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

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

Наша задача – научиться применять этот механизм профессионально.

2.3.1. Поле власти

У Александра Фридмана вычитал интересную аналогию с полем власти: это вроде электричества, к которому подключаются управленческие инструменты типа делегирования, контроля, мотивации и так далее. Если поле власти сконфигурировано правильно – инструменты работают адекватно. Аналогично с электричеством: параметры тока в розетке верные – устройства работают нормально. Если нет – устройства глючат или даже сгорают.

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

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

2.3.2. Самозахват

Давайте посмотрим на поле власти на простой модели.

Вот компания состоит всего из 2-х человек – менеджера и программиста – и между ними как-то распределилась власть. У кого власти должно быть больше?

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

Таким образом, в поле власти может возникнуть красная зона, где люди по-разному понимают круг своих обязанностей, свою зону ответственности и свои права.

Плохо, если сотрудники в компании не знают, как именно власть распределена; плохо, если знают по-разному. Такая мышиная возня отнимает у компании много энергии. В таких случаях вопрос решается повышением компетенций руководителей (нужны энергичные живчики), введением хороших корпоративных правил и наказаний (вплоть до замены нелояльных сотрудников). То есть, долго и дорого.

Вариантов потерять власть – много. Например, самозахват.

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

Другой пример: одна моя сотрудница отвечала за организацию пятничного дизайн-баттла. Каждую пятницу ей нужно было придумать какую-то тему, собрать вечером дизайнеров на 1 час, в рабочее время. Дизайнеры ровно час рисовали по макету. Дальше нужно было организовать публичную презентацию (каждый дизайнер защищал свою работу), и можно было проголосовать за какой-то из макетов, выбрав победителя.

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

За самозахват бьют, и больно.

Чаще всего менеджеров продавливают, лишая прав:

▶ получать оценку оставшейся работы – от этого и программисты, и дизайнеры будут увиливать под любым соусом: мол, я не гадалка и не знаю, сколько времени это займет;

▶ выбирать инструменты и методы работы – проще говоря, технологии;

▶ выбирать, использовать ли готовые модули или писать с нуля;

▶ оценивать выполненную работу.

2.3.3. Как бы шутка

Допустим, я программист и сделал какую-то противозаконную гадость. Например, отказался оценивать задачи. Наотрез, категорически, навсегда. И менеджер-слабак это покорно принял.

Но, скорее всего, это не за один день произошло. До этого я готовил почву: всерьез обсуждал абсурдность тратить время на оценку задач. И никто меня в этом не остановил.

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

А до шутки я серьезно думал, что хорошо бы было избавиться от оценок, и никто меня в этих мыслях не остановил.

А еще что-то было до того, как я про это подумал.

И чем дальше заходило дело, тем больше усилий нужно было, чтобы меня остановить.

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

2.3.4. Воля к власти

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

▶ можно было играться с прикольными и новыми технологиями (о которых другие программисты отзываются позитивно – так действует механизм причастности к успешной группе);

▶ работать по тем правилам, которые удобны;

▶ не отвечать за сроки и ошибки (намеренно использовал слово «ошибки», хотя оно не очень корректно – за ошибки наказывать нельзя).

И несильно себя напрягая? Как-то само собой происходит, что менеджеру навязывается воля программиста, а скрытой или явной угрозой будет его ворчание, токсичное поведение или программисто-зависимость. Борьба за власть выглядит как рациональная борьба за свободу.

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

Становиться руководителем пора только тогда, когда у вас появились важные личные цели, а добиться своими руками вы либо не можете, либо это слишком долго. Если со всем этим «управлением» разбираться не хочется, а хочется сидеть в своей норке и ни за что не отвечать – в менеджеры вам рановато. Выбор – либо командовать, либо подчиняться. Третьего не дано.

Кроме самозахвата, лени и страха, менеджер может потерять власть и своими неаккуратными действиями. Есть власть реальная, а есть – декларируемая или номинальная. И если менеджер очень сильно увлекается декларируемой властью, пишет какие-то грозные указивки, письма, задачи и требования, которые никто в итоге не исполняет, – его власть уменьшается.

Например, менеджер может потребовать у программиста каких-то новых отчетов, которых раньше не было. С точки зрения программиста – менеджер залез на его территорию. Что произойдет, если программист эти отчеты писать не будет, а менеджер при этом не будет настаивать? Очевидно, что реальная власть менеджера в этот момент уменьшится, а авторитет программиста в коллективе может увеличиться: какой он крутой, отстоял свои права.

2.3.5. Функции власти

Цикл Деминга «планируй-делай-проверяй-воздействуй» (PDCA, Plan-Do-Check-Act) – классическая диаграмма с точки зрения организации грамотной работы, о который мы уже упоминали в главе 1. Но если дополнить цикл с точки зрения функций власти, получится следующее:

▶ планируй – формируй принципы работы и картины мира подчиненных;

▶ делай – доводи правила до сотрудников;

▶ проверяй – обеспечивай соблюдение правил;

▶ воздействуй – награждай и наказывай.

Правда, есть этому циклу и классическая альтернатива, которая встречается в организациях довольно часто.

Функции власти

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

Доводите правила до подчиненных: где-то это уместно письменно, декларативно, где-то – устно, в виде обсуждений.

Декларативный способ – это как публикация закона: документ вышел, остается только его прочитать и исполнять. Метод резко снижает затраты на доведение правил. Минусы – не согласные с этими правилами подчиненные могут подвергать письменные документы неправильной трактовке, оглуплять и дискредитировать. Искажать не суть, а дух. Как-то так его прочитать вслух с хитрющей интонацией, что всем кругом станет смешно. Начните с описания проблемы, из-за которой возникло конкретное правило, объясните причины и приведите примеры. Еще один минус деклараций – для честных подчиненных, в случае возникновения вопросов, их будет некому задать.

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

Еще один вариант – доводить регламенты на общих собраниях. Техника хороша тем, что можно и ответить на вопросы, и посмотреть на реакцию сотрудников. В Scrum это уместно делать на ретроспективах – специальных собраниях, где обсуждаются проблемы проекта, ищутся решения и вырабатываются новые правила.

Минусы: вы работаете с умными людьми, и, когда будете доводить до них регламенты, – встретитесь с сопротивлением, подколками, хитрыми вопросами. Особенно если новые регламенты меняют распределение власти. Готовьтесь к работе с возражениями заранее.

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

Наблюдать за ходом работ. Здесь мне нравится понятие «гемба» из японского менеджмента – это то место, где производится ценность. С ним также связан принцип «Тойоты» «Иди и смотри» или, в зависимости от перевода, «Иди сначала в гемба и осмотрись!» Вылезь из своего долбанного онлайна, дойди ножками, и посмотри, как на самом деле люди работают.

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

По итогам контроля производим корректирующие воздействия. Раздаем поощрения и наказания.

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

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

2.3.6. Что будет, если нет?

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

Поэтому менеджер открывает свою любимую тикет-систему, пишет там задачки и ждет, когда они будут сделаны. Вообще, тикет-системы – это отличный инструмент, но вот чисто письменный подход работает на очень небольших проектах с низкой долей неопределенности. Чуть проект сложнее, чуть выше неопределенность – без личных обсуждений, без брейнштормов, без споров уже не обойтись.

2.3.7. Центрирующие парадигмы Фридмана

Центрирующие парадигмы – набор принципов, который был предложен Александром Фридманом для снижения управленческих издержек, формирования адекватного поля власти и выработки одинаковых правил игры. У нас они написаны на доске, на самом видном месте. Настоятельно рекомендую прочитать оригинал.

2.3.8. Источники власти: на что опираться в самом начале

Итак. Развитие требовательности – это не самая простая штука на земле. И начинать нужно с личного уровня. С требовательности к самому себе. Учиться не врать себе. Смотреть, где ты ленишься, не дорабатываешь. И заставлять себя доделывать или делать необходимые вещи. Это база.

Дальше нужно постепенно освоить источники власти:

▶ Полномочия или роль. Это то, что вам досталось, когда вас назначили менеджером.

▶ Право наказывать или награждать. Если вам оно дано; если нет – нужно его получить у своего руководства. Алгоритм можно найти в книге Сивожелезова «Сложные переговоры с подчиненными» – держите ее под рукой.

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

▶ Квалификация. Опыт. И результативность. Если вы крутой в каком-то деле – это тоже наделяет вас определенной властью. Авторитетом. Люди будут вас уважать, так как знают, что с вами можно добиться успеха и нужного им результата.

▶ Регламенты, стандарты отрасли, центрирующие парадигмы и другие нормирующие документы.

▶ Обычаи компании, неписаные правила.

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

Дальше можно найти того, кто явно слабее вас, и попрактиковаться на нем. Чем-то озадачить, посмотреть, как реагирует. Сможете ли вы справляться с его бунтами и закидонами. Если есть под рукой дети – попробуйте заставить их что-нибудь сделать. Например, съесть кашу, вместо того чтобы играть в айпад. Уверяю, это бесценный опыт, после которого вам будет практически все понятно про управление людьми.

Дальше. Если вы вступили в роль менеджера, и ваш руководитель обладает авторитетом, властью – можете смело поначалу опираться на его авторитет. То есть, поначалу отдавать распоряжения, действуя как бы от его имени: «Иван Иванович попросил, чтобы ты сделал кнопку красной. К какому часу это будет готово, скажи пожалуйста мне, чтобы я его сориентировал?»

Как только все ваши подчиненные к этому привыкнут – все, отдавайте распоряжения без ссылки на вашего руководителя. С опорой на вашу должность. Вы руководитель проектов, поэтому и требуете.

Далее – опора на привычку подчиняться.

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

Вот примерно такие ступеньки. Вообще, развитие требовательности можно вынести для себя в такой личный отдельный проект. Где-то на полгода-год.

2.3.9. Ступеньки требовательности и мастерства

Придется ли вам всегда проявлять агрессию? А вот это не факт. Давайте посмотрим, как это развивается.

Допустим, вы не готовы идти на конфликт. Окей. Конфликтов будет мало. Но результат будет за ваш счет. Ваших выходных или овертаймов, например.

Допустим, вы заводитесь с полоборота. Чуть что – сразу готовы идти на конфликт. Тоже не очень хорошо, окружающие будут от вас шарахаться.

Готов конфликтовать ради дела. Если надо подраться – подерусь. В общем, с этого уровня уже можно становиться менеджером. Хотя не все окружающие будут вам сильно рады. При этом руководство тут осуществляется лично. Лично отдаете распоряжения и лично, фактом своего существования, обеспечиваете, чтобы эти распоряжения выполнялись. Уже неплохо, но трудозатратно.

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

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

Вот это очень интересно. Хочу – иду на конфликт, хочу – не иду. Могу и так, и так и сам выбираю, когда и что применить. При этом все подчиненные довольны и счастливы – ну, потому что адекватное руководство, хорошая управляемость и высокая результативность.

Ну а дальше выход на уровень иррационального. Когда все проходит вроде как само собой.

Заметьте, с опытом необходимость идти на конфликт сначала возрастает, а затем спадает.

Через это, наверное, все руководители проходят. И пока они учатся конфликтовать, обязательно будут жертвы. Будут обиженные. Просто по неопытности. Кого-то слишком сильно отменеджерили – и все, теперь он ваш заклятый враг. Экологичнее тренироваться на тех, кого не жалко. Ну и ни в коем случае не на домашних, родных и близких. Ваша требовательность – это для работы. Домашние тут как бы ни при чем.

Итак. Слабые руководители не готовы проявлять требовательность. Испытывают дискомфорт или моральные муки из-за того, что им приходится заставлять коллег дело делать. Выражаться это может по-разному: от состояния «верните меня обратно с управленческой должности на линейную» до высказывания: «А я не хочу быть объектом эксплуатации и не хочу эксплуатировать!»

Гадость в том, что вас никто не спрашивает – хотите вы или нет. Вы либо командуете, либо подчиняетесь. Других вариантов не существует.

Мы как руководители заинтересованы, чтобы сотрудник оставался с нами как можно дольше и работал как можно продуктивнее.

Нужно еще и понимать, кем вы управляете. В диджитале это – айтишники: дизайнеры и программисты. А они, как правило, люди сытые. Сытыми управлять сложнее, чем голодными – приходится дополнительно напрягаться, ведь рублем их вряд ли замотивируешь (чем мотивировать – так сразу и не скажешь). Это люди умные, часто – с системным мышлением, и их задурить не получится. А вот с их стороны вы постоянно будете испытывать подколки и попытки проверить вашу власть на прочность. Кроме того, каждый из них – личность, каждый требует индивидуального подхода и по-разному реагирует на одни и те же слова и задачи.

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

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

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

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

2.4.1. Мозгоклюйство

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

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

2.4.2. Работа в потоке

