Никакие успехи в реализации проекта не будут восприняты аффилянтами позитивно, если вокруг него сложится мнение, что там все дураки и только бюджет пилят. Поэтому репутация (как проекта в целом, так и самого ПМ) – столь же необходимый компонент управления процессом, как и, собственно, реализация бэклога. В отличие от многих объектов, управление которыми мы рассматривали ранее, репутация представляет собой непрерывно поддерживаемый процесс, а не периодически достигаемое состояние. Большинство ранее рассмотренных методов DaShe представляли собой алгоритмы: сделать А, потом сделать Б и получить законченный результат.
Но репутацию (как и любые другие процессы) нельзя сформировать раз и навсегда, проделав несколько последовательных шагов. Процессы требуют постоянной поддержки, поэтому методы управления для них представляют собой ритуалы: если постоянно делать А, Б, В, Г, то процесс будет идти правильно. А если чего-то не сделать – процесс нарушится, и его придется выправлять. Это как езда на велосипеде: нужно постоянно крутить педали и поворачивать руль; никакой, даже самый гениальный, поворот педалей не избавляет от необходимости крутить их дальше.
Репутация в понимании DaShe – позитивные или нейтральные ожидания от любого контакта с ПМ или проектом. Если разработчик не стесняется обращаться к ПМ с любыми проблемами, если стейкхолдеры периодически звонят ПМ просто так, узнать какую-нибудь хорошую новость – значит, они ожидают от таких контактов чего-то хорошего или, по крайней мере, не ожидают ничего плохого. Вот это и есть хорошая репутация.
Управление репутацией в DaShe ведется по трем направлениям:
1) репутация проекта у потенциальных потребителей продукта;
2) репутация самого ПМ у аффилянтов проекта;
3) репутация проекта в профессиональной среде разработчиков.
Измеримыми показателями репутации являются: типичные нарративы (см. нарративный анализ во второй части), связанные с проектом среди потребителей и специалистов (потенциальных разработчиков); частота обращений к ПМ со стороны аффилянтов проекта – стейкхолдеров и разработчиков. Нарративы должны быть положительными («крутой проект, отличная команда»), частота – высокой. Чтобы обеспечить то и другое, задействуется соответствующий метод.
1. Любое хоть сколько-нибудь интересное событие в проекте оформляется как новость и доводится до потенциальных потребителей и профессионалов.
Информация оформляется по-разному для разных аффилянтов, аудиторий и информационных каналов. Используется нарративный анализ и подстройка тональности сообщений (tone of voice) под особенности аудитории.
2. В личном общении со всеми аффилянтами проекта ПМ строго придерживается следующих принципов поведения.
• Вежливость. Независимо от содержания контакта ПМ пользуется корректными интонациями и выражениями.
• Порядочность. ПМ соблюдает «библейские заповеди»: не врет, не подставляет, не занимается шантажом или вымогательством, выполняет свои обязательства и обещания.
Примечание: чтобы выполнять обещания, нужно иметь возможность их выполнять, то есть не обещать слишком многого и отказывать в большинстве просьб и пожеланий. Люди сплошь и рядом получают отказы и относятся к ним намного спокойнее, чем к невыполнению обещанного. Отказать – минус 0,1 к репутации; согласиться и выполнить – плюс 1; согласиться и не выполнить – минус половина от всех (!) накопленных баллов, а не просто минус 1.
Соответствие ожиданиям. На основе карточек аффилянтов и личных контактов ПМ определяет «язык», подходящий каждому аффилянту (одним нужно подробно и увлекательно рассказывать о каждой мелочи, другие, наоборот, ценят краткий ответ с численными показателями). ПМ постоянно владеет информацией о текущем состоянии проекта. Каждый контакт строится по шаблону: 1) выразить удовольствие от контакта; 2) понять, что требуется; 3) выбрать нужную информацию; 4) оформить ответ на языке аффилянта. Критерий правильности выбора информации и языка – повторные обращения; если их нет дольше, чем ожидается, предположения о правильном «языке» нужно скорректировать.
Авторитетность. Репутация ПМ среди разработчиков имеет дополнительное измерение: «авторитет». Он измеряется как частота следования рекомендациям ПМ при объективной свободе выбора технических решений. Для поддержания авторитета ПМ прибегает к «сортировке ответов»: если у него есть стопроцентно работающее решение, оно выдается разработчику; если надежного решения нет – выдается рекомендация, где поискать или к кому обратиться. Иными словами, ПМ не бросает слов на ветер, и поэтому его слова воспринимаются как весомые.
3. Репутация проекта и команды проекта в профессиональной среде проверяется путем «прощупывания почвы» на профессиональных форумах и в социальных сетях: «Меня зовут в проект ХХХ, что посоветуете?» – и тому подобные вопросы от имени знакомых разработчиков (которых у ПМ, разумеется, должно быть много). Для формирования репутации в профессиональной среде ПМ создает информационный канал (блог какого-нибудь разработчика или даже официальный блог проекта; главное, чтобы его автором выступал кто-то другой). Через этот канал осуществляется пропаганда ценностей проекта теми же способами, что и в пункте 1.
4. Ложь и дезинформация в отношении стейкхолдеров и разработчиков создают критические риски для проекта (подрывая доверие к ПМ в случае разоблачения), поэтому прибегнуть к «дезе» можно только один раз, и только в качестве «средства последней надежды».
Примечание. На самом деле в некоторых случаях ложь воспринимается стейкхолдерами как допустимый недостаток ПМ, но эти случаи (стейкхолдеры контролируют ПМ куда сильнее, чем просто зарплатой) выходят за рамки DaShe.
Результат. Репутация проекта и ПМ, благодаря которой к нему охотно обращаются по любым вопросам.