Что значит продолжительность проекта
Как оценить длительность IT-проекта, а когда это вообще не стоит делать
Все хотят знать, сколько времени займёт проект. В этой статье мы объясним, как предоставить менеджеру одновременно точный и неопределённый прогноз, используя время цикла и подсчёт историй, а также дадим советы, когда следует вообще избегать оценки.
Селеста чувствовала давление. Её менеджер Барри хотел составить квартальный прогноз работы её команды. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём. Каждый из них являлся частью другого проекта.
У программистов из группы Селесты не было достаточно информации для составления хоть какого-нибудь прогноза, тем более на целый квартал.
Селеста решила признаться Барри и посмотреть, к чему они придут. Она назначила встречу на следующий день и собрала данные.
Девушка прибыла в офис Барри ровно в 10 утра. Когда она постучала в дверь, Барри всё ещё говорил по телефону. Он жестом попросил её войти и поднял один палец, чтобы дать понять: он будет готов через минуту.
Она села в кресло для посетителей напротив его стола.
Барри повесил трубку и повернулся: «Что ж, обсудим сроки проектов, так?»
Селеста кивнула и сказала: «Да. Кажется, вот что можно сделать в такой ситуации».
Барри нахмурился: «Кажется? Мне нужны конкретные обязательства. Никаких „кажется”!»
Селеста села поудобнее: «Барри, на тебя давят, чтобы выпустить эти три продукта?»
«Как ты узнала? — Барри покачал головой. — Если послушать ребят из продаж и маркетинга, то случится катастрофа, если мы сейчас их не выпустим. Не знаю, что им ответить, кроме того, что всё будет».
«Но в прошлом месяце вы же обсуждали портфель проектов, — напомнила Селеста. — Я думала, продукт А был главным приоритетом».
«Так и есть, — сказал он. — И продукты B и C тоже являются главным приоритетом».
Селеста закатила глаза: «Но ты же знаешь, что может быть только один главный приоритет, не так ли?»
«Я это знаю, и ты знаешь, — сказал он. — Но мои коллеги не знают. Мне нужен прогноз, что ты можешь сделать — ну, обязательства — и тогда можно будет немного вздохнуть спокойно».
«Над каким продуктом нам работать в первую очередь?», — спросила Селеста.
«Продукт А, конечно, — сказал он. — Он самый окупаемый».
«Хорошо, вот что мы сделаем, — сказала Селеста. — Мы напряжёмся и выпустим А в течение месяца. Ваша задача — заставить этих милых людей посещать наши презентации каждую неделю. Они должны увидеть, что мы делаем за неделю. Если они не придут на демо, я отказываюсь давать им какую-либо информацию».
Барри откинулся назад: «Погоди. Я понял насчёт демо. А что в остальные два месяца? И почему ты не дашь им никакой информации?»
Селеста сказала: «Если бы мы работали только над одним продуктом, я могла бы рассчитать оценку на основе нашего цикла разработки. Для продукта А мы выпускаем три-четыре истории [код для пользовательских задач] в неделю. Но мы не знаем реального цикла разработки для продуктов B и C».
Барри кивнул: «Почему нет?»
«Продукты B и C запланированы через два и три месяца, — сказала Селеста. — Это довольно далеко для маркетинга. Проблема в том, что чем дальше работа, тем меньше „времени” отдел маркетинга работает с владельцем продукта для уточнения историй. Мы понятия не имеем, какие функции нужно будет реализовать через два и три месяца. Нам пришлось бы делать научно обоснованные предположения на пустом месте (scientific wild-ass guess, SWAG). Это нормально, мне нравится заниматься этим со своими ребятами, но нам нужно больше конкретики. Которой нет».
«Так почему ты ничего им не скажешь, если они не придут на демонострацию?» — спросил Барри.
«Если для них недостаточно важно наблюдать наш прогресс и обеспечить обратную связь, то им не слишком важна оценка по срокам, — сказала Селеста. — Они хотят, чтобы мы взяли на себя обязательства, не давая своих обязательств взамен. Почему я должна тратить время на оценку, если они не хотят вносить свой вклад?»
Барри согласился «продать» месячный «таймбокс» менеджерам, которые давят на него по установке сроков. Селеста будет следить, что команда сосредоточилась только на продукте A. И она назначила еженедельные встречи для демонстраций, чтобы команда показала свою работу и получила обратную связь.
Был бы у вас соблазн сделать всё иначе?
Оценка сроков — нетривиальная работа
Оценка сроков — это тоже работа. Многие команды закладывают проведение такой проуедуры в свой регулярный рабочий график. Тем не менее, точная оценка на квартал часто требует больше часа или двух работы.
Есть как минимум две проблемы оценки квартальной работы. Слишком часто требования не полностью определены и, как с командой Селесты, проведение оценки отрывает команду от срочной работы над проектом.
Проблема в том, что планирование разработки ПО не похоже на планирование дорожной поездки. Если в вашем городе больше одного светофора, то вы знакомы с колебаниями трафика. Я живу в пригороде Бостона, откуда поездка в аэропорт может занять и 20, и 90 минут. Чаще всего от 30 до 45 минут. Это существенная вариация для 13-километровой поездки.
И в такой поездке нет никаких инноваций. Я много раз ездила в аэропорт и знаю несколько способов добраться туда. У меня есть мобильные приложения, которые помогают найти самый быстрый маршрут даже по пути. Хотя некоторые варианты чуть более предсказуемые, ни один из них не может гарантировать, что эта конкретная поездка завершится за 20 минут.
Поездка в аэропорт происходит по предопределённому маршруту и с хорошо понятными препятствиями. Но разработка продукта — совсем другое дело. Это инновации. Другими словами, раньше мы не делали ничего подобного. Если бы было иначе, то нам не пришлось бы писать новое приложение или обновлять устаревшую систему — мы бы использовали старую.
Для разумной оценки у нас несколько вариантов. На самом деле три:
Какой прогноз нужен менеджеру?
Я заметила, что менеджерам часто нужна оценка порядка величины. В этом случае команда может сделать прогноз и сообщить его следующим образом:
«Мы считаем, что этот проект займёт пять месяцев с 50% уверенностью в точности этого прогноза. В оценке восемь месяцев мы уверены на 80%. Десять месяцев — это 90% уверенности».
Это помогает менеджерам понять, что существует диапазон доверия. Если они хотят 100% уверенности, то для этого может потребоваться срок более 14 месяцев.
Можете использовать метод спирали: «Мы ориентируемся на первый квартал следующего года. Не знаем, когда именно в первом квартале, но думаем, что справимся». По мере продвижения проекта уточняете: «Обновляем оценку на срок где-то между серединой января и серединой марта». Узнав ещё больше, говорите: «Где-то в феврале, если не случится метели». Потом в январе можете сказать: «Третья неделя февраля».
Я бы ещё рекомендовала диапазон из трёх дат: «Оптимистичная дата — январь. Самая реалистичная — конец февраля. Самая пессимистичная — конец апреля».
В любом случае никогда не давайте однозначной оценки. Это искушает Святого Мерфи (из закона Мерфи) заняться вашим проектом и наделать гадостей.
В некоторых случаях и в некоторых командах заказчику могут потребоваться дополнительные сведения. Здесь вы можете обсудить с ним конкретные реализуемые функции, чтобы понять неопределённости.
Используйте время цикла вместо оценки
Я вообще не люблю прогнозы по сроку выполнения программных проектов или других IT-проектов, особенно Agile. Вместо этого предпочитаю, чтобы команда выпускала очень маленькие истории или оценивала работу по времени цикла.
Если вы не знакомы с терминологий:
В случае Селесты она знала, что команда может выпускать от трёх до четырёх историй в неделю для продукта A. Для многих команд подсчёт историй работает так же, как другие методы оценки.
Если команда никогда не работала над подобным продуктом, то предыдущее время цикла не будет применимо к этому новому продукту. Команда может не знать, как уточнять и дробить истории, чтобы выпускать по нескольку в неделю. Кроме того, она может не знать о состоянии кода и наличии достаточного количества тестов. Если ваша команда работает над историями больше трёх дней, не утруждайте себя прогнозом. Сосчитайте истории и не пытайтесь сделать больше, чем обычно.
Когда команда начала справляться с историями за один-два дня, вы тоже не обязаны делать оценку. Часто простой подсчёт легче и более точен.
Почему бы не использовать скорость?
Вы заметили, что я рекомендую время цикла и подсчёт историй, а не скорость работы для оценки времени проекта. Потому что скорость — суррогатная величина.
Например, я каждый день хожу пешком, чтобы поддерживать себя в форме. Я иду по тому же маршруту каждый день, отслеживая свою относительную скорость. В хороший солнечный день я прохожу около 5,6 км в час. В дождливый или жаркий и влажный день скорость падает до 4 км/ч. В снег или гололёд могу вообще не выйти на улицу, в этом случае моя скорость равна 0.
Я иду по тому же маршруту. (Да, это скучно, но это моя проблема). Хотя я прохожу одинаковое расстояние, дорога занимает разное время в зависимости от условий. Здесь условия аналогичны кодовой базе и тестам вашей команды.
Если истории достаточно малы, скорость соответствует времени цикла. Но слишком часто менеджеры пытаются дать оценку для проектов с очень большими историями. Подсчёт будет проще: «Мы можем закончить одну или две истории за цикл. Какую одну или две истории вы хотите выбрать?»
Отказаться от оценки — это не обман
Когда Барри обсудил вопросы с коллегами, один из них заявил: «Отказаться от оценки сроков — это жульничество!»
Барри ответил: «Неправда. Вы же хотите, чтобы мы выпустили продукт, верно?»
Ответ был «Конечно. И B, и C».
«Проблема в том, что их нужно делать по очереди, — ответил Барри. — Если вам так нужен продукт А, какой смысл делать прогноз по остальным? Мы можем приступить к работе и показать наш прогресс. Когда мы сделаем достаточно, то повторим процедуру для B и C. К тому же, у вас будет время уточнить требования для B и С, чтобы подготовить нам истории».
Команда Селесты завершила основную часть проекта А за один месяц. Выпуск продукта B занял больше времени — ближе к двум месяцам. И поскольку компания получила достаточный доход от выпуска продуктов А и В, то снизила давление по выпуску продукта С.
Знайте, какая оценка нужна вашему менеджеру. Преподнесите её так, как ему нужно. И если у вас мало времени, приступайте к работе.
Сроки реализации проектов
Одной из основных отличительных особенностей любого проекта есть его ограниченность во времени, то есть наличие начальной и конечной точки. Исходя из масштаба замысла, а также количества процессов, которые необходимо выполнить для достижения цели, можно рассчитать ориентировочные сроки реализации проектного задания. Правильный временной расчет позволяет избежать дополнительных затрат, особенно на стадии строительно-монтажных работ, и срыва даты сдачи объекта в эксплуатацию.
Содержание статьи
Понятие сроков реализации замысла и важность управления ими
В законодательстве Российской Федерации понятие периода реализации проекта понимается как определенное время, на протяжении которого проводится финансирование и возведение предусмотренных замыслом объектов капитального строительства. Также существует понятие планового периода инвестпроекта, означающего максимум пятилетний период, когда на реализацию инициативы может предоставляться государственная поддержка.
Учитывая то, что общий срок реализации проекта состоит из суммы потраченного времени для выполнения работ на каждом последовательном этапе, необходимо с высоким уровнем точности определить, каков временной бюджет каждой стадии всего начинания. С этим напрямую связан и уровень ответственности подрядной организации, выполняющей конкретные работы. При реализации масштабного замысла разные процессы выполняют несколько подрядчиков, поэтому несоблюдение плановых сроков одним из них может затормозить начало работ другой организацией, что, в конечном итоге, приведет к убыткам инвестора.
Временные отрезки, за которые проводится реализация проектов, чаще всего зависит от таких факторов:
Современная управленческая наука предполагает разнообразные виды менеджмента, включающие в себя управление рисками, стоимостью, коммуникациями, качеством и т.д. По этим направлениям за длительный период уже выкристаллизовалось четкое понятийное поле в менеджерской среде. Что касается управления временем реализации действий, то этот вопрос является спорным и неоднозначным. Причины неудач различных задумок зачастую ищут в чем угодно, не желая признавать, что при планировании были ошибочно просчитаны временные параметры, необходимые для осуществления каждой операции.
И если при параллельном методе планирования еще можно как-то попытаться исправить ситуацию, максимально сократив критический путь (если это технологически допустимо), то при последовательном методе этот сбой совершенно точно отодвинет дату сдачи объекта.
Некоторые видят причины возникающих проблем в том, что в последнее время временными моментами при подготовке обоснования проектов занимаются планировщики, часто не владеющие необходимыми знаниями относительно установленных нормативов и правил проведения строительных и монтажных работ. Используемые ими компьютерные приложения, такие как MS Project, Primavera, Spider, эффективно просчитывают все строительные этапы только тогда, когда им заданы правильные параметры. Поэтому оптимальным является вариант, при котором над календарным планом работают совместно планировщик и опытный инженер-строитель.
В любом случае, такой вопрос, как реализация проектного задания во времени, на сегодня остается открытым. Разными исследователями и специалистами-практиками предлагаются различные варианты решения проблемы, в первую очередь, относительно возможности продуманного планирования горизонта событий.
Метод календарно-сетевого планирования
В начинаниях, связанных с капитальным строительством, а таких среди инвестиционных проектов большинство, традиционно используется метод планирования по календарно-сетевому графику. Он представляет собой модель, иллюстрирующую, как будет протекать реализация замысла по временному и процессному параметрам. Фактически, такой график является инструментом:
Однако графики составляют люди, поэтому постоянно возникают проблемы с их соблюдением. Например, если составить схему, основывающуюся на освоении капитальных вложений, то при проведении ряда параллельных операций, постоянно возникают накладки в положительную или отрицательную сторону. Критический путь при этом часто выводится вручную, он не является экономически обоснованной расчетной величиной, а «рисуется» к определенной дате, которая регулярно не соблюдается.
Фактически такого рода графики лишь ставят временные ограничения нижестоящим исполнителям, но слабо зависят от других факторов (готовности необходимых комплектующих или конструкций, логистических проблем, наличия квалифицированных кадров). В этом случае руководитель проекта не может точно прогнозировать его течение и заранее повлиять на потенциальную проблему. Поэтому затягивание времени завершения отдельных этапов и строительства в целом при таком подходе не редкость, как и необходимость дополнительного финансирования.
Чтобы не возникало серьезных разногласий с подрядчиками по поводу длительности выполнения тех или иных операций, многие заказчики нанимают для составления плана инжиниринговые компании. Те заранее проводят работу относительно составления специализированных баз данных или справочников, где определяется продолжительность типовых или стандартных работ. Такие справочники позволяют избежать затягивания процессов со стороны подрядных организаций.
Иногда заказчик вынужден делать выбор, что лучше: быстрый, но дорогой вариант, или более протяженный, но дешевый. Практика показывает, что в инициативах, в которых конечная цель – получение прибыли, инвестор чаще склоняется к первому варианту, т.к. сокращение длительности предынвестиционной и инвестиционной фаз позволяет быстрее окупить вложения. С социальными проектами ситуация может быть иной, здесь большую роль играет цена вопроса.
Более эффективным является календарно-сетевое планирование, основанное на технологии выполнения требуемых работ. Если есть четко прописанная технология, согласованная с подрядчиками и инвестором, то сроки выполнения всех процессов можно точно прописать на схеме и обоснованно рассчитать критический путь строительства. Этот подход помогает избежать затягивания работ, влекущего за собой дополнительные затраты на аренду, накладные расходы, содержание персонала, обслуживание техники, выплаты процентов по кредитам и т.д. Кроме того, благодаря этому методу можно увидеть, кто конкретно виноват в проволочке из-за неправильного решения или же не решения того или иного вопроса.
Как правильно рассчитать время реализации проекта
Когда речь идет об инвестиционном проекте, то горизонт расчета (расчетный период) охватывает весь жизненный цикл начинания – от разработки концепции до завершения или ликвидации. При определении общей продолжительности реализации проекта учитываются такие факторы:
Для более адекватной оценки ситуации производят разбивку горизонта расчета на отдельные шаги.
Наиболее показательными с точки зрения эффективности замысла являются шаги, в рамках которых собирается определенная статистическая и оперативная информация (год, полугодие, квартал, месяц).
При планировании общего срока реализации инвестиционного замысла и разбивке его на более мелкие шаги необходимо учитывать такие существенные факторы:
Все инвестпроекты состоят из таких основных временных отрезков:
Чтобы избежать ошибок в расчетах относительно сроков начала полноценной работы будущего предприятия, необходимо уделить особое внимание первой фазе, каждая составляющая которой требует тех или иных временных затрат. Особенно это касается последовательных процессов, когда следующее действие не может начаться без полного завершения предыдущего. Предпроизводственный этап может ориентировочно включать в себя такие действия:
По некоторым из указанных действий есть утвержденные нормативы относительно затрачиваемого времени. Однако обязательно следует учитывать и местные особенности, которые могут сдвинуть сроки вперед (климат, состояние почвы, необходимость дополнительных работ, возможность быстро привлечь нужную технику или специалистов).
Система стоимостного управления сроками
Признавая все достоинства метода календарно-сетевого планирования, используемого в строительстве, нельзя не отметить и его недостатки: невозможность точно рассчитать временные параметры всех документальных оформлений и технологических операций, время на переговоры и согласования тех или иных решений. Поэтому ряд специалистов предлагает внедрять такую систему, где каждая единица времени отклонения от разработанного плана должна иметь свою стоимость для заказчика или подрядчика:
Для того чтобы не срывать жестко установленные сроки, при стоимостном методе предлагается такая система управления:
Также важно учитывать время, затрачиваемое непосредственно на планирование. Предлагается не делать его своими силами уже после того, как будет проведена экспертиза всей документации, а нанимать специальные инжиниринговые компании, которые будут просчитывать ориентировочные временные вехи уже на стадии разработки базового документа, а в дальнейшем только осуществлять контроль и управлять сроками.
Такие ситуации происходят из-за того, что люди, которые планируют и выполняют работы, действуют автономно относительно друг друга и имеют разную мотивацию. Нередки случаи, когда подрядчик, желая получить заказ, соглашается на заявленные заказчиком временные рамки, заведомо зная, что не сможет в них уложиться или, не имея достаточно квалифицированных специалистов, которые могли бы просчитать его реальные возможности. В таких случаях заказчику стоит заранее оговорить систему серьезных штрафных санкций за каждую просрочку.
Что значит продолжительность проекта
Общая продолжительность проекта является важным фактором при управлении проектами, требующими проведения большого количества мероприятий. Общую продолжительность можно рассчитать по сетевому графику при условии, что известна продолжительность каждого мероприятия, требуемого в соответствии с проектом. [c.356]
Чтобы определить общую продолжительность проекта, необходимо определить самое раннее и самое позднее время в каждом из кружков сетевого графика. Чтобы вписать эти значения в фафик, каждый кружок поделен на три части, как это показано на рис. 10.14. В каждом кружке имеется три значения номер события, самое раннее время события и самое позднее время события. О номере события мы уже говорили в предыдущих примерах. Самое раннее время и самое позднее время по каждому событию (т. е. по каждому кружку) рассчитывается, как это показано далее. Самое раннее время события рассчитывается следующим образом [c.357]
Любое отклонение от времени начала, продолжительности или времени окончания критического действия неизбежно повлияет на общую продолжительность проекта. [c.361]
В целом действия А, Г и Е не являются критическими. То есть если сократить продолжительность любого из этих действий, то это не скажется на общей продолжительности проекта. Но если изменить продолжительность любого из критических действий (Б, В или Д), то это скажется на общей продолжительности проекта. [c.362]
Определите общую продолжительность проекта исходя из нижеприведенного перечня действий [c.362]
Критический путь для этих действий — это А, Б и Д. Другие действия (В и Г) не являются критическими. Общая продолжительность проекта составляет 11 дней. [c.362]
Е) Определите общую продолжительность проекта и критический путь исходя из нижеприведенных сетевых графиков [c.364]
I) Составьте сетевые графики, определите критический путь и общую продолжительность проекта исходя из нижеприведенных перечней действий [c.364]
I) (i) Определите общую продолжительность проекта и критический путь исходя из нижеприведенного перечня мероприятий по расширению завода [c.365]
В этом разделе мы рассмотрим возможность сокращения продолжительности проекта. На практике этого иногда можно достигнуть за счет использования дополнительных ресурсов, например рабочей силы или внеурочного времени, и отсюда вытекают дополнительные расходы. Такие расходы называются стоимостью срочной программы, а процесс сокращения продолжительности называется авралом. [c.375]
Для того чтобы сократить общую продолжительность проекта, необходимо сократить продолжительность одного или более критических действий. Сокращение продолжительности не критических действий не окажет влияния на общую продолжительность проекта. [c.376]
По этим новым данным составляем новый сетевой график (см. рис. 10.33). Из графика видно, что продолжительность проекта сокращена до 29 недель. [c.377]
Обратите внимание, что действия В и Е также становятся критическими. Это означает, что для того, чтобы сократить продолжительность проекта еще на неделю, сокращения действия Д будет недостаточно. Путь А- В- Е->Ж займет все те же 29 недель. Следовательно, необходимо сократить продолжительность одного из следующих действий [c.377]
Из этих вариантов видно, что дешевле всего сократить продолжительность действия Ж. Поэтому, для того чтобы сократить общую продолжительность проекта, мы сократим продолжительность действия Ж до 11 недель при дополнительных затратах в 200 ф. ст. [c.377]
Итак, процесс сокращения продолжительности проекта до желаемого уровня можно описать следующим образом [c.377]
Обращаем ваше внимание на то, что при сокращении продолжительности можно применять и другие методы. Так, можно сократить продолжительность всех действий, а затем увеличить продолжительность наиболее дорогостоящих действий, и так продолжать до получения требуемой продолжительности проекта. [c.378]
Ожидаемая продолжительность проекта 10 + 8 = 18 дней со среднеквадратическим отклонением [c.382]
Эти значения можно использовать при дальнейшем анализе проекта. Например, можно определить вероятность того, что продолжительность проекта превысит 20 дней. При условии, что продолжительность проекта нормально распределена, это можно сделать следующим образом [c.382]
Среднее продолжительности проекта — 18 дней. [c.382]
Распределение всей продолжительности проекта показано на рис. 10.38. [c.382]
Это указывает на то, что имеется 7.2%-ная вероятность того, что продолжительность проекта превысит 20 дней. Далее можно провести анализ возможных колебаний продолжительности всего проекта. [c.383]
| Рис. 10.38. Вероятность того, что продолжительность проекта превысит 20 дней |  |
I) Предположим, что общая продолжительность проекта определяется тремя действиями А, Б и В. Далее в таблице даны оценки продолжительности этих критических действий [c.385]
Методом действие в узле составьте график перечня действий. Рассчитайте самое раннее и самое позднее время начала и окончания, а также общую продолжительность проекта [c.389]
Методом действие в узле мы получим сетевой график, который приведен на рис. 10.45. Из этого графика видно, что общая продолжительность проекта составляет 16 недель. [c.389]
Потоки денежных средств при реализации проекта. Управление финансами и оценка эффективности инвестиционных проектов с помощью PROJE T EXPERT. Расчет показателей и оценка эффективности проекта. Процедуры компромиссного соотношения между затратами и продолжительностью проекта на основе задач линейного и нелинейного программирования. Решение поставленных задач в EX EL. Распределение денежных средств. Минимизация общей продолжительности проекта с минимальными дополнительными расходами. Выполнение проекта с минимальными издержками. Временной и стоимостной анализ проекта. [c.448]
На рис. 10.39 представлена нормально распределенная продолжительность проекта, и выделен участок, который указывает на вероятность незавершения проекта в течение 70 недель, после чего идут штрафы. По таблицам нормального распределения находим, что такая вероятность равна приблизительно 0.12. То есть компания Гилфорд и партнеры имеет 12%-ную вероятность понести штрафы по предложенному контракту. Это может удержать компанию от заключения контракта и почти наверняка вызовет дополнительные переговоры по пересмотру продолжительности проекта и снижению штрафных сумм. [c.385]