Как решить ваши проблемы бизнеса в разработке ПО

Цель любой коммерческой организации — получение прибыли. Как же её не упустить в разработке ПО, не наступая на раскиданные повсюду грабли? Рассмотрим проблемы и как их избежать в управлении продуктами и проектами.

Меня зовут Александр Мороз, в IT 20 лет, от разработчика до технического директора. Мы в Moroz Team разрабатываем качественное программное обеспечение и помогаем повышать зрелость в IT-организациях.

Рассмотрим типичный подход к разработке ПО

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

Картинка вполне типичная и пока ничего плохого не представляет. А что выходит, если сравнить ожидаемый красивый результат с реальностью?

• Продукт редко выживает после MVP. Остаётся сырым и никуда не годным. Команда не может наращивать функциональность равномерным темпом. А ведь в бизнес-плане или дорожной карте это основная канва
• Проект вываливается далеко за сроки и бюджет и не приносит ожидаемой прибыли

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

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

Он может даже вырвать из контекста цитаты классиков по управлению проектами. Я сталкивался с такой отговоркой:

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

После чего цикл повторяется. Руководитель добывает ещё денег на новый продукт или уходит на другой проект, меняет компанию.

В моём идеальном мире руководитель не такой. Он рефлексирует и задаётся вопросом ЧЯДНТ, гуглит, читает книги, общается с коллегами, аккуратно экспериментирует, постоянно повышает свою компетентность и уровень квалификации... И становится для нас неинтересным, так как у него люди не выгорают, продукты доходят до нужной бизнесу кондиции. Никакой драмы.

Если же идти по пути наименьшего сопротивления, как принято у большинства, то встретим следующие проблемы.

• Превышение бюджета на разработку → низкая экономическая эффективность → убытки.

• Задержки выпуска и/или недостаточный объем (функций) → потеря клиентов, контрактов, доработки за свой счёт → убытки.
• Низкое качество продукта → потеря клиентов, доли рынка, проигрываем конкурентам → убытки.

Возможно, так проблемы сформулирует не каждый. Но вот с симптомами, которые вытекают из этих проблем, сталкивались многие:

• Нет чёткого распределения ролей в команде, межкомандное взаимодействие не налажено
• Нет понятия о необходимом объёме ресурсов для спринта, этапа или итерации
• Собрания ради собраний, тимбилдинг и развитие HR-бренда ради галочки
• Перегруженность высококвалифицированных специалистов, отсутствие задач для остальных. Ключевые ребята не занимаются своими прямыми обязанностями, а постоянно тушат пожары
• Техдолг воспринимается как пороховая бочка, а не как обычный элемент процесса разработки
• Ручное тестирование проводится за миг до релиза, если вообще проводится
• Релиз перед выходными и праздниками (например, 31 декабря)
• Решения не фиксируются, виноватые в неудачных решениях и герои удачных определяются руководством по настроению
• Выполняется менее половины из теста Джоэла (для определения качества кода) и подобных
• Незапланированно высокая текучесть кадров из-за перегорания и отсутствия работающей кадровой политики
• Абсурдные по экономике бюрократические требования. Например, вышел не через ту дверь или задержался — автоматически вычли день работы из зарплаты. Нет практической возможности сдвигать рабочее время даже в случае крайней необходимости, команда биг-даты определяет продуктивность и эффективность
• Игнорирование проблем руководством и подача под соусом «у других ещё хуже»
• ...а также многие и многие другие.

За 20 лет в индустрии я сталкивался с этими проблемами и их симптомами в разных проектах и разных компаниях. И каждый раз встречаясь с ними, не мог понять: почему же никто не пытается с ними разобраться? Почему никто с ними не борется, и они воспринимаются как должное? Я решил перестать быть пассивным вопрошающим у моря погоды и решил найти ответы и разобраться в вопросе самостоятельно.

Как завершать успешные проекты? Как увеличить прибыль без отвлечения на борьбу с симптомами и поиски виноватых? Для этого я стал искать истинные причины проблем IT-бизнеса. Найти их мне удалось с помощью метода пяти «Почему». Он был придуман основателем Toyota Сакити Тоёдой:

Формулируется проблема. В ответ на исходную проблему задаётся вопрос «Почему это произошло (происходит)?». На полученный ответ задать снова тот же вопрос. И так за 5 подходов можно докопаться до того, что же лежит в основе.

Мой внутренний диалог выглядел примерно так:

— Тестирование выполняется в последний момент. Тестировщики не успевают качественно проверить функциональность

— (1)Почему? Потому что в спринте не было учтено время для качественного тестирования.

— (2)Почему? Потому что не знали точно, сколько времени уйдёт на разработку основных функций.

— (3)Почему? Потому что в ходе разработки всплыли подводные камни, которые срочно пришлось чинить и исправлять.

— (4)Почему? Потому что не спроектировали функции заранее или сделали это недостаточно качественно.

— (5)Почему? Потому что в текущей команде для этого не достаточно квалификации.

Таким образом мне удалось выявить первопричины большинства проблем. Сгруппировав их, получил всего 3 базовых причины.

1. Не эффективная бизнес-модель
2. Недостаточная совокупная компетентность и квалификация команды
3. Неподходящий процесс или его отсутствие

Любой бизнес стоит на этих трёх китах. И чаще всего причины проблем в одном из них, слабость в одном из них приводит к снижению прибыли.

Причина 1. Неэффективная бизнес-модель

Обычно используют проверенные на практике бизнес-модели. Если бизнес или проект использует экзотическую модель, либо запущен без бизнес-плана, без расчёта юнит-экономики, это может привести к убыткам независимо от других факторов. Например, выход на конкурентный рынок с заведомо слабым неконкурентоспособным продуктом.

Причина 2. Недостаточная совокупная компетентность и квалификация команды

Эффективная команда, где каждый участник на своём месте и достаточно хорошо выполняет свою работу, является одним из ключевых аспектов успешного бизнеса.

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

Причина 3. Неподходящий процесс или его отсутствие

Процесс может быть неподходящим. А хуже этого — отсутствие какого-либо процесса. Особенно в проектах, которые длятся дольше трех месяцев и над которыми работают больше трех человек. Отсутствуют роли, непонятно, кто и за что отвечает, кто чем занимается, что именно нужно проекту. Всё это приводит к сценарию безнадежного проекта (Э.Йордан – Смертельный марш).

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

Эта формула известна уже много веков со времен появления артелей, отмены рабства и крепостного права. Но моя любимая айтишечка в плане подобной гармонии как будто всё ещё в феодальном средневековье.

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

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

Кажется, что изменить бизнес и мир вокруг нереально? Достаточно начать с постепенного расширения своего круга влияния путём изменения частички мира вокруг себя.

То же советуют и другие великие: Стивен Кови и Стив Джобс. Первый советовал менять мир постепенно, расширяя свой круг влияния, второй — революционно. Но все великие люди вдохновляют нас так или иначе на изменение мира.

Когда вы решились на изменения, начните с поиска узких мест и подбора подходящих инструментов для их закрытия, как завещает Э.Голдратт.

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

Самая надёжная и понятная метрика в коммерческой организации — прибыль. Если у вас есть прибыль и она растёт, то, скорее всего, вы всё делаете правильно! Если беспокоит стратегия, что же будет послезавтра, то аудит по описанным в статье симптомам не помешает.

В следующих статьях раскроем эти темы подробнее. Расскажем о наших практических подходах, методиках и поговорим про теорию, как оно всё должно быть в идеале.

Кому не терпится перейти от теории к практике, заходите к нам: https://moroz.team Поможем, чем сможем.

Список литературы и источников:

• Джим Коллинз — От хорошего к великому
• Стивен Кови — 8 навык. От эффективности к величию
• Элияху Голдратт — Цель. Процесс непрерывного совершенствования
• Эдвард Йордан – Смертельный марш