Как решить проблему оценки задачи
Дать точный срок выполнения задачи в разработки практически нереально.
Обычный вопрос менеджера, сколько времени займет задача?
Начинающего разработчика такой вопрос вводит в ступор.
У меня на старте карьеры этот вопросы вызывал волнение, панику и желание «не ударить в грязь лицом».
Ведь никто не хочет казаться глупым и говорить «не знаю».
А жаль.
Если бы я не боялся, то многие задачи сделались бы в итоге быстрее. И бизнесу было бы лучше.
Как вообще подходить к оценке задач.
Задачи могут быть разные. И отличие в уровне неопределенности.
1. Высокий уровень неопределенности.
Это когда ты не понимаешь, какой именно код нужно написать, как задача разложится на уровне данных, можно ли переиспользовать существующие компоненты системы или нужно писать новые, как будет выглядеть взаимодействие между этими компонентами
2. Средний уровень неопределенности
Решение «на кончиках пальцев». Ты более менее понимаешь, что нужно будет сделать. Вопрос скорее в деталях.
Как назвать методы api. Как разложить решение на файловой структуре. Создать 1 класс или декомпозировать на более маленькие. Точные названия полей в БД.
Но концептуально по основным компонентам и их связям у тебя нет.
3. Низкий уровень неопределенности
Понятно «что» делаем и детально понятно «как» делаем.
Такой уровень достигается, когда проделана исследовательская работа и есть артефакты на выходе.
Артефакты - это, например, архитектурная схема. Описание таблиц в БД. Контракт api описан в swagger. Есть схема архитектуры модулей на фронте и беке. Ты очень хорошо понимаешь, какие компоненты нужны и как они взаимодействуют друг с другом.
По факту, тебе все понятно и нужно только механически закодить.
Таким образом оценка задач сводится к сокращению уровня неопределенности.
Если перед тобой задача с высоким уровнем неопределенности, то скажи сколько дней (обычно 1-3) у тебя займет, чтобы погрузиться в задачу и свести неопределенности к среднему уровню.
После 1-3 дня вернись к менеджеру с более точной оценкой.
Поверь, менеджеру будет ок, если ты возьмешь 1-3 на подумать. Это лучше, чем дать неточную оценку в 1 неделю, а потом потратить 1 месяц.
Когда ты свел уровень неопределенности к среднему, то нужно декомпозировать задачу на набор тасок с низким уровнем неопределенности. Прикинуть трудозатраты и если есть отклонение от названного срока, то сразу сообщить менеджеру, показав реальный объем работы.
Урок тут такой. Называя оценку ты даешь прогноз, а не обязательство. Это важно коммуницировать. По мере снятия неопределенность прогноз может корректироваться в большую или меньшую сторону.
Главное не стрессуй. Это рутина профессионального разработчика. Нам за это и платят, что мы снимаем техническую неопределенность и реализуем.
Дать точный срок выполнения задачи в разработки практически нереально.
Обычный вопрос менеджера, сколько времени займет задача?
Начинающего разработчика такой вопрос вводит в ступор.
У меня на старте карьеры этот вопросы вызывал волнение, панику и желание «не ударить в грязь лицом».
Ведь никто не хочет казаться глупым и говорить «не знаю».
А жаль.
Если бы я не боялся, то многие задачи сделались бы в итоге быстрее. И бизнесу было бы лучше.
Как вообще подходить к оценке задач.
Задачи могут быть разные. И отличие в уровне неопределенности.
1. Высокий уровень неопределенности.
Это когда ты не понимаешь, какой именно код нужно написать, как задача разложится на уровне данных, можно ли переиспользовать существующие компоненты системы или нужно писать новые, как будет выглядеть взаимодействие между этими компонентами
2. Средний уровень неопределенности
Решение «на кончиках пальцев». Ты более менее понимаешь, что нужно будет сделать. Вопрос скорее в деталях.
Как назвать методы api. Как разложить решение на файловой структуре. Создать 1 класс или декомпозировать на более маленькие. Точные названия полей в БД.
Но концептуально по основным компонентам и их связям у тебя нет.
3. Низкий уровень неопределенности
Понятно «что» делаем и детально понятно «как» делаем.
Такой уровень достигается, когда проделана исследовательская работа и есть артефакты на выходе.
Артефакты - это, например, архитектурная схема. Описание таблиц в БД. Контракт api описан в swagger. Есть схема архитектуры модулей на фронте и беке. Ты очень хорошо понимаешь, какие компоненты нужны и как они взаимодействуют друг с другом.
По факту, тебе все понятно и нужно только механически закодить.
Таким образом оценка задач сводится к сокращению уровня неопределенности.
Если перед тобой задача с высоким уровнем неопределенности, то скажи сколько дней (обычно 1-3) у тебя займет, чтобы погрузиться в задачу и свести неопределенности к среднему уровню.
После 1-3 дня вернись к менеджеру с более точной оценкой.
Поверь, менеджеру будет ок, если ты возьмешь 1-3 на подумать. Это лучше, чем дать неточную оценку в 1 неделю, а потом потратить 1 месяц.
Когда ты свел уровень неопределенности к среднему, то нужно декомпозировать задачу на набор тасок с низким уровнем неопределенности. Прикинуть трудозатраты и если есть отклонение от названного срока, то сразу сообщить менеджеру, показав реальный объем работы.
Урок тут такой. Называя оценку ты даешь прогноз, а не обязательство. Это важно коммуницировать. По мере снятия неопределенность прогноз может корректироваться в большую или меньшую сторону.
Главное не стрессуй. Это рутина профессионального разработчика. Нам за это и платят, что мы снимаем техническую неопределенность и реализуем.