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

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

О, я наконец я нашёл эту божественную рекламу
https://youtu.be/VJsp98bgUJ0

Наслаждайтесь))

Интересно, за что тимлид так не любит разработчика. Он же сам должен себя на его месте хорошо представлять

Или это "управление" в голову ударило?..

А вот я не знаю. Может быть тут разница в том, что он из того времени, когда решения делались без ТР, "из головы". Вот и пришло понимание того, что ТР - это просто направление работы. 20% документации, 80% фантазии и предсказаний.

Вот где-то был токой-же момент, про двоих египтян, перевёрнутые вниз остриями пирамиды и инженерию. Про тех, кто не читает ТЗ. =))

Ну вот. Поэтому если компания экономит на РП, чему удивляться)

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

Но любое "пробивание" стоит нервов и беклога.

Мб конечно.

Я наугад сказал про экономию. Не знаю как у вас все организовано.
В целом суть в том, что принимать такие решения должен РП, а не тимлид.

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

You are welcome!)

ммне вообще нравится твои опусы читать

сразу видно аналитика)))

А знаете, что надо делать в таких случаях? Вот сейчас расскажу. =)
1. При понимании того, что вам подкинули песца в задачи (сдвигая планы), первоначально надо резко деградировать производительность (привет йога!). Это действие поможет вам не начать без головы бежать с остальными превозмогая планы, не повредить свою мораль и не иссушить мыслительную выносливость.Надо понимать, что когда в ваш нагруженный процесс работы включается ещё 1, 2 или больше процессов, то надо заново производить их приёмку, оценку и планирование. Иначе вам придётся откуда-то взять время и силы. Обычно этими буферами являются ваше личное время и силы на семью, хобби, отдых. Вы начинаете работать в перегрузке.
2. Выдержите первый удар без напряжения. В этот момент все люди, которые побегут в вас с вопросами - первичны. Не пытайтесь серьёзно работать с основной задачей. Ваша тип задач должен переключиться с задумчивой работы на консультирование и планирование. Сложную работу закидывайте за планирование. Кроме того. из-за разнородности первой волны вопросов будет очень сложно параллельно работать и вы попадёте в ловушку из пункта 1, начав забирать силы и время из буфера.
3. Проведите перепланирование. Снова расставьте приоритеты задачам, примерные сроки (НАВСКИДКУ), уведомите окружающих.
4. Если сдали ваш драфт на растерзание разработке, то не стоит ориентироваться на разработчика и его удобство в плане доработки документа. Надо чётко понять, что в этом случае смешали две фазы (написание ТЗ и разработку, а то ещё и тестирование) и пропустили фазу приёмки (согласования). Т.е. меняете документ как вам надо и пофиг что там разработка делает. Пускай у них горит . быстрее поймут, что так делать не надо. В ином случае, появится дополнительная сложность и вы ещё сильнее затормозите и усложните свою работу.
4. Начинайте декомпозировать песца до простых задач, снова выстраивайте последовательность работы с документом.
5. Следите за тем, чтобы не перенапрягаться в такой работе. Как только возникает перегруз - деградируйте производительность до уровня: "ну я могу вам сосисочек сварить, ничего более сложного".
6. Ограничивайте доступ к себе и старайтесь найти спокойное место и угол, чтобы не торопясь развязать клубок сложностей, декомпозировать его, уложить в поток работ и последовательно обработать.

Вот такие выводы)

В конце хочу сказать, что для решения таких проблем есть два пути:
1. Вы начинаете подключать дополнительные ресурсы и бежать с остальными - именно этого зачастую от вас ждёт ваше начальство (ибо им побоку на ваше состояние и они не особо шарят в том, как можно распределять работы таким образом, чтобы они делались ещё быстрее за счёт нормальных фаз и уменьшения многопоточности). Минусы понятны - повреждение здоровья, морали, нервов, воровство личного времени и сил.
2. Декомпозиция задач, приёмка, выстраивание задач в понятную последовательность выполнения не сложных работ. В этом случае вы защищаете своё здоровье, время и силы, но ваше начальство негодует, т.к. у них планирование короткое, а каждая приёмка с декомпозицией занимает до 30% дополнительного времени к решению средних и больших задач.

В целом и там и там вы никак не выиграете во времени.

Правильное состояние аналитика, когда его завалили кучей задач: