Все перечисленные срезы не являются запусками продуктов для заказчиков и пользователей – это всего лишь своего рода вехи, на которых члены команды должны приостановиться и оценить, как далеко они зашли. Но пусть это вас не смущает: с точки зрения заказчика или пользователя, работа еще не закончена.
Команды Майка и Аарона оценили, что работа над функциональностью потребует примерно двух месяцев. Как и Эрик, они использовали двухнедельные спринты, значит, для реализации потребовалось бы четыре спринта. Я думаю, они могли бы разделить карту на четыре среза, чтобы на каждый пришелся один спринт, но ребята не рассматривали срезы с этой точки зрения. И вам тоже лучше так не делать. Воспринимайте срезы просто как наборы определенных задач по разработке, каждый со своей исследовательской целью. А решать, в какие спринты или итерации войдет очередной набор, нужно по мере необходимости.
Еще один секрет верной оценки временных затрат
Еще один страшный секрет оценки (который на самом деле вовсе не должен быть секретом) заключается в том, что оценки… оцениваются заранее. Я уверен: порывшись как следует в сборниках оксюморонов, выложенных в Интернете, вы непременно найдете там термин «точная оценка». Если нам точно известно, сколько времени займет какая-то работа, разве мы вообще называли бы это оценкой?
Тем не менее, если вы создаете маленькие фрагменты программного обеспечения, одно из явлений, в которых вы уверены, – это время, которое понадобилось на разработку. Эта величина является измерением, и поэтому она куда точнее оценки.
Таким образом, второй секрет очевиден: чем чаще вы делаете измерения какой-то величины, тем легче вам становится предсказывать ее. Если вы каждый день ездите в офис, то, думаю, легко предскажете, сколько времени займет дорога сегодня. Если же я спрошу вас, за сколько времени вы доберетесь в другое место примерно в том же районе, то, уверяю, вы ошибетесь в оценке не более чем на 10 минут. Именно так работают оценки временных затрат.
Разделяя большие куски работы на меньшие, мы получаем больше возможностей для измерений. Какие-то тонкости, конечно, есть всегда, но в целом предсказания всегда будут тем точнее, чем больше есть примеров выполнения аналогичной работы, где известны временные затраты.
Как владельцу продукта, Майку чрезвычайно важно уложиться в сроки при выпуске этой функциональности. И, как хороший владелец продукта, он старается, чтобы каждый в его маленькой команде чувствовал, насколько он значим для достижения этой цели. Майк относится к предварительным оценкам времени так же внимательно, как к бюджету на выпуск.
Регулируйте свой бюджет
Еще на самой ранней стадии Майк и Аарон работали вместе с программистами, которым доверяли, над начальной оценкой временных затрат. Они рассматривали эту величину как бюджет и старались хорошо организовать его.
С каждым небольшим фрагментом, который создавала команда, они могли получить измерения реальных затрат времени. Каждый кусочек работы расценивался как трата средств из бюджета. К примеру, могло оказаться, что бюджет израсходован наполовину, в то время как выполнена лишь треть работы по реализации запланированной функциональности. Этого, конечно, никто не ожидал, но по крайней мере они могли стать еще внимательнее и каким-то образом на это реагировать. Например, можно было бы позаимствовать бюджет у других функциональностей, над которыми команда в то время работала. Или немного упростить функциональность, но так, чтобы не особенно затронуть интересы пользователей. В конце концов они могли просто смириться с неизбежным и поискать способы как-то изменить ожидания людей, которым пообещали сделать работу к определенной дате.
В зависимости от того, насколько плохо будут обстоять дела, понадобится увеличение запасов пива.
Разделяя карту на срезы для перехода к стратегии разработки, ребята стараются как можно раньше выявить элементы, которые, скорее всего, подорвут бюджет. Это рискованные элементы, и найти их можно, только обсуждая продукт со всей командой.
