Скотт Беркун - Искусство управления IT-проектами
- Название:Искусство управления IT-проектами
- Автор:
- Жанр:
- Издательство:Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719
- Год:2014
- Город:Санкт-Петербург
- ISBN:978-5-388-00543-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Скотт Беркун - Искусство управления IT-проектами краткое содержание
В отличие от множества трудов, посвященных руководству проектами и командами, в этой книге не проповедуются никакие новые учения и не превозносятся великие теории. Скотт Беркун считает залогом успеха практику и разнообразие подходов. В книге описываются основные сложности и проблемные ситуации, возникающие в работе менеджера проекта, даны рекомендации по выходу из них.
Издание предназначено не только для лидеров команд и менеджеров высшего звена, но и для программистов, тестеров и других исполнителей конкретных проектных заданий. Также оно будет полезно студентам, изучающим бизнес-менеджмент, проектирование изделий или программную инженерию.
Текст нового издания значительно переработан автором с целью добиться большей ясности, кроме того, книга дополнена новым приложением и более чем 120 практическими упражнениями.
Искусство управления IT-проектами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
7. Многие не любят, когда следят за продвижением их работы. Какие стимулы можно предусмотреть для людей, чтобы они сами отслеживали состояние собственной работы? Почему спортсменам нравится вести статистику своих достижений, а людям, занятым в производстве, это не нравится?
8. Когда вы начинаете настаивать на официальном изменении технических требований, команда игнорирует ваши запросы и продолжает работать во вчерашнем режиме. Какой должна быть ваша реакция? Каков лучший способ перевода команды на новый режим работы?
Глава 15. Стратегия эндшпиля
В продолжение темы предыдущей главы, посвященной стратегии миттельшпиля, в данной главе я сделаю основной акцент на соблюдении сроков и на инструментарии, необходимом для своевременного доведения проектов до финишной черты.
Не забывайте, что у всех проектов, как правило, более одного крайнего срока. У каждого проекта есть промежутки времени, ведущие к концу какого-нибудь этапа или к завершению всего проекта. При этом возникает скрытая опасность, что команду станут усиленно подгонять, чтобы уложиться в срок, хотя она и так прилагает к этому запредельные усилия, понимая, что следующий срок тоже не за горами. Если команда полностью выложится и подойдет к началу следующего этапа в состоянии усталости, депрессии и стресса, то вероятность соблюдения очередного срока резко снизится. Винс Ломбарди (Vince Lombardi) однажды сказал, что накопленная усталость делает всех нас трусливыми. Когда мы измотаны, вернуть нас в работоспособное состояние не сможет никакое количество выпитого крепкого кофе. Как говорит Генри Кайзер (Henry Kaiser), то, как сыграна нота, столь же важно, как и то, какая это нота.
Если команда похожа на загнанную лошадь, то на восстановление интенсивности ее работы до расчетного уровня могут пройти дни или даже недели (рис. 15.1). Хуже того, чем чаще команде устраивают подобные гонки, тем меньше она на них реагирует. Существует некий предел, преодолев который команда перегорает, теряя способность к восстановлению сил в приемлемые сроки.

Рис. 15.1.Ценой аврала, затеянного, чтобы соблюсти один срок, является снижение вероятности соблюдения следующего. Чрезмерные усилия по своевременному выполнению этапа 1 ведут к задержке начала этапа 2
При реализации проекта продуктивность команды лучше рассматривать как ресурс с нулевой суммой: [88]если для соблюдения назначенного срока нужно прикладывать чрезмерные усилия, значит, вы крадете силы, которые вам потребуются в начальной стадии следующего этапа. (Однако если в команде существует специализация ролей, негативные последствия можно снизить за счет перераспределения обязанностей. Чаще всего в процессе работы над проектом у проектировщиков, плановиков, руководителей проекта, тестировщиков и программистов аврал случается в разное время. При правильном распределении работы аврал не может быть сразу у всей команды, поскольку ролевая нагрузка в разное время разная.)
Хуже того, за всем этим следует неравнозначная расплата, поскольку соотношение времени на восстановление сил и на работу в условиях аврала не равно 1:1. На восстановление уйдет намного больше времени, чем на сам аврал (к примеру, если на то, чтобы догнать уходящий поезд, нужно секунд 20, то на то, чтобы отдышаться после этого, может потребоваться несколько минут). Иногда в жертву приносится личная или семейная жизнь, а это уже никак не вяжется с постоянными интересами людей, команды или организации (см. рис. 15.1).
Из этого следует, что хорошее руководство должно обходиться без авралов. Конечно, в серьезных проектах острых углов не избежать, но руководство должно быть заинтересовано в том, чтобы иметь над ними полный контроль, работать преимущественно над тем, чтобы свести их количество к минимуму, и давать реальную оценку их последствиям (не стоит, к примеру, в течение двух недель после начала следующего этапа осыпать команду упреками за вялость и пассивность). Чем продолжительнее работа над проектом, тем больше сил команда теряет на подобные пики активности и тем труднее становится организовать нормальную работу в эндшпиле многоэтапного проекта.
Долгие сроки – это просто сумма нескольких коротких
Чтобы обсудить важные аспекты стратегий миттельшпиля и эндшпиля, мы должны определить в проекте несколько промежуточных сроков. Наиболее важная тройка таких сроков, фигурирующая в простом унифицированном графике работ, относится к переходам между элементами правила трех частей, рассмотренного в главе 2 (рис. 15.2). Каждый переход означает смену области приложения сил команды и должен иметь для этого собственные критерии прохождения.

Рис. 15.2.Внутри этапов имеются ключевые даты, которые нужно отследить, наметить и наделить критериями выхода
Эти критерии представляют собой перечень всего, что предполагается выполнить к концу этапа. В них описывается то состояние проекта, которое он должен приобрести, чтобы этап считался завершенным. Чем раньше определены критерии выхода этапа, тем выше будут шансы на его своевременное завершение.
В каждом этапе есть три основных перехода:
Завершение проектирования (завершение подготовки технических условий).Команда готова к созданию программного кода изделия. Сделано все необходимое для начала реализации проекта: выработаны технические условия, созданы прототипы, составлено краткое изложение замысла. (При этом совсем не обязательно иметь окончательно выработанные технические условия, достаточно иметь в готовности лишь тот объем, который считается необходимым для начала работы, скажем, 20 или 90 %.) Работы по проектированию могут продолжаться (см. раздел «Конвейер по созданию программного кода» главы 14), что-то может переделываться и пересматриваться, но основы в необходимом объеме должны быть заложены.
Завершение реализации заданных характеристик.Команда готова приступить к оптимизации и проверке качества кода. Это означает, что вся функциональность, предусмотренная индивидуальными работами, реализована, выполнено все необходимое, чтобы поведение продукта и его внешний вид отвечали техническим требованиям. Могут оставаться какие-нибудь качественные пробелы или проблемы, но при условии, что руководство их отследило и оценило (ошибки выявлены ), основную созидательную работу можно читать завершенной. Все контрольные и качественные показатели, являющиеся частью технических условий, должны быть в пределах допустимых. К этому времени все остающиеся нерешенными проблемы должны быть переведены в разряд ошибок, а база данных, содержащая перечень ошибок, – стать основным (если не единственным) средством отслеживания хода всей оставшейся работы.
Читать дальшеИнтервал:
Закладка: