Блог компании kolesa group

Делимся алгоритмом работы над созданием дизайн-принципов, который сработал для нас и может пригодиться кому-то ещё.

Интродакшн

Раньше дизайнеры в нашей компании работали в едином отделе по принципу студии. Руководитель распределял задачи по навыкам, загруженности и грейдам. Но по мере роста и развития компании и команды, стали менять и подходы к проектированию. Поэтому осенью 2020 года мы поменяли оргструктуру и выслали в каждую продуктовую команду выделенного дизайнера для бОльшего погружения в продукт.

Работая по старой схеме в первой половине 2020 года, мы научились коммуницировать между собой удаленно. Но когда отсортировали людей по продуктовым командам, у дизайнеров стало меньше времени на общие демо и синхронизации, а сессии дизайн-критики стали затягиваться.

Проблема, которую мы решали

Стало очевидно, что у нас отсутствовал единый вектор мышления. Обратная связь друг другу была основана на личном мнении и ретроградном Меркурии. Поэтому мы решили создать несколько принципов, которые задавали бы нам общий вектор хорошего дизайна. В результате группа людей с персональным мнением должна была превратиться в команду с общими точками зрения и подходами.

Создание принципов нужно в первую очередь дизайнерам, но в сессиях демо участвуют также и продакты, и разработчики, и создатели контента. Вся продуктовая команда должна идти в одном векторе и понимать, почему решения в интерфейсах именно такие или как сделать хорошо, исходя из описанных принципов вместо личного мнения.

Небольшое отступление про компанию и команду

Kolesa Group продуктовая IT-компания, основанная в Казахстане. Мы создаем и развиваем классифайды сервисы для публикации объявлений для людей и компаний в Казахстане и Узбекистане.

У нас 4 основных продукта:

• Kolesa.kz классифайд в категории Авто с MAU в 5 млн пользователей. Это 32 % всех интернет-пользователей в стране.

• Krisha.kz классифайд в категории Недвижимость с MAU 3.5 млн пользователей. Это 23 % всех казахстанских интернет-пользователей.

• Market.kz классифайд для всех категорий товаров и услуг. Ежемесячная аудитория более 2 млн человек.

• Avtoelon.uz автоклассифайд в Узбекистане. MAU 2 млн пользователей.

Процесс

Для формирования принципов нужно было провести брейншторм, но чтобы он был результативным, предварительно нужно было собрать качественные данные и провести анализ, чтобы узнать, как устроены принципы других компаний.

Шаг 1. Рисерч и поиск референсов

Вначале мы подглядели готовые базы принципов разных команд, потому что хотели узнать, как это устроено у других. Принципы многих команд очень схожи между собой и часто пересекаются.

Вот подборка ресурсов, где собраны референсы от других команд:

• https://principles.design/

• https://www.designprinciplesftw.com

Нам нужно было создать принципы, которые бы решали базовые, низкоуровневые проблемы. Например, доступные цвета и контрасты, понятная коммуникация в текстах, отклик интерфейса и его текущее состояние. Нашей главной целью было повысить качество продуктов прямо сейчас.

Шаг 2. Исследование внутри компании и создание опросов

Для проведения объективного брейншторма нужны были качественные данные, поэтому мы решили снять температуру и опросить нескольких сотрудников компании.Мы сделали опросник, понимая, что качество ответов может не соответствовать ожиданиям, но нам нужен был взгляд со стороны и понимание настроя людей.

В опроснике были вот такие открытые вопросы:

1. Перечислите через запятую характеристики интерфейсов и процессов разработки, которые уже работают хорошо в наших продуктах.

2. Напишите, что именно хочется исправить в наших продуктах и какие характеристики интерфейсов или процессы разработки хочется добавить.

3. Приведите примеры продуктов и процессов разработки в командах, которые вас вдохновляют, и опишите, чем именно они вас вдохновляют.

Кроме внутреннего опроса, мы собрали распространенные проблемы в продуктах из базы службы заботы о пользователях (звонки, письма, отзывы в app-маркетах). Это помогло сегментировать проблемы, например, технического или интерфейсного характера.

Шаг 3. Подготовка к шторму

Когда мы определились с целями всей этой затеи, побежали делать доску в Miro и назначать дату брейншторма.

На доске подготовили такие штуки:

• Вытащили примеры принципов некоторых дизайн-команд, которые покрывали наши проблемы.

• Вытащили результаты опросов.

• Подготовили площадку для боя. В этой области будет проходить брейншторм. У нас это проходило в Miro.

Шаг 4. Собственно брейншторм

Сам брейншторм был строго ограничен по времени и разделен на этапы. Прежде всего мы обсудили 3 главных вопроса:

• Почему мы создаем принципы?

• Для кого мы их создаем?

• Как те, для кого они будут сделаны, смогут их использовать?

Обсудив вопросы, модератор брейншторма обозначил правила игры, и все участники приступили к штурму.

1. Сначала каждый участник писал на стикерах ПЛОХИЕ реализации и характеристики интерфейса или пользовательских качеств в продуктах. Ставили таймер на 10 минут.

2. Затем рядом с каждой плохой реализацией каждый участник должен написать решение проблемы, чтобы ПЛОХОЕ стало ХОРОШИМ 20 минут.

3. Затем нужно было структурировать карточки и найти связи, при этом мы использовали результаты опроса и продуктовых запросов из базы службы заботы, которые заранее подготовили на доске 20 минут.

4. В итоге у нас вышло несколько категорий, которые мы тоже объединили в сегменты:

A) человекоориентированность, прозрачность и честность в продуктах;

B) осознанность в проектировании, консистентность, качество продукта, эстетичность;

C) контроль состояния, понятная коммуникация, простота и очевидность;

D) командность.

5. Затем каждый участник отдал голос наиболее важным, на его взгляд, категориям 3 минуты.

6. После мы разложили варианты, набравшие наибольшее количество голосов, по пирамиде дизайн-принципов.

Что осталось?

1. Осталось придумать названия для принципов и их описания. Нам важно, чтобы названия были запоминающимися и их описания развернуто объясняли суть.

   Времени на встрече осталось не так много, и креатив немного охладился, поэтому мы договорились взять домашнюю работу по неймингу и вернуться на следующую встречу со своими вариантами.

2. Через несколько дней, вновь собравшись, мы выкатили предложения по неймингу и описанию каждого принципа. Совместно выбрали варианты, которые точнее всего передавали смысл, который мы хотели донести.

3. Так мы зафиксировали важные моменты, на которые всегда нужно обращать внимание при проектировании, и выставили их по пирамиде, в которой самый важный принцип находится в самом низу и является фундаментом всего.

Вот что у нас получилось:

[Сначала люди]

Делаем продукты и сервисы, которые ежедневно помогают миллионам разных людей. Мы уважаем их время, желания и свободу выбора, поэтому наши продукты и сервисы, как и мы, честные, прозрачные и всегда дают обратную связь.

[Сознательный подход]

Проектируя, мы опираемся на исследования и наблюдения. Мы принимаем решения только после подтверждения наших предположений и качественно их реализуем

[Очевидность]

Наши интерфейсы и внешние коммуникации едины, понятно объясняют, на каком шаге находится человек сейчас, и помогают, если что-то пойдёт не так.

[Коллаборация]

Мы объединяем продуктовый дизайн, контент дизайн, исследования, маркетинг и технологии разработки для единой синергии и улучшения опыта использования наших продуктов и сервисов.

[Инновации]

Создаем передовые методы, инструменты и технологии для развития дизайн-процессов и качества продуктов. Делимся экспертизой с людьми, которые создают полезные продукты и сервисы для людей во всем мире.

Корабль поплыл

Наши дизайн-принципы зафиксированы в Figma. Уже сейчас они упрощают нам сессии дизайн-критики, поскольку фидбек основывается на четкой аргументации, а не на абстракциях. При этом ошибок встречается все меньше, ведь дизайнеры, проектируя, сразу пропускают свои решения сквозь призму принципов, что позволяет на ранних этапах избегать непонятных формулировок и текстов или неочевидного поведения интерфейса.

Наша следующая цель распространять принципы по всей компании, ведь в создании продуктов участвует множество отделов, и их можно применить практически в любой сфере и компетенции. Например, QA при тестировании продукта тоже защищает сторону пользователя и принципы помогут объективно оценить важность исправить что-то до релиза.

Теперь во время дизайн-критики мы стараемся аргументировать фидбек, исходя из принципов, при этом иногда в сессиях участвуют разработчики и менеджеры, что дает эффект распространения метода фидбека в другие отделы.

