[СМИ-2024] Безмаштабность и непрерывность

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

(без)Масштабность

Тут бы надо сделать отсылку к поискам целевой системы. Я всё ещё работаю в Центре цифровых HR технологий. И мы делаем часть внутренней платформы в других организациях (промышленных и не очень). Конкретно мой проект делает информационный продукт (софт) для обеспечения кадрово-расчётных работ.

Минимально нижний системный уровень, который затрагивает проект это человек-сотрудник. Это любой из сотрудников в системе создания (в нашей фирме), как участник проекта. Может я за уши притягиваю. Но в рамках 4Д, пока я работаю именно в этой фирме, меня непосредственно волнует наш рабочий проект. Любой сотрудник из тех фирм, где мы предоставляем сервис. Там от я, как сотрудник хочу видеть свой расчётный листок, иметь возможность быстро оформить отпуск. И дальше к другим ролям, где бухгалтер или начальник хочет легко оформить служебную командировку.

Дальше начинаются сообщества людей (команды, отделы, блоки). Я думаю так же и у нас, и у них. В системе создания команда делает фичи в поддомене кадров или расчётов (или ещё пары тех, которые сбоку). Внутри фирмы потребителя, работает отдел бухгалтерии или кадров.

Дальше идёт уровень организации. У нас наш проект это один из нескольких проектов нашей организации, но он основной. И тут я делаю шаг по цепочке создания, от команды проекта в сам ЦЦ HR. А у них, это тоже шаг от административной платформы, состоящей из отделов-служб (бухгалтерии и прочих) в саму организацию.

Дальше можно фантазировать на уровень стран(ы). Начальный ход это импортозамещение на уровне страны. Хотя как я вижу, импортозамещение не отменяет конкуренции с тем что уже есть (1С) и с тем, что возможно ещё появится/уже появляется. Мало у нас всякого цвета банков и прочих больших фирм, которые тут же кидаются делать вторые Miro, Jira и прочее. Но так же робко (или не очень) присутствует идея продавать продукт за границу тем, кто захочет. У нас итак сейчас Египет, РФ. Так что страны, может союзы стран с учётом нынешних реалий. Планета не получается, пока эти союзы настроены друг против друга.

Непрерывность

Какой-то даты старта проекта у меня нет. Но история изменений кода расчётного блока подсказывает, что всё началось 4 года назад. Через пару недель будет 2 года, как во всём этом участвую. Что меняется? Если говорить про софт, у нас “как бы” микросервисы. Со всеми вытекающими особенностями архитектуры. Меняются способы межсервисного взаимодействия. Меняются владельцы мастер-данных. Например, у был (и пока частично остался) механизм проекций. Т.е. например владеет данными по сотрудникам один сервис, данными по рабочему времени другой, нам в сервисах расчёта эти данные нужны. Сделали асинхронную отправку сообщений из сервисов-владельцев к нам, мы по этим сообщениями формируем и обновляем у себя “проекцию” данных (таблицу в БД). Но с этими проекциями были и есть проблемы. В начале года (или в прошлом году) было две идеи изменений: 1) переделать проекции на другой механизм 2) сделать витрины данных. Витрины застопорились, сложно понять почему (долго, сложно сделать). Переделали проекции на стороне владельцев, мы у себя поменяли обработку. Проблем стало меньше, но проблемы не исчезли. Витрины всё ещё нам никто не делает. Дальше новые идеи: 1) объединить БД (чтобы у всех был доступ к тем данным которые нужны) 2) дать доступ на чтение к нужным данным. Реализуется до сих пор и то, и это в разных частях системы. Идея витрин время от времени оживает. И там похожие штуки с объединением или разделением сервисов.

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

Изменения в оргструктуре, изменения в составе людей. От обычных сотрудников до лидов, методологов, продуктов и всех всех всех. Всякие ещё игры в agile меняют свою форму. До того, как я пришла, был скрам. Когда я пришла, он резко закончился, выбросили все дополнительные встречи (ретро, демо). PBRы какое-то время ещё пожили, но тоже исчезли. Сейчас (спустя два года) новый продакт собирается “восстанавливать процесс”. Появились снова PBR. День тишины убрали, как же дейли в пятницу сильно поможет работать эффективнее. Справедливости ради день тишины часто итак был с пачкой созвонов у многих.

