Путь камикадзе

“Перестаньте по­ручать сотрудникам одновременную работу над пятью или шестью не связанными между собой проектами; дайте каждому один проект и оставьте его в покое, пока он его не закончит.”

у каждого проекта есть три проблемы: люди, люди и люди.

До тех пор, пока менед­жер судит о состоянии проекта по устным отчетам, за­пискам или диаграммам потоков данных, будет слишком легко перепутать движение с прогрессом и усилия с ре­зультатами.

Вряд ли ме­неджеру проекта стоит “прятать голову в песок” и ут­верждать, что процесс, описанный данной моделью, на столько сложен, что о нем вообще не следует думать. Реальные проблемы будут существовать независимо от того, хотим мы знать о них или нет.

Мы твердим, что процессы являются критиче­ски важными, но при этом зачастую забываем об их “нейтральности” — дурак, вооруженный процессами и средствами, все равно останется дураком.

“Если процесс нельзя использовать в критических условиях, его вообще не следует использо­вать”

ветераны-разработчики ПО вспомнят старую поговорку: “Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди”

Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудно­сти. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц со­гласиться с приоритетностью требований и если бы эти приоритеты никогда не менялись в течение проек­та... ну что ж, если вы в самом деле в это верите, товы верите в фей и колдунов.

Борьба с бюрократией таким спосо­бом — не для робкого десятка; но ведь и сами безна­дежные проекты тоже не для робкого десятка.

Мистер Большая Шишка, мы реши­ли не использовать эту методологию, потому что она гарантирует провал. Если вы считаете необ­ходимым настаивать на ней, моя команда и я го­товы уйти хоть сегодня

Если этот чертов проект закончится успешно, нам всем придется учить Smalltalk, а я до сих пор уверен, что Smalltalk — это происки коммунистов

Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров – как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»

Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков.

Что же касается безнадёжных проектов, то пользователям в действительности нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро – вот в чем заключается их определение «достаточно хорошего» ПО.

Бессмысленно навязывать какой-либо процесс в обязательном порядке, если никто не собирается ему следовать. Блюстители методологии просто зря теряют время, пытаясь сделать это, а в результате, что гораздо хуже, может напрасно потерять время проектная команда (во многих случаях эти деятели не совершают ничего полезного, кроме суеты вокруг департамента информационных технологий и надоедания и без того уставшей от всего проектной команде).

Однако, большинство проектов включает сотни требований, а многие – даже тысячи; проект самолёта Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300.000 требований.

Даже если в вашем проектном бюджете недостаточно денег на покупку этой книги (такой крохотный бюджет уже говорит о рискованности проекта!), ровным счётом ничего не стоит обратиться к Web-странице.