Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Используйте предсказывающие контрольные точки. Оговорите их заранее.

1.6.1. Контрольные точки методом поводка

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

Вот так и с контрольными точками. Справился ваш подопечный – молодец! Даем больше свободы. Большие сложные задачи, меньше контроля. Не справился – значит, пока рановато такие задачи решать. Уменьшаем поводок. Задачи мельче и проще, больше контрольных точек.

1.7. Ошибки делегирования

Но если все ясно, то почему руководители не делегируют или делегируют через ж… плохо?

1.7.1. Неумение делегировать

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

И тогда человек накидывает на себя все больше задач, а сотрудников погружает во все больший форс-мажор – чтобы только опять все «горело». Как следствие, в какой-то момент менеджер превращается в супермена, который прилетает и решает мирские проблемы. Собственно, ради этого ощущения «на острие атаки» весь аврал и затевается. Другой бонус – алиби очень занятого человека и повод для оправданий в духе «я впахивал и сделал все, что мог». Иными словами, «я в домике».

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

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

Понятно, что не бывает без форс-мажоров, когда нужно все бросать и лично подключаться к команде, чтобы задача была решена вовремя, и по ней все было хорошо. Единственная проблема – большую часть форс-мажоров создаем мы сами, своими руками: например, неправильным планированием своего времени и времени подчиненного. А потом врем себе, что виноваты звезды.

1.7.2. Боязнь идти на конфликт

Подробнее об этом поговорим в главе 2, про власть и мозгоклюйство. Одна из частых причин избегания делегирования – неуверенность в моральном праве давать распоряжения. Вчера вы сидели за одним столом, ходили вместе на обед, а сегодня – вы уже руководитель, а он – подчиненный. И с этим теперь надо как-то жить.

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

Часто молодые руководители проектов опасаются испортить отношения с подчиненными – эдакое желание быть хорошим и добрым для всех. Со временем проходит, но не у всех. И, конечно, менеджеры часто стремятся избежать публичных ошибок. Когда вы отдаете в распоряжение сотруднику какую-либо задачу, вы можете ошибаться в ее постановке или в технических нюансах. Либо ваше распоряжение может привести к негативным последствиям. Когда происходит ошибка или такие последствия наступают, и вам на них указывают, это всегда удар и по власти, и по чувству собственной значимости. Самое противное – потом кто-то может долго припоминать эту ситуацию.

1.7.3. Неуверенность в своих подчиненных

Для неуверенности могут быть разные причины. Подчиненные могут быть слишком загружены – и тогда из-за неуверенности в том, что задача втиснется в чей-то график, руководитель ее просто не ставит.

Также вы можете быть не уверены в квалификации подчиненных. Но по-хорошему грамотный руководитель должен заниматься постоянным мониторингом квалификации сотрудников и наращивать ее до необходимого уровня. Другая крайность – неуверенность в мотивации подчиненных: а хватит ли им мотивации выполнить поставленную задачу?

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

1.7.4. Нет достаточных управленческих качеств

Если руководитель не умеет планировать свое рабочее время и время своих подчиненных, не оставляет места для постановки задач и для контроля, то ничего удивительного, что делегирование начнет сыпаться. Для контроля за выполнением работ действительно нужно закладывать время, а после контроля – давать обратную связь и следить, чтобы эти изменения были внесены. Это тоже не все умеют.

Часто бывает, что руководитель и подчиненные очень по-разному понимают круг своих задач и ответственности. Это также может стать причиной конфликтов и неудачного делегирования.

Иногда руководителям не хватает умения замечать командные достижения. Например, вы попросили свою команду самоорганизоваться и проверить проект. Сами убежали заниматься великими делами – скажем, спасать другой проект. А потом вы предъявляете претензии к команде: почему на проекте есть баги, почему не все проверено. И вот вы уже снова в роли спасателя проекта: героически до часу ночи тестируете, а потом с гордой миной заявляете, что только благодаря вам все работает, как надо. А команда – так, мимо проходила.

Сама процедура делегирования зависит не только от того, как поставлена задача, но и от уровня подчиненного. Отправляя человека по пути, думай, кто по этому пути пойдет.

1.8. Правила письменной контрацепции. Как ставить задачи, не убив друг друга

Программисты – как джинны. Осторожнее в своих желаниях, они могут исполниться.

Как письменно формулировать свои требования к программистам? С одной стороны, навык несложный, но именно из-за деталей чаще всего можно получить на проекте долгоиграющий геморрой, а потом ходить и удивляться, почему все складывается наперекосяк.

Итак, солнечное утро. Вы сидите за чашкой кофе. Лениво просматриваете свой проект. И находите в нем какой-нибудь баг. Рука тянется открыть отдельное окно браузера, открыть таск-менеджер, например Jira. Авторизоваться там, найти нужный проект, поставить задачу с описанием бага в грамотных формулировках, приложить скриншоты, описать, как этот баг воспроизвести, назначить ответственных, запланировать себе контроль и так далее. Вот если так – то вы святой человек. Ведь интуитивно в этот момент хочется сказать: «Опять эти упыри накосячили, я что им – бета-тестер что ли?!» Ну, и устроить этим уродам веселую жизнь. И не дай бог они начнут сопротивляться.

Почему так? Почему даже мелкий баг на проекте может приводить в бешенство и заказчиков, и менеджеров проектов? Причина тому – транзакционные издержки.

Мы интуитивно чувствуем, что на решение мелкой проблемы придется затратить довольно много энергии. На мелкие огрехи часто проще махнуть рукой, чем доделывать те последние 10 % работы, которые занимают оставшиеся 50 % времени. Возможность быстро поставить задачу, прилагая минимум усилий мозга и телодвижений, напрямую влияет на качество проекта и добрые отношения внутри рабочей группы. Хотя и двояким образом.

Минимум транзакционных издержек – это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять ничерта не работает, пойди разберись!» Нормально ли это? Отчасти.

Совет

Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно все – вплоть до трехэтажных матов и жестких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше – нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с пометкой «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».

Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта – я его периодически показываю своим ребятам, когда начинаются конфликты.

Вернемся к разработчику, который услышал резко высказанное замечание «баг на проекте» или «ничего не работает». У него всего два варианта действий: либо уйти в оборону, либо – в нападение. Но что адекватного можно ответить на формулировку «Ничего не работает»?! У тебя компьютер что ли не включается?!

Часто из-за нехватки времени на постановку, из-за транзакционных издержек и из-за нежелания думать менеджеры и клиенты склонны ставить неконкретные задачи. На что программисты абсолютно резонно попросят больше конкретики – мол, пиши техзадание. А могут и психануть.

Когда атмосфера накаляется, диалог может складываться как-то так:

– У вас баг на проекте!

– А где именно?!

– ВОТ ТУТ, ЕПТ!!!

Плюс скриншот.

Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» – это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика. Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны – это воспринимается так, будто вы на человека ОРЕТЕ. Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.

1.8.1. Меньше насилия, детка!

Вообще, речь на письме выглядит значительно жестче, чем то же самое, произнесенное устно. В подтверждение – известный анекдот про фразы «Папа! Вышли денег!» и «Папа, вышли денег». Если вы имели опыт переписки с клиентами из Европы или США, то наверняка заметили, что те очень часто используют вежливые слова – «пожалуйста», «спасибо» – и часто благодарят. Слова не влияют на суть, но могут сгладить стиль общения. В русских реалиях такое встречается редко. Причина – якобы, вежливая речь может быть воспринята как слабость. На мой взгляд, эта идея глупая, и письменную речь нужно обязательно смягчать.

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

Молодец…

Молодец.

Молодец!!!

Молодец:(