Ответ
Да, в моей команде был senior-разработчик, который стабильно укладывался в сроки. Его подход я взял на вооружение:
1. Детальное декомпозирование задачи перед оценкой. Он не просто брал задачу "добавить API-метод", а сразу разбивал ее на этапы:
- Проектирование контракта (DTO, схема валидации).
- Реализация в слое Controller/Handler.
- Интеграция с Service и Repository.
- Написание unit- и интеграционных тестов.
- Обновление документации OpenAPI/Swagger.
2. Реалистичная оценка с учетом рисков. Вместо оптимистичной оценки он сразу закладывал буфер (20-30%) на непредвиденные сложности, ревью кода и доработки. Например, если чистая разработка оценивалась в 8 часов, в план ставилось 10.
3. Постоянная коммуникация о прогрессе. Если в процессе возникала проблема, которая могла сорвать срок (например, неочевидная бага в legacy-коде или сложность интеграции), он сразу же сообщал об этом тимлиду, а не пытался геройствовать в одиночку. Это позволяло оперативно перераспределить ресурсы или скорректировать ожидания.
Итог: Его секрет был не в том, чтобы работать быстрее всех, а в предсказуемости. Команда могла точно рассчитывать на результат к обещанному сроку, что сильно упрощало планирование спринтов.
Ответ 18+ 🔞
А, ну это же классика, ёпта! Был у нас в команде один senior-разработчик, который никогда не подводил со сроками. Честно говоря, я с него потом всю свою методологию и спиздил, потому что она реально работала, а не просто для отчёта перед начальством.
1. Детальное декомпозирование задачи перед оценкой. Он не был тем самым мудаком, который смотрит на задачу «добавить API-метод» и говорит «да это же хуй с горы, два часа». Нет, он сразу же её на куски рвал:
- Сначала проектирование контракта — что на вход, что на выход, как валидировать.
- Потом уже лезет в Controller или Handler и пишет.
- Потом тянет всё это в Service и Repository.
- И только ебушки-воробушки, он ещё и тесты пишет! И unit, и интеграционные.
- И в довесок, блядь, документацию для OpenAPI обновит, чтобы потом не прибегали с вопросом «а как этим пользоваться-то?».
2. Реалистичная оценка с учетом рисков. Вот тут его гениальность просто пиздец. Он никогда не давал оптимистичную оценку. Всегда сразу закладывал буфер процентов 20-30 на всякую хуйню: на ревью кода, на доработки, на то, что в процессе вылезет какая-нибудь дичь. Если по его расчётам чистая разработка — 8 часов, то в план он ставил 10. И знаешь что? Он всегда укладывался в эти 10, потому что эта хуйня ВСЕГДА случалась. А другие в 8 не укладывались, потому что надеялись на авось.
3. Постоянная коммуникация о прогрессе. И самое главное — он не был героем-одиночкой. Если в процессе он натыкался на какую-нибудь пиздопроебибну в легаси-коде или понимал, что интеграция с этим старым сервисом займёт овердохуища времени, он не молчал неделю, пытаясь всё сам починить. Нет, он сразу шёл к тимлиду и говорил: «Слушай, тут такая хуйня, сроки могут поехать». И это позволяло или помочь ему, или перераспределить задачи, или просто скорректировать ожидания заказчика. Доверия к нему было — ебать ноль, в хорошем смысле. То есть ноль сюрпризов.
Итог: Весь его секрет был не в том, чтобы быть самым быстрым кодомонстром на диком западе. Нет. Его сила была в предсказуемости. Команда и менеджеры могли на него положиться, как на швейцарские часы. Если он сказал «сделаю к пятнице», значит, к пятнице всё будет готово и протестировано. И из-за этого планирование спринтов превращалось из гадания на кофейной гуще во что-то вменяемое. Вот так-то, мать его.