Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

• Медлительность

Хороших кандидатов трудно найти. Если вы уверены, что нашли достойного, — действуйте быстро. Не стесняйтесь пригласить кандидата на интервью вечером или предложить прилететь на выходные. Будьте готовы провести собеседование в тот же день. Я не предлагаю спешить с собеседованием, но бывают обстоятельства, требующие быстрого принятия решения, в том числе во внеурочное время.

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

• Неправильный баланс

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

• Текучесть кадров

Текучка существует всегда. Меняются личные обстоятельства и приоритеты. Люди уходят по причинам, которые вы не можете контролировать: родился ребёнок, нужно быть поближе к родным, далеко до работы… С другой стороны, текучка может указывать на серьёзные проблемы в коллективе или организации. Чтобы оставаться в курсе причин текучести кадров, беседуйте с людьми перед их увольнением и прислушивайтесь к их замечаниям. Если обнаруживается внутренняя проблема, спросите других сотрудников, разделяют ли они такую точку зрения. В больших организациях неплохо вести список причин увольнения сотрудников. Эти сведения помогут отслеживать тенденции и принимать соответствующие меры.

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

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

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

• основной состав группы — специалисты, полностью занятые в создании нового программного продукта:

— менеджеры проекта;

— программисты;

— тестировщики;

— разработчики документации;

— инженерные психологи;

— технологи по разработке ПО;

• вспомогательная группа — специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

— группа менеджмента и маркетинга продукта;

— специалисты по технической поддержке ПО;

— администраторы бета-тестирования.

Очень важно, чтобы перечисленные функциональные подразделения участвовали в работе над проектом с самого начала. Чем раньше люди смогут понять суть требований к продукту и принять участие в их критическом анализе, тем лучше подготовятся к исполнению собственной миссии и ощутят свой вклад в успех проекта. Кроме того, чтобы завершить создание продукта в срок, все перечисленные подразделения должны работать параллельно на протяжении всего цикла разработки. Решение этой задачи будет описано в главе 11 — там мы рассмотрим включение в график проекта взаимно скоординированных во времени промежуточных этапов.

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

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

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