Кстати-20 Гегель и чек-лист321
Проблема-возможность.
Коллеги, сегодня День философии. Я хочу с вами обсудить одну специфическую проблему, стоящую на пути подхода 321.
Прочитав наше введение в BizOpsDev321, пообщавшись или посмотрев пару наших видео, заказчик, бизнес говорит: “Да это у нас уже было” или “У нас так всё и есть”. И не в состоянии уловить отличия, которые существуют в подходе 321 от того, что у вас есть.
И вот здесь, как раз чисто по-гегелевски, единство и борьба противоположностей! Эта проблема превращается в возможность, если мы сможем выделить с вами эту разницу. И окажется, что всего лишь небольшими настройками - как вы настраиваете музыкальный инструмент, будь то гитара или рояль - вы сможете получить не какофонию, а звучание!
То есть, это одновременно и проблема, и одновременно большое преимущество нашего подхода: небольшими изменениями главных рычагов вы можете получить очень сильные результаты. Эволюционными мелкими шагами в состоянии достигнуть революционных результатов.
Итак, сегодня хочу поговорить об этом чек-листе, который позволит нам посмотреть, чем то, что у вас есть или было, отличается от подхода 321.
У нас с вами всего 8 пунктов и один важный вывод.
Пункт 1. Никаких формализованных ТЗ
Нет между бизнесом и ИТ никаких формализованных частных технических заданий - ТЗ, FSD, BRD. Нет никакого согласования всех заинтересованных лиц в бумаге, в документах прежде, чем данная работа выполняется.
Идеи бизнеса, который участвует в работе ИТ своими ключевыми специалистами, сходу реализуются. И эти ключевые специалисты сразу видят: “В ту сторону пошли - не в ту сторону, не то!” - бросили!
Пункт 2. Никакого хождения документов
Точно так же нет формального хождения документов между заказчиком и подрядчиком. То есть, подрядчик работает просто как “Команда-как-Сервис”. Вы у него заказываете определённый объём услуг сопровождения.
Даже нет отдельной разработки - доработка делается в рамках услуг сопровождения. И тоже нет никакой формализации.
Если это у вас есть - идём дальше.
Пункт 3. Кольцо автотестов
Все контрольные примеры, базовые сценарии работы ключевых специалистов должны быть превращены в автотесты. Это must have!
Если это у вас есть, вы это обнаружите - сразу же транслируется в очень удобную документацию, которая к этому связана. Ещё она автогенерируется, всегда обновляется. Ещё она связана с учебным стендом.
Пункт 4. Нет разделения между сопровождением и разработкой
Нет разделения между сопровождением и доработкой или разработкой. Это делают одни и те же люди. Большое ИТ мы сейчас не затрагиваем.
Вот именно переход между бизнесом и ИТ - здесь не должно быть, что у вас есть какая-то первая-вторая линия поддержки, что у вас есть какая-то продуктовая команда, которая выполняет роль только третьей линии поддержки.
Сопровожденцы и разработчики - внутри нет чёткого деления на роли. Нельзя сказать, что это чисто сопровожденец, а это чисто разработчик, а это чисто тестировщик, а это аналитик, а это PM и так далее. Вот эти все роли как-то размазываются, но чёткого деления нет.
Ясно, что есть только BizOpsDev: Operations и Development объединены в одну команду.
Пункт 5. Это не Agile (в смысле Scrum/SAFe/LeSS)
Идём дальше. Многие смотрят, читают, что мы пишем, и говорят: “Так это же Agile!” И да, и нет.
Потому что дальше люди говорят, как правило: “У нас всё это давно внедрено. Scrum, SAFe, LeSS, Prince2”. Нет, коллеги. Это не Agile.
Трагедия ИТ-отрасли заключается в том, что часть тех людей, которые написали Agile-манифест и его принципы, они же стояли у истоков Scrum’a. Вот Scrum они хотели написать так, чтобы middle management, средний менеджмент, отстал от разработчиков, которые хотели напрямую с ключевыми специалистами взаимодействовать. И вот они им дали Scrum.
Это обернулось оружием против них. И если хотите, Scrum, SAFe, LeSS - это anti-Agile.
Поэтому да, это (подход 321) - Agile, но это настоящий Agile! Там есть 10-й принцип, который не выполняется ни Scrum’ом, ни SAFe’ом, ни LeSS’ом.
Пункт 6. Не продуктовые команды
И тут же мы переходим к пункту номер 6 и продуктовым командам. Почему нет?
И даже если вы оперируете понятиями Stream-Aligned Teams, продуктовые команды - это очень слабая связь с бизнесом. Ни Product Owner, ни бизнес-партнёры - айтишники, вставленные на сторону бизнеса, которые демонстрируют, что они разобрались в бизнесе как никто и стоят на страже его интересов, и сейчас они зарулят айтишными командами. Нет!
То есть ни продуктовые команды, ни центры компетенции не являются подходом BizOpsDev.
Если сравнивать образно: BizOpsDev - это тело целиком с головой, а Stream-Aligned Teams или продуктовые команды - они просто тело без головы. Бизнес отделён - отрубленная голова!
Пункт 7. Никаких метрик и оценок
Нет метрик, нет one-to-one митингов 1-на-1, нет KPI, нет ежегодной индивидуальной оценки сотрудников.
Пункт 8. Неприметный советник в топ-менеджменте
Неожиданно вы обнаруживаете, что у вас есть очень неприметный советник в самом топ-менеджменте вашей компании, который постоянно на связи, отвечает на все вопросы, связанные с организацией бизнеса и взаимодействия с ИТ.
Вот такой лёгкий, постоянный, бизнесовый, систематический консалтинг. Вот такой человек должен быть обязательно на самом верхнем уровне менеджмента. И это такой человек, с которым вы пообщаетесь, послушайте - вам будет казаться, что этот человек родился прежде, чем Деминг сформулировал своё правило 95/5.
Который жонглирует, то есть живёт этими понятиями.
Вот, к сожалению, для русскоговорящего сегмента я знаю только одного человека - зовут его Евгений Гаврилов. Вот если Евгения Гаврилова нет :) , то у вас не совсем то, о чём мы с вами говорим (шуткаюмора в которой слишком большая доля правды и вот ссылка на его профиль ).
Вывод
И дальше следует сказать, какой вывод: если у вас все эти пункты положительно отмечены, это означает, что у вас есть подрядчик или потенциальный подрядчик, который выполнит роль катализатора.
Который улучшит работу внутреннего ИТ, улучшит работу уже существующего вашего вендора или команды на стороне подрядчика, которая вообще исходно участвовала с вами в разработке. Вот такая, вам кажется, железная вещь, что там уже нечего улучшать.
Но я вас уверяю: если вы найдёте подрядчика, который соответствует всем этим принципам, и построите с ним работу соответствующим образом, то это будет равнозначно тому, как вы в железо добавили примесей и получили сталь.
Это касается и пункта номер 8 про консультанта, и это касается организации непосредственно работы между внутренним ИТ и подрядческим.
Это то, что мы называем: мы переходим от эры заказной разработки к заказному сопровождению и доработкам.
Соответственно, привлечение, например, нас как подрядчика - это не для того чтобы показать, что можно работать эффективнее, даже чем оригинальные разработчики. Да, это можно показать, только мы не собираемся с ними бороться, и не нужно никого замещать.
Если вы обратите внимание: 3, 2, 1 - это как раз то, что у вас подрядчиков минимум должно быть два. Ну вернее, желательно два, можно и больше.
Кроме внутреннего ИТ, у вас ещё есть любимый железный подрядчик и примесь в нашем лице. И так вы получите сталь - совершенно другого качества соединение!
Пару баек под занавес про ФК “Открытие”
Команда созданная внутри и работавшая с “Хардсофт321” настолько сильно отличалась - и она ассоциировалась с Agile с 2010 по 2013 годы - что нас обзывали “нетрадиционной ориентацией”. То есть это была команда, группа с нетрадиционной ориентацией.
После смены очередного CIO, который сказал, что “мы будем делать Agile”, весь middle management IT очень загрустил. Почитали, что такое Agile, посмотрели, как мы работаем, и сказали: “Ой как плохо, нас сейчас всех уволят!” Почему? Потому что middle management как бы не нужен.
Вот. Но потом новые ребята пришли и прочитали им лекцию установочную, как это будет выглядеть, привлекли консультанта большого и толстого, и он им рассказал, что Agile, который ждёт “Открытие”, - это будет Scrum, это будет SAFe, будет LeSS. И после этого, прямо после недель грусти, все ходили радостные - средние менеджеры. Потому что стало ясно, что это не меньше работы для них, а больше.
И по большому счёту жизнь сопровожденцев и разработчиков стала ещё сложнее.
Вот. А до этого в банке “Открытие” процветал не “Команда-как-Сервис”, не 3-2-1, не то, что должно быть два подрядчика, а проектный подход.
Я упёрся на стороне бизнеса в своё время и сказал: “Нет-нет-нет-нет-нет, мы не хотим никакую закрытую систему, давайте или SugarCRM, или OTRS, Open Source, другая система”.
И вдруг приходит подрядчик альтернативный, который называет нереальные сроки и нереальные деньги по объёму работ для реализации тех требований, которые были выкачаны. А потом, естественно, проект не был выполнен.
Так вот, когда он не был выполнен, я спросил: “Ребята, ну как там, что у вас получилось?” Они сказали: “Да ерунда, знаешь, мы так всё чётко спланировали, но потом всё пошло по Agile’у”. Вот это было отношение к Agile’у. И его не полюбили, а полюбили только когда это стал SAFe, LeSS и Scrum.
Я поднялся на несколько этажей выше после 2014 года, оказал консультационные услуги брокеру “Открытие”. В брокере “Открытие” мне сказали так: “А нам сказали, что вы Agile собираетесь нам рассказывать. Так Agile у нас уже был, предыдущий CIO. Очень плохо всё испортил”.
Заключение
Поэтому используйте наш чек-лист321. И если чек-лист не совпадает - давайте общаться, давайте это делать неспешно, за очень небольшие деньги и постоянно. Давайте выйдем на понимание.
И соответственно, если мы хотим пережить уже начавшийся кризис - а конца ему не видно - то давайте будем не ждать, а готовиться!
Ключевой парадокс: Важнейшим барьером на пути использования подхода 321 или даже его пилотирования может стать его убийственная простота и/или сходство с тем, что уже есть или было. И парадокс в том, что именно это сходство показывает: маленькие эволюционные шаги от “того, что уже есть” дают большие результаты.
Это был первый проход для этой темы. Мы к ней не раз ещё вернёмся.
Дата публикации: 20.11.2025