Как вы считаете время необходимое программисту для решения задачи?

Question

[NewTypes]

Чисто бытовой вопрос для малого бизнеса. Например, я вот ни разу в жизни не писал софта для Windows и мне трудно оценить всю трудоемкость решения поставленных задач. Хуже наверное только тем, кто вообще никогда не программировал.
Из гуманистических соображений к разработчику и себе, я хочу максимально упростить процесс "прикидки", чтобы он был достаточно простым для непрофессионала и быстрым.
При правильной оценке работ плюсы очевидны:
- работник не занимается имитацией бурной деятельности
- работник не перегружается
- сокращаются шансы дедлайнов

Что почитать применительно именно к малому бизнесу, когда посредников, например в виде менеджмента и старших разрабов просто нет.

Какую формулу Вы используете для этого у себя? Как Вы воспроизводите знание об аспектах деятельности?

Answer 1

[Владимир]

Вобще есть формулы по расчетам сроков, но насколько они эффективны - большой вопрос. Если интересно - погугли на тему "Широкополосный дельфийский метод", "PERT"
У нас обычно практикуется 2 метода: разработчик указывает колличество часов, за сколько он сделает доработку - например от 4 до 8, руководитель пишет менеджеру 6-10.
Еще один метод - менеджер сказал - мы это сделаем за 3 дня, может сделать разработчик это или нет - его трудности. Обычно успеваем, но после этого код становится грязным, сопровождать потом не очень хорошо, программисты крайне недовольны работой руководства и менеджеров.

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

От того, кто указал срок, зависит и понятие готовности задачи. Если срок указал программист - это разработка + внутреннее тестирование, если менеджер - срок запуска доработки.

Comments

[NewTypes]

Спасибо за конкретику!

Answer 2

[Павел Елизарьев]

Мой прикладной способ оценки временных затрат следующий.
1) Произвести максимальную декомпозицию задачи (разбить на подзадачи) до такой степени, чтобы каждая подзадача либо уже выполнялась вами, либо вы имели четкое представление как решить подзадачу.
2) Составьте список факторов риска в виде множетилей. Например: новая платформа - 1,2 от базы, сложный клиент - 1,5 от базы и т.д.
3) Перемножьте подзадачи на применимые к ним риски, затем сложите полученные результаты.
Такой подход обеспечивает мне дисперсию в 10% от фактической суммы затрат.

Answer 3

[azShoo]

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

Answer 4

[globuzer]

бюджет времени на выполнение задачи лучше закладывать всегда с 20%, а то и 30% запасом сверху.
все умные книги по разработке ПО говорят что в большинстве случаев проект никогда не будет выполнен в срок, если ставить жесткий дедлайн. по опыту и на практике также. всегда переносяться сроки и подписываются соответствующие решения и договора. конечно очень это еще зависит от количества человек, участвующих в решении задачи. степень риска по не выполнению временного бюджета прямо пропорциональна количеству участников проекта.
если же как сказано в вопросе всего фигурирует допустим один-два исполнителя (для малого бизнеса), то работу и бюджет времени уже можно оценить более точно. но опять же закладывать сверхзапас, форс-мажер и т.п.
очень многое зависит от точности, полноты, четкости требований к разрабатываемому проекту или формулируемой задачи, описания проектных решений и их непротиворечивость, понятность для исполнителей.
в ходе выполнения задачи\проекта проверять степень готовности на некоторых контрольных точках, что более защитит от перерасхода временного бюджета