Проджект, который вывозит | Project Manager в IT

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

В прошлой статье мы считали бюджет. Теперь разберём Fixed Price и Time & Materials - две модели оплаты разработки, от которых зависит, что PM должен согласовать до начала работы и показывать заказчику по ходу проекта. Fixed Price, или фиксированная цена: стороны согласуют стоимость определённого объёма работ. Если исполнитель недооценил трудоёмкость этого объёма, дополнительные часы сами по себе не означают автоматическую доплату. Это базовая логика моделей. Конкретные правила: что считается оплачиваемым...

В прошлой статье мы разбирались с дополнительными правками. Теперь посмотрим, как они вместе с основной работой превращаются в расходы. Разберём на учебном примере: команда делает личный кабинет с заявками. Все суммы ниже условные - это пример расчёта, а не рыночные расценки. Заказчик заплатит за проект 800 тысяч рублей. Можно ли потратить на его выполнение все 800 тысяч? Из одной этой цифры ответ не следует. Есть цена для заказчика: сколько он платит. Есть затраты на выполнение: сколько обходятся команда, подрядчики и остальные ресурсы...

В прошлой статье мы разбирали риски. Теперь — ситуацию, когда новая работа уже появилась и нужно решить, что с ней делать. Управление изменениями в проекте начинается с паузы между «услышала просьбу» и «пообещала сделать». За эту паузу PM должен выяснить смысл запроса, проверить последствия и согласовать решение. Я бы не начинала разговор с «этого не было в ТЗ». Сначала стоит проверить, о чём мы вообще спорим. Разница важна: исправление недоработки нельзя автоматически объявлять дополнительной услугой...

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