Задачу сдали в пятницу. В понедельник заказчик открывает результат и говорит: это не то. Придраться формально не к чему — разработчик сделал ровно то, что было написано в сообщении от двенадцатого числа. Но между двенадцатым и пятницей коммерческий директор в другом чате попросил добавить отбор товаров по складу, а бухгалтерия отдельным письмом уточнила: цену надо показывать и с НДС, и без. Никто ничего не забыл и не схалтурил. Просто эти три разговора нигде не встретились.
Дальше — неделя переделки, и платит за неё либо заказчик, либо подрядчик из своей прибыли. Человека, чья работа — сводить такие разговоры в одно место, называют менеджером проекта или проджект-менеджером. Он не пишет код и не рисует макеты. Разберёмся, за что ему платят и когда он действительно не нужен.
Почему эту строку вычёркивают из сметы первой
Логика при подсчёте бюджета простая: платим за то, что можно потрогать. Разработчик отдаёт работающий сайт, дизайнер — картинки будущих страниц, тестировщик приносит список ошибок. Менеджер не отдаёт ничего, что можно открыть и посмотреть, и строку «управление проектом» — обычно 10–15% сметы — просят убрать первой. Второй довод убедительнее: команда маленькая, все на связи, договоримся напрямую. Так и есть — пока в проекте один заказчик, один разработчик и одна задача.
Третья причина — путаница в том, чем этот человек занимается. За ролью закрепилась слава того, кто собирает отчёты о ходе работ и напоминает про сроки. Если понимать её так, платить не за что: отчитаться разработчик может и сам, а напоминалку заменяет календарь.
Что на самом деле лежит на этой роли
Полезная работа менеджера — не контроль. Он держит четыре вещи, которые иначе не держит никто.
Границы задачи. Что входит в работу, что не входит и по каким признакам считаем её сделанной. Это записывают до начала, а не выясняют при сдаче. «Добавить отбор по складу» и «добавить отбор по складу с учётом товара, отложенного под неоплаченные заказы» — работа разного объёма. Разница вскроется либо в начале, за полчаса разговора, либо в конце, за неделю переделки.
Очередь задач. У бизнеса всегда больше пожеланий, чем часов разработки, и приходят они из разных кабинетов. Нужно одно место, где эти просьбы складываются в общий список по порядку. Иначе очередь выстраивает тот, кто громче написал последним.
Обещания других людей. Пароли от сервера остались у прежнего подрядчика, данные готовит специалист заказчика по 1С, сертификат оплачивает бухгалтерия, договор смотрит юрист. Разработчик, упершийся в такое ожидание, просто стоит — а со стороны это выглядит как «медленно делают».
Перевод с одного языка на другой. Бизнес говорит «остатки не сходятся». Разработчик слышит «на сайте и в 1С разные цифры». Кто-то должен понимать оба языка и задавать уточняющие вопросы обеим сторонам.
Заметнее всего это там, где сайт обменивается данными с 1С: со стороны заказчика работает свой специалист, сайт делает подрядчик, и между ними висят вопросы — в каком виде передавать данные, как часто, кто отвечает за расхождения. Техническое решение тут есть, и мы им пользуемся, но договариваться с людьми на той стороне всё равно приходится. Договаривается не программа.
Куда уходит время, когда роли нет
Часы пропадают не разом, а по четырём каналам.
Первый — ожидание. Разработчик упирается в вопрос вроде «какую цену показывать, если товара нет в наличии и он идёт под заказ», и пишет в общий чат. Ответ приходит через сутки: тот, кто его знает, был в отпуске, а остальные не поняли, что спрашивают их.
Второй — переключение между делами. Разработчик, который сам ведёт переписку, весь день прыгает между двумя занятиями: разбираться в программе и разбираться в людях. После каждого разговора нужно время, чтобы снова войти в задачу.
Третий — переделки, самый дорогой канал: за него платят дважды. Сначала за работу, которую сделали не так, потом за ту же работу, сделанную правильно.
Четвёртый — неверный порядок работ: сначала сделали красивый личный кабинет покупателя, а потом выяснили, что из учётной системы приходит слишком мало данных и показывать в нём нечего.
Считать удобнее в часах: ставки у всех разные, а соотношение примерно одинаковое. Возьмите команду из трёх разработчиков и прикиньте, сколько времени каждый тратит на переписку, уточнения и созвоны. Обычно набегает около часа в день — пятнадцать часов в неделю, почти два полных рабочих дня, оплаченных по ставке разработчика. А час специалиста, для которого общение и есть основная работа, стоит в два-три раза дешевле. Совсем разговоры не исчезнут, но пропадает второй счёт — за переделки, которых при заранее записанных условиях приёмки не возникает.
Что происходит с качеством
Качество здесь — не количество ошибок в программе. Тестировщик ловит поломки, но не ловит главную беду проекта: сделали аккуратно, работает исправно, а нужно было совсем другое. Эта ошибка рождается в самом начале, когда задачу поняли по-своему, и всплывает при сдаче.
Второй слой — последствия в соседних местах. В большом интернет-магазине — скажем, 400 000 товаров и 4 000 посетителей в сутки — безобидная правка в расчёте цены уезжает дальше самого сайта: в файлы с товарами для маркетплейсов, в поиск по каталогу, в отчёты. Разработчик держит в голове свой участок; кто-то должен держать всю картину и спросить «а что будет с выгрузками» до того, как правку выложат.
Третий слой — предсказуемость. Когда известно, что и когда будет готово, бизнес может готовиться к сезону, запускать рекламу, обучать менеджеров. Без этого проект превращается в чёрный ящик, и обходится такая неизвестность дороже самой разработки.
Когда менеджер не нужен и когда он вредит
Роль нужна не всем. Если в проекте один разработчик, один человек со стороны бизнеса, который принимает решения, и задачи приходят по одной — посредник только удлинит цепочку. Поток однотипных мелких задач тоже обходится без отдельного человека: хватает письменных правил — куда писать заявку, в каком порядке их берут в работу и за какое время мы отвечаем. Часть проектов мы так и ведём; про приёмку сайта на поддержку рассказали в отдельной статье.
Эту работу может тянуть и сам владелец бизнеса, если готов отдавать ей несколько часов в неделю: записывать, что считаем сделанным, держать один список приоритетов, отвечать на вопросы в течение дня. Плохо работает другое — когда управление вешают на ведущего разработчика в довесок к задачам. Он либо перестаёт писать код, либо перестаёт управлять. Обычно страдает управление: код виден, а его отсутствие — нет.
Вредит же менеджер в двух случаях. Без права решать он превращается в испорченный телефон: передаёт вопросы туда и обратно, добавляя круг задержки. А не разбираясь в деле заказчика — задаёт бизнесу вопросы разработчика, разработчику вопросы бизнеса и раздражает обоих. Сюда же порядок ради порядка: ежедневные совещания на команде из двух человек, три списка задач в разных программах, отчёты, которые никто не читает.
Как понять, что она вам уже нужна
Смотреть надо не на размер команды, а на число мест, где люди передают работу друг другу. Задачи приходят больше чем от двух человек. В работе одновременно больше двух исполнителей. Есть зависимость от кого-то снаружи — свой специалист по 1С, агентство, поставщик данных. Работу регулярно возвращают на доработку после сдачи. Совпало хотя бы три пункта — роль в вашем проекте уже существует, просто её бесплатно и плохо выполняют несколько человек сразу.
При этом менеджер проекта — это работа, а не обязательно отдельная должность и целая ставка. Её можно взять на часть времени, отдать подрядчику вместе с разработкой или закрыть силами владельца. Выбор тут примерно такой же, как между своим программистом и внешней командой. Ошибка не в том, что роль не наняли отдельно, а в том, что её не поручили никому.
