ТГ-бот для голосования и формирования списков участников мероприятий для случаев, когда функционала стандартного тг-голосования/опроса недостаточно. Например, составление списка участников по типу "запишите меня с +1 (буду с женой/другом и т.д.)" на мероприятие с ограниченным числом мест, ведение "скамейки запасных", перемещение из "скамейки запасных" при отмене голосов тех, кто проголосовал ранее, уведомление добавленных в основной состав, "черный список" участников. Действующий вариант разработан для одного конкретного сообщества. Сейчас изучаю возможность его масштабирования и востребованности для других чатов и групп. Если вам он может быть интересен, прошу принять участие в опросе на 5 минут
Если кому-то удобно формировать свой mind map на тему "что стоит учитывать при разработке продукта", то описанный в статье вариант - один из возможных. Я например вижу в этом некоторые отголоски альф системной инженерии Левенчука, можно найти разделы BABOK. Видимо, автор именно так и представляет для себя road map. Можно уходить в терминологические дуэли, а можно просто позволить ему сделать качественный продукт.
Судя по выводам, автор решил изобрести UML вместо BPMN. Ощущение, что есть некий негативный опыт применения BPMN без должной подготовки, знания его назначения или разочарования из-за исходно завышенных ожиданий. Могу предложить автору познакомиться с понятием цель моделирования и попытаться использовать BPMN для выявления пользовательских задач (для начала хотя бы) процессов, которые лягут в основу проектирования системы. Т.е. 1 прямоугольник - 1 пользовательская задача. Цепочка таких задач составляют процесс. Любая система имеет много проекций. BPMN помогает только в описании проекции процессов деятельности, где, внезапно, может не использоваться ни одна инфосистема, а то и использоваться далеко не одна.
У меня вопрос про исходную логику этого синтетического примера:
Проверка благонадежности и возможных услуг никак между собой не связаны — эти действия можно выполнять параллельно.
А точно ли не связаны? Предложение услуг разве предусматривается для неблагонадежных клиентов? В описанной схеме поиск услуг будет обрабатываться даже для неблагонадежных клиентов, что, вероятно, будет зря расходовать ресурсы. Может, следовало бы поиск услуг запускать после выполнения проверки надежности только с положительным результатом?
А стоит ли рассматривать процесс с тех же позиций, что и объект?
Не кажется ли вам, что это по природе своей это разные вещи, и для изучения и моделирования их используются разные инструменты и описательные категории?
Одно это предложение демонстрирует лютое владение материалом
ТГ-бот для голосования и формирования списков участников мероприятий для случаев, когда функционала стандартного тг-голосования/опроса недостаточно. Например, составление списка участников по типу "запишите меня с +1 (буду с женой/другом и т.д.)" на мероприятие с ограниченным числом мест, ведение "скамейки запасных", перемещение из "скамейки запасных" при отмене голосов тех, кто проголосовал ранее, уведомление добавленных в основной состав, "черный список" участников.
Действующий вариант разработан для одного конкретного сообщества. Сейчас изучаю возможность его масштабирования и востребованности для других чатов и групп. Если вам он может быть интересен, прошу принять участие в опросе на 5 минут
Если кому-то удобно формировать свой mind map на тему "что стоит учитывать при разработке продукта", то описанный в статье вариант - один из возможных.
Я например вижу в этом некоторые отголоски альф системной инженерии Левенчука, можно найти разделы BABOK.
Видимо, автор именно так и представляет для себя road map. Можно уходить в терминологические дуэли, а можно просто позволить ему сделать качественный продукт.
Судя по выводам, автор решил изобрести UML вместо BPMN.
Ощущение, что есть некий негативный опыт применения BPMN без должной подготовки, знания его назначения или разочарования из-за исходно завышенных ожиданий.
Могу предложить автору познакомиться с понятием цель моделирования и попытаться использовать BPMN для выявления пользовательских задач (для начала хотя бы) процессов, которые лягут в основу проектирования системы. Т.е. 1 прямоугольник - 1 пользовательская задача. Цепочка таких задач составляют процесс.
Любая система имеет много проекций. BPMN помогает только в описании проекции процессов деятельности, где, внезапно, может не использоваться ни одна инфосистема, а то и использоваться далеко не одна.
А точно ли не связаны? Предложение услуг разве предусматривается для неблагонадежных клиентов? В описанной схеме поиск услуг будет обрабатываться даже для неблагонадежных клиентов, что, вероятно, будет зря расходовать ресурсы. Может, следовало бы поиск услуг запускать после выполнения проверки надежности только с положительным результатом?
Не кажется ли вам, что это по природе своей это разные вещи, и для изучения и моделирования их используются разные инструменты и описательные категории?