Формирование проектной команды обычно обсуждается в аспекте создания команды внутри компании разработчика. Однако для проектов, относящихся к категории заказных разработок, обсуждать данную тему только в этом аспекте, на мой взгляд, недостаточно.
Если читать литературу и прессу, складывается стойкое ощущение существования китайской стены: по одну сторону волшебный мир software development со всеми его buzzwords, методологиями, нотациями, новыми средствами разработки и, наконец, «peopleware», а по другую сторону этого монумента – мир заказчиков, мир «наживы и чистогана» с его сроками, рабочими местами и ROI. Люди с «темной стороны стены» думают, что они лучше всех на свете могут руководить разработкой ПО; люди со «светлой стороны стены» медитируют, а когда перестают, приходят к мысли, что работа с заказчиками портит их карму.
В ИТ сообществе и ИТ изданиях неоднократно поднимался вопрос: «Может и должен ли заказчик влиять на формирование команды исполнителя?». Вопрос, собственно, риторический. Заказчики этим занимаются постоянно, как только находят на это время. Даже если отбросить Outstaffing и проекты с оплатой «по факту» и рассматривать только проекты с «фиксированной стоимостью», заказчики очень часто стремятся выбирать себе компанию разработчика с самой профессиональной командой. Нужно объяснять почему? Думаю, ситуация очевидна: это просто работа с рисками. Лучше заплатить больше, но с большей вероятностью сделать успешный проект, чем наоборот.
Но давайте посмотрим на это с другой стороны: «Может и должен ли Исполнитель влиять на формирование команды, работающей на проекте со стороны заказчика?». Ответ также очевиден: конечно, может.
И желательно, чтобы хотел. Почему? Да потому, что если руководитель/куратор проекта со стороны заказчика не умеет или не хочет формировать и сплачивать команду проекта, то это все равно кто-то должен делать. Зачем, спросите вы, это нужно? Казалось бы, есть же договор, где все прописано: требования, деньги, сроки и прочие условия. Однако нет, это не всегда работает. Помимо денег и сроков, есть еще и репутация. Как репутация компании, так и репутация каждого конкретного человека на стороне разработчика. Любому разработчику хочется, чтобы результатами его работы не только пользовались, но и чтобы эти результаты нравились. Чтобы о команде разработчика и о конкретных людях говорили хорошие слова, звали работать вместе дальше, писали лестные отзывы в прессе и на форумах.
Чтобы в результате проекта получилось не то, за что «уплочено», а то, что реально будет помогать людям работать, необходимо, чтобы люди со стороны разработчика и со стороны заказчика работали как одна команда на проекте. Каждый должен быть на своем месте, и люди в команде должны дополнять друг друга и таким образом добиваться результата.
Но ведь мы ходим на работу не только ради результата, нам же важен еще и процесс.
Как часто в моей практике были ситуации, когда я видел, что проект превращается для ребят со стороны разработчика в кошмар. И все, что они хотят на проекте, можно выразить одной фразой: «Чтобы это побыстрее закончилось». Такая работа никому ничего положительного обычно не приносит. В такой ситуации люди обычно хотят побыстрее уйти из проекта, из компании, из профессии. Вы хотите терять людей? Нет? Значит, надо заниматься созданием комфортных условий работы. При этом недостаточно посадить человека в просторный светлый офис с бесплатным кофе и диваном, дать ему два 21 дюймовых монитора и ноутбук. Даже разрешить работать из дома - это не выход в данном случае. Самые невыносимые условия создают не старый компьютер или маленький монитор, их создают люди.
Понятно, что заказчик обычно привлекает на проект сотрудников, которые одновременно с проектными работами продолжают выполнять свои непосредственные обязанности. Их мотивация может быть самая разная. Некоторые будут активно участвовать в проекте, другие нет. Некоторые будут вести себя демократично и открыто, другие могут вести себя слишком формально или даже некорректно. Одни представители заказчика могут быть профессиональны, другие могут быть назначены на проект по принципу «назначим самого не занятого, пусть сидит там на встречах».
Если ключевые люди на стороне заказчика не хотят сотрудничать, не могут ответить на вопросы или как-то иначе срывают сроки работ, самое простое, что обычно происходит, – это фиксация факта: дескать, не можем дальше работать, т.к. не получили вовремя ответ на свой вопрос. Формализм как метод управления рисками вещь конечно полезная, но, на деле, не очень эффективная. Да, заказчик признает, что задержка произошла по его вине; но ведь и команда будет сидеть и ждать все это время, а это не лучшим образом скажется на ее моральном состоянии. Даже если исполнитель не потеряет в деньгах, то проиграет с точки зрения состояния морального духа команды.
Чтобы такого не случалось, стремление создать эффективную проектную команду, состоящую из людей со стороны разработчика и заказчика, должно быть обоюдным. Если заказчик назначил в команду не самых лучших людей, команда со стороны разработчика, на мой взгляд, может и должна пытаться ситуацию изменить. Всегда есть способы убедить не очень удобного человека самоустранится путем делегирования или убедить руководство заказчика поменять члена команды. Если выбора нет и человека заменить некем, то всегда можно попытаться найти подходы к каждому человеку лично. Это поможет не только успешно сделать проект, но и сделать процесс его выполнения более легким и предсказуемым. Также, и это немаловажно, если удастся сплотить команду, состоящую из представителей заказчика и разработчика, - это положительно скажется и на моральном духе каждого.
И последнее, что хотелось бы обсудить в этой связи. Часто возникает вопрос: «А кто руководит проектом, а следовательно, должен формировать команду, руководитель проекта на стороне разработчика или руководитель проекта на стороне исполнителя?» Я думаю, что это абсолютно не важно: формировать команду должны все, кто в нее входит. Людям должно быть приятно, работать вместе, они должны хотеть вместе добиваться успеха проекта. Без объединения усилий людей на стороне разработчика и заказчика, на мой взгляд, это вряд ли возможно.
© 2008 - 2012 Илья Корнипаев, info@reqs.ru |