обычно используют agile-методы так часто, как только могут, учитывая более широкий каскадный контекст.
Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.
Далее вашему вниманию предлагается список моей топ-десятки самых больших проблем, которыми чреват такой подход. Имейте в виду: все это очень серьезные проблемы; даже одна из них может свести к нулю усилия всей команды. Тем не менее для многих современных компаний характерны несколько, а то и они все.
1. Начнем с первой проблемы в списке – источник идей. Использование этой модели приводит к созданию заказных продуктов, обусловленных потребностями отдела продаж, и продуктов по требованию заинтересованных сторон. Мы еще обсудим эту важную тему, а пока позвольте заметить, что это нельзя считать источником удачных замыслов продукта. Еще одно очевидное негативное следствие такого подхода – отсутствие самостоятельности и широких полномочий у команд. Работая по этой модели, люди просто реализуют чужие идеи; они трудятся как наемный персонал.
2. Далее следует упомянуть о фатальной ошибке во время оценки идей. На самом деле я ничего не имею против этого подхода, по крайней мере для идей, требующих больших инвестиций. Но то, как большинство компаний используют его на этом этапе для разработки дорожной карты приоритетов идей, просто нелепо. Объясню почему. Помните два ключевых вопроса, на которые должна дать ответ наша оценка? Сколько денег вы заработаете на этой идее и во что вам обойдется ее реализация? Так вот, в действительности на этом этапе мы понятия не имеем ни о том ни о другом. В сущности, мы просто не можем это знать.
Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).
Как бы там ни было, при разработке продуктов всегда нужно знать, чего мы не можем знать, а на этом этапе мы просто не можем знать, сколько заработаем на той или иной новой идее.
Точно так же мы понятия не имеем, во что нам обойдется создание нового продукта. Без фактического решения проблемы инженерам чрезвычайно сложно предсказывать какие-либо результаты. Большинство опытных разработчиков на этом этапе откажутся давать даже приблизительную оценку, но некоторых из них заставляют или убеждают пойти на компромисс и дать прогноз по типу размеров футболок: просто сообщите нам, каковы шансы этой идеи – «маленькие, средние, большие или очень
