В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?

На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?

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

Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.

Участники процесса

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

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

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

И мне кажется, что в этом сложном симбиозе цели компании всё-таки важнее, чем цели отдельных сотрудников. Хорошая компания ценит и любит свои ресурсы, но с точки зрения бизнеса людей (как и многие другие ресурсы) всегда можно заменить (хоть иногда и очень сложно). А вот изменить глобальные цели – невозможно. Да и странно было бы ожидать это от бизнеса. «Давайте мы теперь вместо того, чтобы печь хлеб, будем давать музыкальные представления на детских утренниках!» Ради чего? Если ради большей прибыли и если это легко осуществить, давайте. Но менять направление бизнеса только потому, что пекарь Володя любит и хочет петь (иначе может уволиться), естественно, никто не станет.

Следовательно, первым и самым важным участником производственного процесса является сам бизнес. Он, образно говоря, платит и поэтому заказывает музыку. Чего хочет бизнес? Цели очень разные. Начиная с благотворительности и заканчивая трудоустройством родственника (бывает и так). Но всё же в большинстве случаев главной целью является улучшение благосостояния собственников. И желательно с наименьшими затратами. «Как можно меньше потратить и как можно больше заработать» – это азбука рынка.

В нашем производственном процессе разработки фич представителем бизнеса является продакт-менеджер. Он призван цели бизнеса понять, сформулировать, донести до разработчиков, если потребуется, «разжевать», найти компромисс и всё грамотно спланировать. А затем – проконтролировать процесс, проверить результат и отдать его в эксплуатацию.

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

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

Следовательно, нам необходимо важность целей продакт-менеджера донести до всех участников процесса, объяснить – и, возможно, тогда продакт-менеджеру не придётся бегать за разработчиком каждые полчаса, вопрошая: «Ну, когда уже будет готово?!», мешая ему и отвлекая от работы над задачей.

У нас в Badoo планирование сроков является очень важной частью процесса разработки. Срок доставки новой фичи у нас появляется как можно раньше и называется Due date. Он представляет собой дату, когда фича должна оказаться на продакшне. Due date зависит от многих факторов – на него влияет практически всё в процессе разработки продукта, начиная от степени детализации в описании требуемых изменений и заканчивая методом доставки кода конечному юзеру. Декомпозиция задач, сложность дизайна интерфейсов, тестирование и его автоматизация, количество внешнего взаимодействия и архитектура кода – всё это может радикальным образом влиять на Due date. А учитывая, что на каждом этапе производства работают люди, влияние человеческого фактора на срок доставки колоссальное.

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

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

Кто у нас следующий участник процесса? Пекарь Володя. В нашем случае – программист. Какие цели могут быть у обычного человека, даже если учитывать, что средний IQ в нашей отрасли высокий? Заработать денег и уехать на Бали, купить квартиру, накопить на старость, выплатить кредит, купить гитару Gibson, уйти пораньше с работы, сходить вечером в кино и познакомиться с симпатичной соседкой. Так и быть, поскольку речь об айтишниках, накинем ещё: разобрать беклог на работе, воспроизвести надоевший баг и избавиться от придирок начальника, изучить Erlang, «пощупать» новый фреймворк для Python, выучить английский, собрать дрон на Raspberry Pi и дослушать подкаст про преимущества Kotlin.

Разумеется, есть отличные ребята, которые «болеют за проект» и «понимают бизнес», – ведь мы вместе работаем над общим делом. Но попробуйте им несколько раз не заплатить зарплату (я не пытаюсь обидеть – я специально играю на контрастах, чтобы была понятна суть). Что получится в итоге? Они уйдут в Яндекс, Facebook, Google и любую другую компанию, где зарплаты немаленькие, кормят обедами, стригут и делают массаж и маникюр. И правильно сделают! Работа – это место, где бизнес покупает труд (и мозги) программистов за деньги, поэтому тут правят товарно-денежные отношения. И если у бизнеса цель – получить как можно больше работы за наименьшие деньги, то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше.

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

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

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

Ответственность

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

