Страница 13 из 36
Ключевых вопроса тут два:
1. Где та грань, когда вы требуете от программиста какого-то бреда (вроде выкапывания ямы), а где он просто говнится, чтобы вы отстали?
2. На что опираться руководителю проекта, чтобы добиться нужного ему результата?
Начнем со второго вопроса. Требовательности.
2.2. Требовательность
Требовательность – базовое качество руководителя, в том числе – и руководителя digital-проектов. Это умение настоять на своем, отстоять интересы компании, команды, проекта и свои, если на эти интересы покушается вселенная.
В идеале управление digital-проектом сводится к расстановке приоритетов: это делаем в первую очередь, это – во вторую. Команда весело разбирает тикеты и дружно бежит их выполнять. Желательно автономно: сами подумали, сами быстро и качественно сделали. Вас же на всякую фигню не отвлекают. А только радуют результатами.
Размечтался. Гораздо чаще можно встретить сопротивление требованиям, затупы, а иногда – скрытый или даже явный саботаж.
Требовательность плотно связана с понятиями «власть» и «эксплуатация». Про источники власти много любопытного у Макиавелли, Ницше и других великих умов мира сего. Власть божественная или государственная, бла-бла-бла… – нам так круто не надо. Для управления digital-проектами интересна власть, которая устанавливается внутри команды проекта и разделяет людей на тех, кто командует, и тех, кто подчиняется.
Требовательность – токсична, и в больших количествах – яд (вплоть до психосоматики). Давят сроки, обстоятельства, клиенты, объем параллельных проектов. И малейшее сопротивление требованиям или уточняющий вопрос команды исполнителей вызывает у перегруженного руководителя раздражение. Оставаться при этом еще и в позитивном настроении – сложно.
Я знаю целый класс руководителей уровня «директор по маркетингу», бегающих с конференции на конференцию, с выставки на выставку (в промежутках – в отпуск), забегающих в офис поработать на пару дней и тут же сливающихся на следующую выставку – лишь бы не заниматься управлением.
Требовать мягко и тактично они не умеют. На внятное распоряжение способны только в состоянии аффекта, если их сильно разозлить. Надо ли говорить, что такое поведение деструктивно не только для самого руководителя, но и для его рабочей группы?
Приходится учиться требовать. А в книгах по менеджменту тема табуирована. Принято писать о мотивации, командном духе, самоорганизации и бирюзовых компаниях. Вести дискуссии о том, нужен ли вообще менеджер на проекте. Искать всевозможные поводы как можно дальше дистанцироваться от этого геморроя. При этом забывается, что в западных компаниях субординация, бизнес-процессы, требовательность и исполнительность нормально работают по умолчанию. Никто в голос не ругается, не орет, но если пригласили на разговор за закрытыми дверями – все прекрасно понимают, что дело дрянь. Мотивационные плюшки и самоорганизация – это уже тюнинг.
Забавно выглядит, когда руководитель, начитавшись книг по мотивации и самоорганизации или вернувшись с семинара, вдохновенно решает убрать вот эту самую токсичность управления от себя подальше. Прибегает в компанию и с криками «Ага! Мы с завтрашнего дня – бирюзовые!» пытается перевалить «головняк» на команду. А потом расстраивается, что не работает. И почему-то я не удивлен. Делегировать сначала научитесь!
Уверен, если бы в таск-трекерах была кнопка «Долбануть током» – она бы пользовалась популярностью. Пока такой кнопки нет, ею должны уметь становиться вы сами.
Самоорганизующимся командам нужен самоорганизатор. Уметь планировать, требовать, настаивать, при этом соизмеряя необходимую и достаточную силу. Хотя говорить про требовательность не принято: сочтут упырем, эксплуататором и фашистом.
В долгосрочной перспективе для блага проекта, организации и ее обитателей сильная власть и требовательность предпочтительнее хаоса и анархии. Известный афоризм Гарри Трумэна, 34-го президента США: «Любое действительно эффективное управление на поверку оказывается диктатурой». При этом никто не против, чтобы все были довольны, счастливы и мотивированы. Как такового противоречия здесь нет.
Самоорганизующимся командам нужен самоорганизатор.
2.3. Механизм власти
Винтовка рождает власть.
Механизм власти до ужаса прост: выполняй мою волю, а иначе наступят некоторые (по умолчанию – хреновые) последствия. В основе лежит воля и угроза (явная или неявная). С одной стороны, чертовски обидно (от отвращения до бунта, когда понимаешь, как и когда этот механизм применяют лично к тебе). С другой – факт, что все хорошее в этом мире сделано с использованием механизма власти. С третьей – никуда не денешься.
Наша задача – научиться применять этот механизм профессионально.
2.3.1. Поле власти
У Александра Фридмана вычитал интересную аналогию с полем власти: это вроде электричества, к которому подключаются управленческие инструменты типа делегирования, контроля, мотивации и так далее. Если поле власти сконфигурировано правильно – инструменты работают адекватно. Аналогично с электричеством: параметры тока в розетке верные – устройства работают нормально. Если нет – устройства глючат или даже сгорают.
Всю власть в компании возьмем за 100 %, поделенных между сотрудниками. Причем, зачастую это распределение образовывается стихийно. По историческим причинам. И в результате взаимодействия сотрудников власть перераспределяется (у одного уменьшается, у другого увеличивается). Это архиважный тезис – вы что-то с кем-то делаете (или не делаете), а в результате у вас и у него меняется реальная власть.
Рекурсия: источник власти – в ее грамотном применении. Поэтому молодым руководителям проектов важно сразу начать применять ту небольшую власть, которая у них есть, для тех дел, для которых она годится.
2.3.2. Самозахват
Давайте посмотрим на поле власти на простой модели.
Вот компания состоит всего из 2-х человек – менеджера и программиста – и между ними как-то распределилась власть. У кого власти должно быть больше?
Менеджеры тут же скажут: «У менеджера!», а программисты на это ничего не скажут, но про себя хмыкнут: «Ну-ну, давай, покажи, что ты там из себя за менеджер». И можете не удивляться, если программисты считают менеджеров обслуживающим персоналом. Причем, назойливым, глупым, мешающим работать и думать об архитектуре, ставящим неадекватные задачи и вечно лезущим со всякой несущественной фигней.
Таким образом, в поле власти может возникнуть красная зона, где люди по-разному понимают круг своих обязанностей, свою зону ответственности и свои права.
Плохо, если сотрудники в компании не знают, как именно власть распределена; плохо, если знают по-разному. Такая мышиная возня отнимает у компании много энергии. В таких случаях вопрос решается повышением компетенций руководителей (нужны энергичные живчики), введением хороших корпоративных правил и наказаний (вплоть до замены нелояльных сотрудников). То есть, долго и дорого.
Вариантов потерять власть – много. Например, самозахват.
Допустим, у вас есть правило: «Получил задачу – оцени». Программист может сначала, как бы случайно, не оценивать задачи (типа, забыл). Если на это не отреагируют (ну сделал, и ладно) – не оценивать специально. Если попросят оценки – сказать: «Не знаю, не могу». А потом и вовсе поскандалить и отказаться оценивать задачи: «Вы, менеджеры, ни черта не понимаете в природе программирования, никаких оценок там дать нельзя…» Если менеджер не отреагирует – сформируется право обычая «Васе можно». И все: власть менеджера уменьшилась, а программист отвоевал себе свободу не думать перед началом работы и не отвечать за сроки.