Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Размер шрифта: 13
© Завертайлов В., текст, 2022
© ООО «Издательство «Эксмо», 2022
* * *
Друзья! Всем, кто приобрел эту книгу, мы дарим полгода бесплатной работы в лучшем персональном планировщике задач SingularityApp. Вы экономите 1000 рублей. Чтобы узнать, как получить подарок – переходите по ссылке https://singularity-app.com/pmbook/ или QR-коду
Введение
Что нужно, чтобы стать руководителем digital-проектов или руководителем продукта в IT? Уж точно не классическое вузовское образование (хотя без него будет трудно). На пути к должности руководителя вы потратите огромное количество времени на практику, не раз набьете шишки и столкнетесь с факапами, прольете немало пота, крови и слез, вложите в это много труда. Но самое главное – приготовьтесь каждый день ставить свою шкуру на кон. Потому что руководитель проектов и продуктов отвечает за свое детище, как никто в команде. И делает все то, что нельзя делегировать.
Вас к такому не готовили
Почти 20 лет я руковожу студией разработки и не один год провожу стажировки для студентов. Статистика печальна: востребованных специалистов для управления проектами и продуктами в вузах, увы, не готовят. Поэтому мне приходится отсматривать десятки претендентов на стажировку и отсеивать тех, кто хочет халявы в роли ничего не делающего надзирателя или легких денег (проджекты же много зарабатывают, правда?). Но те, кого я беру на стажировку – счастливчики. Потому что они моментально погружаются в рабочую атмосферу. Сразу вникают в процессы, самостоятельно делают аналитику, продумывают структуру проектов (пусть и не существующих в реальности), ведут их от начала и до конца, наступают на грабли, совершают ошибки. Сразу – действительно учатся. И даже если в дальнейшем наши пути расходятся, ребята уходят счастливыми и окрыленными.
Но что делать, если у вас за плечами нет такой стажировки, а вы хотите быть руководителем продукта или проекта? Или, возможно, уже им стали, но что-то постоянно не клеится: сроки срываются, команда косячит, и вам опять надо это разгребать в стопятьсотый раз? Знакомо? Знакомо. Нет, можно, конечно, уволиться и начать все сначала. Но собственные системные ошибки догонят где угодно – потому что от себя не убежишь.
На должность руководителей проектов я собеседовал множество раз, и это были самые разные люди. Одни работали в каких-нибудь госзакупках, другие – в прошлом были инженерами, но доросли до руководящих позиций, третьи – менеджерили команду в банке или вообще были маркетологами. Меня мало интересует опыт из резюме – он вряд ли расскажет о том, способен ли человек решать проблемы здесь и сейчас или нет. И уж точно не покажет, насколько крутой из него переговорщик и справится ли он с интеграцией на проекте. Меня больше интересуют навыки – те самые Soft Skills, о которых мы будем говорить в этой книге. И которых часто не хватает многим, и не только в IT-среде.
Кто виноват и что делать
Хорошая новость: вы не виноваты в том, что на старте в профессию не обладали огромным багажом знаний и что даже многолетний опыт не спас вас от ошибок. Так уж повелось, что в классических учебных заведениях необходимую информацию почти не дают, а на предыдущих местах работы редко удается прокачать все нужные скиллы.
Но есть и плохая новость: вы в ответе за то, что все так, как есть. Сейчас вы должны решить, что делать дальше: учиться или продолжать слепо ходить по старым дорожкам в надежде получить другой результат.
Если выбираете второй путь – ставьте книгу обратно на полку, диалога у нас не получится. Если все-таки первый – то придется потрудиться. Но оно того стоит.
В digital все крутится вокруг всего двух компетенций: технологии и коммуникации. Hard Skills & Soft Skills. Если проседают коммуникации, руководитель сможет завалить проект, сделанный сильной технической командой. И наоборот: позитивный и энергичный менеджер, который умеет договариваться – вытянет слабый проект и сделает так, что заказчик попросит еще. Технологии же нужны, чтобы общаться с командой и заказчиками на уровне эксперта.
Что вам точно понадобится?
▶ Честность. На уровне «пацан – сказал, пацан – сделал». Без этого с человеком, по-моему, вообще нельзя иметь дел.
▶ Интеллект. В первую очередь – системное мышление.
▶ Зрелость. Готовность брать на себя ответственность.
▶ Позитив и энтузиазм. Если менеджер по натуре депрессивен, и у него на лице написано: «Господи, когда же это все дерьмо закончится» – не стоит ожидать, что команда радостно подхватит знамя и с криками «Эге-гей! Дерьмо! Кончайся!» побежит делать проект.
▶ Внимание к мелочам. Большие проблемы вырастают из мелочей, которые проглядели на старте работ. Или заметили, но решили, что они никак не повлияют на будущее. Мелочи ничего не прощают большому.
▶ Готовность незамедлительно действовать.
▶ Требовательность. Умение пойти на конфликт, если что-то сделано плохо, отстаивать свои интересы и интересы дела.
Вообще, путь менеджера – это трудный путь. В нем много сложностей и много работы над собой, характером, привычками. А это больно. Приходится нести ответственность не только за себя, но и за других, и за весь проект. Отвечать за чужие косяки. Двойные неприятности.
Зато это очень интересный путь, интересная судьба. Практически бесконечные возможности как для горизонтального роста, так и для вертикального, если он вдруг вам понадобится. Хорошо платят. Вы приобретаете чертовски полезные навыки для повседневной жизни. И это определенная степень свободы, умение владеть собой. И еще – вы будете востребованы, и скучно точно не будет. Но это – если оно вам действительно надо. А раз уж вы держите в руках эту книгу, хочется надеяться, что это так.
Что вас ждет в этой книге
В 2017-м году мы в студии создали обучающий курс на Skillbox «Руководитель digital-проектов», который был одним из первых на рынке по этой теме. За 4 года существования его прошли сотни студентов. И каждый из них хотел бы иметь под рукой инструмент, на который всегда можно положиться в сложной и неоднозначной ситуации.
Цель – дать этот инструмент тем, кто только собирается в профессию руководителя проекта или руководителя продукта, и тем, кто уже в ней работает и развивается, но испытывает сложности. Можно сказать, это настольное практическое руководство для проджектов и продактов, которым приходится либо заказывать digital-услуги на стороне, либо управлять своим собственным digital-производством.
Почему книга сразу и для проджектов, и для продактов? Потому что в небольших проектах эти роли часто выполняет один человек. Project Manager (диджитал-продюсер, PM, менеджер, руководитель проектов – зовите, как хотите) – специалист, который своей шкурой отвечает за проект и несет ответственность за то, чтобы в процессе работы ни одно животное не пострадало. Графики, сроки, команда, бюджеты, релизы, качество – вот что в фокусе. Product Manager – это, скорее, про маркетинг, стратегию, приоритеты, трафик, сегменты, конкурентов.
Но работы полно и там, и там. Более того, хороший руководитель проекта должен владеть продуктовыми техниками, чтобы лучше понимать потребности бизнеса. А хороший руководитель продукта должен вырасти из руководителя проектов, чтобы понимать возможности и ограничения своей команды и иметь адекватную картину мира. Именно поэтому в этой книге есть техники для обеих специальностей.
В ней также найдутся ответы на те непростые вопросы, с которыми сталкиваются начинающие и уже опытные менеджеры проектов и продуктов ежедневно:
▶ как общаться с подчиненными, чтобы не быть в их глазах мямлей или деспотом;
▶ как грамотно делегировать и что придется в себе искоренять, чтобы это уметь;
▶ почему Scrum – все еще передовой фреймворк для разработки проектов и продуктов в digital и как его внедрить в свою команду;
▶ как и с помощью каких инструментов проводить аналитику перед стартом проекта, чтобы в процессе разработки не случалось неприятных сюрпризов;
▶ что такое декомпозиция, зачем она нужна на проекте и как грамотно составлять сметы, чтобы потом не было мучительно больно и стыдно перед заказчиком;
▶ как управлять творческими сотрудниками и креативным процессом без магии, шантажа и подкупа;
▶ как строить команду, чтобы людям хотелось приходить на работу и расти профессионально;
▶ как распределять собственное время менеджера эффективно и при этом не выгореть и не уехать в бессрочный отпуск;
▶ что лучше: собственная команда или аутсорс и как быть с техподдержкой;
▶ как не плодить бюрократию, но при этом четко оформить процесс разработки документально;
▶ как интегрировать сайты и продукты с внешними сервисами и системами без моря слез;
▶ что делать, если все пошло не по плану и случился факап на проекте;
▶ и как, черт побери, понять все то, что ежедневно говорит тебе команда на своем айтишном языке.
Полистайте содержание. Посмотрите главы. Загляните в задания после каждого блока. Если есть сомнения – поставьте, где взяли. Не поможет. Особенно, если не планируете постоянно практиковаться. В книге, конечно, есть забавные истории, примеры, кейсы, чек-листы и шаблоны, которые можно брать и сразу применять. Но это – инструмент, а им нужно пользоваться!
Часть 1
Картина мира digital-проекта. Тонкости делегирования в IT
Возьмем такую задачку: довести сайт до ума.
Нет, я не пошутил с формулировкой. Таких задач – доделать за предыдущими разработчиками – на фриланс-биржах пруд пруди. И несчастные сотрудники в них периодически вляпываются. Допустим, вы – менеджер, у вас микрокоманда: дизайнер, программист, аналитик, тестировщик. С которыми вы раньше не работали. И есть еще бизнес-заказчик, нешибко разбирающийся в digital-премудростях, но уже почему-то раздраженный. Он эту карусель оплачивает, если его устроит цена и качество. Понятно, что его в первую очередь интересуют деньги и сроки. Ваши действия?
Правильно: бежать!
А что нас смущает? Запредельная степень неопределенности? Тухлая перспектива? Неуверенность в команде? Непонятки с оплатой? Неадекватный заказчик? Поехали, потом заведешься? Гарантированный геморрой при негарантированном результате?
Давайте мысленно представим, как выглядит картина мира digital-проекта и сколько возни тут вырисовывается.
1.1. Картина мира digital-проекта
Итак, в нашей минимальной картине мира сразу получается куча объектов. И с каждым из них много возни и неопределенности. Объекты связаны, влияют друг на друга, за всеми приходится следить и что-то корректировать. Давайте разбираться, пока поверхностно, потом пойдем в дебри.
Заказчик может быть чертовски сложно устроен: не один человек, а группа (с противоречивыми интересами, требованиями к проекту и даже конфликтами). А еще бывают скрытые агенты влияния, например, у заказчика – жена, с которой он советуется, и ее мнение в итоге будет определять эстетическую сторону проекта. Но вы об этом не узнаете.
У заказчика определяющая роль. Он формирует концепцию проекта, приоритеты, финансирует весь карнавал. От него зависит все: что бы вы как менеджер ни делали, всегда остается шанс упереться в стенку на той стороне. Именно заказчик определяет степень успешности проекта. Подробнее о работе с заказчиком поговорим в главе 9.
Различают два ключевых формата работы. Time & Material – оплачивается время, затраченное командой, в таком случае задачи можно менять как угодно. И Fixed Price – цена и задачи оговариваются на берегу. У обоих вариантов есть как плюсы, так и минусы. Time & Material переносит риски на заказчика, но работу можно организовать быстрее и гибче. Fixed Price – заставляет разработчика зашивать риски и подстраховку в смету, лишает гибкости и снижает скорость выпуска функций из-за процедуры согласования бюджета, но яснее воспринимается клиентом. Существуют также гибридные модели.
Условия заказчика регламентируются тремя способами:
Команда проекта. В digital команда может сжиматься до одного человека, а-ля веб-мастера, и включать в себя заказчика. Либо наоборот: разрастаться, выделяя отдельные функции в роли. Как строить и выращивать команды, мы разберем в главе 7. Командная работа подразумевает делегирование. Например, менеджер справится с задачами аналитика и тестировщика, но с ростом проекта целесообразно выделить это в отдельные роли. Или программист может администрировать серверы, если квалификация соответствует. Но как только серверного хозяйства становится много – приходится выносить это в отдельную роль – администратора. Для примера будет такая команда:
Поле власти. Что-то типа электрического поля, к которому подключаются менеджерские инструменты типа «делегирования». Подробнее про власть разберем в главе 2.
Кто для вас главнее: заказчик или руководитель, и что делать, если у них противоречивые требования? Например, заказчик попросил изменить процесс: нарисовать дизайн до аналитики. Можно ли? Да, если согласуете с руководителем. Приоритет отдавайте руководителю. При этом никто не против, чтобы клиент был счастлив.
Еще несколько компонентов digital команды:
Проект. Это набор артефактов, в основном – файлов:
▶ Код, как правило, в репозитории.
▶ Визуал – макетов, прототипов, гайдлайна и т. д.
▶ Серверная инфраструктура, на которой ведется разработка, тестируется или работает сам проект.
▶ Разноуровневый Доступ и хранение паролей.
▶ Кроме кода и визуала в проекте обязательно есть Данные. Это либо база, либо контент, ради обработки которых проект и затевался.
▶ В развитых проектах код покрывают Тестами и пишут формальные Тест-планы выпуска продукта.
▶ Большинство проектов взаимодействуют с Внешними сервисами. Например, авторизуют пользователей через социальные сети или рассчитывают стоимость доставки товара. Для этого разработчики выполняют интеграцию через API. Подробности в главе 10.
▶ Наконец, в зрелом проекте обязана быть Документация. Ее главная задача – отчуждение знаний о проекте из голов конкретных исполнителей. Документация снижает риски.
1.1.1. Прогулка по картине мира
Итак, мы героически вляпались в задачу «довести сайт до ума». Как бы я действовал (кое-где – чужими руками)?
Жуть, этот план даже читать больно! А ведь вам завтра крутить окровавленную и облитую слезами ручку digital-разработки:)
▶ Поинтересовался, почему расстались с предыдущим разработчиком, на какой ноте, кто это был. Навел бы справки. По возможности переговорил с разработчиком, составил свое мнение.
▶ Получил от клиента предварительный список требований и задач. Рассказал всю процедуру и описал риски. Запланировал время на то, чтобы вникнуть в чужой код. Возможно, его придется полностью удалить, и все написать по новой. Первое время наша скорость будет ниже, чем у предыдущей команды, и у нас будет больше ошибок, потому что мы не знаем всех взаимосвязей. Также обсудил условия, при которых можно попробовать взяться за задачу.
▶ Грубо оценил стоимость проекта (вилочно, от-до), получил подтверждение бюджета у клиента.
▶ Согласовал работу по Time & Material. Работать с чужим проектом по Fixed Price – самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие дальнейшие планы на сотрудничество. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали – в этом случае посоветовал бы закончить проект с предыдущей командой.
▶ Запросил доступы к коду.
▶ Провел код-ревью – процедуру анализа и оценки качества кода.
▶ Изучил текущую документацию. Если документации нет – это тоже показатель.
▶ Принял решение, можно ли работать с текущим кодом или нужно выбросить и все делать с нуля.
▶ Подписал контракт.
▶ Получил предоплату.
▶ Еще раз уточнил требования. Собрал их в бэклог. Отсортировал по приоритетам. Организовал работу спринтами.
☐ Нарисовал прототипы. Сдал клиенту.
☐ Нарисовал дизайн, если задача это предполагает. Также сдал клиенту.
☐ Еще раз проговорил голосом результат с заказчиком, убедился, что мы все одинаково понимаем.
☐ Доформировал требования на уровне задач в тикет-системе с учетом изменений, которые появились в дизайне и прототипе. Обычно это мелочи, но иногда все разворачивается на 180°.
☐ Дал вычитать требования разработчикам.
☐ Проговорил задачи голосом с командой, ответил на вопросы. Получил оценки от команды, например, методом Planning Poker (подробнее в главе 3).
☐ При необходимости провел рисерч. Это нужно для задач, с которыми команда никогда не сталкивалась.
☐ Запланировал разработку в календарном плане.
☐ Написал тест-кейсы или критерии приемки по каждой из задач.
☐ Запрограммировал. Следил за ходом работ, решал «затыки».
☐ По итогам разработки провел код-ревью нового кода.
☐ Протестировал, исправил баги.
☐ Проверил производительность.
☐ Сдал заказчику проект на тестовом сервере, получил и обработал обратную связь. Мелкие недочеты исправил сразу, остальное перенес в будущие спринты.
☐ Провел ретроспективу с командой, посмотрел, что можно улучшить в проекте и процессах работы.
☐ Актуализировал документацию.
☐ Провел деплой (выкладку на боевые сервера).
☐ Обновил контент.
☐ Проверил работу на боевом сервере.
☐ Подписал акты, получил постоплату.
▶ Выяснил, что еще хотел бы клиент, повторил бы цикл. Сам предложил улучшения проекта: по коду, функциям, дизайну, удобству и простоте использования.
▶ Организовал работу по мелко-срочным отвлекающим тикетам (по более дорогой ставке), выполнение которых клиент не готов ждать.
В общем, у менеджера тут много дел. Причем, ценность большинства из них воспринимается клиентом весьма гадательно. И хорошо бы что-то делегировать.
Час нормального проджекта должен стоить не менее часа нормального психолога.
1.1.2. Кривая роста мастерства
Как выглядит кривая роста компетенций и профессионализма руководителя? А это действительно кривая.
Кривая роста мастерства
1. Бурный рост
Для человека все ново, он заинтересован и очень быстро осваивает то, что называется «язык отрасли». Это как игра на гитаре, мальчики поймут: вам показали пять аккордов, вы освоили их за три дня и, в принципе, большинство песен во дворе уже можете петь под гитару. Все девушки ваши.
Хотя уже и на этом этапе часть людей отвалится, потому что поймут – это не для них. Такой начальный профессиональный сплит-тест – «да-нет».
2. Страшно и ни черта не понятно
Дальше расти сложнее. Надо барре ставить, табулатуры разбирать, или (боже упаси) ноты учить. И получается, что усилий нужно прилагать все больше и больше, а видимых достижений – все меньше и меньше. Уменьшается и количество людей, которые могут оценить ваши успехи. Страшно и ни черта не понятно.
Здесь-то многие и сдаются. Особенно юные быстро обучаемые дарования. Интересней нахвататься по верхам, стать лучшим математиком среди гуманитариев или лучшим менеджером среди программистов. Лучшим летчиком среди парашютистов и так далее.
В психологии известен эффект Даннинга-Крюгера. Смысл его в том, что дилетант ведет себя, как правило, очень самоуверенно. Он чего-то нахватался, каких-то догм, и свою уверенность строит на этих догмах.
В свою очередь более профессиональный человек начинает терзаться сомнениями, поскольку уже отходит от догм, видит их ограничения, исключительные ситуации и нюансы. Начинает думать не так категорично. Поэтому со стороны порой кажется, что знания новичка, его повадки – более убедительны, чем знания профессионального специалиста, который говорит с большим количеством оговорок. Но со временем, с опытом, если человек прогрессирует – неуверенность уходит. Когда человек становится экспертом – он не так категоричен, как новичок, но уже точно знает, что сработает, а что – нет.
В росте компетенций менеджера такие перепады настроения – от ощущения всемогущества до ощущения собственного бессилия – абсолютно нормальная история. Более того, если вы таких перепадов не испытываете – значит, перестали расти.
Что делать? Просто продолжать, несмотря на страх и неясность. В какой-то момент картинка встанет на место. У кого-то этот путь занимает полгода, у кого-то – год. При этом нужно уделять больше времени практической работе на боевых проектах, а не теоретизированию.
3. Ясность мысли
Итак, после того, как с «детскими болезнями» разобрались, менеджер постепенно начинает набирать авторитет, опыт, компетенции. Вырабатывает, что называется, стиль.
Он хорошо знает правила компании, методологии, и мало-помалу начинает успешно вести проекты.
И вот тут, после первых нескольких успешных кейсов, его ждет ловушка. Дело в том, что многие вещи для менеджера уже привычны. Если раньше, например, он кропотливо работал по правилам, старательно фиксировал договоренности, мало импровизировал – то с какого-то момента он начинает чувствовать себя уверенным и крутым. И начинает эти правила нарушать.
4. Яма
Менеджер не справился с управлением, но вовремя ушел на больничный.
Стратегия полу-управленца
Менеджер почувствовал силу и начинает экспериментировать с правилами и подходами. И в какой-то момент у него начинают «сыпаться» проекты.
Например, сначала, работая с клиентами, вы все им подробно объясняли. Потому что вам самим нужно было проговорить, что и как будет. А потом вам это стало ясно-понятно. И вы перестали объяснять. И врезались в стену непонимания. Вам все очевидно, а клиенты стали как-то тупить (так это будет выглядеть для вас) и стали несговорчивыми. Причем, резко, все разом. Обычно критическая масса косяков копится, и все они вываливаются на разных проектах, но примерно в одно и то же время.
Как-то один из наших руководителей проектов пожаловался, что клиенты не понимают очевидные вещи: что такое верстка, чем она отличается от дизайна и программирования. Начались недопонимания – за что выставляется каждый конкретный счет. Приходится тратить время на урегулирование этих непониманий, а времени лишнего нет. Как выяснилось, руководитель проекта где-то поймал установку «раз уж мне очевидно – значит и клиенты должны знать, как все устроено». Однако это так не работает. Мы разобрали ситуацию. Поняли, что без резкого снижения нагрузки на менеджера нам не вырулить. Передали два проекта другим руководителям и составили «график некидалова» – недельные планы, в которых менеджер имел права заниматься не более чем двумя проектами в день. Но полноценно и сосредоточено, с созвонами, отчетами и временем на обучение клиента. Примерно через 6 недель ситуация стабилизировалась: менеджер стал меньше уставать, клиенты начали ставить хорошие оценки за этапы. Но если бы ситуацию пустили на самотек – менеджер вряд ли справился бы самостоятельно.
Это – яма. Из нее выкарабкиваются не все. Где-то семь-восемь из десяти. Тут некоторые, скажем так, кривые на душу люди, проявляют себя не с лучшей стороны, показывают свое «искусство вовремя уйти в сторонку». Причем, желательно «пока еще все хорошо». Кровь и ошметки приходится расчищать другим.
Яма неизбежна. Лучше всего, если в этот момент рядом будет опытный наставник, который вовремя протянет руку и из этой ямы вытащит.
Карабкаться сложно. Моя рекомендация: если вам невмоготу, если вы понимаете, что запутались – поговорите об этом с вашим начальником открыто, поищите вместе пути решения. В большинстве случаев вы сможете составить план и за пару месяцев выйти из кризисной ситуации, многому для себя научившись.
И даже если вы решите, что дальше с этой компанией вам не по пути – не бросайте за собой горящие города. Да, по закону вы можете махнуть рукой или шашкой: «А любись оно все конем», и через две недели ощутить вкус свободы. Но таких блуждающих менеджеров на рынке много. И кармически правильно будет привести дела в порядок, пускай это займет и два, и три месяца вашей плотной работы с вашим руководителем. Так правильно, так экологичнее. Вы большему научитесь и сможете сохранить лицо.
К счастью, большая часть людей яму преодолевает.
5. Мастерство
После кризиса уровень менеджера радикально меняется. У него появляется внутренняя уверенность. Он находит решения даже в сложных ситуациях. Такие менеджеры могут не только делать проекты, но и научить других. Это – опора компании. Факапы на этом уровне, безусловно, останутся, но справляться с ними будет уже легче.
На этом этапе руководитель проектов ищет задачи сложнее, интереснее. Он выступает на конференциях и тестирует новые технологии. Дорога в мир настоящих, жирных факапов!
Тут появляется риск перегореть – это когда после рабочего дня ничего не хочется, а сил хватает, только чтобы смотреть в стену и молча ненавидеть людей. Возникает желание уйти в монастырь, заняться духовными практиками или стать буддой. В общем, уйти в себя. Что делать – жизнь-боль, а в конце мы умираем.
На этой стадии очень важно научиться быстро расслабляться и быстро концентрироваться на задачах. Попробуйте спорт, хобби, медитации, путешествия. Кому что. Важно найти баланс между отдыхом и работой и перейти в режим гроссмейстера – когда задач решаете много, но в каждый конкретный момент сконцентрированы.
Самое интересное, что на этом развитие не заканчивается. Управленческое мастерство ничем не ограничено, нет предела совершенству, но к нему нужно стремиться.
1.2. Делегирование
Делегирование – это передача части полномочий или ответственности другим людям. Как правило – своим подчиненным.
Делегирование невозможно без грамотного планирования. Банально, у вас не останется времени ни на постановку задач в нужной форме, ни на контроль. О планировании времени мы поговорим в главе 8.
Делегирование – ахиллесова пята российского менеджмента. Руководители делегируют плохо, боятся или ленятся это делать. Многие просто не умеют, поскольку делегированию, как и вождению автомобиля, нужно учиться. Менеджер, который не умеет делегировать, – бутылочное горлышко организации: он набирает на себя слишком много задач и стремится самостоятельно сделать их большую часть. Грамотное делегирование – это точка роста организации.
Вы как менеджер можете вообще ничего не делать своими руками и ничего не производить. Но при этом вы отвечаете за выработку управленческих решений, распределение задач, нагрузку своих подчиненных. Делегирование – это передача подчиненному задачи вместе с необходимыми для ее выполнения ресурсами. Например, полномочиями и ответственностью: за качество, сроки и другие явно или неявно согласованные параметры.
1.2.1. Что делегировать. Делегирующая сила
Я завел себе регулярную привычку – раз в полгода просматриваю список дел, которыми занимаюсь. Смотрю, сколько времени они у меня отнимают. Оцениваю, насколько они мне нравятся и насколько они стали рутинными. Смотрю, должен ли я их делать сам. Можно ли делегировать что-то из рутины, неприятных мне дел или тех задач, где лучше справится специалист. Планирую: когда, кому и что я могу делегировать и в каком виде.
Помогает табличка – что можно, а что нельзя делегировать:
Советую завести себе подобный ритуал или регулярную задачу в вашем таск-трекере (планировщике). И постепенно увеличивать вашу делегирующую силу.
1.2.2. Устно или письменно
И тот, и другой вариант уместен, но у обоих есть ограничения.
Основной плюс устного делегирования – это быстрее. Годится только для небольших, ясных и привычных заданий. Для команд, которые все понимают одинаково. Для сложных, непривычных заданий есть минусы:
▶ Сложно учесть все детали при постановке. Кто мало думал, тот много плакал.
▶ Подчиненному сложно запомнить множество деталей.
▶ Может аукнуться временем на переделку и повторным делегированием.
▶ Не оставляет артефактов. Появляется искушение при разборе полетов переиграть постановку («а я тебе сказал так-то», «а я тебе этого не говорил…»). Очень плохая практика, которая разлагает рабочую атмосферу. Да и в эту игру могут играть оба.
Письменное делегирование дает время обдумать детали. В итоге получается точнее. А размышления о предстоящих деталях минимизируют количество ошибок. Минусы:
▶ Требует времени на написание ТЗ.
▶ У подчиненного нет возможности уточнить задание в момент его получения.
▶ У вас нет возможности предварительно убедиться, что вас поняли правильно. Пропущен предварительный контроль.
Лучше работают гибридные варианты.
Текст + обсудить. Для сложных заданий – с чек-листами, условиями, пунктами и подпунктами – сначала пишем текст, потом даем прочитать и обсуждаем устно вопросы. Идеально для постановки задач программистам.
Если деталей в задаче слишком много, лучше разбить такие задания на несколько. Проще пропустить один пункт из 30, чем один пункт из пяти.
Сервис «Главред»
Выработайте ясный, четкий стиль. Помогает книга Ильяхова «Пиши, сокращай» (в конце главы есть список литературы). Можете даже первое время для тренировки прогонять постановки через сервис glvrd.ru – программа дает оценку качества стиля. Пользуйтесь сервисом, пока не почувствуете, что справляетесь без него. Постановки длиннее трех-четырех предложений навевают тоску. Не стоит писать длинные инструкции из-за паранойи и личных страхов.
Устно + проверка фиксации. Дать устное распоряжение или даже провести брейншторм, обсудить вопросы, спросить план действий и проверить, как задание было зафиксировано. Тут работает «эффект генерации» – мы лучше запоминаем то, что изложили сами. Можно зафиксировать итоги и ключевые точки самому, но это не так эффективно. Большинству клиентов удобно давать постановки в таком виде. Хорошо работает с дизайнерами, да и в принципе удобный способ.
1.2.3. Список «поручил-контролирую» и сроки о сроках
При устном делегировании вам нужно будет каким-то образом вспомнить о своем задании и своевременно его проверить. Я держу в личном таск-трекере список «поручил-контролирую», где кратко, пофамильно записано: кто что обещал и когда (или когда будет контрольная точка).
Продолжить чтение