Короткий ответ
Заказчику лучше работать с одним названным специалистом, который вправе решать вопросы приоритетов, состава работ и приёмки и отвечает за результат. Об этом же говорят открытые стандарты цифровой работы, от американского Digital Services Playbook до Scrum Guide: один человек, а не комитет. До подписания спросите, кто этот человек, что он может решить без согласований, кто его заменяет и как быстро придёт решение, а не просто ответ.
Общий ящик может вам ответить, но не может решить
Многие сервисные компании дают клиенту адрес, который не принадлежит никому в отдельности: проектный ящик, форму поддержки, очередь заявок. У него есть настоящие достоинства. Письма не теряются, когда кто-то в отпуске, историю видят несколько человек, и клиенту всегда есть куда написать. Для рутинных просьб ничего другого и не нужно.
Слабость проявляется на первом же вопросе, который требует суждения. Можно ли сдвинуть запуск на неделю? Входит ли эта правка в цену? Какой из двух вариантов выбрали бы вы? Ящик способен подтвердить получение такого письма за несколько минут. Ответить на него он не может, потому что ответ — это решение, а решению нужен тот, кто вправе его принять и готов за него отвечать.
Поэтому полезно различать не человека и почтовый ящик. Различать нужно канал, который переносит сообщения, и владельца, который закрывает вопросы. В проекте могут быть оба, и часто так и должно быть. Обойтись нельзя без второго: одного названного специалиста, который отвечает за результат и наделён соответствующими полномочиями.
Три открытых стандарта приходят к одному правилу: один человек
Американский государственный свод правил Digital Services Playbook вынес это правило в название шестого пункта: назначьте одного руководителя и спрашивайте именно с него. В тексте говорится о единственном владельце продукта, у которого есть полномочия и обязанность распределять задачи, принимать деловые, продуктовые и технические решения и отвечать за успех или провал сервиса в целом.
Руководство по Scrum (Scrum Guide), в котором Кен Швабер и Джефф Сазерленд описывают фреймворк Scrum, ещё короче: владелец продукта — один человек, а не комитет. Там же есть условие, которое легко пропустить. Чтобы у этого человека получилось, его решения должна уважать вся организация, а те, кто хочет изменить порядок работ, могут сделать это, попытавшись убедить владельца продукта.
Руководство GOV.UK Service Manual говорит о владельце сервиса, что он должен обладать полномочиями принимать решения по всем сторонам проекта. Все три документа написаны для команд, которые создают программы и государственные сервисы, а не для студии, разрабатывающей бренд, или агентства, ведущего кампанию. Рассуждение переносится без изменений, потому что оно о том, как принимаются решения, а не о том, что именно создают.
Отвечать за результат не значит делать всю работу в одиночку
Обычное возражение против одного имени: никто не может знать всё. Это верно и к делу не относится. Scrum Guide точно разводит два понятия: владелец продукта может выполнять работу сам или передать её другим, но в любом случае остаётся ответственным. Дизайнеры проектируют, разработчики пишут код, аналитики измеряют. Один человек отвечает за то, складывается ли целое в обещанное.
Service Manual проводит ту же границу для качества. Качество цифрового сервиса там названо ответственностью всей команды, а окончательная ответственность возложена на владельца сервиса. Для заказчика в этом и состоит практический смысл ответственности: есть один человек, который не может сказать, что это была задача другого отдела, когда что-то провалилось между двумя специалистами.
Отсюда же понятно, почему названный человек должен быть специалистом, а не передаточным звеном. Контрольный список Playbook ожидает от владельца продукта опыта управления продуктом и технических знаний, достаточных, чтобы оценивать альтернативы и взвешивать компромиссы. Тот, кто лишь пересылает вопросы понимающим людям, добавляет к каждому ответу лишний шаг и ничего не снимает с рисков заказчика.
Решения, которые названный человек должен принимать, никого не спрашивая
Имя в договоре стоит ровно столько, сколько полномочий за ним стоит. Проверку подсказывает один из ключевых вопросов Playbook: что требуется владельцу продукта, чтобы добавить функцию в сервис или убрать её? Если честный ответ — совещание пяти человек и письмо директору, у проекта есть представитель, а не владелец.
В коммерческом проекте важны четыре вида решений. Приоритеты: что делается первым, когда времени мало. Состав работ: входит ли просьба в договорённость и от чего отказываются, если что-то добавили. Приёмка: закончена ли часть работы; Service Manual относит это к обязанностям менеджера продукта, который принимает пользовательские истории по готовности. И компромиссы между сроком, стоимостью и качеством, когда сохранить все три нельзя.
Ни один разумный подрядчик не даёт одному сотруднику неограниченной власти, и заказчику не стоит этого ждать. Важно, чтобы пределы были названы. При рабочей схеме ответственный за проект решает всё в рамках согласованных бюджета и срока, а за этими рамками названо, кто утверждает решение. Записанная граница — сила. Граница, обнаруженная на третьей неделе, — тот же безымянный ящик под другим названием.
Непрерывность, когда названный человек заболел, в отпуске или ушёл
Серьёзный довод в пользу общего ящика — непрерывность. Люди болеют, уходят в отпуск и меняют работу, и проект, который живёт в одной голове, останавливается, когда этой головы нет. Опасение справедливо. Лечится оно не тем, что всех делают одинаково ответственными, ведь на деле это значит, что не отвечает никто, а тем, что отсутствие планируют заранее.
Три вещи позволяют заменить названного руководителя, не делая роль безымянной. Заместитель, тоже названный, который следит за работой настолько, чтобы подхватить её. Письменный журнал решений там, где его может читать заказчик, чтобы преемник унаследовал причины, а не только файлы. И учётные записи, файлы и доступы, которые принадлежат компании или заказчику, но никак не личному логину одного сотрудника.
Вот здесь общий ящик на своём месте. Стоя в копии, он даёт заместителю историю, а заказчику — запасной адрес, и вопрос о том, кто решает, остаётся закрытым. Попросите, чтобы о любой смене руководителя вам сообщали письменно и по возможности с периодом передачи дел. Подрядчик, который об этом думал, ответит сразу, потому что порядок у него уже есть.
Два срока: время до ответа и время до решения
Обещания сервиса часто описывают первый срок: как скоро подтвердят получение письма. Ящик, который читают несколько человек, по этому показателю хорош. График заказчика зависит от второго срока: сколько пройдёт, пока вопрос действительно закроют. Проект может две недели получать быстрые вежливые ответы и стоять на месте.
Причину называет стандарт GOV.UK Service Standard в пункте о многопрофильной команде: важно, чтобы люди, участвующие в принятии решений, входили в команду, тогда они подотчётны ей, а команда в целом может быстро реагировать на то, что узнаёт. Когда решающий находится вне разговора, каждый ответ ходит туда и обратно. Когда решает тот, кому вы пишете, этого круга нет.
Согласуйте оба срока письменно. Только для примера: один рабочий день на подтверждение получения, три — на решение вопроса, которому нужны мнения других, и номер телефона для всего, что блокирует запуск. Ваши цифры будут другими. Одинаковым должно быть одно: рабочие часы, часовой пояс, срочный канал и путь эскалации известны до первого дедлайна, а не выясняются во время него.
Вопросы, которые показывают устройство работы до подписания
Начните с первого ключевого вопроса Playbook, заданного своими словами: кто владелец продукта в нашем проекте? Вы ждёте имя и роль, а не «команду». Затем попросите поговорить с этим человеком до подписания договора. Если руководитель появляется только после продажи, вы познакомились с отделом продаж, а не с проектом.
Добавьте ещё четыре вопроса. Что этот человек может решить, никого не спрашивая? Кто заменяет его в его отсутствие и можно ли с ним познакомиться? Как быстро мне ждать решения, а не просто ответа? Что будет, если руководитель уйдёт из компании посреди проекта? Ясные ответы занимают несколько минут. Расплывчатые — тоже информация.
Наблюдайте, как кандидат ведёт себя в этом разговоре. Настоящий ответственный за проект сначала спрашивает о ваших целях и только потом описывает процесс, хотя бы от одной просьбы отказывается или откладывает её с объяснением и точно называет то, что от него не зависит. Затем поищите те же факты на бумаге: руководитель и заместитель названы в договоре или в протоколе стартовой встречи, и там есть строка о том, как происходит смена руководителя.
Заказчику тоже нужно одно имя, а у ящика остаётся своя работа
Правило действует в обе стороны. Подрядчик с единственным ответственным руководителем всё равно буксует, если заказчик отвечает комитетом и трое коллег присылают противоречивые замечания. Фраза из Scrum Guide применима зеркально: владелец продукта может представлять потребности многих заинтересованных сторон и остаётся одним человеком. Назовите того, кто принимает решения с вашей стороны, и сообщите подрядчику, кто это.
Общий адрес при этом никуда не уходит. Счета, запросы доступа, рутинные обновления контента и сбои в нерабочее время лучше обрабатывает очередь, за которой следят несколько человек: там скорость и охват важнее суждения. Ошибка в другом — пускать через очередь решения или превращать названного руководителя в службу поддержки.
Значит, у здравой схемы две части, и заказчик вправе попросить обе: канал, который не теряет ни одного письма, и человек, который не может сказать, что решение было не его. Если в предложении есть только первое, вы покупаете ответы. Если есть оба, а пределы полномочий записаны, вы знаете, кто ответит за результат в тот день, когда что-то пойдёт не так.
Практический чеклист
- Узнайте имя и роль человека, который отвечает за ваш проект, и поговорите с ним до подписания договора.
- Попросите подрядчика записать, что этот человек решает сам по приоритетам, составу работ и приёмке и кто решает за этими пределами.
- Получите имя заместителя и уточните, где фиксируются решения и доступы, чтобы отсутствие одного человека не останавливало работу.
- Согласуйте письменно два срока — на подтверждение получения и на принятие решения — и отдельный канал для срочных вопросов.
- Назначьте одного человека, принимающего решения с вашей стороны, и передавайте сводные замечания только через него.
Вопросы и ответы
Единое контактное лицо и ответственный за проект — это одно и то же?
Не обязательно. Контактное лицо принимает и передаёт сообщения, а ответственный руководитель вправе решать и отвечает за итог. Разница видна на первом трудном вопросе. Если ваш контакт каждую просьбу о приоритетах, составе работ или приёмке несёт кому-то ещё, перед вами передаточное звено, а настоящий автор решений — человек, с которым вы не знакомы.
Что руководитель проекта должен решать без согласований?
Как минимум порядок работ, входит ли просьба в согласованный состав, принят ли результат и чем пожертвовать из срока, стоимости и качества в рамках согласованных бюджета и дедлайна. Решения за этими пределами могут оставаться за названным старшим сотрудником. Главное, чтобы и пределы, и это второе имя были записаны до начала работы.
Что будет с моим проектом, если названный специалист уйдёт?
При подготовке — почти ничего. Заранее попросите названного заместителя, который следит за работой, журнал решений, доступный вам для чтения, и учётные записи и файлы, оформленные на компанию или на вас, а не на отдельного человека. Попросите также письменно уведомлять о любой смене руководителя и по возможности давать период передачи дел, когда доступны оба.
Общий проектный ящик — это всегда плохой знак?
Нет. Общий адрес — правильный инструмент для счетов, запросов доступа, рутинных обновлений и срочных сбоев в нерабочее время, где охват важнее суждения. Тревожным знаком он становится только тогда, когда это единственный путь для вопросов, требующих решения, и никто не может сказать, какой человек это решение примет.
Как проверить ответственность подрядчика до подписания договора?
Спросите, кто будет отвечать за результат, и настаивайте на разговоре с этим человеком, а не только с отделом продаж. Задайте вопрос, который предлагает американский Digital Services Playbook: что потребуется этому человеку, чтобы добавить или убрать функцию? Затем убедитесь, что в договоре или в протоколе стартовой встречи названы руководитель, заместитель и порядок замены любого из них.