Восемь часов – самый длинный промежуток времени на задачу, который нам можно внести в план. Поскольку восьмичасовые задачи привносят в ваш график неопределенность, постарайтесь ограничить их количество. Может показаться, что работа займет восемь часов, но в итоге она может занять половину этого времени или, что более вероятно, вдвое больше. Используйте восьмичасовые задачи только в том случае, если вы полностью уверены, что задача может быть выполнена за восемь часов. Хорошо подойдут задачи, которые требуют механических повторений и не особо заточены под творческое мышление и инновационные решения, или задачи, которые можно эффективно завершить по истечении восьми часов с применением техники таймбоксинга.
Лучше всего разбивать более длинные задачи на более короткие. Если у вас есть одна задача, которая, по вашему мнению, займет шестнадцать часов, разбейте ее на две отдельные задачи по восемь часов, четыре задачи по четыре часа или восемь задач по два часа.
Ограничения в 1, 2, 4, 8 часов помогут точно определить расчетное время на каждое задание, а также сбалансируют детальность списка: группируя или разбивая задания таким методом, мы перечисляем не слишком много, не слишком мало задач.
Ответственные члены команды
Определите в этом столбце, какой член команды будет решать каждую задачу. Вы должны распределять задачи в зависимости от того, у кого есть навыки для выполнения каждой задачи, но также и с учетом того, кто
Опять же, вы можете использовать функцию СУММЕСЛИ в электронной таблице, чтобы вести текущий подсчет количества часов на выполнение задач, которые были назначены каждому члену команды. Конечно, вы должны постараться распределить работу справедливо, в соответствии с тем, сколько часов каждый член команды готов потратить на выполнение работы. Вполне нормально, если кто-то решит работать больше или меньше, чем его товарищи, при условии, что мы предварительно об этом договоримся и что наша общая ответственность будет согласована. У всех разные обстоятельства жизни и разные обязанности, а потому каждый должен иметь возможность работать столько, сколько считает для себя возможным.
Определяем скоуп проекта
Теперь у нас есть вся необходимая информация, чтобы убедиться в том, что наши цели, скорее всего, достижимы и что содержание нашего проекта реалистично. Мы уже подсчитали количество человеко-часов В, которыми располагает наш проект с конца подготовки к продакшену до конца этапа продакшена.
Теперь мы можем использовать функцию СУММ в электронной таблице, чтобы суммировать все время в колонке «Расчетное время» и рассчитать, сколько работы нам предстоит выполнить на этапе продакшена. Давайте назовем это число Р (работа).
Если у нас работы больше, чем времени, наш проект перегружен и мы в беде! Если у нас больше времени, чем работы, все в порядке.
Если Р > В, мы выходим за сроки проекта!
Если Р <= В, содержание проекта под контролем.
Эти расчеты, конечно, неточны – такой метод дает нам только приблизительные значения, и если Р больше В менее чем на 10 процентов или около того, то, вероятно, все не так уж плохо. Но если Р значительно превышает В, мы можем быть уверены, что скоуп проекта слишком большой. Нужно либо привлечь больше членов команды, либо увеличить сроки производства и В, либо убрать некоторые фичи и контент из игры, чтобы уменьшить количество задач и Р. То есть надо вернуться к таблице макродизайна и посмотреть, без чего мы можем обойтись.
Если Р намного меньше В, то у нас есть время включить в нашу игру еще что-то или лучше ее отполировать. Но гораздо чаще при составлении первого плана Р больше, чем В, – иногда намного больше – и мы должны сократить масштабы нашей игры. Иногда помочь в этом могут самые простые решения: например, убрать один уровень и стратегически отдать время на его реализацию другой задаче. Иногда полностью перерабатывать таблицу макродизайна оказывается сложнее.
В этом и заключается суть определения скоупа проекта. С этим процессом невозможно спорить. Независимо от того, как сильно вы любите придуманный вами дизайн, если простейший план говорит вам, что у вас не хватает времени на создание всего дизайна, вам надо что-то изменить.
Жить в отрицании, планируя работать сверхурочно или надеяться, что все пойдет быстрее, чем вы предполагаете, очень неразумно. Жить в отрицании явно иррационально. Надеяться на то, что все пойдет быстрее, чем вы предполагаете, нереально, как знает каждый опытный разработчик игр. А сверхурочная работа легко приведет к кранчу, который мы обсуждали в главе 15.