Комментарии 34
>а с самым непредсказуемым в природе материалом - людской психикой
Ну да, опять люди виноваты. Очень многие задачи реально находятся в плоскости не то что "хз сколько времени это займёт", а даже в плоскости "хз как это вообще делать", независимо от квалификации. Новые библиотеки, новые подходы, да даже копипаст не всегда копипаст, а куча сюрпризов в процессе реализации, как технических, так и в BL. Со временем на оценки тупо забиваешь, ибо бесмысленно всё это и ты всегда крайний. Понятие Pocker game не даром появилось. И, упаси хосподь, Agile как таковой.
Почему об этом справшивают у работника? На заводе (в нормально производтвенном процессе) этим вопросом занимается экономист и нормировщик. И инструментов у них, чтобы запланировать трудоемкость изготовления детали - множество.От справочников до фотографирования. Виновата индустрия, а не работники. Если бизнес не умеет планировать трудоемкость техпроцесса - это проблема и вина бизнеса.
На заводе в работе отсутсвует творческая составляющая. Происходит производство известно чего и известно как. По документации.
Вы сравните лучше с работой конструктора.
Ну давайте сравним с работой конструктора. Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела. И методов оценки трудоемкости разработки детали или техпроцесса тоже множество - количество отверстий, количество плоскостей и так далее. Всегда можно оценить сложность детали и привязать к ней трудоемкость. И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно. Нигде в промышленности менеджеры проектов, продаваны и прочая бессмысленная братия не насилует работнику мозги насчет сроков, не стоит над душой, не нагоняет стресс на планерках, не подходит и с наездом говорит "что я еще могу сделать, чтобы ты быстрее сделал эту задачу".
Надо сказать прямо и честно. Проблема ИТ в плане планирования сроков и трудоемкости стоит не оттого, что ИТ какая-то особенная сфера, а оттого, что в ИТ доминируют безграмотные кадры, не имеющие высшего технического образования (я имею в виду настоящего инженерного, производственного). Никто из айтишников (я гарантирую вам это!) совершенно не имеет представления о промышленном производстве. Не имеет представления о конструкторской разработке, о технологии. Максимальный потолок для айтишного кадра - радиофак. Большинство же - курсы по джава и спрингу.
О каком планировании может идти речь? Для большинства айтишников (не для производственного инженера!) планирование производства (а разработка софтины в плане планирования производства абсолютно ничем не отличается от разработки ракеты, я гарантирую вам это!) - это магия, тайна, что-то за гранью понимания.
И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно.
Знаете почему расстреливали? Потому что акт насилия происходит от бессилия, это крайняя мера, к которой прибегают когда все другие известные способы решения проблемы не получается осуществить.
Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела.
Так умеют, что в советское время создавали целые направления и кружки для изучения и решения проблем менеджмента на производстве. Это всё с тех времен тянется. Познакомьтесь, например, с Щедровицким. Из его лекций можно узнать, что руководители и начальники бюро в принципе не понимали, как строить заводы и управлять производственными процессами в срок.
И что-то мне подсказывает, отсутствие обратной связи и исключение исполнителей из планирования — было одной из причин этих проблем.
ого батенька, да у вас мания величия, не иначе
Не понял посыл… в ИТ одни неучи, поэтому срывают сроки? Вот бы приставить к ИТ спецам микро-сталина, чтобы расстреливал их, если не уложились в срок? =)
Или надо создать институт исследования планирования сроков разработки ПО?
Интересно посмотреть на оценку детали в числе отверстий при разработке ПО.
На заводе так работает. В ИТ тоже так - но в суппорте, или любом другом конвейере, где примерно понятно и повторяется деятельность, можно вводить нормы.
Но когда мы говорим о проектах, и проектной деятельности - что составляет львиную долю ИТ, нормы неприменимы. Проект по определению уникален и конечен. Даже если мы в прошлом уже делали аналогичный, условия меняются, команда меняется (даже если тот же состав - она набирает опыт, или забывает прошлый проект). А кроме того он обычно делает какой-то продукт который надо еще и продать на рынке, который быстро и непредсказуемо меняется.
Именно исходя из этого так все заморачиваются с оценкой, спрашивают исполнителей, перепроверяют и т.д. потому что делается что-то уникальное, что до этого не делали, или делали но не так, и не там, и вообще для другой цели.
Единственный разумный ответ, но его почему-то заминусовали
PS в советское время были даже справочники по нормированию работ художников
Как же всё-таки правильно ставить и соблюдать сроки?
Ответ на этот вопрос уже давно дан в книге "Мифический человеко-месяц". Достаточно осознать, что есть два вида сложности задачи: практическая и концептуальная.
Первая подразумевает что решение уже известно, нужно только его исполнить. Это любая работа, для которой уже есть алгоритм или императивная инструкция. Такие работы можно оценить с точностью 100%, их легко автоматизировать, включить в инструментарий.
Вторая подразумевает что решения не существует, его нужно найти. Оценить такие задачи невозможно никакими способами. Потому что оценивать можно только то, что известно. Это, например, новые бизнес фичи, архитектура сервиса или алгоритм обработки данных.
Любую задачу концептуальной сложности можно превратить в задачи практической сложности. Для этого необходимо проводить исследования.
Например. Прежде чем брать новую фичу в спринт, сначала провести системный и бизнес-анализ за фиксированное время. Если задача слишком сложная, этот анализ проводится несколько раз, пока всё же не будет найдено решение. И только потом это решение, декомпозированное на практические задачи, берётся в работу.
Кстати, проводить анализ можно итерациями и по 2 дня, и по 2 часа, смотря к какому темпу готова компания и команда. Так что популярный аргумент “нам некогда, нам бизнес делать надо” не работает.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования - никакие средства контроля и самообмана не помогут (кроме везения), сроки будут нарушены.
Оценить такие задачи невозможно никакими способами
Возможно. По опыту решения аналогичных задач.
Если проектный менеджер или тимлид этого не понимает, толкает в работу концептуальные задачи без исследования...
Этого не понимает бизнес, а промежуточным элементам это всё доводится в виде ограничений типа бюджета или сроков. Прокладкам не остаётся ничего иного, кроме как транслировать пожелания вниз. Ну или увольняться, что чаще всего не хочется делать.
В целом всё сводится к глобальной оптимизации, в которую как раз наверху никто не умеет (исключительно по системным соображениям). И "Мифический человеко-месяц" здесь ничем помочь не сможет. Это принципиально не его область.
Срок, спущенный сверху, НИКОГДА не является зоной ответственности исполнителя
Срок, спущенный сверху, всегда является зоной ответственности исполнителя. Потому что это один из факторов принятия решения. Например, программист может применить готовый проблемный алгоритм, если бизнесу надо завтра, или придумать новый качественный за месяц, если сроки квартальные.
Также зоной ответственности исполнителя является способность дать аргументированный отказ, если сроки неадекватные.
Программист должен решать задачу так, как решит руководитель группы. Если исполнитель не укладывается при решении задачи в тот срок, который запланировал руководитель группы - это косяк и ответственность руководителя. Не умеешь планировать работу подчиненных - сдай спецовку.
А каким образом, по-вашему, руководитель группы планирует корректный срок для решения задачи?
На мой взгляд, он не может быть экспертом и практиком в той области, которой занимается исполнитель. Поэтому грамотный срок определить он может только на основе показаний исполнителя:
Сделаю за 1 день, но плохо
Сделаю за 2 дня, но потом придётся переделать за 4 дня
Сделаю за 5 дней, но хорошо
Не сделаю, вы требуете невозможного
Поэтому, грамотно обработать спущенный срок в зоне ответственности исполнителя. Я не говорю, что только он за него отвечает, но тоже отвечает, да.
Другое дело, если руководитель игнорирует комментарии и варианты сроков исполнения — это уже неадекватность. В таких случаях свою зону ответственности желательно переводить в другую компанию.
Дело в том, что PM в ходе своей работы сталкивается не с управляемым кодом или красивыми рисунками, а с самым непредсказуемым в природе материалом - людской психикой. Только держа в голове разнообразные хитрости, слабости и приемы уклонения, мы можем если не избежать, но уменьшить фактор риска при срыве тех или иных сроков.
Ну да, у программистов послушный компьютер, а у дизайнеров и иллюстраторов красивые картинки. И только у менеджеров другое — у них сложная, непохожая ни на что работа.
Есть целая категория науки, которая занимается проблемами менеджмента — это гуманитарная наука. В неё входит большое количество учебных материалов и исследований по вопросам решения менеджерских задач. Кстати, хитрости, уклонения и манипуляции сотрудниками — не входят в перечень инструментов для решения этих задач.
Только не воспринимайте мои комментарии как нападки.
Мы тут сотни статей пишем о требованиях к навыкам программиста: теория, алгоритмы, разбирайся в бизнесе, умей в софты, организуй свой рабочий процесс, оценки давай для задач.
А для менеджера у нас какие требования? Лояльность, интуиция, пару лайфхаков управления из паблика про менеджмент. Я считаю, что мы должны развеять миф о том, что на менеджера не нужно учится.
А для менеджера у нас какие требования?
Одно и очень важное - понравиться нанимателю. Это реально важно для нанимателя. Всё остальное для него - тёмный лес. А система строится именно этими персонажами. Угадайте с трёх раз, какая получилась система.
Да, интересный момент вы затронули.
Но ведь понравится нанимателю может специалист по продажам, или квалифицированный переговорщик. К человеку, который должен уметь управлять производственным процессом это требование не применимо.
А знаете почему так? Потому что в нашем представлении даже чел, который сидит на холодных продажах — тоже "менеджер” по продажам.
Поэтому я и пытаюсь в своих комментариях сделать акцент на том, что менеджер, то есть руководитель — это вполне конкретная специальность, с четкими обязанностями и требованиями к навыкам. А не парень, который приятен для бизнеса в общении.
ПонравитЬся - это комплексная оценка, включающая и субъективное ожидание нанимателя о профессиональных навыках нанимаемого.
руководитель — это вполне конкретная специальность
Не совсем так. Это комплекс, который в нормальной практике разбит на несколько должностей без директивных полномочий. Но общепринятая практика подсказывает очередному "руководителю" - властью нельзя делиться. Тем более, вообще её лишаться. Наниматель этот мотив отлично понимает, ибо сам в точно такой же роли. То есть смысл опять в системе.
Короткий ответ - декомпозировать, учитывать риски с зависимостями, обсуждать задачу с исполнителем
Так то техник как оценивать и попадать в оценки неприлично много и большинство из них рабочие
Оценку данную техническим специалистом, в случае если бизнесу нужна оценка сверху, нужно умножать на Pi с округление вверх и с переводам в следующую единицу измерения времени.
Сказали будет через 15 минут, умножаем на pi, получаем 47.1 округяемм вверх, получаем 48, минуты меняем на часы, 48 часов. Вполне реальный срок. 2 дня? 7 недель. Три недели? 10 месяцев.
Ну а дальше искуство не просрать задачу и сделать быстрее.
Почему не работают? Потому, что на оценку необходимо время. И чем сложнее задача, чем хуже она описана, тем больше времени требуется. А времени на оценку не предусмотрено в бюджете. Так и живем, к сожалению.
Какое совпадение, как раз сегодня Fermat's Library прислали статью THE MYTHICAL MAN-MONTH.
Можно попробовать порассуждать. На заявленную тему.
Предположим, у нас есть модули, решающие отдельные задачи. Скажем, конвертирование файлов или представление результатов запроса к базе данных. Всё это — задачи, допускающие явную оценку времени реализации. Нижняя оценка — для высококвалифицированного программиста, и верхняя — для низкоквалифицированного.
Более крупные задачи решаются при помощи декомпозиции на более мелкие. Линейная декомпозиция означает, что модули собираются в цепочки. Имея K модулей, можно собрать цепочку, у которой будет K+1 точка сочленения (включая точку входа и точку выхода). Соответственно, всего будет 2K+1 точка приложения сил. Добавление в цепочку ещё одного модуля приводит к появлению трёх новых точек сочленения. И это всё — в самом простом, линейном случае!
Ещё бывает пространственная декомпозиция, когда имеются модули, которые имеют в системе различное назначение, или компоненты. Реберное представление графа взаимосвязей компонентов даёт оценку трудоёмкости реализации сложной системы.
Но! Декомпозиция бывает ещё и в иерархическом плане, когда имеются различные слои реализации.
Видимо следует понимать, что основная технологическая причина затягивания сроков заключается в том, что вот эту самую слоистость и многоуровневость игнорируют. Как только приходится делать шаг в новое измерение, происходит "комбинаторный взрыв". Что было бы, если бы даже при создании даже относительно простых приложений создавались (бы) все необходимые слои, модули и компоненты? (Даже если они довольно простые. )
Что это всё означает? А то, что, когда разрабатывается какая-то система, необходимо заранее определить класс этой системы, то есть — выбрать количество слоёв, определить архитектуру каждого слоя и задать зависимости между слоями. С каждым классом системной сложности связано и своё время реализации. Но тогда у клиента/заказчика будет список вариантов, где описывается, что вот такая-то система такого-то класса реализуема за такое-то время. Тогда появляется выбор. Либо такая-то более простая система "здесь и сейчас", либо более сложная система, тогда-то и тогда-то. Проблема в том, что как-только делается выбор, этот выбор должен быть реализован в полном объёме. Это и есть ответственность. А кому хочется нести ответственность?
При этом, надо понимать, что нельзя просто так ввести новое требование. Нельзя просто так взять более простую систему, что-то в неё добавить, и предъявить новый релиз. Новый релиз должен делаться с самого начала и до самого конца. Любая заплатка, костыль или переходник опять же провоцируют комбинаторный срыв сроков. Нельзя рассчитывать на высококлассного специалиста, который может составить чёткий план перехода к новому релизу в своём воображении и также чётко и без ошибок реализовать этот план.
Тут есть ещё один немаловажный аспект. Представим, что собирается новая команда разработчиков. В обычной ситуации, эта команда как можно скорее берётся за первое попавшееся дело, чтобы заработать денег, основать репутацию и притереться к друг другу. Команда, однако, может поставить для начала некоторые внутренние задачи. Например, команда может рассмотреть задачи из своей предметной области, заранее произвести их декомпозицию и реализовать базовую библиотеку для всех своих будущих проектов. Понятное дело, что в терминах этой библиотеки длительность реализации любого потенциального продукта может быть оценена с довольно высокой точностью. Отсюда и адекватный ценник на услуги, который будет представлять в таком случае шкалу увеличения системной сложности, чтобы клиент, приходя за решением конкретной задачи, заранее знал, в какую историю он ввязывается. Но такую работу никто никогда не оплатит. В результате, наука — отдельно, а практика — отдельно.
Так и живём.
А про оттяжки и проволочки ещё классик (не помню какой, у Дейтела в древней книжке по операционным системам было) сказал:
Оттяжки и проволочки — самая тяжкая форма отказа.
А мне нравится вывод в конце, действительно никак. А знаете почему никак? А потому что люди часто путают сроки, время, приоритет, планирование, стоимость и обещание заказчику. Смешивают это все вместе, называют "оценкой" и страдают. В статье я тоже эти страдания наблюдаю. А это ведь разные вещи, с разными целями. Срок может бить привязан бизнесом к какому-то событию, которое сложно сдвинуть, дедлайном называется. Настоящим, а не тем который придумывает плохой PM чтобы красиво закрыть месяц или другой период. Таким дедлайном нарушение которого бьёт по бизнесу. Иногда его даже оценивать не надо, он уже на момент оценки известен. Но иногда спрашивают и учитывают, тогда оценивать надо, вместе, ведь ситуация не частая но впжгая, так что все заинтересованные на колл и оцениваем все риски.
Время - ну тут в нас предполагаемое время на реализацию. Чистое, не привязанное к календарю, может растянутся если вдруг появится срочные задачи а эту отложить. Удобно чтобы прикинуть загрузку и в целом при планировании. Ааа оценивать - спросить разработчика. Плохо оценивает разработчик - скрам покер вам в руки. Риски? А так ли они важны для этой задачи? Компенсируют я другими оценками, можете заложить общею рисковую зону если хотите выполнять все по плану. Но и те если это вам реально нужно.
Приоритет - вот истинный инструмент менеджера. То что позволяет вам не погрязнуть в мелочах и сфокусировать продукт на важном. И всем остальным удобно. У приоритетов врожденный иммунитет к рискам и ошибкам оценки, по умолчанию. Они им просто не нужны. Кто оценивает - заказчик, вы, продукт, ну кто определяет курс продукта тот и оценивает. Ну тех специалиста можно позвать для зависимостей. Тут главное ведь что - назначил приоритет - не меняй, без чезарды в духе "это срочнее а это приоритетнее".
Планирование - ну то есть еценить так чтобы вы потом ганта красивого составили, с числами и загрузкой, все плотненько и красиво, а риски как то в задачу заложить чтобы вот ровно столько заняла сколько оценили. Ну вы в курсе, так не бывает. Поэтому аджайл и используют. И вам тоже скорее всего он пригодится. Только не уродуйте его до состояния "спринт, планирование, демо, остальное вырезаем". Примите неопределённость, осознаете невозможность строгого планирования, смиритесь и признайтесь себе что оно не так важно как вы думали, и обретете покой и гармонию.
Стоимость. Ну там же дело не только во времени программиста, особенно если вы не аутсорсеры. Да даже если и аутсорсеры, а так ли нужны заказчику стоимости каждой задачи? Может он просто так привык? Может ему достаточно грубой оценки в стори поинтах чтобы просто не пускать в работу мелочь которая будет стоить много? Абстрактно много, без привязки а валюте. Вы говорили с ним об этом? Может и ему этот хаос не нужен и он будет просто платить по dedicated team?
Ну и наконец то что встречается на самом деле и чпще всего, его величество обещание. Мы сделаем этот пакет задач к этому сроку и ни днем более . Для этого мы потратили кучу времени на оценку и зависимости, заставили вас детально сейчас продумать задачи и рассказать, даже если вы сами ещё не уверены нужна ли фича и в каком виде, нвбросили сверху рисков, потом нвбросили ещё фикс 30% на риски, отдаём вам план и общение, вот вам ещё и ганта вприлачу, чтоб красиво. Ну а вы передадите на уровень выше. И мы знаем что вам это не особо и нужно, и на уровнях выше точность до дня или нескольких на а не сдалась, и ничего срочного в этих задачах нет, и нам будет неудобно, и рисков мы наьроспли по самое нихочу из-за чего роадмапы далеки от оптимальных а цены конские, и программисты да и все мы будем в стрессе чтобы доставить к нужному сроку вот этот ничем не примечателтный в плане срочности пакет задач (мы ведь с вами знаем что реально срочеып пойдут вне пакета и поломают нам все планы и добавят стресса), но все мы будем играть в этот театр, ведь кака же без планов, для чего-то же нужны менеджеры, а диаграммы ганта красивые. На тут вы поняли, через море сарказма я пытался донести мысль "сроки и планы нужны только если они реально обоснованно нужны, иначе это гора геморроя, стрессы и падение эффективности просто так, чтобы отчетик нарисовать".
Короче определитесь что оцениваете, настройте процессы соответственно, поговорите с начальством и заказчиком, о том что реально нужно, и помните 3 максимы:
процесс, планирование, оценки - все это только инструменты для решения задач.
вы машете инструментами и затачиваете их под задачу, а не они управляют вами и задачами. Жертвы бессмысленных процессов, очень печальное и распространённое зрелище.
не усложняйте. Вот совсем. Режьте бритвой оккама все что можно, любую лишнюю активность, планируйте только то что нужно, закладывает риски только если они важны, ставьте дедлайны только тогда когда их нарушение будет огромной проблемой, работайте приоритетами а не календарём, календарь слишком не надёжная штука чтобы на него рассчитывать.
Всем привет! Читая комментарии заинтересовался почему никто не говорит о некоторых моментах, которые я постараюсь описать ниже
Полностью согласен с автором статьи в том, что исполнитель должен оценивать сроки, но есть несколько нюансов. Во-первых, большая часть разработки – это творчество. При том некоторые задачи настолько творческие, что даже сложно до конца описать. Вот к примеру есть легаси код (увы, он часто-густо есть и это реальность), вам необходимо внедрить в проект какое-то расширение, или в целом новый функционал. Вот как оценить эту задачу? Если бы это был проект с нуля – это очень просто, ведь, если нет технологий, с которыми у вас нет опыта – определить сроки можно довольно легко. Но вот в легаси всё совсем по другому, ведь новый функционал нужно связать со старым кодом – и это проблема. И тем она больше, чем больше легаси кода и чем больше проект, т.к часто, внедряя функционал, мы можем, абсолютно случайно, изменить действие каких-либо абсолютно, казалось бы, не привязанных к задаче частей программы. И нельзя сказать: "Так отдебаж и пойми", в силу огромного количества обстоятельств, которые любой, кто работал с легаси тут же поймёт. Эту задачу можно оценить только с точки зрения написания нового функционала, но сколько времени займет связывание нового со старым иногда непонятно абсолютно.
Во-вторых возникают конфликты в командах, и конфликты могут быть не только между разработчиками, но и между менеджером и разработчиком. И такие нюансы тоже невозможно до конца учесть, а мешает это ужасно. Да, такие ситуации возникают нечасто, но когда возникают – это ужас для планирования той задачи, которую выполняют люди из конфликта.
Ещё одной огромной проблемой является несостоятельность отдельных личностей из бизнеса. Очень часто возникают задачи, при которых не выделяют времени на рефакторинг (а он нужен время от времени любому проекту), требуют решения как можно скорее, т.к не хотят платить больше, не входят в положение (иногда действительно бывает, что с исполнителем что-то случилось, или ещё какой форс-мажор – и никто от этого не застрахован). А потом, порождая своими такими "решениями" легаси проект, с огромным количеством тесно связанных компонентов, костылей, требуя уже новые задачи, сваливают ответственность за это всё на исполнителей. И это, я считаю, не нормально.
Подытожив, хочу сразу предостеречь читателей моего комментария от высказываний, что я во всём виню бизнес. Нет, я знаю, что легаси действительно может возникать из-за некомпетентности программиста, и что сроки могут быть сорваны по той же причине. Но часто компании придерживаются стратегии "заказчик всегда прав", и если каждое решение программиста проходит (в основном) многоэтапное ревью, то решения заказчика на адекватность часто не проверяет никто, не желая ему перечить. Я сам сталкивался с подобным и это ужасно. Я знаю, что стараться переубеждать заказчика – задача общающегося с ним персонала компании, но попадаются действительно упертые и некомпетентные личности.
Этим всем я хочу сказать, что виноваты могут быть обе стороны конфликта, а компании, дабы не терять деньги, не отказывают откровенно некомпетентным заказчикам, что потом, в перспективе, порождает кучу конфликтов
Да, действительно, я взял себе за правило умножать первичный срок в Pi раз. Даже когда после этой операции думаешь: "Как такая тупая задача может потребовать столько времени??" Практика же показывает, что может и требует.
*Лично я занимаюсь Data Science и говорю о своем личном опыте в этой сфере.*
Действительно, иногда случается, что коэффициент Pi высоковат. И результаты, если пригорит, можно предоставить и раньше, но речь идёт не только о скорости, но и о качестве, о качестве и результата, и кода, которым он получен. Возможно, подобный результат можно получить и быстрее, но хватит ли сил тому, кто потом будут разбираться в коде, давшем быстрый результат...?
Мы работаем спринтами по три недели, с предпланированием, распределением ресурсов аналитик-разработчик-тестировщик, по каждой задаче дается три срока (оптимистик, средний, пессимистик), задачам может назначаться метка "риска переноса" и прочее.
То, что говорится здесь, о чем говорится здесь, это какой-то конец 90ых, начало нулевых. Маленькие команды, когда задачу надо решить реально вот прям за два часа. Прошлый век. Когда жава жила без лямбд. Просто не могу проверить, что кто-то еще где-то сталкивается с этими допотопными проблемами.
Есть только один способ оценить сроки - это иметь реальный опыт работы разработчиком, и чем больше этот опыт, тем лучше. Вся проблема в том, что большая часть менеджеров-болтунов-тим лидов и прочих персонажей такого опыта либо просто не имеет, либо не сосоялись как разработчики. И тут мы имеем 2 варианта развития событий). Либо разработчик, которого спрашивает такой персонаж, умножает реальный срок на 2,3,10 либо сам персонаж называет срок и обычно он не имеет никакого отношения к реальности и далее происходит конфликт.
В спагетти-коде сроки всегда непредсказуемы и занимают много времени. Это главный фактор.
Разработка всегда подрузумевает итеративность. Решение нужно не одно, а как минимум три(с минимальным изменением кода, костыльное, хак, решение за раз сразу несколько задач, переделка, идеалистическое) и выбирается оптимальное. Костыльные решения - самые долгие в итоге, это кредит времени от будущего.
Для точной оценки применяется декопозиция задачи, варианты решения и по каждой из них строится оптимистическое время, ожидаемое, пессемистическое. Сроки от балды и сроки манагеров вообще не отражают реальность.
Манагер дает максимальные сроки согласно установленному плану, так как от этого зависят все остальные задачи.
Достаточно часто, приходит менеджер/заказчик и говорит:
— ...За сколько сможешь исправить [это] на новом проекте?
— Не могу сказать... Нужно ознакомиться с задачей, посмотреть как реализовано сейчас, найти способ решения, протестировать, может что-то сломается по ходу...
— Ну хотя бы примерно?
— Примерно день-два.
— Хорошо. Начинай прямо сейчас.
Через неделю, распутывая бороду зависимостей и просмотровая сериальчики на фоне, до сих пор исправляю [это], объясняя проблему и получая по шапке.
Частая ситуация, но и решение вполне известное. Оно называется вхождение в проект. Я в таких случаях всегда говорю, что для вхождения в проект требуется 40 ч., т.е. это не решение задачи, а именно ознакомление с проектом. А уже потом можно говорить об оценке самой задачи. Если заказчика не устраивает такой подход, то дальше не имеет смысла вести дело с таким заказчиком. Конечно же это относится к средним и большим проектам. Если это просто сайт, да к тому же на известной CMS, то вхождение составляет 4 часа
Почему не работают оценки времени в проектах?