📈 Зачем бизнесу люди, которые «не делают работу» 📉

В команде есть те, кто пишет код, делает дизайн, выпускает фичи. А есть те, кто… НИЧЕГО «физического» не делает: не коммитит в репу, не рисует интерфейсы, не продает.
Они проектируют, проверяют, удерживают фокус, работают с неопределенностью и упреждают ошибки.
Их часто считают «прослойкой».

📈 Почему «прослойку» критикуют?
(далее сугубо мои мысли и не претендую не на что...)
1) «Лишняя прослойка, которая только мешает». Ведь вместо прямого общения программиста с заказчиком появляется менеджер, который может искажать информацию, да и разработчики вполне могут сами общаться с клиентами, а появление продакта тормозит обратную связь.
2) «Бюрократия и замедление вместо гибкости». Ну и тут 2 обоснования:
– дополнительные роли вводят формальности, которые замедляют работу команды;
– каждый менеджер – это минус один разработчик.
3) Недостаток компетенций и размытие ответственности. Эффективность таких ролей сильно зависит от квалификации людей. Оппоненты указывают, что плохой аналитик или проектный менеджер не только бесполезен – он может навредить проекту.
4) «Для маленькой команды не нужны, сами справимся». Когда 5–7 человек вместе делают продукт, они могут совместно обсуждать требования, дизайн и архитектуру, без формальных позиций.

Что говорят исследования?
1) McKinsey «Developer Velocity Index» (2020)
Компании с наивысшей скоростью разработки (топ 25%) росли на 4–5 раз быстрее по выручке, чем аутсайдеры. Анализ показал, что на Developer Velocity значимее всего влияют инструменты, культура и качественный продукт-менеджмент. Иными словами, успешные организации не только имеют хороших инженеров, но и вкладываются в организационные практики: налаженный product ownership, эффективные внутренние платформы, обучение и пр.
2) McKinsey «The Business Value of Design» (2018)
Компании с сильными дизайн-практиками опережают рынок вдвое по темпам роста выручки. Под «сильной дизайн-практикой» подразумевается интеграция UX-дизайнеров, пользовательских исследований и ориентация на клиентский опыт на всех этапах разработки.
Результаты программы Enterprise Design Thinking в IBM (2021)
Эффективность разработки выросла на 75%, а совокупная отдача на инвестиции в дизайн превысила 300% ROI. Те, вложения в роли, отвечающие за пользовательский опыт, окупились в ТРОЕ за счет ускорения и повышения качества.
3) Отчеты Standish Group (Chaos Report) (2020)
Значительная доля провалов IT-проектов связана с неполными или неверными требованиями и отсутствием пользовательского участия. Исправление ошибки на этапе требований дешевле в десятки раз, чем на этапе готового продукта!
4) Stanford Graduate School of Business «Building Organizations That Work» (2012)
Команды, в которых полностью отсутствует формальная иерархия, часто приводят сотрудников в состояние дезориентации и неопределенности, особенно когда задачи нередко требуют координации или распределения ролей. Вывод: компании без иерархии приходят не к революционному равенству, а к усталости от неопределенности. Особенно это ощутимо в компаниях, где задачи сложны, межфункциональны или меняются динамично.

👀 А теперь главное:
Эти роли «прослойки» становятся особенно важны, когда:
— проект растет,
— неопределенность растет,
— когда команд больше одной.
В малой команде можно не иметь аналитика — пока вы в одной комнате.
В продакшене с миллионами пользователей — уже нельзя.
Это не прослойка. Это среда, в которой другие роли могут делать свою работу.

🙃 Да, такие роли раздражают, если сделаны плохо.
Если трекер — это просто микроменеджер.
А аналитик — это перекладыватель задач в Notion.
Но это не аргумент против ролей. Это аргумент против людей в этих ролях.

Когда работают — они дают кратный эффект. А когда нет — лучше бы их не было.

💬А вы: За/Против «прослоек»? Сами «прослойка»?