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

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

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

Часть 1

Картина мира digital-проекта. Тонкости делегирования в IT

Возьмем такую задачку: довести сайт до ума.

Нет, я не пошутил с формулировкой. Таких задач — доделать за предыдущими разработчиками — на фриланс-биржах пруд пруди. И несчастные сотрудники в них периодически вляпываются. Допустим, вы — менеджер, у вас микрокоманда: дизайнер, программист, аналитик, тестировщик. С которыми вы раньше не работали. И есть еще бизнес-заказчик, нешибко разбирающийся в digital-премудростях, но уже почему-то раздраженный. Он эту карусель оплачивает, если его устроит цена и качество. Понятно, что его в первую очередь интересуют деньги и сроки. Ваши действия?

Правильно: бежать!

А что нас смущает? Запредельная степень неопределенности? Тухлая перспектива? Неуверенность в команде? Непонятки с оплатой? Неадекватный заказчик? Поехали, потом заведешься? Гарантированный геморрой при негарантированном результате?

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

1.1. Картина мира digital-проекта

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

Заказчик. Бывают два типа заказчиков. Внутренний, когда разработка идет in-house. И внешний, когда проект разрабатывается на заказ.

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

У заказчика определяющая роль. Он формирует концепцию проекта, приоритеты, финансирует весь карнавал. От него зависит все: что бы вы как менеджер ни делали, всегда остается шанс упереться в стенку на той стороне. Именно заказчик определяет степень успешности проекта. Подробнее о работе с заказчиком поговорим в главе 9.

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

Различают два ключевых формата работы. Time & Material — оплачивается время, затраченное командой, в таком случае задачи можно менять как угодно. И Fixed Price — цена и задачи оговариваются на берегу. У обоих вариантов есть как плюсы, так и минусы. Time & Material переносит риски на заказчика, но работу можно организовать быстрее и гибче. Fixed Price — заставляет разработчика зашивать риски и подстраховку в смету, лишает гибкости и снижает скорость выпуска функций из-за процедуры согласования бюджета, но яснее воспринимается клиентом. Существуют также гибридные модели.

Условия заказчика регламентируются тремя способами:

Требования. Постановки задач, технические задания (ТЗ), тикеты^[1], рисунки на салфетках, бэклоги… Управление требованиями, выявление, уточнение, актуализация, расстановка приоритетов занимают массу времени. Рассмотрим подробно работу с требованиями и способы приоритизации в главе 4.

Юридические документы. Иными словами, бюрократия, более актуальная для заказной разработки. NDA, договоры, приложения, акты и т. д.

Тикет-система. Хранит задачи для команды и статусы по ним. Может быть частью системы управления требованиями или существовать отдельно. Может быть только для внутренних нужд команды, а может пускать заказчика внутрь.

Команда проекта. В digital команда может сжиматься до одного человека, а-ля веб-мастера, и включать в себя заказчика. Либо наоборот: разрастаться, выделяя отдельные функции в роли. Как строить и выращивать команды, мы разберем в главе 7. Командная работа подразумевает делегирование. Например, менеджер справится с задачами аналитика и тестировщика, но с ростом проекта целесообразно выделить это в отдельные роли. Или программист может администрировать серверы, если квалификация соответствует. Но как только серверного хозяйства становится много — приходится выносить это в отдельную роль — администратора. Для примера будет такая команда:

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

Разработчик (программист). Бородатый чувак, который пилит код. Пока без дебрей на чем, бэкенд-фронтенд. Универсальный боец.

Дизайнер. Отвечает за весь визуал и интерфейсы. Хотя пошла мода на специализации UI/UX-дизайнеров и т. д. Подробнее об организации дизайна поговорим в главе 6.

Аналитик. Конкретизирует требования. Подробнее об этом поговорим в главе 4, посвященной аналитике.

QA (quality assurance, тестировщик). Тестирует продукт.

Поле власти. Что-то типа электрического поля, к которому подключаются менеджерские инструменты типа «делегирования». Подробнее про власть разберем в главе 2.

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

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

Еще несколько компонентов digital команды:

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

Регламенты, правила, обычаи, стандарты отрасли. Документы или принципы, по которым организован рабочий процесс в команде. Формализуют знания и опыт команды. Такие регламенты собираются в корпоративные базы знаний и доступны всем участникам, но это не гарантирует 100 % осведомленность или применяемость.

Инструменты и технологии. Компьютеры и программное обеспечение, необходимые для разработки нового софта. Навыки владения такими инструментами принято называть Hard Skills.

График загрузки команды. Чтобы спрогнозировать сроки готовности каждой функции, приходится планировать календарную загрузку каждого члена команды и учитывать зависимости задач. Если же вы работаете в мультипроектной среде — приходится учитывать загрузку команды на других проектах. Тут помогут сетевые графики, теория ограничений и метод освоенного объема из главы 5.

Проект. Это набор артефактов, в основном — файлов:

▶ Код, как правило, в репозитории.

▶ Визуал — макетов, прототипов, гайдлайна и т. д.

▶ Серверная инфраструктура, на которой ведется разработка, тестируется или работает сам проект.

▶ Разноуровневый Доступ и хранение паролей.

▶ Кроме кода и визуала в проекте обязательно есть Данные. Это либо база, либо контент, ради обработки которых проект и затевался.

▶ В развитых проектах код покрывают Тестами и пишут формальные Тест-планы выпуска продукта.

▶ Большинство проектов взаимодействуют с Внешними сервисами. Например, авторизуют пользователей через социальные сети или рассчитывают стоимость доставки товара. Для этого разработчики выполняют интеграцию через API. Подробности в главе 10.

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

1.1.1. Прогулка по картине мира

Итак, мы героически вляпались в задачу «довести сайт до ума». Как бы я действовал (кое-где — чужими руками)?

Жуть, этот план даже читать больно! А ведь вам завтра крутить окровавленную и облитую слезами ручку digital-разработки:)

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

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

▶ Грубо оценил стоимость проекта (вилочно, от-до), получил подтверждение бюджета у клиента.

▶ Согласовал работу по Time & Material. Работать с чужим проектом по Fixed Price — самоубийство. Выяснил, сколько примерно часов готов выкупать клиент в будущем и какие дальнейшие планы на сотрудничество. Разовый, короткий контракт, отношения на одну ночь меня бы не заинтересовали — в этом случае посоветовал бы закончить проект с предыдущей командой.

▶ Запросил доступы к коду.

▶ Провел код-ревью — процедуру анализа и оценки качества кода.

▶ Изучил текущую документацию. Если документации нет — это тоже показатель.

▶ Принял решение, можно ли работать с текущим кодом или нужно выбросить и все делать с нуля.

▶ Подписал контракт.

▶ Получил предоплату.

▶ Еще раз уточнил требования. Собрал их в бэклог. Отсортировал по приоритетам. Организовал работу спринтами.

☐ Нарисовал прототипы. Сдал клиенту.

☐ Нарисовал дизайн, если задача это предполагает. Также сдал клиенту.

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

☐ Доформировал требования на уровне задач в тикет-системе с учетом изменений, которые появились в дизайне и прототипе. Обычно это мелочи, но иногда все разворачивается на 180°.

☐ Дал вычитать требования разработчикам.

☐ Проговорил задачи голосом с командой, ответил на вопросы. Получил оценки от команды, например, методом Planning Poker (подробнее в главе 3).

☐ При необходимости провел рисерч. Это нужно для задач, с которыми команда никогда не сталкивалась.

☐ Запланировал разработку в календарном плане.

☐ Написал тест-кейсы или критерии приемки по каждой из задач.

☐ Запрограммировал. Следил за ходом работ, решал «затыки».

☐ По итогам разработки провел код-ревью нового кода.

☐ Протестировал, исправил баги.

☐ Проверил производительность.

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

☐ Провел ретроспективу с командой, посмотрел, что можно улучшить в проекте и процессах работы.

☐ Актуализировал документацию.

☐ Провел деплой (выкладку на боевые сервера).

☐ Обновил контент.

☐ Проверил работу на боевом сервере.

☐ Подписал акты, получил постоплату.

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

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

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

Час нормального проджекта должен стоить не менее часа нормального психолога.

1.1.2. Кривая роста мастерства

Как выглядит кривая роста компетенций и профессионализма руководителя? А это действительно кривая.

Кривая роста мастерства

1. Бурный рост

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

Хотя уже и на этом этапе часть людей отвалится, потому что поймут — это не для них. Такой начальный профессиональный сплит-тест — «да-нет».

2. Страшно и ни черта не понятно

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

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

В психологии известен эффект Даннинга-Крюгера. Смысл его в том, что дилетант ведет себя, как правило, очень самоуверенно. Он чего-то нахватался, каких-то догм, и свою уверенность строит на этих догмах.

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

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

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

3. Ясность мысли

Итак, после того, как с «детскими болезнями» разобрались, менеджер постепенно начинает набирать авторитет, опыт, компетенции. Вырабатывает, что называется, стиль.

Он хорошо знает правила компании, методологии, и мало-помалу начинает успешно вести проекты.

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

4. Яма

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

Стратегия полу-управленца

Менеджер почувствовал силу и начинает экспериментировать с правилами и подходами. И в какой-то момент у него начинают «сыпаться» проекты.

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

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

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

Яма неизбежна. Лучше всего, если в этот момент рядом будет опытный наставник, который вовремя протянет руку и из этой ямы вытащит.

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

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

К счастью, большая часть людей яму преодолевает.

5. Мастерство

После кризиса уровень менеджера радикально меняется. У него появляется внутренняя уверенность. Он находит решения даже в сложных ситуациях. Такие менеджеры могут не только делать проекты, но и научить других. Это — опора компании. Факапы на этом уровне, безусловно, останутся, но справляться с ними будет уже легче.

На этом этапе руководитель проектов ищет задачи сложнее, интереснее. Он выступает на конференциях и тестирует новые технологии. Дорога в мир настоящих, жирных факапов!

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

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

Самое интересное, что на этом развитие не заканчивается. Управленческое мастерство ничем не ограничено, нет предела совершенству, но к нему нужно стремиться.

1.2. Делегирование

Делегирование — это передача части полномочий или ответственности другим людям. Как правило — своим подчиненным.

Делегирование невозможно без грамотного планирования. Банально, у вас не останется времени ни на постановку задач в нужной форме, ни на контроль. О планировании времени мы поговорим в главе 8.

Делегирование — ахиллесова пята российского менеджмента. Руководители делегируют плохо, боятся или ленятся это делать. Многие просто не умеют, поскольку делегированию, как и вождению автомобиля, нужно учиться. Менеджер, который не умеет делегировать, — бутылочное горлышко организации: он набирает на себя слишком много задач и стремится самостоятельно сделать их большую часть. Грамотное делегирование — это точка роста организации.

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

1.2.1. Что делегировать. Делегирующая сила

Я завел себе регулярную привычку — раз в полгода просматриваю список дел, которыми занимаюсь. Смотрю, сколько времени они у меня отнимают. Оцениваю, насколько они мне нравятся и насколько они стали рутинными. Смотрю, должен ли я их делать сам. Можно ли делегировать что-то из рутины, неприятных мне дел или тех задач, где лучше справится специалист. Планирую: когда, кому и что я могу делегировать и в каком виде.

Помогает табличка — что можно, а что нельзя делегировать:

Советую завести себе подобный ритуал или регулярную задачу в вашем таск-трекере (планировщике). И постепенно увеличивать вашу делегирующую силу.

1.2.2. Устно или письменно

И тот, и другой вариант уместен, но у обоих есть ограничения.

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

▶ Сложно учесть все детали при постановке. Кто мало думал, тот много плакал.

▶ Подчиненному сложно запомнить множество деталей.

▶ Может аукнуться временем на переделку и повторным делегированием.

▶ Не оставляет артефактов. Появляется искушение при разборе полетов переиграть постановку («а я тебе сказал так-то», «а я тебе этого не говорил…»). Очень плохая практика, которая разлагает рабочую атмосферу. Да и в эту игру могут играть оба.

Письменное делегирование дает время обдумать детали. В итоге получается точнее. А размышления о предстоящих деталях минимизируют количество ошибок. Минусы:

▶ Требует времени на написание ТЗ.

▶ У подчиненного нет возможности уточнить задание в момент его получения.

▶ У вас нет возможности предварительно убедиться, что вас поняли правильно. Пропущен предварительный контроль.

Лучше работают гибридные варианты.

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

Если деталей в задаче слишком много, лучше разбить такие задания на несколько. Проще пропустить один пункт из 30, чем один пункт из пяти.

https://glvrd.ru/

Сервис «Главред»

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

Устно + проверка фиксации. Дать устное распоряжение или даже провести брейншторм, обсудить вопросы, спросить план действий и проверить, как задание было зафиксировано. Тут работает «эффект генерации» — мы лучше запоминаем то, что изложили сами. Можно зафиксировать итоги и ключевые точки самому, но это не так эффективно. Большинству клиентов удобно давать постановки в таком виде. Хорошо работает с дизайнерами, да и в принципе удобный способ.

1.2.3. Список «поручил-контролирую» и сроки о сроках

При устном делегировании вам нужно будет каким-то образом вспомнить о своем задании и своевременно его проверить. Я держу в личном таск-трекере список «поручил-контролирую», где кратко, пофамильно записано: кто что обещал и когда (или когда будет контрольная точка).

Список «поручил-контролирую» удобно вести в любом тудушнике или блокноте.

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

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

Кроме того, мне нужно время на проверку задания. Поэтому, если договорились сделать задачу «сегодня», то по умолчанию я ожидаю ее до 17:00 (а не в 23:59).

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

1.2.4. Где делегировать, а где — нет. Туалетное делегирование

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

Таким образом, у туалетного делегирования три признака:

1. Неформально. Задача выдается в неформальной обстановке. Курилка. Кухня. Коридор. Любое нерабочее пространство.

2. Корректно. Задача выдается по адресу и корректно. Если не исполнили — понятно, кто не исполнил. И понятно, что именно.

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

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

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

Туалетное делегирование — очень тонкая вещь. Подчиненный может подойти с ВОПРОСОМ (дескать, как мне быть с компанией А) — руководитель отмахнется фразой «надо подумать». И тут подчиненный получит моральное право считать, что ситуацию с компанией А теперь разруливает его руководитель. Итог: через пару дней подчиненный с чистой совестью подойдет и спросит: «Глебываныч, как там с моим ВОПРОСОМ дела?» Спасибо, что не: «Как там с моим ПОРУЧЕНИЕМ дела». Это самозахват полномочий. За такое надо бить, и бить жестко!

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

Решение

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

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

Есть, говорят, такая секта — «Хранители Космоса». Предсказав однажды конец света, они побросали семьи, квартиры, работы и что там у них еще было. И стали ждать часа X, неистово молясь.

Настал час Х. Земля не взорвалась. Пришельцы никого не забрали. Небеса не разверзлись.

