Книги: [Классика] [Базы данных] [Internet/WWW] [Сети] [Программирование] [UNIX] [Windows] [Безопасность] [Графика] [Software Engineering] [ERP-системы] [Hardware]
Предисловие
Думаю, что вас заинтриговало название этой книги и вы решили заглянуть в нее Но, к сожалению, вы, как обычно, ужасно заняты и не уверены, найдется ли у вас время на чтение еще одной книги об управлении софтверными проектами. Особенно если в ней речь идет о некоем идеальном мире, в котором здравомыслящие мужчины и женщины хладнокровно принимают благоразумные решения относительно бюджета, графика и ресурсов вашего проекта.
Тем не менее мы живем в отнюдь не идеальном мире, и существует вероятность того, что в вашем проекте вам придется взаимодействовать с людьми не слишком рационального склада мышления, решения которых трудно назвать хладнокровными или благоразумными. Другими словами, вы участвуете в безнадежном проекте. Замечательно, что название этой книги не требует никаких пояснений. Каждый раз, когда я упоминаю его в присутствии моих друзей и коллег, они говорят мне со смехом: "Послушай, ты ведь говоришь именно о моем проекте!"
Такой проект может быть моим, вашим, чьим-либо еще - мы все так или иначе участвуем в безнадежных проектах. Я думаю, первый вопрос, который вы должны задать самому себе (хотя он может и не возникнуть): "Как я позволил вовлечь себя в такую авантюру?" Это мы обсудим в первой главе, поскольку мой опыт в качестве консультанта, наблюдающего множество подобных проектов со стороны, говорит о том, что наш мир мог быть разумнее, если бы большинство из нас имело смелость остановиться и сказать: "Дудки! Я не желаю участвовать в этом безнадежном проекте!"
Допустим, вы не можете хлопнуть дверью и уйти: трудно найти другую работу или к вашему работодателю вас приковывает своего рода "золотая цепь", отбивающая охоту выйти их проекта. В этом случае следует спросить себя: "Как я могу выжить в этом проекте без ущерба для здоровья, психики и достоинства?" Оптимисту может показаться интересным процесс преодоления препятствий по пути попыток завершения безнадежного проекта в срок и в рамках бюджета. Но если вы уже неоднократно сталкивались с подобными проектами, вы, скорее всего, знаете, что обстоятельства обычно против вас и выживание - это лучшее, на что можно надеяться.
Проработав в индустрии ПО более 30 лет, я обнаружил, что в нашей профессии безнадежные проекты воспринимаются весьма неоднозначно. Скажем, в Силиконовой Долине они окружены ореолом славы, являясь чем-то вроде испытания силы духа и стойкости, наподобие покорения Эвереста босиком. Я и сам переболел этой болезнью во время моих первых проектов в середине 60-х годов, затем наблюдал развитие этих идей у следующего поколения, что навело меня на мысль о постоянстве этого феномена, поскольку технология продолжает развиваться такими же быстрыми темпами, как и в мое время. Наша индустрия тоже продолжает развиваться. Каждый год появляются и новый Эверест, и толпа отчаянных программистов, уверенных в том, что смогут пробежать босиком весь путь до вершины.
В другой области нашей индустрии такие проекты рассматриваются как серьезные неудачи. Мы бываем завалены статистикой, свидетельствующей о срыве планов, перерасходе бюджета, ошибках в ПО, раздраженных пользователях и полных провалах проектов. Эксперты, консультанты и методологи постоянно твердят нам, что причиной неудач является использование неверных методов (или отказ от использования каких-либо методов), или неправильных средств, или неправильных способов управления проектом. Иными словами, безнадежные проекты существуют из-за нашей бестолковости или некомпетентности.
Общаясь с покрытыми шрамами, закаленными в боях ветеранами-разработчиками, которые прошли через пару безнадежных проектов и поняли, что на самом деле ни к чему покорять Эверест босиком, вы наверняка услышите: "Постойте! Я вовсе не бестолковый! Безусловно, мне хотелось бы использовать правильные методы, средства и способы управления проектом. Но нам их уже продиктовали сверху, в самый первый день, когда мы еще не успели получить хотя бы представление о проекте! Вряд ли мое высшее руководство и мои пользователи позволят мне проявить инициативу!" Вывод: в существовании безнадежных проектов виновато высшее руководство, а также наивность и безрассудство пользователей.
Без сомнения, в этом есть некоторая доля правды. Управляя нашими проектами, мы совершаем множество глупых ошибок, наше высшее руководство увлекается смехотворными политическими играми и наши пользователи предъявляют к нам непомерно высокие требования. Я убежден, что это в основном объясняется быстрым научно-техническим прогрессом, а также обычным неуважением каждого нового поколения к советам и опыту предыдущего поколения. Зачем сегодняшним Java-ориентированным фанатам прислушиваться к советам представителей моего поколения, имеющих 30-летней давности опыт программирования на ассемблере? И как нынешнее поколение пользователей может узнать, какое Web-приложение для них наиболее приемлемо, если их предшественники применяли онлайновые системы на мэйнфреймах с символьными, монохромными и немыми терминальными интерфейсами?
Каким бы ни было объяснение этого феномена, я уже пришел к следующему выводу: безнадежные проекты - норма, а не исключение. Полагаю, что сегодняшние разработчики ПО и менеджеры проектов достаточно изобретательны и горят желанием управлять проектами разумно. Сегодня пользователи и высшее руководство обладают гораздо большей компьютерной грамотностью, чем предыдущее поколение, и менее наивны относительно результатов, которые можно ожидать от разработчиков ПО в условиях ограниченных ресурсов. Это не мешает ни тем, ни другим участвовать в очередном безнадежном проекте, продиктованном необходимостью выживания в конкурентной борьбе, а также заманчивыми возможностями, предлагаемыми новыми технологиями. Бизнес-менеджеры могут вполне осознавать, что при разумном планировании разработка новой системы займет 12 календарных месяцев, однако в то же время они будут настойчиво утверждать, что отсутствие готовой системы через 6 месяцев позволит конкурентам захватить весь рынок и вытеснить их новый продукт или услугу. Аналогично технические специалисты, отдавая себе отчет в высоком риске использования новых технологий, подобных Internet, продолжают утверждать, что в случае успеха новая технология обеспечит им стратегическое преимущество в конкурентной борьбе, и это оправдывает любой риск.
С другой стороны, отчеты таких организаций, как Standish Group, а также статистические данные авторитетных экспертов, подобных Кэперсу Джонсу, Говарду Рубину, Полу Штрассманну и Ларри Путнэму, говорят о том, что в среднем продолжительность проекта больше плановой на 6-12 месяцев, а стоимость превышает бюджет на 50-100%. Конкретная ситуация зависит от размера проекта и ряда других факторов, но в любом случае суровая реальность заставляет предполагать, что условия вашего проекта повлекут за собой некоторую степень обреченности на неудачу и это отразится на поведении менеджера проекта и его технических специалистов. Проект, характеризующийся с самого начала высокой степенью риска, наверняка повлечет за собой сверхурочную работу, потерянные выходные, и, скорее всего, массу эмоциональных и физических стрессов до самого завершения. Даже если проект начинается в разумной и спокойной обстановке, все равно не исключена вероятность, что по мере своего продвижения он переродится в безнадежный. То ли первоначальные план и бюджет окажутся крайне нереалистичными, то ли у пользователей появится много новых требований, которые не были учтены при составлении первоначального плана и бюджета.
Итак, спрашивается: если невозможно избежать безнадежных проектов, как их выдержать? Что следует предпринять для повышения шансов на успех? Когда следует быть готовым к компромиссу - и когда следует уйти в отставку, если дальнейшее продолжение работы невозможно? Именно об этом идет речь в данной книге. Очевидно, решение перечисленных проблем затрагивает такие вопросы, как кадровое обеспечение, процессы и методологии, а также методы и средства. Если вы собираетесь руководить безнадежным проектом, то следует ли настаивать на свободе выбора при формировании проектной команды? Нужно ли занимать твердую позицию в отношении процессов и методологий, таких как модель SEI-CMM (SEI - Software Engineering Institute, CMM -Capability Maturity Model - модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать ПО), или позволить проектной команде отказаться от любых формальных методологий, если они считают, что это поможет нормально выполнить работу? Следует ли настаивать на использовании определенных языков программирования, рабочих станций и CASE-средств (CASE - Computer Aided Software Engineering) , или более активно участвовать в политических баталиях?
Эти вопросы одинаково актуальны как для менеджера, отвечающего за проект, так и для технических специалистов, мозолистыми руками которых система проектируется, программируется, тестируется и документируется; все главы книги адресуются в равной степени обеим группам. Несколько слов относительно менеджеров и технических специалистов: некоторые из комментариев, обнаруженных вами в следующих главах, предполагают, что менеджеры -"злые", а участники проектной команды - невинные, угнетенные жертвы. Очевидно, такая ситуация не является обязательной для всех проектов и всех компаний, хотя само существование безнадежных проектов является, как правило, результатом сознательных решений руководства.
Если вы не в состоянии читать всю книгу, скажу только одно слово, которое может оправдать время, потраченное на чтение предисловия: приоритетность (triage). Если вы участвуете в безнадежном проекте, почти наверняка окажется недостаточно ресурсов, чтобы реализовать всю функциональность и возможности ПО, которые требуются конечному пользователю, в рамках утвержденного плана и бюджета. Так или иначе придется решать, какие возможности следует реализовать в первую очередь, а какими - пожертвовать. Действительно, некоторые из незначительных возможностей не будут реализованы никогда, поэтому - лучше дать им спокойно умереть собственной смертью. Другие возможности являются достаточно важными, но также относительно легко реализуемыми, например с помощью поставляемой библиотеки классов или используемых вами CASE-средств. Говоря языком медиков, эти возможности и сами выживут. Успех или неудача безнадежного проекта зачастую зависит от способности проектной команды выделить критические функции и возможности, которые нельзя реализовать, не вкладывая значительные ресурсы и энергию.
Разумеется, чтобы спасти безнадежный проект, недостаточно одной только правильной расстановки приоритетов в реализации функций (см. главу 3). Необходимо рассматривать и такие вопросы, как кадровое обеспечение, процессы и методологии, методы и средства. Я старался быть как можно более немногословным, чтобы вам хватило пары часов на прочтение всей книги, она могла бы помочь более реалистично оценить очередной безнадежный проект.
Но не воспринимайте эту книгу как "библию" и не думайте, что она преподнесет вам решение всех проблем. Стопроцентно правильных решений не существует, то, что срабатывает в одних компаниях и ситуациях, может не сработать в других. Также важно, что компромиссы, на которые готовы пойти некоторые менеджеры и технические специалисты, будут совершенно неприемлемы для других. Я предлагаю те решения, которые считаю разумными , но в конечном счете вы сами должны определить, какие из них годятся для вас, а какие -нет.
Я намереваюсь постоянно собирать на своем Web-сайте www.yordon.com информацию и практические рекомендации от различных проектных команд по поводу наилучшей практики, наихудшей практики и разнообразных проблем. Даже если в вашем проектном бюджете недостаточно денег на покупку этой книги (такой крохотный бюджет уже говорит о рискованности проекта") , бесплатно обратитесь к web-странице.
Как бы вы ни решили поступить, желаю самой большой удачи вашему очередному безнадежному проекту.
Начало
Полное содержание
Об авторе
Заказать книгу в магазине "Мистраль"
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
