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

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

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

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

Оглавление

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

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

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

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

5. Примечания.

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

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

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

• Взаимодействие с заказчиком
  С точки зрения проектного менеджмента вам регулярно придется встречаться с заказчиком для обсуждения текущего прогресса в проекте. А с точки зрения продуктового менеджмента вам придется выслушивать и нормализовывать пожелания заказчика – об этом подробно поговорим позже.

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

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

• Контроль качества и очередности выполнения задач
  В этом вам поможет качественно составленное техническое задание, в котором прописаны правила приема выполненных работ.

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

• Инициация и проведение планерок и совещаний с участниками команды
  Так называемые дейлики очень важны, даже если ваша команда сообщает вам, что все идет по плану. Вы должны иметь релевантный список вопросов к каждой встречи. Тут вам в помощь грамотно настроенный в начале спринта трекер задач. Главная задача на таких встречах – подметить нюансы разработки, которые требуют взаимодействия между разработчиками разных типов, например Frontend и Backend.

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

• Анализ и разрешение спорных ситуаций между заказчиком и членами команды
  Не всегда, но иногда бывают ситуации, когда необходимо убрать барьер между заказчиком и разработкой или аналитикой для оперативного уточнения нюансов. На самом деле – это плохо, очень плохо. Избежать этого помогает качественно составленное ТЗ. Главная задача проектного менеджера в таких ситуациях – установить формат встречи, проконтролировать поведение обеих сторон. Помните, главная цель такого взаимодействия – информативное общение, получение полезной обратной связи.

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

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

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

А также:

• Своевременное реагирование на вопросы клиента

• Готовит и ведет презентации проектов

• Контролирует качество работы

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

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

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

1. Встреча с заказчиком. Знакомство.

   1. Установить доброжелательные взаимоотношения.

   2. Понять боли бизнеса, определить его потребности.

   3. Завершить общение, определив дальнейшую дату обратной связи

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

2. Внутренняя работа. Составление коммерческого предложения.

   1. Сообщить об итогах встречи руководителю.

   2. Доработать идею: определить функционал, приблизительные сроки, приблизительный бюджет.

   3. Согласовать проведенную работу с руководителем, а далее – с проектной командой.

   4. Составить коммерческое предложение (КП).

   5. Согласовать КП с руководителем.

3. Встреча с заказчиком. Предоставление обратной связи.

   1. Выслать КП заказчику.

   2. В случае радикальных корректировок/недовольства со стороны заказчика связаться с руководителем для уточнения вопросов.

   3. Внести коррективы.

   4. Выслать КП заказчику.

   5. Получить положительную обратную связь.

   6. Назначить встречу для детализации решения. К этой встрече необходимо будет подготовить шаблон ТЗ.

4. Внутренняя работа. Подготовка шаблона ТЗ.
   

   1. Детализировать функционал.

   2. Согласовать с проектной командой сроки и зарплату.

   3. Определить конечную стоимость проекта.

   4. Согласовать с руководителем.

5. Встреча с заказчиком. Детализация требований.
   

   1. Детализировать конечный функционал

   2. Назначить дату обратной связи.

6. Внутренняя работа. Составление ТЗ.
   

   1. Составить ТЗ.

   2. Согласовать с проектной командой.

   3. Определить условия оплаты.

   4. Согласовать с руководителем.

   5. Выслать ТЗ заказчику и назначить дату встречи.

7. Встреча с заказчиком. Согласование ТЗ.
   

   1. Согласовать ТЗ, сроки, условия оплаты.

8. Дальнейшая работа:
   

   1. Получить оплату.

   2. Разработать дизайн макеты.

   3. Согласовать дизайн макеты с заказчиком.

   4. При необходимости скорректировать ТЗ для разработчиков. Связаться с руководителем в случае радикальных изменений.

   5. Передать в разработку.

   6. Получать оплату по установленным условиям.

   7. Отчитываться перед заказчиком для поддержания доверительных отношений.     

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

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

1. Согласовать ТЗ, сроки разработки.

2. Согласовать условия закрытия этапов / приема работ.

3. Согласовать фиксированную предоплату каждого этапа.

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

1. Разработка начинается после получения предоплаты за этап.

2. Оплата работы специалистов производится после закрытия этапа.

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

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

1. Оплата дизайнера.

2. Оплата этапов разработки.

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

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

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

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

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

1. Процесс состоит из 3х массивных этапов:

   1. Определение задач на спринт.

   2. Составление КП.

   3. Составление ТЗ.

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

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

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

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

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

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

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

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

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

Примечания

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

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