Бюрократия

November 29, 2016

Сегодня покачаю лодку в другую сторону для разнообразия. Вообще я всегда за такое фри, креатив и отсутствие отчетов, но однако есть секретное оружие, которое решает все проблемы разработки и не только, это - бюрократия. Если что-то не ладится - значит не хватает формализма.

Эту силу я познал в CQG, где были очень сильные и формальные процессы, так как работа идет с большими деньгами. Если задача была чуть более сложная, чем совсем очевидная, она всегда была у простого разработчика одна. Максимум три. И когда задача всего одна, все равно нужно же как-то отчитываться, что по ней сделал. Даже если было непонятно ничего, то можно было как минимум пообщаться с постановщиком задачи, тимлидом, архитектором, человеком из матрицы компетенций, написать несколько писем и пару документов. И чудо, если сделать это даже в самой безнадежной и сложной проблеме, она сдвинется с места. И будет медленно двигаться.

Естественно обратная сторона любого формального процесса - это стоимость. Когда разработчик три недели пишет HLD - это довольно дорого, и компании стараются организовать дела так, чтобы можно было "чик, чик и в продакшен". Баланс между формализмом и процессной свободой зависит от многих факторов и мне кажется немножко является искусством. В продуктовой компании, конечно, формализма может быть меньше, если фича успешная - ТЗ и вроде как не нужно, а провальная - не поможет. В разработке на заказ начинает играть аджайл, спринты, постоянная визуализация результата.

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

comments powered by Disqus