Кому это может быть особенно полезно? Предположим, вы запланировали начать новый проект или разработать продукт. С чего положено начинать в таких случаях?
Правильно, с оценки предположительного бюджета, инструментов и т. п.
Но не всегда такое начало может привести к ожидаемому результату. У вас могут возникнуть такие сложности:
- оценивание используется неправильно и ни к чему не приводит;
- со временем ваши оценки становятся необъективны;
- порой вовсе не нужно знать, что и к какой должно быть построено, на что, сколько и когда денег должно быть потрачено.
У всех традиционных вещей есть альтернативы. В бизнесе так же, и реализованы они через
Agile.
Рассмотрим их подробнее.
Способ 1: вообще никаких оценок Общий принцип: вы вообще не делаете никаких оценок и прогнозов.
Когда применим: когда компания не заинтересована в том, чтобы знать, сколько денег тратится в определённый промежуток времени. Есть бюджет, которым можно свободно распоряжаться.
С одной стороны, это довольно-таки практичный метод, ведь не нужно ходить и договариваться о том, сколько денег нужно кому-то на что-то выделить и действовать интуитивно. Однако не бывает бесконечных ресурсов (денег, людей, времени и т. п.), поэтому совсем без каких-либо рамок может быть тяжело.
Способ 2: капельное финансированиеОбщий принцип: сначала работаете над наиболее важными вещами и тратите доступные средства только на них.
Когда применим: когда неизвестно, насколько большим планируется проект.
Порой, на ранней стадии работы с проектом, мы прогнозируем очень много «необходимых» вещей, которые в дальнейшем оказываются совершенно бесполезными. Поэтому есть вариант начинать с «капель»: небольших, но наиболее важных шагов по реализации главной цели проекта.
Способ 3: #NoEstimates по книге Васко ДуартеОбщий принцип: вы действуете в режиме спринта и всегда готовы завершить проект, переоценить его с увеличенным объёмом работы.
Когда применим: когда не работает обычное оценивание.
В книге
Васко Дуарте объясняет, что стоит работать с ограничениями по времени и по бюджету, но, при этом, с изменяемым объёмом задач. Вы должны как бы разбить идеальный результат на более маленькие и реализовывать их по-максимуму с текущими ограничениями. В отличие от прошлого метода, здесь задачи не делятся на приоритетные и нет.
Способ 4: расчёт примерного количества задач и трат на основе исторических данныхОбщий принцип: вы используете
CFD (кумулятивную блок-схему) для управления ожиданиями от проекта.
Когда применим: когда планирование проекта бессмысленно и отнимает слишком много времени.
Вы не знаете заранее, как много всего предстоит сделать по проекту, но зато можете делать какие-то выводы на основе исторических данных. Используя их для построения диаграммы
CFD, можно составлять полноценные отчёты о работе в текущий момент времени.
Способ 5: деление задач на подзадачиОбщий принцип: каждый план по вашему проекту вы делите на более маленькие задачи, в оценке которых просто невозможно ошибиться.
Когда применим: когда ваши оценки становятся необъективными, а отчёты по проекту можно предоставлять фрагментарно.
Благодаря тому, что вы делите каждый этап работы на максимально маленькие из возможных, вам не нужно заранее прогнозировать время деятельности: вы просто работаете в стабильном режиме.
Способ 6: краткосрочные/среднесрочные задачи/эпопеи и возможности на основе среднего времени каждого этапа работыОбщий принцип: на основе исторических данных определяется приоритетность задач и их объём работы, и с учётом этого выстраивается вся работа.
Когда применим: когда нет временных рамок.
Этот способ похож на методику
Васко Дуарте: вы работаете с гибких объёмом задач, но на этот раз обращаете внимание не на доступные ресурсы, а на их приоритетность.
Связь #NoEstimes, Agile & ScrumОдна из наиболее важных частей руководства по
Scrum состоит в следующем:
«Scrum основан на эмпирической теории управления процессами, или эмпиризме. Эмпиризм утверждает, что знание приходит из опыта и принятия решений на основе того, что известно».А это значит, что капельное финансирование, деление проекта на подзадачи и работа с промежуточными результатами согласуются с идеями Agile и Scrum. Суть в том, чтобы минимизировать усилия, потраченные на планирование проекта, и вложить их в реальную деятельность.