Накопление знаний
Технократическо-управленческое

Команда-тень (с) "ScrumTrek"

Когда-то давно Асхат Уразбаев рассказал мне историю про ShadowTeam (команду-тень), поэтому в заголовке копирайты команды ScrumTrek.
В зону ответственности данной команды входили задачи которые для конечных бизнес-приложений не очень однознаначны, в общем случае зону ответственности можно назвать как "спасти, если вдруг ЧЁ".

Разноцветные фломастеры или на вкус и цвет все фломастеры разные


Начать наверное стоит с проблемы - давайте предполоим что наша супер-пупер команда разработчиков и аналитиков под руководством уважаемых владельцов продуктов и под контролем менеджмента запустила таки рабочую систему.
Кто давно в ИТ - он уже, как минимум, догадывается что систем будет несколько. Учитывая, что меня почитывают в основном 1С-ники - будет говорить скажем про 4 (четыре) типовых

  • ERP
  • Бухгатлерия
  • Зарплата и управление персоналом
  • Документооборот

И вот системы работают... Что происходит дальше ? А дальше необходимо системами владеть...

И если - микродоработки и "приземление процессов" может выполнить начинающий и средний разработчик/аналитик (говорят что до 70% нагрузки приходится именно на анализ организационных расстановок в отделах и управлениях компании), то владеть системой/системами может только ведущий специалист. А что он должен вести ?

Перед проблематикой также стоит ввести несколько метрик и определить зоны ответственности - напомню что в производственном процессе у нас есть

  • анализ требований и бизнес-процессов
  • разработка алгоритмов автоматизации
  • равзертывание и переход к опытно-промышленной эксплуатации

применительно к старту информационных систем именно эти три блока будут находится на вашем "конвейере пользы".

А теперь добавим 3 новых вводных:

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

В перспективе также возникнут проблемы BI и DataMining алгоритмов - проблема самая банальная: кто их будет писать ? Но про это мы поговорим в слудующий раз - сейчас же вернемся к "интеграции" и "контролю производительности".

Черновички схем


Моя дочь советует мне завести Инстаграм или TikTok - это еще одно противоречие которое придется разрешить (как адаптировать архитекторско-системный контент под формат данных площадок); а пока те кто подписан на Телеграм канал видели уже предварительные схемки зон ответственности. Начнем с релиз-инженерии.


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

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

  • WC (working cycle) - медианное время на жизненный цикл блока работ от момента получения запроса на изменение до начала использования пользователями функционала.
  • CPD (commits per day) - количество изменений кода в день на одного разработчика
  • PGB (percent green build) - процент "зеленых сборок", то есть отношение успешных процедур автоматизированного контроля к неуспешным
  • ERR (errors rate) - уровень "красных надписей" в рабочем контуре
  • PCT (performance counters) - показатели производительности работающего контура

Соответственно формулировка для бизнес-Мэнов звучит примерно так

Нам нужен человек который будет администрировать инструменты автоматизации рабочего процесса команд разработки, обеспечивая постоянную скорость автоматизации (WC+CPD) с должным уровнем качества, сокращая наши затраты при возврате на доработку блоков автоматизации (PGB+ERR), вместе с этим контролирую рост нагрузки с проактивным анализом необходимости оптимизации существующих алгоримтов (PCT+DOC)

Внимательный читатель обратит внимание на схему и увидит восклицательный знак в зоне DOC - а это единственный артефакт который может выдать релиз-инженер команде разработки в качестве результата своей деятельности: аналитическую записку с предложениями по оптимизации алгоритмов. Если такого у Вас нет - то формально у вас нет релиз-инженера. Остальные абревиатуры на схемы имеют значение - но уже для техарей и это мы расшифруем в книжке (хотя мои читатели и так видят, что там Jenkins и PostgreSQL). Хотя погодите - абревиатура AS хитрая - это и автономный сервер 1С и Apache Server - можно интерпретировать по разному ;-).
Главное что на данной схеме наконец-то сделана замкнутость зоны ответственности, чтобы Ваш релиз-инженер НЕ лез в зону DevOps - которая вообще не про CICD (странные люди на странных площадках почему-то в своих вебинарах подменяют эти понятия - пусть идут по своим граблям, но моим читателям не советую).

Сотрясатель хаоса (Е-ЭС-БЭ-хер)


Если мы организовали процесс контроля качества разработки и контроля работы продуктивного контура - проблема с владением системами будет решена только на 50%. Здесь на сцену выходит история с интеграцией.
Как назвать этого члена команды ? Опять вернемся к проблематике - интегрировать системы придется... И самое главное - придется писать интеграционный код.

Здесь замкнутость процесса крутится вокруг того, что:

  • интегрировать системы придется
  • требования к скорости разработки и к скорости передачи данных будут увеличваться (с каждым днем объем передаваемых данных будет расти, а алгоритмы усложняться)
  • рано или поздно бизнес-пользователя захотят получать данные с устройств и смотреть это на экранах систем класса BI

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

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

Для завершения и так затянувшегося поста, попробуем расшифровать то что написано на схеме:
  • USERS - пользователи обычно подают требования на интеграцию в формате "Выгрузите в Excel", а реальный запрос "42", единственным способом защиты от такого бреда являеся развертывание систем класса BI+EnterpriseDashboard. Советую посмотреть в сторону ReDash сегодня (а точнее уже DataBricks теперь)
  • PMO (portfolio management office system) - Принимают запросы на интеграцию команды занятые реальной автоматизацией в зоне ERP и других бизнес-систем.. Соответственно разработчик интеграционных потоков должен быть членом всех команд, чтобы помогать командам реальной автоматизации. Поэтому то он также член команды-тень - ну а PMO - это что-то типа JIRA/VSTS/Redmine/Gitlab/etc.
  • ESB - это любая "на выбор" платформа интеграции - зависит только от компетенции вашего разработчика интеграционных потоков. Для начинающих наверное стоит посоветовать Datareon - там порог вхождения ниже всего.
  • ADP - а это самый главный артефакт который отдает разработчик интеграционных потоков командам - "универсальные адаптеры", чтобы как можно меньше необходимо было кодить на целевых системах.

В остальном же данная схема требует погружения в "интеграцию", как зону компетении - для начинающих стоит погуглить что такое ODBC, HTTPs, FILE:\\\, POP3/IMAP, AMQP, NATS, KAFKA, MQTT, STOMP - это вообще целый мир и именно поэтому нужна платформы интеграции и ЦЕЛЫЙ разработчик.

Риски...


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

  • что делать, если количество багов в продуктиве с каждым днем растет ?
  • что делать когда Вас попросят получить теллеметрию с буровых станций на Ямале внутри Московской ERP системы в режиме "онлайн" ?

Если Ваш ответ - разберемся как-нибудь, то я вообще не понимаю как Вы вообще дочитали до конца этот пост и мне с вами не по пути.

P.S. Наверное следующим постом будет история про цифровое бурение.
P.S.S Будьте осторожны с гуглением "термина Shadow IT" - дело в том, что на данный момент это понятие может трактоваться как "команда-драйвер инноваций в компании", так и "команда ИТ безопасности". Картинка для заглавия взята отсюда - https://www.myhubintranet.com/shadow-it/, но если тот же термин загуглить, можно обнаружить совершенно разные темы под названием. А картинка мультяшно-красивая поэтому пусть живет и превлекает старшеклассников в наш ИТ мир.