Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Шрифт:
Например, менеджер может потребовать у программиста каких-то новых отчетов, которых раньше не было. С точки зрения программиста – менеджер залез на его территорию. Что произойдет, если программист эти отчеты писать не будет, а менеджер при этом не будет настаивать? Очевидно, что реальная власть менеджера в этот момент уменьшится, а авторитет программиста в коллективе может увеличиться: какой он крутой, отстоял свои права.
Совет
Если вы только начинаете отстаивать свою власть и авторитет в коллективе – для начала давайте сотрудникам небольшие и простые задания с большим запасом времени.
2.3.5. Функции власти
Цикл Деминга «планируй-делай-проверяй-воздействуй» (PDCA, Plan-Do-Check-Act) – классическая диаграмма с точки зрения организации грамотной работы, о который мы уже упоминали в главе 1. Но если дополнить цикл с точки зрения функций власти, получится следующее:
планируй – формируй принципы работы и картины мира подчиненных;
делай – доводи правила до сотрудников;
проверяй – обеспечивай соблюдение правил;
воздействуй – награждай и наказывай.
Правда, есть этому циклу и классическая альтернатива, которая встречается в организациях довольно часто.
Функции власти
Планирование не терпит суеты, тут нужно действовать постепенно, настойчиво и последовательно. Мы должны продумать в своей голове порядок, по которому другие люди будут делать наш проект или вообще работать. То есть создать принципы, парадигмы, картину мира, правила и задачи, приоритеты.
Доводите правила до подчиненных: где-то это уместно письменно, декларативно, где-то – устно, в виде обсуждений.
Декларативный способ – это как публикация закона: документ вышел, остается только его прочитать и исполнять. Метод резко снижает затраты на доведение правил. Минусы – не согласные с этими правилами подчиненные могут подвергать письменные документы неправильной трактовке, оглуплять и дискредитировать. Искажать не суть, а дух. Как-то так его прочитать вслух с хитрющей интонацией, что всем кругом станет смешно. Начните с описания проблемы, из-за которой возникло конкретное правило, объясните причины и приведите примеры. Еще один минус деклараций – для честных подчиненных, в случае возникновения вопросов, их будет некому задать.
Альтернатива – беседовать и доводить правила до каждого сотрудника лично. Затратно по ресурсам, хотя, в случае наставничества дает обучаемому больше суперсилы. Как вариант, используйте видео-формат. У меня большая часть регламентов текстовые, но снабжены видео. Так сложнее исказить дух или трактовать по-своему. Но, если возникают вопросы и нет куратора, то и этого формата может быть недостаточно.
Еще один вариант – доводить регламенты на общих собраниях. Техника хороша тем, что можно и ответить на вопросы, и посмотреть на реакцию сотрудников. В Scrum это уместно делать на ретроспективах – специальных собраниях, где обсуждаются проблемы проекта, ищутся решения и вырабатываются новые правила.
Минусы: вы работаете
Доведение регламента до пользователей мало чем отличается от процесса продажи. Поэтому умение грамотно продать свое видение будущего, правил работы, регламентов, требований или выполняемых задач – очень важный навык для менеджера и для руководителя проектов.
Наблюдать за ходом работ. Здесь мне нравится понятие «гемба» из японского менеджмента – это то место, где производится ценность. С ним также связан принцип «Тойоты» «Иди и смотри» или, в зависимости от перевода, «Иди сначала в гемба и осмотрись!» Вылезь из своего долбанного онлайна, дойди ножками, и посмотри, как на самом деле люди работают.
Если что-то несложно проверить – проверяйте сами, смотрите сами, вникайте и разбирайтесь сами. Покликайте мышкой проект, а не слепо верьте тестировщикам, что там багов нет. Проверьте со своего телефона. Поиграйте с проектом. Ну и смотрите, как люди делают работу на своих рабочих местах. Наблюдайте сами, как люди работают, а не просто слушайте то, что они об этом говорят.
По итогам контроля производим корректирующие воздействия. Раздаем поощрения и наказания.
К сожалению, без инвестиции вашей личной энергии, без регулярного воздействия и выполнения этих операций, дело протухает. Кто-то должен крутить это колесо. Вялый, угрюмый, депрессивный руководитель убивает команду. И наоборот, позитивный и энергичный способен творить чудеса.
Сама система управления должна периодически пересматриваться: нет ли перегибов, тухляка, можно ли что-то улучшить. Так рождаются самообучающиеся, самоорганизующиеся команды, где роль менеджера – задавать ритм и производить энергию.
2.3.6. Что будет, если нет?
Среди менеджеров-интровертов редко, но встречается паттерн поведения, когда они все общение по проекту переводят в почту или в тикет-систему, а лично с исполнителями никогда не общаются. Причина? Поскольку требовать трудно и токсично, можно столкнуться с сопротивлением – придется отстаивать свою позицию здесь и сейчас, но не у каждого на это хватает «пороху».
Поэтому менеджер открывает свою любимую тикет-систему, пишет там задачки и ждет, когда они будут сделаны. Вообще, тикет-системы – это отличный инструмент, но вот чисто письменный подход работает на очень небольших проектах с низкой долей неопределенности. Чуть проект сложнее, чуть выше неопределенность – без личных обсуждений, без брейнштормов, без споров уже не обойтись.
Совет
Отдавая распоряжение на проекте, особенно если оно касается каких-то непопулярных мер, – я рекомендую вспомнить замечательную песенку Семена Слепакова «Что будет, если нет?»
Что будет, если ваше распоряжение или обещание, или угроза не будут выполнены? Как вы будете действовать в этой ситуации? Важно заранее продумать меры, на которые вы лично готовы пойти, чтобы добиться нужного вам результата. Если не уверены, что распоряжение будет выполнено – не надо такие распоряжения отдавать. Вы просто дискредитируете себя, свою власть и свои полномочия.