В компании, где есть бизнес и разработка, рано или поздно прямой диалог заказчика с аналитиком или разработчиком перестаёт работать. На старте кажется, что это верх эффективности: без лишних звеньев, быстро и «по душам». Но на деле такая схема - шаткая верёвка над пропастью, которая рвется под нагрузкой растущего числа задач.Мы прошли этот путь и набили шишки. До внедрения проектного офиса (ПО) ситуация была следующей.Как мы теряли задачи и сроки: три реальных кейсаКейс 1. «Вечный реактивный режим»Один из наших разработчиков одновременно работал с тремя внутренними заказчиками: из маркетинга, продаж и службы поддержки. Каждый писал ему в личку, и каждый считал свою задачу «пожаром». Разработчик сам решал, что делать первым, ориентируясь не на бизнес-ценность, а на настойчивость просящего. В итоге:· Маркетинг ждал интеграцию с CRM, критичную для запуска рекламы, на две недели дольше.· Продажи получили «срочный» отчёт, который в итоге никто не открыл, потому что реальная потребность была не сформулирована.· Поддержка забросала баг-репортами, и фикс критичной ошибки затерялся среди хотелок по интерфейсу.· Разработчик тратил до 30% времени на переключение контекста, а сроки сдвигались сразу по трём направлениям.Кейс 2. «А я говорил не так»Заказчик в чате бросил фразу: «Ещё бы хорошо добавить фильтр по регионам». Разработчик кивнул, но задача не была зафиксирована. Через неделю заказчик спросил: «Где фильтр?». Оказалось, что разработчик уже переключился на другую горящую задачу, а сам запрос просто утонул в истории переписки. Возник конфликт: «Ты же обещал», - «Я не помню, когда и в каком объеме». Время ушло на выяснение отношений, а не на разработку. Отсутствие письменного следа означало, что любое изменение требований превращалось в игру «испорченный телефон». Читать далее