Как оценивать сроки?

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

Откуда мне знать сколько займет починка бага, если я его ещё не нашел?

Откуда мне знать, сколько займет времени имплементации фичи, если я этого ещё не делал?

Да даже если я сто раз это делал, но не делал в этом проекте, и где-то что-то обязательно вылезет.

Тем более, если я даже не знаю сколько это займет у меня, какого черта менеджер хочет что бы я дал оценку времени на работу моего коллеги?

Когда я тарабанил в веб-студии на типовых проектах, не вопрос, все понятно, но при полноценной разработке?
  • Вопрос задан
  • 7925 просмотров
Решения вопроса 5
saboteur_kiev
@saboteur_kiev
build engineer
Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.

В общем для любого senior разработчика эти вопросы должны быть понятны и ясны. Менеджер не программист и не должен им быть, но разработка крупного продукта должна каким-то образом регламентироваться. Иначе зачем платить программисту зарплату, если он не знает год он будет устранять баг или день? Как тот, кто платит вам деньги, сможет понять а хватит ли у него денег, чтобы вы ему продукт вообще написали, если оценить длительность работы нельзя?

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

Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.
Ответ написан
php666
@php666
PHP-макака
Прикольно звучат высказывания комментаторов в духе "если вы знакомы с проектом". Мне правда интересно, как в условиях современных монстроподобных корпоративных приложений можно быть "знакомым" с проектом, который, возможно, пилится не один год (пусть хотя бы даже от 3 лет) целой командой? Ни один человек, если он не единоличный автор этого проекта, не может быть настолько хорошо быть "знаком" с проектом, что бы чётко отвечать на вопросы в стиле "сколько времени займет поправить баг". Даже программисту среднего звена ясно, что совсем маленький баг может потянуть за собой чуть ли не фатальный коллапс архитектуры с последующим тотальным рефакторингом всего и вся.

Невозможно в разработке планировать какие-либо сроки. Тут автор прав.

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

Как оценивать сроки? Ответ очень простой - да никак не оценивать. Если работодатель построил такую систему, где менеджмент лезет с этими бюрократическими вопросами, не понимает, что разработка или фикс багов в проекте - это не типовая работа, как, например, класть кирпичи или валить лес - то это плохой работодатель. Или плохой менеджмент. А в целом - это компания-эксплуататор, из которой надо бежать.

Я по себе знаю, когда от меня требовали сроки. Последний раз был вообще трешачок в одной московской компании - от меня требовали сроки на 2 день после назначения задачи на меня, при этом я вообще не понимал ничего в задаче - в её бизнес-логике, т.к. работал в этой компании от силы недели три. Через буквально несколько дней меня вызвали "на ковер", мол, почему так долго. Жалею, что прямо тогда не послал их прямым текстом на три известные буквы, а продолжил работать. Ничего хорошего из этого, конечно же, не вышло.
Сейчас я работаю в таком месте, где ВООБЩЕ нет никакого понятия сроки, где разработка проектов в корпорации длится годами - IT работает не на внешнего заказчика, а на внутреннего - на саму же корпорацию. Последний проект, в котором я участвовал, занял около 2-х лет. И бОльшая часть была не программинг, а взаимодействие разных отделов, нахождение багов, форсмажорных ситуаций после запуска и т.д. Работать в таких условиях сплошное удовольствие. Никаких стрессов, никаких менеджеров, изображающих бурную деятельность.

Если хочешь поседеть раньше времени - оставайся и слушай упреки менеджмента. Вместо спокойной работы - придумывай эти цифры сроков. Если нет - просто ищи адекватное место работы. Другого не дано.
Ответ написан
dimonchik2013
@dimonchik2013
жизнь прекрасна в Амстердаме, а в Воронеже gаvно
рекомендую освоить и запомнить
https://www.artlebedev.ru/kovodstvo/sections/167/

сколько фиксятся критичные баги у корпораций - смотри по новостям, тому же Хабру: от 1-2 недель до 3 месяцев (тут спитч про велосипед, костыль и красивый, но уже не нужный к часу Х код)

в остальном - или всю жизнь подаешь ключи (с), или учишь архитектуру / паттерны / тесты / микросервисы и набиваешь руку: сроки даются всегда. Не всегда сразу, можно после ресерча, но всегда.

Да, начальство заявленное умножает на 1,5-3 тоже практически всегда
Ответ написан
dyfran
@dyfran
Это боль, я лишь расскажу как делаем мы.

1. Максимальная декомпозиция задач (кэп)
2. Оцениваем фичи всем скоупом сравнивая между собой в размерах одежды (можно смеяться) S, M, L, XL, XXL
3. После начала работ и примерного понимания скорости команды, а так же опыта аналогичных фич с одинаковой размерностью (сколько было потрачено времени на все предыдущие фичи L), получаем примерную, пальцем в небо оценку.

Благо мой заказчик не идиот и понимает, что оценки на фичи с реализацией 160h+ становятся не актуальны через 2 дня работы, поэтому скрепя сердцем довольствуется такой примерной оценкой, и да, я также как и вы считаю, что мы не мосты и здания строим, наша задача не скрупулезное планирование, а качественный, эффективный и конкурентоспособный продукт.
Ответ написан
vitaly44
@vitaly44
Предприниматель, веб-разработчик, дизайнер
Чтоб никого не задеть за чувства и не перевозбудить — просто менеджеры не программисты :-) А те, кто им всё точно оценивают — все огребают потом.

Вообще, чтобы что-либо оценивать заранее — надо иметь чёткую узкую фокусировку на чем-то одном, нууу, чтоб баги были типовыми)))

Если кто хочет — могу в комменте написать всю правду про этих манагеров)
Ответ написан
Пригласить эксперта
Ответы на вопрос 9
BojackHorseman
@BojackHorseman
...в творческом отпуске...
сопли какие-то. это твоя работа. мне бы такое заявил, я бы тебя выгнал в тот же день.
Ответ написан
@jkotkot
Делаю дела
Тут все просто. Есть законы статистики и больших (и не очень) чисел. Требуют оценки, т.е примерных (с погрешностью не более процентов 30) сроков.
Во-первых, полноценная разработка она тоже довольно типовая.. на самом деле) Если вы этого еще не поняли, то это говорит, что у вас довольно мало опыта.
Во-вторых, если вы пофиксили 100 подобных багов, то можно заметить, что время, которое требуется исправления попадает в некий диапазон, который и требуется озвучить, уточнив его с помощью дополнительно информации, которая вам известна. Если не известна (например, новый неизвестный проект на фрилансе, а заказчик просит сроки и цену), то вполне можно называть весь диапазон. т.е от и до (от часа до недели ), а потом, по мере изучения проекта и получения информации, его уточнять.
То, что там где-то вылезет тоже можно учесть в сроках.. Часто есть предсказуемые вещи, которые могут вылезти. Или сделать оговорку про то, что эти сроки учитывают только хороший сценарий, но тогда нужно будет назвать сроки, когда вы узнаете есть ли проблемы или нет.
Ответ написан
Konata69lol
@Konata69lol
backend php laravel
В сроки попадаю только если задача разжевана от и до. Т.е. задача уровня "делай не думая". И срок у такой задачи в пределах дня.
В остальных случаях это выливается либо в срыв сроков, либо в лапшекод на выходе, либо в правку багов и доработки задним числом. И чем больше примерная оценка, тем больше побочных эффектов.

Возможно это связано с малым опытом (~2 года коммерческой разработки), недостаточными знаниями ООП, отсутствии тестов и базы наработанных решений.
Ответ написан
@vanyamba-electronics
Откуда мне знать сколько займет починка бага, если я его ещё не нашел?


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

Откуда мне знать, сколько займет времени имплементации фичи, если я этого ещё не делал?


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

Да даже если я сто раз это делал, но не делал в этом проекте, и где-то что-то обязательно вылезет.


Не нужно просто трудоустраиваться в такие проекты. Это пустая трата времени и здоровья.

Тем более, если я даже не знаю сколько это займет у меня, какого черта менеджер хочет что бы я дал оценку времени на работу моего коллеги?


Предложи вставить эту работу в план, и скажи, что на это тебе потребуется неделя. Он сам убежит оценивать.

Когда я тарабанил в веб-студии на типовых проектах, не вопрос, все понятно, но при полноценной разработке?


Тем более, когда над проектом трудится маленькая команда настоящих спецов.
Ответ написан
ApeCoder
@ApeCoder
Про это написаны книжки и статьи. Например, вот.

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

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

Я бы советовал написать план выполнения задачи и тестирования, подумать о том что ещё может сломаться и тестирования этого (регрессионное тестирование) и узнать мнение коллег (они могут подсказать что упущено). В SCRUM, например в планировании участвует вся команда.

Ещё я бы советовал гуглить на английском перед заданием таких общих вопросов - скорее всего вы найдете более качественный контент чем сам ответят тут. Например поищите approaches for software estimation.
Ответ написан
vvpoloskin
@vvpoloskin
Инженер связи
Я делаю так: представляю шкалу процентов и времени. Т.е. с вероятностью 80% я сделаю это за неделю. Торопят быстрее? За три дня я сделаю это с вероятностью 20%. Откуда такие цифры? Из опыта, подтверждённого задачами из системы постановки задач.
Ответ написан
lukoie
@lukoie
Откуда мне знать сколько займет починка бага, если я его ещё не нашел?

Откуда мне знать, сколько займет времени имплементации фичи, если я этого ещё не делал?

Для того чтоб дать эстимейт, дается время, а не сразу просят оценить.
Задача разработчика - понять логику работы продукта, понять суть проблемы, найти место, где возникает проблема, оценить качество кода, причину возникновения проблемы. На это обычно уходит до часа. И тогда уже становится примерно понятно что нужно делать и в каких обьемах.
Ответ написан
b0nn1e
@b0nn1e
Alcohol & Ruby on Rails
Мне кажется у вас очень опытные менеджеры а вы ведетесь как дети малые.
Оценка задачи это тоже задача и у нее тоже есть оценка.

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

Не созрела оценка? - Не озвучивай.
Не понятно вообще как оценить? - Декомпозируй, оценивай по отдельности а потом суммируй.
Начал делать и понял что проебался? - Сразу об этом сообщи, а не за час до дедлайна.

Просят оценить за другого человека? - акцентируй внимание на том сколько бы именно ты делал эту задачу.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы