Декомпозиция задачи или почему добавить одно поле это приключение НЕ на одну минуту?

Допустим, вы пишете приложение (как неожиданно) и вам поступила задача отобразить номер телефона в профиле пользователя. Менеджер спросит, сколько это займёт, ожидая услышать ответ сразу же. Но вы отвечаете, что нужно подумать, и ваш менеджер пассивно-агрессивно спрашивает, что тут думать — это одно же поле.

«Вошли и вышли, приключение на 20 минут, Морти!»

К сожалению, зачастую это не так. Особенно если данные для этого поля не хранятся локально.

Во-первых, требующий немедленного ответа менеджер — не самый приятный вариант. Профессионалы своего дела понимают, почему иногда даже на такой, казалось бы, очевидный вопрос может потребоваться время.

Во-вторых, причиной этого может быть непонимание этапов, которые требуется пройти разработчику/команде при реализации.

При постановке вопроса из примера мы должны перечислить следующие пункты:

— Реализовано ли это на сервере? Поверьте, зачастую бывают сложности коммуникации и загруженность у разных команд, парадоксально, разная. От ответа на этот вопрос оценка может взлететь по очевидной причине, ведь если фича не реализована, то пока что в прод выкатить её точно не получится.

— Насколько сложно будет изменить структуру в БД? Нужна ли миграция? Тут поможет опыт прошлых апдейтов.

— Нужна ли локализация этого поля? Заглушки, например. Здесь мы видим то, что как и с вопросом про реализацию на сервере не всё зависит от нас.

— Нужна ли валидация этого номера телефона? Нужны ли нам регулярки, может ли номер содержать буквы, например? Сколько может быть символов? Возможно, вы и не удивитесь, но буквы в номерах возможны как минимум в рекламе.

— Какой шрифт, какой цвет, как оформить вообще? Нужна ли анимация при переводе фокуса ввода?

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

В списке выше на самом деле можно выделить сразу два вида декомпозиции:

Вертикальная: сервер, перевод от команды переводчиков, реализация на клиенте.

И горизональная для приложения: подзадача про валидацию, про оформление, про хранение.

Разработчик с опытом может выдать ответ быстро, если он 1 000 раз проводил подобную декомпозицию. Но вот ответ от него может различаться от ответа джуниора, готового лезть на амбразуру сразу же.

Декомпозиция нужна, чтобы:

— Понять последовательность выполнения задач.
— Оценить сроки.
— Упростить процесс тестирования.
— Помочь расставить приоритеты. В спринте, но по-хорошему, изначально в бэклоге.

Два небольших вывода:

1️⃣ Мы работаем на бизнес. Поэтому мы должны понимать, почему менеджер может быть недоволен медленной оценкой.

2️⃣ Хочется верить, что этот пост прочтут не только разработчики, но и проект-менеджеры. Профессионалы улыбнутся и скажут, что так и есть. Но те, кто начинает управлять командами — пожалуйста, прочтите этот пост ещё раз.

Специально для @iOS Dev