Черный лебедь в 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. “Чёрный лебедь” (теория)
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 17

    +1
    На старте у продакт-менеджера появляется мысль, которую он описывает на 2-10 листах


    То есть исследование рынка продакт пропускает и полностью забивает на почтенные маркетинговые инструменты, которым скоро уже больше 100 лет?

    И даже про Ford Edsel почитать ему не судьба, ему же прыгать, а не думать надо?

    Так проблема не в том, что Agile, MVP и Lean в его методологии нет, а в том, что он дурак.

    Он и с MVP нужных выводов не сделает.
      +1

      MVP вроде бы и предназначен для пропуска исследований рынка до старта разработки. Запустили MVP и исследуем прямо на нём

        +1
        Так да. Один из методов.

        Но ведь у описанного продакта даже вопрос так не стоит.

        Он и с MVP вопрос так не поставит. Не будет у него пункта «гипотеза неудачна, нужна переоценка».
          0

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


          То есть слова "минимально-возможный для быстрого старта" владелец понимает как-то так. Когда предлагаешь сделать версию хлтя бы без бассейна — отметает категорически. Говорит: "да, в этот раз пусть будет по-твоему, но в MVP будет входить это, это и это. И еще вон то".


          И я думаю, таких большинство.

        +2

        Давно ищу материалы и статистику по влиянию типизации на скорость разработки, не могли бы вы поделиться своими результатами?

          +3
          Со стороны программиста поясню что типизация помогает не совершать ошибок, тк редактор кода подскажет ошибку до его запуска, а значит не вылезет бак, и не придётся тратить время на дебаг. В итоге, процент будет зависеть от количества кода и скилов разработчиков.
            –3

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

              0

              Так вот как раз интересно, как время, затраченное на написание и поддержку типов, соотносится с количеством и "качеством" багов, за какой срок инвестиции в типы окупаются и окупаются ли

                0

                Вы не найдете ответа здесь.
                Точнее найдете, но он всегда будет "да, конечно, обязательно, без этого никак".

                  0

                  Или наоборот

                    0

                    Наоборот — слишком велик риск получить.

              0

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


              Я использовал слово "несколько", но считаю, что точнее оценить не выйдет: нет возможности клонировать людей и заставить их вести два проекта рядом с разным подходом.

                0
                какие у вас доказательства?
              +5
              Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.

              О боже, сколько можно пропагандировать это мировоззрение «хороший код vs требования бизнеса»

              Классическая ситуация, в которую приходит компания, когда им «нет дела, до идеального кода, надо просто чтобы работало», это:

              • Закостыленный легаси проект
              • Старая команда, которая это писала — ушла, потому что одно дело — писать костыли, и другое дело — поддерживать и развивать проект написанный на костылях
              • Новых хороших разработчиков нанять невозможно — они сходу понимают суть работы, и отказываются
              • Разработка замедляется до уровня «одна фича в пол года»


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

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

              Аутсорс как раз хорошая школа для всех, кто считает, что «хард скиллы не важны, важны софт скиллы» — вот там с вами будут вежливо общаться, будут делать только то, что вы захотите (если клиент не просит писать автотесты — их и не пишут), и будут максимально клиенто-ориентированными.

              Вот только результатом (на большом отрезке времени) почему-то всегда недовольны…

              Найти причины большого числа ошибок в каждой новой версии продукта

              Много ошибок может быть только там, где не пишут тесты (или пишут для галочки). А тесты не пишут, когда «быстрей-быстрей, срочно-срочно!» — добро пожаловать в замкнутый круг. Впрочем, ничего удивительного — «Скупой платит трижды»

              Внедрение CI/CD даст ускорение на 10-20%

              Крупный проект был без настроенного CI/CD? Забавно. А куда смотрел тим-лид? Или компания захотела сэкономить, и взяла тим-лида по цене милда? Ну, в общем, как обычно.

              P.S.
              На мой взгляд инструкцию можно сократить до двух пунктов:

              • СЕО должен разбираться в разработке. Например, вырасти из программиста. Нет ничего печальнее, чем руководитель разработки, который ничего не понимает в разработке, и может полагаться только на то, что сказал тот или иной «синьер»
              • СЕО должен уметь общаться с владельцами бизнеса. С одной стороны, говоря им правду — что современная разработка, это сложно и дорого, и надо сразу «спуститься с небес и не ожидать чуда», но делать это так, чтобы желание финансировать проект не пропало. Как только СЕО стал соглашаться на неадекватные требования владельцев бизнеса (а они по умолчанию неадекватны — они далеки от разработки также, как луна от земли) — можно закрывать проект.
                0
                Перед разработчиками встала задача значительно переделать их идеальное решение. 4 из 5 программистов, имеющих отличные технические навыки и большой опыт в enterprise к этому не готовы морально: крайне неохотно вносят изменения, которые выбиваются из придуманной архитектуры.


                Наследование и переделка это противоречащие друг другу вещи. Если используется ООП то проще написать новый проект чем переделывать старый.
                  +1
                  Пролистал. На самом деле точек факапа множество, но ключевых можно выделить семь:
                  1. Идея изначально была плохой, и рынок ее не принял
                  2. Идея была хороша, но в процессе написания ТЗ ее потеряли
                  3. Техническая архитектура не соотвествовала в достаточной мере требованиям
                  4. Все было отлично, да запороли управление и планирование задачами
                  5. Наняли не тех разработчиков — те не справились
                  6. Систему не проверили на соответствие требованиям — техническим и функциональным
                  7. В процессе эксплуатации не обеспечили нужную надежность, отказоустойчивость и безопасность

                  Как говорится, выбирайте, кому что больше нравится











                    0
                    Все комментарии выше объединяет одно: проблему рассматривают в рамках нового продукта.
                    А ведь продукт может быть уже действующий и MVP — это новый функционал/версия/рынок, который пытаются реализовать старой командой.
                    Тут как раз и расцветают описанные в статье проблемы, и становится понятно зачем аудит. Ведь выстроившие процесс руководители, под грузом операционки, не могут найти время и ресурс для рефлексии и объективной перестройки процессов, особенно если необходимо признать потерб контроля.

                    Only users with full accounts can post comments. Log in, please.