В строительстве есть концепция ΒΙΜ (Building Information Model), которая полностью описывает будущий объект строительства, включая проект, материалы, работы, ресурсы, время и затраты, причем до мельчайших подробностей, буквально до дверных ручек, и разные части проекта могут быть наложены друг на друга, чтобы выявить коллизии.
Примерно такое же может быть полезно и в разработке софта, в том числе с выявлением коллизией (например, трассировкой требований). Но сапожник без сапог - упирается в инструменты моделирования, которых пригодных для работы нет пока. А какие есть - или слишком дороги, или неудобны. Вот и живут одни и те же требования одновременно в разных местах и в разных версиях, и ничего с этим не поделать. А никому это и не надо особенно.
В этой статье на реальном кейсе я хочу рассмотреть весь путь превращения требований от бизнес-заказчика в техническое задание для разработчиков
Таки заявлена цель статьи в первом же предложении. Однако дальше идет перечисление гипотез маркетинга и сразу:
Собственно говоря, на основе этих пунктов любой начинающий аналитик без труда напишет юзер-стори.
То есть проверять, анализировать гипотезы и уточнять цели не нужно? Тогда это не весь путь превращения требований. А проблема в том, что без анализа получится плохое решение, и это боком выйдет самим разработчикам, они и будут виноваты, так как плохо выполнили задание маркетинга. А без анализа задания как это понять? Это конечно вопрос к маркетингу, но почему они решили, что клиенту нужно предлагать рекомендации на основе его (клиента то есть) опыта, если его опыт такой, что он ищет-ищет, а найти ничего не может? Опыт плохой, и рекомендация на основе этого опыта тоже будет плохая. Тут может быть лучше было бы показывать, что другие покупают в этих категориях, может быть на основе анализа поисковых запросов, но это уже детали, в которые вникать никто не любит. Особенно бизнес. Написать юзер стори из двух частей вместо трех это у бизнеса любимое занятие.
Нужно загрузить в него диаграмму в формате drawio (кнопка "Открыть"), и он выведет: в левой панели саму диаграмму, в средней таблицу объектов (вершины графа диаграммы пока, ребра не выводятся), а в правой - описание в формате markdown.
Для справки сделал тестовую диаграмму, в которой описал идею сервиса в виде диаграммы - она загружается по умолчанию. Редактировать саму диаграмму в сервисе нельзя, только атрибуты объектов.
Можно менять сортировку, добавлять атрибуты, в атрибутах хранить дополнительную информацию, которая может выводиться в описание.
Был такой инструмент - bpwin, в нем можно было делать модели в IDEF0, и по моделям генерировать документацию. Сейчас этого не хватает, особенно если учесть, что нотаций разных много, и часто требуется описание диаграммы в документ вставлять. А поскольку формат drawio - это xml, то я подумал, что в нем можно это делать, тем более что он позволяет дополнять диаграмму пользовательскими атрибутами, которые доступны по Ctrl+M из самого drawio. Можно нарисовать диаграмму в drawio, загрузить в сервис, дополнить ее нужными атрибутами (по кнопке (+) в средней панели можно добавить любые атрибуты ко все объектам диаграммы сразу), настроить вывод, и можно сказать, что документ готов. В таблице на средней панели можно отредактировать значения атрибутов, или сохранить диаграмму и отредактировать их непосредственно в drawio (выделить объект, нажать Ctrl+M и заполнить значения для атрибутов объекта).
Пока не все виды фигур отображаются корректно (убился с рендерингом), но основные фигуры работают.
Заголовок "Как создать шаблон", а содержание - чем заполнить шаблон. Или тема не раскрыта, или заголовок не подходит к тексту.
В строительстве есть концепция ΒΙΜ (Building Information Model), которая полностью описывает будущий объект строительства, включая проект, материалы, работы, ресурсы, время и затраты, причем до мельчайших подробностей, буквально до дверных ручек, и разные части проекта могут быть наложены друг на друга, чтобы выявить коллизии.
Примерно такое же может быть полезно и в разработке софта, в том числе с выявлением коллизией (например, трассировкой требований). Но сапожник без сапог - упирается в инструменты моделирования, которых пригодных для работы нет пока. А какие есть - или слишком дороги, или неудобны. Вот и живут одни и те же требования одновременно в разных местах и в разных версиях, и ничего с этим не поделать. А никому это и не надо особенно.
Таки заявлена цель статьи в первом же предложении. Однако дальше идет перечисление гипотез маркетинга и сразу:
То есть проверять, анализировать гипотезы и уточнять цели не нужно? Тогда это не весь путь превращения требований. А проблема в том, что без анализа получится плохое решение, и это боком выйдет самим разработчикам, они и будут виноваты, так как плохо выполнили задание маркетинга. А без анализа задания как это понять? Это конечно вопрос к маркетингу, но почему они решили, что клиенту нужно предлагать рекомендации на основе его (клиента то есть) опыта, если его опыт такой, что он ищет-ищет, а найти ничего не может? Опыт плохой, и рекомендация на основе этого опыта тоже будет плохая. Тут может быть лучше было бы показывать, что другие покупают в этих категориях, может быть на основе анализа поисковых запросов, но это уже детали, в которые вникать никто не любит. Особенно бизнес. Написать юзер стори из двух частей вместо трех это у бизнеса любимое занятие.
Нужно загрузить в него диаграмму в формате drawio (кнопка "Открыть"), и он выведет: в левой панели саму диаграмму, в средней таблицу объектов (вершины графа диаграммы пока, ребра не выводятся), а в правой - описание в формате markdown.
Для справки сделал тестовую диаграмму, в которой описал идею сервиса в виде диаграммы - она загружается по умолчанию. Редактировать саму диаграмму в сервисе нельзя, только атрибуты объектов.
Можно менять сортировку, добавлять атрибуты, в атрибутах хранить дополнительную информацию, которая может выводиться в описание.
Был такой инструмент - bpwin, в нем можно было делать модели в IDEF0, и по моделям генерировать документацию. Сейчас этого не хватает, особенно если учесть, что нотаций разных много, и часто требуется описание диаграммы в документ вставлять. А поскольку формат drawio - это xml, то я подумал, что в нем можно это делать, тем более что он позволяет дополнять диаграмму пользовательскими атрибутами, которые доступны по Ctrl+M из самого drawio. Можно нарисовать диаграмму в drawio, загрузить в сервис, дополнить ее нужными атрибутами (по кнопке (+) в средней панели можно добавить любые атрибуты ко все объектам диаграммы сразу), настроить вывод, и можно сказать, что документ готов. В таблице на средней панели можно отредактировать значения атрибутов, или сохранить диаграмму и отредактировать их непосредственно в drawio (выделить объект, нажать Ctrl+M и заполнить значения для атрибутов объекта).
Пока не все виды фигур отображаются корректно (убился с рендерингом), но основные фигуры работают.
Из текста диаграмма это хорошо. А обратная задача? Мне не хватало, и решил сделать: diagramhacker.ru