Тут знаете ли, всякие штуки про разработку пишу. И смежные темы. Больше двадцати лет жизни отдал этому балагану, надо опытом делиться. Вводный текст.
Сами по себе модели управления — это тоже технология. Причем ни разу не простая, не интуитивно понятная, и — вопреки мнению некоторых — не воспроизводимая тупым копированием. С интересом смотрю с 2000 года, как на этом моменте регулярно обсираются недостаточно осмотрительные товарищи.
В удивительное время живем. Недавно ко мне пришли неглупые и непожилые, спрашивать «а что бы вот такое сделать, чтобы всем хорошо стало». В смысле, как найти полезную бизнес-модель. Ничего нового, они постоянно приходят (и это хорошо), примерно с 2006 года, и примерно с того же времени у меня нет простого и быстрорастворимого ответа (и это тоже хорошо).
У любого человека есть право послать вас нахер. Ультимативное. Чаще всего, реализуется до банальности просто.
Кейсы и сценарии не единственный подход проектирования. И точно не панацея. Можно иначе. Есть инструменты, для которых кейсы не важны, а важно другое.
Специально унылый заголовок, потому что дальше я буду ворчать. Сильно. Метриками и А/Б тестами можно завести разработку в кромешную жопу, зато все при деле.
Думать и переобуваться надо в выделенное для этого время. Сомневаться постфактум, метаться и нудить — не полезно и так делать не надо (можно даже запретить).
Хотел сослаться на концепцию, а интернет её похоже успешно забыл. Быстрорастворимый читкод про анализ и требования (2003)
Две техники (старых как кал мамонта), которые позволяют писать проблематику и требования без лишней херни. Или хотя бы начать, для старта. Аккуратно, внутри лексика 18+.
Чем сложнее система, тем выше внутри нее спрос на наглядность, прозрачность и проверяемость. Это продается, это ценится. Это позволяет принимать бизнесовые решения.
Клиентский секрет сам по себе лежит на клиенте, а значит секретом уже не является. Со всеми вытекающими граблями и практиками. Сразу посмотрим, как сделать правильно.