Во-первых, слово "не охота" не совместим с уровнем "мастер своего дела". Возможно, потому и начальство кричит... Как правило, когда процесс разработки выстроен и понятен всем заинтересованным лицам, крика значительно меньше, и разработчики появляются тоже в соответствии с планом, не раньше.
Во-вторых, план - это живой постоянно изменяющийся инструмент руководителей, причём с разных сторон. Заказчик/подрядчик/субподрядчик/ещё кто-то. Если план понятный и "живой", постоянно актуализируемый, то кричать никто не будет - времени нет, надо свои задачи всем делать. А вот если план делают "для галочки", то крика всегда много.
В-третьих, распараллелить нельзя только жёстко последовательные задачи. Причина - либо технологическая (нельзя данные залить, пока база не создана), либо ограничения ресурсов (дядя Ваня зальёт данные, когда ему компьютер настроят). Всё остальное решается декомпозицией задач с получением понятных промежуточных результатов.
SMART ваше всё.
В-четвёртых, да, план должен быть основан на принятых технических решениях. Иногда эти решения при реализации (и даже позже!) признаются неверными, и приходится перепроектировать систему, и тогда нужно менять план работ. Это нормально и даже неизбежно, особенно для сложных систем. Но тут уже в плане нужно предусматривать работы по управлению рисками, а в самой системе надо предусматривать такие решения, которые позволят изолировать проблемные места и не допустить, чтобы ошибки проектирования или изменения требований не привели к слишком высоким затратам.
Итого, что крик стоит, и что разработчики ждут - это прямые последствия ошибок планирования и отношения к плану. Не ошибается тот, кто ничего не делает. Вы хорошо знаете аналитику, поэтому с детализацией требований вопросов нет. Но надо развиваться в технологиях, в особенностях процессов разработки, в особенностях управления проектом. Тогда планы будут более реалистичными. Но ещё надо перестать смотреть на план как одну из стадий "водопада". План меняется всё время, планирование продолжается от начала и до конца проекта минимум, а чаще - в течение всего жизненного цикла системы. Тогда и нервы у всех участников работ лишний раз никто не полоскает.
И ещё про детализацию. Задача длительностью 4 часа сильно отличается от задачи длительностью 5 часов. Потому что первую задачу можно выполнить, не отвлекаясь, один раз "войдя в творческий поток". А задачу длиннее 4 часов исполнитель без отвлечений не выполнит никогда (в смысле 95% случаев, остальные 5% - тоже с разрывом "потока" и исключительно на своей самодисциплине). Итого, 5-часовая задача сразу превращается в 6-8 часовую. Фокус-фактор выше 65% не бывает. Так что декомпозируйте задачи так, чтобы они реально были исполнимыми в указанные сроки.
