При чём тут лебедь?
Если Вас, как CEO или CTO IT-проекта (быстрорастущего или уже крупного), не покидают ощущения, что:
- Roadmap продукта буксует
- Разработка не успевает за новыми требованиями бизнеса
- Клиенты готовы платить деньги за продукт, который Вы не можете им предоставить
- Чек за доработку системы догоняет чек от потребителей
- Всё сложнее нанимать толковых разработчиков, а свои уходят к конкурентам
- Сейчас все хорошо, но как-то тревожно…
Тогда усаживайтесь поудобнее, эта статья для Вас.
Согласно википедии, “Черный лебедь” — это теория, описывающая события, подходящие под следующие критерии:
- Событие является неожиданным
- Событие имеет значительные последствия
- После наступления, в ретроспективе, событие имеет логичное объяснение, как если бы оно было ожидаемым
Примеры: антикризисное управление, биржевые обвалы, недооцененные технологии, из свежего — планетарный карантин.
“Черный лебедь” в IT
Чем питается
Как-то на DUMP (IT-конференция) от нашей компании была презентация “10 вредных советов по повышению производительности разработки” — в ней были рассмотрены способы приманить “Чёрного лебедя”:
- Привязка премий к выполнению плана
- Привязка премий к производительности команды
- Детальное планирование квартала
- Отсутствие планирования технических задач
- Постановка задач в план больше чем есть ресурсов
- Частые изменения процесса разработки ПО
- Внедрение изменений сразу во всех командах
- Постоянное отжимание вниз оценок сроков разработки со стороны бизнеса и заказчиков
- Перемещение людей между командами
- Горизонтальное разделение труда (специализация против кросс-функциональности)
Знакомо?
Появление
В сфере IT-проектов путь “Черного лебедя” можно описать так:
- На старте у продакт-менеджера появляется мысль, которую он описывает на 2-10 листах
- Происходит формирование технической команды на новый проект
- После того, как команда сформирована, CTO, тимлиды назначены, оценки по срокам и временным затратам исходной идеи сделаны, начинается производство
- Через полгода (а может год) разработчики рапортуют — продукт “готов”
- Продакт выводит его на рынок, получает обратную связь от целевой аудитории и понимает, что половину необходимо переделать
- Продакт пишет новые 2-10 листов с требуемыми изменениями в системе
- Цикл повторяется
Но на следующем витке есть два ключевых изменения:
- Прошло время, в которое был запланирован запуск продукта
- Написан код продукта
- Разработке необходимо значительно модифицировать систему (под давлением со стороны Продакта из-за сжатых сроков). На целостность архитектуры решения в таких условиях, как правило, команда уже не обращает внимание, в системе появляются “костыли”, растет технический долг
Таких циклов перезапуска может быть от пяти и больше - “Внезапно” прилетает “Черный лебедь”: CEO с Продактом понимают, что выпуск новой версии занимает все больше и больше времени и требует увеличения бюджета на команду программистов, а чек от клиентов не растёт. Проблемы разработки нарастают как снежный ком.
- Начинаются многочисленные совещания для выяснения причин, где в качестве объяснений технические специалисты говорят много непонятного для CEO и Продакта
- Стартап для CEO переходит в статус “нести тяжело, а бросить жалко”.
В таком состоянии проект существует еще некоторое время, в зависимости от оптимизма учредителей. После чего принимается решение заморозить развитие, а может закрыть проект целиком
Это путь многих стартапов, вышедших “из гаража” и команд из трёх человек. С ростом спроса должно расти и производство, но:
- Тремя сотрудниками уже не справиться, да и требования к квалификации становятся невыполнимы, а 100 человек в гараж уже не влезают
- Уследить за эффективностью 100 человек куда сложнее, там потеря даже 10 минут в день на человека даёт более 4000 потерянных рабочих часов в году (а это два штатных сотрудника на полный день)
- Высокая связность архитектуры размывает зоны ответственности и превращает любую задачу в легаси-дайвинг.
Что делать, чтобы не прилетел
Давайте разберем на этом примере, что и когда пошло не так, и что нужно изменить, чтобы результат соответствовал ожиданиям.
- После появления первого описания продукта на 2-10 листах Продакт должен выделить минимальный ключевой функционал, необходимый для запуска (MVP версия) и сконцентрироваться на его реализации в кратчайшие сроки. Максимально быстро вывести продукт на рынок и собрать первую обратную связь от целевой аудитории.
В детстве нас учили: “семь раз отмерь — один отрежь”. В IT-стартапах все с точностью до наоборот: не стоит долго делать систему, чтобы в итоге сделать ее плохо. Надо сделать плохо как можно быстрее, чтобы осталось время на переделку - Продакт должен определить срок для MVP ближе к началу разработки, чем к сроку выхода релизной версии.
Например, если вы хотите вывести жизнеспособный продукт на рынок через 6 месяцев, то MVP должен появиться на рынке через 2-3 месяца, не позже. После выхода MVP-версии у Продакта будет возможность увидеть продукт в рынке, провести CustDev, сделать выводы и написать задание на доработку. - Техническая команда в это время устранит накопившийся из-за спешки технический долг
- Правильно подобрать команду. Hard skills, опыт и применение самых современных практик программирования безусловно важны. Но самое главное, чтобы у CTO и тимлидов было понимание и ответственность за результат. Причем не только с технической стороны, но и со стороны бизнеса.
В примере выше техническое решение было идеальным, на его выпуск понадобилось много трудозатрат. Но продукт не смог закрепиться на рынке. Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.
Подбор команды — большая тема для отдельной статьи. Простое решение — воспользоваться услугами компаний, которые специализируется на запуске IT-проектов и смогут подобрать вам команду из необычных программистов, которые каждую новую версию делают профессионально, но при этом готовы к большим переделкам, так как запустили уже более десятка проектов.
Что делать, если прилетел
Давайте разберемся, что делать, если “Черный лебедь” уже прилетел и вы ломаете голову не над поиском нового сегмента рынка, а над тем, как устранить проблемы разработки.
Напомню, с чем эта ситуация связана:
- В системе накопился технический долг
- Система написана на редком или устаревшем (legacy) стеке (например, сейчас тяжело будет найти знатоков delphi или любителей писать на JQuery)
- Плохая архитектура
- Отсутствие или нерациональное использование современных методологий разработки
Варианты борьбы с “вредителем”:
- Дорогой.
Нанять очень опытных программистов (уровня senior developer). В случаях, когда система полностью поросла костылями, техническим долгом, да еще на непопулярном или устаревшем стеке — придется заплатить им выше рынка.
В таком режиме можно существовать примерно полгода. Потом высокая оплата труда перестанет мотивировать ключевых разработчиков и они уйдут на новые проекты с понижением дохода, но без головной боли - Очень дорогой.
Если продукт смог закрепиться на рынке и есть потребность в его дальнейшем развитии, но в разработке все плохо, то необходимо собраться с духом и принять решение: переписать всю систему с нуля.
Идея проста. По аналогии с первым циклом разработки из примера, мы получим отлично спроектированную систему. С той лишь разницей, что эта система гарантированно будет решать бизнес задачу. Трудозатрат и времени на “перезапуск” системы уйдет примерно в два раза меньше чем ушло на разработку имеющейся версии. - Аудит. Нередко бывает полезно привлечь внешнего технического эксперта, чтобы:
- Понять, на что разработчики тратят основное время
- Найти причины большого числа ошибок в каждой новой версии продукта
- Оценить уровень legacy и технического долга в проекте
- Предложить конкретные варианты для выхода из ситуации
- Чтобы анализ был произведен качественно и беспристрастно лучше сделать его с помощью внешней компании, которая предоставляет такие услуги
Как CTO компании, которая занимается заказной разработкой, подбирает команды программистов и проводит CustDev на базе MVP-версий (или даже без) — я расскажу о третьем варианте.
Аудит разработки
Рассмотрим пример аудита федеральной компании.
Дано:
- Маркетплейс на 10k монетизированных пользователей (при 1 млн регистраций)
- Посещаемость 12 млн. в сутки
- 6 команд
- 2 команды делают план на 50%
- 4 команды не делают...
Задачи в формулировке заказчика
- Ускорить разработку в два раза
- Обеспечить своевременное выполнение планов командами
- Увеличить время, затрачиваемое разработчиками на разработку новых фич до 50%, в идеале до 80%
- Внедрить метрику, показывающую отказоустойчивость системы и вывести этот показатель на уровень 99,9
- Снизить количество багов доходящих до заказчика до 5/мес (были откаты релиза из прода)
- Повысить удовлетворённость клиентов на 5 из 5 (была на 2)
Что заказчик пробовал самостоятельно
Все “вредные советы” без положительного результата.
Результаты аудита разработки
По результатам проведения аудита были предложены меры по решению поставленных задач, а также оценены сроки и трудозатраты на реанимацию. Выглядит это в кратком варианте так:
Первоочередные мероприятия
- Найм выделенных людей на исправление ошибок.
Остальные занимаются только планом. Периодически происходит ротация. Сейчас есть потери на постоянное переключение контекста. Если будут выделенные люди, разработка ускорится на 40-50% - Есть потери в отсутствии статической типизации.
Тем, кто не очень хорошо знаком с кодом, приходится много работать с отладчиком и смотреть что откуда берется. Внедрение статической типизации ускорит погружение людей в проект, увеличит их производительность и уменьшит кол-во случайных ошибок. Сейчас новые люди правят баг и ломают в 3-х других местах. Это даст 20-30% в первые 6 мес. т.к. п.1 подразумевает найм новых людей - Потери в ручном процессе подготовки тестовых стендов с правильными данными для тестирования фич.
Сейчас хаос: на этой базе баг воспроизводится, у других не воспроизводиться и т.д. В итоге баг править 1 час, а подготовить базу данных, где он воспроизводиться — 2 часа. Внедрение CI/CD даст ускорение на 10-20%
Оценка:
Внедрение и отладка CI — 5-10 дней (40-80 часов)
Внедрение CD — 10-20 дней (80-160 часов)
Что можно отложить
- Автотесты на UI.
В долгосрочной перспективе могут уменьшить кол-во ошибок, но сейчас это тормоз разработки. Продукт продолжает активно развиваться и поддержание тестов в актуальном состоянии снижает скорость изменений в системе в 2-3 раза
Итоги
Чего же заказчику удалось достичь следуя рекомендациям аудита? Посмотрим в терминах поставленных заказчиком задач:
- Ускорить разработку в два раза
Не только ускорили, но и получили бонусом сокращение издержек, за счет снижения требований к квалификации разработчиков. - Обеспечить своевременное выполнение планов командами
Обеспечили, не идеально, но “снежный ком” исчез, аврал остановлен. - Увеличить время, затрачиваемое разработчиками на разработку новых фич до 50%, в идеале до 80%
Получилось около 70%. Есть над чем работать. - Внедрить метрику, показывающую отказоустойчивость системы и вывести этот показатель на уровень 99,9
Внедрили, оказалось, что показатель и так на 99,8, но “какой ценой?” (с).
До 99,9 показатель подрос самостоятельно после внедрения рекомендаций. - Снизить количество багов (доходящих до заказчика) до 5/мес (были откаты релиза из прода)
Снизили до 4, но расслабляться не стоит, статистика — дело случая (и фантазии продакта по части новых срочных фич). - Повысить удовлетворённость клиентов на 5 из 5 (была на 2).
Стала на 4, думаю, что роль сыграло послевкусие, которое так быстро не перебить. Время покажет.
А как у вас? (тест)
И, вместо заключения: чек-лист для того, чтобы понять насколько далеко от вашего продукта “Черный лебедь”.
При каждом “да” — прибавляйте километры
- Среднее время найма нового программиста не превышает 1 месяц?
+100 км - Среднее время работы программистов в вашей компании дольше времени создания первой жизнеспособной версии продукта?
+200 км - От найма нового программиста до успешного выполнения им первой задачи проходит меньше 1 недели?
+300 км - Вы не пользуетесь и не планируете привлекать подрядчиков для развития существующего продукта?
+400 км - У вас, как у CEO, нет необходимости собирать отдельные совещания для обсуждения проблем в техническом подразделении?
+500 км - Всегда ли CTO вам называет сроки и трудозатраты на реализацию новых фич и при этом не промахивается более, чем на 30%?
+600 км - работа по тех. поддержке продукта не препятствует выпуску новых версий?
+700 км - На совещаниях по обсуждению направлений развития продукта с точки зрения бизнеса, вы не приглашаете CTO или, если приглашаете, то он сидит и молчит потому что вопросов к нему нет?
+800 км - Если компанию покинет 10% ключевых технических специалистов, то продолжится ли выпуск новых версий?
+900 км
Больше 3000 км: разработка под контролем, либо совсем недавно стартовала и размер команды небольшой.
Меньше 3000 км: “Добрый вечер, дамы и господа! Говорит командир корабля. От имени всего экипажа и авиакомпании “Черный лебедь”, приветствую вас на борту. Наш рейс выполняется по Roadmap компании %companyname%. Время в пути составит приблизительно 15 недель. Желаю приятного полёта!“
Ссылки:
1. 10 вредных советов по повышению производительности разработки
2. “Чёрный лебедь” (теория)
