Задание из R1.1 - игра Назови систему

Посты студентов Рациональная работа
1

Какую систему создаёт моё предприятие

Что я сейчас считаю целевой системой

Компания, в которой я работаю - разработчик программного обеспечения (“вендор”).
Мы делаем “платформу для разработчиков ПО”, но с точки зрения клиента это программная часть рабочего места сотрудника производственной компании.

Таким образом, ответ на нулевом этапе игры:

программная часть цифрового рабочего места сотрудника производственной компании

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

Почему я сейчас выделяю именно так? Потому что для заказчика ценность представляет не программный код сам по себе и не наша внутренняя инженерная кухня. Заказчик покупает не “разработку”, а возможность, чтобы у его сотрудников на рабочих местах реально работал набор цифровых инструментов, поддерживающих их повседневную деятельность.

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

Как система эксплуатируется и кому полезна

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

Пользу от эксплуатации этой системы извлекают разные участники:

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

Кто участвует в создании системы

В создании этой системы участвуют типичные команды по разработке ПО, но не только разработчики. В частности, участвуют:

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

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

Действия по созданию системы тоже довольно типовые для инженерной деятельности, хотя в реальности, конечно, всё сложнее и грязнее, чем на красивой схеме:

  • кто-то определяет видение продукта и его границы;
  • кто-то выявляет и уточняет требования;
  • кто-то проектирует решение;
  • кто-то реализует, тестирует, развёртывает и сопровождает.

Иными словами, система создаётся через работу целой системы создания, а не возникает из усилий какого-то одного исполнителя.

Почему это целевая система и что будет, если ошибиться

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

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

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

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

В пределе это означает следующее:

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

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

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

P.S.

Мы внутри сами пользуемся своей целевой системой, и у нас относительно свежая версия целевой системы одновременно является и подсистемой создания её следующей версии. Как говорится: “We eat our own dog food”.

1 лайк
2

Прямо в названии должно быть коротко выражено: что это за часть функционально. Это же не всё рабочее место? Как выделить именно то, что покупают у вас? Дальше в описании есть детали, но попробуйте найти короткое название.

И надо сформулировать, что находится на уровень выше по цепочке производства. Надо иметь чёткое понимание, рабочее место в целом: оно для чего?

3

И еще стоит решить, вам важно думать про одно рабочее место или только если “все” рабочие места компании подключены и общаются вместе (сетевой эффект).

4

А ваше ПО на каких серверах? На ваших или на серверах клиента?

Один экземпляр вашего ПО устанавливается физически на одно рабочее место сотрудника? То есть если в компании 100 рабочих мест, то вы продаете 100 продуктов?

Если бы информационная система была бы вариантом реализации вашей целевой системы, то как можно было бы назвать целевую систему? Может “Система учета операционной деательности”, “Виртуальный офис”, “Система совместной работы”.

Можно попробовать написать название вашего продукта и контурентов и попросить у LLM типизировать все эти системы.

1 лайк
5

Проанализировал мой ответ с ИИ по спецификации FPF (исходной сырой монолитной, НЕ по отстающим от неё скиллам на её основе).

Агент похвалил меня за “ситную интуицию” (хотя это не только она, но и результаты обучения в МИМ). Сказал, что есть смешение понятий: текст местами смешивает онтологию системы, контекст клиента, коммерческое обещание и систему создания.

Опорные места спецификации:

#### A.1:4.4 - Inside/Outside decision procedure
To decide whether an entity **E** is *inside* a holon **H**, apply:

1. **Dependency test:** removing **E** breaks a core invariant of **H**.
2. **Interaction test:** **E** participates in causal loops wholly within **H**’s boundary.
3. **Emergence test:** **E** contributes to a novel collective property warranting **H** as a single unit.
   Fail all three → **E** is *outside*. This practical triage prevents “scope creep” and forces explicit modeling of environment vs interior.

> **Collections vs collectives.** A set/collection of holons is not itself an acting unit. If a grouping is expected to act, model it as a `U.System` holon with its own boundary ...

#### A.2.3:4.3 - Position in the enactment chain
* **Design‑time:**
  The context may assert: `bindsCapability(ServiceProviderRole, Capability)`.
  Providers choose `Method/MethodDescription` to realise the promised effect described by the promise content.

* **Run‑time:**
  The **provider** performs `Work` to fulfil the promise content ...
  Delivered `Work` instances are evaluated against `acceptanceSpec` ...

> **Memory hook:** *Promise content promises, Method describes, Work proves.*

Прямо сейяас затрудняюсь их полностью осознать, так как мои понятия упомянутых терминов (и особенно различий между ними) слабы. Поэтому в основном ориентируюсь на разъяснения ИИ на русском языке ниже.

Что по сути правильно

  1. Правильное отделение системы создания от эксплуатируемой системы. Это хорошо ложится на A.15 и A.7: описание, метод, план, фактическая работа и эксплуатация не должны схлопываться.

  2. Правильно, что заказчик покупает не “разработку”, а работающую штуку, из эксплуатации которой извлекают пользу. Это согласуется с A.2.3: наружу значимы не внутренние методы, а обещанный внешний эффект, который потом подтверждается фактическим Work.

  3. Правильно, что неправильное выделение системы ведёт к “очень качественно сделали не то”. Это прямое следствие A.1 и A.7: сначала граница и тип сущности, потом роли, методы, работа и критерии.

Где каша

вы смешали unit of sale, unit of engineering responsibility и unit of user value.

  1. не зафиксирована граница целевой системы
  2. “Рабочее место со столом и стулом” как надсистема, скорее всего, плохой ход - слишком далеко от рассматриваемой системы
  3. “Платформа для разработчиков” и “рабочее место сотрудника” не одно и то же (разные bounded contexts)
  4. Фраза “заказчик покупает возможность” слабая
  5. “Информационная система производственной компании” может быть слишком широкой целью - включение в границы нашей системы того, чего в ней нет

Предложение по исправлению

Я бы не держал один “правильный ответ”. Я бы держал слоистую формулировку.

Интересный поворот, так можно было? :wink:

Подробное разъяснение ИИ + FPF

  1. Наружу, для рынка и контракта
    Мы поставляем не “разработку” и не “платформу” как внутренний инженерный объект, а обещание работающей цифровой рабочей системы в определённой области задач с заданными критериями пригодности, доступности и качества.

  2. Инженерно, как поставляемая система
    Целевая создаваемая нами система - это развёрнутая у клиента программная система
    + её конфигурация
    + интеграции
    + данные и правила, попадающие в границу поставки,
    которая поддерживает выполнение сотрудниками рабочих задач в оговорённом контексте.

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

  4. Отдельно от этого
    Система создания - это другой холон: ваши product owners, аналитики, разработчики, QA, DevOps, внедрение, support, плюс представители заказчика в ролях согласования, постановки, приёмки и обратной связи.

Вот это уже похоже на управляемую картину.

Мой прямой ответ на ваш главный тезис

Если коротко: вы правы, что целевая система не равна разработке и не равна внутренней платформе.
Но вы пока не правы в точном масштабе этой системы.

С высокой вероятностью более точная формулировка такая:

  • не “рабочее место сотрудника со столом и стулом”;
  • не “вся информационная система предприятия”;
  • а поставляемая и эксплуатируемая у клиента программная рабочая система в заданной области деятельности, которая уже входит как подсистема в более широкий социотехнический контур предприятия.

То есть ваш текст сейчас слишком расширяет систему вверх и недостаточно отделяет promise / delivery / operation / creation.

6

Спасибо, Виктор!

Кратко и функционально получается цифровая система управления операционной деятельностью предприятия.

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

7

Безусловно, все рабочие места в совокупности дают синергетический эффект. Спасибо за наводку!

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

1 лайк
8

По умолчанию у клиента, но есть и SaaS.

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

Новый переосмысленный вариант: цифровая система управления операционной деятельностью предприятия.

Так можно попросить ИИ сразу и “нашу систему” типизировать! Это же просто, но читерство :wink:

Попросил, итоги:

  1. FPF-определение:

Это система класса enterprise software-production platform, то есть управляемая цифровая производственная среда для полного жизненного цикла ПО, в которой в одном bounded context объединены планирование работ, управление знаниями и документацией, разработка кода, конвейеры сборки и поставки, тестирование, эксплуатация и сервисное сопровождение.

Кратко: управляемая цифровая производственная среда для полного жизненного цикла ПО

  1. В более прикладной формулировке:

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

Кратко: корпоративная внутренняя платформа производства ПО

1 лайк
9

Попросил разъяснить цитаты из спецификации FPF и использованные термины. Сложно за один раз всё запомнить, но в целом понятно.
С критикой ИИ согласен частично. Не согласен в части тоговых формулировок, но кажется, что это больше “трудности перевода”, т.к. концептуальных возражений нет.

Как эти две цитаты связаны между собой

Они про разное, но вместе дают одну логику.

Первая цитата

Помогает ответить:

Что вообще является системой, которую мы обсуждаем? Где её граница?

Вторая цитата

Помогает ответить:

Как эта система создаёт обещанный внешний эффект и чем это подтверждается?

То есть сначала вы определяете holon, потом для него можете уже раскладывать:

  • какие у него роли,
  • какие capabilities,
  • какие methods,
  • какие promise contents наружу,
  • какие work-исполнения в эксплуатации.

Определения терминов, которые я и так вроде понимал, но “повторенье - мать ученья”:

Термин Определение Вопрос, на который отвечает
U.Holon Сущность, которую рассматривают как целое с границей и, возможно, как часть более крупного целого. Что это за целое, которое мы выделяем как систему или объект рассмотрения?
U.Boundary Граница holon’а, которая отделяет то, что считается внутри системы, от того, что считается снаружи. Что входит в систему, а что находится вне её?
U.BoundedContext Локальная рамка смысла, внутри которой слова, роли и правила имеют конкретное, согласованное значение. В каком контексте эти слова, роли и правила имеют именно такой смысл?
U.Role Роль / маска / функциональная позиция сущности в контексте. Роль не является ни поведением, ни структурной частью системы. Кем или чем является носитель здесь и сейчас с функциональной точки зрения?
U.RoleAssignment Факт вида: кто, какую роль, в каком контексте и, возможно, в каком интервале времени играет. Кто именно назначен на эту роль, где и когда?
U.Capability Способность системы выполнять некоторый класс работы в заданных условиях и с заданными показателями. Это не назначение, не рецепт и не факт выполнения. Может ли этот носитель реально это делать в требуемых условиях и с нужным качеством?
U.Method Способ выполнения в принципе, то есть семантическое “как делать”. Это абстрактный метод, а не его конкретная запись. Как это делается в принципе?
U.MethodDescription Описание метода в конкретной форме: код, регламент, BPMN, инструкция, SOP, алгоритм, модель. Как именно этот способ записан, описан или представлен?
U.Work Конкретное выполнение в реальности: датированное run-time событие с исполнителем, временем, ресурсами, результатом и следами. Что реально произошло, когда, кем и с каким результатом?
U.PromiseContent Внешнее обещание потребителю: что именно ему обещают снаружи, на каких условиях и по каким критериям это будет оцениваться. Что именно обещано потребителю или заказчику?
10

Задание R1.1:9 - уточнить описание эксплуатации системы

Ситуация эксплуатации системы “цифровая система управления операционной деятельностью предприятия”

  • Агенты, использующие систему: сотрудники производственной компании (планируется, что вскоре и ИИ-агенты тоже).
  • Причина, по которой эта система полезна эксплуатантам: это среда для взаимодействия эксплуатантов, а также хранения артефактов и свидетельств операционной деятельности предприятия. Экзокортекс предприятия, если так можно выразиться - и память, и некоторое количество “мозгов”.
  • Действия агентов по эксплуатации системы: взаимодействие с системой через компьютер, телефон - типичные CRUDL-операции с сущностями по действующим процессам + запуск неких автоматизированных действий.
  • Условия эксплуатации системы
    • место: любое, где есть устройство доступа (компьютер. телефон) и связь
    • время: по умолчанию рабочее в регионе работы компании (с 9 до 20 - с поправкой на плавающий рабочий график), но по большей части 24/7 за исключением времени плановых техработ

