Как составить план-бюджет проекта в Merlin (Mac OS)

На этапе предпродажи проекта всегда возникают два вопроса.

1. Что вы будете делать?
2. Сколько это стоит?

Чтобы ответить на них быстро и с хорошей точностью, проще всего составить план-бюджет проекта.

Есть проекты, спланировать и забюджетировать которые относительно легко.

1. Проектирование интерфейса.
2. Сборка сайта по схеме Content First.
3. Запуск в разработку идеи корпоративного стартапа.
4. Составление простого (!) технического задания.
5. Тестирования и аудиты всех мастей.
6. Проведение курса или семинара.

План-бюджет не отвечает на следующие вопросы.

1. Почему мы должны делать проект?
2. В чем суть и смысл конкретной подзадачи?
3. Кто конкретно будет выполнять задачу?

В каждой компании свои тонкости и предпочтения по составлению плана-бюджета. О методиках-подходах написаны книги.
Но на практике всегда нужна простая инструкция: делай так, потом так, и всё получится.
Ниже — как раз такая инструкция: как шаг за шагом составить план-бюджет проекта в программе Merlin.

Merlin — аналог MS Project для операционной системы Mac OS. Альтернативы есть, но в этой статье мы про них ничего не пишем.

Мы постарались опустить всю теорию. В комментариях готовы обсуждать вопросы: «Почему так, а не иначе?»

Статья полезна заказчикам, продажникам и менеджерам проектов. Чуть меньше — аналитикам, дизайнерам, проектировщикам, техническим писателям, редакторам, контент-менеджерам и т. п. К программистам материал отношения не имеет.

Порядок действий

На выходе получаем план-бюджет проекта в виде диаграммы Ганта. Формат результата — PDF-файл. Язык — русский. Количество специальных обозначений минимально: новичку легко объяснить суть документа за 5–10 минут.

Последовательность шагов такова.

1. Сформулировать ожидания по срокам и стоимости.
2. Настроить проект.
3. Перечислить этапы работы.
4. По каждому этапу:
   1. записать последовательность работ;
   2. перечислить промежуточные результаты;
   3. вставить согласования и презентации;
   4. задать порядок действий;
   5. прикинуть количество итераций и внести их в план.
5. Оценить трудозатраты на каждый шаг.
6. Задать календарные рамки для медленных работ.
7. Назначить исполнителей.
8. Сравнить итоговые сроки и стоимость с ожиданиями.
9. Еще раз перепроверить и исправить, если нужно.
10. Создать PDF-файл с планом-бюджетом проекта.

Ниже описаны нюансы — только нюансы! — каждого шага. Очевидные действия пропускаем: всё же это не учебный курс для чайников.

Цель: за 20–40 минут с нуля распланировать нетиповой проект (100–300 пунктов списка работ). Предполагаем, что автор документа быстро думает и еще быстрей печатает.

Пошаговые шпаргалки

1. Сформулировать ожидания по срокам и стоимости

Этот шаг не имеет отношения к Merlin. Но именно он поможет увидеть, насколько опасна и неточна оценка «с потолка».

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

Оценивайте быстро и молча. Это не шутка: важно принять решение самостоятельно, а не пытать окружающих.

2. Настроить проект

Некоторые параметры проекта трудно откопать в интерфейсе Merlin. А иногда сложно догадаться, что их вообще надо искать и менять.

3. Перечислить этапы работы

Этапом мы считаем короткую последовательность простых действий, которая приводит к конкретному результату. 7–10 задач, не больше. План проекта крупными мазками — это путь от одного этапа к другому.

Этапы следуют один за другим (очень редко параллельно).

1. Забудьте про стандарты и готовые шаблоны. Кому же нравится следовать чужим методикам? Создавать собственную структуру из хаоса — куда более осмысленное занятие.
2. Двух уровней вложенности достаточно почти всегда. Трех — всегда.
3. Два обязательных этапа почти любого проекта — старт и финиш. Какие еще обязательные этапы есть в вашей практике — вам лучше знать.
4. Детализировать этапы пока рано. Это следующий шаг.

4. По каждому этапу

Многие составляют список задач, прикидывают бюджет каждого этапа и считают, что на этом планирование окончено.
Мы считаем, что этого недостаточно. Обязательно нужно детализировать каждый этап.
Чем мельче детализация, тем проще выявить ошибки планирования в разговоре с исполнителями. И тем точней бюджет.

4.1. Записать последовательность работ

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

1. Запишите все работы, которые придут в голову. Ключевой вопрос: «Что маленькое и понятное нужно сделать, чтобы приблизиться к результату?»
2. К каждому пункту получившегося списка задайте два вопроса: «Что должно произойти для того, чтобы…» и «А что будет после этого?» Ответы добавьте в список.
3. Прочитайте результат как историю, представьте себе развитие событий. Найдите в этой истории пробелы. Заполните их новыми работами.
4. Все названия работ начинаются с глагола: «Нарисовать эскиз баннера», «Обсудить требования внутри команды».
5. Формулировки отвечают на вопрос «Что сделать?». То есть в начале не просто глагол, а совершенная форма: сделаю, а не делаю. Есть только одно исключение — «Презентация чего-нибудь». О нем ниже.
6. В этапе не больше 10 работ. Если их число подбирается к 15 — найдите способ разбить на два этапа или на несколько итераций.
7. Встречи и обсуждения — это работа. И очень большая: примерно 60% от всего объема. Иногда 80%. Обязательно включайте в план все встречи и обсуждения. То же самое относится и к созвонам.
8. Внесение правок по результатам встреч и обсуждений — тоже работа.

4.2. Перечислить промежуточные результаты

Что будет результатом? Что можно будет взять в руки? В чем воплотились творческие усилия команды? Какой промежуточный «кирпичик» мы создадим, согласуем, допилим, а потом презентуем и используем в конце? Как называется эта вещь? Именно результат делает этап очевидно полезным и конкретным.

1. Называйте результаты коротко и точно. «Список комментариев» — плохо. «Комментарии проектировщика» — уже лучше. «Предложения по доработке интерфейса» — годится, хотя и длинновато.
2. Договоритесь о терминах. Жизненные ситуации — это ведь не то же самое, что пользовательские сценарии?
3. Зафиксируйте формат. Прототип интерфейса — это набор html-файлов или картинка?
4. Называйте финальную версию чего угодно — именно финальной: «Финальная версия пресс-релиза».
5. Уточняйте понятия. «Техническое задание» — это три листочка или три тома? «Дизайн» — это набросок или 100500 эскизов?

4.3. Вставить согласования и презентации

Общение с заказчиком и командой проекта — это работа. Содержательная. И очень сложная. На каждый этап потребуется как минимум одно согласование, обсуждение и презентация.

1. Если нужно, поставьте работу «Получить отмашку на старт этапа».
2. Разбавьте рабочий процесс встречами и обсуждениями так, чтобы общаться с клиентом не реже чем раз в три дня.
3. Последнюю версию результата любого этапа всегда надо согласовывать. Это работа: «Согласовать обоснование проекта».
4. Хорошая доза на каждый этап — два контакта с клиентом. Один раз «Обсудить первую версию результата», второй — «Согласовать финальную версию».
5. Иногда в плане бывает и три-четыре встречи с клиентом на этап. Больше — уже скорее ошибка планирования: разбейте этап на два.
6. Презентацию можно записывать без глагола: «Презентация концепций интерфейса». Да, исключение из правила.
7. К презентации нужно подготовиться. Это работа. Вставляйте ее в план: «Подготовить слайды презентации», «Предварительно обсудить суть презентации с людьми, принимающими решения» и т. п.
8. Встречу нужно организовать. Если участники разбегаются, как тараканы, а переговорок мало, то и это тоже работа: «Назначить встречу/созвон».
9. Внутренние обсуждения — тоже работа: «Обсудить прототип со старшим проектировщиком».
10. После каждого обсуждения вставляйте задачу: «Внести правки по результатам обсуждения».

4.4. Задать порядок действий

В диаграмме Ганта общая длительность проекта складывается из длительностей мелких задач. Так что задачи нужно связать в цепочки: что за чем идет и что чему параллельно.

1. Очень редко нужно что-то сложней связи Finish — Start.
2. Если связь Finish — Start выглядит нелепо, разорвите ее. И поштучно настраивайте более тонкие связи между работами.

4.5. Прикинуть количество итераций и внести их в план

Только очень маленькие проекты можно сделать по каскадной модели. Обычно ядро проекта — это несколько итераций «содержательной» работы: проектирования, тестирования, сбора требований, написания текстов и т. п.

1. Итерации должны быть одинаковы по составу работ. Или почти одинаковы.
2. Количество итераций надо оценить уже в плане-бюджете. Это неприятно, но надо. Всё равно надо. Не хочется, а надо.
3. Совсем не знаете, сколько итераций ставить, — ставьте три.
4. Для больших и невнятных заказчиков ставьте 17. Так и будет, поверьте.
5. Количество итераций — вопрос торга с заказчиком. Умный заказчик быстро понимает, что в его интересах — быстро всё согласовать за две итерации. Убедитесь, что вы заложили пространство для торга, и можете выбросить одну итерацию без потери смысла проекта.

5. Оценить трудозатраты на каждый шаг

Удивительно, но даже оценка «с потолка» работает. Смело гадайте (да, это против всех правил). Но лучше допросите исполнителей по каждому пункту плана.

1. Выбирайте оценку трудозатрат из прогрессии: 1–2–4–8–16.
2. Всё, что больше 16 часов, разбивайте на несколько работ.
3. Минимум трудозатрат — 1 час. Даже если по сути 5 минут, все равно время уходит на погружение и мелкие вопросы.
4. Не знаете, во сколько оценить, — ставьте 4 часа. Сократить успеете.
5. Все встречи вне вашего офиса — 4 часа. Возможно, для Москвы — 8.
6. Точней, чем с шагом в 2–4 часа, оценивать в любом случае не нужно.
7. Когда сверяете оценки с исполнителями, спрашивайте так: «На эту работу уйдет скорее 2 часа или скорее 4?» Не просите оценить с чистого листа — людей замучаете.

6. Задать календарные рамки для медленных работ

Есть задачи, в которых работ — на 5 минут. Но эти 5 минут нужно еще найти в графике занятого человека. На подобные пункты плана нужно зарезервировать не только трудозатраты, но и календарное время: оно влияет на сроки, но не на стоимость проекта.

1. Большинство задач не требуют отдельного календарного времени.
2. Календарные диапазоны пишите в днях. Не в часах.
3. На все совещания и презентации выделяйте по 2 календарных дня. Сдвиги почти неизбежны.
4. На созвоны и согласования — 1 день. Та же причина. К внутренним встречам тоже относится.
5. Ставьте календарную длительность на задачи вида «Собрать статистику». Проверить данные можно за 5 минут, но копиться они будут несколько дней или даже недель.

7. Назначить исполнителей

Редкий этап. Обычно хватает «исполнителя по умолчанию» с почасовой ставкой, которую вы назначили на весь проект в самом начале планирования.

1. Чтобы включить в план чужие работы (например, если что-то должен сделать сотрудник заказчика), создайте ресурс с нулевой стоимостью.
2. Если есть исполнители с особой ставкой, назначайте явным образом только их. Остальные задачи оставьте с «исполнителем по умолчанию».
3. Даже в сложных случаях для оценки бюджета обычно достаточно создать трех исполнителей с разными ставками.
4. После назначения исполнителей «поедет» нумерация задач плана. Это не ваша ошибка, а просто особенность Merlin. Не ищите «задачи-потеряшки».

8. Сверить итоговые сроки и стоимость с ожиданиями

Найдите стикер из первого пункта. Что на нем было написано? Сравните с результатом.

1. Ваша «ошибка» ничего не значит.
2. Точное попадание — тоже.
3. Важно только одно: какую погрешность вы со временем начнете считать приемлемой?

9. Еще раз перепроверить и исправить, если нужно

Бывает, что результат не устраивает. Особенно заказчика. Тогда нужно пройти по всем шагам еще раз. И задать себе два вопроса.

1. Что можно поменять, чтобы план приблизился к мечте?
2. Какая тут может быть ошибка?

Иногда нужно править параметры работы, иногда — настройки проекта в целом.

1. Бывает, что поменять нельзя. Или что после переделки ситуация только ухудшилась. Ну что ж, значит, так выглядит правда.
2. Подогнать такой план под необоснованные ожидания — невозможно. И это хорошо.
3. Обычно после review появляются 5–7 забытых задач…
4. …а уточнения трудозатрат снижают цену на 20%.
5. Календарные сроки почти никогда нельзя уменьшить.

10. Создать PDF-файл с планом-бюджетом проекта

Как ни странно, это нетривиальная интерфейсная задача.

* * *

Вот и всё. Как видите, освоить навык быстрого составления плана-бюджета в Merlin — дело нехитрое. Правда, нужно уметь быстро печатать. Ну и смело пренебречь «солидными» методами планирования.

На вопросы по фишкам и смыслу с удовольствием ответим. За уточнения любого рода будем благодарны.

Автор: sobakapavlova

Источник