Разбор ситуации(кейса) 1 для ПМа. Начало проекта.

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

Финансовая компания наняла тебя РМом на проект. Проект на стадии идеи. Хочет сделать мобильное приложение по типу банковского (домен финтех), например по выдаче микрокредитов физ и юр лицам.
Необходимо:
— Сделать анализ стоит ли покупать/самим разрабатывать, а также своя команда или аутсорсить. Расписать плюсы, минусы, риски, альтернативы.
— Для рекомендованного варианта просчитать план реализации. Учесть сбор требований, архитектуру, интеграции, контрактинг, тестирование, разбить на несколько этапов с указанием функциональности для пользователя. Составить календарный план проекта. В идеале в майкрософт проджекте или его аналоге)

Итак, по порядку.

Выбор решения

Чтобы принять решение покупать или самим разрабатывать необходимо собрать информацию о стоимости первого и второго.
В любом случае придется начать с финансово-экономического (технико-экономического) обоснования проекта: что за проект мы собираемся делать, какую цель хотим достичь и какую выгоду планируем получить. С этого начинается сбор требований. На основании этой информации создаем бриф проекта, в котором описываем необходимый функционал в общем виде.

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

Аналогично тот же самый бриф (в английском его называют RFI — Request for information) мы отправляем потенциальным компаниям аутсорсерам, чтобы получить от них примерную стоимость разработки персонализированного решения.

Сравнивая полученные данные мы можем принять решение по вопросу «стоит ли покупать/самим разрабатывать». Надо учитывать тут некоторые нюансы, например, что готовое решение мы начнем использовать намного раньше и, следовательно, получим экономическую выгоду от него. То есть надо отнять от стоимости готового решения прибыль, полученную до момента, когда персональное решение возможно будет начать использовать и только тогда сравнивать. Так же стоит учесть насколько нас удовлетворяет готовое решение по таким параметрам как полнота, поддержка, возможность допилить или доработать под себя, безопасность и так далее. Это же будет отражено в рисках, о них чуть позже. Заодно это будет в списке плюсов-минусов.

Плюсы-минусы

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

— сложность кастомизации или её полное отсутствие
— функционал не на 100% совпадает с желаемым, даже может быть слишком избыточным
— невозможность быстро подстроиться под обратную связь от пользователей

писать самим:
1. аутсорсить
+ возможность разработать решение максимально удовлетворяющее целям и задачам
+ возможность вносить изменения в процессе разработки
+ возможность разбить на этапы и получать обратную связь быстро
+ риски команды на стороне исполнителя
— риски выбора некомпетентного исполнителя

— время запуска сложно спрогнозировать
— финальная стоимость известна очень приблизительно
— потери времени на более долгой коммуникации с удаленной командой

2. своя команда:
+ максимально быстрая коммуникация внутри команды
+ прозрачный контроль работы и бюджета
+ возможность разработать решение максимально удовлетворяющее целям и задачам
+ возможность вносить изменения в процессе разработки
+ возможность разбить на этапы и получать обратную связь быстро

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

План реализации

Какие работы надо учесть в плане:

  • сбор требований
  • непосредственная разработка
  • стабилизация
  • тестирование
  • менеджмент
  • коммуникации (внутрикомандная, отчеты, обсуждение со стейкхолдерами)
  • риски
  • настройка окружения (рабочего, тестового, продуктового)
  • время на релиз и его проверку
  • дизайн (если он нужен)
  • прохождение проверки в appstore и google play (если мобильное приложение)
  • разработка документации: технической и руководство пользователя. (если необходимо)
  • обучение конечных пользователей (если необходимо)
  • финальная приемка и завершение проекта

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

Способов оценки проекта существует много, как простые: экспертная оценка, по историческим данным, так и сложные индустриальные, например FPA IFPUG — метод функциональных точек.
Я подробно рассказывал о методах оценки в своем посте «Несколько тезисов об оценке трудоемкости»
Чтобы оценить трудоемкость большинством способов (если это не грубая ballpark оценка с высокой погрешностью) понадобится составить ИСР — иерархическую структуру работ (в английском WBS — work breakdown structure), где все работы проекта будут отражены в виде иерархии согласно их взаимосвязи. Наверху иерархии — крупные пакеты работ, внизу — их декомпозиция на мелкие пакеты. Каждый из пакетов оценивается, их сумма будет являться оценкой всего проекта.

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

Календарный план (MS Project)

Ниже я привожу пример MS Project плана проекта на разработку (для кейса будет отличаться только структура работ).

Вот скриншот из файла для тех, у кого не установлен MS Project. (кликните чтобы увидеть в оригинальном большом размере)

вот ещё скриншот примера плана реального проекта:
(кликните чтобы увидеть в оригинальном большом размере)

Итоговый расчет

2300 часов всего проекта будут выполнены примерно за 5-6 месяцев и стоимость составит около 60к$ при рейтах за команду — менеджер, бизнес-аналитик, тестировщик, 2 разработчика.

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

Дополнительное чтение

Напоследок, список ресурсов для дополнительного чтения на тему начала проекта: