Стратегии заказной и продуктовой разработки

Как и когда бизнесу построить свою команду разработки и ничего не испортить

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

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

Звоню, рассказываю «как есть». Обещаю подумать, что можно тут сделать и как будет оптимально. Для меня «подумать» — это не вежливая форма «отстань». А абсолютно формальные техники. С выписыванием фактов, поиском связей между ними, вариантов решений и оценкой последствий. В этот раз потребовалось почти двое суток.

«Владимир! — так зовут директора заказчика, с которым у нас сложились доверительные отношения. — Владимир! Вам эта мысль понравится. Вы ее только сразу не отбрасывайте. С ней нужно переспать. Давайте строить внутреннюю команду. In-house. Помогу, чем могу». Понадобилась пара дней, чтобы пройти все стадии: от отрицания до смирения. Но в конечном счете мы с клиентом пришли к единому мнению: «Да, это круто! Это сработает лучшим образом в нашей ситуации». И перешли к конкретным шагам.

В чем разница в организации и управлении. Формирование продуктовой команды. Когда. Где. Как. Из кого?

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

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

Когда ваши задачи переросли коробочные решения, по большому счету есть три варианта: заказная разработка под ключ, аутсорсинг и in-house команда.

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

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

Какие плюсы и минусы в этом подходе?

1. Фиксированная или гибкая стоимость контракта / этапа работ. В зависимости от задачи и стадии проекта вы можете использовать как фиксированную стоимость контракта, так и перейти к гибкой модели, оплачивая фактически затраченное время. Многие клиенты предпочитают работу по фиксированной стоимости, из-за ее предсказуемости. И это правда хорошо работает на запуске крупного проекта. Однако после запуска, когда новые задачи и хотелки в проект летят со всех сторон, и некогда не то, что формализовывать задачи и оценки, но и просто вникать в суть — единственный способ сохранить высокую скорость — Time&Material. Можно комбинировать эти модели.
2. Не беспокоят простои команды. Балансировка нагрузки — один из самых сложных головняков в агентстве. С одной стороны, нельзя допускать простоев команды: это чертовски дорого, расслабляет и приводит к ненужным мыслям. С другой стороны, нужно иметь запас мощностей, чтобы быть готовым быстро включиться в задачи клиента. Если начальник хочет, чтобы у всех подчинённых всегда была работа отсюда и до пенсии, с максимальной интенсивностью — вселенная подкинет такому начальнику работы без выходных и бессонницу в придачу. Впрочем, теперь это головная боль агентства.
   
3. Не надо думать о найме, обучении, мотивации. На что уходит масса энергии.
   
4. Можно ТРЕБОВАТЬ, а не пасти котов. Котики — умные, сытые, независимые IT-шники, с хорошим запасом чувства собственной важности. С ними порой сложно. А тут — можно требовать. Это, в конце концов — почетно!
   
5. Всякие интересные штуки с оплатами. Ну вы знаете эти игры. Печать затерялась, бухгалтер счет на столе забыл, или «у нас платежный день — каждую четную среду месяца, с 11:00 до 11:30».
   

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

Своя команда оправдана, если у вас от 1000 часов в месяц стабильной загрузки. И видно, что такая нагрузка — это не временное явление, а так будет еще долго.

1. Сфокусированность. Если специально не раздергиваете команду криками «Важно! Срочно! Внезапно!», а фокусируете ее внимание на действительно важных задачах, помогаете команде расти и решать проблемы — вам покажут наилучшую результативность. Сфокусированность творит чудеса.
2. Скорость и гибкость — пока не обленились и не разжирели. Тут не так однозначно. По моим наблюдениям, у многих программистов, которые поработали на стороне клиента — вырастает нимб. Особенно у тех, кто почувствовал свою незаменимость («Я — властелин 1С, и фиг вы со мной что сделаете»). Чувство собственной важности зашкаливает до небес. А делать они толком ничего не делают (только инфантильно ноют, брюзжат, все запутывают, убегают от ответственности). В агентствах таких не терпят. А вот в клиентских командах — обычное явление.
   

Оправдано при 1000 часов в месяц стабильной загрузки. Ключевое слово — стабильной!

В команде может быть дизайнер, несколько программистов, руководитель проекта, аналитик-тестировщик. 1000 часов — это небольшая спецназ-команда в 5−7 человек. Как раз норма управляемости для руководителя проекта. При хорошей сработанности может творить чудеса.

1. Простои, найм, обучение, мотивацию, косяки приходится оплачивать. Тут есть риски и очень много работы, которую приходится делать каждый день для формирования команды и поддержания её в форме. Есть масса хороших практик для формирования таких команд, о них — ниже.
2. В агентствах все же больше разных компетенций. И если вам понадобится что-то специфичное, с чем не сталкивалась ваша команда (например, настроить аналитику в мобильном приложении), вы можете потратить много времени на выращивание этой компетенции внутри.
   
3. Руководитель — расфокусирован.
   

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

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

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

