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