Разработчик — проектный менеджер?

Choice image via Shutterstock.

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

Как работает программист

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

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

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

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

Что происходит, если программиста отвлекают

Сначала он не реагирует, потому что мозг слишком занят и сосредоточен. Если раздражитель не исчезает, то всё, на чём сосредотачивался мозг, начинает разрушаться со стремительной скоростью — как мандала, уносимая потоком ветра. Принимая во внимание, что на раздражитель необходимо отреагировать и переключить контекст, а потом вернуться назад временная, цена громкого звонка телефона или крика «Иди кушать» из соседней комнаты составляет уже около 30 минут. Но на самом деле больше, потому что часто бывает сложно вернуться в поток при текущем количестве раздражителей (Twitter, Skype/Slack, Facebook).

Программист не может работать в Windows

Я так считаю потому, что весь софт системы настроен на привлечение внимания. Любая, самая убогая и жалкая, программа засунет себя в tray и выбросит окно бесполезного уведомления. Причем это поведение рекламируется системным софтом. Настройка окружения без раздражителей практически невозможна, в отличии от OS X (хотя и в ней в последнее время появились notifications) или Linux.

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

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

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

Как работает продуктовый менеджер

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

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

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

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

Умышленно написал «ресурсы» вместо людей, потому что важным сигналом вполне может оказаться закончившееся место для backup’а или стена ошибок, пришедшая в Sentry. Если программист ждет ответа, потому что не может продолжить работу над текущей задачей, то хорошо бы успеть ему ответить прежде чем он выйдет из состояния потока.

Заставить программиста управлять

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

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

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

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

Программист vs менеджер

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

Проверка

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

Следующий этап — дать человеку задание на 1-2 дня, пару программистов — и посмотреть, как пойдет дело.

Трудности

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

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

Конечно, серебряной пули нет, но почему бы не поделиться своим опытом? У меня получилось сочетать управление проектами и программирование, завязывая на себя некоторые интеграционные задачи. Например, поддерживать инфраструктуру развертывания проекта и тестов — не такая уж и сложная задача с точки зрения концентрации, плюс интенсивность изменяющихся требований небольшая. Обычно это экономит время для всей команды. Опять же, не страшно, если пару дней проект нельзя будет развернуть со всеми зависимостями одним `make setup`, а надо будет у кого-то спросить версию какой-то библиотеки. В конце концов, программисты и сами могут следить за тем, чтобы окружение не сломалось, а упавший Jenkins быстро пришлет репорт.

Оставаться в курсе

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

Например, можете посмотреть пример шаблона Flask проекта, который я обычно использую, — он разворачивается одним `make` и запускается командой `make run`. Когда программисту нужно что-то быстро протестировать, можно развернуть рядом окружение и запустить проект. Если же окажется, что кому-то нужен Windows, можно развернуть проект внутри Docker’а и работать с проектом в окружении, приближенном к боевому.

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

Преимущества программиста-менеджера

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

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

Особого счастья в управлении проектами нет. Это такая же работа, со своими плюсами и минусами.

Частые ошибки назначения менеджера

Собственно, вся эта статья описывает одну из самых главных ошибок — заставлять менеджера писать код. Чтобы разрушить работу программиста в течение дня, ему надо быть 5 раз по 1 минуте менеджером каждый час. Такое маленькое пересечение обязанностей уничтожает работу программиста полностью. Это приводит к стрессу и всем остальным негативным последствиям.

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

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

Есть ограничения на количество людей, с которыми одновременно может работать один человек, — это видно по динамике общения детей в школе или детском саду. Если у вас в классе было 15 мальчиков, то, скорее всего, они распадались на 2-3 группировки. Когда в класс приходит 16-й мальчик, дружная компания получается редко.

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

Надеюсь, создал некую ментальную модель этих двух ролей и ответил на какие-то вопросы окружающих.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU