Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«Ко­мпле­ксное решение для эле­ктро­нно­го до­ку­ме­нто­о­бо­ро­та на базе SAP ERP»
Иван Савчук:
Не хватает технической части. В остальном все очень подробно.
«Упра­вле­ние сложными ли­чно­стя­ми в проектной группе»
Татьяна Шаньгина:
Управление сложными личностями в проектной группе – тема интересная, актуальная, хотя и довольно амбивалентная. Практический опыт доказывает справедливость концепции Уильяма Зиска о...

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

Управление ИТ-программами

Предыдущая Следующая

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

Управление ИТ программами

Докладчик: Андреас Каллен

Что делает программу программой? Ее масштаб, объем проекта. Качество, бесспорно, связано с этим. Если это IT-программы, то нужно поговорить об управлении релизами. Рассмотрим концепцию «треугольник ограничений» — обычно в центре треугольника находится масштаб проекта, иногда ограничения бывают бюджетные, ресурсные, временные. Размер, масштаб зависит от других параметров — это одна из вершин треугольника, на остальных — время, бюджет, и качество — в середине.

Что нам показывает данный треугольник? Когда вы увеличиваете объем, масштаб, это сразу же влияет на бюджет, на время и на качество. И наоборот, урезаете бюджет — значит, нужно урезать и объем, и границы проекта, в том числе и сроки. Поговорим о масштабе и объеме проекта, и об управлении им. Если вы хороший программный менеджер, вы умеете управлять границами, масштабом проекта. То есть, в каких границах мы должны выполнить полностью всю работу, и какие функции должны включить сюда? Реализовать это в жизнь довольно сложно. В известном комиксе клиент обозначил свои пожелания, но руководитель проекта понял их совершенно по‑другому, потом подключился аналитик и спроектировал это решение, исходя из слов руководителя проекта, затем программист по‑своему понял задачу, а бизнес-консультант описал и вовсе собственную, далекую от других точку зрения. А вот в проектной документации была полная пустота, ничего недоступно. Потом рабочие установили совсем не то, что клиент ожидал.

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

Методические рекомендации, которые помогут вам реализовать проект в его рамках и получить успешную сдачу проекта. Программы выводят нас на более высокий уровень. Но в сложной программе работают обычно 200‑300 коллег, которые пытаются с вами двигаться в одном направлении — невозможно их всех усадить за один стол и всем вместе начать работать. Поэтому неформальная отчетность в таком коллективе не сработает, это работает лишь в маленьких коллективах. Чем больше коллектив, тем более формальным должен становиться из‑за увеличения объема и масштаба проекта или программы.

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

Когда есть ценностное предложение, это одно дело. Но иногда нужно копнуть глубже, чтобы выявить все требования. За этим идут ожидания от программы: чот она, в конечном итоге, позволит сделать? Дело в том, что вы не знаете в самом начале, что вам предстоит сделать, — например, пятилетняя программа будет или более продолжительная. Вы не знаете, что вас ждет в будущем, какие итерации последуют за вашими нынешними действиями. Но вы должны иметь определенные ожидания того, что может произойти в ближайшее и в более далекой перспективе, и подготовиться к этому. Чем дольше реализуется программа, тем непонятнее будущее, тем больше таких ожиданий у вас должно быть.

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

Управление объемом и масштабом проекта и программы

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

То есть вы должны определить участников панельного обсуждения — представителей этих 60 тысяч ключевых пользователей, которые будут озвучивать их совокупное мнение. О чем их спрашивать, понять просто. Потому что, какие ожидания? Ожидания простые. «HR goes cloud», «HR — в облако» — каково ваше видение этого решения, ожидания, роль в этой программе? После этого важно задокументировать, категоризировать их для того, чтобы было проще эту информацию читать, усваивать и достичь определенного согласия, выработать реалистичные ожидания. Программа — это вещь сложная, масштабная, она подразумевает информирование большого количества стейкхолдеров, так что всю документацию нужно четко собирать и использовать при необходимости.

Как связывать группы заинтересованных лиц. Есть группа, которая отвечает за стратегию компании — например, те, кто продает решения SAP или консалтинговые услуги, а также само программное обеспечение. Дальше есть бизнес-стратегия. Бизнес — работа с кадрами, у которых тоже есть стратегия работы в компании, а именно — развивать кадры, продвигать лучших сотрудников. Сама программа должна учитывать эти два параметра стратегии: корпоративную стратегию в целом и бизнес-стратегию, это позволит определить, выполняете ли вы требования. Помимо таких стейкхолдеров, как совет директоров, руководство компании, ваша проектная командатоже является очень важным стейкхолдером. Ваши клиенты в компании — проектные менеджеры от IT и менеджер программы, это тоже стейкхолдеры, ожидания которых нужно учитывать.

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

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

Программа — это всегда большой масштаб и продолжительность. Если совет директоров заявляет, что вам предстоит в течение 5 лет руководить программой с бюджетом в 100 миллионов евро — скорее всего, у вас не получится 5 лет работать скрытно, а потом вдруг огласить результат. Такой бюджет подразумевает результаты, которые вы будете получать в процессе работы. Так что лучше сюда включить проект, который, может быть, к программе не относится впрямую, но позволит показывать результаты, например, спустя год, по системе quick win, «быстрая победа». Это нужно, чтобы успокоить заинтересованных лиц. Такие проекты политически важны, потому как такие вопросы в крупных программах — это очень важная вещь.

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

Потом вы приступаете к третьему шагу — определяете требования достаточно подробно. Это важный шаг, так как ваша команда специалистов собирает требования о бизнесе, но при этом они часто забывают о том, как команда будет это решать средствами информационных технологий. Если об этом забыть, то вы собираете слишком много требований и не сможете в результате создать универсального решения — того, что мы называем «серебряной пулей». IT-консультанты, когда выслушивают требования клиента, должны всегда думать о конкретном решении, которое может получиться из этих требований. Это определенное требование в определенной последовательности должно быть реализовано, иначе вы не поймете действительных требований клиента, и не сможете понять, как эти требования превратить в практическое решение. Ведь требования клиента (01:45:00) часто функциональные: как он хочет функционально использовать эту систему, чем она будет наполнена, с каким контентом она будет работать, какие технические требования, требования по удобству пользования — они вообще выходят на первый план сейчас. Я вижу, что многие наши решения становятся все лучше в этом аспекте тоже, и мы переходим на мобильную платформу, создавая приложения для iOS и Android — вопрос usability является очень важным в таких программах.

Ожидания. Как я уже говорил, в начале реализации программы много вопросительных знаков. Их нужно постепенно превратить в знаки восклицания, то есть реализовать все требования, ответить на все вопросы. Спустя 2‑3 года реализации программы вы должны вернуться к этим ожиданиям, к этим вопросам и проверить, исполнились ли они. Если они исполнились, это очень хорошо, значит, вы правильно спрогнозировали свое будущее. Но не лгите себе, будьте перед собой откровенны. Если не исполнились эти вещи, их нужно изменить. Это неплохой опыт — если ожидания не оправдались, это нормально. Нельзя предугадать будущее в пятилетней перспективе, совсем ничего в этом зазорного нет — скорректировать ваши ожидания спустя какое‑то время. Если вы не превратите эти вопросы в ответы, вы так в конце и останетесь с вопросами. Ничего хорошего в этом нет.

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

Результаты, критерии приемки.

Из-за отсутствия этих критериев проекты часто проваливаются. Потому что сначала нужно, конечно же, определить границы проекта, но после того, как вы все сделали в этих границах, нужно сделать отмашку и зафиксировать полученный результат. А если нет критериев приемки полученного результата, начинается беготня, но слишком поздно. Для меня критерий приемлемости — это то, что система имеет хорошую производительность. Что это значит? Именно это и нужно определить в каждом конкретном проекте. Иногда и время реакции 5 секунд может быть хорошим, и 2 секунды — недостаточным. Определитесь, пожалуйста. Иначе специалисты по бизнесу скажут: «Плохо работает система, потому что у вас не расписаны количественные показатели эффективности. А если их не расписать, то вы не сможете измерить по ним качество работы». Если требования изменились — вы можете обсудить это с клиентом и найти решение, например, в увеличении сроков, изменении границ проекта или бюджета. Так что на какие‑то уступки вы можете пойти с клиентом, но в результате обсуждения, защиты проекта и, конечно, после полной фиксации всех новых договоренностей.

Что говорят клиенты в этот момент? Вот несколько цитат. «Я не знаю, какие будут границы у проекта, они определятся в результате работы». Или, например: «Мы определим границы проекта, когда будет какой‑то уже результат. Если не будете сейчас вписываться в эти границы, мы так это и не сделаем, надо нам все делать за один раз». Вы должны уметь справляться с такого рода аргументами, потому что это показывает, что вы человек ответственный и несете ответственность за реализацию программы. Бизнес ведь пытается вам такие фразы периодически подкидывать, но ваш правильный ответ — это отсылка к зафиксированным договоренностям. Если это так организовать, то вы сможете дальше вместе двигаться более предсказуемо.

Изменения всегда будут происходить, особенно если программа долгосрочная. Не относитесь к этому как к вещи, с которыми не справиться. С этим надо уметь справляться и управлять этим. Прежде всего, каждое требование на изменение должно быть задокументировано. Вы должны все требования клиента просчитать, прикинуть смету вместе с проектной командой. То есть клиент должен увидеть, как на него это повлияет. Ведь у команды, которая над этим работает, нет ни денег, ни времени на то, чтобы прикинуть, во что обойдется этот проект в конечном счете. Предварительный анализ этих изменений — это уже сама по себе работа. И часто встречаются требования потратить резервы бюджета, когда поступают такие изменения проекта. И кстати, вы не знаете в начале, сколько таких изменений будет туда включено — обычно, по опыту, где‑то 1 % программного бюджета должен выделяться на такие изменения, это нормально. И после подсчета, после оценки можно провести верификацию — если требуется, обращаться к каким‑то другим опытным коллегам. Делайте это, включайте в запрос на изменение то, что они вам подскажут. Проектный менеджер должен с этим ознакомиться, программный менеджер, разработчики, естественно. И все должны согласиться с запросом на изменение. Чем сложнее программа, тем сложнее это все. В маленьком проекте, где только пара требований, это можно не вести, но если их тысячи, то этот документ может оказаться весьма полезным. Самая большая важность в том, чтобы показать управляющему комитету время от времени, что их требования, на изменения выглядели так‑то — они, как правило, очень удивляются тому объему изменений, который сами же пытались инициировать. И это работает, когда все задокументировано.

Теперь поговорим про управление качеством. Что такое качество и что зависит от восприятия? Вообще качество действительно зависит от восприятия, от условий. Часто потребитель вашего сервиса или продукта имеет совершенно иные параметры восприятия качества, нежели поставщик этой услуги или продукта. Помните о том, что качество для людей может значить совсем разные вещи. Хотя вроде бы тема‑то одна общая, но воспринимается оно по‑разному. Помните о том, что вы должны определить критерии качества для вашей программы, которыми вы хотите управлять, утвердить и делиться со всеми потребителями, производителями, специалистами по поддержке и прочими заинтересованными вовлеченными лицами, имеющими влияние на проект. После этого уже можно управлять этим всем процессом. Как управлять? С помощью ворот качества, по‑английски — Quality Gates.

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

Вообще, измерять качество довольно сложно. Спрашиваешь у бизнеса: «Чего вы хотите получить?» — «Качественный продукт» — «А вы опишите, пожалуйста, что значит качественный для вас». Пусть бизнес сам задумается о том, что такое качество, которое он так требует, и как он может его описать. А ваша задача — определить и спланировать 5 шагов: предварительная подготовка, инициация, setup, выгода от программы и закрытие ее. Между этими процессами, точнее, фазами, мы ставим так называемые гейты, ворота качества. Их важно определить на определенной фазе проекта и программы. Качество измеряется не только на уровне программы, но и на уровне проекта, и даже на более мелких этапах. Это крайне важно и четко структурирует реализацию программы.

Вот мой пример того, как мы это делаем в концепции «HR в облаке», «HR goes cloud». У нас три основных стейкхолдера, которые отвечают за ворота качества. Первое — бизнес: очень важное заинтересованное лицо в создании ворот качества. В ворота качества мы вставляем бизнес-аспекты, которые проверяются регулярно по мере того, как мы переключаем фазы. Дальше — факторы успеха. Проект HR Cloud делала компания «SuccessFactors», надо посмотреть то, как эта компания видит выполнение качества, и как это проверяется. Последнее — глобальные IT ворота качества. Что это значит? В плане ландшафта, в плане интеграции IT-решений, интеграции в общий ландшафт SAPовских программных решений всегда имеет определенные критерии выполнения, качество которых отслеживается с помощью этих ворот качества.

Управление релизами теперь рассмотрим. В SAP очень сложный IT-ландшафт, и есть взаимосвязанные системы, которые в этом ландшафте функционируют. Финансовые системы, например, вовлечены практически в любой процесс в компании, поэтому управление релизами становится очень сложной и запутанной темой.

Вообще какова цель релиз-менеджмента? Цель его — управление стабильностью. То есть всякий раз, когда программа вписывается в определенные границы и рамки, чтобы она туда вписалась, вы должны подумать о том, как она будет реализовываться. Если вы это делаете не как проект с нуля, а как модернизацию существующих систем, куда подключены HR-процессы, IT-процессы, консалтинговые процессы, финансовые процессы и так далее, вы же не хотите, чтобы уже работающие процессы были прерваны при применении их на новом ландшафте, поэтому общая цель — управиться с ними так, чтобы не было никаких перерывов. Это можно сделать с помощью SAP Solution Manager — это очень хорошее средство, мы для тестирования результатов теста его используем, и опять же с его помощью контролируется проход через ворота качества. Есть определенные пороговые значения, которые не должны быть превышены или занижены. Если у вас в красной зоне один тест находится, через Q-Gate, через ворота качества вы не пройдете. Или, например, зеленые результаты, но больше 100 проблемных вопросов открыты и висят с высокой приоритетностью — опять же это мешает вам пройти через ворота качества. То есть вот такие вот пороговые значения являются фильтрами, которые мешают пройти через ворота качества нерешенным задачам.

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

Возможно, в вашей компании работа над проектами отделяется от работы над имеющимися рабочими версиями. В SAP, по крайней мере, так и делается. Есть люди, которые создают что‑то, а есть люди, которые отвечают за эксплуатацию. У нас поэтому так и называется — создание, постройка и эксплуатация (Build и Run), поэтому есть люди, которые отвечают за эксплуатацию продукта. Их нужно информировать о том, что мы реализуем новую тему, новый проект «HR goes cloud», и уточнять — не повредит ли данный проект уже существующим решениям? То есть они должны быть вовлечены в этот процесс и проинформированы обо всем соответствующим образом.

Также нужно информировать и других участников. Например, соответствует ли это Sarbanes-Oxley, SOX, подпадает ли под требования аудита по Sarbanes-Oxley. То есть все выгоды структурированного процесса налицо. Даются руководящие методические рекомендации менеджерам, которые знают четко процесс, понимают, какие шаги предпринимать при реализации этого проекта и вписании его в общий ландшафт. Для бизнеса выгода налицо. Программа предоставляет много хорошо определенных и документированных возможностей, они прозрачны и видны всем в компании, даты реализации заблаговременно известны. Я уже знаю сроки реализации обновлений на следующий год, и бизнес их знает, от этого менеджеры программ с серьезностью относятся к этому процессу управления и мы работаем в единой системе координат.

Архитекторы также знают, что за расписание им предстоит, и принимают участие в разработке. Они определили даты выпуска финансовых систем, ввода в эксплуатацию систем для специалистов по продажам, HR-систем. Тестеры знают, какие будут даты для тестов, и подготовятся к этому соответствующим образом. Для разработчиков тоже становится все ясно с самого начала, к какой дате они должны успеть разработать программный продукт. Есть так называемый PCB (Production Change Board), координатор, который является важным лицом — его нужно информировать и обучать. Этот PCB-координатор проверяет, можно ли выделить это время для вас. Дальше нужно информировать проектного лидера, который координирует работу над проектом. Он тоже должен успеть к этой дате все сделать, и все должны к этому подстроиться, скорректировать свои планы для того, чтобы подготовиться к запуску решений, реализованных в данной программе.

Есть у нас и Q-Gate менеджер, то есть менеджер, который отвечает за ворота качества. Он тоже должен быть проинформирован, и вопрос безопасности и сотрудничества должен он решать всегда: HR-проекты критически важные, и данные по работникам должны обрабатываться с соблюдением всех правил предосторожности и безопасности. Поскольку SAP — глобальная компания, нам приходится учитывать эти требования во всех странах, в том числе и в России.

Этот процесс PCB, который я только что описал, используется дальше для того, чтобы консультировать менеджеров ворот качества и руководителей проекта. Они видят: чтобы успеть к конкретной дате, нужно такие‑то требования выполнить. Проектный менеджер должен позаботиться о том, чтобы везде у него на так называемых «светофорах» горел зеленый свет, чтобы тема безопасности была зеленой и прочие тоже.

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

Процесс передачи, переключения с фазы Build на фазу Run, передачи знаний от специалистов по созданию системы к специалистам по эксплуатации обычно занимает 6 недель, и после этого уже команда по эксплуатации заниматься этим начинает сама. Вот на этом все заканчивается, но не полностью, потому что каждый год мы что‑то новое для нашего бизнеса придумываем, и поэтому этот процесс повторяется.

Мы даже написали приложение для этого, для iPhone. В приложении и менеджер проекта, и программы видит даты в нашем календаре, утвержденные для этой программы. В дополнение к назначенным можно создать новые. Здесь не используется e-mail, ничего в этом роде. Эта вещь формальная, потому что степень важности и последствия очень серьезные, поэтому нужно это контролировать четко, в том числе и с помощью специализированного приложения. Естественно, есть и календарь. Это пока еще не введено в полную эксплуатацию, но это показывает, в каком состоянии находится ваш проект. Годы, разделенные на кварталы, и в определенный временной слот можно вписать свой релиз, стандартный релиз, и выделить определенные даты. Например, в апреле можно ввести в эксплуатацию такой‑то проект, и такой‑то проект — в октябре. То есть выделяете даты и определяете реализацию этих проектов.

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

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