Естественное состояние человека – расслабленное. Так задумано природой. Экономим энергию или, как говорит Макс Дорофеев, – мыслетопливо. И, если нас никто не напрягает, ничего не требует – мы на расслабоне: сделать что-нибудь не против, но так, чтобы это было интересненько и не слишком напряжно. Мороженку скушать, киношку посмотреть, новую программку потыкать.

Мозг легко заинтересовывается любой фигней, даже работой. Вы когда-нибудь читали за завтраком этикетки, например, от сока? Зачем? Непонятно, но очень интересно. А если еще и на казахском…

Поэтому задача менеджера – создать такую ситуацию или атмосферу, при которой человеку будет проще начать выполнять дело, чем разруливать последствия – «почему не начал?».

Но опять же. Мы управляем умными, творческими людьми. И минут через 15–30 работы они входят в состояние потока. Это когда ты сконцентрирован, мир вокруг как бы перестает существовать, тебя прет и хочется работать, работать и работать. Это супер-продуктивное состояние, результативность выше в десятки раз.

Помните, когда вы до ночи засиживались за делом или за игрой? Время течет незаметно, а все, что вы делаете, – доставляет удовольствие. Усталость не чувствуется, а если чувствуется – это «добрая» усталость, как после пробежки. Вот в этом блаженном состоянии программисты и дизайнеры кайфуют от работы.

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

Посчитайте, сколько раз вас нужно дернуть за день, чтобы вы задолбались, стали злым и раздражительным, но ничего толком не сделали? Вот поэтому я запрещаю дергать ребят без экстренных причин (по экстренным все же можно, только для начала мысленно сравните выгоду от «дернуть» и полчаса времени в утиль, а также готовьтесь обосновать экстренность) и прошу вырубить всплывающие уведомлялки чатиков.

Менеджеры в таком состоянии пребывают редко – нас слишком часто пытаются поюзать (коллеги, клиенты, чатики, почта). Учитесь закрываться. А для этого нужны такие правила игры, когда менеджер тоже может работать в потоке, и дергать его запрещено. Клиентам это, кстати, очень не нравится: нас приучили к мгновенным ответам. Нам кажется, что то, на чем мы сфокусированы в данный момент, и есть «самое важное», и если на наше «самое важное» не реагируют – мы либо теряем его из фокуса, переключаясь на другое «самое важное», либо раздражаемся. Стоит ли говорить, что через пару часов «самое важное» зачастую превращается в пустяк? Предварительный вывод: чатики – зло для продуктивности (про голосовые сообщения вообще молчу).

Ну да ладно. Допустим, вы попали в состояние потока. Знаете свою цель, вам – хорошо, и хочется работать еще и еще.

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

Менеджерская задача – держать человека в этой зеленой зоне графика, где ему интереснее сделать, чем не делать, и при этом вовремя забирать результат. То есть, обеспечить и интерес сотрудника к делу, и рентабельность его работы.

Для этого мы должны грамотно планировать его задачи и следить – интересно ли сотруднику, или он заскучал. Давать обратную связь, отдых, обучение. Словом, сервисное обслуживание. Можно ли тут сэкономить? Угу. Кратковременно добьетесь всплеска результативности, но в итоге получите текучку талантливых кадров, жуткую нагрузку на кадровый отдел и хреновую репутацию. А вместе с этим в долгосрочной перспективе – кратное увеличение себестоимости проектов.

2.4.3. Форсаж

Можно ли использовать людей в режиме форсажа? Ответ – да, можно. К форсажу можно прибегать, если этого требует дело, и если результат главнее последствий и выгорания людей. При этом вы должны понимать, что усталость, ошибки, демотивация возрастают. Но для понятной и великой цели, которую ЧЕТКО объяснили, и указали сроки, когда форсаж закончится, форсаж допустим и иногда даже полезен. Этакая встряска для организма.

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

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

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

На странице Википедии в списке когнитивных искажений целых 200 пунктов, и 199 вы, скорее всего, найдете у себя. Рассмотрим те, которые часто встречаются у работников digital-сферы и у людей интеллектуальных и творческих профессий. Зная, как работают когнитивные искажения, вы научитесь понимать, почему подчиненные капризничают, и сможете регулировать их поведение.

2.5.1. Слишком оптимистичные оценки работы

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

– Когда будет готово?

– Ну, мне осталось вот это, это и это доделать, и будет готово.

– Отлично, но когда именно будет готово?

– Ну, тут недолго, обычно…

– Так когда будет готово?

– Через 20 минут.

Еще один вариант – техника «А на какой вопрос ты сейчас отвечаешь?!» Если человек не дает конкретики и пускается в объяснения или изложение последовательности своих действий, просто скажите ему напрямую, что он отвечает не на тот вопрос, который вы задали.

– Когда будет готово?

– Ну, мне осталось вот это, это и это доделать…

– Ты сейчас на какой вопрос отвечаешь?

– Будет готово через 20 минут.

Кстати, если задаете несколько вопросов письменно (в одном письме или чате) – скорее всего, вам ответят только на самый удобный. Заведите себе привычку нумеровать вопросы, приучите своих орлов нумеровать ответы. Это несложно.

2.5.2. Генерализация частных случаев

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

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

Как и варан, менеджер кусает человека задачей. А после садится рядом и внимательно смотрит в его мониторчик. Он может даже не понимать, что делает подчиненный – это необязательно. Главное – быть рядом и следить. И – о чудо! – через непродолжительное время исполнитель поймет, что таки существует более простое и быстрое решение, чем то, которое он придумал сначала.

2.5.3. Это невозможно!

Среди когнитивных искажений можно выделить целую группу, которые мешают взяться за задачу. И все они сводятся к тому, что человек, чуть поковырявшись в постановках, упирается и заявляет: «Это невозможно!»

У такой реакции несколько причин:

▶ исполнителю просто лень;

▶ сработал эффект сопротивления, и человек хочет доказать, что он сам волен решать, что делать, а что нет;

▶ задача противоречит его чувству прекрасного.

В любом случае менеджеру нельзя верить в то, что задача невыполнима. Наоборот – он должен выяснить, какие ресурсы нужны исполнителю, чтобы ее сделать. Снова и снова долбить подчиненного вопросом: «Расскажи, пожалуйста, что тебе потребуется, чтобы сделать эту задачу?»

Опыт показывает, что со временем подчиненный понимает, что ему не верят, да и действительно задача не так уж и невыполнима… И в конце концов он ее выполняет.

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

2.5.4. Критика как личное оскорбление

Это искажение часто встречается у личностей творческих, особенно невыспавшихся и в плохом настроении. Чтобы вырулить ситуацию в конструктив и никого не обидеть, нужно действовать по следующему алгоритму:

1) Отделить хорошее и плохое.

2) В работе, пусть ее и нужно переделать, все равно были какие-то положительные моменты – вспомните их и похвалите исполнителя.

3) Объясните, в чем ошибка. Возможно, человек не знает, как эту ошибку исправить, и именно поэтому сопротивляется и бунтует.

4) Инициируйте повторное обсуждение или брейншторм по уже пройденным вопросам.

5) Попросите помощи коллег или дайте дополнительный ресурс – например, время на рисерч.

6) Настаивайте на переделке плохого.

7) Закрепите пройденный урок: выясните причину, почему искажение активировалось, и запомните, как вы его пофиксили.

К сожалению, многие начинающие менеджеры в этот момент либо боятся доводить дело до конца, либо ленятся. Но если следовать этому алгоритму – можно выйти на конструктив даже быстрее, чем вы ожидали.

2.5.5. Проклятие знания

Вот пример когнитивного искажения, которое называется «проклятие знания». Это когда человек более информированный не может рассмотреть проблему с точки зрения человека, который знает меньше. Отсюда столько непонятых гениев.

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

2.5.6. Эффект генерации

Не все когнитивные искажения – причина проблем и непонимания. Бывают и полезные. Например, «эффект генерации». Благодаря этому искажению человек лучше запоминает информацию, когда воспроизводит ее сам, а не воспринимает извне.

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

2.5.7. Слепое пятно

Еще одно когнитивное искажение: слепое пятно в отношении когнитивных искажений. Человек, который в курсе, что искажения существуют, отрицает их влияние на свое поведение. А последствия списывает на обстоятельства и на глупость окружающих. И, соответственно, не делает ничего, чтобы пофиксить свои когнитивные искажения.

Так что, если подчиненный говорит вам, что вы начитались книг по психологии, а задачу «Ну правда невозможно никак выполнить» – может быть, пора отдать задачу другому исполнителю.