Зачем мы перевели разработку Work.ua на Shape Up и как это сделали

Андрей Боровик, сооснователь Work.ua, начинал как дизайнер — нарисовал первые эскизы сайта и на протяжении всего времени существования проекта активно принимал участие в его разработке на всех уровнях. Сейчас, когда проект вошел в 25 самых посещаемых ресурсов в Украине, Боровик руководит отделом разработки. В колонке для AIN.UA он рассказывает, как разработка Work.ua переходила на новую схему работы и что из этого получилось — а что нет.

Проблемы, с которых все началось

Work.ua — это украинский проект, который вырос большим и славным из студии веб-дизайна «Реактор». Проект разрабатывался постепенно, и в определенный момент процессы, которые достались ему по наследству, стали работать плохо. В частности, было так:

• Чтобы разработать новую функциональность, долго и подробно писались длинные технические задания, часто вообще без консультаций с дизайнерами и разработчиками.
• Эти ТЗ передавались разработчику с дизайнером.
• В процессе реализации часто выявлялось, что многое из ТЗ нужно сделать иначе по техническим и другим причинам.
• Часть ТЗ теряла актуальность по ходу проекта.
• Эта часть делалась уже без ТЗ, все менялось на ходу.
• Разработкой часто занимался один программист. Это круто: он всегда в курсе всего и может двигаться очень быстро. Но разработчик мог выпасть из процесса (отпуск, болезнь, доработка чего-то из прошлого).
• Сроки из-за этого всего переставали быть предсказуемыми.
• По окончании проекта разработчик уходил на новый проект, но ему часто приходилось возвращаться на доработки.
• Не было понимания, сколько разработка может сделать за условный квартал.
• Сложность задач и качество их выполнения ограничивались способностями одного программиста-исполнителя, а не команды.

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

Книжка и концепция

И тут мне под руку попалась книжка от Basecamp Shape Up: Stop Running in Circles and Ship Work that Matters. Вообще, я читаю все книжки от Basecamp, прочитал и эту. И концепция Shape Up мне очень понравилась! Книжка короткая, насыщенная, так что пересказать ее будет сложно. Я попробую в двух словах, но лучше прочитать.

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

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

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

Пока команды делают, новые проекты формуются.

Главный же прикол подхода для меня в том, что в нем не объем задачи определяет время на ее выполнение, а время цикла (а потом команда) определяет, что будет сделано в задаче. Такие временные рамки помогают исполнителю делать уступки в угоду законченности задачи, но при этом на старте можно не отказываться от интересных идей: хватит времени — сделаем.

Если сравнивать с классическими аджайлами и скрамами, то, пожалуй, главным отличием Shape Up является то, что в нем больше жизни и свободы. С одной стороны такой подход дает очертания того, что и когда должно получиться. С другой — свободу принимать решения по ходу проекта в соответствии с реальным положением дел и без давления «потому что у нас план».

Эксперимент по практике

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

Команда «заизолировалась» в отдельном кабинете. Работали плотно друг с другом: программисты говорили, что им нужно в первую очередь, дизайнер и верстальщик это быстро давали — простоев не было вообще. Проект и общение по нему мы вели в Basecamp (вообще, книга его и рекламировала, и мы решили попробовать). На контрасте с Jira получилось очень просто и понятно даже без подготовки.

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

Переход

После успешного эксперимента мы решили попробовать внедрить все вместе на весь отдел. Получилось так:

• Разработчики разбились на команды по 3 человека. За командой также были закреплены дизайнер, верстальщик и ПМ.
• Время разбилось на циклы: по 6 недель.
• Каждая команда в течение одного цикла работала над одним большим проектом на все 6 недель (L-ки) или над тремя небольшими — по 2 недели (S-ки).
• Задания по этим проектам готовили до начала цикла в таком виде, чтобы все было более-менее понятно, но при этом у команды оставалось достаточно свободы, чтобы получить результат в установленное время (например, отказаться от лишнего или, наоборот, сделать что-то прикольное).
• Мелкие задачи (а иногда и S-ки) по ходу делала команда дежурных, которая менялась каждый цикл.

Со временем мы перешли с Jira на Basecamp, но это тема для отдельной статьи.

Формовки

Задания для команд получались в результате формовок. Формовками занималась команда из меня, архитектора и руководителей ПМ-ов, разработчиков, дизайна и мобильной разработки.

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

Сложности

Конечно, мы столкнулись с проблемами:

• Прийти к общему мнению командой из 6 формовщиков было сложно, ведь у всех разный опыт и мнения. Нам пришлось научиться договариваться и спорить, зато мы получали отличные решения.
• Мы не успевали наформовать достаточно задач до начала цикла, и в результате некоторые команды начинали позже и с плохим заданием. Пришлось научиться начинать формовать заранее.
• Мы были излишне оптимистичны по тому, насколько большой проект можно запихнуть в цикл. Но гибкость концепции позволяет подрегулировать то, что будет сделано, по ходу. А мы учились на результатах этих регулировок.
• Мы выходили за рамки циклов, и в результате «ползла» вся структура. Опять же, с опытом это практически пропало.
• Дизайнеру и верстальщику в конце цикла часто нечего было делать, потому что их работа была закончена. Но они не гуляли, а делали другие мелкие задачи.
• В начале у нас не получалось добиться «кулдаунов» — времени, когда проект уже на проде и происходят необязательные доделки. Из-за этого разработчики не успевали остыть и были в постоянном напряжении, а какие-то вещи, которые хотелось бы доделать — не доделывались. Но с опытом мы достигли и кулдаунов.

Преимущества

Несмотря на проблемы, всяческих преимуществ оказалось очень много:

• Командность и общение. Участники команды взаимодействуют между собой, работая на общий результат (раньше действия разработчиков были более обособленными).
• Автономность. Куча решений ушла в команды, и ребята прекрасно справляются.
• Завершенность. За 6 недель нужно сделать все, что можно, чтобы проект был законченным и к нему не нужно было возвращаться потом.
• Общий контекст всех, кто работает над проектом. Это помогает вместе находить хорошие решения, а также делает проект более стабильным. Отпуск одного человека не остановит весь проект.
• Сфокусированная работа над проектом. Раньше параллельных проектов было больше и приходилось чаще прыгать с одного на другое, теряя время на переключение.
• Процесс планирования стал более предсказуемым. Мы знаем, сколько проектов может сделать разработка за цикл. И не набираем лишнего, с которым не сможем потом справиться. Зато то, что набрали, — выполняем в срок (ну почти).
• Процесс подготовки задания стал короче, но осмысленнее. На начальном этапе в формовке задачи принимают участие ребята, которые обладают знаниями продукта со всех его сторон: архитектура, программирование, бизнес, дизайн и т. д. При этом задание не прописывается до мельчайших подробностей, которые все равно потом придется адаптировать к реальности.
• Масштабируемость. Число команд выросло с 3 до 6, и норм — мы успеваем формовать, а команды получили еще больше свободы.
• Время нормально все закончить. Когда у нас получается сделать все как надо, в конце цикла остается время, чтобы дополировать, убрать мусор, изменить что-то в лучшую сторону и возрадоваться. 

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

Автор: Андрей Боровик, сооснователь Work.ua