Рассуждаю в рамках задания по курсу Методология.
Давайте представим, что мы выпускаем новый продукт. На этапе, когда мы только планируем работы над продуктом, а софт является его частью, у нас часто появляется план разработки. На этапе оценки и планирования я настаиваю на том, что этот план должен быть не детальным и не точным. Достаточно, когда мы можем давать оценку в неделях и расставить ее на таймлайн. Верно, что при этом мы идем на ряд допущений, но это не значит, что план "плохой", как часто меня убеждают разработчики. Это лишь значит, что вероятность, что план отразится в реальности именно так, как мы спланировали может быть ниже по сравнению с другим планированием (а может и нет).
Почему нас это устраивает? Если посмотреть в целом на работу над продуктом, то было еще очень много мест, где мы пошли на допущения. Когда предположили проблему (даже называем ее гипотезой), когда оценивали наличие этой проблемы у пользователя, когда думали как будем ее решать, когда оценивали рынок, и наконец когда оценивали разработку этого решения. Вся цепочка наших рассуждений – это набор гипотез, причем план разработки (да, план это всегда гипотеза, не надо самообманываться) зависит от всех предыдущих допущений. Поэтому точность оценки разработки нам ничего не дает – при малейших новых вводных по цепочке как снежный ком накатываются изменения и план разработки требует пересмотра.
Часто при выпуске нового продукта мы исходим из того, что надо быстро (но качественно) проверить гипотезу. Не важно точно, потому что в условиях неопределенности рынка (продукт-то новый) точно все равно не выйдет.
При таком подходе мне часто возражают (иногда негласно), что мы можем не уложиться в план. Звучит крамольно, но мы планируем не для того, чтобы уложиться! План нужен, чтобы столкнуться с реальностью. План – это модель, предположение. Если нет предположения, то и нельзя оценить, насколько реальность удовлетворяет предположению, то есть нашим гипотезам.
Правда бывают случаи, когда в план нам надо укладываться (можем не выдумывать кейс, пусть даже нас просто ограничивают условия контракта). В таком случае план составляется так, чтобы в него укладываться, например можем заложить в него буферы или применить прототипирование/проектирование на этапе оценки и планирования. Важно понимать, что он все равно остается моделью, но только эта модель очень чувствительна к сроку, учитывает его и вероятно в таком рассмотрении будет более применимой.
Но в продуктах мы думаем по-другому. Мы не можем допустить, чтобы план составлялся так, чтобы в него уложиться. Любой буфер или дополнительное проектирование – это задержка – а значит неэффективность с точки зрения выхода на рынок. Нам надо делать быстро, поэтому мы не тратим время на детальное планирование, а план воспринимаем как модель, на соответствие которой мы проверяем реальность.
Я сейчас рассмотрел продукт и планирование только с одной стороны -- с точки зрения скорости разработки и выхода на рынок. Конечно же рынки разные и требований может быть больше и они могут быть другие. Я лишь хотел показать, что план -- это инструмент для проверки соответствия реальности и нам не нужно его нарекать "хорошим" или "плохим" только с точки зрения его "точности".
Итак, требовать того, чтобы уложиться в план при разработке нового продукта – не обязательно. Нужно уметь быстро планировать реализацию, чтобы быстро проверять гипотезу. Там где быстро – может быть не точно, и с этим можно бороться не только проектированием.