Что раньше: ресурсы или сделка?

Сначала проект, а потом команда или наоборот

Предлагаю рассмотреть два варианта работы над проектом и подискутировать, какой подход вам ближе.

Первый вариант – у нас есть фиксированная команда из разработчиков и один продажник, который ищет проекты под эти ресурсы. Преимущества этого варианта:

• Быстрый старт в проекте. Мы оперативно реагируем на новые запросы, можем сразу внедриться в бизнес-домен, можем сразу сделать классное коммерческое предложение, потому что в нашу бизнес-модель заложено то, что сотрудники уже находятся в режиме ожидания нового проекта

• У свободных игроков между проектами появляется время на обучение и развитие – они могут реализовывать планы индивидуального развития, посещать конференции без ущерба текущим проектам и т.д.

• Минимальный онбординг на новом проекте. Сотрудник знает, что он делает, знает, что нужно сделать, у него есть понимание работы в команде.

• Компетенции команды уже подтверждены – мы можем прийти к клиенту и сказать: наш разработчик делал это уже 100 раз, и в 101-й раз он это сделает для вас.

Недостатки этого варианта:

• Это дорого.

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

• Можно кинуть только на какую-то мелкую техподдержку, но если человек другого профиля, он выгорит без интересных задач и уйдет к тому, кто способен обеспечить для него загрузку.

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

• Есть подтвержденные планы по загрузке команды, сроки и бюджет. Мы можем сказать, что мы стартуем проект 1 июля и к этому сроку HR-менеджеру нужно найти сеньора-разработчика с такими-то компетенциями и трех новых джунов.

• У нас есть возможность собрать команду под проект с нужным опытом в конкретном домене – требования уже более-менее определены, поэтому не придется тратить время на погружение.

• Не тратим ресурсы на время простоя сотрудников без активных проектов.

У этого варианта тоже есть минусы:

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

• Даже если мы найдем человека за пару недель, мы можем потратить много времени на онбординг – это тоже долго.

С такими вводными переходим к обсуждению – как это работает у вас?

Дискуссия

Владислав Дмитриев, «1С»: Я выступаю за компромисс между первым и вторым вариантом, потому что мало где востребованы сотрудники, заточенные только под определенные навыки и технологии. И наоборот, найти специалиста с нужными навыками под проект достаточно сложно – компании держатся за хороших сотрудников и никому их не отдают.

На практике выживают гибкие – те, кто готов разбираться в любой проблеме и подстраиваться под имеющиеся ресурсы.

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

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

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

Я считаю, что платформа 1С – удивительный инструмент, который позволяет легко делать сложные вещи. Я не знаю более эффективного инструмента для построения бизнес-приложений. Платформа 1С – это чудо, которое нужно использовать. Наши решения, такие как 1С:Аналитика, можно за месяц освоить, сделать проработку проекта и внедрить.

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

Николай Медведев, Билайн: Мне кажется, что необязательно собирать на проект сразу всех 20-30 специалистов. Проект может стартовать и с небольшим количеством специалистов – достаточно 2-3 аналитика. Разработчики в любом случае вступают в проект позже.

Таким образом, мы сначала подключаем 2-3 человека и затем подтягиваем остальных. А потом из проекта можно так же кого-то постепенно выводить. Это хорошая практика.

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

Алена Ивахнова: Я тоже считаю, что проекты всегда начинаются с фазы исследования, за которую отвечают аналитики. Причем аналитики имеют возможность одновременно работать не на одном проекте, и цикл работы аналитика на проекте меньше, чем цикл работы разработчика.

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

Хочу отметить еще один момент: в работе проектных команд применим принцип Парето – 20% усилий обеспечивают 80% результата. Мы берем одного сеньора, у которого уже есть определенный опыт, и даем ему двух джунов. Сеньор руководит верхнеуровнево и раздает задачи, а джуны развиваются и закрывают потребности в ресурсах.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.