Lecture16 (1133573), страница 5
Текст из файла (страница 5)
Пример сетевой диаграммы проекта.•Оценив время выполнения и трудоемкость каждой из работ, можно построить сетевуюдиаграмму проекта, пример которой приведен на Рис. 86. Расшифровка названий работ, ихтрудоемкости и время выполнения приведены ниже, в Таблице 13.КодНазваниеT1T2T3T4T5T6T7T8T9T10T11T12T13T14T15T16T17Формулировка целей и содержания проектаСбор и анализ требованийРазработка архитектурыПервичное планированиеРазработка маркетинговых документовРеализация прототипаДетальное проектированиеИспытания прототипаАнализ результатов испытаний и изменения проектаДетальное планированиеРазработка и отладка пользовательского интерфейсаРазработка пользовательской документацииРеализацияТестированиеДоработка по результатам тестированияРазвертываниеОбучение пользователейТрудоемкость, ч⋅мес0.63.06.00.60.33.06.00.61.01.03.02.08.04.04.01.52.0Время, мес0.31.02.00.30.31.02.00.30.30.31.01.02.01.01.00.50.5Таблица 13.
Работы проекта, сетевая диаграмма которого показана на Рис. 86.Если связи между работами в сетевой диаграмме превратить в вершины, а вершины-работыв связи (и добавить две новых вершины — начало и конец проекта), то получится такназываемая PERT-диаграмма (PERT — program evaluation and review technique, техникаоценки и обзора программ).
PERT-диаграмма, соответствующая приведенной ранеесетевой, показана на Рис. 87. Часто различий между этими двумя видами диаграмм неделают, называя обе и сетевыми, и PERT-диаграммами.Сетевые и PERT-диаграммы используются для планирования продолжительности проектаи выделения критических путей — последовательностей работ от начала до концапроекта, сумма длительностей которых максимальна среди таких последовательностей. Впримере, представленном на Рис. 87 критических путей несколько — работы, лежащие наних, изображены жирными стрелками. Выполнить проект быстрее, чем за время,требующееся для прохождения по критическому пути, нельзя. Поэтому критические путииспользуют для планирования основных поставок в ходе проекта.
В нашем примередлительность проекта не может быть меньше, чем 10.7 месяцев. Кроме того, любаязадержка в одной из работ, попавшей на критический путь, обязательно вызовет задержкупроекта в целом, значит, такие работы требуют повышенного внимания во время проекта.T6T1T2T3T8T4T7T5T16T9T10T11T13T14T12T15T17Рисунок 87.
PERT-диаграмма для рассматриваемого примера проекта.Оценка длительности и трудоемкости работ в виде одного числа чаще всего неудобна иможет привести к неправильным выводам. На практике используют несколько оценок —максимальную, минимальную, иногда еще и наиболее вероятную.
С их помощью можнопополнить набор критических путей и получить более полную информацию о критическихработах в проекте, уточнив планы.Рисунок 88. Диаграмма Ганта для рассматриваемого примера проекта.Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Этадиаграмма показывает и связи между работами, и их длительность во времени. ДиаграммаГанта для рассмотренного примера показана на Рис. 88.На этой диаграмме также показаны 4 выделенных группы работ: начало, проектирование,реализация и передача в использование.•Все оценки и планы, сделанные только на основе продолжительностей выполненияотдельных работ, действительны, если у нас имеется достаточно других ресурсов, вчастости — персонала.На следующем шаге (после вынесения предварительной оценки трудоемкости ипродолжительности работ) нужно привязать их к имеющемуся в проекте персоналу идругим ресурсам (оборудованию, материалам и пр.).
При этом может оказаться, чтонекоторые независимые работы не могут проводиться одновременно, поскольку для этогоне хватает ресурсов.Допустим, что в нашем примере, как первичное планирование, так и разработкамаркетинговых документов требуют полной вовлеченности менеджера проекта. При этомвторая работа может быть начата только после окончания первой. В разработкепользовательского интерфейса могут быть задействованы аналитик, проектировщикинтерфейсов и программист. При ограниченности команды проекта это потребуетувеличить время на выполнение работы по реализации.
Итоговая картина послеперепланирования рассматриваемого проекта для команды из менеджера, аналитикатестировщика, архитектора, трех программистов, один из которых также являетсяпроектировщиком пользовательского интерфейса, и еще одного тестировщика, способногописать техническую документацию, показана на Рис. 89. Она отличается от предыдущейизменениями, удлинившими проект на 0.5 месяца.Рисунок 89. График рассматриваемого проекта, построенный с учетом доступных ресурсов.•Естественно, после учета доступных ресурсов критические пути проекта могут измениться.Кроме того, риски, связанные с непредвиденными ситуациями, неаккуратной оценкойвозможностей персонала или технологий и пр., требуют наличия определенных временныхи ресурсных резервов при планировании проектов.В ходе самого проекта необходимо тщательно следить за выполнением запланированныхработ в срок, за доступностью ресурсов, отслеживать проблемы, способные привести ксрыву графика, а также неучтенные при первоначальном планировании факторы.
Реальныедлительности и трудоемкости работ могут отличаться от оценочных, что потребуетпостроения новых, уточненных планов проекта. Грамотная отработка изменений в планах ирасписаниях — ничуть не менее важная задача, чем их первоначальное составление. Вчастности, чем быстрее менеджер проекта проинформирует о возможных или необходимыхизменениях заказчика, спонсора и других лиц, тем более он может рассчитывать на ихпонимание и помощь в решении проблем проекта.Специфика управления персоналомВ силу того, что на поведение человека оказывают влияние многочисленные факторы, включаяпсихологические и социальные, люди, работающие в проекте, не могут рассматриваться какобычные ресурсы.
Люди склонны по-своему оценивать всю информацию, ставшую им доступнойразными путями, преломлять ее через призму своего личного, уникального опыта и характера, ипоступать, на первый взгляд, нерационально. Человеку чаще всего недостаточно слов «Вот задача,вот зарплата, — давай, работай!», чтобы начать делать то, что от него хотел бы руководительпроекта.Перечислить все особенности управления персоналом достаточно трудно. Ниже приведенсписок лишь некоторых из них, тех с которыми весьма часто приходится сталкиваться напрактике.• Производительность.Одной из наиболее специфических черт управления персоналом при разработке ПОявляются особенности производительности людей.
Разработка программ остается вбольшой степени творческой деятельностью, требует зачастую очень специальных знанийи умений, глубокого понимания вопросов организации информации и аккуратногопланирования работы, поэтому нельзя ожидать от людей, участвующих в ней, каких-тосредних показателей производительности. Опыт и многочисленные эксперименты [10,11]показывают, что производительность отдельных разработчиков в терминах объема икачества создаваемых ими программ за единицу времени может различаться до 10 раз, иэтот разрыв можно наблюдать и в рамках одной организации, и в одной команде.На производительность человека, занимающегося обдумыванием вопросов организацииПО, большое влияние оказывает окружение. Эта работа, с одной стороны, требуетпогружения, и разработчику необходимо достаточно много времени проводить вуединении, вдали от шума и суеты.
С другой стороны, иногда требуется консультацияэксперта, мнение руководителя или просто информация от других сотрудников по какомуто вопросу. Тишина, когда это нужно, и общение, когда оно необходимо, в правильномсочетании позволяют очень быстро продвигаться в решении трудных задач. А любая другаяих комбинация — шум на рабочем месте и отсутствие возможности вовремяпосоветоваться со специалистом — часто катастрофически сказывается напроизводительности такого труда.Определение индивидуальной производительности труда является одним из краеугольныхкамней управления персоналом в большинстве проектов.
Но измерить производительностьпрограммиста, архитектора или даже тестировщика ПО не так-то просто — самая значимаячасть их работы выполняется в их сознании. Поэтому оценить ее аккуратно можно, толькоопираясь на общение с сотрудниками, при обоюдном доверии их и руководителя друг кдругу. Любые административные выводы из полученной информации (премии, повышениязарплаты, выговоры, вычеты или увольнения) могут привести к недоверию и искажениюисходных данных, если только эти выводы не связаны с очевидными фактами принесенияпользы или вреда проекту. Поэтому одно из главных правил здесь — крайняя осторожностьв выводах и учет личных способностей каждого служащего.Еще одна особенность разработки ПО связана с достаточно глубокой спецификойпрактически всех проектов и необходимостью обучения для адекватного вхождения впроект.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
