§5.04 Предприниматель, инженер, менеджер: три роли создания
Время: 60 мин чтение + 40 мин = 100 мин Что узнаешь: почему в любом проекте создания системы неизбежно нужны три принципиально разные роли и что происходит, когда одна из них не исполняется
В одном предложении: предприниматель видит возможность, инженер проектирует решение, менеджер организует ресурсы - три роли создания системы, которые могут быть объединены в одном человеке, но не могут быть упразднены.
Сигнатура понятий:
- Предприниматель — это роль, которая видит возможность создать систему, удовлетворяющую чью-то потребность; формулирует «почему» и «для кого»; несёт ответственность за правильность выбора цели
- Инженер — это роль, которая проектирует и создаёт систему, удовлетворяющую требованиям; формулирует «что» и «как»; несёт ответственность за качество технического решения
- Менеджер — это роль, которая организует ресурсы (людей, время, деньги) для достижения цели; формулирует «когда» и «сколько»; несёт ответственность за реализуемость
Мем, который снимается. «Настоящий специалист — это тот, кто умеет делать что-то конкретное; организация и стратегия — это другое.» Этот мем изолирует техническую экспертизу от контекста создания. На деле создание любой системы, даже написание кода в одиночку, требует всех трёх ролей: «какую проблему я решаю?» (предприниматель), «как сделать это технически?» (инженер), «как я распределяю своё время?» (менеджер). Если одну роль игнорировать, система либо решает не ту проблему, либо технически слаба, либо никогда не будет завершена.
Определение из источника.
В Pack (PD.FORM.027) три роли создания описаны следующим образом.
Предприниматель - роль видения: замечает возможность, которую можно реализовать через создание системы; формулирует предпринимательскую гипотезу («если создать X для роли Y, она получит ценность Z»). Предпринимательский предмет интереса - рынок, потребности, возможность. Ролевой интерес - ценность для целевой аудитории.
Инженер - роль решения: получив от предпринимателя «что нужно создать», проектирует «как это создать». Инженерный предмет интереса - архитектура, свойства системы, техническая реализуемость. Ролевой интерес - корректность и качество решения.
Менеджер - роль организации: обеспечивает, что ресурсы распределены правильно, работа идёт в срок, команда функционирует. Управленческий предмет интереса - ресурсы, сроки, взаимодействие. Ролевой интерес - реализуемость и устойчивость процесса.
Развитие мысли.
Три роли создания взаимозависимы, но не взаимозаменяемы. Предприниматель без инженера - идеи без воплощения. Инженер без предпринимателя - техническое совершенство, решающее не ту проблему. Менеджер без предпринимателя и инженера - организованный процесс движения в неизвестном направлении.
В небольших командах или при индивидуальной работе все три роли часто исполняет один человек. Проблема не в совмещении ролей, а в том, что человек может хронически игнорировать одну из них. Технические специалисты часто «выключают» предпринимательскую роль («пусть заказчик думает о том, зачем, я думаю о том, как»). Предприниматели нередко пропускают инженерную роль («детали реализации — это не моя ответственность»). Результат - систематический перекос.
Для созидателя это различение особенно важно при управлении собственным развитием. Предпринимательская роль: «какие навыки создают ценность на пять лет вперёд?». Инженерная роль: «как эффективно освоить конкретный навык?». Управленческая роль: «как выделить время и ресурсы, не разрушив другие обязательства?». Пропуск предпринимательской роли в развитии — это обучение тому, что было актуально пять лет назад.
Метод - минимальный шаг. Практика «Аудит ролей» (40 мин):
- Возьмите проект или направление работы, которым вы сейчас занимаетесь (5 мин).
- Опишите, как каждая роль исполняется: кто в вашей команде (или какая часть вас самого) исполняет роль предпринимателя, инженера, менеджера? (10 мин).
- Для каждой роли оцените по шкале 1–5: насколько полно эта роль исполняется? Что остаётся несделанным? (15 мин).
- Определите самую слабую роль. Запишите: что конкретно нужно сделать, чтобы усилить эту роль на следующей неделе? (10 мин).
Пример из жизни. Антон - разработчик-одиночка, который создавал SaaS-инструмент для дизайнеров. Он месяцами работал над технической частью (инженерная роль) и разбивался об одну проблему: продукт не продавался. Консультация выявила: Антон никогда не применял предпринимательскую роль, не тестировал гипотезу «кто конкретно купит и зачем». Он исходил из собственного ощущения «это нужно дизайнерам», но не проверял это с реальными людьми. Управленческая роль тоже страдала: у него не было расписания, и функции добавлялись хаотично. Когда Антон разделил задачи по трём ролям и выделил время на каждую, движение возобновилось: две недели на предпринимательские интервью с дизайнерами, потом пересмотр архитектуры, потом планирование до релиза.
Типичная ошибка. «Разделение ролей — это для больших команд, у нас слишком маленький проект.» Люди склонны считать, что чем меньше проект, тем менее важна ролевая ясность. На деле в малом проекте отсутствие ролевой ясности заметнее всего: один человек постоянно «переключается» между ролями, не осознавая этого, и каждое переключение без явного разграничения становится источником незаметных сбоев.
Вторая ошибка: считать, что предпринимательская роль — это «начальник», инженерная - «исполнитель», а управленческая - «администратор». Это должностные ярлыки, не функциональные роли. Инженер может исполнять предпринимательскую роль (предлагая техническое направление развития). Предприниматель может исполнять инженерную (прототипируя решение). Роли не привязаны к должности.
Степени мастерства:
| Степень | Что происходит | Критерий перехода |
|---|---|---|
| 1. Объясняю | Могу описать три роли создания и их предметы интереса | Один раз выполнил «Аудит ролей» для своего проекта |
| 2. Умею | Могу для любого проекта назвать, кто исполняет каждую роль, и найти пробел | Есть запись: проект + три роли + их текущее исполнение + слабое место |
| 3. Навык | Автоматически замечаю в командной работе, когда одна из ролей создания не исполняется | Случай, когда я диагностировал пропуск роли и предложил способ заполнить пробел |
| 4. Мастерство | Помогаю командам явно распределять роли создания и диагностировать перекосы | Кейс, где явное распределение ролей исправило системный сбой в проекте |
Проверка себя.
- Понимание: вы можете объяснить, что происходит с проектом, если в нём нет явного исполнителя предпринимательской роли.
- Поведение: когда вы начинаете новый проект, вы явно спрашиваете: «кто отвечает за предпринимательскую роль, кто за инженерную, кто за управленческую?»
- Застревание: если проект движется медленно и никто не понимает почему, проверьте, все ли три роли создания исполняются. Чаще всего одна из них «предполагается», но реально не выполняется.
Что дальше. Три роли создания описывают, кто создаёт систему. Но в сложных организациях есть ещё более специализированные роли, те, кто проектирует саму организацию как систему: архитектор предприятия, директор по развитию, проектировщик организации. Следующий подраздел - о трёх ролях, которые работают не с продуктом или проектом, а с самой организационной системой.