Другая причина нежелание столкнуться с сопротивлением. Действительно бывает, что подчиненный либо морально сильнее вас, либо превосходит по уровню эмоционального интеллекта. Поэтому, если появляются какие-то проблемы по задаче, возникает желание сделать ее самостоятельно лишь бы не провоцировать конфликт, навязывая кому-нибудь свою волю.
Часто молодые руководители проектов опасаются испортить отношения с подчиненными эдакое желание быть хорошим и добрым для всех. Со временем проходит, но не у всех. И, конечно, менеджеры часто стремятся избежать публичных ошибок. Когда вы отдаете в распоряжение сотруднику какую-либо задачу, вы можете ошибаться в ее постановке или в технических нюансах. Либо ваше распоряжение может привести к негативным последствиям. Когда происходит ошибка или такие последствия наступают, и вам на них указывают, это всегда удар и по власти, и по чувству собственной значимости. Самое противное потом кто-то может долго припоминать эту ситуацию.
1.7.3. Неуверенность в своих подчиненных
Для неуверенности могут быть разные причины. Подчиненные могут быть слишком загружены и тогда из-за неуверенности в том, что задача втиснется в чей-то график, руководитель ее просто не ставит.
Также вы можете быть не уверены в квалификации подчиненных. Но по-хорошему грамотный руководитель должен заниматься постоянным мониторингом квалификации сотрудников и наращивать ее до необходимого уровня. Другая крайность неуверенность в мотивации подчиненных: а хватит ли им мотивации выполнить поставленную задачу?
Еще один вариант сомнения, что сотрудники верно понимают поставленную задачу и сделают ее именно так, как вы того хотите. Бывает, что вы даете распоряжение в общих словах. Например, «поедь к Иван Иванычу, возьми такой-то документ и привези его мне». И вот, приходит подчиненный и говорит: «Не получилось». Он не съездил, а позвонил. Иван Иваныч был на совещании и не перезвонил. А вы-то знаете, что Иван Иванычу звонить бесполезно он такой человек, к которому нужно именно приехать. И здесь не остается никаких рычагов, кроме режима бармалея: «Делай так, а то уволю!» Просто потому что на рассказ о всех тонкостях взаимоотношений с Иван Иванычем у вас уйдет полдня.
1.7.4. Нет достаточных управленческих качеств
Если руководитель не умеет планировать свое рабочее время и время своих подчиненных, не оставляет места для постановки задач и для контроля, то ничего удивительного, что делегирование начнет сыпаться. Для контроля за выполнением работ действительно нужно закладывать время, а после контроля давать обратную связь и следить, чтобы эти изменения были внесены. Это тоже не все умеют.
Часто бывает, что руководитель и подчиненные очень по-разному понимают круг своих задач и ответственности. Это также может стать причиной конфликтов и неудачного делегирования.
Иногда руководителям не хватает умения замечать командные достижения. Например, вы попросили свою команду самоорганизоваться и проверить проект. Сами убежали заниматься великими делами скажем, спасать другой проект. А потом вы предъявляете претензии к команде: почему на проекте есть баги, почему не все проверено. И вот вы уже снова в роли спасателя проекта: героически до часу ночи тестируете, а потом с гордой миной заявляете, что только благодаря вам все работает, как надо. А команда так, мимо проходила.
Сама процедура делегирования зависит не только от того, как поставлена задача, но и от уровня подчиненного. Отправляя человека по пути, думай, кто по этому пути пойдет.
1.8. Правила письменной контрацепции. Как ставить задачи, не убив друг друга
Программисты как джинны. Осторожнее в своих желаниях, они могут исполниться.
Как письменно формулировать свои требования к программистам? С одной стороны, навык несложный, но именно из-за деталей чаще всего можно получить на проекте долгоиграющий геморрой, а потом ходить и удивляться, почему все складывается наперекосяк.
Итак, солнечное утро. Вы сидите за чашкой кофе. Лениво просматриваете свой проект. И находите в нем какой-нибудь баг. Рука тянется открыть отдельное окно браузера, открыть таск-менеджер, например Jira. Авторизоваться там, найти нужный проект, поставить задачу с описанием бага в грамотных формулировках, приложить скриншоты, описать, как этот баг воспроизвести, назначить ответственных, запланировать себе контроль и так далее. Вот если так то вы святой человек. Ведь интуитивно в этот момент хочется сказать: «Опять эти упыри накосячили, я что им бета-тестер что ли?!» Ну, и устроить этим уродам веселую жизнь. И не дай бог они начнут сопротивляться.
Почему так? Почему даже мелкий баг на проекте может приводить в бешенство и заказчиков, и менеджеров проектов? Причина тому транзакционные издержки.
Мы интуитивно чувствуем, что на решение мелкой проблемы придется затратить довольно много энергии. На мелкие огрехи часто проще махнуть рукой, чем доделывать те последние 10 % работы, которые занимают оставшиеся 50 % времени. Возможность быстро поставить задачу, прилагая минимум усилий мозга и телодвижений, напрямую влияет на качество проекта и добрые отношения внутри рабочей группы. Хотя и двояким образом.
Минимум транзакционных издержек это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять ничерта не работает, пойди разберись!» Нормально ли это? Отчасти.
Совет
Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно все вплоть до трехэтажных матов и жестких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с пометкой «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».
Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта я его периодически показываю своим ребятам, когда начинаются конфликты.
Вернемся к разработчику, который услышал резко высказанное замечание «баг на проекте» или «ничего не работает». У него всего два варианта действий: либо уйти в оборону, либо в нападение. Но что адекватного можно ответить на формулировку «Ничего не работает»?! У тебя компьютер что ли не включается?!
Часто из-за нехватки времени на постановку, из-за транзакционных издержек и из-за нежелания думать менеджеры и клиенты склонны ставить неконкретные задачи. На что программисты абсолютно резонно попросят больше конкретики мол, пиши техзадание. А могут и психануть.
Когда атмосфера накаляется, диалог может складываться как-то так:
У вас баг на проекте!
А где именно?!
ВОТ ТУТ, ЕПТ!!!
Плюс скриншот.
Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика. Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны это воспринимается так, будто вы на человека ОРЕТЕ. Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.
1.8.1. Меньше насилия, детка!
Вообще, речь на письме выглядит значительно жестче, чем то же самое, произнесенное устно. В подтверждение известный анекдот про фразы «Папа! Вышли денег!» и «Папа, вышли денег». Если вы имели опыт переписки с клиентами из Европы или США, то наверняка заметили, что те очень часто используют вежливые слова «пожалуйста», «спасибо» и часто благодарят. Слова не влияют на суть, но могут сгладить стиль общения. В русских реалиях такое встречается редко. Причина якобы, вежливая речь может быть воспринята как слабость. На мой взгляд, эта идея глупая, и письменную речь нужно обязательно смягчать.