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

3.2.6. Управление репутацией

Никакие успехи в реализации проекта не будут восприняты аффилянтами позитивно, если вокруг него сложится мнение, что там все дураки и только бюджет пилят. Поэтому репутация (как проекта в целом, так и самого ПМ) – столь же необходимый компонент управления процессом, как и, собственно, реализация бэклога. В отличие от многих объектов, управление которыми мы рассматривали ранее, репутация представляет собой непрерывно поддерживаемый процесс, а не периодически достигаемое состояние. Большинство ранее рассмотренных методов DaShe представляли собой алгоритмы: сделать А, потом сделать Б и получить законченный результат.

Но репутацию (как и любые другие процессы) нельзя сформировать раз и навсегда, проделав несколько последовательных шагов. Процессы требуют постоянной поддержки, поэтому методы управления для них представляют собой ритуалы: если постоянно делать А, Б, В, Г, то процесс будет идти правильно. А если чего-то не сделать – процесс нарушится, и его придется выправлять. Это как езда на велосипеде: нужно постоянно крутить педали и поворачивать руль; никакой, даже самый гениальный, поворот педалей не избавляет от необходимости крутить их дальше.

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

Управление репутацией в DaShe ведется по трем направлениям:

1) репутация проекта у потенциальных потребителей продукта;

2) репутация самого ПМ у аффилянтов проекта;

3) репутация проекта в профессиональной среде разработчиков.

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

1. Любое хоть сколько-нибудь интересное событие в проекте оформляется как новость и доводится до потенциальных потребителей и профессионалов.

Информация оформляется по-разному для разных аффилянтов, аудиторий и информационных каналов. Используется нарративный анализ и подстройка тональности сообщений (tone of voice) под особенности аудитории.

2. В личном общении со всеми аффилянтами проекта ПМ строго придерживается следующих принципов поведения.

• Вежливость. Независимо от содержания контакта ПМ пользуется корректными интонациями и выражениями.

• Порядочность. ПМ соблюдает «библейские заповеди»: не врет, не подставляет, не занимается шантажом или вымогательством, выполняет свои обязательства и обещания.

Примечание: чтобы выполнять обещания, нужно иметь возможность их выполнять, то есть не обещать слишком многого и отказывать в большинстве просьб и пожеланий. Люди сплошь и рядом получают отказы и относятся к ним намного спокойнее, чем к невыполнению обещанного. Отказать – минус 0,1 к репутации; согласиться и выполнить – плюс 1; согласиться и не выполнить – минус половина от всех (!) накопленных баллов, а не просто минус 1.

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

 Авторитетность. Репутация ПМ среди разработчиков имеет дополнительное измерение: «авторитет». Он измеряется как частота следования рекомендациям ПМ при объективной свободе выбора технических решений. Для поддержания авторитета ПМ прибегает к «сортировке ответов»: если у него есть стопроцентно работающее решение, оно выдается разработчику; если надежного решения нет – выдается рекомендация, где поискать или к кому обратиться. Иными словами, ПМ не бросает слов на ветер, и поэтому его слова воспринимаются как весомые.

3. Репутация проекта и команды проекта в профессиональной среде проверяется путем «прощупывания почвы» на профессиональных форумах и в социальных сетях: «Меня зовут в проект ХХХ, что посоветуете?» – и тому подобные вопросы от имени знакомых разработчиков (которых у ПМ, разумеется, должно быть много). Для формирования репутации в профессиональной среде ПМ создает информационный канал (блог какого-нибудь разработчика или даже официальный блог проекта; главное, чтобы его автором выступал кто-то другой). Через этот канал осуществляется пропаганда ценностей проекта теми же способами, что и в пункте 1.

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

Примечание. На самом деле в некоторых случаях ложь воспринимается стейкхолдерами как допустимый недостаток ПМ, но эти случаи (стейкхолдеры контролируют ПМ куда сильнее, чем просто зарплатой) выходят за рамки DaShe.

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

3.3. Управление персоналом и субподрядчиками

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

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

Управление субподрядчиками направлено на решение другой проблемы. Как правило, ущерб, нанесенный проекту невыполнением какой-то задачи, невозможно полностью компенсировать ответственностью субподрядчика. Поэтому от ПМ требуется управлять работой субподрядчиков – точно так же, как он управляет собственным персоналом. Для этого в DaShe предусмотрен соответствующий метод.

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

3.3.1. Лидерство

Про лидерство написаны десятки книг, в значительной степени запутывающих смысл этого понятия. В рамках DaShe лидерство означает всего лишь уверенность разработчика в том, что на ПМ можно положиться в решении большинства проблем и спокойно заниматься своими делами. Такая уверенность возникает, когда решения ПМ в большинстве ситуаций оказываются окончательными и не могут быть пересмотрены кем бы то ни было, включая основных стейкхолдеров. Иными словами, как ПМ сказал, так и будет, ПМ первый после бога в проекте – вот и все лидерство.

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

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

1. Высовываться. Объясним смысл этого действия на примере известного анекдота. В проекте работает Вася, который не понравился стейкхолдеру. Тот звонит ПМ: «Давай-ка уволим Васю». – «Нет, – отвечает ПМ. – Вася очень важен для проекта, закрывает ключевой участок работы, без него мы не справимся, если хотите его уволить, начните с меня». – «А, ну если так, – говорит стейкхолдер, – тогда ладно». ПМ кладет трубку и спрашивает у команды: «Кстати, а Вася чем у нас занимается?»