Через какой показатель ms project можно связать казначейство и бухгалтерскую программу с ms project

Обновлено: 18.04.2024

Среди главных вопросов, на которые надо ответить руководству компании перед решением взяться за проект, выделяются следующие:

Будет ли выгодно выполнить обсуждаемый проект за предлагаемую цену?
Как в течение проекта будет выглядеть ситуация по финансам, не появится ли кассового разрыва?

При написании этой статьи учитывалось, что у среднего РМа, выросшего из сеньора, совершенно нет желания вникать в финансовые детали плотно. Поэтому показано, как получить финансовые расчеты по пресейлу с минимальными затратами времени и умственных усилий – вроде получения зачета по предмету «Экология» в техническом ВУЗе, да простят меня экологи.

Предполагается, что план-график в MS Project вы можете сделать сами — ввести задачи, простроить связи между ними, организовать иерархию и т.п. То, о чем будет идти речь – это быстрые подготовка и ввод финансовой информации в MS Project, чтобы получить работающую финансовую модель для пресейла, с которой можно играть, отвечая на вопрос «что-если» с большой точностью в онлайне.

В статье нет никаких финансовых откровений, все стандартно, версия MS Project может использоваться любая, начиная с 2003. В статье использовался MS Project 2019, но в интерфейсе большой разницы нет. Увы, по работе используется англоязычная версия, я не стал рисковать и менять ее на русскоязычную исключительно для написания данной статьи.
Переходим к сути.

Часть первая. Рейты и будущие расходы

Давайте рассмотрим пресейл проекта разработки ~~сферического коня в вакууме~~ железки под Линуксом, которая мониторит важные для заказчика параметры и выдает управляющие воздействия по итогам анализа поступивших данных. Разработка включает разработку платы, системного и прикладного софта, FPGA нет, корпус взяли готовый. Наша цель — выкатить заказчику адекватную сумму с учетом процента своей прибыли и оценить график платежей по проекту, чтобы не уйти в кассовый разрыв.

Какие специалисты нужны для данного учебного проекта:

Программист.
Схемотехник.
Разводчик платы.
Тестер
Внедренец.
Вы сами как ПМ. Ваше время тоже стоит денег.

Лично я предпочитаю в данном случае просто умножить зарплату «чистыми» на 2. Да, вот так просто. Поскольку с зарплаты на руки компания платит налог 43%, а оставшиеся 57% идут как накладные расходы. В эти оставшиеся 57% входят и неявные детали, которые влияют на итоговый рейт: есть отпуск 28 дней, разработчики регулярно болеют, отпрашиваются – можно считать, что они работают 10,5 месяцев в году, и т.п. Если директор/финансист не согласны с 57%, то это уже точно не ваша головная боль – у вас нет и в принципе не может быть доступа ко всей бухгалтерии компании, поэтому попросите директора/финансиста дать свою цифру, а пока ее нет — ставим 57%.

Пример расчета: прикладной программист получает 82 000р на руки. В среднем месяце 164 рабочих часа (с учетом праздников), т.е. его почасовая зарплата 82 000 / 164 = 500р. Ставим рейт 1000р/час. Все.

Прежде чем продолжить, стоит описать еще один способ учета накладных расходов. Как вы, наверное, уже заметили, накладные расходы на офис, печеньки и юристов одинаковы для джуниора и сеньора, так что не совсем правильно будет отсчитывать накладные в % от их зарплаты. Поэтому можно попросить директора поставить задачу финансистам, чтобы те посчитали среднюю цифру расходов на офис в час за период (год/квартал/месяц — неважно, поделим на количество часов). Тогда мы получим цифру, скажем, 300р/ч накладных отдельно и почасовой расход на зарплату (с налогами) отдельно 82 000*1,43/164 = 715р/ч, и это будет точнее, мы получим в сумме 715 + 300 = 1015р/ч. Единственная, но крупная проблема здесь – очень сложно получить от бухгалтерии точную сумму накладных расходов за период. Мне такое удалось только однажды, поэтому я предпочитаю добавлять проценты от зарплаты. Да и проект тянут в основном мидлы с более-менее одинаковой зарплатой, так что разница между двумя способами учета не очень велика. В конце концов, можно договориться, опять же, поставить сейчас 57% накладных от зарплаты, а когда (точнее, если) бухгалтерия предоставит цифру накладных в час – быстро поменяете несколько рейтов, займет это 5 минут от силы, все пересчитается автоматически.

Просто? На мой взгляд – да.

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

Программист — 1300р/ч
Схемотехник — 800р/ч
Разводчик печатной платы – 800р/ч
Тестер — 600р/ч
Внедренец — 1000 р/ч
ПМ, т.е. вы сами – 1200р/ч, при этом вы заняты в проекте на 30%, остальное – другие проекты, пресейловая нагрузка и т.п.

С расчетом рейтов закончили. Вот исходный план-график:

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

Ок, жмем на кнопку “Resource Sheet” и в открывшемся представлении вводим полученные рейты:

Обратите внимание на строку «Завод». Это статьи покупок, где все деньги надо отдавать сразу, точнее – немного заранее, поскольку ваша бухгалтерия перечисляет деньги не моментально, а периодически, один-два раза в неделю, плюс деньги будут идти некоторое время.

Поэтому здесь ставим тип ресурса для изготовления-покупки как «Material», выставляем сумму 40 000 в «Cost/Use» и поставим оплату (Accrue At) на старте задачи. Конечно, по фэн-шуй надо разбить задачу «Изготовление платы» на два Milestones: оплата и получение, но так cложнее – две строки вместо одной, добавляем временное смещение, не видное на план-графике и т.д. Так, как сделано — нагляднее и сложнее забыть. Можно еще подкрасить эту задачу оранжевым цветом, но это уже перебор.

Сейчас переключимся обратно в представление диаграммы Гантта. Чтобы посмотреть получившуюся стоимость, добавим колонку с названием “Cost” или «Стоимость» и вот что мы получим:

Стоимость проекта теперь прозрачна с точностью до работ. Руководство видит, как именно будут расходоваться его деньги в вашем проекте, и это выгодно отличает вас от остальных РМ-ов, которые такой информации не дают. Да и споры о людях в проекте куда проще перевести в конструктивное русло: все прозрачно, хотите дешевле и быстрее – давайте в проект сеньоров вместо мидлов на ключевые задачи, пересчитаем прямо сейчас.

Собственно, на этом основная часть закончена, и с полученной моделью можно играть в достаточно больших пределах, получая мгновенное значение стоимости при тех или иных изменениях. Это хорошо, но это еще не все. Перед нами стоит задача снять с руководства второй головняк – посчитать cash flow на проекте, чтобы аргументированно дать ответ на вопрос: сколько запросить предоплаты и как разбить ее по этапам.

Часть вторая. Cash Flow и будущие доходы

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

Давайте поставим в проекте прибыльность 30%, что дает нам 1 233 600 *1.3 = 1 603 680. Округлим до 1 600 000, чтобы не путаться в копейках. На этой сумме надо посчитать, сколько просить авансом, а сколько – по завершении этапов. Стандартно для разработки программно-аппаратных комплексов иметь аванс в 40% на старте, поскольку закупка оборудования и комплектующих происходят на первом этапе, и по 30% по окончанию первого и второго этапов. Получаем, таким образом:

640 тыс – предоплата
480 тыс – по окончанию первого и второго этапов.

Поставим в проекте Milestones (вехи), соответствующие моментам оплаты этапов. Переименуем, чтобы не плодить лишних строк, задачу «Старт проекта» в «Предоплата», а «Окончание проекта», соответственно, в «Оплата второго этапа». И добавим веху «Оплата первого этапа» после задачи «Перенос ПО на целевую плату» — заказчика легче убедить расстаться с очередными деньгами в момент лицезрения начавшего работать продукта. В столбце «Имена ресурсов» ставим «Оплата 1», «Оплата 2» и «Оплата 3». Должно получиться вот так:

Снова жмем на «Resource Sheet» и вводим полученные значения предоплаты. На этот раз, разумеется, с отрицательным знаком, поскольку мы раньше считали деньги, уходящие из кармана компании, а теперь наоборот. И сменим тип ресурсов «Оплата х» с «Работа» на «Материалы», выставив оговоренные выше суммы (с отрицательным знаком, поскольку платят нам, а не мы) в Cost/Use и поставив оплату (Accrue At) на старте задачи:

Обратите внимание, что стоимость с отрицательным знаком отображает только MS Project 2019, в предыдущих версиях отрицательные значения заключаются в круглые скобки. Хотя считается все правильно.

Ввели. Переключаемся обратно в Gantt и видим такую вот картинку:

Общие расходы по проекту выражаются отрицательной величиной и это, несомненно, приятно.
Ок, переходим к кэш-фло по месяцам. Тут уже придется, увы, экспортировать данные в Эксель и смотреть в нем. Можно, конечно, переименовать несколько полей в названия месяца и года, вывести каждый месяц в свой столбец и соорудить для каждого столбца свою формулу-монстра, учитывающую год и месяц… Я так делал однажды, но смотрится это отвратительно, особенно если проект длинный. Куда как проще использовать встроенные средства создания отчетов и вывод их в Excel, мы по этому пути и пойдем.

Как всегда, все очень просто — переходим на вкладку “Reports” и жмем на кнопку «Visual Reports Export»:

Далее в открывшемся окне выбираем «Cash Flow Report», ставим уровень «Months»:

Жмем на «View» и в открывшемся окне Excel выбираем вторую вкладку (лист) – «Task Usage». Получаем такое вот окно, но оно пока малоинформативно:

На нем надо поставить в «Поля сводной таблицы» галочку «Monthly Calendar» и щелкнуть по значку "+", отмеченных красными овалами на рисунке. Перед нами открывается то, что мы хотели: помесячный кэш-фло в нашем проекте с кумулятивной информацией, т.е. мы понимаем ежемесячно общий итог — в плюсе мы или в минусе в этом месяце, и динамику — мы уже вышли в плюс в проекте по деньгам, или еще нет:

Давайте интерпретируем полученные данные. Красными овалами отмечены места, где нужно быть внимательным.

За март общий профит у нас отрицательный (не забываем инвертировать в уме знак, поскольку речь идет о расходах), расходы превышают доходы на 67 360р. За апрель — положительный, но лишь на 13280р, задержка всего на день сделает его отрицательным. Поэтому надо либо настаивать на увеличении аванса до 45%, либо вернуться из мира цифр в мир реальный и понять, что эти суммы не существуют сами по себе, они являются лишь информацией для принятия решений. Упоминавшиеся +57% к рейтам инженеров — некая абстракция, юристы и бухгалтеры получают свою зарплату за счет не только этого, но и других проектов. Вот если и по ним всем будет кассовый разрыв в марте — то это уже повод настаивать либо на увеличении аванса по проекту, либо отсрочить свои платежи на этот месяц, а если никак — искать другие способы заткнуть дыру, например, взять кредит в банке на пару месяцев. Но эти решения принимают финансист/директор, а не вы как РМ. Вы и так дали им очень ценную информацию: через два месяца есть риск кассового разрыва, у вас есть время, думайте. Это гораздо лучше, чем узнать об этой проблеме за две недели.

Как только ваш план проекта готов в MS Project, для менеджера проекта становится необходимым измерить фактические данные (с точки зрения выполненной работы, использованных ресурсов и понесенных затрат) и пересмотреть и изменить информацию о задачах и ресурсах в связи с любыми изменениями в планы. Руководитель проекта не должен предполагать, что все идет по плану, и всегда должен отслеживать каждую задачу. Сопротивление формальному отслеживанию данных управления проектом является нормой. Вы можете преодолеть сопротивление отслеживанию, объяснив свои ожидания, объяснив преимущества отслеживания и обучив людей самостоятельно отслеживать задачу.

Сохранить базовый уровень

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

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

Примечание. В MS Project 2013 вы можете сохранить до 11 базовых показателей в одном плане. Эти множественные базовые уровни кажутся противоречащими определению базового уровня. Вы можете использовать эту гибкость, когда –

У вас есть базовый план для внешнего клиента и другой для внутренней команды.

Вы готовитесь к риску. Вы хотите разработать отдельные базовые планы реагирования на риски и восстановления.

Вы принимаете большой запрос на изменение, но при общении с заинтересованным лицом вы все равно можете сохранить первоначальный план для дальнейшего использования.

У вас есть базовый план для внешнего клиента и другой для внутренней команды.

Вы готовитесь к риску. Вы хотите разработать отдельные базовые планы реагирования на риски и восстановления.

Создать базовый уровень

Просмотр базовой линии на диаграмме Ганта

Вы увидите базовые столбцы Ганта, отображаемые вместе с текущими столбцами Ганта.

Обновить базовый уровень

По мере того, как время и работа над проектом продвигаются, вам, возможно, придется изменить и базовую линию. У вас есть несколько вариантов для одного и того же –

Обновите базовый уровень.
Обновите базовый уровень для выбранных задач.
Сохранить несколько базовых показателей.

Обновление базовой линии для всего проекта

Это просто заменяет исходные базовые значения на текущие запланированные значения.

Обновить базовый уровень для выбранных задач

Это не влияет на базовые значения для других задач или базовые значения ресурсов в плане.

Сохранить несколько базовых линий

Вы можете сохранить до 11 базовых показателей в одном плане. Первый называется Baseline, а остальные – от Baseline 1 до Baseline 10.

Промежуточные планы

Промежуточный план сохраняет только два вида информации для каждой задачи – текущие даты начала и текущие даты окончания.

Может использоваться как маркер проекта. Визуально легко увидеть, насколько продвигается или отслеживается ход проекта. Поскольку в нем указаны только даты, это простая, понятная и легкая информация.

План отслеживания на определенную дату

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

Галочки появятся в столбце индикаторов для задач, которые были выполнены. Справа в части диаграммы отображаются индикаторы выполнения в барах Ганта каждой задачи.

План трека как% выполнено

Способ 1

Способ 2

Теперь для требуемой задачи щелкните соответствующий столбец % Comp и введите требуемый% завершения.

План трека по фактическим значениям

Вы можете ввести следующие фактические значения для вашего проекта –

Фактические даты начала и окончания – Project соответствующим образом перемещает график.

Фактическая продолжительность задачи – если она равна или превышает длительность расписания: задача = 100% выполнено.

Фактические даты начала и окончания – Project соответствующим образом перемещает график.

Фактическая продолжительность задачи

Вы увидите% W. Comp. (% работа выполнена).

Эта таблица включает столбцы Работа (Запланированная работа), Фактическая и Оставшаяся.

Нажмите на задачу, которую вы хотите обновить. В следующем примере щелкается поле Actual задачи 9 и вводится 24 часа. Для этой задачи начальная запланированная работа была 16 часов, потому что 24 часа больше. Проект помечает задачу как выполненную на 100% и обновляет столбец «Работа» до 24 часов (с начальных 16 часов). В этом примере базовая линия сохраняется, поскольку базовая линия не изменяется и используется в качестве сравнения. Базовая линия по-прежнему составляет 16 часов, а дисперсия в 8 часов теперь рассчитывается MS Project.

Примечание. Фактическая работа свернута и также отражена в итоговой задаче.

Между задачами могут быть зависимости, в которых время начала или завершения выполнения одной задачи зависит от времени начала либо завершения другой. Задача, которая находится в зависимости от другой задачи, называется задачей-последователем ; задача, от которой зависит задача-последователь, называется задачей- предшественником.

При связывании задач (создании зависимости), MS Project автоматически рассчитывает сроки начала и завершения задачи-последователя, основываясь на сроках начала или завершения задачи-предшественника.

Типы связей между задачами в MS Project

Как связать задачи

В выделите (применяя клавишу Ctrl) две или более задач, которые хотите связать.

Выполнить команды Задача – Планирование - Связать выделенные задачи

(Нельзя связать между собой фазу и входящую в нее задачу).

Свяжем Вариантом 1 задачи 2 Закупить стройматериалы и 3.1 Построить фундамент

Время начала задачи 3.1 Построить фундамент автоматически сдвинулось.

По умолчанию MS Project создает связи типа Окончание-начало (ОН). Этот порядок можно впоследствии изменить.

Перейдите в представление Диаграмма Ганта

Мышкой наедьте на графическое изображение задачи предшественника, чтобы появилось изображение в виде крестика,

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

Создалась связь Окончание – Начало от задачи в строке 4 до задачи в строке 5. Задача 3.2 будет начинаться после завершения задачи 3.1

Для задачи последователя в столбце Предшественники можно указать номера строк задач предшественников (через точку с запятой, если предшественников несколько).

Свяжите задачу 3.3 Залить траншею с задачей 3.2 Подготовить бетон , поставив в столбце Предшественники задачи 3.3 номер строки 5 .

Задача 3.3 будет начинаться после завершения задачи 3.2

Сделать два щелчка мыши по задаче последователю – откроется окно Сведение о задаче, выбрать вкладку Предшественники. В столбце Название задачи выделить строку, щелчком мыши по треугольнику острием вниз открыть список задач, выбрать из списка задачу предшественника.

Если задач предшественников несколько, следующую задачу предшественника выбрать в другой строке столбца Название задачи

Для задачи 4 Фундамент готов выбрать предшественником задачу 3.3 Залить траншею

Установите связи между другими задачами нашего проекта. Приведите проект к виду.

Изменение типа связей между задачами

Чтобы изменить тип связи между задачами

Вариант 1 . Перейдите в представление Диаграмма Ганта

Дважды щелкните мышью на линии связи между задачами

В появившемся окне Зависимость задач укажите требуемый тип связи.

Нажмите OK

Вариант 2. Выделить задачу-последователь. Открыть окно Сведения о задаче – Предшественники, щелкая по строкам в столбце Название задачи, выбрать нужную задачу-предшественника, в столбце Тип выбрать нужный тип связи.

Между задачами 1 Геодезические работы и 2 Закупить стройматериалы смените связь Окончание – Начало на Начало - Начало

Чтобы удалить связь между двумя задачами:

Выделите задачи, между которыми Вы хотите удалить связь

Выполните команды Задача- Планирование – Разорвать связи задач

Дважды щелкните на линии связи между задачами

В появившемся окне Зависимость задач нажмите кнопку Удалить .

Открыть окно Сведения о задаче – Предшественники, щелкая по строкам в столбце Название задачи, выбрать нужную задачу-предшественника, в столбце Тип выбрать вариант Нет .

Опережения (перекрытия) и запаздывания (задержки) между задачами

Для задач, имеющих связи, можно задавать опережение и запаздывание между ними.

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

Для того чтобы указать время запаздывания или время опережения:

Перейдите в представление Диаграмма Ганта

Вызовите окно Зависимость задач , дважды щелкнув на линии связи между задачами

В поле Запаздывание укажите время запаздывания как положительное число и время опережения как отрицательное число.

Вы можете указать время запаздывания и время опережения, используя как единицы времени (минуты, часы, дни и т.д.), так и процент длительности задачи-предшественника.

Опережение и запаздывание можно задавать при помощи окна Сведения о задаче .

Перейдите в представление Диаграмма Ганта

Выделите задачу - последователь

Откройте окно Сведения о задаче – Предшественники

В поле Запаздывание введите положительное или отрицательное число

Нажмите OK

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

Время задержки создает задержку между двумя взаимозависимыми задачами. Например, если вам нужна 2-дневная задержка между окончанием первой задачи и началом второй, создайте зависимость "окончание-начало" между двумя задачами, а затем добавьте время задержки 2 дня.

Проделаем упражнения на опережение и запаздывание для задач 2 Закупить стройматериалы и 3.1 Выкопать траншею.

Запланируем чтобы задача 3.1 начиналась за один рабочий день до окончания задачи 2

А теперь запланируем чтобы задача 3.1 начиналась через один рабочий день после окончания задачи 2

Восстановим нулевое запаздывание для задач 2 Закупить стройматериалы и 3.1 Выкопать траншею .

Приведем файл Стройка 2 к виду

Сохраним файл Стройка 2

Конец Части 3.1. Связи между задачами. Опережение и запаздывание между задачами.

Продолжение Урока 3 на следующей странице.

Урок 3. Связи между задачами. Ограничения задач. Часть 3.2. Ограничения задач.

Ставьте лайки. Подписывайтесь на канал. Делайте комментарии. Давайте оценки содержанию и качеству канала. Давайте советы и рекомендации, помогайте улучшить канал, сделать его более понятным и полезным. Обсуждайте содержание канала с коллегами по работе и учебе. Если что-то непонятно, задавайте вопросы.

Трудовые ресурсы – это возобновляемые ресурсы, которые включают людей, машины и оборудование, необходимые для исполнения задач проекта. Трудовые ресурсы затрачивают время (в единицах длительности) для выполнения задач и создают трудозатраты на задачу. Трудовые ресурсы характеризуется максимальным количеством единиц ресурса ( Макс. единиц ), доступным для одновременного использования в проекте. Под количеством единиц ресурса понимается количество рабочего времени ресурса. Например, если в проекте будет задействован один монтажник, то для соответствующего ресурса максимальное количество единиц ресурса будет равняться 100%. И на любую задачу(работу) проекта можно назначить не более оного монтажника. Если в проекте будет задействовано 2 монтажника максимальное количество единиц ресурса будет равняться 200% и т.п. Если же будет задействован только один монтажник, который сможет уделить проекту только половину своего рабочего времени, то для такого ресурса максимальное количество единиц ресурса будет равняться 50%.

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

Файл – Параметры – Расписание – Расписание – Показывать единицы назначений в виде: - процентов / числовых значений

Материальные ресурсы – это различные расходуемые не возобновляемые материалы, комплектующие и другие предметы потребления, используемые для выполнения задач проекта. При использовании материальных ресурсов в проекте затрачивается не рабочее время ресурса, а сам ресурс. Материальные ресурсы характеризуются единицей измерения количества ресурса ( Единицы измерения материалов ), например, шт. , м3 и т.п. Для материального ресурса нельзя указать его максимальное количество.

Затраты – различные затраты, обычно фиксированные, например: субподрядчики, командировочные расходы, аренда площадей и т.п.

Работа со списком ресурсов

Для большего удобства работы можно создавать группы ресурсов. Объединение ресурсов также делает более удобным составление отчетов.

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

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

Настройка рабочего графика ресурсов

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

Я хочу поделиться своим опытом использования MS Project для управления проектами по разработке программного обеспечения. Я уже лет 10 занимаюсь управлением проектами,
и в результате у меня родилась некоторая методология использования MS Project, которая позволяет получить от него немалую пользу и при этом меньше зависеть от его недостатков.

Небольшое введение

Вся методология — это просто набор простых методов и рекомендаций по использованию MS Project для решения прикладных задач руководителя проекта. Сразу оговорюсь, что методология не претендует на универсальность, и применима только при некоторых ограничениях, которые я буду упоминать по ходу повествования.

Для начала, давайте вспомним, что обычно требуется от руководителя проекта. Для опытных руководителей это очевидно, а начинающим (или только собирающимся стать руководителями) будет полезно лишний раз вспомнить. Итак, проект по разработке программного обеспечения — это создание некоторое уникального продукта. На разных этапах жизненного цикла проекта от РП требуется решать различные задачи.

Перед началом проекта

сколько проект займет времени
сколько проект будет стоить

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

В процессе выполнения проекта

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

При завершении проекта

При завершении проекта руководитель обычно оглядывается назад и подводит итоги проекта. Чаще всего требуется оценить насколько проект выбился из плановых графиков и почему это произошло.

Что умеет MS Project

Несмотря на внешнюю сложность, MS Project очень прост в идейном плане. Он оперирует тремя сущностями — задачи, ресурсы, календарь и связи между ними. По сути — это база данных, пользовательский интерфейс для создания и редактирования сущностей и минимальная, довольно простая автоматизация (то, что Project делает сам, в ответ на введенные данные).

Разберем вкратце свойства сущностей.

Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои — этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).

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

На основе этих данных Project умеет делать различные представления с использованием
фильтров, группировок, сортировок и т.п. Кроме этого он умеет по некоторому алгоритму
вычислять сроки начала и окончания задач с учетом доступности назначенных ресурсов
и связей между задачами. Вот, собственно, и почти все что он умеет.
Давайте посмотрим, какую пользу можно из этого извлечь

Как это использовать

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

Подготовка плана

Сколько времени займет этот проект?
Сколько (и каких) специалистов для этого потребуется?
Какие примерно трудозатраты ожидаются по этому проекту?

Готовим список задач
Выставляем зависимости между задачами
(результат какой задачи необходим для перехода к следующей?).
Назначаем исполнителей задач
Выравниваем загрузку ресурсов
Балансируем то, что получилось

Общие рекомендации

Не используем суммарные задачи для декомпозиции.
Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
используем настраиваемые поля (см.ниже).
Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
Срок каждой задачи не должен превышать двух недель.
Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача — 2 дня, средней
сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны — а какая из них точная? По опытку практического применения могу сказать, что на
больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки.
Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.

Балансировка проекта

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

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

Группировка задач по исполнителям

Примечание. Теоретически, для оценки загрузки полагается использовать графики
загрузки пользователей. Эти графики хороши (наверное) для начальства, когда они
оценивают готовый проект. Но они непригодны на этапе создания плана, так как показывают
что все плохо, но совершенно не дают информации почему это так и что можно сделать.

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

Учет рисков

Теперь — последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.

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

Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
достоверности.
Оценить примерные трудозатраты по проекту

Работа с планом

Выдавать задания исполнителями
Отмечать выполненные задания в плане
Корректировать план в случае значительных отклонений

Отслеживание выполнения с группировкой по компонентам

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

Есть другая стратегия — внесение изменений в сроки задач, «выталкивая» невыполненные задачи вперед. При таком подходе для отслеживания отклонений от плана можно использовать другую полезную функцию MS Project — базовый план. Базовый план — это просто сохраненный снимок состояния задач. Его можно сделать в начале проекта. Для сравнения текущего плана с базовым, открываем «диаграмму Ганта с отслеживанием». Для динамичного плана, когда порядок выполнения задач часто меняется, это может оказаться неудобным, поэтому я вставляю в проект контрольные точки, отражающие некоторые важные результаты проекта, и отслеживать отклонения от базового плана только для них.

Диаграмма Ганта с отслеживанием

Управление структурой задач с помощью пользовательских полей

Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля. MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.

Создание пользовательского поля

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

Группировка задач по компонентам
Пользовательские поля позволяют разделять задачи по нескольким категориям, например, я разделял задачи по типу работ: Разработка, Тестирование, Документирование.
Упомяну для любопытных, что в MS Project также можно задать правила рисования диаграмм на основе свойств задач. При желании, можно сделать так, что задачи по разным компонентам будут иметь разные цвета, причем цвет будет определяться только свойством задачи, его не нужно задавать вручную для каждой задачи. Такие настройки не требуют написания сриптов, а делаются штатными средствами настройки диаграмм.

Использование пользовательских полей, а также встроенные в MS Project функции фильтрации, сортировки и группировки задач позволяют получить самые разные представления, которые позволяют получить ответы на многие вопросы, которые возникают у руководителя проекта.

Завершение проекта

В конце проекта мы получаем план, в котором все задачи выполнены. Обычно я стараюсь сохранять также и исходный план, хотя бы в качестве базового. Честно говоря, на этом этапе от MS Project мало проку, так как интересуют не плановые значения, а фактические. Какие-то решения этой проблемы предлагает MS Project Server, там есть возможность учитывать фактические трудозатраты, но это уже за пределами данной статьи.

Заключение

Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно — постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.

Читайте также: