Ребят, привет. Вопрос к практикующим программистам, или кто просто в курсе — ест…

Ребят, привет. Вопрос к практикующим программистам, или кто просто в курсе — есть ли какие-то техники оценки выполнения ТЗ?

Я понимаю, что можно прикинуть, сколько времени займет, умножить на свою ставку.
Но как понять, сколько времени это займет? Это ведь сильно зависит от опыта выполнения подобных задач. Может есть какие-то нормативы?

Как например — на СТО, есть нормы трудозатрат отдельные виды работ. Замена колодок — 30 минут на колесо, снять коробку — 3 часа и т.д.
У строителей есть цены на м.кв. штукатурки и т.д.

Я предполагаю, что можно на определенные типовые действия назначить норму времени. Но снова таки — насколько сильно нужно детализировать эти типовые действия?
С одной стороны сильная детализация даст возможность наиболее корректно оценивать работу, с другой стороны, чрезмерная детализация увеличивает трудозатраты на выполнение самой оценки ТЗ.

Может есть какие-то практики и в нашем деле? Как вы оцениваете или как это делают на вашей фирме? Какие виды типовых действий вы считаете?

Телеграм боты

Заказать сайт визитку
Заказать сайт визитку

11 ответов

  1. Даёте предварительно — 5-10 часов, и что оценка может поменяться в первые 2-3 часа работы. Или берите только те задачи, которые можете оценить и уже делали))

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

    Как по мне, это почти всегда «пальцем в небо», т.к. простые задачи можно оценить легко, а сложные никогда не оценишь точно, т.к. возникают сложности при реализации, даже если берешь время на ресерч (из личного опыта — провели ресерч, оценили задачу, а потом промахнулись в 300% от оценки из за того, что документация используемого модуля отставала на пару версий от фактического функционала и пришлось разбираться в сорсах)

    Есть подходы, когда собирается вся команда (разного уровня) и оценивают задачу/задачи, и выясняется почему кто то оценил в 20 часов, а кто то в 4 часа. Интересная, но спорная практика, не все команды могут организоваться и быстро оценить большой объем задач адекватно.

    Если найдете какой-то структурированный подход к решению этой задачи — поделитесь, пожалуйста!) Вопрос, кажется, довольно актуальный для всех)

  5. Прежде всего надо учитывать, что разработка — дело Творческое! По этому у каждого «художника» это занимает совершенно разное время.
    Во вторых «дьявол кроется в деталях», по этому зачастую общий функционал может занять X времени, а вот проработка деталей — X*N, где N — коэффициент от 2 до 10 ))
    В третьих — заказчик не должен делать ТЗ, заказчик должен предоставить «Бизнес -требования», в котором именно описаны требования бизнеса и бизнес-логика к продукту. И вот тут — чем подробнее вы опишете, тем лучше полученный продукт будет соответствовать тому, что вам нужно! И не стоит стесняться детализации, так как все равно ее придется делать, не в начале, так в процессе проекта!
    А наличие четкой детализации того, что вам на самом деле нужно, может сэкономить вам время и деньги исполнения, так как там, где не ясно, исполнитель может придумать что-то очевидное для него, но вам не нужное и оценит это.
    В остальном стоимость и время — это предмет банального торга и конкуренции различных предложений!

  6. Типовые задачи не занимают времени 🙂 Копируется код и существующей собственной кодовой базы (в лучшем случае) или выбирается библиотека (в худшем). Затраты времени около ноля 🙂

  7. По теме: берется оценка 2-3 опытных разработчиков, усредняется, умножается на 2.5. Если полученная стоимость никак не подходит закзачику, делим на 2.5 и умножаем на 2. Если и после этого дорого — досвидания.

  8. Вообще времени не занимает. Все зависит исключительно от скорости печати. Но вот понять что именно нужно печатать — это не колодки поменять.

  9. Никак. Переходите на scrum. А вот большой проект можно экспертно оценить в сколько-то миллионов и при грамотном управлении не вывалиться за оценку.

  10. Начните с ключевых слов: PERT, COCOMO, IFPUG FPA…

Комментарии закрыты.