Плавая утром в бассейне, я вдруг задумался о том, почему у нас в компании есть команды долгожителей, почему не всегда в них задерживаются новички. Почему есть команды относительно новые, но усердно работающие над старыми проектами, которые начинались до них и достались им в плачевном состоянии. Почему, в конце концов, некоторые проекты любимы, а некоторые - нет. Проще говоря, свой километр я плавал крайне озадаченным.
На самом деле, вопрос не имеет однозначного ответа, равно как и не бывает, на мой взгляд, проектов, которые бы, в течение своей жизни, не переходили из одного состояния в другое. У нас есть проект, команда разработчиков которого сохранилась практически в первозданном виде, ее членами являются взрослые люди, которые даже в моменты полной усталости "от всего происходящего", продолжают пилить свое детище. Или, например, среди множества прочих, у моей команды есть проект, который был чем-то непонятным и чуждым, был ненавистным, был надоевшим, но стал, если не любимым, то своим. А есть у нас в компании и те проекты, которые все еще являются, своего рода, нелюбимыми детьми.
В начале жизненного цикла проект всегда кем-то начинается. Именно эта, стартовая, команда его проектирует и вкладывает свою душу, чтобы результат был лучшим и никак иначе. Он их, он - проект людей. Для простоты аналогии, я бы сравнил этот период с радостью от сборки конструктора, постройки дома или посадки дерева. Все наши мысли и действия подчинены очарованию тем, что создано нашими руками, нашими стараниями - мы испытываем чувство невероятной гордости и ответственности. Вспомните, как дедушка показывал вам на высоченное дерево и рассказывал о том, что в это месте ничего не было, но потом он и его товарищи посадили здесь саженцы. Вспомните яблоню на даче, у нее тоже есть своя история и отношение у вас к ней особое, ведь она своя. Свое и не свое - за этими понятиями для каждого человека скрывается очень многое. Чувства к своему могут обостряться вместе с положительной обратной связью от тех, для кого мы это делаем - наших клиентов. Более того, если что-то не получается, то и мы переживаем особенно сильно.
Но время идет, команды пополняются, а иногда и полностью замещаются новыми людьми, не имеющими общей истории с проектом. И относятся они к нему, пусть и не плохо, но иначе. И вот проект переходит в новую фазу своего развития, теперь они - люди проекта. Если хотите, они, скорее, вынуждены им заниматься, нежели испытывают желание, подогреваемое изнутри. Возникает вопрос, какая из приведенных мной парадигм лучше или эффективнее? Я считаю, что первая, но с очень небольшим перевесом и кучей различных "Но". Заранее скажем, что наиболее частой конфигурацией является их комбинация, но об это мы поговорим позднее. И, разумеется, дальнейшее рассмотрение этого вопроса мы будет выполнять со стороны менеджера проекта.
Проект людей
Проект людей находится в особо охраняемой зоне. Управление им, как и его судьба, зависят от вполне стандартных факторов, таких как его положение на рынке, ролей в команде и так далее - в этом он ничем не отличается от парадигмы "люди проекта". Успешный проект всегда должен развиваться, а его развитие, если утрировать, диктуется рынком или иными внешними факторами. Вот здесь и рождаются первые проблемы. Порой, как молодая мама не согласна с воспитательными методами в детском садике, так и разработчики могут быть не согласны с тем, каким образом должен измениться создаваемый ими продукт. Мотиватором такого несогласия может быть все что угодно, начиная от "нам лучше знать" и заканчивая "это разрушит идеальную архитектуру". Чем успешнее и сложнее проект, чем больший вклад он вносит в общее дело, тем, на мой взгляд, сильнее сопротивление. Следующий пласт проблем кроется в высоком уровне обособленности, фундаментом которой является общая история. Отсюда вытекают проблемы с адаптацией новых сотрудников - люди могут быть не приняты, либо просто чувствовать себя несколько лишними.
Как говорилось выше, ситуация в значительной степени определяется ролями и характером конкретных личностей. Поэтому, если разработчики благосклонны и настроены на взаимодействие или менеджер проекта является для них авторитетом, а еще лучше, если он прошел весь путь вместе с ними, то проблемы могут и не возникнуть. Но, к сожалению, далеко не всегда это так. Высококвалифицированные специалисты, зачастую, очень не просты, а жизненный цикл производимого продукта длителен, за это время компания изменяется, меняются руководители и взгляды на вопросы, связанные с маркетингом и управлением.
Если говорить о положительных сторонах, то, безусловно, главным плюсом является сплоченность и стабильность команды. Менеджеру меньше стоит беспокоиться о вероятных увольнениях или о том, насколько качественно люди выполняют свою работу.
Наверняка, кто-то, прочитав последние несколько абзацев, скажет: "Это же банально, это и есть обычная работа, так везде.". Согласен, но речь не о банальностях, а о необходимости четко понимать мотивы людей вести себя тем или иным образом. Руководитель проекта - дирижер, его действия должны быть выверены, а для этого он должен принимать во внимание все аспекты и уметь, хотя бы чуть-чуть, заглядывать в головы своих коллег.
Люди проекта
Ситуации, когда проект довлеет над своими же создателями, возникают по самым разнообразным причинам.
- Проект изначально задумывался как один из многих - есть проекты, работа над которыми ведется по остаточному принципу. И это далеко не всегда плохо, важно лишь точно понимать, что для этого проекта это приемлемо. Кстати, у моей команды около 6 основных проектов, 2 из них ведутся по остаточному принципу, они просто существуют и я не думаю, что кто-то испытывает к ним особые чувства. Хотя, на всякий случай, я все же стараюсь поддерживать хотя бы минимальный интерес, поскольку ситуация может резко поменяться и данным продуктам потребуется экстенсивное развитие.
- Заказная разработка с фиксированными сроками и бюджетом. Такие проекты очень часто отягчаются не ясными перспективами дальнейшей поддержки или желанием/возможностью усложнения дальнейшей поддержки силами третьих лиц. Именно по этой причине мы все реже стали обращаться к фрилансерам для решения каких-либо непрофильных для нас задач. С фрилансерами у нас разные цели. У них - поскорее сдать проект, у нас - сделать продукт лучшим в определенной временной перспективе. Фрилансеру просто не интересно думать о стройности кода, о масштабируемости и прочих мелочах. Наверняка кто-то скажет, что все зависит от того, насколько адекватно мы готовы оплачивать работу, мол, если заплатить адекватно, то и фрилансера можно найти очень толкового. В этом есть истина, но в реальности все оказывается сложнее. Требуется время на поиски, на срабатывание, на ошибки; сохраняются проблемы контроля и куча других. В общем, все не просто так.
- Значительное размытие команды, которое может произойти по разным причинам, например, вследствие быстрого ее масштабирования, утраты значительной части состава прежней команды.
- Всем пофиг - этот фактор поражает самые разные проекты, даже самые суровые. Как правило, начинается все с менеджера, который откровенно не тянет или выгорел, а может и с самого начала пришел получать зарплату. В этой ситуации происходит деградация коммуникаций, разложение коллектива и т.д. Кстати, менеджеру может быть пофиг временно, например, в силу переутомления или проблем в личной жизни.
Как бы нам не хотелось избежать такой стадии развития проекта, но, как мне кажется, она неизбежна. Если вы хоть сколько-нибудь долго занимаетесь управлением проектами, то обязательно сталкивались с ситуацией, когда нужно напрячь все силы, чтобы переломить ситуацию и вернуть проект людям. Это очень не просто, но необходимо.
Кроме того, как вы понимаете, людей проекта мало что связывает с тем, что они создают. А если не связывает, то какая разница чем заниматься, поэтому если поступит более выгодное предложение от другого работодателя, то всегда можно уволиться, ведь особой разницы не будет. Будет странно, мы не станем утверждать, что ваша команда теперь с вами навеки и вы будете пилить свой проект всегда и несмотря ни на что. Разумеется, нет, люди все равно будут уходить, перегорать, уставать и т.д. Но результат их работы будет значительно лучше, если они будут любить то, что они созидают.
Но что именно нужно делать? Главное - любить проект самому. Если менеджер горит своим делом, то это уже 50% успеха. Остальные 50% я вижу достижимыми комбинацией факторов, среди которых:
- Больше трэша и угара! Если разработчики кулуарно называют проект не по его официальному названию, а как-то иначе, да еще и с легкой насмешкой, то не торопитесь пресекать это. Ваша задача - перевести это в юмор и даже поддержать. Наш проект переживал 2 или 3 внутренних переименования, я сначала беспокоился, что это может негативно отразиться на общем отношении к нему, но потом сам подключился и начал называть его так же. Сейчас я вижу, что это сыграло положительную роль. Буквально на днях ко мне подошел один из ребят и сказал, что нам нужно интегрировать в продукт маскот, долго описывал что-то неприемлемо-феерическое. Я ему предложил пересмотреть свои идеи в сторону большей приемлемости для серьезного продукта. В итоге, к обсуждению подключились почти все. Ну что ж, будем заказывать дизайн.
- Больше персональной ответственности! Людям свойственно уставать, если они работают над разными подсистемами и не имеют какой-то выделенной зоны ответственности. Необходимо закреплять какие-то модули/подсистемы/функции за конкретными разработчиками, это может происходить разными путями, но ниболее эффективным я вижу установление ответственности по завершении работы над данной сущностью. То есть, программист долго работал на какой-то функцией или багом, а в конце мы говорим ему, что он сделал большой вклад и для закрепления результата мы делаем его владельцем данной сущности. Не всегда это работает, особенно, когда речь идет о больших командах и невозможности каждому найти свой кусок, тогда можно говорить о групповом владении. В таком случае мы говорим именно о владении, потому что говорить о групповой ответственности смысла нет, ведь если ответственных больше одного, то ответственных нет.
- Больше участия в принятии решений! Вы уже знаете, что очень важно привлекать участников проекта к обсуждению его судьбы. Однако часто случается так, что это привлечение носит формальный характер, что только отдаляет людей от проекта, делает его чуждым, ведь в нем нет ничего своего. Поэтому старайтесь принимать предложения разработчиков, а если не готовы их принять, то сделайте так, чтобы они думали, что принятое решение без них было бы невозможным, а иногда и больше - это была именно их идея, а вы ее просто развили. Вообще, я считаю, что нет большего греха, чем натягивание менеджером лавров на себя.
- Больше информированности! Рассказывайте команде о судьбе их продукта, сообщайте обратную связь, независимо от того, положительная она или отрицательная. Переживайте вместе с ними, радуйтесь вместе с ними. Никогда не держите команду в информационном вакууме. Не заигрывайтесь в большого начальника, решающего особо важные вопросы, в которые не могут быть посвящены недостойные. Если вы хотите, чтобы они горели проектом, то вы должны раздувать огонь.
Мы попытались описать ключевые факторы, потому что, как вы понимаете, список может быть очень длинным, да и каждый из приведенных пунктов обусловлен множеством нюансов и имеет огромное количество ответвлений. Своей задачей мы видим определение пути, следование по которому может поможет создать общую историю проекта и людей, вернуть проект людям. Да, после этого вы получите проект людей со всеми его тяготами и лишениями, но ведь это позволит вам реализовать что-то действительно полезное и качественное. Что может быть важнее?