Делюсь своими вариантами ответов на вопросы одной IT компании (правда сотрудничество с этой компанией не сложилось).

Кейс-вопросы для Project Manager’а

1. Кейс №1
Проект на поддержке. Поступает задача. Неважно какая. Разработчики дают оценку задаче, например, 10 часов. РМ согласовывает эту оценку с Заказчиком, задача идет в работу.
И тут РМ обнаруживает в трекере или каком-то подобном инструменте, что затрачено уже 14 часов, но задача еще не доделана.
Вопрос 1: какую оценку РМ называет Заказчику, если разработчик оценил задачу в 10ч

Ответ 1: Оценку заказчику нужно отправлять правдивую, исходя из ситуации:
Ситуация 1: Разработчик недооценил время на выполнение задачи (недостаточно опыта / либо не учтены риски / либо не учтено время на обучение/использование новых инструментов и т.д). В таком случае заказчику отправляется время 10ч, а на будущее РМ либо помогает разработчику с системой оценивания, либо заранее добавляет время на разработку.
Ситуация 2: Разработчик оценил все верно согласно поставленно задачи, но в процессе заказчик попросил принять во внимание еще один факт/дополнение/исключение, что повлияло на дополнительный обьем работ. В таком случае с заказчиком заранее (перед началом доработки) согласовывается доп. время и в отчете отправляется все согласованное количество часов: 10ч + Хч
Ситуация 3 : Разработчик оценил все верно согласно поставленно задачи, но в процессе выяснились технические несостыковки (импорт данных/ интеграция / сложность реализации какой-то части и т.д.). Тогда полное затраченное время оговаривается с руководством и принимается решение либо:1) отправить полное время с указанием причин, но взять деньги только за 10 ч (как скидку и ставку на дальнейшее сотрудичество), 2) отправить полное время с указанием причин, согласовать всю сумму и попросить оплатить, 3) отправить 10ч (если задача была реально сложная, разработчик ее делал впервые и результат может сыграть на автоматизацию процессов в будущем при работе с другими заказчиками компании).

Вопрос 2: какие причины такого поведения разработчика?

Причины:
1) Недостаточно опыта.
2) Не умеет оценивать/планировать время.
3) Оценка произведена не для эталонного сотрудника (например, миддла), а для себя лично (архитектора).
4) Оценка выполнена только на написание кода и не учтено время перепроверки/тестирования/внесения правок.
5) Личные проблемы, голова забита другими заботами, не разобрался в задаче до конца.
6) Не разобрался/не почитал задачу, а оценил ее по теме/заголовку исходя из похожей решенной задачи.
7) Другое…

Вопрос 3: какие действия РМа в данной ситуации?

1) Разобраться в причинах задержки.
2) На будущее – мониторить время выполнения задачи на пол-пути (через 5ч) или чаще в зависимости от масштабности проекта.
3) Уточнить у разработчика, сколько еще примерно времени нужно, чтобы доделать задачу.
4) Согласовать сдвиг сроков с заказчиком (если ждал сегодня-завтра выполнения).
5) Помочь разработчику с выполнением (возможно нужна консультация другого разработчика с другого проекта, а он лучше знает технологию, уже стыкался с такой проблемой).
6) Доделать задачу и отправить отчет.

2. Кейс №2
Проект в разработке. Релиз через 2 недели.
Сегодня по графику должен закончиться фронт-энд. Разработчик говорит, что еще день-два и все будет готово.
РМ дает этот день-два разработчику. Через два дня выясняется, что фронт-энд плох и нет еще половины работ. Разработчик переоценил свои силы.
РМ понимает, что уже мы вне графика, а релиз через 2 недели.
Как будет действовать РМ в этой ситуации?

Ответ:
1) Если сегодня по графику должен закончиться фронт-энд – попросить показать готовность (и выяснится половина работ сейчас, а не через 2 дня).
2) Поскольку Разработчик переоценил свои силы, то нужно все же доделать задачу побыстрее (попросить поработать на 2-3 часа дольше каждый день (без овертаймов на выходных)) и выполнить фронт-энд хорошо, без “костылей”.
3) Обсудить с руководством сдвиг релиза на неделю (самый простой способ), или согласовать, что в текущий релиз через 2 недели не войдут такие-то функции (лучше выпустить меньше хорошо работающего функционала, чем всего функционала с багами и недоделками).
4) Проанализировать ситуацию и принять меры, чтобы такого не повторилось в будущем.

3. Кейс №3.
Заходит новый проект – сайт и бэк система международного туроператора. На уровне “пре-сейла” вопрос полностью закрывается, бюджет оговорен, он достаточный на такой проект (например $70K), в брифе от клиента указаны такие цели: “нам нужен новый очень удобный сайт, мы хотим чтобы клиенты и агенты пользовались одной системой бронирования (сейчас на сайте кабинет клиента и кабинет агента это разные сущности), нужно чтобы вырос объем прямых заказов от физ.лиц, но при этом не потерять агентские заказы (их сейчас до 90%). Должно быть реально современно и удобно, должно идеально отображаться на всех мобильных устройствах.”
Опишите поэтапно процесс работы над проектом (начиная от принятия вами в работу): вам в работу от сейлов передан только бриф с поверхностной инфо, которая описана выше. В рамках этого кейса есть доступ к клиенту и возможность привлекать сейла и других сотрудников по вашему запросу.
Какие инструменты (или какие основные опорные документы) на каждом этапе вы будете использовать? Если используются стандартные элементы, типа user stories, use cases, структура сайта – не нужно описывать что это, можно просто назвать и написать, зачем вы это хотите использовать.

Пример ответа:
Этап 1. Собрать полные требования
документы: …..
….
Этап 2 …..
…..
Этап N. Разработка прототипа
– прототип в Axure для того чтобы получить полное представление о front-end сайта
….
Этап Z. Развертывание проекта на сервере клиента

Ответ 3:
Этап 1. Собрать полные требования (бизнес-сторона, пользовательская сторона) и все документы, что есть по проекту:
• старое ТЗ; описание архитектуры; блок-схемы или другое описание зависимостей сущностей для аккаунта клиента/агента; описание процесса заказов, чтобы понять в каких местах можно автоматизировать/ускорить заказ билетов;
• доступы на сайт под клиентом и агентом;
• доступы в аналитику и/или выяснить текущие проблемы, которые сподвигли заказчика на переработку системы с нуля.
….
Этап 2. Проанализировать полученные документы, выяснить проблемные моменты и обсудить возможное решение этих проблем с архитектором (сделать грубую оценку проекта).

Этап 3. Провести митинги с ключевыми сотрудниками заказчика, чтобы озвучить возможные решения и дополнить требования их идеями/текущими неудобными реализациями и что нужно изменить уже сейчас в текущей системе. Описать все полученные данные в ТЗ. Разработать блок-схему тех. реализации, описать зависимости сущностей (это может быть даже фото доски из митинг-комнаты после обсуждения задач с архитектором). Отправить ТЗ и согласовать все работы с заказчиком.

Этап 4. Создать внешний (для заказчика) план разработки roadmap, что соответствует решению каждой задачи из брифа/требований, а также внутренний roadmap с оценками и расчетами по ресурсам…

Этап 5. Разработка прототипа
– Перенести все требования в треккер (например, Jira), создать подзадачи к большим задачам (раздробить задачи до 3-15часов на каждую).
– Организовать митинг с командой и проранжировать задачи по сложности/приоритетности, сделать оценку каждой задачи. Свести общее время на реализацию проекта и сопоставить его с бюджетом на проект.
– Создать прототип в Axure для того, чтобы получить полное представление о front-end сайта, а также нового дизайна.
– При необходимости – согласовать доп. работы с заказчиком или приоритетность задач в рамках бюджета, предварительный дизайн.

Этап 6. Разработка продукта
• перенос задач в Jira по спринтам, редактирование roadmap;
• постановка задач разработчикам (серверные и архитектурные работы);
• постановка задачи дизайнеру;
• согласование с заказчиком финального адаптивного дизайна сайта (веб, мобайл версии);
• разработка user stories (если есть бюджет и необходимость);
• постановка задачи QA: написание test plan + test cases согласно ТЗ;
• проведение ежедневных спринт-митингов и контроль разработки/выполнения задач;
• поставка заказчику первой демо-версии продукта с реализованными функциями, обновление дизайна сайта и доработка функций для последующих релизов по спринтам;
• контроль и мониторинг выполнения задач, сбор дополнений от заказчика/пользователей.

Этап 7. Развертывание проекта на сервере клиента

• Получение всех доступов и полномочий для Развертывания проекта на сервере(серверах).
• Настройка, импорт/экспорт данных, интеграция базы даных существующего сайта в новую БД…
• Написание инструкций или правил по работе со сложной частью (если есть), например, как создать самостоятельно резервную копию данных.
• Поддержка продукта на этапе перехода на новый сайт (если новое доменное имя)/перевода ДНС (если тот же домен).
• Отправка заказчику всех отчетов и оговоренных исходников.

Этап 8. Поддержка проекта или принятие в работу новый бриф/новый проект этого же заказчика
• Последующая поддержка системы на постоянной основе по контракту, доработка фичей и т.д.

Пожелания по тематике будущих статей принимаются на электронный адрес request@business-cases.info