При расчёте срока проекта традиционно мы оцениваем длительность промежуточных шагов, затем их суммируем и прибавляем буфер на всякие случайности. Затем руководство режет нам этот срок вдвое. В рамках данной заметки автора будут интересовать наши расчёты, потому что даже руководитель проектов с большим опытом зачастую понимает, что рассчитанный срок слишком короткий и сильно, иногда в разы, расходится с его личной экспертной оценкой. Да, он поправит оценки сроков проекта и промежуточных шагов до своей экспертной оценки и при истинном мастерстве с некоторыми переработками уложится в срок с точностью до 15%, но осадочек останется.
Данная заметка объясняет причину расхождения экспертной и теоретически рассчитанной оценок. Также рассмотрено, почему “завышенная” экспертная оценка обычно оказывается занижена, если она не делается на основе статистических данных по выполнению аналогичных проектов. Под конец раскрыто как корректно посчитать срок проекта и объяснить ситуацию заинтересованным лицам до начала проекта или в ходе проекта.
Договор строительного подряда
Корень ошибки
Когда мы оцениваем срок реализации кусочка работы, мы определяем наиболее вероятную цифру. Это может быть экспертная оценка по одной точке или по трём точкам, как в PERT. В сложном проекте это может быть параметрическое моделирование. Во всех вариантах мы совершаем одну и ту же ошибку.
Дело в том, что во всех классических методах оценки предполагается, что у нас нормальное распределение оцениваемой величины — по Гауссу. Теоретики очень любят это распределение.
Нормальное распределение означает, что проект с корректно оценённой длительностью 6 месяцев с равной вероятностью завершится через 9 месяцев или через 3 месяца. На равных расстояниях от центра распределения вероятность завершения проекта равна — такова особенность кривой Гаусса.
С другой стороны, на практике мало кто видел IT-проект, завершившийся в два раза быстрее (через 3 месяца), зато проекты затянувшиеся в полтора раза по срокам (9 месяцев) мы видим регулярно. Кроме того, при нормальном распределении половина проектов у нас заканчивалась бы до оценённого срока, а половина — после. Но этого на практике тоже не наблюдается. Это говорит о том, что нормальное распределение для оценки сроков неприменимо. То есть у нас не нормальное распределение, а какое-то иное, с разной вероятностью завершения до наиболее вероятного срока и после.
Рассмотрим в качестве примера подобного распределения логнормальное. Оно нам покажет особенности данного класса распределений. Для логнормального распределения медиана и математическое ожидание находятся существенно дальше пика:
На представленном графике пик показывает наибольшую вероятность срока завершения проекта В план проекта обычно вписывается эта цифра плюс некий запас. Медиана указывает на точку разделения при которой половина проектов завершится до этого срока, а вторая половина — после. Математическое ожидание указывает среднее значение длительности проекта. Для фрагмента работы распределение будет иметь те же самые особенности: большую разницу между наиболее ожидаемым сроком реализации фрагмента работы (на основе него традиционно строятся планы) и средним значением срока.
Особенности закупки строительных работ по закону 44-ФЗ (28.09.2022)
Чтобы спрогнозировать длительность проекта, мы определяем самую длинную по времени цепочку и складываем длительности её фрагментов. Если мы складываем так величины, распределённые по Гауссу, то в среднем должен получиться корректный итоговый срок. Ведь половина фрагментов работы завершиться раньше срока, половина позже и эти неоднородности взаимно скомпенсируются. Чем больше фрагментов, тем точнее скомпенсируются неоднородности. Плюс мы можем посчитать погрешность и чуть сдвинуть срок на сигму-другую в зависимости от последствий срыва сроков.
Но у нас не распределение Гаусса. У нас удлинение срока выполнения каждого фрагмента работы значительно вероятнее, чем укорачивание на такую же величину. В итоге, если мы складываем сроки наиболее вероятного завершения каждого фрагмента работы, то у нас неоднородности по срокам выполнения не компенсируются, а усиливаются.
Причём усиливаются в сторону удлинения реального среднего срока проекта по сравнению с оценкой. Что мы и наблюдаем в реальной жизни: если первый срок просрочен, то будут просрочены и все остальные сроки, при этом просрочка будет только расти. Лишь прикладывая дополнительные усилия можно остановить рост отставания проекта.
Особенностью данного способа подсчёта является известный факт: чем мельче дробить работы для оценки срока проекта, тем менее точной оказывается оценка. Хотя по теории должно быть ровно наоборот. Причина этого в том, что наша экспертная оценка для всей работы и для составляющих её частей берётся из опыта. Опыт оценивает каждый элемент независимо, а не исходя из арифметики, согласно которой длительность работы должна быть суммой длительностей составляющих её частей. Арифметика здесь не работает, так как сумма наиболее вероятных сроков завершения частей не даёт наиболее вероятный срок завершения всей работы — корректно суммировать можно только математические ожидания.
Если мы пытаемся чуть сдвинуть оценённый срок для всего проекта или его частей на сигму-другую, считая распределение нормальным, то это не сильно помогает, так как хвост распределения сильно толще, чем у кривой Гаусса. В итоге, за счёт такого увеличения оценки срока не удаётся дойти даже до медианы, не говоря уже о среднем значении длительности проекта в виде математического ожидания.
Что делать
С одной стороны, складывать следует математические ожидания. С другой стороны, мы не математики. Мы из реальной жизни и понимаем проблемность расчёта параметров графиков даже когда на это есть время и какая-то накопленная статистика. Но есть другие пути. В конце-концов, проблеме оценки сроков не один десяток лет и с этим практики работать научились.
Метод Брукса: считаем срок реализации программы “в лоб” (пользователем выступает сам программист) и умножаем на 3 для программного продукта (пользователем выступает неограниченный круг лиц) или программного комплекса (в текущих реалиях — набор микросервисов) и на 9 для системного программного продукта (в текущих реалиях — набор связанных инфраструктурных компонентов). Откуда берутся такие коэффициенты хорошо теоретически обосновано в первой главе книги Брукса “Мифический человеко-месяц” и это описание 1975 года хорошо перекладывается на текущие реалии.
Метод Скрама: вводим абстрактную промежуточную единицу трудоёмкости реализации функционала, смотрим статистику реализации командой измеренного в данных единицах функционала, просим команду оценить трудоёмкость задач проекта, переводим единицы в Скрам-итерации (спринты) известной длины и получаем оценку сроков для данной команды разработки. Так как мы работаем с реально собранной статистикой и команда отвечает за свои оценки по трудоёмкости, то привязка длительности к единице трудоёмкости является математическим ожиданием и поэтому половина спринтов будет заканчиваться чуть раньше, половина чуть позже. На практике в половине итераций Скрама придётся у команды забрать часть задач, а в половине добавить незапланированных, чтобы длина спринта оставалась постоянной.
Задача переноса Скрам-оценки одной команды на другую команду является искусством. Они не переносятся простым введением коэффициента перевода единиц трудоёмкости одной команды в единицы трудоёмкости другой команды.
Дело в том, что одна команда имеет в своём составе хорошего фронтендера, но в ней нет хорошего специалиста по базе, а другая команда имеет хорошего специалиста по базе, но фронтовые задачи для неё повышенной сложности. Отличия в специализации разработчиков приведут к тому, что относительно бэкендовых задач у одной команды будет перегиб по сложности в сторону задач по базе данных, а у другой — по фронту. Кроме того, команда сама определяет необходимый уровень внутреннего качества продукта и разные команды определяют его несколько иначе, чем соседние команды, что также затрудняет пересчёт единиц трудоёмкости. То есть можно перевести промежуточные единицы одной команды в промежуточные единицы другой команды сравнивая оценки схожих задач, но эти задачи должны браться из разных типов деятельности, с учётом сильных и слабых сторон команд и с учётом особенностей настройки их Скрамов.
Метод функциональных элементов: вводим промежуточную единицу трудоёмкости, составляем список функциональных элементов (экраны в браузере, микросервисы, настраиваемые элементы инфраструктуры и т.д.), оцениваем трудоёмкость работы над каждым функциональным элементом в промежуточных единицах. После этого по своему экспертному опыту работы с конкретной командой разработчиков оцениваем переводной коэффициент промежуточной единицы во время. Лично я ещё независимо оцениваю переводные коэффициенты для разных видов деятельности: аналитики, проектирования, написания постановок задач, написания кода, вёрстки, тестирования, интеграции и т.д. После этого следует учесть порядок операций, характерное время задержки между завершением предыдущей операции и началом новой и определить длительность проекта методом критического пути.
До сих пор мы работали с внутренними факторами проекта. Но у нас есть и внешние: внешние подрядчики, смежные подразделения, поставщики и клиент. Проблемы с ними ровно те же самые: они в два раза быстрее делают или отвечают сильно реже, чем в полтора раза дольше наиболее вероятного значения. То есть там тоже нет нормального распределения по срокам. Это тоже следует закладывать и учитывать на основе статистики работы с клиентами, подрядчиками и смежными подразделениями и, по возможности, защищаться с помощью штрафных санкций.
Обоснование сроков
И вот, мы оценили прогнозную длительность проекта. Как обосновать полученный срок? На основе проделанных расчётов. Например, автор заметки для не-Скрам проектов обычно делает в Google Sheets большую многострочную наглядную таблицу с детальным расчётом методом функциональных элементов.
Расчёт опирается на практику, все коэффициенты и параметры наглядны, а практика для заинтересованных лиц обычно является сильным и хорошим аргументом, даже если получился неудобный для тех или иных лиц срок. Особенно практика наглядная и полученная в рамках текущей компании.
Согласятся ли заинтересованные лица, например руководство, с хорошо проделанной и донесённой оценкой по срокам? Далеко не всегда даже если заинтересованные лица полностью понимают и осознают, что оценка корректная. Иногда оценка неприемлема по внешним причинам, но это уже боль заинтересованных лиц, выливающаяся в трудном решении руководства по срокам.
И тем не менее, видя опирающиеся на опыт расчёты, руководство и иные заинтересованные лица имеют возможность предсказуемо повлиять на итоговый срок проекта выделением дополнительных ресурсов и полномочий. Иногда понявшее ситуацию со сроками руководство будет продолжать резать сроки без выделения дополнительных ресурсов и полномочий. Как с этим жить — тема отдельной заметки.
Источник: habr.com
Влияние организационно-технологической сложности на сроки выполнения работ Текст научной статьи по специальности «Строительство и архитектура»
СТРОИТЕЛЬСТВО / ПРОДОЛЖИТЕЛЬНОСТЬ РАБОТ / СТАТИСТИЧЕСКИЙ АНАЛИЗ / УРАВНЕНИЕ РЕГРЕССИИ / СИСТЕМА УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ / CONSTRUCTION / JOB DURATION / STATISTICAL ANALYSIS / REGRESSION EQUATION / REQUIREMENTS MANAGEMENT SYSTEM
Аннотация научной статьи по строительству и архитектуре, автор научной работы — Дорогань Игорь Александрович
Введение. Важным показателем эффективности организации строительства является продолжительность строительства , которая зависит от сроков выполнения отдельных работ.
Особенно это характерно для крупных проектов строительства общественных зданий, к которым относятся здания медицинских организаций, представляющие собой сложные в объемно-планировочном и технологическом отношении здания. Известно, что на продолжительность работ влияют их трудоемкость и численность рабочих.
Однако остается неизученным влияние сложности работ, которое может быть выражено средним разрядом рабочих и количеством требований, предъявляемых к результатам работ. Кроме того, не изучен нелинейный характер зависимостей. Материалы и методы. Для изучения характера процессов и обоснования необходимости управления требованиями было проведено статистическое исследование.
На материале данных о трудоемкости, сложности и продолжительности работ , численности рабочих при строительстве здания НИИ детской онкологии и гематологии Научно-медицинского центра онкологии им. Н.Н. Блохина в г. Москве составлено уравнение регрессии , определены коэффициенты корреляции и детерминации. Значимость коэффициентов оценена с помощью критерия Стьюдента.
Результаты. Проведенные исследования обнаружили нелинейную зависимость рассмотренных факторов от продолжительности работ , причем средний разряд работы оказывает малое влияние и может быть исключен из числа влияющих факторов. Напротив, количество выдвигаемых требований оказывает заметное влияние, что говорит о необходимости управления требованиями в процессе строительства . Выводы. Для сокращения продолжительности работ необходимо создавать систему управления требованиями, которая позволит одновременно повысить качество выполняемых работ. В дальнейшем целесообразно провести исследования на материале других строительных объектов.
Похожие темы научных работ по строительству и архитектуре , автор научной работы — Дорогань Игорь Александрович
Твердение строительных композиционных материалов на основе магнезиального вяжущего в различных температурных условиях
The influence of organizational and technological complexity on the period of job execution
Introduction. An essential index of the efficiency of the construction organization is its building period, which depends on the timing of individual work items. It is especially significant for large projects of public buildings including ones of medical establishments being complicated installations regarding their space-and-planning and technological aspects. It is known that the job duration is influenced by its complexity and number of workers assigned for it. However, the influence of the job complexity remains unexplored.
It can be expressed by the average job grade and quantity of requirements for the job results. In addition to this, the nonlinear feature of the dependencies is not studied. Materials and methods. A statistical study was conducted to examine the feature of the processes and the reason for managing requirements. It was based on the data of the job labor content, complexity and duration, the number of workers during the construction of the Research Institute of Pediatric Oncology and Hematology building of the Scientific Medicine Centre of Oncology named after N.N. Blokhin in Moscow.
The analysis showed the regression equation , the correlation, and determination coefficients. The significance of the coefficients was estimated using the Student’s criterion. Results. The study demonstrated a nonlinear dependence on the factors considered on the job duration . However, the average job grade is of a minor effect and can be excluded from the influencing factors. On the contrary, the quantity of requirements has a significant impact, which indicates the need to manage the requirements in the course of construction . Conclusions.
To reduce the job duration , it is necessary to create a requirements management system that will also improve the quality of the performed work. In the future, it is expedient to conduct research on other construction projects.
Текст научной работы на тему «Влияние организационно-технологической сложности на сроки выполнения работ»
УДК 658.51:69.05 DOI: 10.22227/1997-0935.2019.10.1331-1340
Влияние организационно-технологической сложности на сроки выполнения работ
Алмаз-СП; г. Москва, Россия
Введение. Важным показателем эффективности организации строительства является продолжительность строительства, которая зависит от сроков выполнения отдельных работ.
Особенно это характерно для крупных проектов строительства общественных зданий, к которым относятся здания медицинских организаций, представляющие собой сложные в объемно-планировочном и технологическом отношении здания. Известно, что на продолжительность работ влияют их трудоемкость и численность рабочих. Однако остается неизученным влияние сложности работ, которое может быть выражено средним разрядом рабочих и количеством требований, предъявляемых к результатам работ. Кроме того, не изучен нелинейный характер зависимостей.
Материалы и методы. Для изучения характера процессов и обоснования необходимости управления требованиями было проведено статистическое исследование. На материале данных о трудоемкости, сложности и продолжительности работ, численности рабочих при строительстве здания НИИ детской онкологии и гематологии Научно-медицинского центра онкологии им. Н.Н.
Блохина в г. Москве составлено уравнение регрессии, определены коэффициенты корреляции и детерминации. Значимость коэффициентов оценена с помощью критерия Стьюдента. Результаты. Проведенные исследования обнаружили нелинейную зависимость рассмотренных факторов от продолжительности работ, причем средний разряд работы оказывает малое влияние и может быть исключен из числа влияющих факторов. Напротив, количество выдвигаемых требований оказывает заметное влияние, что говорит о необходимости управления требованиями в процессе строительства.
Выводы. Для сокращения продолжительности работ необходимо создавать систему управления требованиями, ^ е которая позволит одновременно повысить качество выполняемых работ. В дальнейшем целесообразно провести ¡Л 2 исследования на материале других строительных объектов. 2. н
КЛЮЧЕВЫЕ СЛОВА: строительство, продолжительность работ, статистический анализ, уравнение регрессии, ^
система управления требованиями U С
ДЛЯ ЦИТИРОВАНИЯ: Дорогань И.А. Влияние организационно-технологической сложности на сроки выполнения работ // Вестник МГСУ. 2019. Т. 14. Вып.
10. С. 1331-1340. DOI: 10.22227/1997-0935.2019.10.1331-1340 3 со
The influence of organizational and technological complexity on the period
of job execution
In addition to this, the nonlinear feature of the dependencies is not studied.
Igor A. Dorogan u ^
Almaz-SP; Moscow, Russian Federation a N —§ 2
Introduction. An essential index of the efficiency of the construction organization is its building period, which depends on > §
the timing of individual work items. It is especially significant for large projects of public buildings including ones of medical h o
establishments being complicated installations regarding their space-and-planning and technological aspects. It is known e o
that the job duration is influenced by its complexity and number of workers assigned for it. However, the influence of the job u i
complexity remains unexplored. It can be expressed by the average job grade and quantity of requirements for the job results. o e
Materials and methods. A statistical study was conducted to examine the feature of the processes and the reason for O °
managing requirements. It was based on the data of the job labor content, complexity and duration, the number of workers ^ 1
during the construction of the Research Institute of Pediatric Oncology and Hematology building of the Scientific Medicine o 4
Centre of Oncology named after N.N. Blokhin in Moscow. The analysis showed the regression equation, the correlation, and 4 B determination coefficients. The significance of the coefficients was estimated using the Student’s criterion.
Results. The study demonstrated a nonlinear dependence on the factors considered on the job duration. However, the S y
average job grade is of a minor effect and can be excluded from the influencing factors. On the contrary, the quantity of go
requirements has a significant impact, which indicates the need to manage the requirements in the course of construction. ° 1
Conclusions. To reduce the job duration, it is necessary to create a requirements management system that will also improve O O the quality of the performed work. In the future, it is expedient to conduct research on other construction projects.
Распространяется на основании Creative Commons Attribution Non-Commercial (CC BY-NC)
KEYWORDS: construction, job duration, statistical analysis, regression equation, requirements management system
FOR CITATION: Dorogan I.A. The influence of organizational and technological complexity on the period of job execution. Vestnik MGSU [Monthly Journal on Construction and Architecture]. 2019; 14(10):1331-1340. DOI: 10.22227/19970935.2019.10.1331-1340 (rus.).
Продолжительность строительства и сроки выполнения отдельных работ являются важным показателем эффективности организации строительства в целом. Особенно это характерно для крупных проектов строительства общественных зданий, к которым относятся здания медицинских организаций, представляющие собой сложные в объемно-планировочном и технологическом отношении здания [1].
Сложные схемы компоновок лечебных зданий даны в работах1 [2]. В руководстве2 приведены общие параметры и требования к медицинским зданиям, а в трудах [3, 4] содержатся основы проектирования медицинских зданий и сооружений. Указывается также на важную роль предпроектного планирования с учетом потребностей клиентов и врачей [5]. Дополнительные проблемы при проектировании медицинских зданий возникают при использовании высокотехнологичных видов медицинской помощи, таких как радиологическая диагностика и ядерная медицина [6, 7].
При проектировании и строительстве таких зданий необходимо учитывать требования радиационной безопасности [14, 18]. Строительство часто включает большой объем работ по монтажу и наладке разнообразного технологического оборудования, требует согласований, соблюдения разнообразных местных норм [8, 9]. Реконструкция подобных зданий часто производится без прекращения лечебной деятельности, поэтому к составу работ добавляются процессы разборки, реконструкции, реновации [13, 15].
К результатам проектных и строительных работ при возведении и реконструкции медицинских зданий предъявляются разнообразные требования, обусловленные как медико-техническим заданием заказчика, так и техническими нормами [16]. В связи с этим было рекомендовано использование системы управления требованиями для повышения качества
1 Concevoir et construire un hôpital : hôpitaux, cliniques, centres ambulatoires. Paris : Éd. «Le Moniteur», 2014. 389 p.
2 Hôpitaux А. — трудоемкость 1-й работы, в человеко-днях; N — численность рабочих, чел./день.
Однако в некоторых источниках4 ставится вопрос о том, что простая линейная зависимость (1) недостаточно адекватно отображает сложные процессы строительного производства. Например, на
3 IBM Engineering Requirements Management DOORS Next. URL: www.ibm.com/us-en/marketplace/requirements-management-doors-next/details (дата обращения: 06.06. 2019).
4 Методические рекомендации определения стоимости работ по сохранению объектов культурного наследия на основе банка данных о стоимости работ объектов-аналогов. М. : Министерство культуры РФ, 2009.
большом фронте работ, который характеризуется высокими трудозатратами, строительная бригада может развить более высокую производительность труда, чем на малом фронте работ. С другой стороны, большое количество рабочих на узком фронте работ приводит к «толкотне», отчего производительность труда падает. Кроме того, более сложные работы обычно занимают больше времени, что формулой (1) никак не учитывается. Как правило, строители-практики интуитивно соглашаются с этими положениями, однако доказать это не могут.
Для определения влияния отмеченных факторов было выполнено статистическое исследование на базе данных по организации строительства (с элементами реконструкции) в 2015-2016 гг. корпуса «А» НИИ детской онкологии и гематологии Научно-медицинского центра онкологии им. Н.Н. Бло-хина. Этот корпус, выполненный в монолитных железобетонных конструкциях, отличается набором строительных, монтажных и пусконаладочных работ различной сложности и различного объема. Поскольку здания ядерной медицины имеют черты как промышленных, так и гражданских объектов, они хорошо подходят для сравнительного изучения организации строительства с участием бригад различного профиля.
Для проведения исследований предложено проанализировать влияние основных факторов на продолжительность работ: проектных трудозатрат, фактической численности бригады и сложности работ. Сложность в данном случае является не абстрактной характеристикой, а конкретным показателем строительного производства.
С одной стороны, технологическая сложность может быть оценена средним разрядом рабочих звена, что, однако, не учитывает организационные сложности строительства. Для обобщенного учета сложности работ предлагается учесть также количество требований, предъявляемых к результатам работ и к процессу их выполнения. В самом деле, большее количество требований вызывает необходимость большей интенсивности и тщательности проверок, неоднократных исправлений замечаний контролирующих лиц. Естественно, это вызывает дополнительные затраты времени.
Для учета сложности работ было проанализировано количество требований, предъявляемых к производству и к результатам работ (технические требования третьего уровня, см. ниже). Как правило, по каждой работе можно выделить от 5 до 25 и более требований, подтвержденных нормативно-техническими требованиями, заданием заказчика и проектной документацией.
Следует отметить, что набор требований, предъявляемый на этапе выполнения строительно-
монтажных работ, лишь частично соответствует требованиям, предъявляемым заказчиком на этапе проектирования. Например, требования к расположению помещений и их размеру, характерные для разработки объемно-планировочного решения, практически не актуальны для выполняемых строительно-монтажных работ. Напротив, технологические требования к производству работ, от которых во многом зависит качество строительства, в проектной документации обычно выражены в самом общем виде.
Фрагмент перечня требований, предъявляемых к технологии и результатам строительно-монтажных работ, приведен в табл. 1.
Поскольку требования к технологии работ слишком многочисленны, они показаны укруп-ненно. Так, для точности установки опалубки монолитных железобетонных конструкций в СП 70.13330.2012 и ГОСТ 34329-2017 приведено около 30 показателей. В табл. 2 они объединены в одно интегральное требование точности установки опалубки. Это связано с тем, что служба заказчика может привлекать для верификации требований экспертов, дающих интегральную оценку качеству работ.
Было выдвинуто предположение о нелинейном характере зависимости между затратами труда, численностью рабочих, сложностью работ и их продолжительностью. В качестве математического выражения гипотезы о нелинейном характере зависимости предложена формула
где С, т, п, k, I — константы, определяемые статистическим путем; R. — количество требований, предъявляемых к I-й работе; Q . — средний разряд -й работы.
Для проведения статистического анализа составлен перечень из 106 отдельных строительных, монтажных и пусконаладочных работ. Как правило, каждая из этих работ выполнялась одной комплексной или специализированной бригадой в две (реже — в три) смены, средняя численность которой определялась по фактическим записям в журнале работ и по табелям выхода на работу.
Для каждой из данных работ на основе сметной документации, составленной по ГЭСН-2001 и ГЭСНм-2001, были вычислены проектные трудозатраты в человеко-часах, включая трудозатраты машинистов. Самые мелкие работы с затратами труда менее 100 человеко-часов объединены с однородными более крупными работами. Количество требований определено в соответствии с табл. 1. Фрагмент полученных таким образом статистических данных приведен в табл. 2.
Для того чтобы использовать методы регрессионного анализа для линейных статистических за-
Источник: cyberleninka.ru
Как научиться правильно определять сроки выполнения работы — отвечают эксперты
Зачастую разработчики, особенно неопытные или прошедшие только сертификацию в IT, теряются, когда их просят обозначить сроки выполнения задач. Однако умение планировать — это то, что должен знать даже новичок и развивать по мере профессионального развития. Мы решили узнать у экспертов, как научиться правильно планировать и сдавать проекты вовремя.
Краткие выводы можно посмотреть в конце статьи.
Разработчику обычно требуется учесть сразу несколько параметров, чтобы оценить время выполнения задачи:
- Опыт выполнения таких заданий и работы с данным технологическим стеком. Если предстоит делать что-то принципиально новое, нужно быть особенно осторожным с оценкой.
- Опыт работы с данным клиентом. Зная заказчика, можно примерно предугадать некоторые дополнительные требования и объём правок.
- Качество кода, с которым предстоит работать. Это — самый влиятельный фактор, из-за которого всё может сильно затянуться и вообще пойти не по плану. Если в проекте есть тесты, везде только явные зависимости и функциональность хорошо изолирована, всё не так страшно. Намного хуже, если вы имеете дело с легаси-кодом без тестов или с кодом, перенасыщенным неявными зависимостями. Осложнять дело могут также такие вещи, как «магические функции» (когда по коду тяжело увидеть конечный стек вызовов) и дублирование кода (когда для изменения какой-либо функциональности нужно править несколько независимых участков).
Чтобы научиться адекватно оценивать сроки работы, нужно постоянно практиковаться. В начале своей работы я поступал именно так: оценивал время на выполнение любой входящей задачи, даже если этого никто не требовал, а потом смотрел, насколько точно удалось попасть в свою оценку. В процессе выполнения задачи отмечал, какие действия занимают больше времени. Если что-то сильно увеличивало срок, запоминал этот момент и учитывал его в следующих оценках.
К объективной оценке времени, нужного чисто на работу, следует прибавлять небольшой запас для покрытия форс-мажорных ситуаций. Его часто оценивают в процентах от выполнения основной задачи, но у всех он разный: кто-то прибавляет 20 % времени, кто-то — 10 %, а кто-то — 50 %.
Полезно также анализировать причины срывов сроков после каждого серьёзного нарушения дедлайна. Если не хватило квалификации, нужно поработать над своими слабыми местами. Если проблема была организационной — понять, что помешало нормально работать.
Методикам оценки трудоёмкости проекта, включая длительность работ и отдельных задач, посвящено большое количество статей. Однако до сих пор это является причиной возникновения конфликтов как внутри проектной команды, так и при общении с заказчиком.
Основной помощник в оценке — опыт. Попробуйте как-то сопоставить новую задачу с уже сделанными. Если вы делаете отчёт, посмотрите, сколько по времени занял похожий отчёт в прошлом. Если вы делаете что-то новое, попробуйте разбить на известные части и оценить их. Если задача совсем новая, выделите время на изучение (ещё лучше — согласуйте это время с тем, кто ставит задачу).
Обратите внимание на сопутствующие этапы — если нужно разработать сервис, то в оценку необходимо включить также и юнит-тестирование (а может, и не только юнит), определённое время займёт подготовка тестовых данных. Следует продумать интеграцию с другими сервисами и т. д. Заложите время на исправление дефектов, которые вы найдёте самостоятельно или с помощью тестировщиков. Много времени может утекать в «незаметные» задачи. Например, есть оценка по разработке и есть оценка по тестированию, но передача артефакта на тестирование может быть сопряжена с разворачиванием стендов. Поэтому важно мысленно себе представить весь процесс, чтобы ничего не упустить.
После определения трудоёмкости необходимо включить новые работы в календарь, не забыв про другие задачи и активности, которые идут параллельно.
И не забывайте, что планы бесполезны, но планирование бесценно. Учитесь вовремя корректировать планы, держать в курсе всех заинтересованных и своевременно эскалировать, чтобы проваленные сроки не оказались ни для кого неожиданностью.
Вопрос, на который невозможно ответить в краткой форме. Если бы это было просто, то проблемы нарушения сроков не существовало бы.
Чтобы сделать сроки окончания разработки более предсказуемыми, надо сначала понять причины, по которой программисты постоянно ошибаются.
Первая причина — большинство задач, которые делает программист, являются в той или иной степени уникальными. То есть, скорее всего, программист будет делать подобную задачу в первый раз. Он недостаточно хорошо представляет, сколько займет эта работа. Если это программист с солидным опытом и ему приходилось выполнять подобную задачу, его оценка будет ближе к реальности.
Прибегнем к простой аналогии — если вы никогда не копали канавы, вы не можете точно сказать, сколько времени у вас займет выкопать траншею 30 см шириной, 60 см глубиной и 20 метров длинной. Если вы раньше копали, оценка времени работы у вас будет гораздо ближе к фактической длительности работы.
Вторая причина — программисты по своей природе оптимисты. То есть, рассматривая задачу, подбирая для неё вариант реализации, давая оценку доработкам, разработчик ожидает, что всё будет работать так, как он предполагает. И не думает о тех проблемах, что ему встретятся на пути. Зачастую он и не может их предвидеть.
Например, есть задача, которую программист может реализовать, используя стороннюю open-source программную библиотеку. На этапе оценки он нашел её в интернете, прочитал её описание — она ему подходит. И он даже верно оценил объём своей работы, чтобы встроить использование этой библиотеки. Но он совсем не предусмотрел, что в окружении его программного продукта в этой библиотеке возникнет ошибка.
Разработчику придётся не только встроить использование библиотеки в свой код, но и исправить ошибку в самой библиотеке. А ещё зачастую разработчик не предусматривает время на исправление своих ошибок. Как показывает статистика, тестирование и исправление ошибок может занимать порядка 50 % от времени, что было затрачено на кодинг. Цифра зависит от квалификации разработчика, окружения, используемых практик разработки (например, юнит тесты существенно это время сокращают и итоговая длительность/трудоёмкость задачи по разработке получается меньше).
Если вернуться к аналогии с землекопом, то землекоп не предполагал, что у него сломается лопата и придётся потратить два часа на поиски нового черенка.
Третья причина — непредусмотренные требования. Ни в одной области материального производства, с которыми так любят сравнивать заказчики разработку ПО, нет такого потока новых требований. Представьте себе пассаж землекопа, который выкопал 19 метров из 20 и услышал от заказчика пожелание, чтобы канава шла не по прямой, а змейкой с длиной плеча 97 сантиметров.
Как со всем этим бороться и как жить в условиях подобной неопределённости? Уменьшая неопределённость и закладывая резерв времени.
Самый простой способ привести свои ожидания ближе к реальности — это использовать шутливое эмпирическое правило «Пи». Получив оценку от разработчика (по срокам или трудоёмкости), надо умножить её на число Пи (= 3,14159). Чем более опытный разработчик делал оценку, тем меньше может быть этот коэффициент.
Обязательной является практика декомпозиции исходной задачи до маленьких задач размером не более 4 часов. Чем детальнее выполнена декомпозиция, тем выше шансы, что оценка окажется близка к фактической трудоёмкости/длительности.
Если вернуться к выделению резерва — это время должно быть выделено в конце проекта. Плохая практика делать резерв и включать его для каждой задачи. Закон Паркинсона «Работа заполняет всё время, отпущенное на неё» выполняется неукоснительно.
Если подвести краткое «итого», то чтобы правильно определить сроки выполнения работы, полезны будут следующие действия:
- выполнить декомпозицию работ, разбить задачу на как можно более детальные шаги;
- провести прототипирование;
- ограничить реализацию непредусмотренных ранее требований. Это не значит, что их не надо делать, но целесообразно выделять эти требования и согласовывать с заказчиком изменение сроков и стоимости для их реализации;
- учесть время на стабилизацию решения;
- использовать практики повышения качества кода, например писать юнит тесты;
- заложить общий резерв.
Ну, и помнить, что если факт превышает вашу оценку на 30 % — то это очень хороший результат.
Для максимально точной оценки нужен опыт реальной разработки, причём именно в конкретной области. Но есть и общие правила, которые помогут избежать ошибок в планировании и проблем при сдаче работы заказчику. Я бы описал эти правила так.
Во-первых, нужно понять задачу. Это вроде бы очевидно и не относится напрямую к оценке сроков, но на самом деле это ключевой момент. Даже в серьёзных крупных проектах одним из основных факторов неудачи и затягивания сроков является проблема в определении требований. У начинающих разработчиков, к сожалению, это серьёзная проблема — не читают ТЗ или читают и понимают очень избирательно (из десяти пунктов запомнили и выполнили пять, а про оставшиеся вспомнили уже при сдаче результата). Понятно, что неправильно понятую задачу невозможно правильно реализовать в срок.
Далее — оценить само время на разработку. Особенность программирования в том, что не бывает абсолютно одинаковых задач. Это делает нашу работу интереснее, но оценку сроков — сложнее. Здесь хорошо работает декомпозиция, т.е. разделение сложной уникальной задачи на последовательность маленьких знакомых подзадач. А каждую из них уже можно оценить в часах достаточно адекватно.
Сложим оценки подзадач — и получим оценку всей задачи.
Как правило, такая оценка включает в себя только затраты непосредственно на кодирование. Это, безусловно, самая важная часть разработки, но далеко не единственная (а часто — и не самая объёмная). Полное выполнение задачи включает в себя еще чтение и прояснение ТЗ, встречи с коллегами или заказчиком, отладку и тестирование, составление документации, сдачу результата (демонстрацию заказчику и возможные переделки по его замечаниям). Сколько именно времени у вас уйдёт на эти действия, подскажет только опыт. На первых порах важно, как минимум, не забыть их учесть в расчётах, а примерную оценку времени можно спросить у более опытных коллег.
Итак, мы берём оценку трудозатрат на кодирование, добавляем оценку затрат на дополнительные работы — и получаем искомую оценку времени на выполнение задачи. Но и это ещё не всё! Нужно обозначить планируемую дату завершения задачи. Ошибкой будет просто взять и разделить трудозатраты (в часах) на 8 часов и прибавить к текущей дате.
В реальной практике разработчик никогда (ну ладно, почти никогда) не работает 100% времени над одной конкретной задачей. У вас обязательно будет уходить время на другие работы — важные, но не связанные напрямую с главной. Например, помощь коллегам, обучение, составление отчётов и т.п.
Обычно при планировании считают, что непосредственно на работу над текущим проектом уходит 60-70% рабочего времени. Дополнительно надо учесть ещё возможные задержки, которые не дадут вам непрерывно работать над задачей. Например, если для этого вам нужно взаимодействовать с другими людьми (коллегами, заказчиками), то учитывайте их занятость, график работы и т.п.
Вот основные правила, которые, на мой взгляд, помогут разработчику избежать проблем в оценке и соблюдении сроков. Кроме этого, ключевым является накопление собственного опыта как в реализации задач, так и в оценке. Например, очень полезно после завершения задачи сравнивать свою первоначальную оценку с фактическими сроками и делать выводы на будущее. И, конечно, стоит изучить чужой опыт. Я бы порекомендовал по теме книги С. Макконнелла «Сколько стоит программный проект» и С. Архипенкова «Лекции по управлению программными проектами».
Источник: tproger.ru