В общем-то, можно распределить работу со стратегией и работу с командой по двум или трем ролям:

1. руководитель продукта — отвечает больше за стратегию и маркетинг;

2. руководитель проекта — отвечает за поставку новых версий;
3. Scrum-master — член команды разработки, отвечающий за поддержку команды, игру по правилам и решение проблем команды.

В общем, у руководителей тут очень много работы и сильная расфокусировка.

Гибридный вариант, когда под конкретного заказчика резервируется команда внутри агентства. Команда выкупается полностью (реже — частично, ведь тут сразу возникает расфокусировка). Как правило, оплачивается фактически затраченное время. Стоимость задач зависит от их срочности: работа спринтами, как правило, дешевле. А «вот все прям сейчас всё бросили, и идите перекрашивать кнопку с красной на зеленую» — дороже.

1. Сфокусированность выше, чем в заказной разработке (но не такая, как можно обеспечить в своей команде).
2. Скорость, гибкость.
   
3. Простои, найм, обучение, мотивация, косяки — не ваша забота.
   

Оправдано от 200-400 часов разработки в месяц. Это пара программистов, кусочек руководителя проекта и кусочек тестировщика. Время от времени — дизайнер, если это нужно для задачи.

• Проджект-менеджер, скорее всего, будет заниматься еще 3-4 проектами.
• Норма управляемости 7±2.
  

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

Если у вас идет стабильное развитие разработанного решения, если у вас планы на год-два вперед, причем, нужно часов 200-400 разработки в месяц — скорее всего, в агентстве под вас будет выделенная команда. Внутри нее могут быть некоторые ротации (увы, средний срок работы сотрудника даже в Facebook — чуть более двух лет). Но это не ваша проблема.

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

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

1. Поставьте сильного Руководителя Проекта. Лучше с агентским опытом. Еще лучше — с сочетанием технического бэкграунда и хорошими переговорными навыками. Всё крутится вокруг этих двух компетенций. Знания в маркетинге будут плюсом.

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

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

4. Стройте команды. Не один программист, а минимум — два. Иначе есть риск остаться с неподдерживаемым кодом.
   

5. Первую версию продукта или большую автономную разработку лучше отдать агентству. Так будет быстрее. Когда проект будет вызревать — можно начать формировать свою команду.
6. Используйте классический Scrum или Канбан для организации разработки. Не изобретайте колесо. Проводите стендапы. Демонстрации. Планинги. Обсуждайте задачи. Команда должна чувствовать свою причастность к важному.
   
7. Используйте тикет-системы. Снижайте до минимума СРОЧНО-ВАЖНЫЕ задачи.
   
8. Проводите ретроспективы. Следите за удовлетворенностью команды. Прислушивайтесь и решайте проблемы.
   
9. Подбадривайте. Хвалите больше и чаще. Общий тон настроений в коллективе должен быть мажорный.
   
10. Фокусируйтесь. Минимизируйте переключения команды. Дерготня, суета, спешка приводят к ошибкам и выгораниям.
    
11. Заведите и отслеживайте несколько простых метрик, говорящих об успехе команды. Визуализируйте эти метрики. Это могут быть оценки задач в Story Point (ни в коем случае не в часах!), которые вы отгрузили за очередной спринт (план-факт) и количество дефектов. Три таких метрики (план, факт, дефекты) — уже достаточно.
    
12. Решайте проблемы команды. Медленное железо, слабые сервера, неудобные стулья или необходимость отгулов — за этим всем нужно следить.
    
13. Проводите раз в полгода стратегические сессии с участием всей команды и заинтересованных в проекте лиц. Формируйте планы. Прозрачные и понятные для команды. Должна быть ясность целей и ясность пути.
    
14. Ищите вызовы и интересные задачи. Давайте время на изучение новых технологий. Работа не должна превращаться в рутину.
    
15. На зрелых проектах — документируйте и стандартизируйте разработку. Покрывайте проекты автотестами.
    
16. Имейте в виду, что статистически рано или поздно у вас из команды будут отваливаться люди. И приходить новые. Это неизбежно, что бы вы ни делали. У вас, по сути, есть два года, чтобы раскрыть потенциал человека. Если всё сделаете грамотно — то больше. Постройте процесс онбординга (погружения новых людей в команду). Избавляйтесь от токсичных людей, которые тормозят команду.
    
17. Постройте карьерный трек по каждому члену команды. Проводите аттестации. Внедрите карты компетенций. Давайте время на учебу. Внедрите OKR.
    

18. Сами много читайте и развивайтесь. Пока есть развитие — не будет застоя. Обязательно почитайте старые книги Макаренко (например, «Педагогическая поэма»).

19. Снижайте персонало-зависимость. Стремитесь к совместному владению кодом. Не должно быть укромных уголков.

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

21. Все будет хорошо. Даже если — не будет!

Эта статья – глава из книги Управление digital-проектами.

Предыдущие главы: #001, #002, #003, #004, #005

Продолжение следует.