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

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

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

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

Второй игрок в подходах к разработке

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

• 1975 – был организован институт PMI (Project Management Institute) в США. Именно они издают PMBoK (с 1996 года) – справочник для менеджеров проектов. Это самый популярный стандарт для проектного управления во всем мире, буду говорить именно о нём далее по тексту. 

• 1989 – был организован стандарт из Великобритании PRINCE2.

• 1996 – Microsoft и IBM сформировали подходы RUP. 

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

Их называют тяжелыми проектными подходами потому, что они более формализованы и подробно описаны, больше уделяют внимание практическим методам и процессам, чем общему подходу и философии. Достаточно сравнить объемы изданий на английском языке: 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 и классические проектные подходы это воплощение базовых принципов для решения задач. Человеческий мозг – одна из самых сложных вещей во Вселенной, а управляя проектами, мы имеем дело с десятками уникальных мозгов других людей, взаимодействием между ними и гнетущей неопределенностью. 

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

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

2. Гибкие методологии исходят из предпосылки, что невозможно предусмотреть всё и нет смысла долго проектировать и планировать, а истину лучше искать в процессе. В частности, Scrum хорош, когда у нас есть нечеткая цель и мы не знаем в какой форме она может быть решена. Представим, что мы разрабатываем приложение для фитнеса. Мы знаем, что пользователи хотят следить за своим прогрессом, но не понимаем, как именно они предпочли бы это делать – через графики, тексты или подсказки. Вместо того чтобы тратить месяцы на создание окончательной версии приложения, мы начинаем с простого прототипа, получаем обратную связь от пользователей, тестируем разные подходы и постепенно улучшаем его.

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

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

Не забывайте о людях

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

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

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

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