Формула успешного внедрения DevOps и Agile в 1С: от неудачи к неудаче без потери энтузиазма

Если у вас нет DevOps, то у вас нет и Agile. А если у вас нет Agile, то вам и DevOps не нужен. Именно поэтому этот доклад звучит в секции «Управление проектами».

Начну с того, что я не согласен с тем, что технологии DevOps непроверенные и ненадежные. И в ходе доклада я буду делать акцент не только на том, какие инструменты и фишки у нас работают. Я буду больше акцентировать внимание, зачем мы что-то делаем, как до этого дошли, и почему это эффективно.

 

4 зоны БИТ:ERP

 

 

Не буду нарушать традицию и расскажу о том, кто мы такие.

Мы являемся подразделением компании «Первый БИТ». На слайде представлена матрица направлений нашей команды.

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

В каждом разделе моего доклада будут QR-коды, которые будут вести на соответствующую литературу.

Там, где это возможно, я буду давать ссылку на русскоязычный формат, а там, где это невозможно – на Amazon.

Соответственно, первая книга – это «Зона победы» Джеффри Мур. Думаю, что многие его знают по другим произведениям.

Именно Джеффри Мур сформулировал, что с точки зрения управления бизнесом можно выделить 4 зоны. Каждое из направлений бизнеса находятся в одной или другой зоне. У каждой из этих зон свои правила, разные потребности и стратегии.

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

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

 

 

Итого, первая зона нашего подразделения, зона основного бизнеса – это ERP-проекты.

Мы занимаемся внедрением крупных проектов в крупных торгово-производственных холдингах на платформе 1С:ERP 2. Делаем это уже давно, начинали еще с 1С:УПП.

Список проектов нашей команды достаточно обширен, особенно для небольшой команды, которой является наша.

На слайде представлены самые крупные наши проекты. Три из них – это проекты года.

 

 

Вторая зона – зона трансформации. В эту зону мы относим разработку нашего продукта, распространяемого по подписке, нашего мобильного приложения на платформе 1С для работы с маркированным (и не только) товаром.

 

Зона перспективных возможностей – это инкубатор, зона инвестиций, которая пока денег не приносит.

Для нас это – наш продукт БИТ:Промышленный интернет вещей. Суть в том, что у нас сейчас внутри подразделения, основная специализация которого – 1С:ERP, выделилось отдельное направление, где мы сотрудничаем с разработчиками на других платформах. В том числе для программируемых логических контроллеров мы тоже делаем вещи, связанные с ERP-системой, связываем с промышленным оборудованием, с конвейером, отбраковщиками, сканерами и т.д.

 

 

Ну и зона продуктивности – это DevOps, то, что необходимо для всех остальных зон компании. Все, что связывает все эти зоны.

 

Главное – сконцентрироваться на ценности конечного клиента

 

 

В докладе 2018-го года я пытался ответить на вопрос: «Какой подход применить на проекте?». Сейчас я считаю неправильным то, что я тогда говорил – сейчас бы я себя так не вел. Причем, неправильным я считаю не ответ, который давался в ходе выступления, а постановку самого вопроса.

Почему постановка вопроса неправильная, подробно изложено в книге Мика Керстена Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. К сожалению, на русском эта книга пока не вышла, но она есть на английском – в режиме чтения и аудио. Очень рекомендую почитать.

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

Меня многие обвиняют в том, что я слишком много говорю на английском. Поэтому покажу наши российские ГОСТы.

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

Когда мы говорим про каскад, Agile, гибридные методики, DevOps, 1C, автоматизировать, не автоматизировать, технико-экономическое обоснование, риски, заказчика, команду, время и т.д., для нас самое основное – это то, на чем мы концентрируемся.

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

 

Lean. Поток создания ценности

 

 

По этому поводу рекомендую еще три книги.

 

Первая книга вышла давно, причем на русском языке. Это Джеффри Лайкер «Дао Toyota». С нее можно начинать.

Вторая книга еще лучше. Авторы James P. Womack, Daniel T. Jones, название Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании.

И возглавляет топ книга «Машина, которая изменила мир» – от тех же авторов, что и вторая.

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

 

Вернемся к понятию lean. Когда мы говорим про философию бережливого производства, мы говорим про поток создания ценности.

Давайте вспомним теорию, в чем заключается вывод продукта на рынок:

• первое, что ты должен сделать – это определить ценность,

• затем ты должен сформировать поток создания ценности,

• а дальше ты должен обеспечить вытягивание.

Соответственно Kanban – это метод вытягивания. Поэтому вопрос «Kanban – это Agile или не Agile?» опять достаточно странный, так как Kanban – lean-методика, которая может применяться в Agile, а может и не применяться.

Т.е. Kanban появился именно как инструмент обеспечивания вытягивания – мы концентрируемся на ценности, а потом все подчиняем ценности. Убираем все лишнее, что не приносит ценности, устраняем потери, и делаем так, чтобы доставка ценности была максимально быстрой, потому что время – это одна из потерь.

 

Средний Time to Market для 1С:ERP – три года

 

Если мы возьмем любую ИТ-компанию, не важно, что мы делаем: внедряем ERP, создаем продукт или другое – поток создания ценности, по большому счету, всегда одинаковый:

• существует какая-то идея, есть формулировка о том, что нужно сделать в рамках автоматизации (притом все больше задач касается именно автоматизации);

• далее разработка;

• потом эксплуатация;

• а затем клиент.

Время, затрачиваемое процессом от идеи до появления конечного продукта у клиента, называется Time to Market – «время до выхода на рынок».

К сожалению, до сих пор практика даже успешных ERP-проектов в России такова, что Time to Market – это три года. С точки зрения lean – это одна из тех проблем, которую нужно решать. Не потому, что рынок и требования меняются, а потому, что если мы доставляем ценность только через три года, то в течение всех трех лет мы несли затраты и росла «незавершенка».

Меня поразили цифры предыдущего доклада, где говорилось о том, что при подготовке ТЗ было зафиксировано порядка тысячи функциональных разрывов. Их же посчитали, описали, систематизировали – это сколько же времени и денег потратили на это? Поэтому, когда делаются большие описания, обследования, фундаментальные труды, все это ценности для клиента не несет – ERP система не работает. Вместо этого, чтобы все описать, систематизировать и начать разрабатывать, было потрачено много времени умных и высокооплачиваемых людей.

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

Если нам удалось запустить систему, мы докладываем об этом на конференции и подаемся на «Проект года». Если не удалось, то все, как обычно: меняем ИТ-директора или подрядчика и начинаем процесс заново.

 

Накапливать «незавершенку» – неправильно. Проект vs продукт

Чтобы понять, как действовать правильно, следующая книга в помощь – Элияху Голдратт, Джефф Кокс «Цель. Процесс непрерывного совершенствования».

Если вы представили процесс в формате Time to Market, то берете эту книгу и начинаете анализировать, что в этом потоке не так.

После того как вы все проанализируете, важно задать себе вопрос: «Зачем это внедрение или продукт нужны?»

При этом важно понимать разницу между проектом и продуктом – книга Мика Керстена про Flow Framework (про которую я говорил в самом начале) как раз об этом.

Проектное управление – про сроки, бюджет и объем. Если ты вложился в указанные сроки, бюджет и объем – у тебя успешный проект. Ты как Project Manager – молодец: сделал то, что планировали, за те деньги, которые планировали, и уложился в планируемые сроки.

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

Но проблема в том, что вне зависимости от сроков проекта (допустим, он длится три года или три месяца) ты не можешь заранее сформулировать требования, которые гарантированно приведут тебя к успеху. Если бы ты мог это сделать, это мог бы сделать весь рынок. А если бы это мог сделать весь рынок, то, конечно, у кого-то получалось бы лучше.

Соответственно, неправильно за три месяца или за три года вперед требовать от бизнеса, чтобы они сказали, что нужно сделать, чтобы все работало.

Поэтому нужно позиционироваться на продукте и на его ценности. Когда мы позиционируемся на ценности, мы не строим диаграмму Ганта, а задаем себе вопросы:

• «Что нам нужно сделать и зачем?»

• «Что нужно сделать, чтобы протестировать эту гипотезу минимальными усилиями и минимальными деньгами?»

И если для решения данного вопроса нам понадобится диаграмма Ганта на три года, то ок, мы нарисуем диаграмму Ганта на три года. Правда в большинстве случаев это почему-то не нужно.

В общем: мы задаем не тот вопрос и не на тот вопрос ищем ответ.

Есть клиент, есть ценность для клиента. Возникла идея.

• Первый вопрос, который мы должны себе задать: «Зачем клиенту эта ценность?»

• А второй: «Как мы можем проверить, что это действительно будет работать, перед тем как делать?»

 

 

Есть еще путаница в терминологии, связанная с тем, что английские слова outcome, output и benefit в ряде источников переводятся как «результат».

Но на самом деле:

• output – это результат;

• outcome – это последствия;

• benefit – это выгода.

Разница между продуктом и проектом объясняется, в том числе, разницей между владельцем продукта и руководителем проекта.

Руководителя проекта глупо спрашивать про бизнес-ценность – зачем он сделал то, что сделал. Ему сказали – и он сделал. В соответствии с критериями, с техническим заданием, с постановкой задачи и т.д.

Поэтому мы говорим о том, что подрядчик должен мыслить в терминах владельца продукта, а не в терминах руководителя проекта. И это – ключевая разница, которую нужно понять.

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

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

 

 

Не мог пройти мимо этого слайда. Он достаточно популярен в интернете. Это сравнение Space-X и «Роскосмоса».

В Space-X, как вы догадываетесь, используется продуктовый подход – его делали люди, которые ранее создавали различные digital-продукты. Они начали применять продуктовые же технологии в отрасли, где традиционно продуктовый подход не применялся. Это древняя отрасль, там свои традиции, свои правила.

На слайде показано, что из этого получилось. Я думаю, что проблема «Роскосмоса» даже не в бюрократии или в коррупции. Ключевое отличие – это просто разница в подходах. Все остальное – это просто какие-то усложняющие факторы.

 

 

Заканчивая теоретическую часть, хочу рассказать про большие циклы конъюнктуры, т.н. «длинные волны Кондратьева».

Обращаю внимание, что «Управление проектами» как инструмент появился на третьей «волне», где-то 200 лет назад.

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

По поводу циклического развития в рамках научно-технических революций рекомендую почитать книгу: Н.Д. Кондратьев «Большие циклы конъюнктуры и теория предвидения». К сожалению, я не нашел эту книгу сейчас в продаже, но это скорее просто теория про тренды. Если предыдущие книги можно читать, выписывать и сразу применять полученные знания, то эту – просто использовать в качестве пищи для размышлений.

 

Чем связаны Agile и DevOps. И почему Scrum не подходит

 

Если рассмотреть поток создания ценности, становится понятно, чем связаны Agile и DevOps.

• Сначала у нас возникла идея. Если рассматривать ее как ценность – с позиции предпринимателя, собственника бизнеса – нам нужно как можно быстрее донести ее до клиента.

• Чтобы она была донесена, нам нужно, чтобы она была сделана.

• Чтобы она была сделана, нам нужно связать бизнес и разработку.

• А для того, чтобы связать бизнес и разработку, как мы знаем, нужен Agile.

Многие разочаровались в методике Scrum.

• Некоторые – потому что у них его не получается запустить.

• Другие – потому что, что он слишком медленный. Потому что две недели – это слишком долго, все слишком быстро меняется, и нет смысла в таком планировании.

• Другие говорят, что две недели – это слишком мало, т.е. Scrum делает разработку медленной. Звучит вроде так же, но смысл совсем другой.

Если взять в качестве ориентира «Полярную звезду» Toyota, то в идеале у нас должна быть всего одна задача в работе. То есть в незавершенке не должны быть задачи на спринт – там должна быть только одна задача.

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

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

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

А продом заведует отдельное подразделение, основной принцип которого: «Если это работает, это трогать не надо».

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

Отсюда: «А давайте мы 1-го января это сделаем?» Чтобы было больно, но один раз. Как с вырыванием зуба, чтобы кровищи было много, но хотя бы раз в году.

«А давайте приурочим к каким-то календарным датам, к началу квартала?»

Дальше бизнес привыкает к этому и говорит: «Давайте мы сначала выполним план продаж? А потом в начале месяца, когда времени еще много, тогда и вашу систему запустим. Все равно ничего работать не будет, отгрузки встанут. Зато у нас все будет хорошо – KPI выполнен, премии получены, потом нагоним».

Все это противоречит потоку создания ценности. Бизнес сам говорит, что ему не нужен релиз – у него отгрузка, конец месяца, KPI, планы, бонусы, и нужно закрывать квартал.

То есть без DevOps ты ничего сделать не можешь.

Более того, это цикл порочной обратной связи. Ведь чем больше у тебя разница между началом разработки и запуском, тем больше накапливается изменений. Чем больше изменений, тем больше шансов, что что-то пойдет не так, так как там не может не быть багов, ведь протестировать такой объем нереально. И бизнес будет привыкать, что обновляться можно только с 1 по 10 января, когда никто не работает.

Кроме этого, есть проблема в том, как искать ошибки. Допустим, если у тебя изменилось пять строчек кода, то ты знаешь, что вызвало проблему. Но если релиз включает в себя множество объектов и модулей с десятками тысяч строк кода – найти, что вызвало проблему, реально сложно и даже почти невозможно.

Это совмещение неприятного и бесполезного: мы делаем себе хуже и больнее, чем могли бы.

Поэтому, если вы не можете накатывать релизы часто, Agile действительно становится ограниченно-полезным. Бизнесу легче заставить себя раз в три года помучиться, чем страдать каждый раз после выпуска нового релиза. А без DevOps обеспечить корректность вносимых изменений – нереально.

 

Инструменты для взаимодействия с бизнесом. Канбан-доска и карты пользовательских историй

 

Сейчас я покажу несколько маленьких видео об инструментах, которые мы используем для решения конкретных проблем в процессе создания ценности

Говоря об инструментах, первое, что нужно сделать – это посмотреть на поток и найти «узкое место», которое ограничивает производительность системы. Нужно подготовить технико-экономическое обоснование и объяснить себе, руководителю, заказчику или кому-то другому причину, почему в этом «узком месте» нужно снять ограничения – какие полезные эффекты это даст.

Что можно сделать, если узкое место – это бизнес?

 

 

У нас используется Kanban-доска от Jira – здесь вы видите доску нашего тиражного продукта для мобильных устройств. Показана регистрация задачи с точки зрения консультанта.

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

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

 

 

 

Здесь показан предмет для моего самобичевания – в докладе 2018-го года я показывал вот такие схемы бизнес-процессов, где описана взаимосвязь всех элементов, всех блоков, всех систем и т.д.

Да, я так говорил, но забудьте, удалите это из памяти.

Такие исчерпывающие EPC-диаграммы писать не надо, потому что в них нет ответа на вопрос «Зачем?»

Такую диаграмму никто не будет читать. Наибольшую пользу такая диаграмма приносит только ее составителю – тот, кто ее сделал, реально начал разбираться в том, что он сделал. Всем остальным эта диаграмма обычно абсолютно бесполезна, они ее даже не читают.

Кроме этого, диаграммы, которая бы описывала все возможные ситуации, я тоже не видел. Начинаются усложнения, а реально бесконечную всеобъемлющую вещь сделать сложно… и не надо, т.к. как она еще изменится.

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

Зато карта пользовательских историй полезна команде. Любой член команды или владелец продукта может по карте провести и рассказать, как продукт работает в реальной жизни пользователя.

Для построения карт пользовательских историй мы применяем конкретный инструмент – Feature Map. Но Miro для этого тоже подойдет

 

Инструменты для разработки. Автотесты, создание базы и ChatOps

 

Дальше – разработка.

Разработка – это наша «любимая» проблема, мы ее любим решать. Поэтому и инструментов здесь реально гораздо больше:

• мы активно используем автотесты – больше всего в зоне трансформации;

• CI-контур в части создания баз у нас используется в зоне продуктивности – для автоматизации деятельности разработчика;

• а в части ChatOps – для всех зон, потому что инструменты CI-контура у нас интегрированы в Slack (корпоративный чат, который используется для общения в подразделении, в том числе, с членами команды со стороны заказчика).

 

 

Здесь показан процесс разработки сценариев тестирования. По запросу создается эталонная база. Для сценария используется особая структура и особые правила написания.

 

 

Вот так выглядит передача задачи разработчику в Jira.

 

 

Вот так – подготовка базы разработки.

 

 

Вот так – сам процесс разработки.

 

 

Процесс создания Merge Request.

 

 

Проверка ветки автотестами для Merge Request.

 

 

Здесь показан список автотестов для одного из наших проектов и правила, которых мы придерживаемся при их написании.

 

 

Здесь показано, как мы ежедневно синхронизируем работу команды, заполняем отчет в Slack.

 

Инструменты для передачи в эксплуатацию. Сборка релиза

 

Важный этап – приемка и эксплуатация.

 

 

Передача задачи на внедрение – это обязанность разработчика, и мы требуем от разработчика, чтобы он оценивал сроки ее передачи в эксплуатацию.

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

У нас спринты короткие – одна неделя, поэтому ставится вопрос: «Почему эта задача висит здесь вторую неделю? Что нужно сделать, чтобы не висела?»

 

 

Вот так производится сборка релиза.

 

Инструменты для быстрых исправлений у клиента. Canary-релизы

 

 

Хочу рассказать о нашей гордости. Мы первые, кто реализовал для 1С возможность выпускать Canary-релизы.

 

 

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

Допустим, у нас есть 100 клиентов на ТСД, но мы можем обновлять приложение только у избранных ТСД. Т.е. при выпуске нового релиза мобильного приложения мы не парализуем все предприятие во всех географических зонах, а даем команду серверу: «Обнови, пожалуйста, приложение у двух ТСД на этом складе». И на эти два ТСД выкатывается новая функциональность, а мы тестируем и анализируем, что на них происходит.

Это очень хорошая идея, которая позволила нам делать релизы по несколько раз в течение дня.

Обычно мы на своих проектах выкатывали релизы один-два раза в неделю, а сейчас начали выкатывать несколько раз в день. Это реально крутая тема – рекомендую. Но как такие релизы делать на проекте уровня ERP – сразу предупреждаю: не знаю:)

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.