Ответ
Сроки устанавливаются коллаборативно, но финальное решение и приоритизация обычно лежат на менеджменте продукта (Product Owner, Project Manager).
Типичный процесс оценки и установки сроков:
- Разработчик дает оценку на реализацию функционала (например, 3 дня).
- QA-инженер добавляет оценку на тестирование и возможные доработки (например, +1 день).
- Команда обсуждает риски и зависимости на планировании (Scrum Planning, Sprint Grooming).
- Product Owner / Менеджер утверждает срок, учитывая:
- Бизнес-приоритеты и roadmap.
- Общую загрузку команды.
- Оценки, данные командой.
Важно: Реалистичные сроки — результат открытого обсуждения. Если оценка команды не совпадает с ожиданиями стейкхолдеров, это должно быть явно озвучено и согласовано до начала работы.
Ответ 18+ 🔞
А, ну это классика, блядь! Сейчас объясню, как у нас тут сроки рождаются, а то многие думают, что они с неба падают, как манна небесная, или из жопы менеджера вываливаются, готовенькие.
Смотри. В теории всё красиво звучит — «коллаборативно», ёпта. На практике это значит: вся братва садится, и начинается цирк.
Первым выходит разработчик, такой важный, почесывает репу: «Ну, этот фич... с одной стороны — хуйня, три кнопки. С другой — там, блядь, чёрт ногу сломит в legacy-коде. Дай-ка мне... три дня». И смотрит на всех умными глазами.
Потом поднимается QA-инженер, хитро так прищуривается: «О, три дня говоришь? Ну-ну, смешной ты человек. А на то, чтобы это говно протестировать, найти баги, которые ты, конечно же, наворочаешь, отправить тебя три раза на доработку и потом ещё раз всё перепроверить — это, считай, +1 день минимум. И то, если повезёт». И уже не три, а четыре, понимаешь?
А потом вся команда начинает «обсуждать риски». Это самый ахуительный этап! Тут всплывает, что «ой, а там же бэкенд-АПИшка от васяна ещё не готова, он в отпуске», «а дизайны, сука, только на бумажной салфетке», «а этот сервис у нас падает раз в неделю, и мы точно в него упрёмся». В общем, волнение ебать, все начинают жестикулировать.
И вот, когда все уже устали и хотят нахуй пойти, встаёт Product Owner или менеджер. Он всё это время молчал, а у него в голове уже горит дедлайн от какого-нибудь высшего начальства, который «вчера». Он смотрит на оценку команды (которая уже раздулась до пяти дней), смотрит в свой roadmap, где эта фича должна была быть сделана «позавчера», и говорит:
«Ребята, вы — молодцы. Очень реалистично оценили. Но бизнес, понимаете ли, требует. Давайте сделаем за два. Вы же справитесь? Мы в вас верим».
И вот тут наступает момент истины, блядь. Либо команда, как один мудак, молча кивает, а потом ночами ебётся с этой хуйней. Либо какой-нибудь смелый говорит: «Ну нахуй. На два дня — это если не тестировать, не дизайнить и забить на все баги. Ты готов подписать, что на прод выпустим сырое говно?».
Короче, суть-то вот в чём: реалистичные сроки — это не когда начальник сказал «надо», а ты ответил «есть». Это когда ты послал его нахуй с его «надо», сел, и вы ВМЕСТЕ придумали, как сделать НОРМАЛЬНО. Если твоя оценка и его ожидания — как хуй и пальто, это надо выяснять ДО того, как ты уже в процессе, а не после, когда у тебя горит проект и волосы дыбом. Иначе будет поздно, и виноват будешь ты, а не его ебаные ожидания. Пиздец и точка.