Границы правил в маленькой компании: когда нужно устанавливать правила, а когда отпускать

Дилемма правил в маленькой компании

Несколько лет назад, когда я основал Chengdu Past Time Network Technology, нас было всего четверо. Никаких правил: пушили прямо в мастер, отчётность по расходам — скриншот в WeChat, отгул — просто сказал. Дела двигались быстро, но иногда случались сбои — однажды несовпадение полей в базе данных привело к полуторачасовому откату.

Когда команда выросла до дюжины, хаос начал меня беспокоить. Я скопировал систему правил из своей предыдущей крупной компании: еженедельный стендап, отчёт, код-ревью, согласование отпусков, процесс возмещения расходов. Результат? Через два месяца все жаловались. Производительность упала. Писать недельные отчёты стало дольше, чем писать код. Стендапы превратились в ритуал. Срочный баг исправляли два дня из-за цепочки согласований.

Это классическая ловушка правил для маленькой компании: либо нет правил — хаос, либо слишком много правил — паралич.

Ключевая идея: правила — это компромисс транзакционных издержек

Я позже понял: правило — это по сути транзакционные издержки. Вы тратите время на его определение и соблюдение, чтобы уменьшить другие издержки — потери от случайностей, ошибок или конфликтов. Если стоимость соблюдения правила превышает сэкономленные издержки, правило становится обузой.

Почему большим компаниям нужно так много правил? Потому что масштаб увеличивает цену ошибок. Неудачный деплой может затронуть миллионы пользователей. А для маленькой компании цена большинства ошибок низка, зато высока ценность скорости.

Поэтому вопрос не в том, «нужны ли правила», а в том, «где проходит граница».

Фреймворк принятия решений: три вопроса

Теперь я задаю три вопроса, прежде чем формализовать что-либо:

1. Как часто это происходит?

Если еженедельно (например, конфликты слияния, обратная связь от клиентов) — нужен простой стандартный процесс. Если раз в полгода (например, сбой сервера) — достаточно чек-листа, а не правила.

2. Насколько дорогостояща ошибка?

Если одна ошибка может стоить тысячи долларов или ключевого клиента — нужна защита. Если она просто теряет полдня — позвольте ошибки и учитесь.

3. Есть ли у исполнителя здравый смысл?

Если все опытные инженеры — достаточно документа по стилю кода, а не принудительной проверки. Если есть новички или кросс-командная работа — автоматизируйте проверки (линтер, CI) вместо написания правил.

Пример: возмещение расходов. В нашей компании было мало отчётов — около трёх в месяц, каждый до 50 долларов. Раньше я требовал форму, утверждение, проверку финансиста. Люди откладывали и отчитывались раз в год. Я изменил: до 50 долларов — просто скажи мне в WeChat со скриншотом; свыше — короткая записка. Через год ни одной проблемы, и люди стали отчитываться вовремя.

Границы правил в зависимости от размера команды

По моему опыту:

• 1-5 человек (стартап): Правил почти нет. Достаточно доверия и устных договорённостей. Единственное обязательное — как делить деньги.
• 6-15 человек (рост): Вводятся лёгкие правила: стратегия ветвления, SOP по ответам клиентам, ритм встреч. Но каждый раз спрашивайте: «Можно ли сделать легче?»
• 16-30 человек (расширение): Нужны базовые финансовые, HR и проектные правила, но избегайте сложных согласований. Используйте low-code автоматизацию для заявок на отпуск, а не громоздкий workflow.

Парадоксальный вывод: Чем подробнее правило, тем чаще его обходят. Люди находят лазейки, и никто не помнит деталей. Лучше несколько принципов плюс запасной вариант «если сомневаешься, спроси меня».

Как постепенно внедрять правила

Не пишите справочник сотрудника за один раз. Я рекомендую:

1. Фиксируйте точки трения: Когда проблема повторяется или решение застревает, записывайте.
2. Минимальное решение: Напишите одну страницу или автоматизируйте только эту точку. Не думайте о будущих крайних случаях.
3. Пробный месяц: Если за месяц не возникло проблем из-за отсутствия правила, или само правило создало новые — корректируйте или отменяйте.
4. Ежеквартальный пересмотр: Удаляйте устаревшие правила, упрощайте оставшиеся.

Например, частые конфликты слияния. Сначала я хотел написать документ «git workflow». Потом просто написал простой скрипт, который принудительно делает rebase и автоматически проверяет. Этот скрипт работает лучше любого правила.

Правила — не цель

Наконец, самая большая ошибка маленьких компаний — считать «построение системы правил» признаком управленческого мастерства. KPI, OKR, еженедельные отчёты, ежедневные отчёты, обзоры производительности — эти инструменты хороши, но если вы внедряете их только потому, что «все так делают», они становятся обузой.

Настоящее управление — это дать команде возможность принимать правильные решения с низкими затратами. Правила — лишь один из инструментов, и даже не самый важный. Доверие, общение, общие ценности часто решают больше проблем, чем чёрно-белые документы.

PaxLee