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

Question

[raiboon]

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

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

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

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

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

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

Comments

[Дмитрий Есин]

Чувак, как я тебя понимаю.
Сам пришел в разработку в апреле 2016.
Сколько литературы перечитано на тему оценки сроков, гибких методологий разработки (статьи и серьезные книги). Сколько методик на практике использовано (писал таблички, делал исследования задачи до того как брать работу, сравнивал с похожими ранее выполненными задачами, делал совместную оценку с более опытными разработчиками, уточнял сроки при изменениях и инсайтах).
С высоты своего небольшого опыта работы скажу, что всё это не работает и с опытом не приходит. Писатели книг и статьеписцы зарабатывают свои деньги и лайки, а вот вложить навык от одного к другому - это очень редко происходит. Я наблюдаю такую корреляция (не причинно-следственую связь, а именно корреляцию) - человек либо умеет оценивать, либо не умеет. Он может прокачать умелку, но она либо есть либо нет. И это природное скорее всего, зависит от генов, образования, психотипа, воспитания, школы, детского сада. Где-то там собака зарыта и нужно просто принять это.
Вот завтра я проваливаю срок по одной крупной задаче, которую не смог оценить, переживаю, т.к. это не первый раз и с утра буду думать как поведать об этом бизнесу, какие варианты решения проблемы предложить...

Answer 1

[Saboteur]

Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.

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

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

Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.

Comments

[raiboon]

Опытный разработчик то, опытный разработчик сё.
Откуда мне знать? Откуда вообще может кто-то это знать без хрустального шара?
До пенсии успею я стать этим мифическим "тыжсеньером"? встречал core issue, которые вообще нельзя было решить. Я видел, как команда из 5 человек целый день issue, которой на самом деле не было. Я не помню случаев, когда кто-то сказал и сделал все в срок (Ну кроме первых работ, где были сайтоконвееры).
И не важно, были в команде только джуно-миддлы, во главе с тех диром, или сеньеры, архитекторы с 30 летнем стажем, ещё и привлеченные иностранные консультанты за много денег. Раза в 2-3-4 и больше сроки продалбываются всегда. И это удача, если вообще в разумный срок хоть что-то вышло.

[Saboteur]

. Я видел, как команда из 5 человек целый день issue, которой на самом деле не было.

Видел или это происходит ежедневно?

Я же писал, что всегда есть риски, на них следует выделять какой-то процент времени каждый спринт. 10%? 20%? Нормальный менеджер смотрит на продуктивность команды и меняет эти проценты так, чтобы они максимально соответствовали действительности.
Да, в нормальной компании если команда не успевает выполнять задачи в срок регулярно - либо уменьшают количество задач на спринт, либо увеличивают штат.

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

Да, опытный разработчик и то и сё, потому что для бизнеса нужны сроки, а не творческий полет души быть может через 10 лет. Опытный менеджер должен уметь набрать людей и настроить работу команды так, чтобы она работала предсказуемо. Иначе никакого планирования быть не может.

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

[raiboon]

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

Черт, два лагеря ответов. Одни говорят, что все планируется, и почти всегда укладываются в прогнозы.
У других опыт как у меня - насколько не была бы опытной команда, планирование и сроки существуют только в отчётах манагеров. А в жизни все 50 на 50, либо получится, либо нет.

[Saboteur]

raiboon, Не, ну серьезно. Я не представляю - как вы можете работать, если 50 на 50 неизвестно получится или нет.
А если зарплату будут выдавать 50 на 50, либо выдадут, либо нет, будете работать?
И что же это за контора, что же это за работа, что им вообще некритично что вы делаете?

[raiboon]

Saboteur, ну как то я 7 лет работаю?
Продуктовые компании, где качество и стабильность кода важнее, чем абстратный ttm.

Не правда у вас получается планировать? Вы не понтуетесь публично?

[Saboteur]

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

Довольно быстро можно понять root cause, сразу понятно, уложилось ли решение непредвиденной проблемы в те самые 10% общего времени, которые бронировали для решения непредвиденных проблем.
Постфактум уже анализируется вопрос - это случайность, человеческая ошибка, невыполнение плана и насколько эта проблема единичная или регулярная.
Делаются выводы - например увеличивать сроки для непредвиденных срывов, увеличивать штат, улучшать постановку задач. И точность планирования все время улучшалась. Собственно именно для этого в Agile и есть эти регулярные стендапы, общие митинги, ретро-митинги и др., а не просто собраться и поговорить за жизнь, потому что Agile действительно требует от всей команды умения себя организовать, и в Agile участвует не только менеджер, тимлиды и скраммастер, а каждый.

Я не понтуюсь, все что я пишу выше - это вообще принцип работа за деньги. Браться за работу, которую вообще нельзя спланировать - это тогда как? Есть люди, которые закладывают +30% на риск, есть которые закладывают 200%, а то и 300%. Это уже как договоришься с работодателем. Но планы, сроки - они должны быть.

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

[Mofsy]

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

[Saboteur]

Mofsy, в данном контексте это не совсем смешивание языков, это терминология, которая используется в различных ITIL системах и багтрекерах.

[Mofsy]

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

[Saboteur]

Надо настучать тем, кто написал ServiceNow, Jira, надо настучать создателям гугла за "гуглим"?
Множество вещей было создано и распространено зарубежными компаниями, отсюда и иностранное похождение многих терминов.
Вы же говорите ксерокс, а не копир?
Да и слово копир - тоже иностранное.

Поэтому не понимаю, почему вы паритесь - в русском словаре полным полно слов иностранного похождения.

Answer 2

[Северное Сияние]

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

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

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

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

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

Если хочешь поседеть раньше времени - оставайся и слушай упреки менеджмента. Вместо спокойной работы - придумывай эти цифры сроков. Если нет - просто ищи адекватное место работы. Другого не дано.

Answer 3

[Dimonchik]

рекомендую освоить и запомнить
https://www.artlebedev.ru/kovodstvo/sections/167/

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

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

Да, начальство заявленное умножает на 1,5-3 тоже практически всегда

Answer 4

[Виталий Кузнецов]

Чтоб никого не задеть за чувства и не перевозбудить — просто менеджеры не программисты :-) А те, кто им всё точно оценивают — все огребают потом.

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

Если кто хочет — могу в комменте написать всю правду про этих манагеров)

Comments

[Konata Izumi]

Напишите правду матку о манагерах.

[Валентин]

Konata Izumi, а мы потом опишем Асю правду-матку о программистах

[Виталий Кузнецов]

1. Манагеры не разбираются в технологиях.

2. Манагеры не хотят разбираться в технологии производства.

3. Манагеры подчинены продаванам.

4. Продаваны впарили идеал без знания технологий и процессов.

5. Заказчик повёлся на иллюзию от продавана.

Программисты крутые.

Проблема кроется в продажах, далее уже по цепной реакции и «виноваты» программисты :-)

[lukoie]

Виталий Кузнецов, о ужас, какое дремучее невежество...

[Виталий Кузнецов]

lukoie, яж говорил )))

[lukoie]

Виталий Кузнецов, уважаемый Говорил, то что Вы написали это Ваше очень субьективное мнение, а потому с точки зрения моего объективного мнения оно всё, по каждому пункту является неправильным.

[Виталий Кузнецов]

lukoie, вы за себя говорите, товарищ и себя оценивайте)

[lukoie]

Виталий Кузнецов, я всегда именно сам и говорю за себя, и не доверяю этой функции спикеру или секретарше.
Оцениваю себя на 8,576 из 10ти.
ЗЫЖ я не "товарищь". Не являюсь гражданином российской федерации.

Answer 5

[Никита]

Тут все просто. Есть законы статистики и больших (и не очень) чисел. Требуют оценки, т.е примерных (с погрешностью не более процентов 30) сроков.
Во-первых, полноценная разработка она тоже довольно типовая.. на самом деле) Если вы этого еще не поняли, то это говорит, что у вас довольно мало опыта.
Во-вторых, если вы пофиксили 100 подобных багов, то можно заметить, что время, которое требуется исправления попадает в некий диапазон, который и требуется озвучить, уточнив его с помощью дополнительно информации, которая вам известна. Если не известна (например, новый неизвестный проект на фрилансе, а заказчик просит сроки и цену), то вполне можно называть весь диапазон. т.е от и до (от часа до недели ), а потом, по мере изучения проекта и получения информации, его уточнять.
То, что там где-то вылезет тоже можно учесть в сроках.. Часто есть предсказуемые вещи, которые могут вылезти. Или сделать оговорку про то, что эти сроки учитывают только хороший сценарий, но тогда нужно будет назвать сроки, когда вы узнаете есть ли проблемы или нет.

Comments

[longclaps]

Есть законы статистики

Законы - в студию!

[raiboon]

>> полноценная разработка она тоже довольно типовая

Сколько займет интеграция с api, которое предоставляет нам fignya limited? Вот же доки, все просто.

Сколько займет вынести в вашем последнем проекте авторизацию из самого приложения, на self-hosted oath2 сервер?

У вас ничего не работает. Сколько времени займет починить?

>> То, что там где-то вылезет тоже можно учесть в сроках

Как вы учите, что документация устаревшая и по любому вопросу вам предлагают спрашивать в чате? А потом, что из-за тестов черного ящика, вас начнут rate-limit?

А уж сколько проблем может вылезти во втором-третьем кейсе - не сосчитать.

[Никита]

Все что вы описали - это все типичные ситуации. Умножаете хороший сценарий на 3 и получаете реальную оценку. Все все пойдет хорошо - сделаете раньше. Не сделаете - попадете в оценку, если вы не никчемный.
Если верхняя оценка не устраивает, то предлагаете сделать ресерч: интегрируете одну функцию из апи, замеряете время, потом умножаете на число функций.. с каким-то поправочным кэфом.
Если решение зависит от кого-то еще, то называете оценку с учетом того, что отвечать вам будут за какое-то разумное время. За задержки сроков не по своей вине вы не отвечаете. Вот и все. Озвучивайте все эти факторы и предупреждайте о возможных рисках. Это то, что от вас хотят.

[raiboon]

Всё-таки непонятно.
Толи вы все гении.

Толи я тупой.

Толи вы себе врёте, что можете что-то прогнозировать. А в сроки попадаете, случайно, то скатываясь в говнокод и срезая углы, то расслабленно пописывая то, что оказалось проще, чем было.

[raiboon]

Или как вариант, работа всю жизнь на одном стеке и на однообразных проектах?

[Никита]

Ну почему СЕБЕ врем? За оценки же нужно отвечать перед руководством или заказчиками. Нет смысла врать.
Работа в одном стеке, конечно увеличивает точность оценки, но сложность большинства задач можно оценить без детального знания стека. Просто понимая, что там. Также как и апи. ну и оценки можно пересматривать.

[Никита]

Мало того, как руководитель можно давать оценки за своих подчиненных. Даже еще не существующих. Даже по новым проектам. Например просто оценивая много или мало. Год много? да. день? мало полгода? многовато 3 месяца? маловато. ну вот и выходит 3-6 месяцев. в среднем 4.5. остальное - погрешность

[Никита]

Если ошиблись с оценкой, то смотрите что не учли. В следующий раз включайте это. Используйте поправочные коэффициенты. Т.е если просто заходить рабочую версию это месяц, то решить внезапные проблемы, оттестировать, пофиксить баги, вывести в прод это уже 3 месяца). И вы будете попадать в оценки.

Answer 6

[Konata Izumi]

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

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

Answer 7

[vanyamba-electronics]

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

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

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

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

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

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

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

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

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

Тем более, когда над проектом трудится маленькая команда настоящих спецов.

Comments

[Виталий Кузнецов]

у меня поиска бага у себя в среднем 1 день, если проект старый — 2-3 дня.

в чужих от 1 дня до недели.

это среднее и зависит от проекта и уровня бага.

[vanyamba-electronics]

Виталий Кузнецов, а время на исправление ты не считаешь?

[Виталий Кузнецов]

vanyamba-electronics, поиск включает исправление. Обычно не так всё плохо)))

Answer 8

[ApeCoder]

Про это написаны книжки и статьи. Например, вот.

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

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

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

Ещё я бы советовал гуглить на английском перед заданием таких общих вопросов - скорее всего вы найдете более качественный контент чем сам ответят тут. Например поищите approaches for software estimation.

Answer 9

[Валентин]

Я делаю так: представляю шкалу процентов и времени. Т.е. с вероятностью 80% я сделаю это за неделю. Торопят быстрее? За три дня я сделаю это с вероятностью 20%. Откуда такие цифры? Из опыта, подтверждённого задачами из системы постановки задач.

Answer 10

[sim3x]

Какие есть методики и ориентиры для подсчета количества программо-часов на проект?

Answer 11

[lukoie]

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

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

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

Comments

[Konata Izumi]

Для того чтоб дать эстимейт, дается время, а не сразу просят оценить

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

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

Это на хороших проектах.
На всяких цмсках/движках/самописах можно целый день баг ловить.

[lukoie]

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

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

Это на хороших проектах.
На всяких цмсках/движках/самописах можно целый день баг ловить.

Та на любом. Если сказали что работает не так, показали пальцем, то найти кусок кода, который приводит к этому, вполне возможно. Там можно изучить массив кода, и примерно понимать что это и о чем. А отсюда и понять что нужно править, и сколько примерно на это может уйти времени +25% на неизвестное.

Answer 12

[Андрей Андреев]

Мне кажется у вас очень опытные менеджеры а вы ведетесь как дети малые.
Оценка задачи это тоже задача и у нее тоже есть оценка.

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

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

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

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

Comments

[Konata Izumi]

Не созрела оценка? - Не озвучивай.

Спрашивает менеджер:
- Когда задачу сделаешь?
Разраб:
- Ну я не знаю, оценка еще не созрела. Как сделаю, так сделаю.

[Андрей Андреев]

Konata Izumi,

Спрашивает менеджер:
- Когда задачу оценишь?

[Konata Izumi]

Андрей Андреев,
- Через час.
прошел час
- Какие сроки?
- Тут примерно столько часов, тут столько, тут не знаю, нужно подробнее исследовать, тут тоже неясно. Лучше стало?

[Андрей Андреев]

Konata Izumi, ну да. Это в принципе то что от вас и ждут. Уже что-то.

[Konata Izumi]

Андрей Андреев, Всё равно точных сроков нет, и даже с погрешностью +-50% нет.
Чем ближе к концу задачи, тем точнее определяем срок. Задача решена - получаем точный срок.

Еще интересно, кто должен заниматься декомпозицией задач: менджер, разработчик или совместными усилиями?
Например, задача с виду занимает больше одного дня. Кто будет разбивать задачу на более короткие подзадачи?

[Андрей Андреев]

Konata Izumi, когда оценили потом сделали - можем посчитать на сколько проебались. При могократном повторении придёт понимание что делаем не так в оценке.
Декомпозицией занимается разработчик.

[sergealmazov]

"И да, иногда оценивать задачи на много сложнее чем собственно их реализовывать, очень велик соблазн на отебись что-нибудь сказать и даже не начинать вникать." - что и происходит в 99% времени. Потом все дружно огребают )