Come work in Estonia – the most advanced digital society. Many Ukrainians already know that Estonia is affordable – become one of them and check out the jobs available!
×Закрыть

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

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

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

31 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Программист не может работать в Windows
Серьезно? Как там живется, в параллельной веленной? :)

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

В програмерских конторах доморощеные манагеры о таком и не слышали.

правильная статья

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

Разъясните, пожалуйста.

Проджект отвечает за имплементацию проекта. А продукт менеджер отвечает в первую очередь за его коммерческие показатели — revenue, ROI.

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

Наиболее близкой к Продакт Менеджеру, является роль Product Owner из Agile\Scrum, только его работа не заканчивается когда проект сдан и закончен. Одна из задач Продакт Менеджера это развитие продукта.

Для проджект менеджера это завершения проекта

Ээээ.... А если это не заказная или продуктовая ИТ-разработка? Что, если проект «никогда не завершится»?

Project manager = дословно «руководитель проекта».

Что касается разницы между продуктовым менеджером и проектным, то она незначительна как в outsource, так и в продуктовых компаниях.

Серьёзно? Как по мне — слишком смелое утверждение.

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

коменты иногда похожи на неконструктивное умничанье )

Неправильная статья.
Программистами руководит Team lead. А продуктовый менеджер может вообще не общаться с программистами. Ему нужно смотреть на программу и общаться с клиентом изучать рынок. Есть еще архитектор программы. Он должен быть один, иначе бяда. Тим лидов может быть много.

вы действительно читали? при чем тут архитекторы и тмлиды?

Ага,

архитекторы
дома проектируют.

Сколько проектов, столько и структур команд. Вовсе не обязательно программистам управляться тимлидом.

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

Программист не может работать в Windows
Особенно если он/она пишет на .NET

Какой смысл в отдельном не техническом менеджере на 7 человек? Люди и заказчик будут ему задавать технические вопросы. Написание кода как раз и поможет на них ответить. Время совместить найдется. Разве что не брать на себя технических задач, которые являются одновременно и срочными и сложными. Чтоб руководить разработкой надо отвечать за программирование или отвечать за финансовые вопросы з заказчиком и командой. От менеджера, который не отвечает ни за что, толк минимальный. Он имеет право на жизнь только в бюрократических организациях с тонной отчетов и бумажной работы.

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

// Тихо, шёпотом, чтобы топикпастер не услышал: Windows настраивается! Равно как и программы с уведомлением имеют опции отключения уведомлений (если не хотят получить негативных отзывов).

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

Программист не может работать в Windows
и первый параграф после — ну бред же.

Прикольная статья.

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

Можно. Просто разделить по времени. Например 1 час в день манагер, 8 часов кодер. Особенно если команда маленькая.

Так и делают, но значит 8 часов все остальные ждут. Продуктивность это не особенно сильно повышает.

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

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

Как раз наоборот. Правило Парето в действии: менеджер может делать как раз те самые 20%, которые дают 80% результата.

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

Залежить від того, що ви розумієте під менеджментом.

продуктовый или проектный менеджер?

Подписаться на комментарии