Как об этом не подумать проблемы-то никакой нет. Даже науки не надо никакой разводить. И так всё понятно. Посмотрел на таски, сказал сколько времени они займут и просуммировал. Вот вроде бы и всё, так? Так?

Но очень часто такой подход подводил меня. А если вы неправильно оцениваете время, то заказчик начинает нервничать, расходы, рассчитанные на проект, начинают увеличиваться и соответственно прибыль от проекта идёт на убыль.

Если между вами и заказчиком стоит ещё тимлид и/или проджект менеджер, то отношения с этими людьми перестают быть доверительно положительными: какой-нибудь крутой таск в следующий раз вам не доверят, а отдадут тому, кто правильно оценивает время нужное ему на выполнение задачи.

Выводы, которые мне никто не объяснял и до них пришлось дойти самому.

Вывод первый

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

Не нужно бояться, что на тебя посмотрят как на ленивого программиста, который не может сделать простую вещь. Проджект менеджеры, директоры будут пытаться смотреть на тебя с прищуром, пытаясь разгадать, а не ленивый ли ты программист, и требовать сделать невозможное за неделю.

Ни в коем случае не поддаваться на упреки от начальства. Отсюда следует еще один вывод, который обязательно нужно помнить стартаперам.

Вывод второй

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

В этом плане программирование можно сравнить с ездой в пробке. Иногда поток начинает двигаться быстрее, медленнее, останавливается. Но вы должны быть на ужин в 18, а уже без десяти, но остальной маршрут займет по прогнозам навигатора минут 30 или 40. Макорошки остынут.

Давайте также как разработчики поднатужимся и доберемся до вечиринки за 10 минут. В моих проектах обычно пробка - это шоссе, где нет своротков, нет объездов и коротких путей по дворам.

В итоге

При оценивании таска нельзя соглашаться на желаемый проджектом нереальный срок, если этот срок не реальный.

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

А ощущение времени у задач приходит только с опытом.

Перестаешь программировать, меняешь стэк - и это ощущение пропадает.

Я это ощутил при смене стэков, когда вернулся на свой старый стэк Qt/C++ после Python/JavaScript и весь проект ощущался изначально раза в два меньше.