Разбор ситуации(кейса) 1 для ПМа. Начало проекта.
Мне неоднократно поступала обратная связь сделать разборы примеров типовых ситуаций (кейсов) для менеджера проектов. Обсудим первый такой кейс: что делать и какие инструменты использовать.
Условие кейса
Финансовая компания наняла тебя РМом на проект. Проект на стадии идеи. Мобильное приложение по типу банковского (домен финтех), например по выдаче микрокредитов физ и юр лицам.
Необходимо:
— Сделать анализ стоит покупать или самим разрабатывать, а также своя команда или аутсорсить. Расписать плюсы, минусы, риски, альтернативы.
— Для рекомендованного варианта просчитать план реализации. Учесть активности: сбор требований, архитектуру, интеграции, контрактинг, тестирование. Разбить на этапы с указанием какая функциональность для пользователя входит в каждый этап. Составить календарный план проекта. В идеале в форме ганнт чарта созданного с помощью MS Project или его аналога.
Итак, разбираем один из вариантов ответа, по порядку.
Решение
Чтобы решить покупать или самим разрабатывать надо для начала собрать информацию о стоимости первого и второго.
Надо начать с финансово-экономического (технико-экономического) обоснования проекта: что за проект собираемся делать, какую цель хотим достичь и какую выгоду планируем получить. С этого начинается сбор требований. На основании этой информации создаем бриф проекта, в котором описываем необходимый функционал в общем виде.
На основе брифа ищем в интернете подходящие по функционалу готовые решения и запрашиваем их полную стоимость (включая внедрение и обслуживание).
Аналогично тот же бриф мы отправляем выбранным подходящим компаниям аутсорсерам, чтобы получить от них ориентировочную стоимость разработки персонализированного решения. В английском языке такой запрос называется 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 разработчика.
Обратите внимание что в примере расчета нет буферов на риски и постоянные работы не на полный день, такие как менеджмент и тестирование на диаграмме ганнта не растянуты на длину критической цепи.
Дополнительное чтение
Напоследок, список ресурсов для дополнительного чтения на тему начала проекта:
- документы начала проекта, основанные на PMBoK
- экономическое обоснование it проекта — университетский курс
- короткое описание как составлять план в MS Project
Для отправки комментария необходимо войти на сайт.