Читать онлайн «Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте». Страница 29

Если процесс формирования такой команды протекает успешно, обычно это бывает заметно по некоторым внешним признакам. Как замечают DeMarco и Lister, в преуспевающих командах обычно присутствует сильное ощущение общности интересов и гордости за свою команду, а также (по крайней мере, в безнадёжных проектах типа «невыполнимая миссия») чувство, что они в состоянии хорошо выполнять свою работу и получать от этого удовольствие. С другой стороны, если организация не в состоянии обеспечить создание такой сплочённой команды, это может привести к тому, что DeMarco и Lister называют «командным самоубийством» (teamcide) – т.е., принимается сознательное или бессознательное решение плыть по течению и не совершать никаких действий для создания сплочённой и целостной команды. Такая ситуация обычно порождается следующими причинами:

21) Оборонительное руководство – не доверяющее проектной команде. Отметим, что при этом для команды становится очень важным наличие «защитника», как обсуждалось в главе 2.

22) Бюрократия – изобилие бумажной работы. Если команда обладает хоть каким-то здравым смыслом, она просто откажется заниматься бумажной работой или невнятно пообещает вернуться к ней после окончания проекта.

23) Физическое разобщение участников команды – (например, по различным зданиям, городам или странам) – конечно, электронная почта и средства групповой работы могут частично решить эту проблему, однако этого явно недостаточно для поддержки командного духа, который столь необходим для успеха безнадёжного проекта.

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

25) Снижение качества продукта – хотя команда может быть готова к тому, чтобы допустить некоторое снижение уровня качества с целью своевременной разработки «достаточно хорошего» ПО, обычно существует некоторая нижняя грань, которую они откажутся перейти. Понятие качества может подразумевать наличие дефектов (ошибок), отсутствующие функции, примитивный пользовательский интерфейс или некачественную документацию.

26) Нереальные сроки – настолько жёсткие сроки, что команда абсолютно не верит в возможность их выполнения. Такая разновидность «командного самоубийства» обычно превращает проект «невыполнимая миссия» в «самоубийственный» проект.

27) Произвол руководства – роспуск проектной команды после завершения проекта. Как было отмечено выше, некоторые команды по завершении проекта приходят к выводу, что он невыразимо скучен, а пользователи, для которых они разрабатывали свои программы – неблагодарные деревенщины; таким образом, единственное удовлетворение, полученное от проекта, заключается в удовольствии от совместной работы в одной команде с конкретными людьми. В самом деле, это удовлетворение может быть настолько большим, что участники команды выражают надежду на перспективу продолжения совместной работы в будущих проектах. Но на их беду тот командный дух, который помог им добиться успеха, зачастую воспринимается руководством как угроза для своего благополучия, поэтому роспуск такой команды после завершения проекта является обычным делом. Такая перспектива, в свою очередь, является настолько деморализующей, что команда может распасться ещё до окончания проекта.

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

28) Формирование: участники команды определяют цели, роли и направление работы.

29) Утряска: команда устанавливает правила и процедуры принятия решений и, как правило, пересматривает роли и ответственность.

30) Нормирование: вырабатываются процедуры, стандарты и критерии.

31) Выполнение: команда начинает функционировать как целое.

В идеальном случае команда оказывается уже прошедшей первые две стадии ещё до начала проекта – поскольку участники команды работали вместе в предыдущих проектах. Тем не менее, все проекты разные, и в каждой проектной команде обычно имеются один или два новых человека, присутствие которых повлечёт за собой некоторое «формирование» и «утряску». Но независимо от того, сколько времени потребуется на весь процесс – день, неделя или месяц – он все равно произойдёт; если это окажется возможным, менеджеру проекта следует постараться как можно больше ввести команду в курс дела ещё до «официального» начала проекта, с тем, чтобы к этому моменту уже оказаться в стадии «выполнения».

Важно также не забывать, что даже сплочённая команда может развалиться под воздействием тех стрессов, которые они испытывают в безнадёжном проекте. В своём письме ко мне Dale Emery рекомендует, чтобы менеджер проекта внимательно следил за процессами, происходящими в команде:

В худшем случае может случиться, что команда так и не пройдёт первые две стадии, или, иначе говоря, встанет на путь «командного самоубийства», не сумев справиться с перечисленными выше проблемами. Если через какое-то время менеджер проекта (или кто-нибудь из более высокого руководства) обнаружит, что так оно и произошло, может оказаться слишком поздно формировать новую команду. Се ля ви.

4.5 Условия работы

Проблемы создания нормальных условий для работы уже так много лет обсуждаются среди разработчиков ПО, что кажется бессмысленным снова их поднимать. Tom DeMarco и Tim Lister, чья книга уже не раз цитировалась в этой главе, уделяют большое внимание тем преимуществам, которые даёт создание нормальных условий для работы; например, если разработчики ПО работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе и постоянно отвлекается на посторонние дела. Проанализировав работу 600 разработчиков ПО, DeMarco и Lister смогли получить результаты, убедительно говорящие о том, что продуктивность работы тех, кто находится в хорошем офисе и может закрыть дверь, не отвечать на телефонные звонки и не отвлекаться на посторонние дела, почти в 2,6 раза выше, чем у находящихся в обычном офисе.

Хотя DeMarco и Lister опубликовали свою работу в 1987 году, с тех пор в условиях работы большинства разработчиков ПО мало что изменилось – за исключением фирм-разработчиков ПО. Условия работы в Microsoft и в большинстве других софтверных компаний Силиконовой Долины в самом деле достаточно цивилизованные – отдельные помещения с закрытыми дверями, наличие содовой, сока и других напитков, и «постоянный» телефонный номер, который остаётся за программистом даже в том случае, если он перебирается в другое помещение.

Что касается разработчиков ПО, работающих в банках, страховых компаниях, правительственных учреждениях, промышленных предприятиях и сотнях других компаний, которые до сих пор смотрят на программное обеспечение как на «накладные» расходы, то им приходится работать не в нормальных офисах, а в отгороженных клетушках, где возможность сконцентрировать свои умственные усилия на решении какой-либо проблемы варьируется от плохой до полностью отсутствующей. Звучит набившая оскомину музыка, не прекращаются телефонные звонки, лают собаки, кричат люди, и нет никакого спасения от кого угодно (от курьера до директора), кто может засунуть голову в твою комнату и отвлечь тебя. Как отмечают DeMarco и Lister: