Render.ru
Поддержать
  • ПРЕДЛОЖИТЬ ПРОЕКТ
  • ДОБАВИТЬ В КОНТАКТЫ
44Записей
53Следят
2Читает
474 KЗаходов
Евгений Мельников (e.ov)

Когда мы закончим? Как считать срок проекта вилкой, а не датой

Мысли Софт

Почему дата «на глазок» почти всегда врёт, откуда в проекте берутся скрытые недели и что на самом деле двигает срок. Разбираем на маленьком примере в бесплатной программе RoadMapper.


[ВИДЕО] Короткая версия этой статьи в ролике на 3 минуты

«Когда мы закончим?»

Это первый вопрос, который задаёт руководство. И почти всегда хочется ответить одной датой: «к марту», «к 16 марта». Звучит уверенно, а потом начинается: отсмотры, правки, «покажи ещё раз», ожидание, пока все соберутся. Март превращается в май, и никто не может объяснить, куда делись два месяца.

Честный ответ на вопрос «когда» - не дата, а диапазон. Например так: «втроём мы закончим между 22 декабря и 16 марта, и вот от чего это зависит». Такой ответ звучит хуже, чем одна дата, зато он правдивый. И главное, его можно посчитать.

01_four_dates.jpg

Иллюстрация 1 - на ней: четыре отчёта калькулятора RoadMapper на одном экране. Минимум и максимум, на двоих и на троих. В каждом отчёте выделены две даты: когда команда закончит свою работу и когда всё будет сдано с учётом ожидания. Это итог, к которому мы придём в конце статьи.


Дальше я покажу, откуда берутся эти четыре даты, на проекте, где каждую цифру можно проверить в уме.

Кто я и откуда эта задача

Я аниматор, работаю в геймдеве, делаю шутеры. На большом проекте условий, от которых зависит срок, у меня набиралось под сотню: этапы, отсмотры, правки, ожидание, перенос работы на другой вид. Удержать всё это в голове невозможно, а прикинуть срок на глазок тем более.

Поэтому я сделал RoadMapper: программу, где сложный проект можно не угадывать, а считать. Она бесплатная и работает под Windows.

Пример у меня игровой, но принцип не про игры. Разработка, стройка, маркетинг, кино: везде, где есть задачи, исполнители и сроки, всё устроено одинаково. Пушки здесь просто удобный пример.

Из чего состоит любой проект

Любой проект можно разложить на три вещи:

- Задачи. Что нужно сделать. В программе каждая задача - это трек, то есть строка таблицы.
- Условия. От чего зависит, сколько займёт задача: этапы, отсмотры, ожидание. Каждое условие - это столбец. В ячейке на пересечении стоит, сколько это условие стоит для этой задачи.
- Люди. Сколько человек делает работу. Их задаёт калькулятор проекта, и он же отвечает, когда мы закончим.

02_model.jpg

Иллюстрация 2, на ней: промо-карточка «Из чего проект». Слева три пункта: задачи, условия, люди. Справа вся таблица учебного проекта: параметры сверху, шесть пушек, этапы и итоговые столбцы с вилкой.

Учебный проект: шесть пушек и четыре этапа

Чтобы всё можно было проверить в уме, проект нарочно маленький. Задачи - анимации шести известных пушек: два пистолета (Glock 17 и Desert Eagle), два автомата (AK-47 и M4A1), дробовик Remington 870 и снайперская винтовка AWM.

Условия - этапы работы. Анимация в геймдеве начинается с черновика, потом доводится до мидреза, затем до хайреза, а в конце идёт полиш. В разных студиях слова свои, но суть одна: от черновика к хорошей анимации и дальше к очень хорошей. Каждый этап - столбец, в ячейке - сколько дней он займёт у этой пушки. Например, у Glock 17 это 2 + 2 + 2 + 1 = 7 дней, а у снайперки, самой сложной, 13.

03_stages.png

Иллюстрация 3, - На ней: таблица этапов в программе. Столбцы этапов заполнены руками, столбец Stages, d считается сам, внизу строка TOTAL с итогом 60.

Всего выходит шестьдесят дней на шесть пушек. Если бы оценка на этом заканчивалась, два аниматора управились бы за полтора месяца. Не управятся. И дальше будет видно почему.

Неочевидное №1: круги отсмотра

