Модель организационной структуры компании NuMega
Программы, как правило, создаются коллективами, а не одиночками. Команда разработчиков — это группа людей с различными техническими навыками, работающих над реализацией общего проекта. Поскольку разработать ПО довольно сложно, в команде требуются специалисты с самыми разными навыками и способностями, необходимыми для создания продукта. Вот какие специалисты должны быть в группе:
• основной состав группы — специалисты, полностью занятые в создании нового программного продукта:
— менеджеры проекта;
— программисты;
— тестировщики;
— разработчики документации;
— инженерные психологи;
— технологи по разработке ПО;
• вспомогательная группа — специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:
— группа менеджмента и маркетинга продукта;
— специалисты по технической поддержке ПО;
— администраторы бета-тестирования.
Очень важно, чтобы перечисленные функциональные подразделения участвовали в работе над проектом с самого начала. Чем раньше люди смогут понять суть требований к продукту и принять участие в их критическом анализе, тем лучше подготовятся к исполнению собственной миссии и ощутят свой вклад в успех проекта. Кроме того, чтобы завершить создание продукта в срок, все перечисленные подразделения должны работать параллельно на протяжении всего цикла разработки. Решение этой задачи будет описано в главе 11 — там мы рассмотрим включение в график проекта взаимно скоординированных во времени промежуточных этапов.
С другой стороны, если при подборе кадров какие-либо функциональные подразделения будут не (недо-) укомплектованы, то реализовать такие важные условия разработки ПО, как глубокое понимание задач, синергизм в работе и постепенный прогресс, будет невозможно. Я не настаиваю на том, чтобы все подразделения были полностью укомплектованы к первому дню работы над проектом, но по крайней мере их представители (хочется надеяться, что это будут ведущие специалисты) должны работать над проектом с самого начала. Нельзя недооценивать как важность этого требования, так и трудность его реализации.
Управление проектом
В качестве примера структуры оптимальной системы управления небольшой компании я подробно остановлюсь на организации управления в NuMega, позволившей ей справиться с трудностями. Как и любой молодой компании (и большинству начинающих групп разработчиков), нам требовалось выполнить большую работу в сжатые сроки, при этом ресурсы были сильно ограничены. Мы знали: чтобы воспользоваться всеми преимуществами талантливых сотрудников, которых нам удалось привлечь с таким трудом, необходимо их эффективно организовать. Нужна такая структура организации, которая позволила бы оперативно реагировать на возникающие трудности, сводить к минимуму разного рода издержки и которую можно было бы расширить в дальнейшем. Чтобы реализовать сформулированные требования, мы решили задействовать простую модель структуры организации, в которой за все аспекты разработки продукта отвечает один менеджер проекта. В сферу его ответственности входит наблюдение за всеми программистами, тестировщиками, технологами и разработчиками документации, т.е. за основным составом группы. Важнее всего, что все способные сотрудники были собраны под началом одного менеджера.
Остальные сотрудники (группа технической поддержки, администраторы бета-тестирования, группа менеджмента и маркетинга продукта) не отчитывались перед менеджером проекта, но работали с ним в прямом контакте для решения своих проблем и получения всего необходимого для работы. Этот подход дал неплохие результаты, так как приоритетной обязанностью каждого из вспомогательных подразделений было решение конкретной задачи (анализ рынка, формирование ценовой политики, обработка входящих сообщений, реклама и т.д.) и не предполагало повседневного участия в разработке продукта. Поскольку же все подчинялись одному менеджеру проекта, взаимодействие функциональных подразделений стало заметно проще и понятнее.
Хотя избранная нами структура организации работала хорошо, применение следующих принципов способствовало дальнейшему повышению её эффективности.
• Гибкое использование ресурсов
Менеджер проекта мог выделять нужные ресурсы и направлять группу специалистов для решения любой отдельной проблемы, устранения той или иной неполадки или поддержания какой-либо инициативы. Такая система позволила менеджеру проекта распределять ресурсы в соответствии с текущими внутренними приоритетами проекта и обеспечила полноту использования и оперативную балансировку ресурсов согласно быстро меняющимся потребностям проекта.
• Ответственность за распределение специализированных ресурсов
Все ресурсы находились в руках его менеджера, а команда в полном составе работала над проектом с первого и до последнего дня. Таким образом, была группа людей с единым набором приоритетов, работавших над решением единой задачи и под руководством одного человека. Такая структура позволяла привлечь каждого сотрудника к непосредственному участию в проекте уже на начальных этапах работы, в результате каждый в большей мере испытывал чувство ответственности и причастности к достигнутым результатам. Люди лучше представляли себе все особенности и ограничения проекта, а также причины тех или иных решений, что позволяло лучше спланировать проект и организовать тестирование, а также обеспечить проект более качественной документацией.
• Централизованное принятие решений
Поскольку проект целиком находится в ведении одного менеджера, он может оперативно принимать критически важные решения, разрубая «Гордиевы узлы», когда не удалось достичь согласия.
• Более чёткое взаимодействие
Каждый, у кого возникают вопросы или трудности, может обсудить их с менеджером проекта. Таким образом, простая и понятная схема взаимодействия участников позволяла эффективно устранять затруднения, возникающие у участников как основной, так и вспомогательной групп.
• Инициативная ответственность
Менеджер проекта — это не просто управляющий, но один из тех, кто заинтересован в успехе продукта. Он должен быть в курсе конъюнктуры и тенденций рынка, а также чётко представлять ценность функций программы. Без этих знаний он не сможет оперативно оценивать ход реализации ПО и обеспечить выполнение работы на должном уровне. Менеджер проекта работает в одной упряжке с менеджером продукта, формулирующим требования рынка и курирующим экономические аспекты создаваемого продукта. Оба вносят свой вклад во всех областях: в формирование политики лицензирования, ценообразование, продвижение и сбыт продукта. В конечном счёте они вместе отвечают за успех продукта и наделены полномочиями принимать ключевые решения. Обладая большой властью, они могут быстро принимать нужные решения. В то же время участники команды, зная, что они работают непосредственно с теми, кто принимает решения, в курсе их идей и уверены в том, что их работа не просто нужна, но имеет решающее значение для успеха проекта.
Из собственного опыта
Обычно в NuMega самое важное собрание, посвящённое проекту, — вводное. Всем участникам проекта, собравшимся в одной комнате, говорили, что продукт может быть создан только с участием каждого из них — все должны посвятить себя реализации проекта. Пока проект не будет отправлен заказчику, каждый должен выполнять свои обязанности. Если проект будет успешным и заказчик его одобрит, это будет результатом общих усилий команды, а если проект будет сорван — опять же в этом будут виноваты все. Методика, в рамках которой команда получала прямые полномочия, позволяющие ей принимать большинство решений, необходимых для работы, приносила восхитительные результаты.

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

Рис.3-1. Связи между менеджером проекта и ведущими специалистами функциональных подразделений.
Поскольку мы нанимали высококвалифицированных и опытных специалистов, они могли работать почти без надзора менеджера. Их нужно было лишь познакомить с обязанностями и планом. Важнее всего, что такая модель позволила держать ключевые ресурсы под контролем одного человека — менеджера, который непрерывно был в курсе повседневной работы группы.
Роли и обязанности
Рассмотрим основные роли и обязанности лидеров функциональных подразделений, участвующих в создании продукта.
Менеджер проекта
Совершенно ясно, что менеджер играет ключевую роль в реализации проекта. Его функционал включает следующие многочисленные роли и обязанности.
• Подбор кадров и управление ими
Менеджер проекта отвечает за создание команды и управление её составом. Он также курирует кадровое обеспечение, планирование карьеры, кадровую политику, анализ и проверку работы сотрудников и поддержание «боевого духа» группы. В его обязанность также входит найм новых сотрудников, повышение мастерства и развитие навыков специалистов, а также поддержание мотивации и целенаправленной деятельности людей во время работы над проектом.
• Формулирование и исполнение плана проекта
Формулированием и исполнением плана проекта руководит менеджер проекта. Он подбирает группу специалистов, формулирующих и согласовывающих требования, а также отслеживающих их выполнение. Когда список требований готов, менеджер составляет план, регламентирующий все действия, необходимые для реализации проекта: программирование, тестирование, разработку документации, работу технологов по разработке ПО и инженерных психологов. План также учитывает другие ключевые аспекты создания продукта, а именно: составление графика работы, реализацию технологии программирования, подбор кадров, а также неопределённости и риск. Это не значит, что все решения принимает только менеджер проекта, но именно он отвечает за то, чтобы довести создание всех частей продукта до конца во взаимодействии с ключевыми участниками проекта, и обязан донести общий план до каждого участника группы. Подробнее все эти вопросы мы рассмотрим во второй части книги.
При реализации функций ПО во время разработки постоянно приходится идти на компромисс. Именно менеджер проекта отвечает за то, чтобы соответствующие решения принимались своевременно и были согласованы с командой, которая должна быть в курсе принятых решений. Если корректировки приведут к коренным переменам в направленности продукта, он должен довести решение и все его последствия до сведения каждого, кого оно затрагивает.
Поскольку менеджер проекта не только отвечает за реализацию функций продукта, кадровое обеспечение и балансировку ресурсов проекта, но и курирует график реализации всего проекта, именно он отвечает за соблюдение графика работы над проектом и обязан вносить соответствующие коррективы в случае возникновения проблем.
Менеджер проекта создаёт главный график работ на основе сведений, поданных всеми участниками проекта. Как правило, в соответствии с этим графиком работа над проектом подразделяется на ряд промежуточных этапов и базовых уровней. Менеджер проекта должен непрерывно следить за исполнением графика, вносить нужные изменения и сообщать о них группам разработчиков и другим группам, в сотрудничестве с которыми ведётся работа (группы менеджмента, технической поддержки и администраторов бета-тестирования), а также верхнего эшелона управления. Подробнее мы поговорим о планировании в главе 11.
• Руководство командой
Менеджер проекта отвечает за плавное и эффективное исполнение разработки продукта. Менеджер проекта устраняет возникающие препятствия и обеспечивает всё необходимое для успешной работы команды. Он должен определять проблемные области, работать над ускорением решения проблем и поддерживать команду в состоянии сосредоточенности и гармонии. Он также должен быть готов выступить в роли инструктора или наставника, обладающего достаточными знаниями и опытом в разных областях, чтобы оценить успехи команды и при необходимости помочь ей.
• Обеспечение связи между подразделениями
Менеджер проекта — главное связующее звено между разработчиками и группой менеджмента и маркетинга. Он отвечает за сбор пожеланий в этих группах и воплощение их в плане проекта. Во время выполнения проекта он также отвечает за доведение возникших трудностей или изменений в плане проекта до сведения менеджера продукта и менеджера по маркетингу. Кроме того, проанализировав планы менеджмента и маркетинга, менеджер продукта должен дать свой отзыв о них.
Менеджер проекта также является главным каналом связи между группами разработчиков, технической поддержки и администраторов бета-тестирования. Он должен решать любые критические проблемы, возникающие как во время тестирования продукта клиентами (бета-тестирования), так и после выпуска;
• Обеспечение готовности продукта
Менеджер проекта также отвечает за создание максимально завершённого и качественного продукта. Таким образом, ответственность за достижение всех целей, поставленных перед программистами, разработчиками документации и инженерными психологами ложится в конечном счёте на плечи менеджера проекта.
Программисты
Можно выделить три основных категории технических специалистов: ведущий разработчик (программист), ведущий программист, отвечающий за реализацию определённой функции и рядовой программист (рис. 3-2).
Рис. 3-2. Связи между ведущим разработчиком, ведущими программистами, ответственными за реализацию определённых функций ПО, и рядовыми программистами.
Ведущий разработчик
Это главный специалист по разработке ПО. Эту должность, как правило, занимает один человек. Поскольку он играет ключевую роль в разработке ПО, занимающий эту должность специалист должен быть достаточно зрелым и квалифицированным, чтобы справиться со сложными техническими и кадровыми проблемами, постоянно возникающими во время цикла разработки. В число его обязанностей входит:
• наблюдение за соблюдением архитектурных и технических спецификаций продукта;
• подбор ключевых технологических инструментов и стандартов;
• диагностика и разрешение всех технических проблем;
• выполнение роли технического инструктора и консультанта для участников проекта;
• наблюдение и контроль за работой групп разработчиков документации, тестировщиков и технологов;
• мониторинг состояния (ведение списка обнаруженных ошибок);
• подбор инструментов разработки, метрик и стандартов и наблюдение за их использованием;
• ну и, конечно, программирование, программирование и ещё раз программирование.
Ведущие программисты, отвечающие за реализацию отдельных функций
Отвечают за реализацию отдельных функций продукта, часто на основе конкретной технологии. Обычно определение функций формулируют довольно широко, например, «интеграция с IDE» или «разработка API доступа к БД». Обязанностями ведущих программистов, отвечающих за создание отдельных функций ПО, являются:
• согласование архитектурных вопросов с коллегами, ответственными за разработку других функций;
• формулирование требований к функциям и их критический анализ;
• проектирование функций;
• снабжение тестировщиков и разработчиков документации техническими материалами;
• ну и, конечно, программирование, программирование и ещё раз программирование.
Рядовые программисты
Работают над реализацией определённой функции ПО обычно под руководством ведущего программиста, ответственного за эту функцию. Они отвечают за реализацию конкретных аспектов этой функции, например, за «интеграцию в IDE окон X, Y и Z» или «написание для API баз данных методов create, update и delete». В круг их обязанностей входит:
• реализация функции;
• её тестирование;
• исправление ошибок в реализованной функции;
• помощь техническим писателям в документировании реализованной функции;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30