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

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

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

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

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-проектами интересна власть, которая устанавливается внутри команды проекта и разделяет людей на тех, кто командует, и тех, кто подчиняется.

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

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