Комментарии 6
Отличная статья, спасибо!
У меня только один вопрос: а что бы такого почитать про декомпозицию?
Спасибо за интерес!
Не могу посоветовать каких-то конкретных книг, которые были посвящены декомпозиции (либо не знаю, либо декомпозиция в книгах идёт скорее как смежная тема и не раскрывается), но мне как-то попадалась статья на Хабре, которая довольно интересно раскрывает этот вопрос (в комментариях тоже интересно).
Ну или можно почитать что-то более собирательное.
Если кто-нибудь из читателей знает хорошие материалы — пишите в комментариях, тоже буду рад изучить!
Да, классная статья, спасибо! Я сейчас в одиночку иду на очень неопределенную исследовательскую задачу с неясными результатами, но многое из статьи могу сразу начать применять. Главное -- не нервничать)
Отличная статья! Но поразило, что это делал не менеджер, А САМ РАЗРАБОТЧИК. Что делал менеджер???
И конечно, самое главное правило - система должна быть продана в команде, и использоваться всеми без исключения. Если кто-то не следует правилам - страдает вся система.
Спасибо за ваш отзыв и интересный комментарий! Вы подняли очень важные вопросы.
Но поразило, что это делал не менеджер, А САМ РАЗРАБОТЧИК. Что делал менеджер???
Действительно, акцент в статье сделан на действиях разработчика и некоторые моменты могут быть "притянуты за уши". Возможно, создается впечатление, что ответственность (как минимум за анализ) перекладывается на разработчика. К тому же пример выбран не в пользу собирательного образа менеджера :)
С другой стороны в реальности у нас могут быть такие ситуации:
Нет аналитиков: В небольших командах (или где не принято "держать" аналитиков) сотрудники часто берут на себя дополнительные роли (что не обязательно плохо, об этом ниже). Т.е. нет людей, которые могут до начала реализации точно просчитать что и как будет работать и к чему это приведет.
Технический контекст: Когда задача требует глубокого понимания технических деталей, вклад разработчика в анализ и планирование может быть неоценим.
Продуктовое мышление: Поощряется, когда разработчики думают не только о коде, но и о влиянии своей работы на пользователей и бизнес.
Декомпозиция и оценка: Технические нюансы сильно влияют на структуру задачи и время её выполнения. Вряд ли менеджер сможет с высокой точностью выполнить это без мнения разработчика.
Это не означает, что менеджер не выполняет свою работу. Скорее, это пример тесного сотрудничества, где каждый вносит свой вклад согласно своим сильным сторонам.
И конечно, самое главное правило - система должна быть продана в команде, и использоваться всеми без исключения. Если кто-то не следует правилам - страдает вся система.
Полностью согласен. Эффективность любой системы зависит от последовательности её применения всей командой. При этом даже если не все готовы принять такой подход целиком, отдельный разработчик всё равно может извлечь пользу и упростить разработку на своем уровне, применяя эти принципы в своей работе.
Спасибо за ваше мнение! Буду рад продолжить обсуждение, если у вас есть дополнительные мысли по этой теме.
P.S. да, сперва решил ответ подготовить, а потом уже одобрить комментарий) Поэтому не обращайте внимания на короткое время ответа.
Зачем фронтенд-разработчику Ивану информация про вовлеченность пользователей и про бизнесовые метрики?
Анализ, декомпозиция и оценка задач: от теории к практике