hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								438m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 17. Вместе мы – силаClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Администратор базы данных

Проектирует и разворачивает структуру базы данных для обеспече% ния проекта.

Проектировщик

Работает на более низком, чем архитектор, уровне, проектируя компоненты системы. Часто эту работу выполняют программисты.

Программист

Разумеется, это главный человек в команде!

Менеджер проекта

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

Администратор проекта

Помогает менеджеру, решает практические проблемы функциони% рования команды.

Инженер по контролю за качеством

Разрабатывает планы QA и добивается соответствия качества вы% пускаемого кода принятому стандарту.

Специалист по подготовке пользователей

Составляет руководства по работе с программным продуктом, сле% дит за точностью маркетинга, составляет графики обучения и т. п.

Специалист по поставке продукта

Другими словами, инженер по выпуску. Организует упаковку, из% готовление, дистрибуцию и установку конечного продукта.

Инженер по сопровождению

Осуществляет поддержку продукта, установленного у пользовате% лей.

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

Групповая работа

Это стадия, когда команда полностью укомплектована. Вращаются все шестеренки, и процесс создания программного продукта неумоли% мо движется вперед.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Жизненныйm		цикл команды
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
439Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

В этой фазе команда проходит большую часть своего существования, добиваясь целей проекта. Для этого общая большая задача разбивает% ся на серию мелких. Каждый член команды получает свой пакет работ и синхронизирует свою деятельность (скажем, с помощью проведения совещаний или личного общения). Результаты труда всех членов ко% манды интегрируются по мере готовности. Постепенно программный продукт обретает форму.

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

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

Роспуск команды

Со временем все, даже самые затянувшиеся, проекты подходят к кон% цу. Конец может означать выпуск успешного продукта, которым дово% лен клиент. Возможен вариант, когда продукт не удался и разработка прекращена досрочно. В любом случае проект завершен, и команда снимается с него.

С самого начала разработки нужно иметь в виду четкую конечную точ% ку. Ни одна команда не может быть вечной или планировать работать до бесконечности. Желание завершить работу служит мотивацией, и мно% гие программисты не стали бы сильно напрягаться на работе, не будь они поставлены в жесткие временные рамки.

По этой причине любая команда должна планировать роспуск или пре% образование в другой тип команды (например, по обслуживанию или со% провождению) по завершении проекта. Этот план должен быть рассчи% тан как на обычные условия, так и на случай аномального завершения.

Роспуск команды не происходит в одночасье. Проекты не прекраща% ются неожиданно; они постепенно сворачиваются. Обычно люди сни% маются с проекта по мере того, как отпадает в них надобность. Никому не нужны праздно шатающиеся люди, только потребляющие ресурсы. При уходе каждого участника позаботьтесь о том, чтобы сохранились его важные знания или результаты труда. При распаде команды очень легко потерять информацию.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								440m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 17. Вместе мы – силаClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Не теряйте информацию при уходе людей из команды. Организуйте ее пере& дачу и получите от них все важные данные, включая документацию по коду, инструментарий тестирования и инструкции по сопровождению.

Что происходит, когда команда добирается до окончания проекта? Можно предпринять одно из следующих действий:

•Перевести команду в режим поддержки для сопровождения про% дукта.

•Начать какую%то новую разработку (может быть, новую версию то% го же продукта).

•Инициировать посмертное вскрытие, если проект провалился.

Кадры решают все!

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

Лучше меньше, да лучше

Большие команды требуют больше каналов связи и больше администрирования, в них больше потенциальных возмож% ностей для провала и труднее обеспечить общее видение.

Распределяйте задачи соответственно способностям, а также мотивации

Не забывайте про Принцип Питера1: не нужно выдвигать от% личных программистов на руководящие должности, которые они не могут или не хотят занимать.

Делайте инвестиции в людей

• Вы получите от них больше отдачи, если что%то вложите в них. Технологии быстро развиваются; дайте им возмож% ность обновлять свои знания. Иначе они уйдут туда, где могут приобрести более ценный опыт.

1 Принцип Лоуренса Дж. Питера гласит: «Хороших работников про% двигают на высший уровень, соответствующий их компетентности, и поскольку они с ним справляются, их продвигают еще на одну сту% пеньку – на тот уровень, где они уже некомпетентны.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Жизненныйm		цикл команды
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
441Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Не выращивайте экспертов

Опасно, если некий программист становится единственным экспертом в своей области. Из%за этого весь проект ставится под угрозу.1 Есть люди, которые активно стараются стать не% заменимыми программистами, других делают ими насильно, не разрешая заниматься ничем другим. Когда ваш эксперт за% хочет увидеть новые горизонты, он уйдет от вас. И как вы по% сле этого будете сопровождать программный продукт?

Выбирайте людей по принципу дополнительности

Невозможно, чтобы команда состояла целиком из экспертов мирового масштаба. Точно так же нельзя, чтобы все члены были неопытными программистами. Необходимо здоровое со% четание разных навыков. Необходимо также подбирать людей по личным качествам, чтобы они хорошо сочетались и могли работать вместе.

Избавляйтесь от тех, кто мешает

Тех, кто не вписывается в команду, нужно удалять. Делать это нелегко, но гнилой член может испортить всю команду, а по% следствия промедления будут тяжелыми (см. «Зыбучие пески» на стр. 423). Не будьте сторонним наблюдателем хода событий и не надейтесь, что все само уладится. Решайте проблему.

Успех команды зависит от того, кто в нее входит. В успешной ор% ганизации правильно выбирают сотрудников и полностью ис% пользуют их возможности.

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

•Разделить команду на части для работы над отдельными проектами (или отпустить людей, если их контракт закончился).

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

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