Бизнес любит вопрос "Когда?". По этому вопрос не про трекеры

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

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

прочитал и заплакал (((

это бизнесу надо плакать, что не думает раньше

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

Всё, на самом деле, намного прозаичнее. Просто в абсолютном большинстве случаев над каждым таким посылатором, который искренне верит, что разработка (и тестирование) такое непредсказуемое, что нельзя давать никаких конкретных оценок, стоит условный техлид, ЦТО или хэд оф что-нибудь там, который транслирует бизнесу нормальные и понятные эстимейты, вместе со всей остальной business-oriented инфой. Потому что этот условный ЦТО\техлид\whatever уже осознал, что платят зарплату всему отделу не за написание кода или его тестирование, а за решение бизнес проблем.

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

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

Должны понимать)) В итоге таких менеджеры просто не понимают разработку, приходят на продукт и начинают думать, что за 1 месяц образно можно поменять модель монетизации. Или куча других моментов, не осозновая риски.

Конкретно может сказать команда, но за частую умные менджеры, который не понимают разработку, считают что это время преувеличено)

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

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

Если менеджеры не должны ничего понимать, то они не должны и ничего получить. Практический случай. 10 лет назад был напилен функционал который преобразует pdf файлы в текст. При проектировании первоначального функционала максимальный размер pdf файла считался 3 мегабайта. Подобрали набор компонентов, для того типа и структуры файлов (pdf-ки они очень разные бывают) и с теми размерами оно работало. Проходит 10 лет. Новые менеджеры захотели чтобы на похожем стеке и компоненте преобразовывались pdf файлы других типов и структуры, с размером 30 мб, 60 мб, 100 мб, а ещё лучше 1 гб (да, можно сделать пдфку и на 450 мб, и на 600+ , и некоторые регулярно такие делают). Конкретных сроков при этом им дать просто нельзя. То что хорошо работало на 3 мб , на 30 мб запросто может закрэшиться, уже не говоря про бОльшие размеры. Всё будет эксперименты, и экспериментов будет много. При экспериментах результат не гарантируется.

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

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

интеграция с частным провайдером для имплементации данных при оценке бизнес-задач - вполне крупная задача, например. Не было ни ТЗ, ни изученной доки, только бизнес-запрос о том, что мы должны получить на выходе. Две недели на исследование в связке аналитик+сеньор разраб и тз на фичу было готово и было ясно, откуда что и как тянуть и как мутировать под наши нужды

Если у вас получилось провести все нужные вам эксперименты и были под рукой все нужные данные — отлично. Но так везёт не всем и не всегда.