Главное забыла. Аналитики! Два года назад в расчётном блоке был методолог, продакт (с бухгалтерским прошлым) и пара-тройка бизнес-аналитиков. Истории и задачи прорабатывались мозгом методолога и продакта. Спускались бизнес аналитикам, они там что-то чуть подробнее расписывали. И главное имели возможность с вопросами прийти к методологу. Разработка получала фичу и придумала, как это намастерить в коде с учётом разных сервисов. Проблемы тоже были. Но мой взгляд это было максимально похоже на правду. Методолог не выдержала нагрузки, ушла. У нас появился некий бизнес-архитектор. Его архитектурные решения до сих пор вспоминаем. Но опять же он всё равно был сильно мощнее чем бизнес-аналитики. Потом и он ушёл. История длинная. В этом году, весной где-то кому-то пришла гениальная идея внедрить в процесс системный анализ. А то бардак же. Про систему никто не думает. И вот шарящей головы нет, зато есть сомнительная цепочка бизнес-анализ - системный анализ - разработчик. Бизнес анализ считает себя важнее всех, но за работоспособность почему-то спрашивает с системного анализа. Типа концепцию системы на уровне фичи должен сгенерить системный аналитик и отдать разработчику чисто на реализацию в коде. Вот уже конец года, с системным анализом продолжаем биться. Проблем меньше не стало, стало больше. Новый архитектор вообще по возможности не лезет ни в какие глобальные изменения.

Как долго? Вчера выкатили видение продукта вплоть до 2030 года. Заканчивать не собираемся)

2 лайка

Хорошо бы когда безмасштабность обсуждать, чётче говорить – по какой иерархии вокруг какой системы меняем масштаб. Ибо даже если взять ваш софт, то то ли он внутри иерархии вашей организации, или внутри иерархии организации клиента, а сотрудники клиента непонятно в какой там иерархии (но они ж потом в окружении в момент эксплуатации, обработанные как-то вашим софтом! Или софт обрабатывает сотрудников администрации, которые обрабатывают сотрудников клиента?). То есть сначала прописать чётко граф создания, а потом тыкать в каждую систему графа создания и пытаться понять, что там вокруг. Ибо первое поколение системного мышления – целевая, и вокруг, безмасштабно, второе поколение – ах, там ещё и граф создания есть, и узлы в нём работают непрерывно.

Отдельно ещё то, что если целевая как-то связана с людьми, то люди не любят проходить обработки в сдизайненной последовательности, они сами как-то бегают по точкам обработки и каждый раз удивляют своим состоянием. Появляется какой-то employee journey, которое вы как-то обслуживаете с их eXperience. И у этого employee своё окружение и вроде как у вас там это сотрудник организации клиента, а ваш софт то ли ему помогает, то ли это инструмент сотрудника HR организации клиента – там цепочки, в них бы разобраться ))) Или ваш софт будет сам HR, администрирование ведь автоматизируется стремительно )))

Так что докрутить надо как-то с графом создания.

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

И там много у вас рассуждений про архитектуры, там ведь моды-тренды важны. Событийные архитектуры приходят на смену архитектурам, направленным на master data (которые как раз ориентированы на персон), но там же сплошные trade-offs у архитекторов – а их обсуждать некому. И архитекторы тоже беседуют с клиентами – а с клиентами там у вас пока ещё недодумано (то ли работники клиента, то ли HR клиента, то ли люди, которые организуют HR клиента и заодно нанимают вас как “софта-сотрудника этого департамента HR”), и ещё вы тогда становитесь как разработчики этого софта сотрудниками какого расширенного предприятия с точки зрения людей клиента? Если это сотрудники HR, одни ответы, если это люди, которые при помощи вашего софта пытаются изменить/организовать/трансформировать работу сотрудников HR – там другие ответы.

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

Главное, что если есть модель этого графа хоть как-то документированная, то можно дальше над ней размышлять – это ж главный чеклист “о чём хорошо бы помнить в суете проекта”.

1 лайк