Какую систему создаёт моё предприятие
Что я сейчас считаю целевой системой
Компания, в которой я работаю - разработчик программного обеспечения (“вендор”).
Мы делаем “платформу для разработчиков ПО”, но с точки зрения клиента это программная часть рабочего места сотрудника производственной компании.
Таким образом, ответ на нулевом этапе игры:
программная часть цифрового рабочего места сотрудника производственной компании
Проще говоря, это информационная система производственной компании, в которой сотрудники ставят и выполняют задачи, работают с корпоративной базой знаний, создают и согласуют документы и в целом ведут свою работу по принятым в компании процессам.
Почему я сейчас выделяю именно так? Потому что для заказчика ценность представляет не программный код сам по себе и не наша внутренняя инженерная кухня. Заказчик покупает не “разработку”, а возможность, чтобы у его сотрудников на рабочих местах реально работал набор цифровых инструментов, поддерживающих их повседневную деятельность.
При этом надсистемой для такой целевой системы я бы назвал рабочее место сотрудника производственной компании. В него входят уже не только наши программные продукты, но и компьютер, стол, стул и другие подсистемы из реальной рабочей обстановки.
Как система эксплуатируется и кому полезна
Если говорить об эксплуатации, то система эксплуатируется сотрудниками производственной компании в ходе их обычной работы. Они ведут задачи в таск-трекере, читают и пишут статьи в базе знаний, подготавливают документы, отправляют их на согласование, фиксируют результаты работы и обмениваются рабочей информацией. То есть, система используется не ради самой себя, а как рабочий инструмент, встроенный в деятельность компании по процессам этой компании.
Пользу от эксплуатации этой системы извлекают разные участники:
- непосредственный пользователь получает возможность выполнять свою работу в более организованном и управляемом виде;
- руководитель получает прозрачность, управляемость, более предсказуемое исполнение процессов и повышенную эффективность работы предприятия;
- предприятие в целом получает возможность координировать деятельность сотрудников через единое цифровое пространство, а не через разрозненные договорённости и хаотический обмен сообщениями.
Кто участвует в создании системы
В создании этой системы участвуют типичные команды по разработке ПО, но не только разработчики. В частности, участвуют:
- владельцы продуктов;
- аналитики;
- разработчики;
- тестировщики;
- DevOps-инженеры;
- внедренцы и специалисты сопровождения;
- коммерческие и управленческие подразделения (в их ролях не ориентируюсь).
Кроме того, в создании системы участвует и сам заказчик: он формулирует свои ограничения и ожидания, предоставляет контекст эксплуатации, даёт обратную связь и в каком-то смысле соучаствует в доопределении того, какой система вообще должна быть.
Действия по созданию системы тоже довольно типовые для инженерной деятельности, хотя в реальности, конечно, всё сложнее и грязнее, чем на красивой схеме:
- кто-то определяет видение продукта и его границы;
- кто-то выявляет и уточняет требования;
- кто-то проектирует решение;
- кто-то реализует, тестирует, развёртывает и сопровождает.
Иными словами, система создаётся через работу целой системы создания, а не возникает из усилий какого-то одного исполнителя.
Почему это целевая система и что будет, если ошибиться
При этом сама “платформа для разработчиков” или “платформа для управления процессами производства”, если разобраться, с точки зрения клиента может и не быть целевой системой. То, что мы поставляем - это важное средство создания и развития конечной системы, но не то, что клиент хочет получить в конечном счёте. Клиенту нужна не платформа как внутренний инженерный конструкт, а работающая у него (в его инфраструктуре) система.
Именно поэтому я сейчас считаю целевой системой не процесс разработки, не отдельный программный модуль и не рабочее место целиком, а работающую у клиента информационную систему. Она ближе всего к той системе, которая реально эксплуатируется и из эксплуатации которой извлекают пользу.
А что будет, если система выделена неправильно? Последствия, на мой взгляд, довольно неприятные. Можно очень качественно сделать не то. Например, можно улучшать внутреннюю платформу, когда у клиента на самом деле не решена задача эксплуатации конечной системы. Можно спроектировать удобство для команды разработки и при этом не обеспечить удобство и пригодность для пользователя. Можно вообще перепутать средство создания системы с самой целевой системой.
Тогда довольно быстро появляется разрыв между тем, что создаётся, и тем, что на самом деле нужно получателю. Из этого следуют неверные требования, неверные критерии качества, неверные архитектурные решения и в конечном счёте лишние затраты времени и денег. Если ошибка небольшая, систему ещё можно дотащить до нужного состояния. Если ошибка принципиальная, может оказаться, что работа велась вообще не туда и существенную часть либо вообще всё придётся переделывать заново.
В пределе это означает следующее:
- создатель системы не окупит свои расходы;
- заказчик не получит нужный ему результат;
- пользователи не смогут удовлетворить свои рабочие потребности.
У такой ошибки почти неизбежно есть финансовые последствия, а в некоторых случаях могут быть и юридические, если ожидания сторон были зафиксированы формально, а поставленный результат им не соответствует.
Так что мой текущий ответ пока не претендует на окончательную правильность. Но на сегодня я бы сказал так: целевая система в моей работе - это эксплуатируемая у клиента информационная система, поддерживающая работу сотрудников производственной компании, а всё остальное стоит проверять уже относительно неё.
P.S.
Мы внутри сами пользуемся своей целевой системой, и у нас относительно свежая версия целевой системы одновременно является и подсистемой создания её следующей версии. Как говорится: “We eat our own dog food”.