Узнайте, почему истинное чувство собственника в разработке — это не послушание, а готовность спорить. Как не спутать лояльность с ответственностью и построить культуру, где инженеры спасают проекты, а не просто выполняют задачи.
Вы когда-нибудь просили инженера "проявить чувство собственника", а потом жалели об этом? Менеджеры обожают эту фразу, пока не сталкиваются с её последствиями. Настоящий собственник не просто кивает — он задаёт неудобные вопросы, тормозит спринты и спорит с архитектурой. И это именно то, что нужно для создания надёжного продукта. В этой статье разберём, почему культура послушания убивает проекты, и как построить среду, где инженеры реально заботятся о результате.
Представьте типичное совещание. Менеджер говорит: "Нам нужен человек с настоящим чувством собственника, который переживает за продукт". Инженер поднимает руку: "Эта архитектура упадёт при конкурентных записях, давайте переделаем модель данных". Через минуту тот же менеджер: "Почему ты такой сложный? Мы уже опаздываем, просто сделай".
Знакомо? В чём подвох? Вы просили ownership — получили его. Но ownership пришёл с мнением, а мнение оказалось неудобным. На самом деле проблема не в коммуникации, а в стимулах. Боль от задержки сегодня ощутимее, чем боль от аварии через квартал. Иерархия кажется эффективной, когда вы наверху. А compliance (послушание) маскируется под прогресс.
Настоящий собственник не тот, кто молча делает, а тот, кто:
Рассмотрим пример: функция поиска пользователей. Первая версия — без индекса, с потенциальным N+1.
# Плохо: нет индекса, N+1 запросов
def get_users_with_orders(db):
users = db.execute("SELECT * FROM users") # один запрос
for user in users:
# для каждого пользователя ещё запрос — это N+1
orders = db.execute(f"SELECT * FROM orders WHERE user_id = {user['id']}")
user['orders'] = orders
return users
Инженер с ownership скажет: "Это упадёт при 1000 пользователях. Давайте сделаем JOIN и поставим индекс".
# Хорошо: один запрос с JOIN и индексом
def get_users_with_orders(db):
# Создаём индекс, если его нет (ownership — думать о масштабе)
db.execute("CREATE INDEX IF NOT EXISTS idx_orders_user_id ON orders(user_id)")
# Один запрос вместо N+1
users = db.execute("""
SELECT u.*, o.id as order_id, o.amount
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
""")
# Группируем заказы по пользователям
from collections import defaultdict
result = defaultdict(lambda: {'orders': []})
for row in users:
user_id = row['id']
if user_id not in result:
result[user_id] = {'id': user_id, 'name': row['name'], 'orders': []}
if row['order_id']:
result[user_id]['orders'].append({'id': row['order_id'], 'amount': row['amount']})
return list(result.values())
Это и есть ownership: не молча сделать, а подумать о последствиях и предложить лучшее решение. Да, это занимает на 15 минут больше. Но спасает от падения продакшена через месяц.
Если наказывать за инициативу, культура меняется:
Вы получаете краткосрочную скорость и долгосрочный хаос. А потом проводите ретроспективу, где все соглашаются: "надо было говорить раньше". Но никто не спрашивает, почему перестали.
Дайте инженерам время подумать, прежде чем брать обязательства. Мозговой штурм и быстрая поставка — не враги. Не смешивайте их в одной встрече.
Если инженер поднял важный вопрос, а вы его отклонили — сделайте это решение видимым. Если он оказался прав — признайте это публично. Если неправ — он узнает предметную область. В любом случае сигнал: говорить — часть работы.
"Возьми ownership" — пустая фраза. Если нужно "сделать к пятнице, даже грязно" — скажите это. Если нужно "выдержать 10x трафик" — скажите это. Размытые лозунги заставляют людей гадать, за что их наругают.
Инженеры живут в коде, который вы видите только через тикеты. Это не упрямство — это их работа. Не всегда они правы, но их аргументы основаны на реальности, а не на политике.
Лучшие команды спорят о дизайне, а на следующее утро доверяют друг другу. Разногласия — не личное. Когда вы делаете их личными, вы получаете подхалимов и сломанные системы.
Вам, скорее всего, действительно нужны инженеры с чувством собственника. Но вы не хотите — и случайно отбираете — тех, кто улыбается, делает и позволяет вам бежать в стену, чтобы оставаться популярным.
Ownership — это раздражающе. Он задаёт неудобные вопросы. Тормозит встречи "просто сделай". Заставляет старших защищать решения, которые они считали окончательными.
Если это звучит утомительно — что ж, такова цена создания продукта, который не развалится при первых настоящих пользователях.
Вы не можете получить одновременно "людей, которым не всё равно" и "людей, которые никогда не спорят". Выбирайте. И если выбираете послушание — хотя бы перестаньте называть это ownership. Это слово всё ещё что-то значит для тех, кто действительно строит.
На следующей встрече по планированию, когда инженер начнёт возражать — не обрывайте его. Спросите: "Какие альтернативы ты видишь?" и "Какие риски мы берём, если сделаем по-твоему?". Запишите решение и через месяц проверьте, кто был прав. Это первый шаг к культуре, где ownership — не лозунг, а реальность.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →