Черный лебедь в IT-проектах. Взгляд со стороны CEO на проблемы разработки

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


При чём тут лебедь?


Если Вас, как CEO или CTO IT-проекта (быстрорастущего или уже крупного), не покидают ощущения, что:

  • Roadmap продукта буксует
  • Разработка не успевает за новыми требованиями бизнеса
  • Клиенты готовы платить деньги за продукт, который Вы не можете им предоставить
  • Чек за доработку системы догоняет чек от потребителей
  • Всё сложнее нанимать толковых разработчиков, а свои уходят к конкурентам
  • Сейчас все хорошо, но как-то тревожно…

Тогда усаживайтесь поудобнее, эта статья для Вас.

Согласно википедии, “Черный лебедь” — это теория, описывающая события, подходящие под следующие критерии:

  • Событие является неожиданным
  • Событие имеет значительные последствия
  • После наступления, в ретроспективе, событие имеет логичное объяснение, как если бы оно было ожидаемым

Примеры: антикризисное управление, биржевые обвалы, недооцененные технологии, из свежего — планетарный карантин.

“Черный лебедь” в IT


Чем питается


Как-то на DUMP (IT-конференция) от нашей компании была презентация “10 вредных советов по повышению производительности разработки” — в ней были рассмотрены способы приманить “Чёрного лебедя”:

  1. Привязка премий к выполнению плана
  2. Привязка премий к производительности команды
  3. Детальное планирование квартала
  4. Отсутствие планирования технических задач
  5. Постановка задач в план больше чем есть ресурсов
  6. Частые изменения процесса разработки ПО
  7. Внедрение изменений сразу во всех командах
  8. Постоянное отжимание вниз оценок сроков разработки со стороны бизнеса и заказчиков
  9. Перемещение людей между командами
  10. Горизонтальное разделение труда (специализация против кросс-функциональности)

Знакомо?

Появление


В сфере IT-проектов путь “Черного лебедя” можно описать так:

  1. На старте у продакт-менеджера появляется мысль, которую он описывает на 2-10 листах
  2. Происходит формирование технической команды на новый проект
  3. После того, как команда сформирована, CTO, тимлиды назначены, оценки по срокам и временным затратам исходной идеи сделаны, начинается производство
  4. Через полгода (а может год) разработчики рапортуют — продукт “готов”
  5. Продакт выводит его на рынок, получает обратную связь от целевой аудитории и понимает, что половину необходимо переделать
  6. Продакт пишет новые 2-10 листов с требуемыми изменениями в системе
  7. Цикл повторяется
    Но на следующем витке есть два ключевых изменения:

    • Прошло время, в которое был запланирован запуск продукта
    • Написан код продукта
  8. Разработке необходимо значительно модифицировать систему (под давлением со стороны Продакта из-за сжатых сроков). На целостность архитектуры решения в таких условиях, как правило, команда уже не обращает внимание, в системе появляются “костыли”, растет технический долг
    Таких циклов перезапуска может быть от пяти и больше
  9. “Внезапно” прилетает “Черный лебедь”: CEO с Продактом понимают, что выпуск новой версии занимает все больше и больше времени и требует увеличения бюджета на команду программистов, а чек от клиентов не растёт. Проблемы разработки нарастают как снежный ком.
  10. Начинаются многочисленные совещания для выяснения причин, где в качестве объяснений технические специалисты говорят много непонятного для CEO и Продакта
  11. Стартап для CEO переходит в статус “нести тяжело, а бросить жалко”.
    В таком состоянии проект существует еще некоторое время, в зависимости от оптимизма учредителей. После чего принимается решение заморозить развитие, а может закрыть проект целиком

Это путь многих стартапов, вышедших “из гаража” и команд из трёх человек. С ростом спроса должно расти и производство, но:

  • Тремя сотрудниками уже не справиться, да и требования к квалификации становятся невыполнимы, а 100 человек в гараж уже не влезают
  • Уследить за эффективностью 100 человек куда сложнее, там потеря даже 10 минут в день на человека даёт более 4000 потерянных рабочих часов в году (а это два штатных сотрудника на полный день)
  • Высокая связность архитектуры размывает зоны ответственности и превращает любую задачу в легаси-дайвинг.

Что делать, чтобы не прилетел


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

  1. После появления первого описания продукта на 2-10 листах Продакт должен выделить минимальный ключевой функционал, необходимый для запуска (MVP версия) и сконцентрироваться на его реализации в кратчайшие сроки. Максимально быстро вывести продукт на рынок и собрать первую обратную связь от целевой аудитории.
    В детстве нас учили: “семь раз отмерь — один отрежь”. В IT-стартапах все с точностью до наоборот: не стоит долго делать систему, чтобы в итоге сделать ее плохо. Надо сделать плохо как можно быстрее, чтобы осталось время на переделку
  2. Продакт должен определить срок для MVP ближе к началу разработки, чем к сроку выхода релизной версии.
    Например, если вы хотите вывести жизнеспособный продукт на рынок через 6 месяцев, то MVP должен появиться на рынке через 2-3 месяца, не позже. После выхода MVP-версии у Продакта будет возможность увидеть продукт в рынке, провести CustDev, сделать выводы и написать задание на доработку.
  3. Техническая команда в это время устранит накопившийся из-за спешки технический долг
  4. Правильно подобрать команду. Hard skills, опыт и применение самых современных практик программирования безусловно важны. Но самое главное, чтобы у CTO и тимлидов было понимание и ответственность за результат. Причем не только с технической стороны, но и со стороны бизнеса.
    В примере выше техническое решение было идеальным, на его выпуск понадобилось много трудозатрат. Но продукт не смог закрепиться на рынке. Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.

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

Что делать, если прилетел


Давайте разберемся, что делать, если “Черный лебедь” уже прилетел и вы ломаете голову не над поиском нового сегмента рынка, а над тем, как устранить проблемы разработки.
Напомню, с чем эта ситуация связана:

  • В системе накопился технический долг
  • Система написана на редком или устаревшем (legacy) стеке (например, сейчас тяжело будет найти знатоков delphi или любителей писать на JQuery)
  • Плохая архитектура
  • Отсутствие или нерациональное использование современных методологий разработки

Варианты борьбы с “вредителем”:


  1. Дорогой.
    Нанять очень опытных программистов (уровня senior developer). В случаях, когда система полностью поросла костылями, техническим долгом, да еще на непопулярном или устаревшем стеке — придется заплатить им выше рынка.
    В таком режиме можно существовать примерно полгода. Потом высокая оплата труда перестанет мотивировать ключевых разработчиков и они уйдут на новые проекты с понижением дохода, но без головной боли
  2. Очень дорогой.
    Если продукт смог закрепиться на рынке и есть потребность в его дальнейшем развитии, но в разработке все плохо, то необходимо собраться с духом и принять решение: переписать всю систему с нуля.
    Идея проста. По аналогии с первым циклом разработки из примера, мы получим отлично спроектированную систему. С той лишь разницей, что эта система гарантированно будет решать бизнес задачу. Трудозатрат и времени на “перезапуск” системы уйдет примерно в два раза меньше чем ушло на разработку имеющейся версии.
  3. Аудит. Нередко бывает полезно привлечь внешнего технического эксперта, чтобы:

    • Понять, на что разработчики тратят основное время
    • Найти причины большого числа ошибок в каждой новой версии продукта
    • Оценить уровень 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. “Чёрный лебедь” (теория)
Источник: https://habr.com/ru/post/505692/


Интересные статьи

Интересные статьи

В прошлой статье мы сделали черновые прошивки для контроллера FX3 и ПЛИС, чтобы начать работу с шиной USB 3.0. Статья так разрослась, что проверку работоспособности системы мы отложили на...
Всем привет! Не так давно на работе в рамках тестирования нового бизнес-процесса мне понадобилась возможность авторизации под разными пользователями. Переход в соответствующий р...
Вы можете стать более ценным специалистом, изучив лучшие инструменты для разработки веб-приложений на React. Большинство резюме работодатель отклоняет, просто пробежав их по ди...
Одним из очевидных недостатков систем онлайн образования является невозможность проконтролировать самостоятельность решения задач студентами. Это приводит к массовому списыванию и, как следствие,...
Привычка — страшная сила. Она заставляет сопротивляться изменениям, мешает развитию. Но в IT мы любим быть на переднем крае технологий, любим вызовы, любим внедрять то, что распространится по дру...