Методичка по ведению проекта
Меня зовут Артем, я проектный менеджер студии разработки ПО — CORE. Мы разрабатываем с нуля программное обеспечение для бизнеса. В основном, мелкие CRM/ITSM-решения, которые предоставляют функционал, не реализованный крупными поставщиками ПО.
Данная статья будет полезна как начинающим проектным менеджерам, переходящим на уровень взаимодействия с заказчиком, так и руководителям проектов, желающим сравнить операционные процессы в своей организации с описанными ниже. Я же прошу читателя воспринимать эту статью, как «Методичку» или шаблон, который можно адаптировать под себя.
В связи с резким набором персонала возникла необходимость написать данную методичку по работе с заказчиками и техническими специалистами, чтобы стандартизировать и зафиксировать порядок существующих в студии процессов работы.
Оглавление
Должностные обязанности проектного менеджера.
Первая встреча с заказчиком.
Порядок оплаты работ.
Непрерывная разработка продукта.
Примечания.
Должностные обязанности проектного менеджера
В каждой организации должностные обязанности могут установлены по-разному. Данная же статья написана, через призму опыта и процессов студии CORE.
В список должностных обязанностей проектного менеджера входят:
Взаимодействие с заказчиком
С точки зрения проектного менеджмента вам регулярно придется встречаться с заказчиком для обсуждения текущего прогресса в проекте. А с точки зрения продуктового менеджмента вам придется выслушивать и нормализовывать пожелания заказчика — об этом подробно поговорим позже.Разработка стратегии проекта, внесение коррективов
Анализ текущих результатов проекта и выявление областей для улучшения, а также адаптация стратегий в зависимости от изменений в требованиях или условиях рынка.Распределение обязанностей между участниками команды, постановка дедлайнов
Определение ролей и задач для каждого члена команды, а также установление четких сроков выполнения, чтобы обеспечить эффективное сотрудничество и достижение целей проекта.Контроль качества и очередности выполнения задач
В этом вам поможет качественно составленное техническое задание, в котором прописаны правила приема выполненных работ.Обеспечение качественной коммуникации между клиентом и участниками команды проекта
Для этого пригодится документ «Отчетный лист», приложенный в файлах. В него записываются как ключевые события проекта (завершение этапа, изменение ТЗ, согласование ТЗ с заказчиком и т.п.), так и менее важные (завершение настройки сервера, завершение верстки главной страницы т.п.). По сути, вы ведете историю проекта, и делаете это для того, чтобы в случае возникновения вопросов, могли дать внятный ответ опираясь на лог событий.Инициация и проведение планерок и совещаний с участниками команды
Так называемые дейлики очень важны, даже если ваша команда сообщает вам, что все идет по плану. Вы должны иметь релевантный список вопросов к каждой встречи. Тут вам в помощь грамотно настроенный в начале спринта трекер задач. Главная задача на таких встречах — подметить нюансы разработки, которые требуют взаимодействия между разработчиками разных типов, например Frontend и Backend.Поиск дополнительных специалистов, инструментов и других ресурсов
Зависит от проекта. Порой бывают ситуации, когда срочно нужно найти дополнительного специалиста для делегирования задачи, на которой у вашей main-команды либо не хватает времени, либо не хватает компетенций. В этом ничего страшного нет. Ваша задача — грамотно составить техническое задание, согласовать его с разработкой и отправиться на поиски исполнителя.Анализ и разрешение спорных ситуаций между заказчиком и членами команды
Не всегда, но иногда бывают ситуации, когда необходимо убрать барьер между заказчиком и разработкой или аналитикой для оперативного уточнения нюансов. На самом деле — это плохо, очень плохо. Избежать этого помогает качественно составленное ТЗ. Главная задача проектного менеджера в таких ситуациях — установить формат встречи, проконтролировать поведение обеих сторон. Помните, главная цель такого взаимодействия — информативное общение, получение полезной обратной связи.Будьте внимательны, на таких встречах заказчик может пытаться «пропихнуть» идеи и вытекающие из них задачи, не входящие в оговоренный план работать. При отклонениях от ТЗ смело говорите об этом. Если этого не делать, риски начнут расти, как на дрожжах, и виноваты в этом будете уже вы.
Анализ рентабельности разрабатываемого решения
Возьмите на себя роль менеджера продукта и проанализируйте, в каком приоритете лучше внедрять технологии из беклога. При планировании спринта со стороны заказчика может поступать много пожеланий, и ваша задач определить, в каком порядке лучше вести разработку.Плохим примером является разработка конструктора заказов по продаже и монтажу быстровозводимых домов, если у вас еще не реализована система учета типов стен, крыш, креплений и прочих других видов услуг/материалов/технологий, необходимых для корректного просчета конечной стоимости заказа.
А также:
Своевременное реагирование на вопросы клиента
Готовит и ведет презентации проектов
Контролирует качество работы
Первая встреча с заказчиком
На подобных встречах вы, как правило, не будете одни, с вами будет либо руководитель, либо продажник, которые помогут раскрутить идею заказчика, сразу установят рамки по разработке и помогут в будущем развивать продукт. Но что, если вы оказались одни в лесу, к вам подходит ваш будущий клиент и говорит: «Хочу CRM»?
Порядок работы:
Встреча с заказчиком. Знакомство.
Установить доброжелательные взаимоотношения.
Понять боли бизнеса, определить его потребности.
Завершить общение, определив дальнейшую дату обратной связи
Больше слушаем, чем говорим. Ставим перед собой задачу — получить максимум информации о желаемом продукте
Внутренняя работа. Составление коммерческого предложения.
Сообщить об итогах встречи руководителю.
Доработать идею: определить функционал, приблизительные сроки, приблизительный бюджет.
Согласовать проведенную работу с руководителем, а далее — с проектной командой.
Составить коммерческое предложение (КП).
Согласовать КП с руководителем.
Встреча с заказчиком. Предоставление обратной связи.
Выслать КП заказчику.
В случае радикальных корректировок/недовольства со стороны заказчика связаться с руководителем для уточнения вопросов.
Внести коррективы.
Выслать КП заказчику.
Получить положительную обратную связь.
Назначить встречу для детализации решения. К этой встрече необходимо будет подготовить шаблон ТЗ.
Внутренняя работа. Подготовка шаблона ТЗ.
Детализировать функционал.
Согласовать с проектной командой сроки и зарплату.
Определить конечную стоимость проекта.
Согласовать с руководителем.
Встреча с заказчиком. Детализация требований.
Детализировать конечный функционал
Назначить дату обратной связи.
Внутренняя работа. Составление ТЗ.
Составить ТЗ.
Согласовать с проектной командой.
Определить условия оплаты.
Согласовать с руководителем.
Выслать ТЗ заказчику и назначить дату встречи.
Встреча с заказчиком. Согласование ТЗ.
Согласовать ТЗ, сроки, условия оплаты.
Дальнейшая работа:
Получить оплату.
Разработать дизайн макеты.
Согласовать дизайн макеты с заказчиком.
При необходимости скорректировать ТЗ для разработчиков. Связаться с руководителем в случае радикальных изменений.
Передать в разработку.
Получать оплату по установленным условиям.
Отчитываться перед заказчиком для поддержания доверительных отношений.
Порядок оплаты работ
Порядок установления оплаты работ с заказчиком:
Согласовать ТЗ, сроки разработки.
Согласовать условия закрытия этапов / приема работ.
Согласовать фиксированную предоплату каждого этапа.
Порядок оплаты работ:
Разработка начинается после получения предоплаты за этап.
Оплата работы специалистов производится после закрытия этапа.
Оплата работы проектного менеджера и услуг студии производится после закрытия последнего этапа.
Приоритет оплаты (по убыванию):
Оплата дизайнера.
Оплата этапов разработки.
Оплата работы проектного менеджера и услуг студии.
В данном примере описан минимальный состав проектной команды. В более крупных проектах состав может быть гораздо разнообразнее. В таких случаях приоритет оплаты устанавливается относительно включаемых в работу кадров.
Непрерывная разработка продукта
Важным аспектом непрерывной разработки со стороны студии является своевременное взаимодействие с заказчиком для обсуждения задач нового спринта. Такой подход очень похож на Agile, но имеет свои особенности. Рассмотрим условия, когда студия получает доход от спринтов, через такую призму мы и будем рассматривать процесс разработки. В большинстве организациях вы не заметите данной практики. Тем не менее, описываемые ниже процессы легко адаптируются под ваши нужды.
Схема непрерывной разработки продукта при необходимости согласовывать каждый спринт и получать за него оплату.
Примечания к графику:
Процесс состоит из 3х массивных этапов:
Определение задач на спринт.
Составление КП.
Составление ТЗ.
Составление КП можно пропустить. Однако, оно пригодится, если в лице заказчика стоит проектный менеджер, с которым вы спокойно согласовываете сроки и стоимость, а за ним уже совет директоров, которым важно понимать детальную стоимость разработки, сроки этапов, финальные сроки. Составление КП для стейкхолдеров является частой практикой, поэтому я не смог удержаться не отобразить этот на иллюстрации.
Полезные документы
Все документы доступны по ссылке:
Шаблон коммерческого предложения для первой встречи.
Шаблон коммерческого предложения для формирования спринтов.
Разница «КП для формирования спринта» от «КП для первой встречи» в том, что первое не несет в себе цели познакомить клиента с деятельностью организации, вызвать доверие или продемонстрировать какой-либо опыт. Главная цель такого документа — продемонстрировать именно финансы, сроки, внедряемые технологии, этапы оплат и примечания, касающиеся будущего спринта.
Диаграмма Ганта — важный инструментов при планировании проекта. С ее помощью можно легко отследить, сколько времени будет затрачено на проект, визуально отобразить резервные дни, зафиксировать процессы, которые могут идти параллельно. А если упростить диаграмму Ганта, то ее можно и вложить в коммерческое предложение, таким образом повысить шансы на положительный итог.
Шаблон диаграммы Ганта в excel
Баг форма. Обязательна, если система, которую вы разрабатываете, может находиться в разных состояниях и также может иметь разное поведение. В таких случаях для устранения багов и корректировки используется баг форма. Её истинное предназначение — воспроизведение того поведения системы, с которым столкнулся пользователь, нашедший неполадки.
Шаблон баг формы в word
Отчетный лист. В разделе «Должностные обязанности» уже описано назначение данного документа. Добавлю, в случаях, когда заказчик ставит очень много встреч для уточнения логики работы, просит переделать ТЗ, отправляет документы, влияющие на скорость разработки — проект может затянуться. С помощью отчетного листа вы с легкостью можете отчитаться перед заказчиком и обосновать изменения в планах.
Шаблон отчетного листа в word
Примечания
В большинстве случаев роль заказчика на себя берет проектный менеджер со стороны клиента. Порядок работы от этого не меняется. Большинство наших кейсов именно такие.
Конечно, я привел все не документы необходимые проектному менеджеру. В данной статье мы рассмотрели работу ПМа больше с уклоном в контроль финансов.
