Том Демарко - Человеческий фактор: успешные проекты и команды
- Название:Человеческий фактор: успешные проекты и команды
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2005
- ISBN:5-93286-061-8, 0-932633-43-9
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Том Демарко - Человеческий фактор: успешные проекты и команды краткое содержание
Книга Тома Демарко и Тимоти Листера «Человеческий фактор: успешные проекты и команды» – перевод 2-го издания всемирно известного бестселлера об управлении проектами разработки ПО. Первое издание содержало революционные по тем временам (1987 г.) идеи, которые выдержали проверку временем. Авторы скорректировали свои выводы и добавили несколько новых глав. Ценность этой книги в том, что в ней описываются принципы, за каждым из которых стоит реальная история. Все главы содержат наблюдения и новаторские подходы, которые заставят читателей и руководителей увидеть важные вопросы в новом, более разумном ракурсе. С юмором и мудростью, обретёнными за годы руководства и консультирования, Демарко и Листер демонстрируют, что сложнейшие проблемы разработки ПО имеют человеческую, а не техническую природу. Они не дают простых ответов, но дают правильные, подкреплённые научными исследованиями. Издание предназначено в первую очередь руководителям проектов, но будет полезно и рядовым программистам.
Человеческий фактор: успешные проекты и команды - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Жадины, как правило, – это мы, руководители. Мы часто видим хаос в своей области. И предполагаем, что наша задача – избавиться от хаоса, причём полностью. Руководитель в открытом кимоно имеет другую точку зрения. Он готов оставить небольшие фрагменты хаоса другим людям. В последнем случае задача руководителя разделить хаос поровну. И тогда подчинённым удаётся получить удовольствие, приводя хаос в порядок.
Количество беспорядка постоянно уменьшается. Это особенно очевидно в новых технологических областях. Люди, которых в эти области много лет назад привлекла новизна, отсутствие порядка, испытывают ностальгическую привязанность к временам, когда вещи были не до такой степени механизированы. Каждое великое открытие последних двадцати лет сокращало безумие нашей работы. Разумеется, открытия эти прекрасны – кому захочется возвращаться в прошлое – но все же…
Все мы готовы улучшать методы и делать разработку более упорядоченным предприятием. Это прогресс. Да, часть безумного веселья в процессе теряется, но удовольствие одного человека может быть агонией другого (тот проект, показавшийся вам столь весёлым, вероятно, стал причиной язвы у вашего начальника). В любом случае движение к более упорядоченным, управляемым методам остановить невозможно. Вдумчивый руководитель и не хочет препятствовать этой тенденции, но может при этом ощущать потребность в замене потерянного беспорядка, который генерировал так много энергии. Это подводит нас к политике конструктивного привнесения дозированного беспорядка.
Выразив идею столь смело, мы можем достаточно легко собрать перечень способов реализации подобной политики:
• пилотные проекты;
• военные игры;
• мозговые штурмы;
• провокационные курсы;
• обучение, путешествия, конференции, торжества, отдых.
Этот список мы ограничили методами привнесения беспорядка, успешное применение которых наблюдали в реальной жизни. Ваш собственный список может быть не столь кратким. Небольшой мозговой штурм по предмету (о мозговых штурмах чуть ниже) позволит найти фантастические и замечательные возможности.
Пилотный проект – это такой, в котором вы откладываете в сторону толстый том стандартов и пробуете новый, неизученный метод. Новый метод вам не знаком, поэтому поначалу можно ожидать низкой производительности. Такова цена изменений. Обратная сторона медали – повышение производительности в результате применения нового метода. Кроме того, добавляется ещё эффект Готорна – прирост энергии и интерес, наполняющий людей, когда они изучают что-то новое и непривычное.
Могут ли эти два плюса перевесить минус кривой обучения? Было бы безрассудством предполагать, что могут всегда. Большое значение имеет природа вносимых изменений, а также продолжительность проекта, способности его участников, степень веры людей в изучаемый метод.
По нашему опыту пилотные проекты тяготеют к средней производительности, превышающей средние показатели. Это означает, что затраты на проект будут, вероятно, меньше, если вы решите сделать проект пилотным, то есть решите использовать какой-то новый метод.
Означает ли это, что все проекты должны быть пилотными? Ваша организация окажется в хорошей компании, если примет подобный подход за правило; здесь и Fujitsu, и части Southern Company Services, и некоторые подразделения IBM. В любом случае смысла больше в том, чтобы все проекты были пилотными, чем в том, чтобы таких проектов вообще не было.
Существует два возражения против любой расширенной программы пилотных проектов:
• Что делать, если закончатся новые идеи?
• Не усложнится ли ещё более сопутствующая деятельность (поддержка продукта, обучение клиентов и т. д.), если мы начнём поставлять не устойчивую продукцию?
Первое возражение имеет смысл лишь в теории. Большинству организаций после десятилетних испытаний новых подходов редко (если вообще) приходится волноваться из-за того, что новые подходы закончатся. Если начать исследовать все хорошие идеи, на которые мы не обращали внимание в шестидесятых, затем перейти к семидесятым и восьмидесятым, то к моменту, когда исследование завершится, пройдёт ещё десятилетие и появятся многочисленные новые идеи.
Что касается проблемы неустойчивых продуктов, то почему бы не признать, что такая проблема существует даже в случае следования жёстким стандартам? Существующая стандартизация привела к документальной стабильности продуктов, но никак не к осмысленной функциональной стабильности . Иначе говоря, стандартизация в основном затронула бумажную работу, связанную с продуктами, но не сами продукты. Если же бумажный вариант проекта немного отличается от стандартного, то серьёзных неудобств это не вызовет.
Одно предостережение по поводу пилотных проектов: не экспериментируйте более чем с одним технологическим аспектом в пределах проекта. Несмотря на все разговоры о важности стандартов, просто удивительно, насколько часто руководители забывают обо всяких стандартах в редких пилотных проектах. Они часто испытывают новые аппаратные средства, новые программы, новые процедуры контроля качества, матричное руководство, а ещё новые методы создания прототипов – и все в одном проекте.
Разумный подход к пилотному проекту – разрешить изменить лишь одну составляющую процесса. В здоровой среде участники проекта поймут, что экспериментировать с одним новым методом в каждом проекте – это нормально, но в целом следует всегда придерживаться стандарта.
За четыре года существования наших военных манёвров разработчиков мы узнали, что иногда жёсткое состязание, в котором нет проигравших, может стать замечательным источником созидательного беспорядка. Наши игры ориентированы на сообщество разработчиков программного обеспечения, но идею можно применять практически в любой области. Независимо от рода вашей деятельности, возможность испробовать себя в решении специализированных задач и сравнить свои результаты со статистикой производительности коллег может быть весьма интересной. (Конечно же, такой опыт приятен лишь при наличии гарантий конфиденциальности, описанных в главе 8. Вы должны быть уверены, что результаты состязаний не будут использованы против вас.)
Военные манёвры помогают вам оценить свои плюсы и минусы по относительной шкале, помогают организации выявить свои плюсы и минусы в глобальном масштабе. По этим причинам две из наших клиентских компаний разработали программу по ежегодному проведению военных манёвров, чтобы позволить своим сотрудникам измерять рост собственной квалификации с течением времени. Раз в год сотрудники подвергают себя конфиденциальным испытаниям (в чем-то это похоже на медосмотр).
Читать дальшеИнтервал:
Закладка: