Стратегии заказной и продуктовой разработки
Как и когда бизнесу построить свою команду разработки и ничего не испортить
Это было ужасное утро, 26 декабря. Мороз на улице был за 30. Я всю ночь колесил по кварталам в поисках нашего программиста, который ушел с корпоративной вечеринки с двумя детскими подарками подмышкой. И не вернулся. Сашка погиб.
Месяц назад с проекта, которым он занимался большую часть времени последние лет пять, уволился его напарник. А нового парня еще не успели толком ввести в курс дела. Вот такой сложился дрим-тим: один уволился, второй — погиб, третий — джун. Отличные новости для клиента под конец года.
Звоню, рассказываю «как есть». Обещаю подумать, что можно тут сделать и как будет оптимально. Для меня «подумать» — это не вежливая форма «отстань». А абсолютно формальные техники. С выписыванием фактов, поиском связей между ними, вариантов решений и оценкой последствий. В этот раз потребовалось почти двое суток.
«Владимир! — так зовут директора заказчика, с которым у нас сложились доверительные отношения. — Владимир! Вам эта мысль понравится. Вы ее только сразу не отбрасывайте. С ней нужно переспать. Давайте строить внутреннюю команду. In-house. Помогу, чем могу». Понадобилась пара дней, чтобы пройти все стадии: от отрицания до смирения. Но в конечном счете мы с клиентом пришли к единому мнению: «Да, это круто! Это сработает лучшим образом в нашей ситуации». И перешли к конкретным шагам.
Заказная и продуктовые команды
В чем разница в организации и управлении. Формирование продуктовой команды. Когда. Где. Как. Из кого?
Разработка программного обеспечения — это сложно и дорого. Всегда было сложно и дорого. Особенно в современных системах, с кучей микросервисов, интеграций и взаимосвязей. И если есть шанс не писать код, а взять готовое решение или конструктор — берите конструктор.
Мы уже не в песочнице. В картине мира digital-проектов десятки и сотни артефактов, за которыми нужно следить, чтобы выпускать и поддерживать достойный продукт. И тем не менее, в какой-то момент конструктора станет мало. Да и конкуренция, в основном, идет на поле технологичности. И придется с этим разбираться.
Когда ваши задачи переросли коробочные решения, по большому счету есть три варианта: заказная разработка под ключ, аутсорсинг и in-house команда.
Заказная разработка
Вы пишете в агентство. Обсуждаете задачу. Агентство проводит аналитику, собирает требования. Рисует прототипы, дизайн. Пишет код. Запускает проект. Занимается технической поддержкой. Множество технических и организационных вопросов и рисков агентство берет на себя.
Такие команды лучше всего годятся за запуска продукта с нуля, поскольку имеют опыт, компетенции, их не надо собирать. Быстрее всего выпустить и развивать MVP именно в заказной разработке.
Minimum Viable Product — Минимально жизнеспособный продукт — концепция запуска в свет программных продуктов поэтапно: сначала самое важное, пусть небольшое, но имеющее ценность для потребителя; затем – обкатка рынком, сбор обратной связи и выпуск следующих версий.
Какие плюсы и минусы в этом подходе?
Плюсы:
- Фиксированная или гибкая стоимость контракта / этапа работ. В зависимости от задачи и стадии проекта вы можете использовать как фиксированную стоимость контракта, так и перейти к гибкой модели, оплачивая фактически затраченное время. Многие клиенты предпочитают работу по фиксированной стоимости, из-за ее предсказуемости. И это правда хорошо работает на запуске крупного проекта. Однако после запуска, когда новые задачи и хотелки в проект летят со всех сторон, и некогда не то, что формализовывать задачи и оценки, но и просто вникать в суть — единственный способ сохранить высокую скорость — Time&Material. Можно комбинировать эти модели.
- Не беспокоят простои команды. Балансировка нагрузки — один из самых сложных головняков в агентстве. С одной стороны, нельзя допускать простоев команды: это чертовски дорого, расслабляет и приводит к ненужным мыслям. С другой стороны, нужно иметь запас мощностей, чтобы быть готовым быстро включиться в задачи клиента. Если начальник хочет, чтобы у всех подчинённых всегда была работа отсюда и до пенсии, с максимальной интенсивностью — вселенная подкинет такому начальнику работы без выходных и бессонницу в придачу. Впрочем, теперь это головная боль агентства.
- Не надо думать о найме, обучении, мотивации. На что уходит масса энергии.
- Можно ТРЕБОВАТЬ, а не пасти котов. Котики — умные, сытые, независимые IT-шники, с хорошим запасом чувства собственной важности. С ними порой сложно. А тут — можно требовать. Это, в конце концов — почетно!
- Всякие интересные штуки с оплатами. Ну вы знаете эти игры. Печать затерялась, бухгалтер счет на столе забыл, или «у нас платежный день — каждую четную среду месяца, с 11:00 до 11:30».
Минусы:
Главный минус агентства — расфокусированность. Скорее всего, менеджер в течение дня переключается несколько раз с проекта на проект. Разработчики тоже могут быть расфокусированы. На этой неделе — одно, на следующей — другое (это, кстати, неплохо для их роста как специалистов и поддержания интереса к работе, если задачи интересные). Расфокусированность — последствие рваного потока работ, характерного для заказной разработки.
Своя команда (in-house)
Своя команда оправдана, если у вас от 1000 часов в месяц стабильной загрузки. И видно, что такая нагрузка — это не временное явление, а так будет еще долго.
Плюсы:
- Сфокусированность. Если специально не раздергиваете команду криками «Важно! Срочно! Внезапно!», а фокусируете ее внимание на действительно важных задачах, помогаете команде расти и решать проблемы — вам покажут наилучшую результативность. Сфокусированность творит чудеса.
- Скорость и гибкость — пока не обленились и не разжирели. Тут не так однозначно. По моим наблюдениям, у многих программистов, которые поработали на стороне клиента — вырастает нимб. Особенно у тех, кто почувствовал свою незаменимость («Я — властелин 1С, и фиг вы со мной что сделаете»). Чувство собственной важности зашкаливает до небес. А делать они толком ничего не делают (только инфантильно ноют, брюзжат, все запутывают, убегают от ответственности). В агентствах таких не терпят. А вот в клиентских командах — обычное явление.
Нюансы:
Оправдано при 1000 часов в месяц стабильной загрузки. Ключевое слово — стабильной!
В команде может быть дизайнер, несколько программистов, руководитель проекта, аналитик-тестировщик. 1000 часов — это небольшая спецназ-команда в 5−7 человек. Как раз норма управляемости для руководителя проекта. При хорошей сработанности может творить чудеса.
Минусы:
- Простои, найм, обучение, мотивацию, косяки приходится оплачивать. Тут есть риски и очень много работы, которую приходится делать каждый день для формирования команды и поддержания её в форме. Есть масса хороших практик для формирования таких команд, о них — ниже.
- В агентствах все же больше разных компетенций. И если вам понадобится что-то специфичное, с чем не сталкивалась ваша команда (например, настроить аналитику в мобильном приложении), вы можете потратить много времени на выращивание этой компетенции внутри.
- Руководитель — расфокусирован.
Тут вот какая штука. В любом проекте самые интенсивные действия по организации идут в начале проекта (нужно все предусмотреть, продумать, всех организовать). И ближе к концу работы, когда нужно все принять, проверить или отправить переделывать к чертовой матери. Однако посередине всегда есть довольно большое плато, где руководитель не обязан бегать в мыле. Все происходит как-то само по себе.
Но, современное программное обеспечение обновляется постоянно. По некоторым проектам мы делаем обновления чуть ли не несколько раз в день. Но по большинству работаем недельными или двухнедельными циклами. В разработке это называется «спринт». То есть каждую, допустим, неделю, у нас новая версия. И нужно обеспечить «старт», «нормальную работу» и «запуск».
Тут пока все нормально. Однако циклы накладываются. Руководитель должен отслеживать несколько потоков разработки одновременно: продумывать стратегию и приоритеты на пару спринтов вперед, обеспечивать постановки и дизайн для следующего спринта, проверять новые интерфейсы, проверять и помогать команде разработки с текущим спринтом, собирать обратную связь от пользователей по только что запущенному спринту и т.д.
В общем-то, можно распределить работу со стратегией и работу с командой по двум или трем ролям:
руководитель продукта — отвечает больше за стратегию и маркетинг;
- руководитель проекта — отвечает за поставку новых версий;
- Scrum-master — член команды разработки, отвечающий за поддержку команды, игру по правилам и решение проблем команды.
В общем, у руководителей тут очень много работы и сильная расфокусировка.
Выделенная команда (аутсорс)
Гибридный вариант, когда под конкретного заказчика резервируется команда внутри агентства. Команда выкупается полностью (реже — частично, ведь тут сразу возникает расфокусировка). Как правило, оплачивается фактически затраченное время. Стоимость задач зависит от их срочности: работа спринтами, как правило, дешевле. А «вот все прям сейчас всё бросили, и идите перекрашивать кнопку с красной на зеленую» — дороже.
Плюсы:
- Сфокусированность выше, чем в заказной разработке (но не такая, как можно обеспечить в своей команде).
- Скорость, гибкость.
- Простои, найм, обучение, мотивация, косяки — не ваша забота.
Нюансы:
Оправдано от 200-400 часов разработки в месяц. Это пара программистов, кусочек руководителя проекта и кусочек тестировщика. Время от времени — дизайнер, если это нужно для задачи.
Минусы:
- Проджект-менеджер, скорее всего, будет заниматься еще 3-4 проектами.
- Норма управляемости 7±2.
Какую модель выбрать
Итак, если у вас разовый проект, рваная, нестабильная нагрузка или нужно выпустить продукт (или MVP), но нет времени, сил, компетенций и желания возиться и пасти котиков — однозначно, заказная разработка — правильное решение.
Если у вас идет стабильное развитие разработанного решения, если у вас планы на год-два вперед, причем, нужно часов 200-400 разработки в месяц — скорее всего, в агентстве под вас будет выделенная команда. Внутри нее могут быть некоторые ротации (увы, средний срок работы сотрудника даже в Facebook — чуть более двух лет). Но это не ваша проблема.
Наконец, если у вас больше 1000 часов в месяц разных полезных дел и есть зрелость и готовность строить внутренний продакшн, то почему бы и нет?
Тактика организации in-house-команды
Общий тон настроений в коллективе должен быть мажорный.
Довольно сложно давать конкретные советы, не зная конкретного проекта, архитектуры и культуры компании. Однако, если вы решили строить in-house команду, эти идеи и принципы вам помогут:
Поставьте сильного Руководителя Проекта. Лучше с агентским опытом. Еще лучше — с сочетанием технического бэкграунда и хорошими переговорными навыками. Всё крутится вокруг этих двух компетенций. Знания в маркетинге будут плюсом.
Выбирая между двумя Руководителями Проектов — берите самого позитивного и энергичного. Никакие процессы не заменят энергию и драйв. Унылый Руководитель Проекта гарантированно сделает унылой всю команду и унылый продукт.
Поддержите его властью. Руководитель Проекта не должен быть мальчиком для битья, он должен иметь право формировать команду. Кроме того, у него должен быть доступ к ресурсу, открывающему любые двери внутри компании. Иначе проект забуксует во внутренней бюрократии. Итак, Руководитель Проекта должен иметь доступ к полю власти и поддержку со стороны высшего руководства.
Стройте команды. Не один программист, а минимум — два. Иначе есть риск остаться с неподдерживаемым кодом.
- Первую версию продукта или большую автономную разработку лучше отдать агентству. Так будет быстрее. Когда проект будет вызревать — можно начать формировать свою команду.
- Используйте классический Scrum или Канбан для организации разработки. Не изобретайте колесо. Проводите стендапы. Демонстрации. Планинги. Обсуждайте задачи. Команда должна чувствовать свою причастность к важному.
- Используйте тикет-системы. Снижайте до минимума СРОЧНО-ВАЖНЫЕ задачи.
- Проводите ретроспективы. Следите за удовлетворенностью команды. Прислушивайтесь и решайте проблемы.
- Подбадривайте. Хвалите больше и чаще. Общий тон настроений в коллективе должен быть мажорный.
- Фокусируйтесь. Минимизируйте переключения команды. Дерготня, суета, спешка приводят к ошибкам и выгораниям.
- Заведите и отслеживайте несколько простых метрик, говорящих об успехе команды. Визуализируйте эти метрики. Это могут быть оценки задач в Story Point (ни в коем случае не в часах!), которые вы отгрузили за очередной спринт (план-факт) и количество дефектов. Три таких метрики (план, факт, дефекты) — уже достаточно.
- Решайте проблемы команды. Медленное железо, слабые сервера, неудобные стулья или необходимость отгулов — за этим всем нужно следить.
- Проводите раз в полгода стратегические сессии с участием всей команды и заинтересованных в проекте лиц. Формируйте планы. Прозрачные и понятные для команды. Должна быть ясность целей и ясность пути.
- Ищите вызовы и интересные задачи. Давайте время на изучение новых технологий. Работа не должна превращаться в рутину.
- На зрелых проектах — документируйте и стандартизируйте разработку. Покрывайте проекты автотестами.
- Имейте в виду, что статистически рано или поздно у вас из команды будут отваливаться люди. И приходить новые. Это неизбежно, что бы вы ни делали. У вас, по сути, есть два года, чтобы раскрыть потенциал человека. Если всё сделаете грамотно — то больше. Постройте процесс онбординга (погружения новых людей в команду). Избавляйтесь от токсичных людей, которые тормозят команду.
- Постройте карьерный трек по каждому члену команды. Проводите аттестации. Внедрите карты компетенций. Давайте время на учебу. Внедрите OKR.
Сами много читайте и развивайтесь. Пока есть развитие — не будет застоя. Обязательно почитайте старые книги Макаренко (например, «Педагогическая поэма»).
- Снижайте персонало-зависимость. Стремитесь к совместному владению кодом. Не должно быть укромных уголков.
Делайте хороший продукт для хороших целей. Не тратьте время на разработку ерунды, от которой всех воротит.
- Все будет хорошо. Даже если — не будет!
Эта статья – глава из книги Управление digital-проектами.
Продолжение следует.
Все четко и по делу, особенно про 400 и 1000 часов. Но думаю что для руководителя (заказчика продукта) всегда будет актуальна проблема объективной оценки проектов в часах. Разработчики инхаус в своих оценках будут стремится к бесконечности, а сам продукт оунер задавать любимый вопрос «чо так долго»?
Когда объем работ по проекту приближается к этим цифрам оунер волей-не волей начинает примерно понимать трудоемкость :)
В статье рекомендуется не изобретать колесо и использовать классический скрам. И одновременно с этим предлагается ввести 3 роли - владелец продукта, руководитель проекта и скрам мастер. Как бы в чистом скраме роли руководителя проекта нет и её нет не просто так, а потому, что команда берет на себя необходимую ответственность, иначе это не скрам.