Операция выполнена!
Закрыть
Хабы: Блог компании alabuga

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

Мы прошли этот путь и набили шишки. До внедрения проектного офиса (ПО) ситуация была следующей.

Как мы теряли задачи и сроки: три реальных кейса

Кейс 1. «Вечный реактивный режим»

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

·       Маркетинг ждал интеграцию с CRM, критичную для запуска рекламы, на две недели дольше.

·       Продажи получили «срочный» отчёт, который в итоге никто не открыл, потому что реальная потребность была не сформулирована.

·       Поддержка забросала баг-репортами, и фикс критичной ошибки затерялся среди хотелок по интерфейсу.

·       Разработчик тратил до 30% времени на переключение контекста, а сроки сдвигались сразу по трём направлениям.

Кейс 2. «А я говорил не так»

Заказчик в чате бросил фразу: «Ещё бы хорошо добавить фильтр по регионам». Разработчик кивнул, но задача не была зафиксирована. Через неделю заказчик спросил: «Где фильтр?». Оказалось, что разработчик уже переключился на другую горящую задачу, а сам запрос просто утонул в истории переписки. Возник конфликт: «Ты же обещал», - «Я не помню, когда и в каком объеме». Время ушло на выяснение отношений, а не на разработку. Отсутствие письменного следа означало, что любое изменение требований превращалось в игру «испорченный телефон».

Читать далее
Читайте также
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro