Методичка по ведению проекта

Меня зовут Артем, я проектный менеджер студии разработки ПО – CORE. Мы разрабатываем с нуля программное обеспечение для бизнеса. В основном, мелкие CRM/ITSM-решения, которые предоставляют функционал, не реализованный крупными поставщиками ПО.

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

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

Должностные обязанности проектного менеджера

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

В список должностных обязанностей проектного менеджера входят:

Взаимодействие с заказчиком
С точки зрения проектного менеджмента вам регулярно придется встречаться с заказчиком для обсуждения текущего прогресса в проекте. А с точки зрения продуктового менеджмента вам придется выслушивать и нормализовывать пожелания заказчика – об этом подробно поговорим позже.
Разработка стратегии проекта, внесение коррективов
Анализ текущих результатов проекта и выявление областей для улучшения, а также адаптация стратегий в зависимости от изменений в требованиях или условиях рынка.
Распределение обязанностей между участниками команды, постановка дедлайнов
Определение ролей и задач для каждого члена команды, а также установление четких сроков выполнения, чтобы обеспечить эффективное сотрудничество и достижение целей проекта.
Контроль качества и очередности выполнения задач
В этом вам поможет качественно составленное техническое задание, в котором прописаны правила приема выполненных работ.
Обеспечение качественной коммуникации между клиентом и участниками команды проекта
Для этого пригодится документ «Отчетный лист», приложенный в файлах. В него записываются как ключевые события проекта (завершение этапа, изменение ТЗ, согласование ТЗ с заказчиком и т.п.), так и менее важные (завершение настройки сервера, завершение верстки главной страницы т.п.). По сути, вы ведете историю проекта, и делаете это для того, чтобы в случае возникновения вопросов, могли дать внятный ответ опираясь на лог событий.
Инициация и проведение планерок и совещаний с участниками команды
Так называемые дейлики очень важны, даже если ваша команда сообщает вам, что все идет по плану. Вы должны иметь релевантный список вопросов к каждой встречи. Тут вам в помощь грамотно настроенный в начале спринта трекер задач. Главная задача на таких встречах – подметить нюансы разработки, которые требуют взаимодействия между разработчиками разных типов, например Frontend и Backend.
Поиск дополнительных специалистов, инструментов и других ресурсов
Зависит от проекта. Порой бывают ситуации, когда срочно нужно найти дополнительного специалиста для делегирования задачи, на которой у вашей main-команды либо не хватает времени, либо не хватает компетенций. В этом ничего страшного нет. Ваша задача – грамотно составить техническое задание, согласовать его с разработкой и отправиться на поиски исполнителя.
Анализ и разрешение спорных ситуаций между заказчиком и членами команды
Не всегда, но иногда бывают ситуации, когда необходимо убрать барьер между заказчиком и разработкой или аналитикой для оперативного уточнения нюансов. На самом деле – это плохо, очень плохо. Избежать этого помогает качественно составленное ТЗ. Главная задача проектного менеджера в таких ситуациях – установить формат встречи, проконтролировать поведение обеих сторон. Помните, главная цель такого взаимодействия – информативное общение, получение полезной обратной связи.

Будьте внимательны, на таких встречах заказчик может пытаться “пропихнуть” идеи и вытекающие из них задачи, не входящие в оговоренный план работать. При отклонениях от ТЗ смело говорите об этом. Если этого не делать, риски начнут расти, как на дрожжах, и виноваты в этом будете уже вы.
Анализ рентабельности разрабатываемого решения
Возьмите на себя роль менеджера продукта и проанализируйте, в каком приоритете лучше внедрять технологии из беклога. При планировании спринта со стороны заказчика может поступать много пожеланий, и ваша задач определить, в каком порядке лучше вести разработку.

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

А также:

Своевременное реагирование на вопросы клиента
Готовит и ведет презентации проектов
Контролирует качество работы

Первая встреча с заказчиком

На подобных встречах вы, как правило, не будете одни, с вами будет либо руководитель, либо продажник, которые помогут раскрутить идею заказчика, сразу установят рамки по разработке и помогут в будущем развивать продукт. Но что, если вы оказались одни в лесу, к вам подходит ваш будущий клиент и говорит: «Хочу CRM»?

Порядок работы:

Встреча с заказчиком. Знакомство.
1. Установить доброжелательные взаимоотношения.
2. Понять боли бизнеса, определить его потребности.
3. Завершить общение, определив дальнейшую дату обратной связи

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

Внутренняя работа. Составление коммерческого предложения.
1. Сообщить об итогах встречи руководителю.
2. Доработать идею: определить функционал, приблизительные сроки, приблизительный бюджет.
3. Согласовать проведенную работу с руководителем, а далее – с проектной командой.
4. Составить коммерческое предложение (КП).
5. Согласовать КП с руководителем.
Встреча с заказчиком. Предоставление обратной связи.
1. Выслать КП заказчику.
2. В случае радикальных корректировок/недовольства со стороны заказчика связаться с руководителем для уточнения вопросов.
3. Внести коррективы.
4. Выслать КП заказчику.
5. Получить положительную обратную связь.
6. Назначить встречу для детализации решения. К этой встрече необходимо будет подготовить шаблон ТЗ.
Внутренняя работа. Подготовка шаблона ТЗ.
1. Детализировать функционал.
2. Согласовать с проектной командой сроки и зарплату.
3. Определить конечную стоимость проекта.
4. Согласовать с руководителем.
Встреча с заказчиком. Детализация требований.
1. Детализировать конечный функционал
2. Назначить дату обратной связи.
Внутренняя работа. Составление ТЗ.
1. Составить ТЗ.
2. Согласовать с проектной командой.
3. Определить условия оплаты.
4. Согласовать с руководителем.
5. Выслать ТЗ заказчику и назначить дату встречи.
Встреча с заказчиком. Согласование ТЗ.
1. Согласовать ТЗ, сроки, условия оплаты.
Дальнейшая работа:
1. Получить оплату.
2. Разработать дизайн макеты.
3. Согласовать дизайн макеты с заказчиком.
4. При необходимости скорректировать ТЗ для разработчиков. Связаться с руководителем в случае радикальных изменений.
5. Передать в разработку.
6. Получать оплату по установленным условиям.
7. Отчитываться перед заказчиком для поддержания доверительных отношений.

Порядок оплаты работ

Порядок установления оплаты работ с заказчиком:

Согласовать ТЗ, сроки разработки.
Согласовать условия закрытия этапов / приема работ.
Согласовать фиксированную предоплату каждого этапа.

Порядок оплаты работ:

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

Приоритет оплаты (по убыванию):

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

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

Непрерывная разработка продукта

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

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

Примечания к графику:

Процесс состоит из 3х массивных этапов:
1. Определение задач на спринт.
2. Составление КП.
3. Составление ТЗ.
Составление КП можно пропустить. Однако, оно пригодится, если в лице заказчика стоит проектный менеджер, с которым вы спокойно согласовываете сроки и стоимость, а за ним уже совет директоров, которым важно понимать детальную стоимость разработки, сроки этапов, финальные сроки. Составление КП для стейкхолдеров является частой практикой, поэтому я не смог удержаться не отобразить этот на иллюстрации.

Полезные документы

Все документы доступны по ссылке:

Шаблон коммерческого предложения для первой встречи.
Шаблон коммерческого предложения для формирования спринтов.

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

Диаграмма Ганта — важный инструментов при планировании проекта. С ее помощью можно легко отследить, сколько времени будет затрачено на проект, визуально отобразить резервные дни, зафиксировать процессы, которые могут идти параллельно. А если упростить диаграмму Ганта, то ее можно и вложить в коммерческое предложение, таким образом повысить шансы на положительный итог.

Баг форма. Обязательна, если система, которую вы разрабатываете, может находиться в разных состояниях и также может иметь разное поведение. В таких случаях для устранения багов и корректировки используется баг форма. Её истинное предназначение – воспроизведение того поведения системы, с которым столкнулся пользователь, нашедший неполадки.

Отчетный лист. В разделе «Должностные обязанности» уже описано назначение данного документа. Добавлю, в случаях, когда заказчик ставит очень много встреч для уточнения логики работы, просит переделать ТЗ, отправляет документы, влияющие на скорость разработки – проект может затянуться. С помощью отчетного листа вы с легкостью можете отчитаться перед заказчиком и обосновать изменения в планах.

Примечания

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

ссылка на оригинал статьи https://habr.com/ru/articles/859174/