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

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

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

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

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

Литература

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

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

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

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

Пояснения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мао Цзэдун

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