СОКРАЩЕНИЕ СРОКОВ ПРОЕКТОВ С ПОМОЩЬЮ УСКОРЕННОГО АНАЛИЗА И РАЗРАБОТКИ

из "Как успешно руководить проектами Издание 3 "

В то же самое время начали появляться инструментальные средства, которые автоматизировали некоторые части процесса программирования и тестирования. Таким образом, казалось, что мы имеем лучший из миров - вкладывайте время и трудозатраты в приятную часть работы (требования и разработка) и автоматизируйте, насколько возможно, работу, поглощающую много времени и трудозатрат. Результатом всего этого стала нынешняя расхожая мудрость, что невозможно сократить время стадий выработки требований и проектирования проекта без серьезного ухудшения качества конечного продукта. [c.203]
Помимо участников (а между прочим, восемь - это практически максимальное число участников, которое полезно иметь на УАР) требуются еще два человека. Сеанс УАР нуждается в лидере, а также требуется тот, кого мы называем техническим секретарем. Лидер работает с восьми и допоздна технический секретарь работает, начиная после обеда и допоздна. Вот что они делают. [c.205]
В первый день лидер начинает сессию УАР с группой. Секретарь может быть или не быть там, это, вообще говоря, не имеет значения. Группа начинает собирать главные требования для системы или продукта. Обычно это делается на доске, на пластиковых лекционных планшетах или (если ваш бюджет позволяет) на фотокопировальном планшете - одном из наиболее замечательных изобретений, известных человеку. После выработки главных требований они последовательно детализируются, и этот процесс продолжается до тех пор, пока не будет достигнут требуемый уровень детализации. [c.205]
Продолжим с нашим УАР. Технический секретарь показывается после обеда. Как правило, это человек уровня старшего разработчика. Сеанс УАР кончается, скажем, в 5 часов пополудни, и секретарь с лидером группы собирают все материалы, накопленные за день, и записывают все, что было выработано в технических требованиях. Этот документ затем оказывается на рабочем столе каждого члена группы, когда они приходят на следующее утро. [c.206]
Процесс начинается снова, при этом новый документ используется как отправная точка. Обычно можно надеяться на получение 95 % требований к концу второго дня, однако может потребоваться и намного более длинный срок. Сессии УАР полностью управляются временем, так что вы планируете делать столько, сколько вы можете в отведенное время, в противоположность фиксированному количеству работы, которую надо сделать, и переменному количеству времени на ее выполнение. [c.206]
Дни продолжают идти таким же образом, с обновлением документации каждый вечер и с использованием ее в качестве отправной точки на следующее утро. Результаты варьируются, однако в конце двухнедельной сессии УАР можно ожидать получения спецификаций технических требований, правильных почти на 100 % (только незначительные пункты детализации могут вызывать сомнения, если вообще вызовут), и некоторой части разработки системы/продукта на месте. [c.206]
В этом разделе мы поговорим о рисках, существующих при проведении УАР, и что можно, если можно, сделать, чтобы минимизировать их. Ниже перечисляются риски, а затем указываются возможные действия по их минимизации. [c.206]
Лидер должен быть не из проекта, а лучше из другой организации. [c.208]
До четырех аналитиков/разработчиков они должны быть из отделения информационного обслуживания/информационных технологий или из компании по разработке программного обеспечения, в зависимости от потребности. [c.208]
До четырех клиентов вообще можно было бы ожидать большее их количество, чем аналитиков/проектировщиков. Для разработки информационной системы/продукта в идеале они должны представлять различные уровни потенциальных пользователей от эксплуатационного персонала до управленцев. Для разработки коммерческого продукта, вероятно, имела бы смысл смесь маркетинга, сбыта и потенциальных клиентов. [c.208]
Руководитель проекта если он уже не включен в группу аналитиков/проектировщиков или клиентов. [c.208]
Мы только однажды проходим через этот мир и ограничены в том, что мы можем сделать, в доступные нам часы бодрствования. Мы, как менеджеры проектов, находимся в уникальном и привилегированном положении мы можем использовать время других людей, чтобы выполнить то, что мы хотим, и таким образом, всемерно увеличиваем количество доступного нам времени, а в конечном результате целей, которых мы можем достигнуть. [c.210]
Подумайте об этом. От каждого человека из нашей команды мы имеем время этого человека, чтобы использовать его в наших целях. Это как возможность увеличить продолжительность свой жизни или прожить ее много раз. Мы сможем правильно и эффективно использовать эту силу, только если мы делегируем свои полномочия, передавая столько материала, сколько можем, нашим членам команды. [c.210]
Делайте это тогда, когда вы можете доверять это людям. Если вы будете делать обе эти вещи, вы обнаружите, что ваши дни содержат достаточно времени, которое вы можете использовать для всех тех новых вещей, которыми вам всегда хотелось заняться. Тогда, и только тогда, вы будете испытывать реальную радость руководства. [c.210]
Этот документ описывает процедуру оценки, основанную на этапах 1-5 из десяти этапов , которая может использоваться всем персоналом, а не только менеджерами проектов, для получения оценок. Эта процедура может входить в ряд процедур управления проектами, которые, в свою очередь, могли бы войти в руководство по управлению качеством организации - разработчика программного обеспечения. Процедура состоит из семи разделов. [c.211]
Раздел 1 показывает, как создать структуру распределения работ (WBS) и использовать ее для получения оценки трудозатрат. Это - сторона спроса уравнения проекта. [c.211]
Раздел 2 показывает, как вычислить сторону предложения , то есть наличие ресурсов. [c.211]
Раздел 3 показывает, как согласовать спрос и предложение, описывая, таким образом, модель того, как проект мог бы разворачиваться. [c.211]

Вернуться к основной статье