Как дать максимально хреновую оценку задаче

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

Топ 10 советов

• Не обращай внимание на существующую кодовую базу, такой профессионал как ты всегда сможет решить задачу в любой кодовой базе. Ведь ты, дружище, добавлял новый экран в свой пет проект за пару часов? И я добавлял, так что на боевом проекте все будет также.
• 
• Ни в коем случае не советуйся с коллегами перед оценкой. Что они могут знать о твоей задаче, им бы только пообсуждать, как бинарное дерево ревертнуть. Ты лучше знаешь как нашлепать формочек для нового экрана и сколько времени это займет.
• Запомни: никакого дополнительного времени на прохождение код ревью. Твой великий код должен всем понравиться с первого раза. Иначе ведь и быть не может.
• Поддавайся уговорам снизить эстимейт, надо ведь всегда быть дружелюбным, чтобы все вокруг были довольны твоей оценкой. Даже если просят вместо 40 часов сделать за 8 все равно соглашайся, авось прокатит. Зато менеджер доволен.
• Всегда исходи из того, что будешь писать грязный код зато быстро, ну а что потом разберешься со сложностями поддержки плохого кода, зато менеджер доволен твоим перформансом и оценками.
• Никогда не слушай коллег с других платформ, что эти айосники могут знать о твоем великом андроиде. Или что эти выскочки с мобилок, которые умеют только формы шлепать, могут знать про тонны логики на твоем великолепном бэкенде? Их слушать незачем.
• Запомни: крутые парни или девочки не переспрашивают, если тебе непонятно и половины того, что от тебя хотят, просто тыкни пальцем в небо и дай оценку, а там уже разберешься. Зачем тратить свое драгоценное время на какие-то разговоры и выяснения, ты поэт, твое дело творить !
• Не думай об интеграции. Разве на то, чтобы провести интеграцию мобилок с бэкендом нужно время? Да не, бред какой-то.
• На ручное тестирование совсем не уходит время. Да и твой великолепный код не нужно тестировать ручками, он должен великолепно работать без крашей и проблем.
• Будь смелым, никогда не делай оценку с запасом, ведь всегда есть возможность и на выходных поработать, а выгорают только слабаки. Такому крутому перцу как ты это не грозит.

А теперь к полезным советам

Относиться ко всему с чувством юмора это всегда хорошо, но теперь давай с тобой разберем каждый пункт, только в разрезе уже хороших советов:

• Всегда следует давать оценку, исходя из существующей кодовой базы.
  Исключение составляют те случаи когда проект начинается с нуля, но даже в таком варианте следует учитывать, что уйдет время на продумывание архитектуры и путей взаимодействия сущностей в системе. Будет здорово если ты перед каждой оценкой задачи будешь открывать код и смотреть, что будет модифицироваться и какие проблемы возможны.
• Если в оценке есть сомнения то лучше посоветоваться с коллегами перед тем как выносить вердикт. Это хорошая практика даже если у тебя нет ни капли сомнения в своем эстимейте. На случай если советоваться не с кем, то будет круто даже если ты поищешь совета в сообществе, учитывая NDA своего проекта. Мнение со стороны может пролить свет на какие-то нюансы, которые ты сам не видишь.
• В свой эстимейт всегда нужно закладывать время, которое уйдет на прохождение код ревью. Это касается проектов, на которых есть практика проверки кода коллег. Количество времени, которое стоит заложить сильно зависит от проекта и от того будешь ты дробить свои пул реквесты на небольшие или выливать все сразу скопом. Зачастую на прохождение ревью может уйти больше времени, чем ушло на написание самой фичи. Старайся дробить свои пул реквесты на более мелкие.
• НИКОГДА НЕ поддавайся уговорам снизить эстимейт, у тебя есть уверенность в своей оценке, а она будет, если ты следуешь шагам, описанным выше. Менеджеры всегда хотят задачу побыстрее и подешевле, но это не коррелирует с реальным миром. Если ты поддашься, снизишь оценку, а потом не попадешь в нее, то виноват будешь только ты.
• Ты как ответственный специалист должен думать о том, что писать чистый код иногда медленнее чем грязный, а следовательно стоит об этом задумываться при эстимейте.
• Бывает полезно прислушаться к мнению коллег с соседних платформ. Конечно у каждой платформы своя специфика. IOS определенно отличается от Android, но зачастую ваша система имеет одинаковую бизнес логику и тут и там и шаринг мнений помогает увидеть дыры в этой логике и что может пойти не так.
• Если у тебя есть вопросы или что-то не понятно всегда переспрашивай. В требованиях могут быть шерховатости, что-то невозможно реализовать в принципе на твоей платформе. Где-то есть добавление, которое ломает всю логику системы Не ленись тратить время на то, чтобы прояснить все вопросы, это избавит тебя от большой боли в жопе голове.
• Всегда думай о том, что на интеграцию с серваком или мобилками уходит время и возможно придется, что-то менять. Этот пункт не самый значительный из всех, но все же стоит задумываться и об этом.
• На ручное тестирование УХОДИТ время. Необходимо держать в уме возможные баги, и время, которое будет потрачено на них. К сожалению, ошибки и баги всегда идут рука об руку с каждой новой написанной строчкой кода.
• Есть поговорка: запас оценку бережет. Всегда следует думать о рисках, которые мы никак не предусмотрим, например:
  
  
  1. Сразу после обновления ПО у тебя не получается начать работу
  2. Сделал обновление среды разработки и перестал компилироваться проект
  3. Метеорит упал на офис
  
  
  Именно для этого следует подстелить себе немного соломки на случай если придется падать.
  Как-то я ошибся с оценкой ровно в 10 раз и вынес из этого несколько уроков, надеюсь для кого-то кроме меня это тоже будет полезно.