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

• Дайте проявить себя каждому ведущему разработчику

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

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

Остаётся обсудить, на чём сосредоточить усилия исследователей. Если работа идёт в среде с небольшими ресурсами, позаботьтесь о том, чтобы шансы на успех исследовательской работы были максимальны. Следует разумно распределить усилия исследователей. В общем случае приоритетными являются следующие направления:

• Анализ тенденций и перспектив рынка

Каждые 3-4 года на рынке появляются новые, более совершенные технологии. Независимо от того, связаны ли новшества с графическим интерфейсом пользователя, клиент-серверными продуктами, моделями компонентных объектов или Интернетом, всегда следует идти в ногу с фундаментальными нововведениями и стараться, чтобы большие перемены не оставили вас позади. Направляйте исследования на поиск, анализ и мониторинг серьёзных изменений на рынке. Однако не заходите в своих исканиях так далеко, чтобы потерять связь с реальностью.

• Отбор новых идей

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

• Анализ инноваций и направлений работы конкурентов

Одна из самых важных областей исследования — анализ инноваций и направлений работы конкурентов. Чтобы успешно состязаться с ними, надо понимать их технологии, знать их сильные и слабые стороны.

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

Из собственного опыта

К концу работы над BoundsChecker 3.0 энтузиазм нашего ведущего разработчика изрядно поубавился: проект отнял много времени и сил, и необходимость перемен была очевидна каждому его участнику. В это время возникла ещё одна задача: нужно было разобраться, что может дать новая технология от Microsoft под названием СОМ для наших продуктов. СОМ привлекла большое внимание, её даже считали «дорогой в будущее». Однако мы смутно представляли себе её суть, поэтому решено было взяться за обе проблемы одновременно.

В то время как остальная часть группы работала над следующим (неосновным) выпуском продукта, ведущий разработчик уделял все своё время изучению внутренней организации СОМ и моделированию новых функций BoundsChecker. Спустя три месяца, когда новая версия была практически завершена, главный разработчик был готов присоединиться к работе над BoundsChecker 4.0. Ему удалось не только восстановить свои силы, но и обучить остальных участников группы принципам работы с СОМ и показать им рабочие прототипы новых функций. Так что для начала наше положение было весьма неплохим: вовсю шли поставки BoundsChecker 3.0, только что закончена разработка версии 3.1, а мы уже обладали фундаментальной технологией для следующего выпуска программы.

Оценка технологий

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

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

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

Оценивая технологию, нужно дать ответы на следующие вопросы.

• Возможности технологии: обладает ли новая технология возможностями, необходимыми для реализации проекта?

• Качество: приемлем ли уровень качества технологии?

• Совершенство: обеспечивает ли технология должную производительность, масштабируемость и устойчивость?

• Поддержка: обеспечена ли новая технология адекватной поддержкой?

• Простота использования: не слишком ли сложна новая технология в использовании и при отладке?

• Профессионализм команды: хватит ли у команды мастерства для применения этой технологии?

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

• формулировать критерии: определяйте свои потребности заранее и делайте это как можно точнее с помощью критериев, данных выше;

• использовать сформулированные критерии при оценке: объективно оценивайте результаты, опираясь на факты, а не на мнения;

• учитывать отзывы заказчиков: собирайте отзывы заказчиков (как положительные, так и отрицательные) о результатах оценки; не забывайте интересоваться мнением заказчиков: удовлетворят ли новые технологии их нужды.

Моделирование

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

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