{"id":9001,"title":"\u0417\u0430\u0447\u0435\u043c \u043d\u0443\u0436\u0435\u043d \u0444\u0438\u043d\u0442\u0435\u0445 \u043a\u0430\u043a \u0441\u0435\u0440\u0432\u0438\u0441. \u041d\u0430\u043f\u0430\u0434\u0430\u0435\u043c \u0441 \u043a\u0440\u0438\u0442\u0438\u043a\u043e\u0439","url":"\/redirect?component=advertising&id=9001&url=https:\/\/vc.ru\/promo\/321129-kritika-finteh-kak-servis-eto-dorogo-slozhno-i-slishkom-universalno&placeBit=1&hash=0f11beca127b0260f19ba1d57bd2ebb2f81750b56fe49269b93cb930545c9faa","isPaidAndBannersEnabled":false}
Офтоп
Dmitriy Soldatov

Как не факапить больше чем запланировали: Scrum в разработке веб-сервисов

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

​Вчера один из членов команды разработки сказал мне, что мы перестали улучшать процессы. Я был счастлив.

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

Эта статья как раз о том, как мы управляем разработкой продукта.

Итак. Сейчас команда разработки — это 9 человек: СТО и scrum master, бэкэнд разработчики, фронэнд разработчики, тестер, дизайнеры и product owner.

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

Суббота

Наша рабочая неделя заканчивается и начинается в субботу. Нет, разработчики не работают 6 дней в неделю.

В субботу собирается узкий круг из Scrum master-а, Product owner-а, дизайнера, ответственного за продукт, и самых заряженных членов команды. Чтобы поиграть в PS4 (в первую очередь) и спланировать задачи в спринт. Обычно планирование занимает 2-3 часа. Это возвращение старых или незаконченных задач в спринт, добавление новых и расстановка приоритетов.

Спринт после пары дней работы

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

— Почему в субботу?

Мы пробовали делать планирование в “рабочий” день. Это не работает. Все слишком спешат: отвлекаемся на клиентов, команда дергает по вопросам, у каждого куча своих задач и так далее. А у нас часто происходят зарубы (читать “проектирование”) как реализовывать тот или иной функционал. Чем больше времени мы можем уделить этому, тем точнее продумаем как будет работать продукт. Это чертовски важно!

В итоге, в субботу у нас готов план на неделю с хвостиком.

— А как же стратегия?

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

Понедельник

Понедельник один из самых офигенных дней. Почти как четверг (об этом позже). В понедельник происходит 2 важных события: Demo и Планерка.

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

Каждый из команды самостоятельно рассказывает о своих результатах. Это делает всех сопричастными. Это важно:)

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

Когда мы запускали Demo, была задача демонстрировать результаты команды разработки. Чтобы на деле показать важность работы каждого разработчика, ответственность и все такое. Но в процессе команды сами попросили расширить Demo, дав слово всем. Мы думали, что от этого Demo разбухнет, станет скучным и длинным. Но по факту оно занимает 15 минут и дает огромную пользу.

Планерка

Это процесс расстановки приоритетов и фиксирования человекочасов у тех задач, которые были запланированы в субботу.

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

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

Сейчас планерка занимает минут 30, а в результате каждый знает и понимает свои задачи и время на спринт.

— Как расставляется время на спринт?

Мы итерационно пришли к тому, что ставить задачи на 100% времени неправильно. Под 100% времени я понимаю не 40 часов, а 36 часов в неделю. Часа 4 уходит на всякую человеческую “фигню” и естественные потребности.

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

У каждого разработчика свое время на внезапные задачи. У scrum master-а оно 12 часов, у фронтэнд разработчика 4 или более часов. Объемы внезапных задач мы выявили итерационно, фиксируя левые задачи и затраты на них несколько недель подряд.

Утро вторник-пятница

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

Поэтому каждое утро у нас проходят стендапы. Мы определили железное время, к которому никто не должен опаздывать (10:15). Во время стендапа каждый коротко рассказывает 3 пункта:

  • результаты за вчерашний день;
  • план на сегодня;
  • сколько осталось времени на спринт и почему он может не успеть.

На стендап уходит 10 минут в день, но это уменьшает риски незавершения спринта, так как сосед может помочь решить какую-то проблему.

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

Рыбный четверг

Была задача еще глубже (чем на Demo) погрузить компанию в особенности задач каждой команды. Цель: синхронизировать всех со всеми, чтобы было понимание, что происходит в соседней команде, и работала взаимопомощь.

Для этого мы стырили формат “Рыбного четверга” у Людвига Быстроновского, немного (полностью) его модифицировав.

Каждый! четверг после работы (в 18.00) мы организуем какую-то презентацию (за полгода существования этого формата ни одного рыбного четверга не пропущено).

Презентации бывают на самые разные темы:

  • ​изменения процессов во внедрении автоматизации маркетинга;
  • гипотезы, сработавшие в платных каналах (маркетинг);
  • регламент отношений поддержки пользователей и разработки;

  • когортная аналитика в продажах;

  • построение воронок на clickhouse, результаты исследования;

  • и мнооого чего еще.

Почему я отдельно выделяю этот формат в статье про разработку? Одна из наиболее частых тем для рыбного четверга — дизайн.

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

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

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

Итерации от прототипа к дизайну

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

Пятница

В пятницу мы подводим итоги. Каждую пятницу в конце рабочего дня (18:00) мы проводим небольшую ретроспективу, в которой коротко разбираем спринт, что удалось и что пошло не так.

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

На основе ретроспектив мы дорабатываем процессы или меняем какие-то детальки.

— После всего этого, завершаем ли мы все спринты вовремя?

Нет.

Потратив суммарно 3-4 часа в неделю на все процессы: планирование, синхронизацию, митинги, мы не завершаем 100% спринтов вовремя. Такова жизнь.

Не самый лучший, но и не самый худший спринт.

Есть еще много работы, чтобы приблизиться к идеальной Burndown диаграмме.

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

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

  • попробовать на ретроспективе фиксировать причины, по которым не завершаем спринты. Посмотреть, какие из них самые больные и частые;

  • и так далее.

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

0
34 комментария
Популярные
По порядку
Написать комментарий...

Нет, разработчики не работают 6 дней в неделю.

Чтобы поиграть в PS4 (в первую очередь) и спланировать задачи в спринт.

А вы оплачиваете овертайм такой как-бы-нерабочей-субботы?

5

Ты еще забыл рыбный четверг ( "Каждый! четверг после работы (в 18.00)").

И почему в пятницу в 18.00 это конец рабочего дня, а в четверг "после работы"?

2

Ну решил на это не обращать внимания, но да, ретроспективы, демо и прочее должны проводиться в рабочее время, в идеале в 4-5 вечера. А то получается овертаймят ребята просто так

0

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

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

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

0

В субботу собираются только по собственному желанию.

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

0

Ну вы в статье написали "В субботу собирается узкий круг из Scrum master-а, Product owner-а, дизайнера, ответственного за продукт, и самых заряженных членов команды".

Я конечно не знаю, являются ли ваши фаундеры тем самым скрам мастером, дизайнером, но звучит как добровольно-обязательное занятие, если хочешь казаться "заряженным членом команды".

3

Они входят в этот злощастный круг))

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

1

А почему бы просто не ответить на первый вопрос, который вам задали?
– Нет, не оплачивается.

3

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

В итоге, если ты приходишь в субботу, то ну молодец.
Если это влияет на работу в целом, хорошая работа вознаграждается.

Поэтому нет, свободное посещение не оплачивается.

0

Потому что есть премии.

–1

Круто

5

Ну что-то это капец какой-то.. Вы такие поработали на недельке, потом у субботу поработали (называйте как хотите это, плойка, потрындеть собрались, пиццу покушать, но вы работаете и голова у коллег не отдыхает от работы).. Это вы как-то оплачиваете? Потому что по сути из-за неспособности организовать процесс в рабочее время на уровне руководителя вы воруете время у коллег, которые могли бы проводить его с семьей или на отдыхе на даче. И вся ваша статья говорит о том, что вы не очень-то задумываетесь о том, что есть время, которое должно принадлежать не вам с работой, а семье, друзьям и всякого рода отдыху. А это плохое уже отношение к сотрудникам.

4

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

0

Ох уж этот скрам... Будто в макдоналдсе поработал. Планерки, стендапы. Скоро гимны во славу скрама запоют

4

Мы только стихи читаем

0

Ну еще театральную постановку готовим.
Но песни петь... мы что, психи?

0

Хорошая статья, спасибо. 3-4 часа на все процессы - это отлично.

3

Спасибо

0

Комментарий удален

Но если по существу. В скраме речь идёт о том, чтобы не вмешиваться в процесс разработки в течении спринта. Это не имеет отношения к планированию спринта, ретроспективам и тд.

Да и пофиг так-то. Надо быть невменяемым, чтобы слепо следовать правилам.

Надо брать методологию и использовать то, что подходит вам. Не подходит - в топку.

Мы поступаем только так. И вам рекомендую.

2

Комментарий удален

Влепил лайк ))

0

А кто за команду то решает? К нам Иисус не спускается и не велит что делать (хотя может в команде кто-то что-то скрывает о себе)

0

Комментарий удален

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

Интересно.

1

Ее наверно в блоге позже напишем: http://www.carrotquest.io/blog/

0

Огонь!

0

а какие еще артефакты Scrum вы взяли на вооружение?

0

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

0

Как называются сервисы на скриншотах?

0

Ещё realtimeboard.com

0

Дмитрий, вопрос)
А как вы относитесь к переговорам на ходу? Вообще, по себе и команде - плохо без физ активности.
И ещё оффтоп. Как вы относитесь к удалёнке? Обязательно ли сотрудник должен сидеть в офисе?

0

Про переговоры на ходу... по моему тут 2 вопроса:

1) Переговоры и совещания...
Вообще, достаточным количеством совещаний можно убить любой проект. Поэтому мы стараемся как-то уменьшить их количество. Делать их утром, пока не ушел в поток или в начале недели. Это удается с трудом, но стараемся.
Поэтому совещания мы разделили на 2 части:
* Про гм бэкэнд или логику. Их делаем голосом, стараемся чтобы присутствовали все кого это коснется + зафиксировать результат в конфлюренсе.
* Про дизайн. Про него тоже много обсуждений. Но их делаем в realtimeboard. Там оставить комменты можно в любое удобное время и никто не отвлекается от текущей задачи. Прекрасно работает.

2) Про физ активность - каждый для себя сам решает. Обед, футбол, пройтись и т.д. Кто-то, например, ездит на обед за 5 км.

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

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

0

Общая цель для всех: UX & CX

0
Читать все 34 комментария
AWS анонсировала платформу Amplify Studio для разработки приложений с минимальным написанием кода Статьи редакции

Платформа подключена к онлайн-сервису Figma.

Удаленное трудоустройство - плюсы и минусы. Юридический взгляд
Такие дела: жалоба на «Яндекс.Такси» за отказ перевозить собаку-поводыря

Девушка с нарушением зрения подала жалобу в прокуратуру из-за того, что водители популярного сервиса такси «Яндекс Go» слишком часто отказываются возить ее с собакой-поводырем.

Google запланировала выпустить «умные» часы Pixel Watch в 2022 году — Insider Статьи редакции

Компания предложила сотрудникам протестировать устройства и дать обратную связь.

«Альфа-банк» доставляет карту, самостоятельно вскрывая конверт, в котором видно все данные

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

«Он как из 2008-го»: браузер Edge от Microsoft начал «отговаривать» пользователей перед установкой Chrome Статьи редакции

Компания предупреждает, что браузер работает по тем же технологиям, но Edge безопаснее.

The Verge
Питч-дейтинг выпуск третий: комбайнеры

Рассказываем историю продакта «Яндекса», который решил помочь фермерам, а также составляем свой словарик стартапера.

Маркировка молочной продукции

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

Запустить игру и не прогореть: зачем нужны маркетинговые исследования в гейминге и как их проводить

Маркетинговое исследование помогает экономить сотни тысяч долларов и выпускать продукты, которые приносят миллионы.

Наводим порядок и изучаем rocket sience. Доклады Go meetup

На прошедшем Go meetup спикеры из Evrone, «Ситимобил» и «Авито» учили правильной организации кода микросервиса, рассказывали, как вырастить MVP в полноценную масштабируемую архитектуру, и разобраться с мусором и алгоритмами управления памятью. Все доклады записаны в студии и доступны для просмотра.

null