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

Владимир Завертайлов, 2022

Максимально полный путеводитель по профессии российского project-менеджера. В нем Владимир Завертайлов, основатель и руководитель scrum-студии «Сибирикс», которая входит в Топ-10 лучших веб-студий страны, рассказывает, как управлять собственным digital-производством и грамотно руководить проектом, заказывая digital-услуги на стороне. А еще – как расти в этой профессии, опираясь на знания о продуктовых техниках и понимая потребности бизнеса. Из книги вы узнаете: – чем kanban отличается от scrum и при чем тут agile; – как управлять неуправляемым – дизайнерами; – что лучше: собственная команда или аутсорс и как быть с техподдержкой; – откуда берутся оценки времени и как понять, что исполнитель их завышает; – что такое декомпозиция, зачем она нужна на проекте; – как планировать экономику проекта, рассчитывать операционные затраты и анализировать P&L продукта. В карточку подгружен издательский PDF макет.

Часть 2

Требовательность: как развивать ее у себя и своих сотрудников

2.1. Сколько программистов нужно, чтобы выкопать яму?

Давайте решим такую задачу (гротескная, но так будет веселее).

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

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

Сформулировали? Если вы использовали, например, смарт-подход и умеете развешивать контрольные точки, у вас могло получиться что-то типа: «Вася, нужно выкопать яму 30×30×30 см для захоронения офисного котика. А то он сдох, и нам тут скоро всем будет очень душно. Вон в том углу забора. Сегодня до обеда. Лопату возьми в сарае, вот тебе ключ. Справишься? А есть шанс, что не справишься?»

Теперь усугубим. Допустим, вы руководитель диджитал-проектов, а Вася — программист. Вы произносите похожую мантру (мол, выкопай яму, очень надо). Он смотрит на вас честными глазами. И говорит: «Не-хо-чу!» Ваши действия?

Первая естественная реакция: «Ну что за бред! Почему я должен уговаривать программиста заниматься непрограммистскими делами?» Потом идут попытки:

▶ надавить на Васю трудовыми обязанностями (облом, Вася знает, что его дело — код писать, а не ямы копать);

▶ уболтать на личном уровне: либо по-дружески, либо девушкиными ходами, строя глазки (облом, Вася — интроверт, идеалист и женатик);

▶ подкупить премией или даже напугать штрафами (не прошло, у программистов все нормально с зарплатами, а с угрозами штрафов идите вы знаете куда? — правильно, в трудовую инспекцию);

▶ или сослаться, что это дебильное задание дало вышестоящее руководство (совсем гнилой ход, особенно с точки зрения морали — фу так делать! — и Вася вас раскусит).

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

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

Теперь представьте, что вы приходите к программисту, вам срочно надо кнопку на сайте перекрасить. Из красной в зеленую. Потому что клиент рвет и мечет (мантры, вроде «URGENT! IMPORTANT! ВЫ НЕ КЛИЕНТООРИЕНТИРОВАННЫЕ» и т. д.). Никак свою задачу не мотивируя. Клиент имеет, наверное, право ничего не объяснять за свои деньги, но это не точно.

А программист Вася вместо того, чтобы за две минуты поправить CSS-файлик, да еще и варианты вам показать с экрана в Developer Tools, начинает артачиться: «Не-хо-чу! Дизайн — это дело не программистское! Вот принесете мне отрисованный макет, утвержденный клиентом, я и поправлю. А то уже пять раз за день туда-сюда-обратно. Достали, менеджеры, блин, работать спокойно не дают».

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

Ключевых вопроса тут два:

1. Где та грань, когда вы требуете от программиста какого-то бреда (вроде выкапывания ямы), а где он просто говнится, чтобы вы отстали?

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

Начнем со второго вопроса. Требовательности.

2.2. Требовательность

Требовательность — базовое качество руководителя, в том числе — и руководителя digital-проектов. Это умение настоять на своем, отстоять интересы компании, команды, проекта и свои, если на эти интересы покушается вселенная.

В идеале управление digital-проектом сводится к расстановке приоритетов: это делаем в первую очередь, это — во вторую. Команда весело разбирает тикеты и дружно бежит их выполнять. Желательно автономно: сами подумали, сами быстро и качественно сделали. Вас же на всякую фигню не отвлекают. А только радуют результатами.

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

Требовательность плотно связана с понятиями «власть» и «эксплуатация». Про источники власти много любопытного у Макиавелли, Ницше и других великих умов мира сего. Власть божественная или государственная, бла-бла-бла… — нам так круто не надо. Для управления digital-проектами интересна власть, которая устанавливается внутри команды проекта и разделяет людей на тех, кто командует, и тех, кто подчиняется.

Требовательность — токсична, и в больших количествах — яд (вплоть до психосоматики). Давят сроки, обстоятельства, клиенты, объем параллельных проектов. И малейшее сопротивление требованиям или уточняющий вопрос команды исполнителей вызывает у перегруженного руководителя раздражение. Оставаться при этом еще и в позитивном настроении — сложно.

Я знаю целый класс руководителей уровня «директор по маркетингу», бегающих с конференции на конференцию, с выставки на выставку (в промежутках — в отпуск), забегающих в офис поработать на пару дней и тут же сливающихся на следующую выставку — лишь бы не заниматься управлением.

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

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

Забавно выглядит, когда руководитель, начитавшись книг по мотивации и самоорганизации или вернувшись с семинара, вдохновенно решает убрать вот эту самую токсичность управления от себя подальше. Прибегает в компанию и с криками «Ага! Мы с завтрашнего дня — бирюзовые!» пытается перевалить «головняк» на команду. А потом расстраивается, что не работает. И почему-то я не удивлен. Делегировать сначала научитесь!

Уверен, если бы в таск-трекерах была кнопка «Долбануть током» — она бы пользовалась популярностью. Пока такой кнопки нет, ею должны уметь становиться вы сами.

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

В долгосрочной перспективе для блага проекта, организации и ее обитателей сильная власть и требовательность предпочтительнее хаоса и анархии. Известный афоризм Гарри Трумэна, 34-го президента США: «Любое действительно эффективное управление на поверку оказывается диктатурой». При этом никто не против, чтобы все были довольны, счастливы и мотивированы. Как такового противоречия здесь нет.

Самоорганизующимся командам нужен самоорганизатор.

2.3. Механизм власти

Винтовка рождает власть.

Мао Цзэдун

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

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

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», как понять, это нормальное требование или мозгоклюйство? Вполне возможно, что нормальное, ведь допустимо, если мы в самом начале плохо представляем конечный результат. Ненормально, если мы не готовы тратить и выделять достаточное количество ресурсов исполнителю на поиск решения, зато готовы выделять бесконечное число яда для критики результата и личности исполнителя.

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

Мозгоклюйство — это требовательность без предоставления необходимых конкретному исполнителю ресурсов.

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

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

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

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

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

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

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

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

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

Чатики — зло для продуктивности.

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

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

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

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

2.4.3. Форсаж

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

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

2.5. Когнитивные искажения у дизайнеров и программистов

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

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

На странице Википедии в списке когнитивных искажений целых 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. Слепое пятно

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

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

2.6. Для тренировки

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

Начинайте с выдачи небольших заданий, но добивайтесь по ним 100 % выполнения. Сначала ставьте задачи тем исполнителям, которых вы психологически сильнее. Опирайтесь на власть своего руководителя, правила компании, парадигмы, стандарты отрасли, регламенты. Затем — на здравый смысл и эстетику. Постепенно переходите к иррациональному уровню.

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

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

И постарайтесь не перегнуть палку — уж больно хлопотно исправлять управленческие ошибки.

Литература

▶ Нассим Николас Талеб, «Рискуя собственной шкурой. Скрытая асимметрия повседневной жизни».

▶ Александр Фридман, «Вы или хаос. Профессиональное планирование для регулярного менеджмента».

▶ Александр Фридман, «Управление мышлением подчиненных: центрирующие парадигмы», аудиокнига.

▶ Павел Сивожелезов, «Сложные переговоры с подчиненными».

▶ Максим Дорофеев, «Джедайские техники» и «Путь джедая».

Пояснения

Рекурсия — ситуация, когда объект является частью самого себя. Если у вас украли кредитную карту, позвоните по номеру на обороте кредитной карты.

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

Большинство современных промышленных систем реализованы с использованием паттерна проектирования приложения MVC (Model View Controller) или его производных. Не все, это не догма, есть и альтернативные варианты, но этот подход чаще всего применяется. Model-View-Controller или MVC, или «Модель-Представление-Контроллер» — предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента:

Модель (Model) предоставляет данные, как правило, лежащие на сервере, например, в базе. И эти данные со временем могут как-то модифицироваться. Например, на сервере хранится информация о товаре.

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

Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Чтобы было понятнее, пример. В базе данных у вас лежит товар. Его можно вывести и на страницу с карточкой товара, и на страницу списка товара и в корзине пользователя. Физически в базе это будет один и тот же товар, но отображаться он будет по-разному. За хранение данных о товаре отвечает модель. За то, как этот товар можно показать пользователю — представление, или View, их может быть несколько. Ну и есть некие операции, которые можно выполнять с товаром: положить в корзину, удалить из корзины, удалить из базы, добавить остатки на складе и так далее. За них отвечает контроллер.

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

Scrum — передовой фреймворк (платформа), созданный в 90-е специально для разработки, передачи и поддержки сложных продуктов. Сейчас используется и в других сферах. Суть: весь объем работы делится на короткие этапы в 2–4 недели (спринты), в рамках которых выполняется конкретный перечень задач из бэклога (списка всех задач, упорядоченных по приоритетности). Подробнее о Скраме мы поговорим в главе 3.

Карта компетенций — таблица со списком и уровнем необходимых навыков по каждому сотруднику. Благодаря ей можно оптимально распределять людей по командам, следить за прогрессом каждого из них и давать задачи на прокачку недостающих навыков. Подробнее о картах компетенций говорим в главе 7.11. Пример карты компетенций ищите в Приложении 1.

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

CSS-файл — каскадная таблица стилей, которая применяется для оформления веб-страниц. С помощью CSS-файла задается цвет, шрифт, положения отдельных блоков на странице.

Developer Tools — панель инструментов веб-разработчика. Обычно встроены по умолчанию в современные браузеры, чтобы можно было легко просматривать исходный код сайта.