Очевидные условия заполнены. Но в любом проекте есть и неочевидные, и первое из них - отсмотры. Сделал кусок работы, показал, получил замечания, пошёл править.

В маленькой команде достаточно показать работу лиду. В большой это уже коллективный отсмотр: лиды, дизайн, люди из смежных отделов. Прилетает фидбек, и исполнитель идёт делать правки.

Сколько будет таких кругов, заранее не знает никто. Дизайн может сказать «ок» после первого же показа, а может после третьего. Кругов вообще может быть сколько угодно, но слово «бесконечность» продакшен не любит, поэтому я закладываю от одного до трёх. Если после третьего круга работу так и не приняли, проблема уже не в оценке, а в том, как договариваются заказчик и исполнитель.

Совет из практики. Пусть право финального «да» будет у одного человека. Когда последнее слово у нескольких, до финала не дойти ни в какие сроки.

Вот и первая вилка. У этого условия не одна цифра, а две: минимум и максимум. И отсмотр нужен не один раз на пушку, а на каждом этапе: черновику, мидрезу, хайрезу и полишу. Четыре этапа - четыре цикла отсмотров.

Такие условия удобно держать наверху таблицы, в отдельной группе параметров. Поменял число там, и пересчиталась вся таблица.

04_params.png

Иллюстрация 4, На ней: группа PARAMETERS в верхней части таблицы. У каждого параметра два столбца, Min и Max. Видно, что круги отсмотра заданы от 1 до 3, а правки после одного круга - полдня.

Посчитаем в уме для одной пушки. Минимум: 4 этапа × 1 круг × 0,5 дня = 2 дня правок. Максимум: 4 × 3 × 0,5 = 6 дней. На шесть пушек это от 12 до 36 дней сверху к шестидесяти. И это только правки.

Правило вилки. В итог «минимум» входят только минимумы, в итог «максимум» только максимумы. Если смешать, ни одна из границ не будет настоящим сценарием, и наверх уйдёт цифра, за которой ничего не стоит.

Неочевидное №2: ожидание и возврат к задаче

Второй неочевидный фактор - сколько работа ждёт, пока её посмотрят. А за ним прячется третий: сколько стоит потом к ней вернуться.

На большом проекте команда не собирается после каждой анимации. Обычно набирается комплект, и работа уходит в ожидание. Сколько она будет лежать: день, два, неделю, пока все найдут время? Это тоже надо закладывать. Ставим вилку: от 1 до 3 дней.

Пока работа ждёт, человек, который её делал, двигать её дальше не может и берёт другую задачу. А когда фидбек наконец приходит, он возвращается и вспоминает: что там было, какие нюансы, на чём остановился. Отложите любую работу на неделю, займитесь другим, потом вернитесь, и вы поймёте, сколько стоит такое погружение. Чем дольше ждали, тем дороже возврат.

Здесь легче всего ошибиться, поэтому разведу эти два времени явно. Ожидание - это календарь: работа лежит, а человек свободен и делает другое. Возврат к задаче - это работа: человек сидит и тратит время, чтобы снова погрузиться.

05_wait_table.jpg

Иллюстрация 5, На ней: карточка-таблица «Ожидание - не работа. Контекст - работа». Два столбца, ожидание отсмотра и возврат к задаче, сравниваются по четырём строкам: что это, чьё время (календарь или работа), вилка (1…3 дня и 0,5…1 день) и что двигает (только дату или дату и загрузку людей).

Ожидание и возврат связаны: ждали день, на возврат хватит полдня, ждали три, уйдёт целый день. Поэтому минимум одного стоит в паре с минимумом другого, а максимум с максимумом. Это то же правило вилки.

Что будет, если их перепутать

Допустим, ожидание просто сложили в работу. Возьмём худший случай и трёх человек.

06_mixup.jpg

Иллюстрация 6, На ней: карточка «Ожидание сложили в работу», сравнение двух расчётов. Если ожидание отдельно: 168 человеко-дней, команда заканчивает 25 января, всё сдано 16 марта. Если ожидание сложили в работу: 384 человеко-дня, и команда заканчивает, и всё сдано только 5 мая.

Человеко-дней становится в 2,3 раза больше. Расчёт скажет, что трое не успевают даже к маю и людей надо удвоить. А на самом деле трое закончат свою работу в январе, сдача уедет в март из-за ожидания, и его никакой наём не ускорит.

Бывает и обратная ошибка: ожидание заложили, а возврат к задаче забыли. Тогда работа недооценена, и в максимуме это 72 дня из 168.

Одна формула на строку

Все условия собираются в два итога для каждой задачи: сколько работы и сколько ожидания.

- Работа = этапы + 4 × круги × (правки + возврат к задаче)
- Ожидание = 4 × круги × дни ожидания

Четвёрка здесь - это четыре этапа, на каждом из которых бывают отсмотры. В столбцах «минимум» формула берёт минимумы параметров, в столбцах «максимум» - максимумы.

Формулы в RoadMapper пишутся почти как в Excel: щелчком по ячейке в таблице её адрес попадает в формулу, а результат виден сразу.

07_formula.png

Иллюстрация 7, На ней: окно редактирования формулы для ячейки «работа, максимум» у снайперки. Формула =H11+4*C2*(C3+C5): этапы своей строки плюс параметры наверху. Результат 31 виден прямо в окне.

Формулу достаточно написать один раз, на первой пушке, и залить на остальные. Ссылки на свою строку сдвигаются, а ссылки на параметры остаются на месте: все пушки смотрят на одни и те же круги и дни.

Проверим на одной пушке

Возьмём самую длинную, снайперскую винтовку AWM. Этапов у неё 13 дней. В лучшем случае работы выходит 17 дней, в худшем 31. Ожидания от 4 до 36 дней.

08_awm_calc.jpg

Иллюстрация 8, На ней: карточка «Снайперка AWM: 13 дней этапов». Расчёт в уме для минимума и максимума. Работа: 13 + 4 × 1 × (0,5 + 0,5) = 17 и 13 + 4 × 3 × (0,5 + 1) = 31. Ожидание: 4 × 1 × 1 = 4 и 4 × 3 × 3 = 36. Внизу обе формулы словами.

Тринадцать дней «чистой» работы превратились в 17-31 день. И это ещё без ожидания. Программа считает ровно то же самое.

09_awm_row.png

Иллюстрация 9, На ней: строка AWM в таблице. Выделены 13 дней этапов, работа от 17 до 31 и ожидание от 4 до 36. Цифры совпадают с теми, что мы посчитали в уме.

Что получилось по всему проекту

Складываем все шесть пушек. Работы выходит от 84 до 168 дней, ожидания от 24 до 216.

10_fork.jpg

Иллюстрация 10, На ней: промо-карточка «Не одна цифра, а вилка». Работа: 60 → 84…168 дней. Ожидание: 0 → 24…216 дней, «больше, чем работы!». Внизу подпись: минимум - если дизайн примет с первого раза, максимум - если с третьего.

Шестьдесят дней стали вилкой от 84 до 168. А ожидания в худшем случае набралось больше, чем всей работы. Пугаться рано: ожидание людей не занимает, и дальше видно, во что оно обходится на самом деле.

Калькулятор: четыре даты

Таблица знает, сколько работы. Калькулятор проекта раскладывает эту работу по календарю на заданное число людей и отвечает, когда мы закончим.

Порядок простой. Отмечаем, какие строки и столбцы считать. Столбец ожидания помечаем как «не нашу работу»: так калькулятор понимает, что это время двигает дату, но не занимает людей. Задаём дату старта и число людей и нажимаем Calculate.

Логика у калькулятора понятная: одна задача достаётся одному человеку целиком, кто освободился раньше, тот берёт следующую. Ожидание ставится в конец задачи: пока пушка лежит на отсмотре, человек уже делает другую.

11_calculator.png

Иллюстрация11, На ней: окно калькулятора проекта. Видны пресеты, число людей (Workers), кнопка Calculate и отчёт: Finish (команда заканчивает свою работу 25 января), Delivery with those (с ожиданием всё сдано 16 марта) и Floor (самая длинная строка).

В отчёте три главные строки:

- Когда команда закончит свою работу. Люди освобождаются.
- Когда всё будет сдано. С учётом того, что последние работы ещё ждут отсмотра.
- «Пол». Самая длинная задача в проекте. Быстрее неё не выйти, сколько людей ни добавь, потому что одну задачу делает один человек.

Четыре пресета, четыре даты

Минимум и максимум, на двоих и на троих, старт 2 ноября. Это как раз те четыре отчёта с первой картинки, только сведённые в одну таблицу.

12_four_presets.jpg

Иллюстрация 12, На ней: карточка-таблица «Четыре пресета - четыре даты». Для каждого варианта человеко-дни, дата, когда команда заканчивает работу, и дата, когда всё сдано. Минимум на троих: 16 и 22 декабря. Минимум на двоих: 31 декабря и 6 января. Максимум на троих: 25 января и 16 марта. Максимум на двоих: 1 марта и 20 апреля. Даты сдачи в минимуме зелёные, в максимуме красные.

Посмотрите на разницу между «закончили» и «сдали». В максимуме ожидания было 216 дней, больше, чем работы, а сдачу оно сдвинуло всего на семь недель. Потому что пушки ждут параллельно: пока одна лежит на отсмотре, люди делают другие. Ровно поэтому ожидание и нельзя складывать в работу.

Калькулятор не только считает, но и сам раскладывает план на таймлайне: сплошная полоса - человек работает, пунктир - работа ждёт отсмотра.

13_timeline.png

Иллюстрация 13, На ней: два плана на таймлайне один под другим, сверху минимум, снизу максимум на троих. Коричневые сплошные полосы - работа, серые пунктирные - ожидание отсмотра. У AWM жёлтый бейдж «самая длинная строка, больше людей её не ускорят». Синей линией отмечена веха Alpha 1 марта: к ней команда свою работу сделает, а сдачу нет.

Что показать руководству

Не дату, а диапазон и то, от чего он зависит. Например:

«Втроём - между 22 декабря и 16 марта. Где именно, зависит от того, сколько кругов отсмотра понадобится и как быстро мы смотрим работу».

На встрече лучше всего работают обе границы на одной шкале. Пушки и люди те же, разница только в кругах отсмотра и ожидании.

14_min_vs_max.png

Иллюстрация 14, На ней: два плана один под другим, на одной шкале времени. Сверху минимум на троих (всё сдано 22 декабря), снизу максимум на троих (всё сдано 16 марта). Сразу видно, насколько длиннее становятся пунктиры ожидания.

Неделя против семи недель

А теперь самое интересное. Такой ответ не только честнее, он сразу показывает, на что можно влиять. Возьмём худший случай: три человека, отсмотра ждём до трёх дней, всё сдано 16 марта. Как ускориться: нанять четвёртого человека или смотреть работу быстрее?

15_levers.jpg

Иллюстрация 15, На ней: промо-карточка «Неделя против семи недель». Три варианта с датами сдачи: как есть (16 марта), нанять четвёртого (10 марта), смотреть работу на следующий день (25 января, выделен зелёным).

Четвёртый человек даёт неделю. А отсмотр на следующий день вместо трёх даёт семь недель, и без найма. Фраза «давайте смотреть работу быстрее» - это не про вежливость, а про срок проекта. И когда это показано цифрами, а не словами, разговор с руководством идёт совсем по-другому.

Что унести с собой

Даже если вы никогда не откроете RoadMapper, вот что работает в любом проекте:

1. Разложите проект на задачи и условия. Задача - строка, условие - столбец.
2. У неочевидных условий две цифры. Отсмотры, правки, ожидание: всегда минимум и максимум.
3. Не смешивайте границы. «Минимум» считается только из минимумов, «максимум» только из максимумов.
4. Ожидание - это календарь, возврат к задаче - работа. Первое двигает дату, второе ещё и занимает людей.
5. Руководству - диапазон и то, от чего он зависит. Не одну дату.

Принцип не меняется от размера проекта. Меняется только число условий. В моём рабочем проекте их под сотню, здесь их шесть, а логика та же.

Попробовать самому

RoadMapper бесплатный. Скачать: https://eu-melnikov.github.io/roadmapper-versions.html

Внутри программы есть справка (F1), а в ней урок «Оценка проекта» с этим самым учебным проектом: шесть пушек, параметры, формулы и четыре пресета калькулятора. Всё, что показано в статье, там разобрано по шагам, а сам файл проекта можно ломать как угодно.

Для начала попробуйте простое: поменяйте максимум кругов отсмотра с 3 на 2 и пересчитайте вариант «максимум, три человека». Насколько приблизилась дата?



Евгений Мельников.

0
Комментарии:2
по поступлению
0
Вилка в глаз или дата раз?
4
0
Николай Громов
13.10.2026 23:42
Пока не дойдём до ложки или половника не считается