Мы в Badoo называем такой процесс «ответственностью разработчика» и всячески стимулируем и поощряем эту самую ответственность. Как я уже рассказывал, в наших процессах разработчик выступает в роли микропроджектменеджера проектов, над которыми он работает. Что это означает, как мы это стимулируем? Очень просто: за соблюдение срока (того самого Due date) отвечает разработчик.

Это значит, что и устанавливать срок должен сам разработчик. Разумеется, он должен сделать это, тщательно изучив задачу и стараясь учесть как можно больше факторов при планировании. И разумеется, он должен стремиться этот срок соблюсти. Но при этом нужно быть готовым к тому, что разработчик может сорвать дедлайн. Суть в том, как мы поступаем дальше: мы рассматриваем каждый нюанс, который мешает нам уложиться в срок, и готовим ответ на него (как сделать так, чтобы в следующий раз подобная проблема не повторилась).

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

Хорошо бы, чтобы технический менеджер, получив срок на реализацию (Due date) и подтвердив его, не перестал обращать внимание на проект до наступления дедлайна – это рискованно и откладывает решение многих проблем на последний этап (проблем, которые проще, быстрее и дешевле решить сразу). Тут необходимо с определённой, заранее оговорённой периодичностью (чтобы это не отвлекало разработчика от работы) возвращаться к каждой задаче и уточнять ситуацию, корректировать сроки. Возможно, придётся принимать компромиссные решения, позволяющие уложиться в срок, но на перспективу оставляющие «полировку» и доработки функционала.

Ну, и не лишним будет упомянуть, что просто накинуть n дней к сроку – не лучшее решение. Как это контролировать? Очень просто: задачи, выполненные раньше срока, тоже должны считаться неправильно спланированными. При этом «неправильно спланированные» не значит, что всё плохо и нужно наказать разработчика – это значит, что следует обратить на этот аспект внимание менеджера и обсудить проблемы, повлиявшие на срок (это могут быть, например, «творческий экстаз» и неожиданные находки в процессе разработки).

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

Очень важно уловить суть – мы не стремимся просто заставить всех соблюдать Due date. В фичевой разработке (в отличие от хлебопечения) слишком много неопределённостей. Очень немногие задачи похожи одна на другую – это не «универсальные» батоны хлеба. Если у пекаря «что-то пошло не так» со сроками, значит, либо случился форс-мажор (отключили электричество, вовремя не привезли муку и т. д.), либо он просто лентяй. В разработке же, напротив, редко удаётся уложиться в установленный срок, даже если очень стараться. И если разработчик в срок не уложился, это совсем не значит, что он где-то схалтурил. Суть тут в другом – мы смотрим на то, почему сроки не выдержаны и оцениваем причины (что повлияло на срок: ситуация, ресурсы, лень исполнителей или непонимание бизнес-целей). Разработчик может быть очень работоспособным, но без нацеленности на результат постоянно отвлекаться на несущественные мелочи, которые могут показаться ему важными (или, как вариант, на оказание помощи грузчику Васе, потому что у них приятельские отношения). В результате у разработчика есть масса причин, которые он искренне считает важными, но при этом отсутствует результат. Тут необходима постоянная поддержка и корректировка менеджера.

Итак, подведём итог.

1. Разработчик устанавливает срок задачи в виде Due date. Это срок, когда задача окажется на продакшене.
2. Технический менеджер должен подтвердить срок Due date. Хорошо бы, чтобы он сделал это, предварительно самостоятельно изучив проект, и сразу указал на факторы, способные повлиять на сроки в будущем. Коучить нужно начинать уже на этом этапе.
3. С определённой периодичностью, оговорённой заранее, менеджер должен проверять статус вместе с разработчиком: рассматривать проблемы, которые уже могли возникнуть, и процессы, которые уже можно ускорить. Пример: «Почему ревью трёх строк кода заняло три дня?»
4. После завершения проекта в любом случае нужно делать ретроспективу и ставить вопрос: как в следующий раз сделать быстрее?

Due date – это оптимистичный прогноз. В нашей компании все это понимают и знают, что разработчику нужна поддержка менеджера на всех этапах работы над проектом. И даже если предположить, что у разработчика остаётся небольшой запас времени, который помогает ему чувствовать себя спокойнее и увереннее, в этом нет ничего плохого. У нас цель – сделать эффективно и прагматично, а не «загнать лошадей насмерть», ведь нам ещё работать вместе и делать много крутых проектов.

Примеры

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

1. У задачи было слишком много переоткрытий, потому что тестировщики находили много багов, что привело к лишним временным затратам на всех смежных этапах: переключение контекста, ожидание задачи в очередях и т. д. Плохое решение: наорать на тестировщиков, уволить их, нанять новых. Хорошее решение: покрыть код юнит-тестами, чтобы в следующий раз фидбек о качестве кода получать быстрее; работать над методологиями и практиками по улучшению качества продукта.
2. Дизайнер сделал слишком сложный дизайн новой фичи, кнопки приходилось буквально рисовать с нуля, это заняло больше времени. Плохое решение: попросить дизайнера больше так не делать. Хорошее решение: составить гайдлайны для вашего приложения и иметь стандартные компоненты, дать их дизайнерам и работать в соответствии с гайдлайнами.
3. Разработчик решил новую фичу делать на новом модном фреймворке, это потянуло за собой изменения в других местах, пришлось переписать почти всё. Плохое решение: сказать всем, что фреймворк плохой, и больше никогда его не использовать. Хорошее решение: в задаче кода должно быть по минимуму – только чтобы решить эту конкретную задачу; новые подходы, фреймворки и т. д. должны идти отдельными задачами в рамках технического долга с инвестигейтом, плавным развёртыванием и т. д.
4. В процессе работы над исправлением бага разработчик нашёл ещё один старый баг, стал его исправлять, закопался в старый код и отрефакторил половину проекта. Плохое решение: запретить исправлять баги и рефакторинг. Хорошее решение: в задаче кода должно быть по минимуму – только то, что касается исправления бага. Несмотря на то, что XP предполагает разработку через рефакторинг, необходимо несколько раз обдумать ситуацию, прежде чем пускаться в переделки всего и вся. Часто бывает так, что рефакторинг на данном этапе лучше отложить. На переднем плане должен быть прагматизм, а не красота кода и правильность архитектуры. Считаете, что надо рефакторить – обсудите это с менеджером и лишь после этого начинайте «лопатить» код.
5. Сделали всё вовремя, но через два дня после раскладки обнаружили, что очень важный компонент системы был сломан новым кодом, пользователи не могли пользоваться продуктом, фичу пришлось откатить и исправлять. Плохое решение: оштрафовать разработчика и тестировщиков. Хорошее решение: начать вести мониторинг данного и других важных компонентов системы, покрыть их автотестами, новые фичи снабжать хотя бы минимальной статистикой о работоспособности и об основных бизнес-показателях.

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

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

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

Заключение

Создавая процесс, я стараюсь делать так, чтобы система сама себя оптимизировала. В теории решения изобретательских задач есть подход, который называется «идеальный конечный результат» (ИКР). Он предлагает при решении задачи представить себе идеальный образ решения, когда нужное действие совершается без каких-либо затрат, усложнений и нежелательных эффектов.

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

К тому же имеется масса факторов, влияющих на мотивацию разработчика, на стимуляцию его понимания и принятия целей бизнеса: перспективы бизнеса, понимание важности проекта для компании, стремление к беспроблемному внедрению и эксплуатации, субъективная удовлетворённость заказчиком и т. д. Но многое из этого трудно формализовать и измерить. А тем более сложно порой донести ценность до конкретного исполнителя. Часто даже очень хороший разработчик не улавливает изменение направления «продуктового ветра», и ему требуется какой-то понятный и простой механизм, указывающий верное направление.

Соответственно, я рассматриваю Due date как один из основных инструментов стимулирования ИКР разработчика на всех этапах. Он проходит через весь процесс и заставляет изобретать решения, позволяющие избежать массу проблем в будущем. Он позволяет нам делегировать ответственность, не прибегая к многочисленным KPI. Он понятен и доступен практически всем. И он ведёт нас всех к главной цели бизнеса: сделать как можно быстрее как можно больше. А будет ли это ещё и дёшево, зависит от тех решений, которые мы будем использовать, а следовательно, от нас всех.

А как делаете вы в своей компании?