Что изменится

  • В мире после действий агента-пользователя системы: переход на следующий этап выполнения производственного процесса - автоматизированный, удобный, с сохранением всех необходимых свидетельств происходящего (как для участников процесса, так и технических - для поддержки, безопасников и т.п.)
  • У самого агента-пользователя системы: отслеживаемый прогресс по рабочим продуктам
  • У других агентов, которые будут получать пользу от результата: отслеживаемые входящие рабочие продукты в предсказуемом (регламентированном) виде: для смежников - необходимая информация для их работы, для руководства - показатели, отчёты и т.п.
11

Попросил ИИ + FPF покритиковать

… Тут была пара экранов с ключевыми ошибками …

Что у вас уже неплохо

Не всё плохо. У вас есть несколько сильных интуиций, которые с FPF совпадают:

  • вы правильно чувствуете, что система должна хранить не только данные, но и evidence;
  • вы уже различаете разные аудитории результата: исполнители, смежники, руководство, support/security;
  • вы описываете мир как mixed human/AI environment, а это как раз близко к практической зоне FPF;
  • вы связываете систему не с “данными вообще”, а с продвижением рабочего процесса.

То есть направление правильное. Ошибка в том, что это пока не разложено на FPF-слои.

Ваш текст сейчас описывает не эксплуатационную модель системы в FPF, а смесь из:

  • продуктового позиционирования,
  • пользовательского сценария,
  • обещания сервиса,
  • и желаемого операционного эффекта.

Это не фатально, но это именно ошибка моделирования.

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

1 лайк
12

Предложенное исправление от ИИ + FPF

Убрал или ослабил три проблемных места:

  • заменил метафоры вроде “экзокортекс” и “мозги” на операционно проверяемые функции системы;
  • развёл роли, контексты, исполнение работы и evidence;
  • убрал неявное утверждение, будто система сама является субъектом управления предприятием (сам придумал! не было такого!)

Ситуация эксплуатации системы

Система: цифровая система координации и исполнения операционной деятельности предприятия.

1. Что это за система

Это цифровая рабочая среда предприятия, в которой:

  • координируется исполнение операционных процессов;
  • фиксируются рабочие объекты, события исполнения и связанные с ними артефакты;
  • сохраняются свидетельства фактически выполненной работы;
  • публикуются разные представления одного и того же хода работ для разных ролей: исполнителей, смежников, руководителей, поддержки, безопасности и аудита;
  • запускаются автоматизированные действия в рамках допустимых полномочий и правил.

Важно: система не “управляет предприятием” сама по себе. Она обеспечивает среду, правила фиксации, маршрутизацию, наблюдаемость и частичную автоматизацию операционной работы.

2. Кто эксплуатирует систему

Систему эксплуатируют не “агенты вообще”, а носители ролей в разных контекстах.

Основные группы ролей:

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

3. Зачем эта система полезна

Система полезна не как “мозг предприятия”, а как общая среда координации и накопления операционного знания.

Она даёт предприятию:

  • единое пространство для работы с операционными объектами и состояниями;
  • фиксацию не только данных, но и фактов исполнения работы;
  • хранение evidence-слоя: журналов, подтверждений, версий, согласований, следов автоматизированных действий;
  • предсказуемые hand-off между участниками процесса;
  • согласованные представления одной и той же деятельности для разных аудиторий без ручного пересочинения смысла.

4. Что делают пользователи и автоматизированные участники

В ходе эксплуатации выполняются:

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

Важно различать:

  • описание способа работы и регламента;
  • план выполнения;
  • фактически произошедшее исполнение;
  • свидетельства, подтверждающие, что исполнение действительно произошло.

5. Контексты эксплуатации

Система используется не в одном общем контексте, а как минимум в нескольких связанных контекстах:

  • контекст исполнения операционной работы
    Здесь важны рабочие объекты, очереди, состояния, сроки, исполнение шагов, отклонения;

  • контекст межфункциональных hand-off
    Здесь важны состав входящего рабочего продукта, полнота передачи, статус приёмки и правила перехода между участниками;

  • контекст управленческого наблюдения
    Здесь важны агрегированные показатели, прогресс, загрузка, отклонения, сроки и отчётные представления;

  • контекст поддержки, безопасности и аудита
    Здесь важны трассировка действий, provenance, журналы, авторства, основания изменений и проверяемость событий;

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

6. Условия эксплуатации

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

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

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

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

Что изменяется в результате эксплуатации системы

1. Что меняется в операционной реальности предприятия

После действий пользователя или автоматизированного участника:

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

2. Что меняется для самого исполнителя

Исполнитель получает:

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

3. Что меняется для других участников

Для смежников:

  • появляется стандартизованный входящий рабочий продукт, пригодный для следующего шага без лишней ручной расшифровки.

Для руководителей:

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

Для поддержки, безопасности и контроля:

  • появляется проверяемая трасса действий, событий, автоматизаций и оснований изменений.

Для будущих ИИ-участников:

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

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

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

Вероятно, это издержки генерации ИИ текста на русском языке. В данном контексте понятно, что это делает описываемая система (а не оно само делается). Но всё равно дребезжит.

Других возражений по существу, кроме языковых огрехов (“трасса” вместо “трассировка”) у меня нет.

13

в пунктах 1,2,3,4 - можете заметить повторение объектов при перечислении?
Например: “фиксируются рабочие объекты…” и “сохраняются свидетельства…” - это про одно и тоже. И может, какие-то из повторении будут вызывать больше или меньше ощущения дребезга для вас.

14

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

1 лайк
15

А можете описать это как проблему (боль), которую будут испытывать без этой системы.

16

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

Почему так: в рассмотрении службы, если занимаетесь инструктажом(хоть даже минимальным) сотрудников в использовании вашего ПО, то уже вы занимаетесь инженерией мастерства(навыка) конкретного оператора использующего ПО → тратите на это ресурсы, меняете в этой части мир. Часто платят не за то, что ПО разработали и дистрибуцировали, а за пользу. Пользу не получить в данном случае, если оператор не будет жать правильные кнопки в правильной ситуации по назначению. По же здесь всего-лишь элемент того, что собираете. Это отразиться и на экономической модели - обучение сотрудников потребует затрат ресурсов, а если считаете только ПО как конечным продуктом, то неучтете эти расходы, можете столкнуться с проблемами.

второй момент, может оказаться, что через ваше ПО что-то конкретное делают, и вам это в вашем ПО надо учитывать: что-то спецефическое, в зависимости от предметной области, ситуаций: к примеру в нашей фирме это фарм-ритейл (с этим и нюансы важные имеются). Возможно важны поэтому какие-то характеристики от ролей заметятся. Коммент у меня сырой, но интересно разбираться, спасибо за кейс.

1 лайк
17

Конечно!
Какую проблему решаем (даже несколько):

  1. Разрозненный инструментарий выполнения рабочего процесса
    • требуются усилия на настройку и поддержку работы каждого отдельного компонента (IDE, хранилище исхдоного кода, CI/CD, репозиторий артефактов, база знаний, таск-трекер и т.д.)
    • сложно достичь полного соответствия отдельных инструментов по промежуточным рабочим продуктам (контрактам взаимодействия): выход одного этапа рабочего процесса не полностью соответствует ожидаемому входу следующего этапа.
  2. Разрозненное хранение свидетельств выполнения этапов рабочего процесса: если что-то идёт не так, сложно найти причину, т.к. нужно смотреть в 10+ местах. А иногда нужных данных нет в принципе.
  3. Плохой UX (user experience): с точки зрения выпонения работ пользователем (“рабочей станцией”) в нашей системе количество атомарных действий (двинуть мышкой, нажать кнопку, ввести текст) в разы меньше, чем для выполнения тех же работ без нашей системы.
  4. Синергитический эффект (раскрытие темы плохого UX): в системе из разрозненных компонентов отсутствует. В нашей системе есть (сквозная авторизация, функция текстового поиск сразу по всем артефактам системы).
1 лайк