Ознакомительная версия. Доступно 26 страниц из 130
Если у нас больше времени, чем работы, все в порядке.
Если Р > В, мы выходим за сроки проекта!
Если Р <= В, содержание проекта под контролем.
Эти расчеты, конечно, неточны – такой метод дает нам только приблизительные значения, и если Р больше В менее чем на 10 процентов или около того, то, вероятно, все не так уж плохо. Но если Р значительно превышает В, мы можем быть уверены, что скоуп проекта слишком большой. Нужно либо привлечь больше членов команды, либо увеличить сроки производства и В, либо убрать некоторые фичи и контент из игры, чтобы уменьшить количество задач и Р. То есть надо вернуться к таблице макродизайна и посмотреть, без чего мы можем обойтись.
Если Р намного меньше В, то у нас есть время включить в нашу игру еще что-то или лучше ее отполировать. Но гораздо чаще при составлении первого плана Р больше, чем В, – иногда намного больше – и мы должны сократить масштабы нашей игры. Иногда помочь в этом могут самые простые решения: например, убрать один уровень и стратегически отдать время на его реализацию другой задаче. Иногда полностью перерабатывать таблицу макродизайна оказывается сложнее.
В этом и заключается суть определения скоупа проекта. С этим процессом невозможно спорить. Независимо от того, как сильно вы любите придуманный вами дизайн, если простейший план говорит вам, что у вас не хватает времени на создание всего дизайна, вам надо что-то изменить.
Жить в отрицании, планируя работать сверхурочно или надеяться, что все пойдет быстрее, чем вы предполагаете, очень неразумно. Жить в отрицании явно иррационально. Надеяться на то, что все пойдет быстрее, чем вы предполагаете, нереально, как знает каждый опытный разработчик игр. А сверхурочная работа легко приведет к кранчу, который мы обсуждали в главе 15.
Если вы планируете реализовать свой проект, работая дольше, имейте в виду, что количество недель подряд, в течение которых люди могут работать сверхурочно, очень ограниченно, и это быстро приводит к снижению производительности и выгоранию. Как говорит вооруженная исследованиями Сара Грин Кармайкл в своей статье для Harvard Business Review, которую я упоминал в главе 15, «Даже если вы любите свою работу и добровольно засиживаетесь допоздна, усталый человек все равно делает больше ошибок… Переусердствуете – упустите из виду основную картину. Исследования показали, что при выгорании человек начинает путаться в пустяках… Словом, повесть о переработке – это повесть о снижающейся отдаче: продолжайте пришпоривать себя, и будете все хуже выполнять все более простые задания»[130].
Еще одна причина серьезно подойти к содержанию проекта – это неопределенность будущего и тех дней или недель, которые может потерять проект из-за непредвиденных событий: плохого самочувствия, семейных неурядиц, просроченных лицензий на программное обеспечение или сломанного оборудования. Также важно подойти к критической последней трети проекта, когда мы пытаемся связать все нити игры вместе с последними важными дизайнерскими решениями, не измотанными, раздражительными и демотивированными, как обычно бывает при кранче. Нам нужно подойти к концу проекта с хорошим физическим и психическим здоровьем, чтобы мы могли принять правильные решения и сделать хорошую игру.
По иронии судьбы, когда увлеченность побуждает людей расширить игру до невероятных масштабов при недостаточном количестве человеко-часов, либо получаются плохие игры, либо никакой игры вообще не выходит. Определение содержания проекта часто сводится к простому выбору: вы можете создать проходную большую игру, в которую никто не захочет играть, или вы можете создать небольшую игру, которую люди полюбят, запомнят и с удовольствием будут играть в нее снова и снова.
Отслеживание прогресса в простом плане
Вы можете использовать простой план, который мы создали, чтобы отслеживать прогресс проекта по мере продвижения этапа продакшена, просто вычеркивая задачи из списка, как показано на рис. 19.2. Каждый раз, как вы выполните задачу, вычеркните строку из списка, воспользовавшись форматированием таблицы.
Рис. 19.2. Вычеркивание задач из списка
Если вы измените расчетное время для выполненных задач на ноль, это обновит все вычисления, которые вы сделали с помощью функций СУММ и СУММЕСЛИ, рассчитав общее количество оставшихся часов для каждого приоритета, члена команды и в целом.
Но отслеживание вашего прогресса с помощью такого простого метода может быть рискованным. В какой-то момент все пойдет лучше, чем ожидалось, и вы будете опережать график. В другие недели все будет идти медленно, и вы будете отставать. Разве не было бы здорово, если бы у вас был инструмент, который помог бы определить, впереди вы или отстаете? Хорошая новость: такой инструмент есть, и он называется диаграммой сгорания задач (англ. Burndown Chart).
Диаграмма сгорания задач
Кен Швабер – разработчик программного обеспечения и продакт-менеджер, который участвовал в создании платформы Agile-разработки Scrum. Кен изобрел диаграмму сгорания задач в качестве инструмента планирования, помогающего командам Scrum прогнозировать ход проектов, и впервые описал ее на своем веб-сайте в 2000 году[131].
Я лично видел, как диаграммы сгорания задач помогли более чем ста проектам в программе USC Games успешно завершиться. Я наблюдал, как амбициозные разработчики реализовывали свои мечты, не выгорая и просто наблюдая за линией на графике в течение нескольких недель.
Диаграмма сгорания задач дает графическое представление (а) работы, которую еще предстоит выполнить до завершения игры, (б) того, как быстро вы выполняете работу в среднем, и (в) не закончится ли у вас время. Таким образом, она чрезвычайно эффективно помогает разобраться в масштабах проекта в условиях неопределенности и неизвестности, присущих сложным творческим процессам создания видеоигры.
Построить диаграммы сгорания задач с нуля может оказаться довольно сложно, но вы можете найти множество примеров и шаблонов онлайн, в том числе на сайте этой
Ознакомительная версия. Доступно 26 страниц из 130
