Ну например бизнес аналитику и манагеру показалось что в первые месяцы имплементации приложения вдруг понадобилась иерархическая структура организации ну т.е. главное предприятие и филиалы  с различными виджетами которые это отображают, было вложено много ресурсов на имплементацию данного функционала, но потом по мере углубления знаний в этой предметной области оказалось что нет ни одного юзкейса где необходим этот функционал, более того как еще позже оказалось что и сущности организации тоже не нужны, а нужны только их департамент ну или подразделения.
В остальных нужно погружаться в предметку.
В общем если провести черту  то можно сказать что просчеты в анализе происходили из-за того что выдавалось желаемое за действительное, а это в свою очередь возникало имхо из-за плохой коммуникации со специалистами в предметной области (или его отсутствием), ну и вообще отсутствие должной квалификации у аналитиков что бы распознать эту проблему.

так, это а это для чего ?

По ТЗ сейчас никто не работает, тем более если брать стартап и проекты с ноля просто по тому что их некому писать, грубо говоря в момент начала имплементации нет еще четкого видения, это все делается итерациона, но конечно вначале всегда есть некая фаза сбора требований.

Вот это понимание и дает эффект, описанный выше.


Предметная область есть всегда.

Процессы, происходяшие над ней есть всегда. Мало/много — они есть.

И вот тут бизнес-аналитик валит и уступает место кому-то, кто ux строит для юзера, а не для бизнес-аналитика.

Я с вами согласен что с точки зрения разработки хочется все упорядочить и это будет походит на вотерфол, ну т.е. то что вы и предлагаете. Это значит то что пока предидущая фаза не закончилась то следующая не начинается. Написание юзкейсов -> работа дизайнера -> работа архитектора -> имплементация. И эта схема вполне рабочая, но она целесообразна для довольно сложных, наукоемких проектов где цена ошибки высока. Заказчик как правило это понимает и дает на это время.
Но в случае с обычными проектами, стартами важна скорость выхода на рынок и гибкость поэтому приходится сжимать эти процессы и вводить итеративность что быть гибкими.

Я с вами согласен что с точки зрения разработки хочется все упорядочить и это будет походит на вотерфол, ну т.е. то что вы и предлагаете. Это значит то что пока предидущая фаза не закончилась то следующая не начинается. Написание юзкейсов -> работа дизайнера -> работа архитектора -> имплементация. И эта схема вполне рабочая, но она целесообразна для довольно сложных, наукоемких проектов где цена ошибки высока. Заказчик как правило это понимает и дает на это время.
Но в случае с обычными проектами, стартами важна скорость выхода на рынок и гибкость поэтому приходится сжимать эти процессы и вводить итеративность что быть гибкими.

При чем тут водопад?

Вы сейчас о водопаде как о природе или как о процессе ? просто что бы понимать

Друзья, мы в сообществе FBO, собираем закрытую онлайн тусовку в субботу в 15:00. На тему Edtech. Только продакты реальных компаний в сфере онлайн образования. Если кто из этой сферы и кому интересно присоединиться, пишите.

Половина третьего... предлагаю проголосовать. Мне не принципиально.

В общем я про это https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D0%BA%D0%B0%D0%B4%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C
Что бы полностью подготовить тот документ о котором вы повествует нужна именно модель водопада (каскадная модель)

Ну например бизнес аналитику и манагеру показалось что в первые месяцы имплементации приложения вдруг понадобилась иерархическая структура организации ну т.е. главное предприятие и филиалы  с различными виджетами которые это отображают, было вложено много ресурсов на имплементацию данного функционала, но потом по мере углубления знаний в этой предметной области оказалось что нет ни одного юзкейса где необходим этот функционал, более того как еще позже оказалось что и сущности организации тоже не нужны, а нужны только их департамент ну или подразделения.
В остальных нужно погружаться в предметку.
В общем если провести черту  то можно сказать что просчеты в анализе происходили из-за того что выдавалось желаемое за действительное, а это в свою очередь возникало имхо из-за плохой коммуникации со специалистами в предметной области (или его отсутствием), ну и вообще отсутствие должной квалификации у аналитиков что бы распознать эту проблему.

нуу, технически, не совсем. в те времена некоторые были избалованы такой штукой, которая называлась azalo. Однако, снова попробую... первые шаги. предметная область. Вот они важны "Очень!" на какой бы скорости вы ни вытались работать с требованиями.

Если у вас есть опыт разработки то вы должны понимать что изучить какую то предметную область в сжатый срок это очень сложная задача, это проблема хорошо освещается в работах про DDD. Опять же познание предметной области это процесс также итерационный.
Если проект будет дружно ждать пока заинтересованные люди изучать предметную область до той степени в которой будет понятно как её автоматизировать то мы так и не сдвинемся с места, либо это будет недопустимо медленно.