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

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

Контроль

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

Санкционирование

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

1.5. Постановка задач на рисерч

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

Исследование требует ресурсов, иногда – серьезных, и если задача новая и неизвестная, то процесс оценки стоит разбить на стадии:

1) Постановка задачи, анализ и предварительная оценка

Например, задача – анимированная 3D-модель, а вы такого раньше не делали. Предварительно вы закладываете 8–16 часов на всю эту задачу.

2) Фаза рисерча

Мы берем себе час-два на «поиграться» с какой-то технологией или новым стэком, провести нужные эксперименты. В примере про 3D-модель нам нужно будет посмотреть, как «запекаются» текстуры, посмотреть фреймворки для 3D-анимации, изучить софт, посмотреть примеры. В итоге оценка может увеличиться в 4 раза, или вы поймете, что только на стадию рисерча вам нужны исходные 8–16 часов. Бывает. Возможно, в этот момент вы упростите задачу, обойдетесь без анимации. Или поменяете исполнителя, найдете опытного. Или добавите ресурсов. Я называю это «контролируемый факап». Провал возможен, но глубина провала известна заранее.

3) Уточненная оценка, начало работы, фиксация оценки

Когда вы поняли, с чем имеете дело, оценки фиксируются железобетонно.

4) Выполнение задания. Согласованные контрольные точки

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

На первом и втором этапе оценки и прочие параметры можно менять. Начиная с третьего – уже нет.

Если у вас нет навыков в сфере, в которой нужно делать декомпозицию, ее нужно поручить сделать подчиненному с соответствующими навыками. Результат получить в письменном виде. И если что – проверить сторонним специалистом, мнению которого вы доверяете.

1.6. Фальшивые автобусные остановки. Тонкое искусство контрольных точек

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

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

Пример из практики: один мой знакомый очень любит внедрять KPI. Из пяти метрик одну делает фальшивой. В реальной работе получить ее нельзя. Хитрецы же могут накрутить любую херабору.

Другой пример: как-то я подготовил чек-лист, первым пунктом которого было: «Внимательно прочитать документ до конца». Дальше было примерно 30 пунктов. Последним был «Выполнить пункты 1 и с 5 по 12, остальные проигнорировать». Жестко, да?

Нет четкого алгоритма расстановки контрольных точек. Их не должно быть очень много. Это лишняя нагрузка на вас и раздражитель для исполнителей. Попробуйте мысленно представить, как выглядит провал по задаче. Теперь мысленно представьте, что было до этого провала. Попробуйте найти такую точку, где провал уже возможен, но ситуацию можно исправить. Постарайтесь использовать «предсказывающие» контрольные точки.

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

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

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. Меньше насилия, детка!

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

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

Молодец…

Молодец.

Молодец!!!

Молодец:(

Молодец:)

ХОРОШ!

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

Совет

Не допускайте КАПСА, мата и ругани в письме и старайтесь отучать от этого коллег. И не стесняйтесь использовать смайлы, чтобы смягчить жесткость, присущую письменной речи.

Окей, вы такой молодец, написали разработчику вежливое обращение со смайликом и скинули ссылку. Насколько это конкретно? Приложили скриншот? Уже лучше. Можно стрелок к нему еще нарисовать. Уже почти хорошо. Только все равно не спасает. Многие грешат надписями на скриншотах. Но часто конкретики с ними все равно нет.

Я не преувеличиваю ни на грамм. Ставится задача с формулировкой «Косяк на сайте». КАПСОМ. Ставится ссылка на скриншот, где тоже что-то невменяемо написано капсом. Не удивляйтесь, если в комментариях к такой задаче вам также начнут отвечать капсом, нервно и грубо. Тикет-система тут будет не виновата – так накуролесить можно и в Jira, и в Trello, и в чем угодно еще.

Надписи на скриншотах не возбраняются, но они должны быть конкретными.

1.8.2. Найди меня потом, попробуй!

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

Сейчас за кадром оставим вопрос, почему у вас заказчик нашел баги, и их так много, но акцент не на этом. Это могут быть и формулировки заданий – разницы нет.

Если в таком виде с вами работает ваш клиент, и у вас не получается договориться о нормальных формулировках (ему тоже не до формулирования и четкости и проще вам заплатить побольше денег, чтобы вы сами все фиксировали с его слов), тогда проблем нет. Фиксируйте все сами, сами переводите с клиентского на программистский. Берите за это деньги. Это воспринимается абсолютно нормально в 80 % случаев и ценится (если вы не сильно косячите). Вы экономите клиенту время – и это тоже часть менеджерской работы. К исполнителям формулировки должны попадать такие, чтобы задачу можно было найти поиском. Очевидная вещь, но приходится и про такое рассказывать.

Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов – и нельзя их за него осуждать.

1.8.3. Проблема или требование?

Бывают формулировки, из которых непонятно: это проблема или требование? Пример – «ссылка фиолетовая». И что? Она должна такой быть или ошибка в том, что она фиолетовая, а должна быть серой? Дело в том, что непонятно, что именно вы хотите, чтобы с этим фактом сделали и как именно его поправили.

1.8.4. Мне кажется…

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

1.8.5. Поплачь о нем… В другом месте!

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

Представьте, что программист переживает расставание с подружкой, пришел с плохим настроением. Открывает текстовый редактор. Создает файл VsePloho.php. В нем – класс PolniyPipec. А в нем метод KakViVseDostali (vi, vse). На другой день настроение наладилось, помирились, новый файл уже SuperPuperMegaKorzina.php и все в таком роде. И это все идет на ревью службе безопасности. Думаю, там разговор будет короткий.

1.8.6. Принцип пирамиды

Организуйте постановки по принципу «пирамиды». Заголовок задачи должен быть такой, чтобы была понятна суть и не приходилось много читать. Детали помещайте в описание.

1.8.7. Приоритеты

В баг-листах, помимо описания проблемы, ее места на сайте и способов воспроизвести баг, также указывается приоритет. В разных компаниях системы приоритетов обычно складываются исторически. У нас она – вот такая:

▶ 0 – критические баги (падает сервер или не работает оплата), нулевой приоритет ставим в случае, если тестировщик из-за этого бага не может дальше продолжать проверку проекта.

▶ 1 – либо что-то забыли реализовать, либо что-то критичное по юзабилити.

▶ 2, 3 – менее критичные вещи.

▶ 4 – ошибки в текстах или текстовые правки.

▶ 8 – это «хотелки», некритичные баги.

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