Полная версия
Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий
Наша задача – научиться применять этот механизм профессионально.
2.3.1. Поле власти
У Александра Фридмана вычитал интересную аналогию с полем власти: это вроде электричества, к которому подключаются управленческие инструменты типа делегирования, контроля, мотивации и так далее. Если поле власти сконфигурировано правильно – инструменты работают адекватно. Аналогично с электричеством: параметры тока в розетке верные – устройства работают нормально. Если нет – устройства глючат или даже сгорают.
Всю власть в компании возьмем за 100 %, поделенных между сотрудниками. Причем, зачастую это распределение образовывается стихийно. По историческим причинам. И в результате взаимодействия сотрудников власть перераспределяется (у одного уменьшается, у другого увеличивается). Это архиважный тезис – вы что-то с кем-то делаете (или не делаете), а в результате у вас и у него меняется реальная власть.
Рекурсия: источник власти – в ее грамотном применении. Поэтому молодым руководителям проектов важно сразу начать применять ту небольшую власть, которая у них есть, для тех дел, для которых она годится.
2.3.2. Самозахват
Давайте посмотрим на поле власти на простой модели.
Вот компания состоит всего из 2-х человек – менеджера и программиста – и между ними как-то распределилась власть. У кого власти должно быть больше?
Менеджеры тут же скажут: «У менеджера!», а программисты на это ничего не скажут, но про себя хмыкнут: «Ну-ну, давай, покажи, что ты там из себя за менеджер». И можете не удивляться, если программисты считают менеджеров обслуживающим персоналом. Причем, назойливым, глупым, мешающим работать и думать об архитектуре, ставящим неадекватные задачи и вечно лезущим со всякой несущественной фигней.
Таким образом, в поле власти может возникнуть красная зона, где люди по-разному понимают круг своих обязанностей, свою зону ответственности и свои права.
Плохо, если сотрудники в компании не знают, как именно власть распределена; плохо, если знают по-разному. Такая мышиная возня отнимает у компании много энергии. В таких случаях вопрос решается повышением компетенций руководителей (нужны энергичные живчики), введением хороших корпоративных правил и наказаний (вплоть до замены нелояльных сотрудников). То есть, долго и дорого.
Вариантов потерять власть – много. Например, самозахват.
Допустим, у вас есть правило: «Получил задачу – оцени». Программист может сначала, как бы случайно, не оценивать задачи (типа, забыл). Если на это не отреагируют (ну сделал, и ладно) – не оценивать специально. Если попросят оценки – сказать: «Не знаю, не могу». А потом и вовсе поскандалить и отказаться оценивать задачи: «Вы, менеджеры, ни черта не понимаете в природе программирования, никаких оценок там дать нельзя…» Если менеджер не отреагирует – сформируется право обычая «Васе можно». И все: власть менеджера уменьшилась, а программист отвоевал себе свободу не думать перед началом работы и не отвечать за сроки.
Другой пример: одна моя сотрудница отвечала за организацию пятничного дизайн-баттла. Каждую пятницу ей нужно было придумать какую-то тему, собрать вечером дизайнеров на 1 час, в рабочее время. Дизайнеры ровно час рисовали по макету. Дальше нужно было организовать публичную презентацию (каждый дизайнер защищал свою работу), и можно было проголосовать за какой-то из макетов, выбрав победителя.
С одной стороны, это прокачивало навыки презентации, ускоряло дизайнеров и просто было весело. С другой, за долгое время проведения таких баттлов пошла профанация: часто работы не имели художественной ценности, а выигрывала самая укуренная. И вот в одну из пятниц я узнаю, что баттла не будет. «Как так?» – спрашиваю я. Ответ был таким: «А они отказались сегодня. Говорят, каждую неделю – слишком часто, давайте через неделю хотя бы». Тут много чего было нарушено, но острее всего – самозахват: дизайнеры захватили право решать, будет баттл или нет, а также, чем они будут заниматься в рабочее время по пятницам.
За самозахват бьют, и больно.
Чаще всего менеджеров продавливают, лишая прав:
▶ получать оценку оставшейся работы – от этого и программисты, и дизайнеры будут увиливать под любым соусом: мол, я не гадалка и не знаю, сколько времени это займет;
▶ выбирать инструменты и методы работы – проще говоря, технологии;
▶ выбирать, использовать ли готовые модули или писать с нуля;
▶ оценивать выполненную работу.
2.3.3. Как бы шутка
Допустим, я программист и сделал какую-то противозаконную гадость. Например, отказался оценивать задачи. Наотрез, категорически, навсегда. И менеджер-слабак это покорно принял.
Но, скорее всего, это не за один день произошло. До этого я готовил почву: всерьез обсуждал абсурдность тратить время на оценку задач. И никто меня в этом не остановил.
А до этого я прощупал почву – пошутил про глупость оценки задач, все посмеялись, и никто меня не остановил. Слова, сказанные как бы «в шутку» нужны, чтобы прощупать границу допустимого. Чуть-чуть наступаем на чужую территорию, кончиком носочка, но готовы в любой момент ногу одернуть.
А до шутки я серьезно думал, что хорошо бы было избавиться от оценок, и никто меня в этих мыслях не остановил.
А еще что-то было до того, как я про это подумал.
И чем дальше заходило дело, тем больше усилий нужно было, чтобы меня остановить.
Самозахват (да и любое нарушение) спускать с рук нельзя, но отвечать нужно соразмерно. Шутливый самозахват лучше остановить шуткой. Твердой по содержанию, но мягкой по форме. Например, программист как бы в шутку произносит: «А сдается мне, что оценивать задачи – это лишняя трата времени». И смотрит на вас добрыми глазами. Можно так же в тон, шутливо ответить: «А сдается мне, что не оценивать задачи – это попытка увильнуть от ответственности». Верните ему это же без агрессии, но с улыбкой.
2.3.4. Воля к власти
Кстати, вряд ли программисты сидят и серьезно думают «как бы так у менеджера власть оттяпать» – им это неинтересно (и даже брезгливо). Но вот как сделать, чтобы:
▶ можно было играться с прикольными и новыми технологиями (о которых другие программисты отзываются позитивно – так действует механизм причастности к успешной группе);
▶ работать по тем правилам, которые удобны;
▶ не отвечать за сроки и ошибки (намеренно использовал слово «ошибки», хотя оно не очень корректно – за ошибки наказывать нельзя).
И несильно себя напрягая? Как-то само собой происходит, что менеджеру навязывается воля программиста, а скрытой или явной угрозой будет его ворчание, токсичное поведение или программисто-зависимость. Борьба за власть выглядит как рациональная борьба за свободу.
Вторая частая причина потери власти – отказ от ее применения. В силу лени или страха. Применение власти требует поставить свою шкуру на кон (см. Н. Талеб, «Рискуя собственной шкурой. Скрытая асимметрия повседневной жизни»). Выбирая комфорт, мы выбираем отказ от власти. Или нам не нравится применять власть, потому что мы это делаем плохо. Не умеем, а прокачивать себя – ленимся. В итоге полно менеджеров, которые ни черта не решают. Робкие, пугливые, рукожопые, что-то вечно «передающие» и «выясняющие».
Становиться руководителем пора только тогда, когда у вас появились важные личные цели, а добиться своими руками вы либо не можете, либо это слишком долго. Если со всем этим «управлением» разбираться не хочется, а хочется сидеть в своей норке и ни за что не отвечать – в менеджеры вам рановато. Выбор – либо командовать, либо подчиняться. Третьего не дано.
Кроме самозахвата, лени и страха, менеджер может потерять власть и своими неаккуратными действиями. Есть власть реальная, а есть – декларируемая или номинальная. И если менеджер очень сильно увлекается декларируемой властью, пишет какие-то грозные указивки, письма, задачи и требования, которые никто в итоге не исполняет, – его власть уменьшается.
Например, менеджер может потребовать у программиста каких-то новых отчетов, которых раньше не было. С точки зрения программиста – менеджер залез на его территорию. Что произойдет, если программист эти отчеты писать не будет, а менеджер при этом не будет настаивать? Очевидно, что реальная власть менеджера в этот момент уменьшится, а авторитет программиста в коллективе может увеличиться: какой он крутой, отстоял свои права.
Совет
Если вы только начинаете отстаивать свою власть и авторитет в коллективе – для начала давайте сотрудникам небольшие и простые задания с большим запасом времени. Но добивайтесь 100 %-го выполнения. Не 98 %, а именно 100 %. И если все идет хорошо – постепенно увеличивайте нагрузку и сложность задач.
2.3.5. Функции власти
Цикл Деминга «планируй-делай-проверяй-воздействуй» (PDCA, Plan-Do-Check-Act) – классическая диаграмма с точки зрения организации грамотной работы, о который мы уже упоминали в главе 1. Но если дополнить цикл с точки зрения функций власти, получится следующее:
▶ планируй – формируй принципы работы и картины мира подчиненных;
▶ делай – доводи правила до сотрудников;
▶ проверяй – обеспечивай соблюдение правил;
▶ воздействуй – награждай и наказывай.
Правда, есть этому циклу и классическая альтернатива, которая встречается в организациях довольно часто.
Функции власти
Планируй
Планирование не терпит суеты, тут нужно действовать постепенно, настойчиво и последовательно. Мы должны продумать в своей голове порядок, по которому другие люди будут делать наш проект или вообще работать. То есть создать принципы, парадигмы, картину мира, правила и задачи, приоритеты.
ДелайДоводите правила до подчиненных: где-то это уместно письменно, декларативно, где-то – устно, в виде обсуждений.
Декларативный способ – это как публикация закона: документ вышел, остается только его прочитать и исполнять. Метод резко снижает затраты на доведение правил. Минусы – не согласные с этими правилами подчиненные могут подвергать письменные документы неправильной трактовке, оглуплять и дискредитировать. Искажать не суть, а дух. Как-то так его прочитать вслух с хитрющей интонацией, что всем кругом станет смешно. Начните с описания проблемы, из-за которой возникло конкретное правило, объясните причины и приведите примеры. Еще один минус деклараций – для честных подчиненных, в случае возникновения вопросов, их будет некому задать.
Альтернатива – беседовать и доводить правила до каждого сотрудника лично. Затратно по ресурсам, хотя, в случае наставничества дает обучаемому больше суперсилы. Как вариант, используйте видео-формат. У меня большая часть регламентов текстовые, но снабжены видео. Так сложнее исказить дух или трактовать по-своему. Но, если возникают вопросы и нет куратора, то и этого формата может быть недостаточно.
Еще один вариант – доводить регламенты на общих собраниях. Техника хороша тем, что можно и ответить на вопросы, и посмотреть на реакцию сотрудников. В Scrum это уместно делать на ретроспективах – специальных собраниях, где обсуждаются проблемы проекта, ищутся решения и вырабатываются новые правила.
Минусы: вы работаете с умными людьми, и, когда будете доводить до них регламенты, – встретитесь с сопротивлением, подколками, хитрыми вопросами. Особенно если новые регламенты меняют распределение власти. Готовьтесь к работе с возражениями заранее.
Доведение регламента до пользователей мало чем отличается от процесса продажи. Поэтому умение грамотно продать свое видение будущего, правил работы, регламентов, требований или выполняемых задач – очень важный навык для менеджера и для руководителя проектов.
ПроверяйНаблюдать за ходом работ. Здесь мне нравится понятие «гемба» из японского менеджмента – это то место, где производится ценность. С ним также связан принцип «Тойоты» «Иди и смотри» или, в зависимости от перевода, «Иди сначала в гемба и осмотрись!» Вылезь из своего долбанного онлайна, дойди ножками, и посмотри, как на самом деле люди работают.
Если что-то несложно проверить – проверяйте сами, смотрите сами, вникайте и разбирайтесь сами. Покликайте мышкой проект, а не слепо верьте тестировщикам, что там багов нет. Проверьте со своего телефона. Поиграйте с проектом. Ну и смотрите, как люди делают работу на своих рабочих местах. Наблюдайте сами, как люди работают, а не просто слушайте то, что они об этом говорят.
ВоздействуйПо итогам контроля производим корректирующие воздействия. Раздаем поощрения и наказания.
К сожалению, без инвестиции вашей личной энергии, без регулярного воздействия и выполнения этих операций, дело протухает. Кто-то должен крутить это колесо. Вялый, угрюмый, депрессивный руководитель убивает команду. И наоборот, позитивный и энергичный способен творить чудеса.
Сама система управления должна периодически пересматриваться: нет ли перегибов, тухляка, можно ли что-то улучшить. Так рождаются самообучающиеся, самоорганизующиеся команды, где роль менеджера – задавать ритм и производить энергию.
2.3.6. Что будет, если нет?
Среди менеджеров-интровертов редко, но встречается паттерн поведения, когда они все общение по проекту переводят в почту или в тикет-систему, а лично с исполнителями никогда не общаются. Причина? Поскольку требовать трудно и токсично, можно столкнуться с сопротивлением – придется отстаивать свою позицию здесь и сейчас, но не у каждого на это хватает «пороху».
Поэтому менеджер открывает свою любимую тикет-систему, пишет там задачки и ждет, когда они будут сделаны. Вообще, тикет-системы – это отличный инструмент, но вот чисто письменный подход работает на очень небольших проектах с низкой долей неопределенности. Чуть проект сложнее, чуть выше неопределенность – без личных обсуждений, без брейнштормов, без споров уже не обойтись.
Совет
Отдавая распоряжение на проекте, особенно если оно касается каких-то непопулярных мер, – я рекомендую вспомнить замечательную песенку Семена Слепакова «Что будет, если нет?»
Что будет, если ваше распоряжение или обещание, или угроза не будут выполнены? Как вы будете действовать в этой ситуации? Важно заранее продумать меры, на которые вы лично готовы пойти, чтобы добиться нужного вам результата. Если не уверены, что распоряжение будет выполнено – не надо такие распоряжения отдавать. Вы просто дискредитируете себя, свою власть и свои полномочия.
2.3.7. Центрирующие парадигмы Фридмана
Центрирующие парадигмы – набор принципов, который был предложен Александром Фридманом для снижения управленческих издержек, формирования адекватного поля власти и выработки одинаковых правил игры. У нас они написаны на доске, на самом видном месте. Настоятельно рекомендую прочитать оригинал.
2.3.8. Источники власти: на что опираться в самом начале
Итак. Развитие требовательности – это не самая простая штука на земле. И начинать нужно с личного уровня. С требовательности к самому себе. Учиться не врать себе. Смотреть, где ты ленишься, не дорабатываешь. И заставлять себя доделывать или делать необходимые вещи. Это база.
Дальше нужно постепенно освоить источники власти:
▶ Полномочия или роль. Это то, что вам досталось, когда вас назначили менеджером.
▶ Право наказывать или награждать. Если вам оно дано; если нет – нужно его получить у своего руководства. Алгоритм можно найти в книге Сивожелезова «Сложные переговоры с подчиненными» – держите ее под рукой.
▶ Информация. Если вы знаете больше о проекте, волей-неволей люди к вам прислушиваются, у них формируются ожидания, что вы знаете, как надо действовать, и это дает вам дополнительную власть.
▶ Квалификация. Опыт. И результативность. Если вы крутой в каком-то деле – это тоже наделяет вас определенной властью. Авторитетом. Люди будут вас уважать, так как знают, что с вами можно добиться успеха и нужного им результата.
▶ Регламенты, стандарты отрасли, центрирующие парадигмы и другие нормирующие документы.
▶ Обычаи компании, неписаные правила.
▶ Ну и иррациональные вещи, такие как харизма, возраст, тембр голоса. То, что подсознательно воспринимается как «О, это наверное начальник. Крупная шишка». То есть, многие люди охотнее начнут подчиняться здоровому, брутальному, бородатому мужику, который говорит басом и со всех чего-то требует, чем молодому человеку с писклявым голосом, который прячет глаза за дипломом MBA.
Дальше можно найти того, кто явно слабее вас, и попрактиковаться на нем. Чем-то озадачить, посмотреть, как реагирует. Сможете ли вы справляться с его бунтами и закидонами. Если есть под рукой дети – попробуйте заставить их что-нибудь сделать. Например, съесть кашу, вместо того чтобы играть в айпад. Уверяю, это бесценный опыт, после которого вам будет практически все понятно про управление людьми.
Дальше. Если вы вступили в роль менеджера, и ваш руководитель обладает авторитетом, властью – можете смело поначалу опираться на его авторитет. То есть, поначалу отдавать распоряжения, действуя как бы от его имени: «Иван Иванович попросил, чтобы ты сделал кнопку красной. К какому часу это будет готово, скажи пожалуйста мне, чтобы я его сориентировал?»
Как только все ваши подчиненные к этому привыкнут – все, отдавайте распоряжения без ссылки на вашего руководителя. С опорой на вашу должность. Вы руководитель проектов, поэтому и требуете.
Далее – опора на привычку подчиняться.
И дальше уже выход на иррациональный уровень. Харизма, требовательный вид, голос, взгляд (жесткий или мягкий), интонация. Вы чего-то требуете, потому что так надо. Никому ничего не объясняя.
Вот примерно такие ступеньки. Вообще, развитие требовательности можно вынести для себя в такой личный отдельный проект. Где-то на полгода-год.
2.3.9. Ступеньки требовательности и мастерства
Придется ли вам всегда проявлять агрессию? А вот это не факт. Давайте посмотрим, как это развивается.
Уровень «Слабак»Допустим, вы не готовы идти на конфликт. Окей. Конфликтов будет мало. Но результат будет за ваш счет. Ваших выходных или овертаймов, например.
Уровень «Злоблин»Допустим, вы заводитесь с полоборота. Чуть что – сразу готовы идти на конфликт. Тоже не очень хорошо, окружающие будут от вас шарахаться.
Уровень «Боец»Готов конфликтовать ради дела. Если надо подраться – подерусь. В общем, с этого уровня уже можно становиться менеджером. Хотя не все окружающие будут вам сильно рады. При этом руководство тут осуществляется лично. Лично отдаете распоряжения и лично, фактом своего существования, обеспечиваете, чтобы эти распоряжения выполнялись. Уже неплохо, но трудозатратно.
Уровень «Дипломат»Умеет не только конфликтовать, но и договариваться. Конфликты редкие, но и готовность идти на них – низкая. Тоже неплохо, но дипломат при прямом столкновении с бойцом, скорее всего, проиграет. Поэтому предпочитает управлять через бюрократию, регламенты. А это не всегда продуктивно.
Уровень «Нормальный руководитель»Он, в случае чего, – готов идти на конфликт. Поставить негодяев на место. Обеспечить плохим людям проблемы и веселую жизнь. Все про это прекрасно знают. Поэтому на конфликт не нарываются. И конфликты становятся все реже и реже.
Уровень «Хороший руководитель»Вот это очень интересно. Хочу – иду на конфликт, хочу – не иду. Могу и так, и так и сам выбираю, когда и что применить. При этом все подчиненные довольны и счастливы – ну, потому что адекватное руководство, хорошая управляемость и высокая результативность.
Ну а дальше выход на уровень иррационального. Когда все проходит вроде как само собой.
Заметьте, с опытом необходимость идти на конфликт сначала возрастает, а затем спадает.
Через это, наверное, все руководители проходят. И пока они учатся конфликтовать, обязательно будут жертвы. Будут обиженные. Просто по неопытности. Кого-то слишком сильно отменеджерили – и все, теперь он ваш заклятый враг. Экологичнее тренироваться на тех, кого не жалко. Ну и ни в коем случае не на домашних, родных и близких. Ваша требовательность – это для работы. Домашние тут как бы ни при чем.
2.4. Нормальная эксплуатация и мозгоклюйство
Итак. Слабые руководители не готовы проявлять требовательность. Испытывают дискомфорт или моральные муки из-за того, что им приходится заставлять коллег дело делать. Выражаться это может по-разному: от состояния «верните меня обратно с управленческой должности на линейную» до высказывания: «А я не хочу быть объектом эксплуатации и не хочу эксплуатировать!»
Гадость в том, что вас никто не спрашивает – хотите вы или нет. Вы либо командуете, либо подчиняетесь. Других вариантов не существует.
Мы как руководители заинтересованы, чтобы сотрудник оставался с нами как можно дольше и работал как можно продуктивнее.
Нужно еще и понимать, кем вы управляете. В диджитале это – айтишники: дизайнеры и программисты. А они, как правило, люди сытые. Сытыми управлять сложнее, чем голодными – приходится дополнительно напрягаться, ведь рублем их вряд ли замотивируешь (чем мотивировать – так сразу и не скажешь). Это люди умные, часто – с системным мышлением, и их задурить не получится. А вот с их стороны вы постоянно будете испытывать подколки и попытки проверить вашу власть на прочность. Кроме того, каждый из них – личность, каждый требует индивидуального подхода и по-разному реагирует на одни и те же слова и задачи.
Руководителям digital-проектов вообще выпала доля иметь дело с наиболее трудно управляемой категорией людей: сытыми, умными, творческими индивидуалистами, у которых свое на уме и к которым порой нет физического доступа (удаленка рулит?). Но даже если вы рядом, посмотреть глаза в глаза и поговорить один на один зачастую трудно. Просто потому, что интроверты прячут взгляд и не любят подобного рода разговоров. Короче – сложно.
Задача менеджера – использовать потенциал, интеллект, время и ресурсы этих людей во благо своих проектов, и делать это грамотно. Грамотный руководитель должен понимать интересы сотрудника, его характер, мотивацию, знать его тактико-технические характеристики (хотя бы на уровне карт компетенций), уважать его свободу воли. В общем, знать и учитывать особенности при постановке задач и ведении проектов.
Нормальная эксплуатация
▶ своевременное планирование;
▶ грамотная настройка: постановка задач и целей;
▶ мониторинг и контроль;
▶ обратная связь;
▶ четкие границы допустимого (зеленая, желтая и красная зоны);
▶ системное сервисное обслуживание.
Диапазон допустимых режимов эксплуатации часто зависит от целей организации. Есть разница, когда компания работает ради денег здесь и сейчас, или когда она планирует зарабатывать и в будущем. Есть разница в ценностях компании: важно ли, чтобы сотрудники были счастливы, или этот параметр желателен (иногда и вовсе необязателен). Есть разница и в выпускаемом продукте – он рядовой (как туалетная бумага «Обычная») или им хочется гордиться?
Это те параметры, которые в западной литературе задаются в документах с громкими названиями «миссия» или «ценности компании». Сама идея таких документов – неплохая, но глупые шарлатаны ее окончательно испортили.
2.4.1. Мозгоклюйство
Наверное, каждый хоть раз ощущал на себе разницу, когда к нему отнеслись требовательно, но справедливо, а когда занимались мозгоклюйством? К сожалению, эту разницу не так-то просто формализовать. Если клиент говорит: «Сделайте мне сайт, как у Apple», как понять, это нормальное требование или мозгоклюйство? Вполне возможно, что нормальное, ведь допустимо, если мы в самом начале плохо представляем конечный результат. Ненормально, если мы не готовы тратить и выделять достаточное количество ресурсов исполнителю на поиск решения, зато готовы выделять бесконечное число яда для критики результата и личности исполнителя.
Причем, ресурсы – это не только деньги. Это и время, знания, навыки. Это конкретизация задачи, то есть готовность того человека, который ставил задачу, погрузиться в проект, потратить свое время на брейнштормы, обсуждения требований и обратную связь. Когда мы требуем от исполнителя «сделай то, не знаю что» или хотим, смутно понимая результат и не обсуждая конкретику, без экспериментов и права на ошибки, чтобы тот сам догадался, каким должен быть результат и как его достичь, – это уже не требовательность, а мозгоклюйство.