Когда-то давно я столкнулся с почти совершенной корпоративной методологией внедрения ИТ-проектов. Она была полной, удобной, масштабируемой и понятной даже джуну (которым я тогда был).

С тех пор, за почти 20 лет внедрений(!) в куче российских компаний, я не встретил равного ей аналога в России. И до массового увлечения Agile, и после него, и даже сейчас, после того, как рынок проголосовал за гибриды WF и Agile.

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

Так в чем же дело? Почему идеал есть, но уже 20 лет большинство компаний изобретают велосипеды, кто как может?

Этот текст - для начинающих РПО и РП, которые хотят вырасти в РПО.

Я расскажу про то, что такое для меня "идеальная методология", чем она отличается от PMBoK, P3.express и всего остального, почему ГОСТ34 не так уж и плох, и почему волшебная таблетка не используется повсеместно, если рецепт был известен уже 20 лет тому назад.

Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление в ИТ.

Начнем с идеала...

Как я встретил идеальную методологию и влюбился

Дело было в далеком 2007 году. Я работал со стороны вендора на большой иностранный телеком - внедрял одну из ключевых систем.

Я тогда был зеленый, но про PMBoK уже знал, что скучнее книги на свете не найти. Дофига написано, ничего непонятно, четкой инструкции нет, артефактов нет, одна вода (это я тогда так думал).

Потому, когда РП со стороны заказчика мне сказал "у нас собственные правила к документации, она нужна именно такая, ты там почитай" и кинул ссылку, я был настроен скептически - опять будет какая-то тяжелочитаемая шляпа, и все придется придумывать самому.

Но я ошибся.

То, что я увидел, вызвало у меня профессиональный оргазм. Больше того, до сих пор вызывает. Это была не просто папка с кучей файликов. И даже не список отрисованных процессов с шагами и ответственными в нотации bpmn, о нет.

Это была интерактивная Квест-карта (напомню, это 2007 год!) по всем этапам жизненного цикла проектов Компании от инициации до передачи в поддержку со всеми необходимыми подпунктами в строгой очередности, со всеми необходимыми артефактами.

И все это было на одной веб-страничке!

Этапы проекта: Инициация/Планирование/Анализ/Разработка/Тестирование/UAT/передача в поддержку - каждый этап четко отделялся от предыдущего и содержал понятные требования по переходу с этапа на этап (ясно, что даже там в жизни этапы могли накладываться друг на друга, но такая штука критична, если за этапы отвечают разные департаменты, как, к примеру бывает с инициацией и всем остальным внедрением).

На каждом этапе на пути следования были расписаны документы, необходимые к созданию, кто их делает.

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

Это была просто магия:

1. Наглядно и суперудобно: все на одной большой картинке;

2. С распределением ответственности: все документы имели свой список согласований по матрице RACI (тогда я как раз впервые и услышал про нее), было ясно, что делает бизнес, что - айтишники, что - техподдержка

3. С защитой от дурака: В каждом шаблоне была структура, правила именования, и заполнения каждого раздела.

4. Интерактивно: Это вам не унылая вики со структурой папок-подпапок, где офигеешь тыкать. Одна картинка, где все можно натыкать самому.

5. А еще это было масштабируемо: для разного размера проектов выделялись или разные пакеты документов:

   1. Small (до миллиона USD) - треть от полного пакета, упрощенные доки и согласования;

   2. Medium - 2/3 от полного пакета;

   3. Large (более 10 млн USD) - полный фарш с архкомитетами, управляющими советами и расширенными матрицами коммуникаций.

РП было достаточно выбрать проект по размеру бюджета - и список шагов и артефактов был определен. И все говорили на одном языке - какая то фантастика.

Это обучало лучше любых тренингов. Новичок просто шел по стрелочкам, и после 1–2 проектов работал как опытный менеджер.

Вау.

Это был «Роскошный максимум». Тогда не было этого выражения, но максимум уже был:)

Что говорить: я сам научился правильной документации именно на этой методологии. Я сам понял, какая должна быть правильная последовательность артефактов, какие правила согласования требований и как тесткейсы связываются с требованиями, зачем нужен каждый документ в цикле разработки большой ИТ системы, и даже зачем нужен в документе раздел «о документе», что там писать, и для кого.

С тех пор я был на многих тренингах по проектному управлению, изучил методологии от PMBoK до модной нынче P3.Express, работал в топовых российских компаниях, но ничего более простого, понятного и ясного не встречал.

Почему?

Проверка реальностью

Можно подумать, что ребята, с которыми я тогда работал, изобрели велосипед. Но нет: если посмотреть на методологии внедрения SAP (SAP Activate или старый ASAP), мы увидим похожий подход.

Логика везде одна: фазы, идущие строго одна за другой (в SAP Activate это разбито на итерации и названо Agile, но суть та же), шаблоны документов и жесткая структура. То есть все выглядит плюс-минус одинаково. Это подтверждает, что подход верный.

ГОСТ-34, описывающий этапы создания информационных систем и документов, тоже подозрительно похож. С поправкой на необходимость продираться сквозь сложные формулировки, но там есть полный стек документации проекта. И даже масштабируемость подразумевается, просто не такая очевидная, как в моем идеале выше.

Почему у вас этого нет (и, скорее всего, не будет)

Да потому что не нужно.
У «Роскошного максимума» есть два фатальных недостатка:

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

2. Еще более высокая стоимость эксплуатации. Cистему надо поддерживать. Нужен отдельный методологический офис, который будет актуализировать шаблоны, обучать новичков, строить аналитику и следить за нарушениями. Хотите красиво и правильно - платите.

У небольшой компании таких денег нет, такая методология может окупиться только для крупняка, где на масштабе будет хорошая экономия как минимум на:

• Контроле за проектами — за счет единых правил;

• Административке — за счет сокращения кучи персонала, приводящего все в единый формат (а таких историй на ИТ рынке много, даже на Хабре палились ребята)

• Обучении — методология учит сама по себе, не надо курсов. Ну ок, можно ролик записать к квест карте, для непонятливых.

• Использовании более дешевых РП (если у меня такая квест карта, мне нужно меньше синьоров, а местами сгодятся даже джуны).

НО
Если вы - цифровая студия или средний бизнес, попытка внедрить такой «идеал» вас убьет. Вы просто потратите весь бюджет на написание регламентов и шаблонов, а код писать станет некому.

А что на счет ГОСТ34?

34ка - это хорошая попытка допрыгнуть до той же планки: документация полная, разделы описаны, масштабируемость заложена (хоть и неявно).

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

А что на счет PMBoK, P3 и всех остальных методологий?

С ними другая история. Их разработали умные ребята, которые постарались сделать описание максимально широким, таким, чтобы оно подошло под основные правила ведения вообще любых проектов. В итоге такие методологии похожи на анекдот "средняя температура по больнице - нормальная": вроде все сказано хорошо и по делу, но как это использовать мне здесь и сейчас - "да фиг его знает" или "да используй, че хошь" (а чего я хочу?). Короче, прикладная польза есть, но только как справочник, и только для тех, кто понимает, как и во что это должно превратиться на земле.

Так что если вы изучили очередную методологию, но ничего не поняли - вы не тупой, с вами все ок, я тоже через это проходил, просто они... несколько оторваны от реальности, иначе этого не описать.

Что делать бедным?

Итак, денег на «Роскошный максимум» нет, ГОСТ адаптировать сложно, хаос надоел, СЕО ругается. Что делать?

1. Все равно помнить про идеал. Его не надо делать, но дергать хорошие мысли оттуда надо. Я на каждом новом месте применял элементы той самой "подсмотренной" когда-то методологии и не могу ее забыть до сих пор, просто потому, что лучше и подробнее - не было.

2. Искать свой собственный баланс между полным хаосом и Роскошным максимумом.

В госухе используют ГОСТ. Он сложный и тяжелый, но если привыкнуть - норм, годится.

Для smb (small-to-medium business) компаний вопрос помимо артефактов внедрения должен касаться еще процесса разработки (если она есть) и точек коммуникации с бизнесом - основные сложности и разочарования я вижу там.

Об этом я могу написать отдельно, если эта тема будет интересна, так что поддержите лайком и каментом, если было интересно :-)