Сергей Щеглов – Фреймворк управления и анализа проектов DaShe (страница 12)

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

1. Вежливость и уважение. Будущему разработчику должно быть приятно общаться с ПМ – что впоследствии перерастет в «приятно общаться по поводу проекта» и в «приятно делать проект в такой компании».

2. Заинтересованность. Полезно узнать о кандидате какой-нибудь факт, не относящийся к его профессиональной деятельности, и упомянуть его в разговоре. Это покажет, что: 1) кандидат интересен ПМ как личность; 2) ПМ располагает временем и желанием обсуждать отвлеченные темы, а значит, к нему можно обращаться с личными вопросами.

3. Благожелательность. Каждый раз, когда в ходе собеседования возникает повод похвалить кандидата или выразить положительную эмоцию по поводу его слов или действий, это нужно делать.

4. Особое внимание общему интеллекту. Профессиональная квалификация – это владение неким набором компетенций. Высокий интеллект (IQ > 135) – это способность быстро освоить любую требуемую компетенцию. В ходе проекта требуемые от разработчиков компетенции меняются очень часто («а давайте попробуем ХХХ»), поэтому любой фиксированный набор компетенций окажется недостаточным, и разработчика с низким IQ придется менять. Для проектов продолжительностью от одного года и более интеллект становится единственным критерием, исходные компетенции попросту несущественны.

Общий принцип: собеседование – это первый рабочий день кандидата в проекте, а не соревнование «кто лучше споет песенку».

Результат. Кандидат, который будет нанят в проект, будет нанят уже мотивированным.

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

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

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

1.2.7. Организационно-ресурсная схема проекта

После закрытия всех вакансий становятся известными личные профили всех аффилянтов проекта и пути доступа ко всем инфраструктурным ресурсам. Это позволяет создать организационно-ресурсную схему проекта, что представляет собой матрицу 3 × 3, в которой остаются незаполненные клетки.

Название «схема» заставляет предположить, что ПМ должен заполнить некий лист на всю стену, где стрелочками размечены тысячи связей между разными субъектами и объектами проекта. Ничего подобного: схемы, на которых присутствует больше семи субъектов и объектов и больше семи связей между ними, вызывают не понимание, а головную боль. Единственный смысл заключается в том, что, составляя такую схему, человек формирует общее понимание у себя в голове (саму схему после этого можно выбросить). Поэтому ПМ может составлять организационно-ресурсную схему в любой удобной для себя форме (и на большом листе бумаги, и в виде отдельных листочков, разложенных на кучки, и в виде Excel-листов с таблицами для разных компонентов и т. д.). Главное – такую схему действительно нужно составлять (выбросить еще успеете), чтобы вся информация о проекте была хорошо обдумана и в какой-то форме структурирована.

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

1.3. Определение требований и ограничений

В мечтах создаваемый в ходе проекта продукт может быть любым – создавать деньги из воздуха, читать мысли и проходить сквозь стены. Реальный продукт отличается от иллюзорного ранжированием полезных свойств («сквозь стены пусть проходит, а денег из воздуха не надо, подсудное дело») и ограничениями – тем, чего делать нельзя («стена чтоб осталась целой»).

Требованиями в DaShe называются позитивные условия осуществления проекта («обеспечить такую-то функциональность», «использовать такую-то технологию», «произвести пробное внедрение в такой-то компании»), а ограничениями – негативные условия («потратить не больше миллиона», «сделать не позже 7 ноября», «никакой утечки информации к конкуренту ХХХ», «офис закрывается в 20:00, всех выгоняем», «использовать только легальное программное обеспечение»). Например, когда Ашот хочет, чтобы разработка велась в современном красивом open space, куда постоянно ходили бы журналисты, – это требование; а когда Семен желает, чтобы о разработке знало как можно меньше людей, – это ограничение. Совместить требования и ограничения в одном и том же проекте непросто, но это и есть часть работы ПМ. Ну а чтобы совместить, нужно сначала их определить.

Требования и ограничения возникают не только как пожелания стейкхолдеров, но и в силу особенностей всех аффилянтов, а также объективных свойств используемых в проекте ресурсов (офис закрывается в 20:00, но зато он практически бесплатен). Основная цель выявления требований и ограничений остается прежней: это раннее выявление рисков (в данном случае – противоречивых свойств, приводящих к конфликтам) и их минимизация.

Источниками как требований, так и ограничений являются те самые аффилянты проекта, которые были выявлены на предыдущих этапах. Сам ПМ не может и не должен знать все особенности внешней среды: какие свойства продукта важнее, какие технологии с большей вероятностью сработают и т. д. Все эти сведения поступают в проект от аффилянтов (одним из которых, конечно, является и сам ПМ – в сфере своей компетентности).

Ограничения могут возникать и из уже выявленных свойств аффилянтов. Например, под проект может быть выделена отличная команда разработчиков; но что, если тимлид этих разработчиков вдрызг разругался с ПМ несколько лет назад? Ресурс в виде «лучших разработчиков» оказывается ограничен уровнем сотрудничества тимлида. Или если финансовый директор явно продвигает интересы банка ХХХ: его настойчивые требования «пусть клиенты берут кредиты в правильных банках» обязательно войдут в противоречие с другими требованиями к продукту, и появятся ограничения либо на финансирование, либо на свойства продукта.

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

1.3.1. Конфликты между аффилянтами

Это чаще всего встречающиеся, реже всего ожидаемые и наиболее деструктивные по отношению к проекту ограничения. Составленная на предыдущем этапе таблица конфликтов анализируется следующим образом: если конфликтующие аффилянты находятся в разных клеточках организационно-ресурсной схемы, возникает ограничение типа «запрет контактов», а если в одной и той же клеточке – ограничение типа «запрет повода».

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

Начинать анализ следует с возможных политических конфликтов (между стейкхолдерами): если в интересах какого-либо аффилянта – «подсидеть» другого аффилянта, он может сознательно вести проект к краху, чтобы свалить вину на конкурента. Другие варианты конфликта между стейкхолдерами – из-за требований к продукту («мои требования важнее!») или к процессу («пусть мой племянник будет главным дизайнером»; «я должен контролировать расходы»).