Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 29)

Если часть команды работает на удаленке, ПМ должен обеспечить не только первичную притирку (пригласив удаленщиков на первое собрание команды), но и регулярные личные встречи всей команды в неформальной обстановке (разумеется, с обязательной «фоновой» деятельностью, чтобы не создавать атмосферу принудительного общения). Кроме того, полезно периодически переводить на удаленку и офисных сотрудников, чтобы они на себе почувствовали возникающие при этом проблемы и увидели возможности.

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

3.3.3. Нацеливание на достижения

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

Нацеливание на достижения и есть формирование связей «результат проекта – воплощение мечты» для каждого из разработчиков. Стихийно такие связи не возникают (люди, как правило, не привыкли планировать будущее и целенаправленно стремиться к тому, чего хотят на самом деле), поэтому в DaShe этим занимается ПМ.

1. Записываются десять целей. Устраиваясь в проект, каждый разработчик надеется получить что-то еще, помимо регулярной зарплаты. Кого-то интересует большой бонус по итогам проекта, кто-то уже видит у себя в резюме строчку «участвовал в разработке ХХХ» или «в совершенстве владеет технологией YYY»; кто-то рассчитывает произвести хорошее впечатление и обеспечить себе занятость в следующих проектах, а кто-то хочет просто отбывать восемь часов и чтобы больше его не беспокоили. Такие ожидания, как правило, не продуманы, а чаще всего даже и не вербализованы, и в ответ на прямой вопрос «Чего вы хотите достичь, участвуя в проекте?» мало кто сможет сразу привести весь список. На основе карточки аффилянта и личной беседы ПМ помогает разработчику составить список из десяти личных целей, семь из которых точно будут достигнуты в случае успешного выполнения проекта. Числа 10 и 7 условны, но отражают общие принципы: целей должно быть несколько, это повышает вероятность достижения одной из них (хотя бы случайно); должен оставаться «резерв» – какие-то цели не будут достигнуты, и это не должно демотивировать разработчика, поскольку большинство (семь из десяти) целей достижимы. Составление списка целей непривычно для большинства людей («а что это такое – цель?»), поэтому требует использования специальных приемов.

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

 Используется прием «Каким я вижу себя в будущем». Отвечая на этот вопрос, люди отталкиваются от своего теперешнего состояния, создавая образ будущего как настоящее без наиболее беспокоящих проблем: «в будущем я здоров» или «в будущем у меня есть своя квартира». Описание будущего переводится в формулирование целей («поправить здоровье» или «накопить на ипотеку»), которые добавляются в список.

Учитывается структура мотивации (см. п. 1.2.4) «безопасность – секс – доминирование», уже известная ПМ с этапа анализа аффилянтов. ПМ уточняет ожидания и мечты, связанные с мотивационным ядром разработчика, и переводит их в конкретные цели.

В результате такой работы получается «образ будущего» – список целей, каждая из которых, будучи достигнутой, ощутимо изменит самоощущение разработчика к лучшему. Нужно помнить, что такой «образ будущего» в любом случае присутствует в глубине души у каждого разработчика, и именно с ним он сверяет свое положение в проекте. Если ПМ не знает, чего хочет разработчик, он не может его мотивировать – и разработчик будет мотивировать себя сам, начиная от сторонних шабашек (в том числе совместно с другими участниками команды) и заканчивая банальным воровством.

2. Счастье для всех. Зная «образы будущего» каждого из разработчиков, ПМ формулирует «образ успеха» проекта в целом. Успех проекта собирается из целей, подразумевающих какую-то отдачу от самого разработчика («вкалывать без выходных», «освоить девопс»); если все цели сводятся к «получать зарплату и ничего не делать», никакого успеха, конечно, не получится, разработчиков с такой мотивацией следует отсеивать еще на этапе отбора. ПМ сопоставляет цели разработчиков с задачами проекта и формирует образ успеха: делаем ХХХ (за счет тяжелой работы и наращивания квалификации) – получаем реализацию некоторых целей, делаем YYY – получаем реализацию следующих. Например, обеспечить «чтобы меня не дергали» сразу после начала проекта не получится – еще неизвестна производительность команды и размеры «подводных камней» проекта; но через два-три этапа может выясниться, что некоторых разработчиков и в самом деле можно оставить в покое.

3. Путь к успеху. Поддержание общего и индивидуальных «образов будущего» требует постоянных усилий. Для этого ПМ производит следующие регулярные действия.

 Беседует (при любом удобном поводе, но не реже раза в неделю) с каждым из разработчиков о том, как продвигается достижение его личных целей и что ему нужно сделать, чтобы продвижение шло быстрее; критерий успеха – когда разработчики сами начинают инициировать такие беседы, принося с собой листочки с заметками.

 При планировании каждого этапа ПМ демонстрирует связь поставленных задач с индивидуальными целями разработчиков: «Реализовав эту фичу, Саша станет специалистом в библиотеке XXX; за пять спринтов без косяков Мише был обещан персональный кальян, и это будет как раз пятый; закончив CJM, Маша сможет приходить в офис после одиннадцати и наконец высыпаться по утрам».

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

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

NB. Обратите внимание, что здесь, как и в некоторых местах ранее, используются контринтуитивные действия, вытекающие из того факта, что в проектной деятельности нужно руководствоваться принципами, диаметрально противоположными привычным в других областях. Обычно считается, что наемный работник сам знает, чего хочет, и зарплаты более чем достаточно для его мотивации. В случае проектной деятельности это не так: чтобы разработчик по-настоящему хотел успеха проекта, он должен не только понимать собственные настоящие цели, но и надеяться достичь их работой в проекте.

3.3.4. Защита исполнителя

В отличие от процессной деятельности, где все операции отработаны и регламентированы, проектная требует от исполнителей значительной самостоятельности. Разработчики набраны в проект, чтобы делать новый продукт, а не просто отбывать в офисе положенное время. Делать новый продукт – значит преодолевать возникающие сложности путем самостоятельного поиска решений, а не ждать руководящих указаний. Искать решения трудно – как по объему работы, так и психологически, ведь никто не знает, сколько времени займет поиск и приведет ли к желаемому результату. Чтобы не опускать руки, разработчикам требуется дополнительная мотивация, созданию которой были посвящены предыдущие разделы. Однако созданную мотивацию нужно еще и сохранять.

Мотивация разрушается, когда исполнитель не получает положительной обратной связи по итогу хорошо сделанной работы. Наиболее распространенным случаем неправильной обратной связи является изменение заданий в ходе спринта: «Задача А, которую вы делали, пока не нужна, делайте сейчас Б». Казалось бы, ничего особенного – но ради задачи, которая не так уж и нужна, никто не захочет напрягаться. Даже единичный случай изменения заданий может подорвать доверие к проекту, а если такие изменения возникают регулярно – команда гарантированно перейдет в режим «не торопись выполнять указание, все равно отменят».