Комментарии 78
— Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
— Представь что тебе надо разгрузить машину, сколько времени это займет?
— Пару часов
— Это камаз
— 8 часов
— Камаз, груженый песком
— 12 часов
— У тебя нет лопаты и инструментов, только твои руки
— 2 дня
— На улице -40
— 4 дня
— Камаз вообще под водой
— Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
«В молодости я спросил у начальника, как оценить время на выполнение работы? И начальник ответил мне:
— Время, которое ты планируешь, умножить на Пи пополам, плюс 2 недели.
— Почему Пи пополам? — удивился я.
— Потому что в реальной жизни ты никогда не будешь двигаться к своей цели напрямую, а скорее — по дуге окружности.
— А почему плюс две недели?
— А потому, что когда ты в итоге просрёшь все сроки, то за две недели хоть что-то успеешь сделать.»
makishvili, прошу прощения, если слегка художественно переврал ваши слова :)
Если он под водой при -40°С — разгружать его вообще не нужно.
:)
Это если спросить сеньора который разбирается в фреймворке
И в конечном итоге разгрузит этот чертов камаз за пол дня, хотя сеньер сказал, что это вообще невозможно ;-) Все дело в мотивации.
Разгрузить надо равными частями в 10 разных местах
У Камаза кончилась солярка
…
Вечно вы что-нибудь придумываете!
Слышал вариант: "планируемый срок исполнения увеличить в двое и перевести в следующую единицу измерения ". Из одного дня получаются две недели.
Не понимаю, почему недостаточно того, вроде просто и очевидного факта, что на данный момент не существует способов предсказывания будущего с доказанной эффективность? Один человек просит другого предсказать будущее, а потом пытается понять почему тот ошибся? Серьезно?
Какая токсичность. В нашей команде все могу делать любую работу и оценить ее с точностью до минуты. Какой из двух трекеров выберите? С такими soft skills, Вы нам не подходите на должность ночного сторожа.
ну наймите строителей оценивать сроки )))
Мне ремонт обещали за 3, а делали 4 месяца.
Не справляются, строители, врачи, кто угодно, ошибаются в оценках(иногда в большую сторону). Просто исходя из аксиомы о невозможности точного предсказания будущего, не могут они этого сделать.
первое что нагуглилось https://www.irn.ru/conf/103/
Но строители хорошо справляются с этой задачей!
Когда строят одинаковые дома — да, справляются. Потому что всё уже известно.
При попытке построить что-то уникальное — у строителей наблюдается постоянный выход за бюджеты сроков и денег, вплоть до умопомрачительных многократных масштабов от первоначальной стоимости/сроков.
Кроме рутины ещё отношение к нетиповым задачам, как к приготовлению пиццы из меню
в кафе.
Но в большинстве случаев, это аналогия с заказом произвольного блюда не из твоего меню, со своим пониманием конечного результата.
Мой прошлый шеф говорил: "У нас сильная команда разработчиков, поэтому время мы умножаем на 2. Была бы обычная команда — умножали бы на три"
А как рутина влияет на количество часов, которые нужно потратить непосредственно на задачу?
Не превращаются. Потому что я говорю про трудозатраты, т.е. про "количество часов, которые нужно потратить непосредственно на задачу". Читайте внимательнее.
И тут выясняется, что вы сделали бы это за два дня, если бы все вокруг про вас на эти два дня забыли и забили — не звонили бы, вопросов бы не задавали, на совещания бы не звали, в почту и прочие слаки не писали бы.
Именно об этом весь сыр-бор. Количество часов вы назовёте весьма точно, я не сомневаюсь. А вот срок — дату на календаре — когда задача будет реально готова? Можно не отвечать, у меня те же проблемы. Вроде и простенькая задачка — сесть и сделать (я не разработчик) за пару часов. Ан нет — этому ответь, того проконсультируй, тут совещание, там опять у кого-то горит на ровном месте. И в итоге простенькая задачка, не переставая быть простенькой, решается неделями.
Вы говорите про трудозатраты в два, условно, дня. А менеджер слышит от вас, что вы сделаете это за два дня. Через два дня менеджер приходит — ничего не сделано.
В этом случае нужно решать проблему с коммуникацией. Говорите менеджеру, что на задачу нужно потратить 16 человекочасов, а не 2 дня. И объясните, что вы программируете не 8 часов в день. Какой-нибудь трекер учета времени легко поможет самому понять, на что вы его тратите и менеджеру потом объяснить. Попробуйте как-нибудь.
А вот срок — дату на календаре — когда задача будет реально готова?
Если у задачи есть приоритет и она должна быть готова к определенному сроку (в силу каких-либо обязательств), она будет к нему готова. При этом все менее приоритетные задачи откладываются. Если кто-то пытается всунуть менее приоритетную задачу в таймлайн, сразу же нужно говорить, что дата реализации изначальной фичи отодвигается. Вроде простой тайм менеджмент же.
Конечно, ошибки планирования (оценки необходимого на реализацию времени) тоже случаются постоянно, тут спорить глупо. Но, проблемы о которых говорите вы, они организационного характера и их вполне можно решить. Навыков предсказания будущего для этого не требуется.
Глубина исследования при этом иногда не может быть конечной, для того, что бы уместить ее в памяти разработчика. То есть разработка начинается с определенными допущениями в виде принимаемого риска.
Там где требуется снизить риски – появляется конвейерная разработка на фреймворке с помощью сертифицированных разработчиков, а задачи ставятся с пониманием ограничений этого фреймворка.
Но если это так низкорисково и предсказуемо, то это же выгодно запрограммировать? Так мы поднимаемся на уровень абстракции выше и получаем новые риски.
То есть грубо говоря, если в проекте не описывают только CRUDы, то разработка оценивает не «разгрузку грузовиков с песком», как в комментариях выше, а дает оценку проекту и реализации механизма, который мог бы разгружать разные грузовики в разных условиях при наступлении всяких событий, причем наборы этих «разных и всяких» меняются и их обычно надо при оценке прикинуть самостоятельно и задать наводящие вопросы.
Например, когда от инженера требуется назвать срок разработки еще до того, как написано нормальное ТЗ, а вместо него подсовывают только «хотелки». Причем возражения, что «без подробного ТЗ, результат будет ХЗ», к сведению не принимаются. Прямо, как в армейском анекдоте «Поехали, потом заведешься».
Сколько раз бывало, что проекту на переход от стадии Ознакомились с ТЗ к стадии Что-то вроде «задышало». потребовалось, например, два месяца.
И сотрудники коммерческого отдела сделали вывод, что «Раз они самое сложное сделали за два месяца, то через неделю можно продавать.».
И тут оказывается, что для перехода к следующей стадии развития проекта (Когда Все готово, проверено, мин нет) может внезапно потребоваться и полгода, и год, и больше. Потому что сейчас проект работает только в режиме «Руками не трогать!!!». А в ходе опытной эксплуатации выползают такие нюансы, которые почему-то никому на стороне заказчика не приходили в голову на этапе написания ТЗ. И хорошо, если заказчик понимает причины этого явления. («Да все нормально, не переживайте. Чтобы с первой попытки все прямо вот взяло и заработало — так не бывает. Мне уже очевидно, что вы на верном пути. Продолжайте работать»)
Бывало и так, что многие тонкости казались заказчику настолько очевидными, что он просто поленился их подробнее расписать в ТЗ. А вопросы (типа, Как это должно выглядеть, чтобы оператору было удобнее? А вот такая ситуация возможна? А что в этом случае делать?), которые ему явно пытались задавать разработчики, оставались без ответа (Типа, «Заняты все были...»).
Ну и про «блуждания пьяного человека» (то есть про многочисленные изменения в ТЗ, вносимые на разных сроках разработки), уже куча копий переломано.
Хотя много раз было и так, что на реализацию какой-то мелкой фичи достаточно опытному инженеру внезапно потребовалось несуразно большое количество времени. Потому что в процессе работы открылась самая натуральная пучина, и фича оказалась не такой уж мелкой, какой казалась в начале…
Неправильная оценка времени (основная тема этой статьи).
Есть всего одна причина почему не удается оценить время работы, и она заключается в отсутствии размерностей в правой части следующей формулы:
время выполнения задачи = объем задачи / скорость выполнения
В отличие от копания канавы или кладки кирпичей, для работы креативного плана не существует объективной величины, позволяющей выразить объем и скорость выполнения, как бы ни старались современные менеджеры и маркетологи. Все-равно что работу художника приравнять к работе маляра и оценивать по разрисованным квадратным метрам. Реальный объем проекта не измерить ни в тасках ни в строчках ни в сториз, также как и продуктивность девелопера — это совсем не количество закрытых тикетов в месяц.
Украшательства: слишком много внимания уделяется деталям, не относящимся к сути проекта.
Всегда есть нефункциональные требования, которые не оговариваются, но которые должны присутствовать в той или иной мере в проекте. Играя с "уровнем детализации" этих требований, можно выиграть время или наоборот потратить лишнее на рефакторинг, "полировку" и улучшение продукта. С этой точки зрения проект — это газ, который занимает весь доступный объем.
Недостаточно времени уделено этапу исследований и проектирования архитектуры. Или наоборот — уделено слишком много времени.
Чрезмерное увлечение проектированием и паттернами как правило лишь усложняет архитектуру, и сильно утяжеляет последующую разработку и поддержку. Зачастую топорное решение влоб или копипаста быстрее и легче, нежели хитрожопый паттерн, построенный по всем правилам.
Недооценка потенциальных проблем интеграции со сторонними системами.
Сегодня это чуть ли не основная проблема. Львиная доля функционала приходится на подключаемый код, написанный сторонними людьми, в котором всегда водятся подводные камни. А вечно меняющаяся экосистема постоянно заставляет работать с новыми средствами, параллельно осваивая их. Часто бывает, тратишь в разы больше времени, разбираясь как приспособить такой-то фреймворк для своей задачи, нежели запрогать ее самому с нуля.
Я бы еще добавил:
- Фетишизм и фричество (девопс, тдд и т.д.)
Желание освоить новые горизонты, сделать все модно, стильно и молодежно, по последним методологиями и с целым паровозом моднючих средств. Идя на поводу у маркетологов, использование ненужных и излишних малоизученных средств сомнительного назначения, которые лишь добавляют проблем и работы, никак не улучшая конечный продукт.
Время легко считать, тк у нас есть точный инструмент в виде часов. А вот точного инструмента для подсчёта сложности проекта нету.
Мне понравилось как Роберт Мартин сказал, примерная цитата: если Вам нужен функционал, который уже кем-то сделан, просто возьмите эту реализацию; если этот функционал раньше никто не реализовывал, то как можно его оценить?
Даже если кто-то реализовывал, то вряд-ли поделится информацией и тем более исходниками.
Из какого года пишете нам? Опенсорс еще пока не изобрели? :)
А про безопасность, то как раз это работает с точностью наоборот, опенсорц более защищённый.
Колесо вот тоже давно реализовано, только оно слегка разное у КАМАЗа и приоры.
Есть одна интересная закономерность, что я заметил, чем ближе дедлайн тем выше продуктивность.И при написанние кода, как справедливо замеченно в статье, возникают баги.И при создание чего-то лучше сразу закладывать примерное время на решение багов.Если оно не понадобится это стагет буферной зоной, а если нет, то это учтенно.
Сложно расчитать точное время выполненмя, но можно пойти по-другому критерию.По сложности проета в целом и в частности.
Дя, для этого нужны примеры прошлых работ, но сравнить сложность с чем-то эталоным, приняв его сложность средней, намного проще чем прикинуть время.А потом просто умножить соответственный колфецент сложности(например лёгкая -0.5, средняя 1, сложная 3, можно заморочится и придумать сложную шкалу, формулу и т.п.) на коофецент форс-мажоров(например взять его 1.5, а потом коректировать на основе опыта), а после умножить на время выполнение эталоного проекта.
Проблема в том, что если ТЗ меняется во время проекта, то надо умножать получившиеся число сразу на 5-10, ибо адекватная оценка в этом случае, почти не возможна.
изян — 1ч
изи — 2ч
просто — 4ч
вроде просто — 6ч
норм — 8ч
норм так — 12ч
хз — 16ч
хз как-то — 20ч
как-то сложно — 24ч
сложно — 30ч
очень сложно — 40ч
б*я — 48ч
п*здец — 60ч
п*здец какой-то — 80ч
вроде изян — 100ч
В свое время присутствовал на докладе Woody Zuill, "Estimates or NoEstimates?" (на ютюбе есть запись). Идея в том, что оценка времени на реализацию — самоцель — на самом деле нужно не число, а некая уверенность что работа вообще будет сделана. В докладе много психологии в стиле "на кой хрен тебе вообще эта оценка?".
Наша команда взяла на вооружение и мы оцениваем не время на выполнение, а сложность задач — если задача достаточно маленькая чтобы быть реализованной за время спринта — мы ее берем в спринт. Если большая — разбиваем на задачи поменьше, пока не получим достаточно маленькие задачи. А дальше — методом проб и ошибок приближение по трудоемкости команды, приоритеты от продуктов и проч. И мы еще не научились закладывать время на "то что нам накинут сверху". Пока вроде более-менее работает.
Но исходя из многолетнего опыта, все эти оценки — херня, нету хоть сколько точного метода оценки, всегда будут ситуации когда сроки прогорят (прилетит "вот это капец срочно!" от начальства — и никакой скрам не спасет, ну или кто-то будет пилить тривиальную задачу весь спринт и все равно не уложится). Да и трудозатраты на все эти оценки часто могут быть потрачены с много большей пользой на собственно решение задач, а не на их оценку.
Я своему менеджеру толкаю мысль, что если задача стоящая, то есть от её реализации будет полезный эффект, то стоит её делать и стоит потерпеть, чтобы достичь результата. То есть работа менеджера просчитать эффект от реализации. А моя задача обеспечить этот эффект.
Я один обычно генерирую примерное время на задачу 'с запасом', а потом просто умножаю это число на 2.5? Ну и как ответственный человек, если я заканчиваю это раньше срока, то просто начинаю заниматься следующей задачей. Такой подход меня ни разу не подводил
Спасибо за статью! Вы переизобрели story points)
Статистика с тяжелыми хвостами. Матожидание невычимлимо.
Тут даже киберпанк в пример привести можно
y = x * 2 + x
y = x * (2 + 1)
y = x * 3
или это какая-то цитата, с которой я не знаком
Я не совсем программист, но это реально работает ;-)))
Написание кода и в самом деле потребовало примерно 7–10 минут. А потом потребовалось 2 часа из-за совершенно неизвестного мне бага во фреймворке.То есть прогноз оказался верным, но в скопе задач появилась новая «разобраться с багом фреймворка».
Аналогичная ситуация в многочисленных кейсах «изменилось ТЗ» — появляются новые задачи, а не изменяется ранее оцененная.
Поэтому можно утверждать, что опытные программисты практически всегда верно оценивают трудоемкость задач, проблемы вовсе не в эстимейтах.
Варианты проблем, приписываемых программистам, якобы срывающим сроки:
— Часть времени съели задачи, подкинутые вне очереди. Включая те блокеры, которые возникли в процессе работы, будь то особенности фреймворка, подводная мина в легаси или разгребание ошибок оператора.
— Программиста вынудили оценивать задачу с недостаточно четким ТЗ, и когда программист сказал «от двух часов до двух месяцев без гарантии завершения», менеджмент не захотел услышать окончание фразы.
— Кто-то начал считать эстимейты достаточным поводом для назначения дедлайнов. Особенно это прикольно выглядит, когда есть зависимости — для продолжения работы необходимы телодвижения со стороны, и ждать этих телодвижений иногда приходится неделями.
— Часть времени съели совещания, больничные и прочие факторы, которые менеджмент не умеет учитывать, гибко изменяя график работ.
На самом деле оценка сроков это как бюджет, туда можно включить полет на Луну :) главный вопрос насколько это нужно заказчику.
У меня было несколько проектов в которых у меня не спрашивали сколько времени потребуется, просто ставили перед фактом, через месяц первая версия должна быть отгружена заказчику. При этом у нас даже опыта в этих областях не было. Сейчас, я бы сказал, этого сделать нельзя, а кто попытается это сделать — авантюрист. Но тогда мы это делали. Был реально драйв. Были довольные заказчики. Было довольное начальство.
Но как-то поучавствовал в "долгоиграющем" проекте, у них стандартно было 2 года между релизами, любое изменение в ТЗ это сдвиг сроков, за пару месяцев которые я был на этом проекте, я успел хорошенько проштудировать интернет, сдать пару десятков брейнбенчесвских экзаменов и тп. Но они практически всегда вписывались в сроки.
Для себя я уже давно выделяю задачу интеграции чего-то с чем-то — это 100% вероятность, что вылезет дурацкая проблема на самом ровном месте. А поскольку последнее время это можно сказать основной тип задач, то сроки целенаправленно увеличиваются. Но всеравно формула умножте на два и добавте еще две недели не работает, хотя раньше достаточно неплохо работала.
Метод определения сроков выполнения проекта по Бобуку-Бацеку
https://youtu.be/XUqiMEh2PMc
http://0x1.tv/Poisson-burning-time-agiledays-lighting-talk Не устаревший блиц-доклад, обосновывающий «умножение на Pi», тремя разными моделями реализации проекта (пуассоновский поток, логнормальное распределение, броуновское движение)
Я начал разделять спринты на задачи равного размера чтобы обеспечить некую однородность процесса оценки времени.
У вас есть пара конкретных примеров? В теории этот пункт звучит достаточно разумно и понятно, однако мне сложно представить как можно сравнивать затраты по времени на задачи разного содержания и приоритета.
Почему инженеры не могут оценить время разработки