Вдохновленные

Большинство компаний самых разных размеров, когда я встречаюсь с ними в первый раз, работают именно таким образом на протяжении многих лет. При этом они постоянно жалуются на отсутствие инноваций и на то, что на превращение идеи в реальный продукт в руках потребителя уходит слишком много времени. Вы вряд ли станете спорить с тем, что, несмотря на упомянутую методологию Agile и практически всеобщее утверждение о гибком подходе к разработке программного обеспечения, только что описанный процесс очень уж напоминает каскадную модель, или, как ее еще называют, «водопад». Впрочем, справедливости ради надо сказать, что инженеры-программисты обычно используют agile-методы так часто, как только могут, учитывая более широкий каскадный контекст.

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

1. Начнем с первой проблемы в списке – источник идей. Использование этой модели приводит к созданию заказных продуктов, обусловленных потребностями отдела продаж, и продуктов по требованию заинтересованных сторон. Мы еще обсудим эту важную тему, а пока позвольте заметить, что это нельзя считать источником удачных замыслов продукта. Еще одно очевидное негативное следствие такого подхода – отсутствие самостоятельности и широких полномочий у команд. Работая по этой модели, люди просто реализуют чужие идеи; они трудятся как наемный персонал.

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

Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).

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

Точно так же мы понятия не имеем, во что нам обойдется создание нового продукта. Без фактического решения проблемы инженерам чрезвычайно сложно предсказывать какие-либо результаты. Большинство опытных разработчиков на этом этапе откажутся давать даже приблизительную оценку, но некоторых из них заставляют или убеждают пойти на компромисс и дать прогноз по типу размеров футболок: просто сообщите нам, каковы шансы этой идеи – «маленькие, средние, большие или очень большие». Очень уж хочется иметь дорожные карты с приоритетами, а для этого нужна какая-нибудь система для оценки идей и замыслов. Поэтому люди играют в бессмысленную игру с оценками.

3. К еще большим проблемам приводит то, что происходит после, когда компании возлагают на составленные таким образом дорожные карты слишком уж большие надежды. За годы работы я видел множество таких «карт», и подавляющее большинство из них были, по сути, не чем иным, как списками функций и проектов с учетом их приоритетности. Маркетингу нужна эта функция для проведения успешной маркетинговой кампании. Подразделение продаж настаивает на той функции, которая позволила бы ему привлечь нового перспективного клиента. Кто-то мечтает об интеграции продукта с PayPal. Ну, в общем, вы меня поняли…

Но тут возникает проблема, возможно, самая серьезная, на которую все закрывают глаза. Я называю это двумя неприятными правдами о продукте.