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

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

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

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

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

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

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

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

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

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

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

За время существования программной инженерии только треть IT-проектов были успешными (срок, бюджет, объём)

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

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

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

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

Проблемы бизнеса

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

Распространённые симптомы

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

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

Поиск причин возникновения проблем IT-бизнеса

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

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

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

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

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

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

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

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

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

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

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

Всего 3 основных причины всех бед в разработке ПО

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

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

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

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

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

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

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

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

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

Итак, решение

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

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

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

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

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

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

Если желаешь, чтобы мир изменился, — стань этим изменением

Ганди

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

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

С. Кови - 8 навык. От эффективности к величию

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

Заключение

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

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

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

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

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

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

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

Это все конечно хорошо, но в статье ни слова про архитектора (software architect). A software architect is a software engineer responsible for high-level design choices related to overall system structure and behavior.

Почему-то при строительстве дома всем понятно, что должен быть проект и архитектор. А при разработке ПО.... Когда меня просят оценить или разобраться с "понаписанным", мой первый вопрос - кто архитектор? Примерно в 6 случаях из десяти ответ типа нафиг он нужен, в двух случаях тычат в девопсов, в одном в старшего разраба, и еще в одном в CTO.

Это разработка, которую мы заслужили. Вот бы так в строительстве. ))

1
Ответить

См. причину №2 — Команда. СТО и архитектор, а также аналитик, тимлид, владелец продукта, дизайнер и другие не менее важные роли — это тема про команду.
Бизнес и проект не начинается с архитектора. Архитектор — неотъемлемая часть, но не самая первая) Я большую часть своей карьеры был как раз архитектором ПО (solution).
У меня есть огромная статья на эту тему. Чуточку терпения))
Не ожидал, что на vc сразу будет потребность в таких деталях

3
Ответить

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

1
Ответить

В целом всё верно

1
Ответить