Monthly Archives: September 2011

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 – что-то сделано в проекта, дата приблизительная, дедлайн – не меняется).
Все – больше никаких отчетов не нужно.

Видимость и продвижение вашей команды в компании. По результатам доклада.

Выступил на тему “Видимость и продвижение вашей команды в компании”.

Забавное видео получилось:

Спасибо за видео докладчикам второй части события: Катерине Синдяковой и Инне Кравченко.

Также доступны презентации на русском и английском языках.

Отдельное спасибо компании Materialise, которая дала мне возможность проделать то, о чем была презентация, и без которой мне бы не было чем делиться с коллегами.

Уточнения

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

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

NDA внутри компании есть, особенно если это касается данных пользователей. Но нашу команду это редко касалось, поэтому ответ на вопрос мог показаться странным.

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

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

Различие между публикациями и Release Notes можно описать так: публикация может появиться еще до Release Notes, может идти разговор также о некоторых специфических случаях использования, сравнении фич и т.д. С другой стороны в публикациях некоторые очень специфические фичи, которые используются малым количеством пользователей, лучше не использовать.

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

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

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

P.S. Собираюсь послушать 22 сентября выступление Василия Кривоноса на следующий встерече КУЛ ИТ о взаимодействии PM c заказчиками. Чуть меньше года назад он уже представлял доклад о зарплатах.