2017-04-29: инженерная культура и ее ограничения

Этот пост возник, как ответ на один из вчерашних докладов на IT Spring 2017, в котором нам рассказывали о построении конвейера в IT-разработке, чтобы делать программы как автомобили по всем правилам инженерной науки. Так вот, это доклад не инженера, а изобретателя. Изобретатели — очень увлеченный народ, уверенный в своей гениальности, в том, что у них точно получится, даже если у многих раньше — не получалось. Например, вечный двигатель. А инженеры — они все-таки сначала смотрят на работы предшественников и разбираются с предметом.

То, что софт нельзя производить по регламентам и правилам было осознано на опыте проектов еще в 1980-х, и об этом есть классическая книга Тома ДеМарко «Человеческий фактор». А несколько позднее, в 1992 в статье What is software design (перевод) Ривз объяснил, почему так, в чем именно отличается разработка ПО от создания самолетов, которые у Боинга не только собираются, но и проектируются по регламентам, и почему вследствие этих отличий производство софта по регламентам не работает. Схема этого объяснения - справа.

Но инженеры — они ведь умные. Это у других не работает, а они придумают так, что заработает. И группа гуру во главе с Иваром Якобсоном (автором use case и соавтором UML) придумала RUP. Но и у них не получилось? этому есть много примеров и статистика. Конечно, всегда есть объяснение, что это не получилось по причине неправильного применения регламентов. Но квалифицированные инженеры — они осознают свои ошибки, и для меня лично достаточным основанием является факт, что практически все ведущие авторы RUP, включая самого Ивара, достаточно быстро приняли Agile, который был следующим тактом развития, и участвуют в его развитии.

Впрочем, это не останавливает других инженеров: ну и что, что у других не получилось, у них-то получится. Конечно, может и получится, только для этого в конструкции должны быть некоторые принципиальные инновации по сравнению с предыдущими провалами. А этого — не наблюдается, в докладе было рассказано о конструкции регламентов на 4-5 уровней, а далее авторы с удивлением обнаружили, что большинство проектов у них на нулевом, перевели их на первый, получили профит. Что давно известно и в Agile — гигиеническое нормирование процесса необходимо. Только там для этого применяется легкий механизм чек-листов начального уровня, без разработки совершенной многоуровневой конструкции, которая останется в идеальном мире.

И, что интересно, сейчас регламенты перестают работать не только в IT, но и в других отраслях. Почему так — написал другой классик, Питер Друкер в книге «Менеджмент. Вызовы XXI». Анализируя изменения в характере деятельности, связанные с повышением роли знаний, он выделил возникающие при этом вызовы, на которые традиционный менеджмент не может ответить — а они непременно придут. И они уже пришли. Зафиксированные на глобальном уровне тренды Business Agility и Цифровизации обесценивают культуру правил, делая это, однако, по-разному.

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

Кстати, сама конференция мне понравилась. Разработчики разбираются с софт скилл, основательно, в том числе - добираясь до старых теорий, и я узнал про психоделическую революцию Тимоти Лири и его подходы к описанию личности в рассказе Ярополка Раша, и про связь конституции человека с его психозами в модели Эрнста Кречмера, о которой рассказывал Юрий Сорокин. Я, кстати, по ней - маниакально-депрессивный шизоид. Но позитивный. На этом, пожалуй, закончу.

[ Хронологический вид ]Комментарии