Когда-то давно я столкнулся с почти совершенной корпоративной методологией внедрения ИТ-проектов. Она была полной, удобной, масштабируемой и понятной даже джуну (которым я тогда был).
С тех пор, за почти 20 лет внедрений(!) в куче российских компаний, я не встретил равного ей аналога в России. И до массового увлечения Agile, и после него, и даже сейчас, после того, как рынок проголосовал за гибриды WF и Agile.
И это не потому, что у нас методология в компаниях не нужна - нужна, еще как. Тренд на оцифровку процесса управления проектами компании - такой же старый, как PMBoK. Потребность в формализации бардака в ИТ только растет.
Так в чем же дело? Почему идеал есть, но уже 20 лет большинство компаний изобретают велосипеды, кто как может?
Этот текст - для начинающих РПО и РП, которые хотят вырасти в РПО.
Я расскажу про то, что такое для меня "идеальная методология", чем она отличается от PMBoK, P3.express и всего остального, почему ГОСТ34 не так уж и плох, и почему волшебная таблетка не используется повсеместно, если рецепт был известен уже 20 лет тому назад.
Статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, а особенно той его части, которой толком никто не учит: софтскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление в ИТ.
Начнем с идеала...
Как я встретил идеальную методологию и влюбился
Дело было в далеком 2007 году. Я работал со стороны вендора на большой иностранный телеком - внедрял одну из ключевых систем.
Я тогда был зеленый, но про PMBoK уже знал, что скучнее книги на свете не найти. Дофига написано, ничего непонятно, четкой инструкции нет, артефактов нет, одна вода (это я тогда так думал).
Потому, когда РП со стороны заказчика мне сказал "у нас собственные правила к документации, она нужна именно такая, ты там почитай" и кинул ссылку, я был настроен скептически - опять будет какая-то тяжелочитаемая шляпа, и все придется придумывать самому.
Но я ошибся.
То, что я увидел, вызвало у меня профессиональный оргазм. Больше того, до сих пор вызывает. Это была не просто папка с кучей файликов. И даже не список отрисованных процессов с шагами и ответственными в нотации bpmn, о нет.
Это была интерактивная Квест-карта (напомню, это 2007 год!) по всем этапам жизненного цикла проектов Компании от инициации до передачи в поддержку со всеми необходимыми подпунктами в строгой очередности, со всеми необходимыми артефактами.
И все это было на одной веб-страничке!
Этапы проекта: Инициация/Планирование/Анализ/Разработка/Тестирование/UAT/передача в поддержку - каждый этап четко отделялся от предыдущего и содержал понятные требования по переходу с этапа на этап (ясно, что даже там в жизни этапы могли накладываться друг на друга, но такая штука критична, если за этапы отвечают разные департаменты, как, к примеру бывает с инициацией и всем остальным внедрением).
На каждом этапе на пути следования были расписаны документы, необходимые к созданию, кто их делает.
Документы можно было скачать в виде шаблона. При этом внутри была готовая рыба со структурой и кратким описанием по разделам, что в них должно быть написано — реально «для тупых».
Это была просто магия:
Наглядно и суперудобно: все на одной большой картинке;
С распределением ответственности: все документы имели свой список согласований по матрице RACI (тогда я как раз впервые и услышал про нее), было ясно, что делает бизнес, что - айтишники, что - техподдержка
С защитой от дурака: В каждом шаблоне была структура, правила именования, и заполнения каждого раздела.
Интерактивно: Это вам не унылая вики со структурой папок-подпапок, где офигеешь тыкать. Одна картинка, где все можно натыкать самому.
А еще это было масштабируемо: для разного размера проектов выделялись или разные пакеты документов:
Small (до миллиона USD) - треть от полного пакета, упрощенные доки и согласования;
Medium - 2/3 от полного пакета;
Large (более 10 млн USD) - полный фарш с архкомитетами, управляющими советами и расширенными матрицами коммуникаций.
РП было достаточно выбрать проект по размеру бюджета - и список шагов и артефактов был определен. И все говорили на одном языке - какая то фантастика.
Это обучало лучше любых тренингов. Новичок просто шел по стрелочкам, и после 1–2 проектов работал как опытный менеджер.
Вау.
Это был «Роскошный максимум». Тогда не было этого выражения, но максимум уже был:)
Что говорить: я сам научился правильной документации именно на этой методологии. Я сам понял, какая должна быть правильная последовательность артефактов, какие правила согласования требований и как тесткейсы связываются с требованиями, зачем нужен каждый документ в цикле разработки большой ИТ системы, и даже зачем нужен в документе раздел «о документе», что там писать, и для кого.
С тех пор я был на многих тренингах по проектному управлению, изучил методологии от PMBoK до модной нынче P3.Express, работал в топовых российских компаниях, но ничего более простого, понятного и ясного не встречал.
Почему?
Проверка реальностью
Можно подумать, что ребята, с которыми я тогда работал, изобрели велосипед. Но нет: если посмотреть на методологии внедрения SAP (SAP Activate или старый ASAP), мы увидим похожий подход.
Логика везде одна: фазы, идущие строго одна за другой (в SAP Activate это разбито на итерации и названо Agile, но суть та же), шаблоны документов и жесткая структура. То есть все выглядит плюс-минус одинаково. Это подтверждает, что подход верный.
ГОСТ-34, описывающий этапы создания информационных систем и документов, тоже подозрительно похож. С поправкой на необходимость продираться сквозь сложные формулировки, но там есть полный стек документации проекта. И даже масштабируемость подразумевается, просто не такая очевидная, как в моем идеале выше.
Почему у вас этого нет (и, скорее всего, не будет)
Да потому что не нужно.
У «Роскошного максимума» есть два фатальных недостатка:
Высокая стоимость создания. Чтобы нарисовать, описать и наполнить шаблонами такую систему, нужны сотни, а то и тысячи часов дорогих методологов. Это миллионы рублей инвестиций просто в бумагу.
Еще более высокая стоимость эксплуатации. Cистему надо поддерживать. Нужен отдельный методологический офис, который будет актуализировать шаблоны, обучать новичков, строить аналитику и следить за нарушениями. Хотите красиво и правильно - платите.
У небольшой компании таких денег нет, такая методология может окупиться только для крупняка, где на масштабе будет хорошая экономия как минимум на:
Контроле за проектами — за счет единых правил;
Административке — за счет сокращения кучи персонала, приводящего все в единый формат (а таких историй на ИТ рынке много, даже на Хабре палились ребята)
Обучении — методология учит сама по себе, не надо курсов. Ну ок, можно ролик записать к квест карте, для непонятливых.
Использовании более дешевых РП (если у меня такая квест карта, мне нужно меньше синьоров, а местами сгодятся даже джуны).
НО
Если вы - цифровая студия или средний бизнес, попытка внедрить такой «идеал» вас убьет. Вы просто потратите весь бюджет на написание регламентов и шаблонов, а код писать станет некому.
А что на счет ГОСТ34?
34ка - это хорошая попытка допрыгнуть до той же планки: документация полная, разделы описаны, масштабируемость заложена (хоть и неявно).
Но есть нюанс: продраться сквозь описание ГОСТ непросто начинающему, а уж ждать квест карту и простого понятного механизма масштабирования точно не стоит – ГОСТ придуман для всей отрасли и, как положено общему документу, он не может быть применен «как есть», его надо адаптировать, желательно с умом. Ну и дополнительно: ГОСТ не описывает правила инициации проектов, точки взаимодействия с бизнесом и управление изменениями, а это важнейшие болевые точки проектов.
А что на счет PMBoK, P3 и всех остальных методологий?
С ними другая история. Их разработали умные ребята, которые постарались сделать описание максимально широким, таким, чтобы оно подошло под основные правила ведения вообще любых проектов. В итоге такие методологии похожи на анекдот "средняя температура по больнице - нормальная": вроде все сказано хорошо и по делу, но как это использовать мне здесь и сейчас - "да фиг его знает" или "да используй, че хошь" (а чего я хочу?). Короче, прикладная польза есть, но только как справочник, и только для тех, кто понимает, как и во что это должно превратиться на земле.
Так что если вы изучили очередную методологию, но ничего не поняли - вы не тупой, с вами все ок, я тоже через это проходил, просто они... несколько оторваны от реальности, иначе этого не описать.
Что делать бедным?
Итак, денег на «Роскошный максимум» нет, ГОСТ адаптировать сложно, хаос надоел, СЕО ругается. Что делать?
Все равно помнить про идеал. Его не надо делать, но дергать хорошие мысли оттуда надо. Я на каждом новом месте применял элементы той самой "подсмотренной" когда-то методологии и не могу ее забыть до сих пор, просто потому, что лучше и подробнее - не было.
Искать свой собственный баланс между полным хаосом и Роскошным максимумом.
В госухе используют ГОСТ. Он сложный и тяжелый, но если привыкнуть - норм, годится.
Для smb (small-to-medium business) компаний вопрос помимо артефактов внедрения должен касаться еще процесса разработки (если она есть) и точек коммуникации с бизнесом - основные сложности и разочарования я вижу там.
Об этом я могу написать отдельно, если эта тема будет интересна, так что поддержите лайком и каментом, если было интересно :-)
Где обещанная квест карта, и зачем я все это написал?
Эту главу я написал по итогом каментов к статье.
Идея статьи не в том, чтобы дать какой то один простой и "идеальный" способ решения всех проблем на ИТ проектах. Его нет.
Еще раз скажу: методология внедрения сильно зависит от типа проектов (порелизные, водопадные, развитие продуктов), типа деятельности (разработка ПО, строительство, наладка ПАК), масштаба компании (МСП - небольшие внедрения, Крупняк - и малые и большие), от области деятельности (разные обязательные пакеты документации).
Потому идеальной квест-карты не будет. Даже не потому, что она по NDA, а потому что конкретно именно вам - вам, она не поможет.
Но есть моменты, которые принципиально важно понимать по итогам статьи и часть которых я вообще не видел и не слышал ни в одной статье (тыкните меня, если пропустил, скажу спасибо).
Идеальная проектная методология - это серьезная инвестиция в операционную эффективность компании. Окупается она годами. Считаю, что это и есть основная причина, почему в России этого нет и не скоро увидим. Горизонт планирования у нас - три года от силы. Такая жизнь.
Идеальная методология уникальная для компании, но общие черты это
полностью описанный пошаговый процесс от зарождения идеи до передачи в поддержку, включая ответственных (RACI) и артефакты
все шаблоны артефактов - заполненные универсальные и подготовленные. Да, с поддержкой масштабирования по проектам, где какие то части документа могут быть не нужны (пример - архитектура компонентов - для простых решений)
и да речь не только и не столько о проектном плане (его почему то бегут шаблонизировать первым делом), речь о бизнес-кейсах, фин обосновании, ФТ, ТЗ, ЧТЗ, detailed design и прочих документах.
очередность подготовки документов - что готовится и в какой момент, когда и для чего должно быть готово (к примеру detailed design не ранее согласования functional requirements, оно же: ПЗ к ТП только после согласования ТЗ в терминологии ГОСТ34)
наглядность и простота обучения. Я видел пример в 2005 году. с тех пор прошло 20 (!) лет и дизайн ушел далеко вперед. Если вы сейчас придете к вашему штатному дизайнеру (а если вы хотите внедрить "идеал", он у вас есть, так?) и скажете: "вот процесс и артефакты, отрисуй квест-карту", он отрисует не хуже. Смысл не в конкретном дизайне.
Методология должна быть понятна даже джуну. Сложные системы сделать понятными может дизайн.Масштабируемость под разный размер (ведь вообще ни одна методология в РФ этого не делает!)
Идеальная методология должна приниматься, как ориентир (ака OKR) при создании вообще любой методологии. Потому что когда РПО создает методологию, он балансирует между необходимостью и достаточностью, между тактическими и стратегическими и тем, сколько денег у него есть. Делать надо что-то свое, не забывая, что есть идеал. Да, у нас нет "Мерседеса", у нас есть "Жигуль", но он едет и задачу выполняет. Когда появятся деньги - можно будет купить и "Мерседес".
