Или «Как меньше сосать на оценках».

Основы

  1. Всем плевать на оценки.
  2. Нет ничего, что могло бы сделать вас хорошим оценщиком. Скорее, есть еще куча вещей, на которые нужно обратить внимание, и которые в среднем сделают хорошую оценку.
  3. Почему в среднем? Потому что природа оценок состоит в том, чтобы придумать число на основе частичных данных (единственный способ полностью узнать объем задачи — это реализовать ее). Так что у вас всегда будут случаи, когда вы ошиблись. Но в среднем вы должны стать лучше в этом.

Разделение задач

Легче правильно оценить несколько задач (ошибки выровняются сами собой), чем оценить одну большую задачу. Так что если у вас есть большая задача — разбейте ее на более мелкие задачи.

Саморефлексия

Если вы постоянно занижаете оценку, примите это во внимание. Добавьте 30% ко всем своим оценкам и продолжайте оценивать себя.

Наличие хороших требований является ключевым

Большинство действительно плохих, на несколько порядков, ошибок в оценке происходят из-за плохих требований.

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

И вот так ваши оценки уже не актуальны.

А как насчет возможности сменить пароль? А восстановить забытый пароль?

Решение — не принимайте требования как данность и не думайте, что тот, кто дал вам требования (будь то клиент, менеджер по продукту или кто-то еще), действительно точно знает, чего хочет.

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

Это не просто код

Еще одна распространенная ошибка — думать только о времени разработки. Всегда учитывайте следующее:

  1. Время разработать решение. Неважно, каков процесс проектирования, где вы работаете. Независимо от того, пишете ли вы дизайн-документ или нет, проверяется ли дизайн или нет, является ли это просто чем-то, о чем вы думаете в своей голове. Это всегда требует времени.
  2. Время протестировать ваш код. Я не говорю о QA. Как только вы начинаете писать код, вы всегда тестируете его, чтобы убедиться, что он хотя бы работает на вашей машине. И это иногда менее тривиально, чем ожидалось. В примере с входом в систему вам нужно подождать, пока бэкэнд-разработчик разработает API для входа в систему, вам нужен работающий сервер с обновленной базой данных для тестирования вашего кода. Все эти вещи требуют времени.
  3. Пришло время проверить и исправить ошибки. Как только вы закончите разработку, QA обнаружит ошибки в вашем коде, и вам нужно будет их исправить, повторно опубликовать свой код, и цикл начнется снова. Не забудьте добавить время на исправление ошибок.

Время разработки против. Календарное время

Поймите разницу между временем разработки, календарным временем и временем готовности к производству.

Каждая метрика важна для кого-то другого.

Время разработки – это сколько времени вы действительно тратите на работу над функцией. Это дизайн + время реализации + исправление ошибок. Иногда у вас будет много пробелов (возможно, вам нужно подождать, пока бэкенд-команда реализует свою сторону, может быть, QA перегружен и протестирует вашу фичу только на следующей неделе). Обычно это важно только как инструмент для оценки календарного времени.

Календарное время — когда функция будет готова?

Если на кодирование уйдет 4 дня, а на этой неделе вы планируете взять отпуск, когда он будет готов? И, может быть, у QA или backend-команды другие графики? Обычно менеджер проекта берет ваши оценки времени разработки, а также все остальные оценки и графики и должен сообщить, когда функция будет готова.

Готово к работе — даже если функция закодирована, протестирована и исправлены ошибки, она не всегда попадает в рабочую среду. У вас непрерывная интеграция или вы регулярно развертываете? Есть ли какие-либо другие тесты, которые необходимо выполнить перед развертыванием в рабочей среде? Когда бэкенд-код попадет в производство?

Как на самом деле оценить

Просмотрите соответствующий код перед оценкой. Не просто колдуйте количество дней, исходя из того, что, по вашему мнению, это займет. Если вам нужно реализовать логин — просмотрите соответствующий код:

  1. Что нужно будет изменить в системе навигации?
  2. Как вы будете хранить токен?
  3. Как токен будет доступен для всего остального кода?
  4. Какие еще места в коде нужно изменить из-за логина?

Вам не нужно делать полный дизайн, но вам нужно попытаться найти более сложные части, места, где инфраструктура должна быть изменена, где другие функции конфликтуют с новой функцией и в целом, пройти большую часть поток функции. Таким образом, вы получите гораздо лучшее представление о масштабе задачи.

Оценка – это непрерывный процесс

После того, как вы оценили все задачи и приступили к работе, работа по оценке не выполняется.

Вам нужно постоянно проверять свой прогресс в сравнении с вашими оценками и понимать, где вы находитесь.

При необходимости — пересмотрите свои оценки и обновите всех, кто имеет отношение к делу. Это может быть немного неловко — вы практически признаете, что ошиблись. Но лучше знать заранее, чтобы позволить другим заинтересованным сторонам подготовиться и приспособиться к новым оценкам.

Краткое содержание

Всем плевать на оценки. Можно меньше сосать. Принять это