29 лет топтания на месте. Почему подходы к разработке ПО не развиваются?

Scrum появился осенью 1995 года и по сей день остается самым популярным Agile фреймворком разработки программного обеспечения. Первое руководство по Scrum уже в 2001 году включало всё то, с чем сталкивались большинство из нас: распределение по ролям, артефакты и церемонии (планирование спринта, стенд-ап, демо и ретроспективы). Концепция уточнялась, но это был всё тот же Scrum, с которым в том или ином виде работал практически каждый в IT хотя бы немного.

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

Однако в сфере проектных подходов и Scrum в частности нет даже сотой доли этого прогресса, они остались практически неизменны, хотя есть явная неудовлетворенность итоговыми результатами, как и у бизнеса, так и у непосредственных исполнителей. Как же так вышло и что с этим делать?

Помимо легких подходов вроде Scrum и Kanban существуют и тяжелые проектные подходы, они появились в большинстве своем раньше гибких:

Все эти стандарты представляют описание последовательных процессов разработки и реализации проекта, направленных на то, чтобы удержать его в треугольнике “сроки - бюджет - содержание”. Родились они из личного опыта и практики родоначальников стандартов, которые попытались систематизировать те подходы и решения, которые хорошо работали в их проектах и передать знания другим менеджерам.

Их называют тяжелыми проектными подходами потому, что они более формализованы и подробно описаны, больше уделяют внимание практическим методам и процессам, чем общему подходу и философии. Достаточно сравнить объемы изданий на английском языке: Scrum руководство в 14 страниц и PMBoK 7-ой редакции на 370 страницах. Я не буду подробно останавливаться на их принципиальных различиях, но нельзя не отметить, что семейство Agile фреймворков и тяжелые подходы находились в тесной связи долгие годы и влияли друг на друга и на то, как разрабатывались проекты и продукты в сфере ПО.

Концепция, отраженная в PMBoK от PMI не стояла на месте как и Scrum, на сегодняшний момент доступна 7 редакция. Однако по существу мало что изменилось, но, например, в PMBoK впервые описал гибкие методологии разработки Scrum и Kanban в 5 редакции в 2013 году как о возможной опции, полноценно включил практики уже в 6 редакции с расширенными рекомендациями по использованию.

В этой сфере прогресс ощутим и заметен, однако в нём не так много золотых стандартов, которые используют все, таких, например, как система контроля версий Git при разработке ПО. Появился Git, кстати, в 2005 году, а его предшественник SVN в 2000, я даже застал работающие проекты на SVN, хотя я не такой уж старый.

Задачи вместо физических досок ведут в таск-трекерах, документацию хранят в вики и правят совместно в режиме реального времени. Для упрощения построения планов и планирования ресурсов используют ПО для построением диаграммы Ганта, это позволяет удобно следить за ходом проекта, отмечая отклонения.

Среди программного обеспечения высокая конкуренция: лучшие UI/UX специалисты бьются за каждый пиксель интерфейсов, а разработчики за каждую миллисекунду быстродействия (или нет, но я пользуюсь облачной Jira, возможно в этом проблема). Последний тренд – использование AI для утилитарных нужд руководителя проектов: записать встречу и подвести итоги в письменном виде, генерация и накидывание идей, накидывания шаблонов документов по планированию рисков и т.д.

Потребность в выполнении задач бизнеса для зарабатывания денег огромная, крупные сервисы сражаются за увеличение конверсии в 0,001%, что выражается в миллионные прибыли. Спрос на увеличение эффективности продуктов и проектов есть, но ни Scrum/Kanban, ни классические проектные подходы не предлагают за годы кардинальных и радикальных изменений в себе, чтобы это обеспечить. В чем же причина?

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

Эти факторы формируют два ключевых подхода:

Обращу внимание, что ни один из подходов не имеет ультимативных преимуществ перед другим, и у каждого есть свой набор недостатков и ограничений. Думаю, каждый бывалый ITшник может вспомнить пример пары провальных проектов с применением каждой методологии, а то и не пару, а десяток-другой.

Хотя подходы к разработке существенно не изменяются уже много лет, у меня есть надежда, что в следующие лет 20 появится новая методология. Как это будет работать пока до конца непонятно, но ключевая задача состоит в том, чтобы по-новому взглянуть на неопределенность, двигаться сразу в нескольких направлениях для ее уменьшения, учитывать множество вариантов и быстро принимать решения по устранению проблем. Да, я знаю, больше похоже на фантастику, но у каждого должны быть свои мечты :)

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

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

Мы встречаем много людей на протяжении нашей IT жизни, классический конфликт “плохой проджект - плохой разработчик” уже набил оскомину и никогда полностью его не искоренить. Но хочу дать вам напутствие: цените коллег, которые бок о бок с вами сражаются с неопределенностью и особенно тех, кто греет вам душу, а не задницу. В следующий раз на очном дейли митинге обнимите проджекта или разработчика, которого цените и скажите ему: “Я хочу провести следующие тысячу митингов с тобой!” :)

Если вам было интересно, хотите больше всего и разного про проектное управление и IT, то подписывайтесь на мой Телеграм канал.