Заметить эффективный рост качества продукта только от внедрения таких принципов сразу невозможно, пока мы только следим за показателями NPS и внешним feedback loop (звонки, письма, отзывы в app-маркетах).

Дизайн-принципы пишутся не один раз и на всю жизнь. Они должны решать вашу конкретную проблему в данный момент. Мы уверены, что в будущем будем пересматривать свои принципы, когда осознаем, что текущие стали обыденностью, будем строить новые принципы вокруг наших продуктов. Но это будет уже следующий этап стратегии развития дизайна продуктов.

В современных продуктовых компаниях самое главное это продукт и его пользователи. Чтобы повысить фокус разработки на продукте, стандартом де-факто в отрасли являются кросс-функциональные команды.

Мы в Kolesa Group прошли путь от иерархической структуры управления в матричную. Хапнули багов и пропатчили ее до оптимального, в нашем профиле, состояния.

В статье разберем:

1. Как достичь автономности команд разработки.

2. Как эта автономность помогает нам расти в 2 раза по всем показателям.

Немного контекста

Kolesa Group это классифайды. 4 продукта в 2-х странах (Казахстан и Узбекистан) на 4-х платформах (iOS, Android, десктопный и мобильный web). Начинает свою историю компания с печатного издания. В 20хх году печатное направление было закрыто, и компания целиком сосредоточилась на онлайн-направлениях.

Вся разработка ведет свою историю с веб-направления. Изначально это были fullstack-разработчики в отделе под названием Веб-редакция. По мере роста в компании появлялись сначала админы, потом тестировщики, мобильные разработчики. Разделились на frontend и backend веб-разработчики, и наконец разделились QA на web и mobile.

Немного внутренней кухни

У каждого из направлений есть руководитель, который отвечает за:

• операционные вопросы (отпуск, больничный, найм, увольнение),

• развитие и обучение,

• формирование требований к позиции,

• оценку и грейдирование специалистов,

• техническую стратегию по направлению.

Специалисты разделены на команды по продуктам. А микрокоманды по микропродуктам. В каждой команде есть тимлид: отдельно веб, отдельно мобильный. Также есть менеджер продукта, подчиняющийся руководителю продукта, который в свою очередь подчиняется директору по продуктам.

Такая структура позволяет нам работать через короткие цепочки коммуникации. Менеджер продукта ставит задачи напрямую исполнителям и осуществляет контроль за их реализацией. Однако мы столкнулись с рядом проблем.

О проблемах и их решениях

Проблема 1. У специалиста появилось несколько начальников.

Руководитель направления, тимлид, продуктовый менеджер. Возникали ситуации из басни Лебедь, рак и щука, когда на бедного разработчика навешивали одновременно продуктовые и технические задачи с одинаковым приоритетом.

Решение. Общий бэклог и джентльменское соглашение между технарямии бизнесом.
Соглашение заключается во фразе Технари всегда топят за бизнес и принимают решения исходя из интересов бизнеса, а продакты в свою очередь дают разработке возможность срезать техдолг и реализовывать техническую стратегию.

Проблема 2. Организационные вопросы.

Для специалистов был непрозрачен алгоритм действий при необходимости взять отпуск, отгул, больничный.

Решение. Сформулировали матрицу ответственности.

Прописали, за что отвечает каждый из руководителей и как следует действовать специалистам в тех или иных обстоятельствах. В первую очередь, здесь учитывались интересы команды в целом.

Проблема 3. Появилась некоторая разобщенность внутри команд.

Мобильные разработчики были распределены по продуктам одними из последних. Получалось так, что взаимодействие между бэкендом и мобилкой частенько усложнялось.

Решение. Ввели роль SEM-а или Software Engineering Manager.

В его обязанности входит обеспечение оптимального процесса разработки продукта всеми (микро-) командами на всех платформах. По сути, это технический директор (CTO) конкретного продукта.

Немного о SEM-ах: какие задачи они выполняют

Помимо оптимизации всего процесса разработки, SEM решает другую важную проблему не допускает микроменеджмент со стороны руководителей отделов. Теперь руководители могут решать возникающие проблемы системно. На уровне процессов и культуры, а не локально с помощью микроменеджмента.

Изменение в воркфлоу команды происходит по цепочке:

Руководитель департамента -> SEM -> Тимлид от департамента -> Юниты

Иногда, в этой цепочке SEM-у достаточно дать свой аппрув. Важно отметить, указанная сверху цепочка это не цепочка коммуникаций, а применения каких-либо изменений в команде на уровне процессов и даже культуры. Коммуникации остаются свободными во всех направлениях.

Новая роль: тимлиды мобильной разработки

Даже если на роль SEM-а подбирались самые зубастые разработчики, которые имели опыт тимлидерства, их скиллов не всегда хватало, чтобы закрыть все направления. Последним, что мы сделали, было добавление в каждый продукт мобильных лидов. В вебе продуктовые лиды исторически были. Тимлиды в мобайл отвечают за техническую экспертизу по мобильному направлению, говорят на одном языке с разработчиками и вместе с SEM-ом дружат мобилку и бэкенд.

Итог

Благодаря этим изменениям за год мы ощутили значительные улучшения в производительности команд. Все показатели, которые мы замеряем, улучшились в два и более раза. Мы стали поставлять код на продакшен в два раза быстрее, закрывать в два раза больше задач. Мы реализуем техническую стратегию развития, не останавливая и не замедляя развитие продуктов.

Аналоги

Полных аналогов SEM мы не нашли. Скорее потому, что каждая компания растёт и развивается по собственному сценарию. Все мы решаем схожие проблемы схожими, но не идентичными путями.

Так, например, в компании Spotify существуют Engineering Managers.Их основные задачи:

1. Создание, сплочение, лидерство и менторство

2. Найм и увольнение людей в команду

3. Фидбек

4. Ответственность за техдолг и и стратегию команды

5. Сотрудничество с другими инженерами и менеджерами по продуктам для решения интересных и сложных проблем на платформе.

6. Развитие здоровой культуры совместной инженерии, в соответствии с ценностями компании

7. Быть активной частью команды лидеров и сотрудничать с другими лидерами в компании

8. Растить техническую экспертизу команды

Engineering Manager в Badoo:

1. Работает с командой над внедрением новых фич, обучает и развивает команду в направлении гибких методологий.

2. Возглавляет междисциплинарную команду, работающую с клиентом, серверной частью и отделом контроля качества, помогая всем членам команды развивать свою карьеру в компании.

3. Работает с менеджером по разработке и менеджером по продукту, влияя на план развития его продукта.

4. Является гарантом того, что команда создаст решения соответствующего уровня качества.

Привет, Хабр!
Недавно мы провели Kolesa QA Meetup онлайн-встречу для Mobile и Web QA-инженеров и тестировщиков. На примере кейсов Kolesa Group ребята рассказали, как улучшают процессы обеспечения качества в продуктах и автоматизируют тестирование. Делимся видео докладов.

Независимый мокинг зависимостей в Koin, Аида Сундетова, Mobile QA-инженер

При создании тестов с моками, может возникнуть ситуация, когда тесты на разные кейсы будут получать один и тот же мок-объект с одинаковыми данными. Это приводит к тому, что следующий тест будет иметь дело с данными для предыдущего теста. Так возникает зависимость между тестами, а это, как известно, нарушает одно из основных требований к написанию тестов независимость. В своем докладе Аида рассказывает о том, как писать независимые тесты с моками в контексте dependency injection, используя основные методы фреймворка Koin.

QA-центрический подход к разработке, Игорь Бучинский, ведущий Mobile QA-инженер в Kolesa Group

Игорь рассказывает о том, что QA может предложить команде помимо своих мануальных способностей проверки задачи и как он может влиять на процесс разработки более комплексно и основательно.

Пути подготовки данных к автотесту, Сергей Рыжков, Web QA-инженер в Kolesa Group

Сергей рассказывает о том, какими способами можно готовить данные к автотестам, о плюсах и минусах каждого из способов и о том, как это работает в Kolesa Group.

QAчественные меры, Асель Абильмажинова, Web QA-инженер в Kolesa Group

Асель рассказывает о нашем опыте перехода от тестирования к полноценному Quality Assurance и о мерах, предпринимаемых командой для обеспечения лучшего качества продуктов. Она затрагивает тему shift left и важность проведения ревью требований, рассказывает о том, как внедряли чек-листы в Kolesa Group. А еще, делится опытом поддержания базы знаний в актуальном состоянии, повышения awareness того, что происходит в продуктах среди сотрудников и реагирования на фейлы на проде.

Есть мнение, что войти в айти легче через тестирование. Будучи на третьем курсе, я part-time подрабатывала асессором. Тогда я впервые попробовала себя в тестировании, увидела первые чек-листы (я еще не знала, что они так называются). Войти в айти не было моей целью, потому что я уже и так училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group.

Месяц подготовки: чтение пресловутого Романа Савина Тестирование дот ком, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.

Чтение книг != тестированию реальных продуктовых задач. Так, в ходе работы я сталкивалась с интересными кейсами и проблемами. Теперь, уже будучи миддлом, я рефлексирую и вижу паттерны поведения, которые тормозили мое развитие в профессии. Ошибки, на которые, будучи джуном, я не обращала внимания, но которые позже стали моей болью. Ошибок было куда больше чем три, но именно эти я повторяла из раза в раз, не отдавая себе отчета.

0. Не просить помощи

Когда я была стажером, мне очень хотелось показать себя, потому что от этого зависело, возьмут ли меня на работу. Но даже после успешного прохождения испытательного срока я взяла свои стажерские наклонности в junior-позицию. Я могла работать над парой задач в то время, когда еще парочка висела в бэклоге. И в тот же момент я частенько пыталась решить какие-то сторонние вопросы и проблемы. Итог: несколько висящих в воздухе задач, ожидающих меня, в то время как другой тестировщик мог быть свободен.

Я не говорю, что стараться и делать больше, чем нужно, это плохо. Плохо неразумно оценивать свои возможности и строить из себя героя в попытках сделать все. Не сделаешь. А если и сделаешь, то не так качественно, как мог бы. Просить помощи не зазорно. Грамотно делегировать нагрузку и задачи круто. Своевременные релизы и тщательно проверенные фичи лучшее, что может быть для продукта и бизнеса.

Вывод: проси помощь. Все мы люди и иногда нуждаемся в ней. Не успеваешь делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.

1. Бояться задавать вопросы или задавать слишком много вопросов

Я интроверт, к тому же время от времени страдаю синдромом самозванца, поэтому когда у меня возникали вопросы, очень стеснялась подходить к старшим товарищам. Мне казалось, что мои вопросы глупые и вообще я сама могу найти на них ответы.

В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес-логикой, особенностями архитектуры и различными workflow, можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфических вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл-поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного на поиски времени и, возможно, так и не найденный ответ. Помочь избежать этого могли 510 минут общения с коллегами.

Но у этой медали есть обратная сторона задавать слишком много вопросов. Даже не так. Задавать вопросы без предварительно проведенного самостоятельного исследования. Бывают случаи, когда человеку легче подходить каждые пять минут с новыми вопросами, в то время как ответы на них можно было бы найти самому.

Вывод: иногда действительно продуктивнее просто спросить у коллег то, чего ты не знаешь. Но перед этим всегда нужно самому провести небольшой поиск ответа на вопрос и собрать все вопросы, которые возникли по ходу.

Так можно получить новые знания и закрепить ранее приобретенные. А когда ты подойдешь с вопросом к коллеге, ему будет приятно осознавать, что ты проделал хоть какую-то работу сам, прежде чем бомбардировать вопросами его/ее.

2. Не брать на себя ответственность

Когда ты джун, ты получаешь простые задачи и несешь меньше ответственности. Ты понимаешь, что есть более опытные коллеги, которые в случае чего придут на помощь и решат проблему. Например, при релизе забаганной фичи ты знаешь, что откат к предыдущей версии сделает кто-то другой. И так во многих вещах.Но для роста нужно научиться брать на себя ответственность и решать проблемы самому, брать инициативу и просить более сложные задачи, быть в эпицентре и помогать во время факапов. При совершении ошибок признавать их и искать пути решения. Брать ответственность не только за свои задачи, но и за качество продукта в целом.

Вывод

Через принятие ответственности можно выйти на новый уровень задач и новые челленджи, которые помогут в твоем профессиональном росте. Не бойся ответственности она твой друг.

Это были ошибки, которые я совершала не раз. Если быть честной на 100 %, я даже сейчас их иногда совершаю. Но это абсолютно нормально. Осознание проблемы первый шаг на пути к ее решению.