#вопрос Взял задачу, назначил срок 4–5 дней. Сделал за 4, отпр | FEDOR BORSHEV

#вопрос Взял задачу, назначил срок 4–5 дней. Сделал за 4, отправил на ревью, и выяснилось, что неверно понял задачу. Теперь задача требует ещё 4 дня, то есть в два раза больше.

Всегда ли возможно сразу сказать, сколько времени займет задача, учитывая такие моменты? Какие другие ошибки я сделал?
——————

Я вижу тут две ошибки. Во-первых, вы даже будучи уверенными в задаче, когда оценивали её в первый раз, вы ошиблись как минимум в два раза. Вы оценили задачу в 5 дней, а отправили на ревью только через 4, то есть практически в конце срока. А после ревью ещё наверняка будет QA, релизный поезд, служба безопасности или ещё чего пострашнее. И даже если все эти препятствия работают чётко, дня 4 они добавят, это уж точно. Получится уже 8, и это в лучшем случае.

Во-вторых, вы нарушили принцип «исполнитель понимает задачу». Этот принцип хорошо сформулировали в Бюро Горбунова, гляньте. Идея простая — убеждаться в том, что ваш код решает именно ту проблему, которая стоит у бизнеса — это ваша задача. Не менеджера, который формулировал таску, не ревьюера\QA, который её проверяет — ваша. В соответствии с этим принципом нужно было запланировать MVP — может быть прототип решения, или хотя бы документ, где вы своими словами описываете задачу в том виде, как вы её поняли (гляньте «понимание задачи» по ссылке выше). MVP — это такая же часть работы, как и ревью, на неё нужно точно так же закладывать время при планировании. Забирая задачу на 4–5 дней, я бы как минимум взял один день на MVP, согласовал бы его с бизнесом, и только потом называл срок на оставшуюся часть задачи. Так вы никого не подведёте — все понимают, что предсказуемые сроки по задаче вполне стоят небольшого ожидания прототипа.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me