Проджект-менеджер: зачем платить тому, кто не пишет код

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

Дальше идёт неделя переделки, которую оплачивает либо заказчик, либо подрядчик из своей маржи. И почти всегда в разборе полётов звучит «надо было лучше согласовать», а не «у нас некому было это собрать».

Почему эту роль вычёркивают из сметы первой

Когда считают бюджет, логика простая: платим за то, что можно потрогать. Разработчик отдаёт работающий код, дизайнер — макеты, тестировщик приносит список дефектов. Менеджер проекта не производит ничего, что можно открыть и посмотреть. В смете он выглядит как накладной расход, и при фиксированной цене строку «управление проектом» — на рынке это обычно 10–15% сметы — просят убрать первой.

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

Третья причина — путаница в том, чем эта роль занимается. За менеджером проекта закрепилась репутация человека, который собирает статусы и напоминает про дедлайны. Если роль понимать так, платить за неё действительно не за что: статусы разработчики напишут и сами, а напоминалку заменяет календарь. Больше девяти лет ведём проекты и видели обе крайности — и команды без управления, и менеджеров, которые занимались ровно перепиской статусов. Вторые вредили не меньше первых.

Что на самом деле лежит на этой роли

Полезная работа менеджера проекта не в контроле, а в том, что он держит четыре вещи, которые иначе не держит никто.

Границу задачи. Что входит в работу, что не входит и по каким признакам мы считаем её сделанной. Это формулируется письменно до начала, а не выясняется на приёмке. «Добавить фильтр по складу» и «добавить фильтр по складу с учётом резерва под неоплаченные заказы» — разные по трудоёмкости задачи, и разница вскрывается либо в начале за полчаса разговора, либо в конце за неделю переделки.

Очередь. У бизнеса всегда больше хотелок, чем часов разработки, и требования приходят из разных кабинетов. Кто-то должен быть единственным местом, где эти потоки сливаются в один список с порядком. Без этого приоритет определяет тот, кто громче написал последним.

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

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

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

Куда уходит время, когда роли нет

Часы не пропадают разом, они утекают по четырём каналам.

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

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

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

Четвёртый — неверный порядок. Сначала сделали красивый личный кабинет, потом выяснили, что интеграция с учётной системой не тянет нужный объём и кабинету нечего показывать.

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

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

Отраслевые отчёты про «проекты с менеджером успешнее на N процентов» приводить не будем: они складывают в одну статистику стройку, внедрение ERP и сайт-визитку, и переносить оттуда цифру на вашу команду бессмысленно. Гораздо честнее посчитать свои два человеко-дня в неделю.

Что происходит с качеством

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

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

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

Когда менеджер не нужен и когда он вредит

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

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

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

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

Как понять, что вам она уже нужна

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

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