Вы думаете, они сильно расстроились и разошлись по домам? Хренушки! Хранители космоса объявили, что ТОЛЬКО БЛАГОДАРЯ ИХ МОЛИТВАМ мир получил отсрочку! Хитро, не поспоришь.

Алгоритм такой:

1. Начиная новое дело, объявить о возможных негативных последствиях. Что уже само по себе КАК БЫ дает право не верить в результат и действовать деструктивно.

2. Вяленько что-то делать. Право действовать «вяленько», не напрягаясь, человек как бы отвоевал себе своим скепсисом и неверием в результат.

3. В случае наступления негативных последствий — высунуться и сказать: «А Я ЖЕ ГОВОРИЛ!!!» (Если, конечно, будет кому «а-я-же-говорить»: в случае с Хранителями Космоса и спрашивать, и отвечать было бы некому.)

4. В случае, если негативных последствий не наступило, говорить, что это ТОЛЬКО БЛАГОДАРЯ МОЕЙ САМООТВЕРЖЕННОЙ РАБОТЕ.

Алгоритм часто применяют неосознанно. Он вшит где-то на уровне BIOS-а в мозгу (см. А. Курпатов, «Красная Таблетка»). В digital этим особенно грешат программисты. Иногда пропуская 4-й пункт, ибо он как бы подразумевается.

Противоядие:

1. Знать, что Хранители Космоса не угомонились, и что их алгоритм, зараза, действует.

2. Поймать человека на применении этого алгоритма. И рассказать, что именно он делает. При необходимости — повторить. При острой необходимости и частых «А-Я-ЖЕ-ГОВОРИЛ!» поинтересоваться, не сектант ли он.

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

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

1.3. Уровни делегирования

1.3.1. Делегирование на уровне идеи

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

Руководитель: Давай организуем семинар для клиентов?

Сотрудник: Давай, а на какую тему?

Р: Не знаю, что-нибудь про интернет-магазины.

С: Ок, в июне есть время. Давай я придумаю тему, составлю план подготовки, можем обсудить.

Р: Да сам как-нибудь самоорганизуйся:)

С: Ок.

1.3.2. Делегирование на уровне тезисов

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

Р: Я хочу провести семинар, как в прошлом году, на 300–400 человек. Придумай тему, напиши план подготовки и какие ресурсы тебе понадобятся для этого.

С: Ок.

1.3.3. Делегирование на уровне задач

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

Р: Нужно организовать семинар, как в прошлом году, на 300–400 человек. Тема — интернет-магазины.

С: Что требуется от меня?

Р: Подбери зал на 300 человек в пределах 1-го кольца и не дороже 100 000 рублей.

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

1.3.4. Делегирование на уровне инструкций

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

Совет

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

Р: Мы организовываем семинар. Вот список клиентов, вот скрипт. Тебе нужно будет обзвонить клиентов по списку, используя этот скрипт. Сейчас ты заучиваешь его, подходишь через 15 минут ко мне и воспроизводишь его слово в слово. Если все ок — начинаешь обзвон, вот телефон. Тех, до кого удалось дозвониться, помечаешь зеленым. Как понял?

С: Взять скрипт, взять список, скрипт выучить, подойти и через 15 минут сдать его тебе, обзвонить. Потом пометить тех, кому удалось дозвониться, зеленым.

Р: Тебе всего хватает для этого?

С: Да, все есть.

Р: А зеленый маркер?:)

Со стороны может показаться, что делегирование на таком уровне — это маразм. Дается много вводных, которые сложно запомнить и удержать в голове, поэтому тикет-системы и письменные постановки здесь спасают.

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

1.4. Smart-делегирование

Популярный фреймворк постановки задач. SMART — аббревиатура, где каждая буква обозначает:

▶ Specific — конкретный;

▶ Measurable — измеримый;

▶ Achievable — достижимый;

▶ Relevant — значимый;

▶ Time-bound — ограниченный во времени.

Конкретность — хотим, чтобы сотрудник выкопал яму. Измеримость — яма должна быть метр на метр, в сквере. Достижимость — за счет каких ресурсов можно достичь результата: лопата лежит в сарае, для копания можно привлечь разнорабочих, бюджет 2000 рублей. Значимость — подчиненным важно объяснить, зачем мы достигаем этого результата, и как этот результат связан с целями компании: яма нужна, чтобы посадить дерево, это нужно для поддержания имиджа экологичной компании. Ограниченность во времени — указать конкретные сроки: через 3 дня, потому что идет сезон посадки деревьев.

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

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

Планирование

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

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

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

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

Контроль

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

Санкционирование

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

1.5. Постановка задач на рисерч

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

Исследование требует ресурсов, иногда — серьезных, и если задача новая и неизвестная, то процесс оценки стоит разбить на стадии:

1) Постановка задачи, анализ и предварительная оценка

Например, задача — анимированная 3D-модель, а вы такого раньше не делали. Предварительно вы закладываете 8–16 часов на всю эту задачу.

2) Фаза рисерча

Мы берем себе час-два на «поиграться» с какой-то технологией или новым стэком, провести нужные эксперименты. В примере про 3D-модель нам нужно будет посмотреть, как «запекаются» текстуры, посмотреть фреймворки для 3D-анимации, изучить софт, посмотреть примеры. В итоге оценка может увеличиться в 4 раза, или вы поймете, что только на стадию рисерча вам нужны исходные 8–16 часов. Бывает. Возможно, в этот момент вы упростите задачу, обойдетесь без анимации. Или поменяете исполнителя, найдете опытного. Или добавите ресурсов. Я называю это «контролируемый факап». Провал возможен, но глубина провала известна заранее.

3) Уточненная оценка, начало работы, фиксация оценки

Когда вы поняли, с чем имеете дело, оценки фиксируются железобетонно.

4) Выполнение задания. Согласованные контрольные точки

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

На первом и втором этапе оценки и прочие параметры можно менять. Начиная с третьего — уже нет.

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

1.6. Фальшивые автобусные остановки. Тонкое искусство контрольных точек

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

Это яркий пример, как стереотипы и привычки можно применять для управления и выстраивания контрольных точек. Старческое слабоумие — момент далеко не ключевой.

Пример из практики: один мой знакомый очень любит внедрять KPI. Из пяти метрик одну делает фальшивой. В реальной работе получить ее нельзя. Хитрецы же могут накрутить любую херабору.

Другой пример: как-то я подготовил чек-лист, первым пунктом которого было: «Внимательно прочитать документ до конца». Дальше было примерно 30 пунктов. Последним был «Выполнить пункты 1 и с 5 по 12, остальные проигнорировать». Жестко, да?

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

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

Используйте предсказывающие контрольные точки. Оговорите их заранее.

1.6.1. Контрольные точки методом поводка

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

Вот так и с контрольными точками. Справился ваш подопечный — молодец! Даем больше свободы. Большие сложные задачи, меньше контроля. Не справился — значит, пока рановато такие задачи решать. Уменьшаем поводок. Задачи мельче и проще, больше контрольных точек.

1.7. Ошибки делегирования

Но если все ясно, то почему руководители не делегируют или делегируют через ж… плохо?

1.7.1. Неумение делегировать

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

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

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

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

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

1.7.2. Боязнь идти на конфликт

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

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

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

1.7.3. Неуверенность в своих подчиненных

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

Также вы можете быть не уверены в квалификации подчиненных. Но по-хорошему грамотный руководитель должен заниматься постоянным мониторингом квалификации сотрудников и наращивать ее до необходимого уровня. Другая крайность — неуверенность в мотивации подчиненных: а хватит ли им мотивации выполнить поставленную задачу?

Еще один вариант — сомнения, что сотрудники верно понимают поставленную задачу и сделают ее именно так, как вы того хотите. Бывает, что вы даете распоряжение в общих словах. Например, «поедь к Иван Иванычу, возьми такой-то документ и привези его мне». И вот, приходит подчиненный и говорит: «Не получилось». Он не съездил, а позвонил. Иван Иваныч был на совещании и не перезвонил. А вы-то знаете, что Иван Иванычу звонить бесполезно — он такой человек, к которому нужно именно приехать. И здесь не остается никаких рычагов, кроме режима бармалея: «Делай так, а то уволю!» Просто потому что на рассказ о всех тонкостях взаимоотношений с Иван Иванычем у вас уйдет полдня.

1.7.4. Нет достаточных управленческих качеств

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

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

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

Сама процедура делегирования зависит не только от того, как поставлена задача, но и от уровня подчиненного. Отправляя человека по пути, думай, кто по этому пути пойдет.

1.8. Правила письменной контрацепции. Как ставить задачи, не убив друг друга

Программисты — как джинны. Осторожнее в своих желаниях, они могут исполниться.

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

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

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

Мы интуитивно чувствуем, что на решение мелкой проблемы придется затратить довольно много энергии. На мелкие огрехи часто проще махнуть рукой, чем доделывать те последние 10 % работы, которые занимают оставшиеся 50 % времени. Возможность быстро поставить задачу, прилагая минимум усилий мозга и телодвижений, напрямую влияет на качество проекта и добрые отношения внутри рабочей группы. Хотя и двояким образом.

Минимум транзакционных издержек — это когда программист сидит рядом, под боком, и вы силой голоса призываете его, тычете пальцем в монитор и говорите: «Опять ничерта не работает, пойди разберись!» Нормально ли это? Отчасти.

Совет

Большая часть крупных релизов перед дедлайном и перед выпуском проходят через фазу стресса. И здесь возможно все — вплоть до трехэтажных матов и жестких конфликтов. В целом, это даже полезно. Главное, чтобы такое не вошло в традицию. День-два в таком ритме можно пережить, дальше — нет. Все должно войти в русло, задачи должны поступать из одного источника, а не сыпаться на бедного-несчастного разработчика с пометкой «СРОЧНО», «КОГДА УЖЕ БУДЕТ» и «НЕМЕДЛЕННО».

Рекомендую посмотреть старое интервью со Стивом Джобсом про драки внутри команды и как они влияют на качество продукта — я его периодически показываю своим ребятам, когда начинаются конфликты.

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

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

Когда атмосфера накаляется, диалог может складываться как-то так:

— У вас баг на проекте!

— А где именно?!

— ВОТ ТУТ, ЕПТ!!!

Плюс скриншот.

Когда пишешь разработчику матом, либо просто «баг» или даже «косяк» — это воспринимается как личное оскорбление (чуть позже мы посмотрим на когнитивные искажения). Это серьезный плевок в душу разработчика. Пишите простыми, понятными формулировками. Не машите кулаками там, где не должно быть драки. А с надписями КАПСОМ будьте совсем осторожны — это воспринимается так, будто вы на человека ОРЕТЕ. Конечно, только если это не ваш управленческий ход, чтобы загнать кого-то под тумбочку. Только ведь он потом оттуда вылезет! В общем, давайте не капсить. В мире и так слишком много этого дерьмеца.

1.8.1. Меньше насилия, детка!

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

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

Молодец…

Молодец.

Молодец!!!

Молодец:(

Молодец:)

ХОРОШ!

Оформляя баг-листы или письма, всегда задумывайтесь хоть на полсекунды, как это прочитают и с какой интонацией. У нас в студии терпимо относятся, если разработчик использует ненормативную лексику в баг-листах и в комментариях. Для менеджеров и тестировщиков это — табу, для разработчика — иногда можно, если он этим не злоупотребляет, и если эти комментарии не увидят клиенты. А вот за неуважительные высказывания, устные или письменные, по отношению к клиенту уже надо наказывать или, как минимум, — разбираться, разговаривать про добро и зло. Для меня это индикатор «все ли нормально на проекте?!». Потому что, если появляется ругань в сторону клиента или проекта, дальше по инерции ситуация становится все менее и менее управляемой.

Совет

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

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

Я не преувеличиваю ни на грамм. Ставится задача с формулировкой «Косяк на сайте». КАПСОМ. Ставится ссылка на скриншот, где тоже что-то невменяемо написано капсом. Не удивляйтесь, если в комментариях к такой задаче вам также начнут отвечать капсом, нервно и грубо. Тикет-система тут будет не виновата — так накуролесить можно и в Jira, и в Trello, и в чем угодно еще.

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

1.8.2. Найди меня потом, попробуй!

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

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

Если в таком виде с вами работает ваш клиент, и у вас не получается договориться о нормальных формулировках (ему тоже не до формулирования и четкости и проще вам заплатить побольше денег, чтобы вы сами все фиксировали с его слов), тогда проблем нет. Фиксируйте все сами, сами переводите с клиентского на программистский. Берите за это деньги. Это воспринимается абсолютно нормально в 80 % случаев и ценится (если вы не сильно косячите). Вы экономите клиенту время — и это тоже часть менеджерской работы. К исполнителям формулировки должны попадать такие, чтобы задачу можно было найти поиском. Очевидная вещь, но приходится и про такое рассказывать.

Формулировки стоит писать так, чтобы по ним было легко найти, где случился и как проявился баг. Подробно описывайте, что заставило баг вылезти. И поменьше оценочных формулировок: что это за «абракадабра в тексте ссылки»? В том же Битриксе, например, по умолчанию не генерируются ссылки с человеко-понятными названиями, любой программист вам скажет про это. И даже не попытается понять вашу проблему. Мол, в коробочной версии это работает именно так, чего вы от меня хотите?! Это нормальное поведение программистов — и нельзя их за него осуждать.

1.8.3. Проблема или требование?

Бывают формулировки, из которых непонятно: это проблема или требование? Пример — «ссылка фиолетовая». И что? Она должна такой быть или ошибка в том, что она фиолетовая, а должна быть серой? Дело в том, что непонятно, что именно вы хотите, чтобы с этим фактом сделали и как именно его поправили.

1.8.4. Мне кажется…

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

1.8.5. Поплачь о нем… В другом месте!

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

Представьте, что программист переживает расставание с подружкой, пришел с плохим настроением. Открывает текстовый редактор. Создает файл VsePloho.php. В нем — класс PolniyPipec. А в нем метод KakViVseDostali (vi, vse). На другой день настроение наладилось, помирились, новый файл уже SuperPuperMegaKorzina.php и все в таком роде. И это все идет на ревью службе безопасности. Думаю, там разговор будет короткий.

1.8.6. Принцип пирамиды

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

1.8.7. Приоритеты

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

▶ 0 — критические баги (падает сервер или не работает оплата), нулевой приоритет ставим в случае, если тестировщик из-за этого бага не может дальше продолжать проверку проекта.

▶ 1 — либо что-то забыли реализовать, либо что-то критичное по юзабилити.

▶ 2, 3 — менее критичные вещи.

▶ 4 — ошибки в текстах или текстовые правки.

▶ 8 — это «хотелки», некритичные баги.

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

Мы намеренно пропускаем 5, 6, 7 — если такие приоритеты понадобятся на конкретном проекте, мы их просто придумаем, не ломая основную систему.

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

1.8.8. Перфекционисты должны гореть в аду. Но это не точно

Есть клиенты-перфекционисты, которые считают, что нельзя выпускать проект с незакрытыми багами. Увы, в наше время это утопия. Любой софт выпускается с какой-то долей некритичных ошибок. С какой именно — это вопрос дискуссионный. Бывает, что пользователи используются как бета-тестеры. Скорость на запуске (или Time To Market, TTM — время от начала разработки идеи до ее конечной реализации) важнее. Понять это можно, посмотрев на обновления приложений, которые прилетают к вам в телефон. Большая часть обновлений в описании содержит две строчки: «Увеличена стабильность, улучшена производительность». На русский язык переводится как: «Мы поправили пару багов». Даже у Apple ошибки, которые известны годами, — это норма.

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

1.8.9. Горшочек, не вари

Было ли у вас такое, что вы моете посуду, а вам все время подкидывают новую? Опа, а тут еще и сковородка! Это откровенно бесит. Я считаю, что программисты должны видеть конечный набор багов и задач. Поэтому, если тикетов много, стоит организовать работу мелкими итерациями (спринтами). И даже если параллельно с исправлением багов идет процесс тестирования, то новая пачка багов должна попасть к программистам, только когда они отработают и закроют уже выданный им объем. Это не всегда возможно и не везде применимо, но стоит к этому стремиться, потому что так в итоге спокойнее.

1.8.10. Подведем итоги. Правила грамотной постановки задач разработчикам

1. Маты и КАПС. Вам — нельзя. Разработчикам — иногда можно.

2. Место. Указывайте конкретное место, где возникла ошибка.

3. Поископригодность. Пишите так, чтобы запись легко искалась по ключевых словам.

4. Пирамида. Используйте принцип пирамиды. Важное — в начало. Детали — в кончало.

5. Скриншоты — важное дополнение. Подкрепите текстовое описание скриншотом.

6. Решение, а не мнение. Формулируйте не только проблему, но и ожидаемое решение — четко и однозначно, а не в виде абстрактных пожеланий и мнений.

7. Не впадайте в истерику. Пишите по делу, без эмоций.

8. Приоритизируйте. Расставляйте приоритеты и организуйте по большим баг-листам работу микро-спринтами.

9. Закончите уже! Не подкидывайте посуду!

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

1.9. Семь простых истин из авиации о делегировании и контроле

В авиацию я попал не через авиацию, а почти случайно. Просто повезло столкнуться с правильными людьми. С тех пор прошло несколько лет. Кроме самолета освоил вертолет, посчастливилось полетать по Алтаю, освоить строгий спортивный самолет Су-29, 3-ю лигу по пилотажу, поучаствовать в паре авиашоу. Летаю меньше, чем хотелось бы, и до сих пор чувствую себя дилетантом. Постоянно узнаю новое. Этот опыт меняет картину мира в управленческой работе над digital-проектами.

1. Все, что можно — проверяй сам

Как правило, самолеты должны обслуживать специально обученные техники. Их у нас мало.

Да, есть специальные чек-листы проверки самолета перед вылетом. Обойди самолет, все проверь, все пошатай, бла-бла-бла… Но есть и фактор разгильдяйства. Ребята рассказывали про забытые техником в самолете пассатижи. Рули переклинило. В тот раз обошлось, летчик чудом посадил машину. В авиации, если ты хочешь жить и летать долго — ты просто обязан проверять все сам.

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

2. Зрелищно — не всегда круто

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

Я видел в проектах, когда море сил тратится на иллюстрации (в том числе — 3D), а по итогу — ну да, картинка и картинка. И наоборот, когда стоковое видео или фото в банальном слайдере вызывает реакцию: «Вау! Какой дизайн!»

3. Мелочь ничего не прощает большому

В авиации мелочей не бывает. Никаких. Нигде. Любая мелочь может тебя угробить.

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

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

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

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

4. Тщательно выбирай, кого брать на борт

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

Был случай, когда на взлете испугавшийся (или от эйфории) пассажир попытался перехватить у меня управление. Благо в RV-7 он сидел рядом, и можно было успокоить пассажира. В самолетах типа Extra, Як-52 или Су-29, где кабины разделены и посадка друг-за-другом — такой возможности нет.

Ребята рассказывали про ситуации, когда испуганная девушка-пассажир крепко зажимала сильными ногами ручку управления самолетом и на призывы: «Расслабься. Расслабь ноги. Ноги расслабь! РАЗДВИНЬ НОГИ $%^^…!!!» — реагировала слабо.

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

5. Вся ответственность, один черт, на тебе

Да, есть куча всяких контролирующих органов, транспортной прокуратуры, проверок, центров сертификации, подач планов, диспетчеров, техников, метеорологов, и всякого такого. Но как только ты — КВС (командир воздушного судна) и принимаешь решение о взлете — ВСЯ (ВСЯ!) ответственность на тебе. Отмазки не канают. Никакие.

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

Брать на себя всю ответственность — это, кстати, прикольное чувство, попробуй.

6. Летать больше — безопаснее, чем летать мало

Чем больше ты летаешь — тем больше будет разных ситуаций.

Вот недавно знакомые летчики в районе Телецкого озера попали в облако саранчи. Одно зеленое насекомое попало в ПВД — приемник воздушного давления, который обеспечивает определение скорости относительно воздуха. Итог — отказал указатель скорости.

Скорость — наша жизнь. В горах — особенно интересно. Но ничего, сориентировались. Дошли до ближайшего аэродрома, выдерживая скорость по GPS, а изменение маршрута объяснили «санитарной необходимостью» (хорошая формулировка, емкая!).

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

То же и про управление. Занимаясь чем-то профессионально — нельзя делать это время от времени.

7. Ищи наставников и оставляй следы

Так уж получилось, что Су-29, который пригнали из-за границы, два года пылился в ангаре. Самолет сложный, суровый. Летать на нем стало некому, однако с учителями везло. Познакомился с Михаилом Переверзевым, мастером спорта России международного класса, многократным призером чемпионатов России, Европы и мира… Короче, крутым парнем.

Сколько было скепсиса у него в глазах, когда я обратился к нему с просьбой о тренировках: «На таких самолетах только мастера спорта раньше летать могли, и то не все… Это не учебная машина. Эх, времена!» Тем не менее, желание вновь полетать на пилотажнике пересилило, и Михаил согласился. Каково же было наше с ним удивление, когда на третьем часу тренировок мы поняли, что я готов к самостоятельному вылету. На четвертом часу полетел сам, в сложных метеоусловиях. Самолет очень живой, и я даже на 10 % не освоил его потенциал.

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

Учить и тренировать вас никому неинтересно. И уж точно — никто не обязан вами заниматься. Это время, нервы, и в конце концов — риск. Если вдруг вас учат чему-то на работе и в рабочее время (управлению проектами, дизайну, программированию, soft skills), и вам это идет на пользу — относитесь к этому с благодарностью. А не как к само собой разумеющейся херне. В жизни очень сложно найти хороших учителей и уж тем более заинтересовать/убедить их заниматься вами. Большая удача.

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

Итак, мы посмотрели картину мира digital-проекта, убедились, что для нас там полно работы и посмотрели, как эту работу делегировать (не поубивав друг друга и с возрастающими шансами на успех).

1. Какие еще объекты вы бы добавили в картину мира digital-проекта? Что вы с ними делаете? Как они связаны друг с другом?

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

3. В течение недели попробуйте делать постановки четко по SMART, а письменные постановки с использованием принципа «пирамиды». Проверяйте их через сервис glvrd.ru.

Литература

https://www.youtube.com/watch?v=bo4i525EszY

Андрей Курпатов, «Красная Таблетка».

Максим Ильяхов, «Пиши, сокращай».

Максим Ильяхов, «Новые правила деловой переписки».

Старое интервью Стива Джобса о командной работе (ссылка спрятана в QR-коде слева).

Пояснения

Тикет-система — система онлайн-постановки и контроля задач.

Тикеты — собственно, задачи.

Бэклог — инструмент Скрама, по-простому — это список всех хотелок проекта, отсортированный в порядке приоритетов.

NDA — Non-disclosure agreement, соглашение о неразглашении: юридический договор, между сторонами с ограничением доступа третьим лицам к каким-либо данным и/или результату работ.

Софт — программное обеспечение, или ПО.

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

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

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

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

Спринт — временной интервал, обычно в 2–4 недели, в течение которого scrum-команда выполняет заданный объем работы.

Рисерч — (en: research) исследование: поиск и сбор необходимой для выполнения задачи информации, проба новой технологии и так далее.

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

Деплой — развертывание кода сайта на сервере.

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

Артефакт — результат какого-то процесса: в разработке — файлы исходного кода или файлы данных, в управлении — поставленные в тикет-системе задачи.

Пересаживание обезьян — когда подчиненные свешивают своих обезьян, свои проблемы на своего босса, а тот покорно их принимает, потому что «без вас никак не разобраться» или «вам нужно подписать», или «давайте подумаем, что можно сделать» (см. «Одноминутный менеджер и обезьяны», Бланшар К., Онкен-мл. У., Берроуз Х.).

Стендап — короткая планерка менеджера с командой проекта на 10–15 минут, где обсуждаются три главных вопроса: что было сделано вчера, что будет делаться сегодня и какие есть проблемы.

Декомпозиция — разбивка большого и неповоротливого проекта по аккуратным и понятным блокам. Об этом подробнее поговорим в главе 5, посвященной декомпозированию.

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

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

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

Бета-тестер — почти настоящий пользователь, который интенсивно использует почти готовую версию продукта/сайта/приложения, чтобы выявить максимальное число ошибок для их последующего устранения перед окончательным выходом (релизом).

Баг — ошибка на сайте, в сервисе или в приложении.

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

Класс — шаблон кода, по которому создается какой-то объект.

Код-ревью — процесс ревизии кода одного программиста — другим, более опытным. Цель: улучшить качество кода и обеспечить соблюдение принятых в команде стандартов.

Примечания

1

Расшифровку терминов, выделенных полужирным курсивом, можно найти в «пояснениях» (конец каждой главы).