в конечном итоге все по этой схеме делается) вопрос мастабов) где-то водопад, тз на 200 страниц, месяц на планирование, месяц на анализ, 2 месяца на дизайн, пол года на разработку, пол года на тестирование. потом впрод)

а можно эджайл, и по 3 релиза впрод в день)

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

масштабы могут максимум влиять на управление бюджетом и хайринг людей. потому кросфункциональные команды все еще не повсеместно используются. Куда проще с точки зрения найма иметь отдел QA с тимлидом или там отдел разработки с каким-нибудь отдельным менеджером

все в комуникации и общее понимание проблемы упирается. вводя стадии ты на каждой стадии увеличиваешь scope creep (потому что люди так устроены - больше думаешь над проблемой больше проблем придумываешь). Больше стадий больше теряется информации между стадиями.

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

это только про аналитику) а потом эти звездочки отправляют в виде тз в разработку - а на выходе получается какая-нибудь хрень другая)

с другой стороны, не очень охота сидеть и слушать разговоры бизнеса с аналитиками ниочем часами в день. хочется код писать.

нужен некий баланс, совсем разделенности быть не должно, но и нельзя вообще всех за один стол. вот найти правильный расклад - тоже та еще задача.

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

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

Смысл в том что бы попытаться на основании информации либо принять решение какие минимальные изменения надо внедрить что бы либо получить профит либо получить доп инфу для принятия решений. Когда фичи месяцами обсуждают это обычно приводит к тому что они все больше и больше обрастают ненужными деталями.

для этого у всех участников беседы должен быть тот самый shared understanding проблемы про который все эти "аджайл коучи" (которые не шарлатаны) говорят.

да, надо зафигачить что-нибудь для начала. потом итеративно менять, пока не устроит всех.

продумывать все в деталях - пустая трата времени. все равно возникнет куча нюансов и проблем на других стадиях.

не обязательно даже фигачить - разработчик может предложить решение которое можно запилить и с дизайнером накидать прототип какой (кликабельные картинки) - что-то что можно сделать за час и провалидировать с какой-то таргет группой. не все проблемы надо решать написанием софта

ну короч, это все дико интересно и в большинстве компаний отделы и KPI по отделам)

лучший код это который не написан))

идеальный проект: кода ноль, фич бесконечно)

хороший дизайнер рисует больше больше мокапов. хороший разработчик закрывает больше тасок. хороший qa находит больше багов) Это ли не красота)