Как избегать фатальных ошибок в разработке

При принятии решений нужно стараться избегать фатальных ошибок. Как говорят трейдеры: «Можно заработать много раз по 100%, но потерять 100% можно только один раз».

1. Как выглядит фатальная ошибка в разработке программного продукта — команда берется за очень классный, но очень большой продукт или новый функционал в текущем продукте. Через год закопанных усилий и денег выясняется:
   Так и не смогли реализовать задуманное, а бюджет или терпение заказчика кончилось.
   Сделали, но оказалось никому не нужно, либо нужно, но требуется еще год, чтобы переделать.
2. Как этого избежать? Нужно идти маленькими шагами, проверяя результат каждого шага и корректируя планы, если требуется. Избавит ли это от ошибки? Нет. Но в случае неправильно выбранного направления мы потеряем месяц, а не год. Месяц это не так дорого.

Если через месяц мы сделали прототип, показали клиентам, а они сказали: «это не то, что нам требуется». Мы можем просто прервать работу и заняться чем-нибудь более полезным, сэкономив тем самым 11 месяцев усилий 🙂

Всевозможные Agile, SCRUM и прочие итеративные подходы это как раз про это, а не про то что всем нравится постоянно собираться и устраивать демонстрации продуктов.

Когда можно делегировать решение вниз?

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

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

Альтернатива описанному выше — мы управляем при помощи постановки долгосрочных планов, которые потом стараемся выполнить. Это быстро превращается в управленческий ад. Почему так происходит?

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

В качестве бонуса: так как на принятие решения о планах на будущее уходит много времени, то компания становится неповоротливой. В случае какой-нибудь плохо прогнозируемой ситуации (COVID или СВО), у конторы нет механизма быстрого реагирования.

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

Как Agile позволяет внедрять инновации

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

На текущем уровне развития ИТ один человек не может разбираться сразу во всем, огромное количество фреймворков, библиотек и различных технологий, которые появляются каждый день. А кроме этого, еще и анализ клиентов, уже накопленное legacy в продуктах и т.п. Если руководитель пытается в одиночку все это двигать в светлое будущее, то компания неминуемо начинает деградировать, так как ресурс руководителя, пусть даже гениального, ограничен. Следовательно, нужно привлекать других сотрудников к решению вопросов. Используем старую народную мудрость: «Один ум хорошо, а два лучше.»

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

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

Все новости сайта в телеграм канале: @CTO_in_Action