Пятничный наброс

Есть два способа управлять разработчиками, через процессы и через использование головного мозга.

В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.

Плюсы: можно брать более-менее любого человека, его поставят на рельсы, проконтролируют, и поезд будет ехать в нужную сторону
Минусы: нет чувства ответственности за результат, все заняты процессами. Да и вообще, подход "один размер подходит всем" работает не очень эффективно, поэтому быстрой разработки тут не будет точно. Смелых решений никто не предложит. Ты начальник, я дурак. Инициативные люди устают биться о стену апрувов на каждый чих и выгорают. Тимлид тоже подгорает, потому что приходится принимать все решения, а не все решения принимаются правильно (так как сверху видно далеко не всё).


Во втором случае предполагается, что мы нанимаем не только навыки кодописательства, но и мозг целиком. Что программист может сам обговорить некоторые детали с заказчиком, сам понять, что важно тестировать, а что нет. Какие подходы и библиотеки использовать. Например, потому что он сам же будет это поддерживать, выкатывать на прод и разгребать потом проблемы. Формальные апрувы необязательны, разве что он сам захочет показать код товарищам для валидации идеи.

Плюсы: максимальная свобода порождает дополнительную мотивацию. С развязанными руками легче работать. Появляется ответственность за результат. Результат достигается оптимальным в данном контексте образом, а не по усредненной инструкции. Предлагаются идеи, что можно поменять, чтобы было легче работать. Тимлид на расслабоне может поехать в отпуск, да и вообще он может себе позволить быть самым тупым в команде, это нормально.

Минусы: огромные требования к найму. Если ленивый или тупой попадет в команду с максимальной свободой, то проекту пизда. Отсюда вытекает главное требование к тимлиду: быть способным быстро уволить человека, который работает плохо. И не мешать ничем людям, которые и так работают хорошо. По сути, надо изредка контролировать лишь результат: код более менее норм, пишется быстро, прод не ложится каждые 5 минут и т.д. А как именно человек этого достиг - это его дело.

Понятно, что новичков все равно придется контролировать поначалу, да и вообще, это крайние вырожденные случаи, обычно бывает смесь двух подходов. Но я всё же явно тяготею к последнему способу и стремлюсь продвинуться к нему как можно сильнее.