График проскальзывания — первопричины

«Самая важная задача проекта: установление реалистичных ожиданий. Нереалистичные ожидания, основанные на неточных оценках, являются основной причиной сбоя программного обеспечения», — Футрелл, Шафер

Вступление

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

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

График проскальзывания: Задержка в завершении проекта от его первоначальной предполагаемой даты завершения.

Каждый план проекта будет иметь запланированную дату завершения (NRA, RA) и ограничительную рамку или верхний предел в расписании. В настоящее время обычной практикой является привязка трех дат к любому плану проекта:

  • Дата без поправки на риск (NRA): дата завершения проекта при условии отсутствия препятствий — идеальные условия.
  • Дата с поправкой на риск (RA): дата завершения проекта при условии, что на пути наступят некоторые риски, и потребуется дополнительное время для их устранения.
  • Ограничительная рамка (BB) или верхний предел: верхний предел плана проекта, до которого проект должен быть завершен при любых обстоятельствах — как правило, определяется высшим руководством на основе дорожной карты продукта / услуги и запуска на рынке.

В идеальных условиях любой проект планируется завершить к дате NRA. Учитывая некоторые риски, которые могут возникнуть на пути и могут съесть некоторое время вне графика, проект должен быть закончен к дате RA. Если риски не были предусмотрены и, следовательно, не спланированы должным образом, проект может быть отложен и завершится после даты RA. Завершение проекта, пересекающее RA или верхний предел, не является ни хорошим, ни ожидаемым из хорошо спланированного проекта.

Коренные причины

Поскольку мы всегда планируем закончить проект до даты RA, редко бывает так, как это ожидается. Существует множество причин для смещения графика, от неправильного планирования, нехватки ресурсов до незапланированных требований и переделок, которые пожирают жизненное время по сравнению с запланированным графиком.

Типичный процесс разработки проекта — у каждого проекта будет команда (разработка, тестирование и другие функции), которая будет работать через процесс (анализ требований, оценка графика, проектирование, внедрение и тестирование), чтобы доставить продукт клиенту / конечному пользователю. Каждая сущность, участвующая в проекте, прямо или косвенно влияет на график.

Из процесса разработки мы можем определить элементы, которые могут вызвать задержку в выполнении проекта — например, неверно истолкованное или неясное требование добавляет время завершения, недоступность инструментов или ресурсов разработки может продлить продолжительность проекта. Различные процессы, такие как оценка графика, детальное проектирование и разработка продукта, если они не выполнены умело, могут значительно взорвать цикл проекта.

Для лучшего понимания все эти возможные причины, которые могут привести к смещению графика, классифицированы.

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

1) График оценки: «Ключ не в том, чтобы расставить приоритеты в расписании, а в том, чтобы наметить приоритеты». — Стивен Кови

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

· Недооценка технических сложностей: В начале проекта многие из членов команды могут не иметь глубоких знаний о технических сложностях, и, следовательно, их оценка будет неправильной. Иногда может так случиться, что человек, дающий оценки для конкретной задачи, не имеет представления о технических проблемах, связанных с выполнением этой конкретной задачи. Вы можете услышать, что к середине / концу жизненного цикла проекта, когда задача не завершена вовремя — «О, я не знал, что эта функция также требует выполнения еще 5 задач!» или «Я думал, что эта задача настолько проста, но я ее недооценил!». · Отсутствие дизайна / Большая картина: Важно иметь более полную картину / обзор всего проекта, чтобы понять, как конкретный модуль / функция будет соответствовать завершенному проекту. Проектирование уровня продукта или системы помогает в понимании интерфейсов между другими модулями и необходимой координации для сборки продукта и, следовательно, лучшего понимания выполняемой работы. Часто оценки без акцента на детальном проектировании имеют тенденцию больше отклоняться от фактического времени, затрачиваемого на завершение работы. · Интеграционное тестирование: При составлении плана проекта, тестирование также должно быть включено в график. Иногда принимается во внимание модульное тестирование или тестирование, выполняемое отдельными участниками на их модуле, но не тестирование на системном уровне. К выпуску, когда все индивидуально протестированные модули собраны вместе, обязательным является системный уровень или интеграционное тестирование. Отсутствие времени на интеграционные испытания в общем графике проекта приведет к задержке в завершении проекта.

· Незапланированные зависимости: Планирование проекта — это не только разбивка проекта на мелкие задачи и управление ими. Хорошо спланированный график проекта также должен учитывать определенные незапланированные зависимости. Вот некоторые из них:

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

o Инструменты и оборудование: проект может быть отложен, если команда ожидает выпуска обновления или закупки какого-либо жизненно важного инструмента (аппаратного или программного обеспечения, используемого в проекте) или если оборудование, необходимое для разработки и тестирования, недоступно. «У нас был трехмесячный проект для проверки нашего существующего решения на новой платформе продукта с использованием клиентского DUT (тестируемого устройства). Нам пришлось ждать DUT почти 1,5 месяца, так как он застрял на таможне. После получения DUT мы Я понял, что он был частично поврежден во время транспортировки. В результате нам пришлось запросить еще одно DUT, и весь проект занял более 5 месяцев, чтобы завершить его ». — Уверен, что такие случаи будут вполне знакомы многим организациям. Другой причиной своевременного отсутствия инструментов / оборудования является то, что они используются несколькими проектами для снижения эксплуатационных расходов. Любая незапланированная зависимость от их использования или неверное предположение о доступности этих общих ресурсов может вызвать задержку в работе программы. Члены команды, возможно, должны работать посменно, чтобы оптимизировать использование общих ресурсов, что может привести к сокращению рабочих часов и / или снижению производительности, а также к планированию проскальзывания.

«Я ждал, чтобы лицензия Matlab была выпущена другим человеком в команде, но он покинул офис, не делая этого, и я потерял 3 часа, чтобы понять, что делать?» — это то, с чем вы сталкивались раньше?

o Другие программы: если несколько программ имеют зависимые результаты, задержка в одном проекте будет каскадно влиять на другие проекты, которые прямо или косвенно зависят от его результатов. «Мы задержались, потому что нам пришлось ждать критического компонента пользовательского интерфейса от проектной команды фреймворка» или «Мы не планировали исправления ошибок для компонента, который должен был быть доставлен без дефектов для нашего использования» — вот общие сценарии задержки в программе, которые зависят от других результатов программы. Параллельные программы могут по-разному влиять на расписание вашей программы. Иногда руководство меняет приоритет программ, работающих параллельно. Если ваш проект рассматривается как проект с низким приоритетом, то может быть нехватка ресурсов, выделенных вашему проекту, что может привести к смещению графика.

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

· Смягчение рисков и план Б: Каждый проект будет иметь те или иные риски. Эти риски могут быть различной степени тяжести и вероятности. При составлении плана проекта важно учитывать риски индивидуально, исходя из их серьезности и вероятности возникновения. Если высокий вероятный риск с более высокой серьезностью не планируется с их планом смягчения (или план B), они будут иметь огромное влияние на отклонение графика от запланированного. Как и в одном из предыдущих приведенных примеров, получение DUT вовремя для проверки было риском. Если бы существовал план смягчения (план B), такой как — Проверка с другим DUT или, если DUT здесь не доступен, пусть один разработчик отправится к клиенту и завершит проверку вовремя, проскальзывания расписания можно было бы избежать.

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

· Плохое руководство: Прежде чем думать о выполнении проекта, именно планирование проекта на самом деле установит платформу успеха. Выполнение проекта зависит от его команды, в то время как планирование осуществляется руководителем проекта. Ожидается, что руководитель проекта будет обладать достаточным техническим ноу-хау, чтобы понимать цели проекта и детали вовлеченных задач. Плохое лидерство и поверхностное знание заданий часто приводят к неправильной оценке усилий и специальному делегированию задач, что вызывает стресс и возможную задержку выполнения проекта. Люди, возглавляющие команду, также несут ответственность за поддержание командного духа и уровня мотивации в приподнятом настроении. Плохая личная приверженность из-за отсутствия мотивации приводит к потере производительности и может привести к сбою графика. Другая причина, которая приводит к задержке проектов, заключается в неспособности руководящей команды отслеживать ход выполнения графика и предпринимать корректирующие действия.

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

· Кривая обучения: Когда в проект включается новый человек или член команды, ему или ей может потребоваться некоторое время, чтобы понять проект, чтобы идти в ногу с другими участниками. Кривая обучения необходима для новых членов команды, вступающих в команду либо из-за истощения, либо из-за каких-либо особых требований к технической компетентности. · Переключение контекста: В небольших организациях или группах, где люди работают над несколькими проектами одновременно, важно иметь некоторый буфер для переключения контекста. Человеку, планирующему работать в проекте «А» в течение двух часов после двухнедельного перерыва, потребуется больше запланированного времени для выполнения этой задачи. Разрыв в две недели и тот факт, что он или она были вовлечены в другой проект, потребует некоторого времени для того, чтобы участник вернулся к контексту текущего проекта. · Глобальные команды разработчиков: В эпоху глобализации и аутсорсинга в наши дни распространено распределение команды разработчиков по разным географическим регионам. План проекта должен учитывать различные часовые пояса и рабочую культуру. Вы можете ожидать ввода для вашей задачи утром в понедельник, но это может быть воскресенье поздно вечером для этого человека, и, наконец, когда поступит информация, вы, возможно, будете возвращаться домой после работы.

Иногда оценка графика может быть совершенно неверной, если вы не понимаете рабочую культуру региона, к которому относится ваш товарищ по команде: «В моей предыдущей работе мне было поручено выполнить задачу, которая является очень важной и требует немедленного внимания «Когда я спросил руководителя проекта, сколько дней / часов у меня на это ушло, я потратил 2 недели на работу с высоким приоритетом и работой с немедленным вниманием». Определение «срочных», «приоритетных задач» меняется в зависимости от культуры и региона.

· Проблемы со связью: Люди общаются по-разному. Если важные вопросы не доведены до сведения членов команды или не обострены вовремя, весь проект может пострадать. Часто страх смущения мешает членам команды сообщать о проблемах, с которыми они сталкиваются во время выполнения, что приводит к увеличению времени, затрачиваемого на выполнение этой задачи, что может легко выполнить дополнительную помощь.

3) Участие клиентов: Эти проблемы достаточно серьезны, если заказчик или конечные пользователи продукта вовлечены в фазу разработки. Понимание приоритетов клиентов, определение ваших ожиданий от их участия должно быть четким и согласованным с обеими сторонами.

· Опытное пользовательское тестирование: В начале проекта должен быть запланирован цикл тестирования опытных пользователей. Процесс предоставления сборок или выпусков для тестирования и сбора их отзывов, анализа и включения их в ваш продукт занимает значительное время, которое, если не запланировано, может задержать вашу программу. · Своевременная обратная связь: «Я получил отзывы клиентов о функциях, поставленных в рамках этапа разработки-1, после этапа-5 к релизу. Эти отзывы очень важны, но теперь я беспокоюсь о том, как включить их, не влияя на график». Это звучит как общая проблема. Включение обратной связи от клиентов должно быть хорошо спланировано с учетом обязательств со стороны клиента. · Обзор спецификации требований к продукту: Планирование и выполнение обзора требований к продукту поможет вам в правильном направлении на протяжении всего проекта. Изучение спецификации требований позволит избежать устранения дефектов, связанных с требованиями, которые в противном случае привели бы к задержке проекта.

4) Неоднозначное требование проекта: Для любого проекта, который должен быть инициирован, в первую очередь необходимо иметь требования к нему. В жизненном цикле разработки продукта фаза требований действует как фундамент. Четкое требование или видение проекта направляет команду к успеху. Однако требования могут быть неясными во время оценки и могут привести к задержке в завершении проекта. Вопросы связанные:

· Развивающиеся спецификации: Если вы делаете продукт, основанный на стандарте, который еще не созрел или все еще развивается, вы более подвержены этому риску. Частота изменений в спецификациях изменит требования к проекту на разных этапах разработки продукта, и команда продолжит работу над тем, что еще не развито. Это приводит к переделке, которая задержит проект, если время для обработки этих изменений не будет учтено в графике. «Мы разработали алгоритм и, следовательно, измерения, основанные на определенном отраслевом стандарте. В связи с выпуском продукта характеристики изменились, и наши измерения перестали быть действительными. Нам пришлось переделывать алгоритм, чтобы отразить изменения в характеристиках. Это вызвало выпуск нашего продукта отложен на 2 месяца. " · Новые требования: Иногда новые требования добавляются по мере развития проекта к его завершению. Реализация новых требований не планируется в начале проекта и, следовательно, не учитывается в графике. Добавление новой функции без изменения графика может привести к задержке.

· Невыразимое ожидание: Требования от клиентов могут быть двух типов — неявные или явные. Важно, чтобы требования были хорошо документированы. Неявные требования должны быть лучше определены и задокументированы, чтобы избежать путаницы в конце проекта. Клиенты могут не описывать свои требования, связанные с производительностью системы, проблемами с памятью, качеством пользовательского интерфейса и удобством использования, но они очень заинтересованы в предоставлении обратной связи по этим аспектам после того, как продукт будет предоставлен для тестирования опытным пользователем. Если нам не ясны такие требования, наш дизайн может их не учитывать. Решение их к концу проекта может потребовать изменения дизайна и дополнительной работы, которая задержит проект.

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

· СуОкрашивающая работа: В небольших организациях часть проектной команды также может отвечать за поддержание / поддержку клиентов существующих продуктов. Эти незапланированные задачи, возникающие на основе событий, связанные с поддержкой клиентов, всегда имеют высокий приоритет. Избыточная или длительная поддерживающая работа может вывести ресурс из запланированного проекта, создавая потенциальную угрозу для отставания графика. · Дефекты: Дефекты являются плохими, поскольку они ухудшают качество продукта и требуют дополнительного времени / усилий для их устранения. Рекомендуется провести тестирование промежуточных выпусков проекта, чтобы быстрее находить и исправлять дефекты в жизненном цикле разработки. Если цикл исправления для таких дефектов внутренней вехи не запланирован, то либо проект будет приостановлен, либо продукт будет худшего качества. Плохое программистское мастерство команды, неспособность адаптироваться к современным практикам программирования и наличие специальных процессов разработки может привести к большему количеству дефектов, для устранения которых потребуется больше времени, чем планировалось, и к проскальзыванию.

· Побочные эффекты от предыдущего этапа: Задачи, которые не были выполнены на предыдущем этапе по любой причине (неэффективность, отпуск члена команды, нехватка ресурсов и т. Д.), Должны быть выполнены на следующем этапе, что увеличит нагрузку на команду. Если адекватный буфер не планируется, эти задачи, перенесенные с предыдущего этапа на следующий, могут задержать проект. · Изменение / уточнение требования: Изменения требований во время разработки продукта приведут к переработке того, что ранее было сделано с первой версией требований. Устранение изменений в требованиях требует дополнительного времени и усилий и может привести к смещению графика. В некоторых случаях требование клиента неправильно понимается, что приводит к неправильному проектированию и внедрению системы. Дополнительное незапланированное время теряется при корректировке дизайна / реализации, что приводит к смещению графика.

Заключение

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *