Как научиться декомпозировать задачи?

Переодически может появиться очень крупная задача вида "нужно то не знай что". Мне приходится с ней разбираться и если с первым этапом - конкретизация требований все более-менее понятно, то с дальнейшими действиями все совсем плохо. Сильнее всего это проявляется когда работать нужно в команде и задачи по разработке распределить на группу разработчиков. Ты начинаешь смотреть на задачи и понимаешь, что вот это должно быть сделано после этого, вот это после этого и получается так что каждая задача требует завершения (хотя бы частичного) другой. Распараллелить это никак не получается и приходится говорить что-то типа: ну вот у тебя зависит от него, ты посмотри как у него сделано, поставь заглушки, потом объедините. А совсем попа когда во время разработки понимаешь, что все должно быть не совсем так как ты запроектировал и приходится переделывать.
Дробить задачу еще на более мелкие совсем не охота, да и руководство будет кричать когда уже начнем писать код (разработчики то выделены и сидят без дела).

Собственно вопрос основной вопрос в заголовке. Расскажите ваш опыт. Что вы делаете первым делом и как решаете проблемы с параллельными задачами?
Особенно буду признателен за рекомендации курсов/книг/статей по этой теме.
  • Вопрос задан
  • 566 просмотров
Пригласить эксперта
Ответы на вопрос 5
Adamos
@Adamos
Дробить задачу еще на более мелкие совсем не охота

Ну и зря. Вообще-то технологиям планирования совместной работы уже не первый век, и важнейший этап - как раз выделение тех участков работы, которые критичны для начала работы на других участках, и подтягивание их на диаграмме Ганта как можно раньше, чтобы уменьшить простой. Потом уже менее критичные задачи ложатся на свободные участки и параллелятся относительно друг друга.
Так, например, нас учили делать генплан строительства еще 30 лет назад. До популяризации в РФ всяких там Скрамов и Канбанов.
Ответ написан
@mayton2019
Bigdata Engineer
Переодически может появиться очень крупная задача вида "нужно то не знай что". Мне приходится с ней разбираться и если с первым этапом - конкретизация требований все более-менее понятно, то с дальнейшими действиями все совсем плохо.

Ситуация - знакомая. Во первых это - не задача. Это issue типа investigation. Его результатом должен быть не финальный продукт а просто новый сет issues. Оценивать время можно как угодно. Можно писать 1 день для начала. Все равно никто не сможет оспорить вашу оценку.

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

Это - риски и их просто надо заранее проговорить на митингах. Просто сообщайте заказчику что задача - рисковая и если что-то не так пойдет - то время надо будет сдвинуть.
Ответ написан
Комментировать
hint000
@hint000
у админа три руки
приходится говорить что-то типа: ну вот у тебя зависит от него, ты посмотри как у него сделано, поставь заглушки, потом объедините.
Сначала пишутся все необходимые интерфейсы между кусками задачи. С обсуждением. На это много времени не требуется. Когда интерфейсы зафиксированы (ну как "зафисиксированы", в рабочем порядке никто не запрещает слегка корректировать), то куски можно спокойно разрабатывать независимо. Вроде же это классика. Я бы не сказал "ну вот у тебя зависит от него...", я бы сказал "ваши куски взаимодействуют - значит сразу договаривайтесь, как в точности они взаимодействуют".

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы