Блог

Канбан, мини-хакатоны, Inbox и другие моменты из жизни команды, создающей сложный технологический продукт

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

YS: Для начала зададим уже ставший традиционным вопрос, как вообще началась работа в YouScan?

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

Так, в определенный момент мне на глаза попалось объявление о вакансии Customer Success менеджера в YouScan, а поскольку компания «на слуху», то я подумал: «Почему бы и нет?». Отправил резюме, встретились, поговорили, потом еще раз поговорили, потом еще раз поговорили, и договорились до того, что в YouScan появилась позиция продакт-менеджера (которая раньше не существовала), а я приступил к работе в этом качестве.

YS: И какое было самое первое впечатление о работе и людях? Как оно изменилось со временем, если изменилось?

АР: Больше всего меня впечатлило (и впечатляет до сих пор) парадоксальное сочетание очень высокого ритма происходящего, высоких требований, нацеленности каждого члена команды на максимальный результат с крайне легкой и непринужденной атмосферой в офисе, полной оптимизма и доверия. До этого я встречал подобное только по отдельности…

YS: А в чем конкретно заключается работа продакт-менеджера в YouScan, как она помогает клиентам достигать своих целей при помощи мониторинга социальных медиа?

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

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

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

Разработчики — это не простые «исполнители», а творцы нашего продукта — это очень важно! Чтобы творцы делали то, что будет приносить пользу клиентам, им нужны не «технические задания», а понимание сценариев использования той или иной функциональности, целей, которые нужно преследовать, приоритетов.

YS: Итак, создание YouScan — это командная работа, а как команда творцов взаимодействует с другими подразделениями?

АР: Мы делаем все, чтобы взаимодействие с одной стороны было максимально свободным, а с другой — не отвлекало всех от их основной деятельности.

Во-первых, dev-команда проводит ежедневные стендапы, в которых участвует также команда отдела Customer Success и отдельные члены sales-команды. Каждый максимально коротко рассказывает о том, чем занимался, чем собирается заниматься, какие есть проблемы и вопросы. Максимально допустимая продолжительность ивента — пятнадцать минут, но мы обычно укладываемся в десять. Он всегда начинается в одно и то же время, и для членов dev-команды обязателен. Если опаздываешь даже на полминуты — будь добр, кинь 50 гривен в специальную баночку. Допускается участие «удаленно» через hangouts, но в этом случае тоже нужно бросить 50 гривен в баночку, когда будешь в офисе.

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

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

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

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

20160728_8896_a_mikhaylov_flat

YS: Вертится на языке вопрос про банку с деньгами, а что делаете с накопленным капиталом?

АР: На накопившиеся деньги раньше в основном виски покупали, сейчас же команда стала больше, некоторые не пьют, поэтому деньги там начали просто накапливаться. Баночка превратилась в минибанк с функциями микрокредитования на случай, если кому-то нужна наличка, а в кошельке нет.

YS: Вернёмся к специфике работы, а всё-таки, как расставляются приоритеты по задачам?

АР: Как ни странно, этот вопрос не главный, вернее на него есть очень простой ответ. Приоритет в каждый момент времени один для всей команды, и он явно обозначен на нашей канбан-доске отдельной горизонтальной полосой. Еще одна горизонтальная полоса зарезервирована для «пожаров» — срочных задач, обычно связанных с какими-то неисправностями, такие задачи имеют высший приоритет. В остальном же разработчики имеют высокую степень свободы в выборе того, за что браться. Каждый знает обо всех актуальных задачах, все они есть на доске, также всегда можно со мной посоветоваться о том, что следующее брать в работу.

Главный же вопрос для любой задачи — с чего начать, и в более широком смысле — на какие этапы разбить ту или иную задачу? Вот тут начинается самое интересное 🙂 Разработчики всегда хотят делать все по порядку, как будто слой за слоем укладывая ингредиенты пирога. Но беда в том, что при таком подходе попробовать пирог можно будет лишь тогда, когда он полностью готов. А что если окажется, что он на вкус не такой, как хотелось бы? Поэтому, лучше начать с того, чтобы приготовить «микрокусочек» этого пирога, но так, чтобы его уже можно было попробовать. Но как это сделать? Тут нет универсального решения, для каждого случая приходится подолгу общаться с разработчиками, чтобы найти такой подход, и в большинстве случаев это удается.

YS: А как оцениваете эффективность команды, какие KPI используются?

АР: Если говорить о KPI с точки зрения продуктивности dev-команды, то нужно для начала осознать, что «производительность» как каждого человека, так и команды вместе взятой, является константой. Если вам кажется, что для получения лучшего результата нужно больше и усерднее работать, то это глубокое заблуждение (конечно, если при этом взять за аксиому, что каждый член команды ответственен и «не ленится»).

Точно также очевидно, что результат при этом никак не является константой. Так от чего же зависит результат? Для того, чтобы найти ответ на этот вопрос, нужно для начала немного разобраться с тем, как работает технологический бизнес. Основная его особенность — это высокая степень неопределенности, с которой приходится работать, а если взять конкретно нашу сферу, то тут она не просто высокая, а крайне высокая. Как добиться максимальной эффективности в условиях высокой неопределенности? Единственно верный ответ — двигаться максимально короткими шагами с тем, чтобы после каждого из них получать обратную связь и корректировать траекторию. Отсюда вывод: результат будет тем лучше, чем короче будет промежуток времени, который пройдет с момента зарождения идеи (или планирования какой-то задачи) до момента появления фичи на продакшине.

YS: Само понятие «канбан» сейчас на слуху, а если простым языком объяснить, что это такое?

АР: Основная фишка канбана — лимит на «work in progress», то есть ограничивается количество задач на каждой стадии разработки. Есть доска (лучше всего — физическая, а не электронная), на ней карточки, которые означают задачи (правильнее называть их «пользовательскими историями»), и есть вертикальные полосы. Каждая вертикальная полоса соответствует определённой фазе разработки: запланировано, в работе, протестировано и т.д., для разных компаний это может быть по-разному. А для каждой такой полосы есть лимит на количество карточек, которое может там находиться, лучше всего, чтобы этот лимит совпадал с размерами самой доски, тогда меньше соблазна его нарушить. Не вдаваясь в детали, как именно работает «механика» разработки в таком случае, такой подход позволяет максимально сократить промежуток времени с того момента, когда мы решили что-то делать до момента, когда оно появляется на «продакшене».

Этот подход не нов, он появился в компании Тойота еще в середине прошлого века, в Интернете можно найти много материалов на эту тему, почитайте. Сейчас же канбан как ничто другое лучше всего подходит для разработки технологических продуктов.

YS: А могут ли программисты сделать что-то, что не запланировано, чего нет на канбан-доске?

АР: Да, могут, но только по пятницам. Пятница — это так называемый «education day», день когда каждый может выбрать какую-то задачу, которая, как он считает, поможет ему развиваться. В пятницу мы не проводим стендапы, работаем в максимально неформальной обстановке. Но это не означает, что все бездельничают, как раз наоборот, самые интересные и смелые идеи воплощаются в жизнь именно по пятницам.

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

20160728_8800_a_mikhaylov_flat

YS: Поговорим о более личном, с чего обычно начинается рабочий день?

АР: Как бы это банально ни звучало, рабочий день начинается с формирования планов на день. Анализирую список дел, сопоставляю его с календарем (смотрю, какие встречи/созвоны назначены), стараюсь объективно оценить, что успею. Если вижу, что все успеть нереально, часть дел переношу на завтра или на следующую неделю.

Кстати, для управлениями всеми своими задачами пользуюсь Google Inbox — очень удобно. Если вижу что какое-то дело переношу на следующую неделю уже n-й раз, то в большинстве случаев это означает, что дело на самом деле не настолько важное, поэтому пользуюсь функцией “Snooze to … someday”. Одну-две задачи в неделю постигает такая участь. Я также изначально рассчитываю на то, что большая часть дня уйдет на внеплановые активности (такова уж моя работа). Поэтому стараюсь оставлять в планах не более одного объемного дела, например, написать статью или глубоко исследовать какую-то проблему, а также до десяти небольших дел, типа что-то кому-то о чём-то написать, что-то проконтролировать, кому-то ответить и т.п.

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

YS: А есть увлечения помимо работы, хобби?

АР: Главное мое увлечение — семья, у меня трое детей, что бы я ни делал, хочу чтобы это приносило пользу для всей семьи. А ещё играю на фортепиано, пишу музыку, кое-что даже есть на моем ютуб-канале, хожу в горные походы, люблю велопрогулки. Всё, что происходит в мире технологий — тоже мое хобби. Мне интересно отслеживать тренды, пытаться предсказать, как поведет себя тот или иной сегмент экономики с учетом влияния инноваций, и т.п.

YS: Последний вопрос на засыпку, какую книгу можно посоветовать тем, кто хотел бы профессионально развиваться в такой же сфере?

АР: Для того, чтобы заниматься развитием технологического продукта, очень важно для начала разобраться с основными принципами работы технологических бизнесов, поэтому советовал бы начать с 2-х настольных книг любого «стартапера»:

Также могу посоветовать неплохую книгу про поведение пользователей:

Ну и про канбан:

YS: Ну что же, отправимся изучать рекомендуемую литературу и благодарим за интервью. В следующем интервью расскажем о том, как мы… Впрочем, со временем сами узнаете 🙂

комментарии

Добавить новый комментарий: