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

    image

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

    Топ 10 советов


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

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


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

    image

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

      1. Сразу после обновления ПО у тебя не получается начать работу
      2. Сделал обновление среды разработки и перестал компилироваться проект
      3. Метеорит упал на офис

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

    Комментарии 15

      0
      Ох, это неловкое молчание коллег, когда даешь адекватную, как считаешь, оценку, а потом тебя ненавязчивыми вопросами уламывают её снизить, хотя делать-то тебе, а не им.
        0
        Главное не поддаваться, если оценка действительно адекватная)
        0
        А на аватарке у автора есть руки?
          0
          руки-скриптухи)))
          0
          Работая в одной компании, где очень любили, когда задачи выполняются в срок, но очень не любили твои отказы, когда ты занят решением задачи, а тебе приносят другую, я выработал для себя золотое правило, оцени сроки и умножь их на 3. Всегда успевал, даже с учётом наваливающихся дополнительных задач, всегда молодец, всегда в срок или раньше. С тех пор прошло почти 5 лет, а способ оценки сроков у меня так и не изменился
            +1
            Можете подробнее расказать о той части, которая идет до умножения на 3?
            Тоже хочу всегда в срок успевать
              0
              Тут всё зависит от конкретики. Руководствуясь опытом и зная кодовую базу проекта обычно безошибочно понимаю сколько надо на решение той или иной задачи. Но если оценить сходу не получается, то беру время на оценку. Бью задачу на максимально минимальные подзадачи, которые могу точно оценить руководствуясь опытом, в сторону откладываю то, что оценить не получается даже после деления. После пытаюсь накидать по-быстрому прототип тех подзадач которые оценить не удаётся, чтобы появилось хоть какое-то понимание объёмов. Ну а дальше складываю, умножаю, озвучиваю
              0
              Прикол. Я всегда на 2 умножаю, и вроде работает)
              0
              Как ваш способ работает на больших задачах?
              К примеру Вы оценили задачу в месяц и говорите что будете делать её 3 месяца?
              Насколько ваш подход работает на длительных задачах?
                0
                Ну, большую задачу лучше всего декомпозировать до такой степени, чтобы оценка выходила в районе одной, максимум двух недель. Лучше всего когда задача такого размера, что на нее уходит меньше рабочей недели.
              0
              Пусть манагер сам оценивает задачи — нафиг он еще нужен. А разрабы корректируют — и все
                0
                А как манагер может оценить чисто технические вещи?
                0
                Меня часто спрашивают:
                Почему это нормально, что на прохождение ревью может уйти в 2 раза больше времени чем на написание кода? Может быть ли это нормально для старичков проекта? Почему? Или сколько времени закладывать на исправление выявленных багов? Почему так много? что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия?
                Что вы отвечаете на такие вопросы?
                  0
                  Почему это нормально, что на прохождение ревью может уйти в 2 раза больше времени чем на написание кода?
                  — Это нормально, так как на проекте может быть несколько разработчиков и каждый из них может оставить свое замечание к вашему пул реквесту, которое придется либо оспаривать, либо исправлять.
                  Может быть ли это нормально для старичков проекта?
                  — Со старичками проекта такое случается реже, так как они уже больше знают о специфике проекта и правилах код ревью, которые установлены на этом проекте
                  Или сколько времени закладывать на исправление выявленных багов?
                  Сложно дать точный ответ на этот вопрос, опять же все зависит от специфики проекта, сложности вашей задачи и так далее. Очень много факторов имеют влияние.
                  Что будет если половину этого времени переложить на аналитиков, то будет ли здесь экономия?
                  — Не до конца понял вопрос, половину какого именно времени ?)

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

                Самое читаемое