Как оценить подходит ли проект команде

Body

Как определить, подходит ли проект для команды?

Возникновение проблемы

Однажды мне на UpWork-е пришло необычное предложение о работе. Команда программистов из Сибири искала человека, который поможет им искать проекты на этой бирже и проводить начальные переговоры с клиентами. Вообще-то я программист, а не продавец, но кое-какой опыт общения с клиентами на UpWork у меня был, и я согласился.

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

Ходить с каждым вариантом к команде спрашивая их мнение было бы не очень удобно (у нас было 8 часов разницы во времени) да и не очень умно. Нужно было какое-то решение, которое помогло бы мне быстро оценить проект с точки зрения того, насколько он подходит команде. Мне не нужна была 100% точность – тут важнее было отсеять то, что команда точно не потянет.

Матрица навыков как решение

Тут я вспомнил про такой инструмент как матрица навыков (skills matrix) и предложил техническому лидеру команды сделать такую матрицу. Это заняло почти неделю вместо ожидаемых мной 2-3-х дней, но зато, имея на руках эту информацию, я уже смог более точно настроить фильтры для поиска на UpWork и количество положительных откликов от потенциальных клиентов возросло в три раза. Что же это за чудесная матрица, как её заполнить и как использовать?

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

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

На пересечении строки и столбца должна стоять некая оценка того, насколько данный член команды владеет данным навыком. Всё просто и понятно. Думаю, что мне не нужно объяснять, что теперь, глядя на предложение от клиента, я мог очень быстро оценить, насколько команда может «потянуть» данный проект.

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

Ошибка №1 – набор навыков

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

Безусловно, у каждого опытного разработчика найдётся «в загашнике» какая-нибудь редкая технология или библиотека, которой он один раз в жизни пользовался. И, конечно же, он непременно захочет добавить её в матрицу. В этом случае нужно сказать твёрдое «нет» - матрица должна содержать список только актуальных и востребованных клиентами навыков. Другое дело, если у вас в команде есть единственный гуру в какой-то области – тогда его навык должен быть в матрице, но такой «незаменимый» игрок – отдельная тема.

Другая возможная крайность список в стиле «могу копать, могу не копать» - то есть 5-6 высокоуровневых навыков, по которым совершенно невозможно ничего определённого сказать. В идеале список навыков должен состоять из 3-5 групп в каждой по 5-7 навыков. Группы отражают высокоуровневые навыки (front-, back-, ЯП и т.д.), а конкретные навыки в группе достаточно общие, чтобы эффективно сопоставлять с требованиями клиента.

Ошибка №2 – шкала оценки

Я рекомендую простую и понятную шкалу от 0 до 10. От «я даже не знаю, что это такое», до «я сам это написал». Но тут очень важно определиться с полутонами, иначе вы получите, по сути, 2.5D матрицу заполненную исключительно 0-ми и 10-ми с редкими вкраплениями 5-ок. Это лучше, чем ничего, но не позволяет эффективно оценить, насколько команда способна потянуть действительно сложный проект.

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

А судьи кто?

Итак, будем считать, что у нас есть список навыков и для каждого навыка есть шкала позволяющая поставить оценку владения данным навыком от 0 до 10. Но как организовать сам процесс заполнения матрицы данными:

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

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

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

Проблема №1 – актуализация

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

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

Проблема №2 – доступность

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

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

Выводы

Матрица навыков позволяет вам быстро оценить любой потенциальный проект с точки зрения принципиальной возможности его выполнения вашей командой. Она не даёт 100% ответа на вопрос «можем ли мы это сделать», но позволяет отсеять заведомо «неподъёмные» проекты.

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

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