Customer Satisfaction от Василия Кривоноса

Был на КУЛ ИТ.
Василий Кривонос делал доклад на тему Спасти Рядового РМа, сложные вещи простыми словами, Customer Satisfaction.
Презентация доступна здесь.

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

Итак, коротко:

Если все в балансе, то это как раз то что нужно для управленческого карьерного роста. Нужно во всем разбираться по немногу, чтобы понимать кто что делает.

Цели PjM:
* Вовремя, по спецификации, вложиться в бюджет (локальная цель).
* Customer Satisfaction (цель стратегическая – глобальная)

Если заказчик удовлетворен, он вовлекается классно в проект – это большой плюс.
2 основных источника новых проектов:

  1. удовлетворенные раннее заказчика.
  2. рекомендации удовлетворенных раннее заказчиков.

Существует два основных вида контрактов, а остальное в основном их варианции:
* FP – fixed price (риски лежат в основном на исполнителе).
* TnM – time and material (риски делятся между продавцами и и покупателями)
Первый подход в основном выбрается для областей, где исполнитель еще не может оценить досточно точно объем требуемых ресурсов, второй – когда есть большой обыт.
В FP всегда учитывают риски.

Sales – давят на ПМ, потому что получают процент от продаж. Мотивы Sales & ПМ – имеют противоположные цели.
С практикой общаться с продажниками становится легче.

Неявные угрозы.
FP:
* спецификация и SOW – могут быть недостаточно проработаны.
* сложно реализовать Win Win.
* Change Requests (много рутинной работы)
TnM (есть мнение, что более прибыльный подход)
* Communication – часто большие накладные расходы. Необходимо часто общаться с клиентом, а он может быть недоступен или занят.
* клиент без технической экспертицы – часто нужно будет объяснять заказчику (“когда сделаешь у себя ремонт, будешь знать как его делать”)
* клиент с технической экспертизой – мнение, что «им ПМ не нужен» 🙂 . Заказчик может влезать в микроменеджмента – получаем 2 PjM. Много зависит от хороших доверительных отношений – в этом случае технически подкованный заказчик не влазит в детали.
Если заказчик все таки влазит, нужно чтобы был человек, следящий за тем, чтобы проект не расползался (e.g. project owner)
* кристаллизация проекта. Кажется сыпятся требования и ложатся в проект – все ок. Но в реальности ближе к концу сложно менять проект. Нужно объяснять клиенту, что к концу проекта изменения вносить сложнее. А в конце как правило самые важные изменения 🙂

Проверка вовлеченноста заказчика – послать 10 писем и посмотреть на сколько он ответил 🙂

Обычно чем человек выше по карьерной леснице, тем адекватнее. Например вам пришло письмо YOU ARE STUPIED – за защитой к биг-босу 🙂

Project Scope – план работ по проекту.
Проект появляется, когда появляется прожект-менеджер.

WBS – deliverable oriented иерархическая декомпозиция проектной работы
1. Принцип 100%. Включены все 100%, включая тестирование, дизайн и т.д.
2. Принцип итеративной детализации.
3. Принцип Deliverable-Orientation. Это результат который передается заказчику. Степень детализации должна быть такой, чтобы все можно было бы оценить по времени.
Дальше все это валидируется – в книжках написано, как это делать.

WBS хороша тем, что ее легко всем понять. Хороший инструмент как для коммуникации ПМ с командой, так и для коммуникации с заказчиком. Можно читать с заказчиком, заказчик вовлечется в проект, поймет все и увидит что сделано, а что нет.
Есть онлайн инструменты, можно делать и в google doc и сразу всем доступно.

Построение графика работ и методы его сжатия (по WBS+Estimation).
Сначала достраиваем зависимости между Work Package from WBS – network diagram, строим с конца, с деплоймента.

Все строится вокруг Critical Path и его минимизацией:
Ужать:
* Crashing – добрасывать ресурсы. Не всегда работает, потому что внешние ресурсы надо обучить или же некоторые вещи должен делать один человек и нельзя распараллелить.
Овертаймы – под конец люди уже эффективно не работают.
* Fast tracking – последовательные задачи делать параллельно, но нужно быть готовым к тому, что что-то будет необходимо переделать.

Проектные буферы – резерв для решения проектных проблем.
Например в fixed price всегда точность не 100%, обычно 70%-80%.
Буфер ПМ-а нельзя никому показывать 🙂
Обычно есть еще буфер у человека, который стоит над ПМ-ом, но им нельзя часто пользоваться 🙂

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

Репортинг:
* Репортинг для заказчика: progress report based on WBS – реализованные элементы, все остальное его не интересует. Отдельно выделять красным, если изменения требований привели к многим новым задачам.
* Репортинг для account manager: profits and lost based on S-curve (вначале мало ресурсов тратится, потом много, потом опять мало)
* Репортинг для высшего руководства: status report based on milestones. (mail stone – что-то сделано в проекта, дата приблизительная, дедлайн – не меняется).
Все – больше никаких отчетов не нужно.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *