Humanized Software Development

Казалось бы, чего общего между скотобойнями и коммерческой разработкой ПО?

Да, хорошие разработчики тоже полностью вкладывают себя в продукты, производимый для совсем других людей, отдают всю свою жизнь и здоровье. Но ведь в этом нет особой трагедии, «it's is circle of life», как и с круговоротом мяса в природе с начала времен.

Однако «невидимая рука рынка» индустриального мира постоянно требует эффективности, а в человеческой культуре самый большой и универсальный опыт управления сосредоточен в тюремной, военной и заводской сфере. В результате, часто добрые люди, ведомые благими намерениями, выстраивают в компании подобие тюрьмы, военного лагеря и завода («как ни собирал — пулемет получается» ©). И получается рукотворный ад совершенно излишних страданий — неоправданные ограничения, иерархия доминирования, ненужные жертвы, несчастные случаи на конвеере и постоянные стрессы.

Все это следствие непонимания области управления, отчего, как в случае с карго-культом, обращаются к «сильнодействующему лекарству» — опыту массового промышленного производства или военной мобилизации, и пытаются перенести эти методы на новую область.

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

А имея власть (организационный, плюс финансовый кнут и пряник) можно «сильнодействующими методами» заставить работать любой, сколь угодно жесткий процесс и пользоваться любыми инструментами контроля, после чего гордится этим и пропагандировать как индустриальные «best practices». Можно ли разорвать этот порочный круг?

Думаю, да, ибо есть пример, когда это удалось в казалось бы таком безнадежном деле, как забой скота. Это тот самый пример, когда увеличивая «эффективность» производства «заводскими методами» были созданы те самые адские-тюрьмы-заводы, где животные не просто убивались, а долго страдали ради «надежного и эффективного процесса». И так было почти везде, и считалось индустриальными «best practices», хотя разумный человек, как бы он не относился к веганам и движениям типа PETA, в ужасе старался не задумываться о том, что там происходит. Но даже там, появился человек, который смог понять коров, и разработал максимально гуманные, и кстати, высокоэффективные системы для этого процесса! Причем, по-большому счету, он просто убрал кучу незаметных мелочей, пугающих скот.

Так давайте уберем все стрессы, пугалки, демотиваторы из процесса разработки!

Но на что ориентироваться, если вы «менеджер-неразработчик», а своим разработчикам не доверяете («что эти молодые лентяи могут знать об эффективном процессе?», «может они нетипичные?», «давайте послушаем серьезных менеджеров из компании на 100500 человек»).

В случае с коровами, у того эксперта был интересный дар наблюдения за животными на свободе. А в нашем случае, мы всегда можем наблюдать за миллионами «диких программистов», разрабатывающих open-source, без стимуляции и насилия!

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

Вот об этом — о принципах «юзабилити» эффективных инструментов поддержки разработки, о основных принципах и о положительных и отрицательных кейсах-примерах, мы и поговорим.