У нас нет соглашения о том, как идти об этом процессе.
Характеристики того, что мы строим:
Учитывая такое положение вещей, я придерживаюсь мнения, что мы сядем вместе (может быть, на день или два) и составим матрицу общих проблем, с которыми сталкивается бизнес (думаю, мы назовем это бизнес-кейсом), и запишем их решения. - т.е. традиционное бизнес-решение (со своими плюсами и минусами), наше продуктовое решение проблемы (со своими плюсами и минусами). Мы можем заморозить этот вопрос, рассмотрев его с заинтересованными сторонами.
После этого мы можем приступить к созданию пользовательских историй, вайрфреймов и т. д.
Однако на самом деле мы создаем пользовательские истории с несколькими бизнес-кейсами, которые в целом не убеждают нас в принятии системы или дают ложное предположение о принятии.
Каков реальный способ сделать это?
Все такие проекты должны начинаться с бизнес-кейса (БК). BC должен указать проблему, которую вы хотите решить, или возможность, которую вы хотите использовать. В нем должны быть указаны затраты на реализацию проекта (в ресурсах и в наличных деньгах) и выгоды, которые, по мнению бизнеса, будут получены в результате реализации проекта. В вашем случае, поскольку природа продукта не определена, я предлагаю небольшой предварительный проект с собственным бюджетом, чтобы провести некоторый анализ клиентов и продукта, чтобы определить, как может выглядеть результат и какие функции он должен содержать. Результатом проекта анализа требований должен быть BC для проекта внедрения.
Все BC должны быть рассмотрены, утверждены и подписаны бизнесом. Это ваше одобрение для продолжения и выделение бюджета для выполнения работы. Оказавшись там, вы начинаете заниматься простым управлением проектами. То, как вы решите реализовать проект (и, следовательно, Продукт и другие результаты), зависит от ваших местных предпочтений (например, Agile/Waterfall/некоторая другая модель).
Начните с создания BC, который будет складываться (т. е. он принесет вашей компании больше пользы, чем затраты на завершение проекта — проще говоря, он принесет больше денег, чем затраты на его создание).
Затем в рамках общего БК зафиксировать особенности проекта и, по возможности, разделить их по МОСКВЕ, т.е. должно быть, должно быть, могло быть.
Получите свой бюджет. Запустите проект. Доставить товар. Делайте деньги (или измеряйте свои преимущества)
Исходя из моего опыта управления разработкой новых продуктов, я думаю, что первым шагом должен быть поиск запускающего клиента.
Нет запускающего клиента = нет эталонного случая, нет внутренних знаний, продукт, основанный на ИТ, вряд ли будет успешным на насыщенном рынке.
В вашем случае я бы порекомендовал найти по крайней мере двух клиентов, готовых потратить время и деньги, поскольку набор требований слишком сильно различается, и в противном случае вы можете найти решение для конкретного клиента. В качестве альтернативы вы можете обратиться к человеку, который хорошо разбирается в отрасли, работал с потенциальными клиентами, имеет навыки управления продуктом и готов поделиться.
Остальное — это просто создание бизнес-кейса с MoSCoW, agile или что-то еще, но всегда запуск клиентов в качестве партнеров на борту. Удачи!
Мне кажется, что вы боретесь с тем, что на самом деле у вас нет определенного владельца продукта для этого программного обеспечения. При разработке программного обеспечения, даже если вы пишете программное обеспечение, ориентированное на рынок, кто-то должен представлять роль владельца продукта, когда вы разрабатываете свое программное обеспечение. В противном случае вы будете развиваться бесцельно и, в конечном счете, не сможете узнать, представляет ли ваш код ценность для кого-либо, включая людей, разрабатывающих его. Владение продуктом — важнейший аспект разработки программного обеспечения. Как только вы это поймете, лично я рассмотрю возможность использования какой-либо гибкой методологии разработки, чтобы вы могли более гибко реагировать на потребности владельца продукта.
В InfoQ есть хорошее обсуждение того, за что отвечает владелец продукта, здесь: Шаблоны владельца продукта .
Одна из важных вещей, в которой нужно быть уверенным, — это то, что у вас есть приоритетный список невыполненных работ. Без роли владельца продукта невозможно ожидать, что у вас будет список важных вещей, над которыми нужно поработать.
В качестве общего ресурса для практики разработки я также рекомендую этот блог, написанный инженерным персоналом Etsy: Code as Craft .