Роли в разработке ИТ-продукта
Время на прочтение
11 мин
Количество просмотров 25K
Разработка ИТ-продукта – это длительный и трудоемкий процесс. В каждом проекте участвует большое количество специалистов. В небольших компаниях часто один менеджер отвечает сразу за несколько моментов, выполняя несколько ролей. В крупных корпорациях такое не приветствуется.
Эффективность команды во многом зависит от того, насколько хорошо налажена коммуникация внутри нее, соблюдаются ли дедлайны и насколько четко распределены роли. В каждом отдельном проекте это индивидуально, так как многое зависит от того, выполняется ли разработка на заказ или внутри компании и от многих других факторов.
Однако имеется некий стандартный список ролей, которые используются в каждом проекте. Рассмотрим их подробнее.
Стандартный список ролей
Аккаунт
Это «правая рука» заказчика. Именно аккаунт-менеджер является гарантом того, что фирма выполнит свои обязательства.
Задачи:
-
развитие партнерских отношений между фирмой-исполнителем и заказчиком продукта;
-
курирование команды, работающей над проектом;
-
оперативное решение нестандартных ситуаций и вопросов между клиентом и командой или внутри команды;
-
создание плана выполнения заказа;
-
анализ рисков и гарант дедлайнов;
-
документооборот по проекту.
hard skills |
soft skills |
Навыки работы с облачными хостингами (cloud computing) – AWS, GCP, Azure, DigitalOcean, RackSpace, программами документооборота и т. д. – для ведения документации и отчетности пригодится знание данных программ. |
Креативность – поможет в том случае, когда клиенту требуется необычный продукт. Также важное умение при подготовке презентации команды. |
UX-design – такой скилл будет полезен при контроле результатов, понимании того, насколько интерфейс удобен пользователю и была ли достигнута конечная цель. |
Умение убеждать – хороший навык при работе с заказчиком и выстраивании партнерских отношений. |
Принятие решений для решения проблем (decision-making) пригодится при работе в команде. |
Умение работать в команде – важное качество, которое пригодится для выстраивания коммуникации с командой и внутри нее. |
Управление командами (leadership) для контроля за дедлайнами разных этапов разработки. |
Адаптируемость – разные проекты требуют разного подхода. |
Тайм-менеджмент – помогает распределить задачи по их значимости и уложиться в дедлайн. |
Продакт
Менеджер продукта в команде. Он отвечает за продукт, поэтому может быть не особо осведомлен в том, как развивается проект и на каком он сейчас этапе. Зато о конечном продукте он должен знать все.
В его задачи входит:
-
продумывание стратегии развития продукта;
-
определение ЦА продукта, понимание ее болей;
-
анализ рынка и стратегия продвижения продукта;
-
знание особенностей продукта, его плюсов и особенностей;
-
презентация продукта.
hard skills |
soft skills |
Нетворкинг помогает в продвижении продукта на рынке. |
Эмпатия – понимание болей клиента, что помогает закрыть их с помощью продукта. |
Анализ и цифры пригодится при обдумывании стратегии развития продукта и анализировании рынка, конкурентов, метрики и ЦА. |
Умение давать и получать фидбек – важный навык при работе с ЦА и командой. Обратная связь помогает понять необходимость улучшения продукта. |
Выбор модели монетизации позволяет провести монетизацию наиболее эффективно и с максимальной отдачей. |
Коммуникативные навыки помогают при подготовке и проведении презентации продукта. |
Постановка OKR. |
Умение продавать идеи. |
Проджект-менеджер
Иными словами, менеджер проекта. Он дублирует в отдельных функциях аккаунт-менеджера, тоже следит за соблюдением дедлайнов и требований по проекту, ведет документацию. Но если аккаунт-менеджер работает напрямую с заказчиком и представляет его сторону, то проджект-менеджер – это представитель со стороны команды разработчиков и работает именно от ее лица.
В его задачи входит:
-
бюджет проекта;
-
сбор требований по проекту и постановка целей по итогам анализа этих требований;
-
делегирование задач;
-
контроль за дедлайнами;
-
общение с заказчиком по конкретным техническим задачам и нюансам ТЗ;
-
распределение зон ответственности между ключевыми специалистами проекта;
-
сбор и контроль метрических данных проекта.
hard skills |
soft skills |
Навыки работы с облачными хостингами (cloud computing) – AWS, GCP, Azure, DigitalOcean, RackSpace, программами документооборота и т. д. Нужны для ведения документации и отчетности. |
Тайм-менеджмент – помогает распределить задачи по их значимости и уложиться в дедлайн. |
Scrum и подобные методики. |
Лидерство – полезно при управлении командой. |
Управление командами (leadership) необходимо для контроля за дедлайнами разных этапов разработки. |
Стрессоустойчивость пригодится при решении спорных моментов и налаживании коммуникации. |
Ведение переговоров важно для обсуждения бюджета, сроков и выявления нюансов в техническом задании при общении с заказчиком. |
Управление рисками – при изменении в проекте поможет не потерять контроль над изменившейся ситуацией. |
Ведение багтрекера – для анализа результатов и эффективности разработок. |
Эмпатия – для комфортного выстраивания диалога с заказчиком, например, для понимания, можно ли убедить клиента в необходимости расширить бюджет или нет. |
Сейл
Проще говоря, это менеджер по продажам. Его основные задачи:
-
найти клиента;
-
произвести на него хорошее впечатление, убедить, что продукт или решение – именно то, что ему в данный момент необходимо и закроет его боли на все 100%;
-
продать, то есть подписать контракт на поставку товаров и/или услуг.
В идеале сейл-менеджер – специалист, который умеет убеждать клиента, что продаваемый им товар самый нужный. К сожалению, анализ того, насколько выгоден контракт клиенту, не является задачей сейла.
hard skills |
soft skills |
Знание техник переговоров поможет продавать эффективно и избежать маркетинговых ловушек. |
Дисциплина и самоорганизация важны для сейла, ведь он постоянно в поисках клиентов, и важно ничего не упустить. |
Работа в CRM-системе – важный навык для оформления продаж. |
Коммуникабельность – умение общаться, убеждать, производить хорошее впечатление. |
Владение техниками продаж поможет продать, заключить контракт. Знание техники прогревов или работа с возражениями. |
Стрессоустойчивость – важный скилл, особенно, когда приходится сталкиваться с отказами. |
Нетворкинг – чем больше связей и знакомств, тем эффективнее продажи. |
Эмпатия – умение чувствовать настроение клиента помогает сейлу продавать эффективнее. |
Архитектор (Architect)
Именно этот специалист принимает на проекте решения о том, каким будет внутреннее строение программной системы и ее интерфейсов. Среди других задач архитектора в ИТ-проекте можно выделить:
-
составление конструкции программного обеспечения (ПО), элементов и их взаимосвязи;
-
знание мировых практик разработки ПО и построение системы в зависимости от задач бизнеса, для которого она разрабатывается;
-
проектирование архитектуры ПО;
-
выполнение требований заказчика к системе: быстрое восстановление, быстрая работа, возможность дальнейшего развития.
hard skills |
soft skills |
Навыки работы с алгоритмами искусственного интеллекта (AI&ML) для понимания этапов разработки и информирования заказчика. |
Умение работать в команде для выстраивания коммуникации. |
Знание мировых практик разработки ПО для решения бизнес-задач. |
Эмпатия – для понимания болей бизнеса и построения системы так, чтобы она максимально подходила для их закрытия. |
Технические навыки – знание языка программирования и многие другие. |
Бизнес Аналитик (Business Analyst)
Этот специалист нужен на любом проекте по разработке ИТ-продукта, ведь именно он составляет, так называемый, Vision, или конечную концепцию продукта, который и предстоит разрабатывать команде. Он должен хорошо представлять себе конечный вид и функционирование системы.
Задачи бизнес-аналитика на проекте:
-
общение с заказчиком и выявление его желаний;
-
выявление целей, для которых разрабатывается продукт, какие задачи он должен решать;
-
предложение собственных идей по улучшению конечного продукта;
-
формирование совместно с заказчиком документации по проекту, в которой подробно описывается, какой именно продукт разрабатывается, каковы его цели и задачи, для какой ЦА предназначен и основные возможности будущей системы.
hard skills |
soft skills |
Знание основ экономики бизнеса поможет при создании концепции продукта сделать его максимально полезным для бизнеса. |
Творчество, интуиция, опыт – навык хорош для улучшения разрабатываемого продукта. В процессе разработки концепции будет нелишним использовать творческий подход при решении отдельных бизнес-задач. |
Основы финансового анализа важны для закрытия связанных с этим задач при разработке продукта для бизнеса. |
Коммуникативные навыки помогут при выявлении потребностей заказчика. |
Знание принципов интеграции систем и владение инструментарием бизнес-аналитика пригодятся при интеграции нового продукта в уже работающую систему компании-заказчика. |
Умение ставить задачи программистам и оценивать сами задачи – навык помогает при общении с командой разработчиков и донесении до них пожеланий заказчика и бизнес-целей, под которые разрабатывается продукт. |
Системный аналитик (System Analyst)
Как правило, этот специалист работает в паре с бизнес-аналитиком, но в отличие от него обращает внимание не на то, как должна выглядеть и какие задачи решать система. Главное, что волнует системного аналитика – это то, как система должна работать в различных вариантах использования и какие у нее функции. Именно это детально описывает системный аналитик проекта.
Задачи системного аналитика включают в себя:
-
анализ данных и метрик;
-
принятие решений о том, какие именно методы использовать;
-
составление технического задания (ТЗ);
-
разработка и написание спецификации;
-
составление списка требований к системе;
-
функциональный анализ системы.
hard skills |
soft skills |
Анализ и цифры – поможет при анализировании метрик и результатов работы системы. С помощью этого выполняется функциональный анализ системы. |
Понимание целей оптимизации продукта поможет быстрее сориентироваться в том, какие именно функции системы нужно доработать. |
Технические навыки – необходимы при составлении ТЗ и написании спецификации к системе. |
Тайм-менеджмент – важный навык для соблюдения дедлайнов. |
Владение навыками конфигурирования – помощь при составлении требований к системе и выполнении функционального анализа. |
Коммуникативные навыки нужны для выстраивания взаимодействия с командой. |
Технический писатель (Technical writer)
Без этого специалиста невозможен ни один проект, так как чаще всего именно технический писатель рассказывает о продукте и ведет его в массы.
Основными задачами такого специалиста становятся:
-
написание инструкции по эксплуатации системы;
-
составление документации для сотрудников фирмы-заказчика, обеспечивающих поддержку программы в дальнейшем.
hard skills |
soft skills |
Навыки работы с профессиональными программами, например, Adobe FrameMaker, MS Word, MadCap Flare, RoboHelp и даже PageMaker и Quark. Зависят от того, какие именно использует компания для производства технической документации. |
Умение убеждать – без этого статья получится сухой и неинтересной, а значит, и о продукте узнает намного меньше людей. |
Технические навыки пригодятся для более достоверного и профессионального описания продукта. |
Коммуникативные навыки помогут при получении фидбека. |
UX-design будет полезен при контроле результатов, понимании того, насколько интерфейс удобен пользователю и проверке продукта. |
Эмпатия помогает почувствовать «боли» ЦА, написать о них наиболее естественно и убедительно показать, как продукт помогает в их решении. |
Писательские навыки – владение информационным стилем и знание сервисов проверки текста. |
Тайм-менеджмент – важный навык для соблюдения дедлайнов. |
Проектировщик
Этот специалист нужен в проекте для построения макетов разрабатываемой системы. При этом он обязательно должен учитывать удобство ее использования клиентом.
Основные задачи проектировщика:
-
создание панелей инструментов, меню и кнопок, которые были описаны в ТЗ;
-
создание макета расположения графических элементов;
-
демонстрирует команде/заказчику черновик продукта, например, как будут осуществляться переходы между элементами и страницами (экранами) продукта.
hard skills |
soft skills |
Технические навыки – знание языков программирования, элементов системы и методов их визуализации. |
Коммуникативные навыки необходимы для установления диалога внутри команды и с заказчиком. |
Навыки работы с алгоритмами искусственного интеллекта (AI&ML) нужны для понимания этапов разработки и информирования заказчика. |
Тайм-менеджмент – помогает распределить задачи по их значимости и уложиться в дедлайн. |
Понимание целей оптимизации продукта поможет быстрее сориентироваться в том, какие именно функции системы нужно доработать. |
Дизайнер (Designer)
Этот специалист отвечает за оформление и внешний вид продукта. Именно он «рисует» все элементы продукта, которые видит заказчик в конечном варианте, подбирает цвета и формы.
Задачи дизайнера выглядят так:
-
определение формы и цвета каждого элемента продукта, чтобы вместе они составляли единую картину;
-
прорисовка графических элементов;
-
отрисовка баннеров и логотипов для продукта;
-
конечное оформление продукта.
hard skills |
soft skills |
Владение профессиональными программами, например, Adobe Photoshop, Adobe Illustrator, GIMP, Figma, Adobe InDesign, CorelDraw, FontLab, Sketch и т. д. |
Насмотренность пригодится для создания современного и стильного продукта, отвечающего всем требованиям времени. |
Знание основ дизайна – важно понимать, что такое композиция, цвет, типографика, иметь базовое понимание шрифтов. |
Тайм-менеджмент – благодаря ему все работы будут завершены в срок и команда избежит срыва дедлайнов. |
Визуальные коммуникации – базовое понимание анимации и 3D-моделинга, а также умение создавать шаблоны. |
Вкус и стиль – важные черты дизайнера для создания красивого продукта. |
Верстальщик (Web developer / Front end developer)
Именно благодаря верстальщику «оживают» макеты, созданные проектировщиками и дизайнерами. Эти специалисты создают верстку страниц так, чтобы они правильно отображались с мобильного телефона и с ПК.
Задачи верстальщика:
-
постановка правил, как браузер должен отобразить тот или иной элемент на web-странице;
-
создание эффектов переходов и кликабельности;
-
выравнивание текста.
hard skills |
soft skills |
Технические навыки – знание специального языка разметки HTML и CSS. Знание Bootstrap и других фреймворков полезно в процессе разработки. |
Эмпатия – понимание того, что хочет видеть клиент. |
Знание основ дизайна. |
Коммуникативные навыки. |
Знание специальных инструментов, например, сборщиков или инструментов-помощников. Git помогает хранить проекты и управлять ими. Docker поможет упаковать проект со всеми окружениями и зависимостями. Командная строка важна для автоматизации и т. д. |
Тайм-менеджмент. |
Разработчик / Программист (Developer) (backend & frontend)
Этот специалист в команде занимается реализацией требований, которые ранее были прописаны аналитиками.
Задачи разработчика включают в себя:
-
воплощение в жизнь функций, которые должна иметь система;
-
создание логики, которая отвечает за то, чтобы все функции системы выполнялись именно так, как это и было задумано изначально.
hard skills |
soft skills |
Технические навыки – знание языков программирования, фреймворков, работа с искусственным интеллектом. Знание IDE и средств коллективной разработки (Git и/или других). |
Умение работать в команде. |
Анализ данных пригодится для поиска ошибок системы и их исправления, для создания логической цепочки действий системы. |
Нацеленность на результат. |
Тестировщик (Testing Engineer)
Именно он первым получает возможность запустить продукт и пользоваться им. Его основные задачи:
-
выявление ошибок и недочетов в работе системы;
-
давать фидбек по продукту.
hard skills |
soft skills |
Технические навыки – выявление ошибок, багов и дефектов системы. |
Работа в команде. |
Навык работы с документацией – поможет при составлении отчетности по продукту. |
Ответственность и самодисциплина. |
Локализатор
Этот специалист часто участвует исключительно в международных проектах, то есть работает только с теми продуктами, которые будут распространяться не только в стране разработки, но и за рубежом.
В задачи локализатора входит:
-
перевод всех слов и команд на другой язык, где планируется распространение и продажа продукта;
-
контроль за внешним видом переведенного продукта.
hard skills |
soft skills |
Технические навыки – знание языка, на который будет совершаться перевод. |
Ответственность и исполнительность. |
Знание основ дизайна поможет подобрать размер и тип шрифта для языка перевода, согласовать длину слов и терминов. |
Работа в команде. |
Тимлид
Это управленец с техническими навыками. Такой специалист, как правило, требуется, если проект масштабный и техническое управление просто необходимо.
Задачи тимлида, обычно включают в себя:
-
Набор сотрудников в команду, подбор необходимых для выполнения поставленной задачи специалистов. Важно, чтобы в команде была сплоченность и высокий уровень корпоративной культуры.
-
Принятие решений по вопросам стратегии разработки.
-
Делегирование задач между специалистами. Контроль за дедлайнами.
-
Выстраивание коммуникации с другими отделами, а не только внутри команды. Именно тимлид общается с тестировщиками, дизайнерами и прочими специалистами, решая вопросы, не прибегая к помощи заказчика.
В крупных проектах всегда работает два тимлида, со стороны заказчика и со стороны исполнителя.
hard skills |
soft skills |
Работа с оборудованием – знание оргтехники и умение с ней работать. |
Работа с людьми – умение договориться, презентовать свою команду. |
Технические навыки – знание программ, языков программирования. |
Управление отношениями – умение улаживать конфликты, поиск компромиссных решений. |
Умение анализировать данные. |
Коммуникативные навыки. |
Управление процессами – делегирование задач сотрудникам, контроль дедлайнов. |
В разработке продукта принимают участие большое количество человек, при этом у каждого из них свои задачи. Чтобы добиться эффективного взаимодействия между ними, важно правильно подобрать команду и ведущих специалистов, имеющих определенные hard и soft навыки. Только в таком случае можно добиться качественного и эффективного взаимодействия, продуктивной коммуникации внутри команды.
Важно обращать внимание на масштабы проекта, готовится ли он для распространения на зарубежном рынке.
Успех любого проекта по разработке программного обеспечения заключается в тщательном планировании, квалифицированной команде разработчиков и четкой коммуникации между членами команды проекта, как внутри компании, так и за ее пределами — с заказчиком или владельцем продукта.
Легко запутаться среди ролей и обязанностей в жизненном цикле разработки программного обеспечения, особенно если вы запускаете свой первый ИТ-проект. В этой статье мы начнем с основ и объясним различные роли в команде разработчиков, чтобы помочь вам лучше понять, почему вам нужно нанимать определенных специалистов и что они делают на проекте.
Ключевые роли в команде по разработке программного обеспечения
Бизнес-аналитик
Бизнес-аналитик участвует в проекте с самого начала, сразу после подписания контракта, а иногда и раньше. Основной обязанностью бизнес-аналитика является общение как с клиентом, так и с командой разработчиков.
Клиенты обычно в первую очередь думают о своих целях. Разработчики же думают о коде и функциях, сосредотачиваясь на том, как сделать то, что хочет заказчик, и решить его проблемы. Однако между целями клиента и возможностями программного обеспечения существует огромный разрыв. Именно поэтому бизнес-аналитик должен точно определить, что нужно клиенту.
Сначала бизнес-аналитик собирает требования клиента, анализирует, какие функции должны быть реализованы, и определяет, как это должно быть сделано. Далее он проводит конкурентные исследования, чтобы обеспечить устойчивость программного обеспечения на рынке и его конкурентоспособность по сравнению с существующими продуктами.
Также бизнес-аналитик определяет целевую аудиторию продукта, создает вайрфреймы и пишет техническое задание, если оно не полностью предоставлено клиентом. Таким образом, роль бизнес-аналитика заключается в планировании оптимального цикла разработки программного обеспечения в соответствии с требованиями клиента, подготовке документации и установлении эффективной коммуникации между клиентом и командой разработчиков.
Менеджер проекта
После того как бизнес-аналитик определил требования заказчика, к проекту подключается менеджер проекта. Его основная роль заключается в управлении проектом. Менеджер проекта следит за тем, чтобы у команды разработчиков было все необходимое для выполнения работы, а также устраняет любые препятствия и управляет всеми встречами и коммуникациями.
Чтобы лучше объяснить роль менеджера проекта, давайте рассмотрим его основные задачи. Как и бизнес-аналитик, менеджер проекта также может быть вовлечен в общение с клиентом, но все-таки его основная обязанность — непосредственное сотрудничество с командой разработчиков программного обеспечения.
Менеджер проекта распределяет задачи между участниками команды разработчиков, отслеживает прогресс, мотивирует команду, контролирует процесс разработки и координирует деятельность команды. Кроме того, менеджер проекта отвечает за управление временем, рисками и непредвиденными обстоятельствами, а также следит за тем, чтобы разработчики не отклонялись от плана. В гибких методологиях это также означает, что команда разработчиков внедряет изменения быстро, правильно и без ненужной работы, так что заказчик может легко утвердить их.
Дизайнер UI/UX
Это, наверное, самый креативный человек в команде разработчиков. Основная задача дизайнера UI/UX заключается в создании визуально интересного интерфейса и обеспечении отличного пользовательского опыта.
Дизайнер использует вайрфреймы — детальные черно-белые планы страниц сайта, созданные клиентом или бизнес-аналитиком, чтобы разработать макеты и спроектировать пользовательский интерфейс программного обеспечения, соответствующий рекомендациям и последним тенденциям. Дизайнер также создает прототип, который отражает поведение и внешний вид будущего продукта и позволяет протестировать его на реальном устройстве перед началом цикла разработки. После того как заказчик одобрит дизайн будущего программного обеспечения, разработчики приступают к написанию кода.
Разработчик
Разработчик — это сердце команды. Разработчики подобны переводчикам, переводящим человеческий язык и язык графики на язык цифровых технологий, понятный компьютерам и устройствам.
В команде разработчиков программного обеспечения существует несколько уровней, включая младших, средних и старших сотрудников каждый из которых вносит в проект свою толику опыта и знаний.
Кроме того, разработчики имеют различную специализацию, поэтому каждый из них использует определенные языки программирования и работает с определенными фреймворками и инструментами. В результате команды разработчиков часто состоят из нескольких человек, работающих с различными технологиями и инструментами. Например, основная команда разработчиков мобильных приложений состоит из разработчиков Android, iOS и бэкенда.
Технический лидер
Название этой должности может ввести в заблуждение, поскольку оно подразумевает, что этот человек должен быть «лучшим» разработчиком в команде. Это не обязательно так. Технический лидер — это человек, который общается с менеджером проекта и бизнес-аналитиком так, чтобы им не приходилось отвлекать от работы других разработчиков. Другими словами, технический лидер освобождает других разработчиков от необходимости отвечать на вопросы менеджера проекта и бизнес-аналитика. Две другие обязанности технического лидера — быть осведомленным о функциях, разрабатываемых в спринте, и посещать соответствующие встречи, включая демонстрации функций.
Тестировщик
Тестировщики, или специалисты по обеспечению качества, необходимы на каждом цикле разработки программ для гарантии высокого качества продукта. Они тестируют и проходят через все программное обеспечение, чтобы выявить ошибки, а затем предоставляют отчет команде разработчиков для исправления ошибок.
Некоторые клиенты сомневаются в роли специалиста по обеспечению качества. Однако если тестирование программного обеспечения проводится некачественно или вообще не проводится, это может повлиять на весь продукт. Чтобы обеспечить положительный пользовательский опыт, необходимо выявлять ошибки до того, как продукт попадет к пользователям. Другие обязанности специалиста по обеспечению качества включают общее тестирование программного обеспечения и его проверку на соответствие заявленным требованиям.
Специалист по контролю качества
Как клиент, вы должны ожидать, что ваш поставщик программного обеспечения проведет широкий спектр тестов продукта, чтобы убедиться, что он соответствует различным стандартам качества. Поэтому специалисты по контролю качества должны провести заключительные тесты, чтобы убедиться, что программное обеспечение хорошо работает в различных реальных сценариях.
Приемочное пользовательское тестирование — это заключительный шаг перед выпуском программного обеспечения. Компания-разработчик, с которой вы сотрудничаете, должна располагать ресурсами для своевременного и скоординированного проведения приемочного тестирования пользователей, поскольку данное тестирование часто является узким местом между завершением и выпуском программного решения.
Правильная структура команды разработчиков может обеспечить успех вашего проекта
Существуют десятки факторов, которые способствуют успеху проекта: сама бизнес-идея, пользовательский опыт и внешний вид вашего программного обеспечения, качество и безопасность вашей системы и многое другое. Структура команды — один из самых важных факторов. Как вы можете видеть, разнообразие ролей в команде разработчиков программного обеспечения гораздо сложнее, чем «просто разработчики». В оптимальной организационной структуре разработчики специализируются на различных языках программирования и фреймворках, специалисты по контролю качества в области безопасности и тестирования производительности и т.д. Самое приятное то, что вам не нужно нанимать всех этих специалистов на полный рабочий день. Хорошая компания по разработке программного обеспечения проанализирует ваши потребности и определит правильную структуру команды, соответствующую вашим целям и бюджету.
Вы готовы нанять команду разработчиков для своего проекта? Или, может быть, у вас есть вопросы об услугах по разработке программного обеспечения, прежде чем принять окончательное решение? Не стесняйтесь обращаться к нам! Наши специалисты дадут вам бесплатную консультацию и ответят на ваши вопросы.
Каждый член команды играет решающую роль
Разработка программного обеспечения — это совместный процесс, в котором участвуют различные специалисты, работающие вместе над созданием, развертыванием и обслуживанием программных приложений. Каждый член команды играет решающую роль в обеспечении успеха проекта разработки. В этой статье мы рассмотрим роли и обязанности различных членов команды разработчиков программного обеспечения, включая разработчиков программного обеспечения, бизнес-аналитиков, специалистов DevOps, руководителей отдела маркетинга, а также различные роли в компании-разработчике программного обеспечения.
Ключевые члены команды по разработке программного обеспечения: роли и обязанности
Разработчик программного обеспечения: Разработчик программного обеспечения — это квалифицированный специалист, отвечающий за проектирование, кодирование, тестирование и поддержку программных приложений. Они обладают опытом работы с языками программирования, средами разработки программного обеспечения и инструментами. Их основная роль заключается в преобразовании требований к программному обеспечению в функциональный код и сотрудничестве с другими членами команды для обеспечения успешного внедрения программных решений. Разработчики программного обеспечения часто специализируются на определенных языках программирования или областях разработки.
Роль бизнес-аналитика (BA) в разработке программного обеспечения: бизнес-аналитик действует как связующее звено между командой разработчиков программного обеспечения и клиентом или заинтересованными сторонами. Их основная цель — понять требования клиента, проанализировать бизнес-процессы и преобразовать их в действенные спецификации программного обеспечения. BA способствуют эффективному общению, собирают и документируют требования, проводят технико-экономические обоснования, создают функциональные спецификации и помогают в планировании проекта и определении приоритетов. Они устраняют разрыв между техническими и нетехническими заинтересованными сторонами, гарантируя, что программное обеспечение соответствует предполагаемым потребностям бизнеса.
DevOps в разработке программного обеспечения: DevOps, аббревиатура от Development and Operations, представляет собой совместный подход, сочетающий разработку программного обеспечения (Dev) и ИТ-эксплуатацию (Ops). Специалисты DevOps сосредоточены на оптимизации процессов разработки, развертывания и обслуживания для улучшения совместной работы, производительности и общего качества программного обеспечения. Они автоматизируют конвейеры доставки программного обеспечения, управляют инфраструктурой, отслеживают производительность системы и обеспечивают непрерывную интеграцию и развертывание. Специалисты DevOps стремятся развивать культуру сотрудничества и гибкости в команде разработчиков программного обеспечения.
Тестировщики и инженеры обеспечения качества (QA): сосредоточьтесь на тестировании программных приложений для выявления ошибок, проблем с удобством использования и обеспечения соответствия спецификациям. Они играют жизненно важную роль в поддержании качества программного обеспечения.
Дизайнеры UX/UI: отвечают за создание визуально привлекательных и удобных интерфейсов, обеспечивающих оптимальное взаимодействие с пользователем в программных приложениях.
Руководители проектов: отвечают за планирование, организацию и надзор за проектами разработки программного обеспечения. Они управляют ресурсами, сроками и бюджетами, чтобы обеспечить завершение проекта в рамках определенного объема.
Различные роли в софтверной компании
Помимо разработчиков программного обеспечения, бизнес-аналитиков и менеджеров по маркетингу, компании-разработчики программного обеспечения выполняют множество других ролей, которые способствуют общему успеху проектов.
Некоторые общие роли включают в себя:
- Технические писатели: создают документацию, руководства пользователя и руководства, чтобы помочь конечным пользователям понять и эффективно использовать программное обеспечение.
- Инженеры службы поддержки: предоставляют техническую помощь и устраняют неполадки для клиентов после развертывания программного обеспечения. Они решают вопросы, связанные с программным обеспечением, и обеспечивают удовлетворенность клиентов.
Отделы в компании-разработчике программного обеспечения.
Компания-разработчик программного обеспечения обычно состоит из разных отделов, которые управляют различными аспектами разработки программного обеспечения и бизнес-операций. Эти отделы могут включать:
- Управление продуктом: отвечает за определение дорожной карты продукта, сбор информации о рынке и определение приоритетов разработки функций на основе потребностей клиентов.
- Продажи и развитие бизнеса: занимается выявлением потенциальных клиентов, заключением сделок и стимулированием продаж для получения дохода.
- HR или отдел кадров: Управляет наймом, адаптацией сотрудников, обучением и инициативами организационного развития в компании-разработчике программного обеспечения.
- Финансы и бухгалтерский учет: занимается финансовыми аспектами, такими как составление бюджета, финансовая отчетность и управление дебиторской и кредиторской задолженностью.
- Служба поддержки клиентов: оказывает помощь клиентам, отвечает на запросы и решает проблемы, связанные с использованием программного обеспечения.
- Менеджер по маркетингу: руководители по маркетингу играют решающую роль в компаниях-разработчиках программного обеспечения, продвигая продукты, привлекая потенциальных клиентов и обеспечивая удовлетворенность клиентов. Они разрабатывают маркетинговые стратегии, проводят исследования рынка и определяют целевую аудиторию. Руководители отдела маркетинга сотрудничают с командой разработчиков программного обеспечения, чтобы понять особенности и преимущества продукта, создать привлекательные маркетинговые кампании и эффективно донести ценностное предложение до клиентов. Они также собирают отзывы клиентов и вносят свой вклад в инициативы по улучшению продукта.
Успешная разработка программного обеспечения полагается на коллективные усилия различных членов команды, которые делятся своим опытом и уникальными взглядами. От разработчиков программного обеспечения и бизнес-аналитиков до профессионалов DevOps и руководителей отдела маркетинга — каждая роль играет решающую роль в создании высококачественных программных продуктов. Понимание обязанностей и вклада этих членов команды помогает обеспечить эффективное сотрудничество и успех проекта внутри команды разработчиков программного обеспечения и компании в целом.
У вас есть 5 рублей. Соберите команду разработки:
Окей, мы пытались пошутить🥲
Теперь серьезно. Состав команды разработки меняется от проекта к проекту, но если вы — владелец стартапа, советуем найти полноценную тиму. Лучше сразу отдайте проект подрядчикам, потому что опытные команды на аутсорсе обычно сработанные и стабильные. А чем лучше команда, тем меньше переживаний. В новой статье узнаем, кто есть в кто в крутой команде!
Основной состав команды разработки обычно такой:
- менеджер проектов
- бэкенд-разработчик
- фронтенд разработчик
- UI/UX дизайнер
- тестировщик
Опытные разработчики становятся тимлидами, с них мы и начнем рассматривать всех членов команды подробнее.
Тимлиды
Самые крутые ребята на районе. Тимлидами становятся только опытные и скилловые разработчики, которые умеют и в бэк, и в фронт. В их задачи входит разбираться с самыми сложными частями проекта, помогать команде и управлять процессом разработки. Поэтому хороший тимлид — это не только разработчик, но и менеджер.
Найти тимлида — задача непростая. Специалисты такого уровня редко «обитают» на фрилансе, а на сервисах поиска работы их вообще днем с огнем не сыщешь. Согласно опросу Stack Overflow, 76,7% тимлидов работают полный рабочий день в компаниях разработки, и только 6,7% — фрилансеры. Такая статистика объясняется просто: тимлидами не рождаются, тимлидами становятся.
Есть три способа получить тимлида в команду: нанять, назначить и вырастить. Давайте разбираться, какой из них самый выгодный для стартапа
Нанять
Тимлида трудно найти, легко потерять и невозможно забыть, поэтому для найма такого сотрудника потребуются все силы эйчарства и небывалая удача. Скорее всего, такой способ не подойдет стартапу, который ищет команду разработки — слишком долго и дорого. На карте — средние зарплаты тимлидов в разных регионах.
Средняя зарплата тимлидов по регионам мира
Назначить
Поздравляю, вы тимлид. Не ожидали? Также и некоторые программисты не рассчитывают на быстрое повышение, но все равно его получают. Это связано с тем, что в компании не хватает или вообще нет хороших руководителей команд, и их приходится выбирать среди хороших разработчиков. Беднягу бросают на проект, а дальше будь что будет. Мы в Purrweb думаем, что это не самый эффективный подход.
Вырастить
Берете в штат джуна + растите его компетенции + расширяете зоны ответственности + назначаете сильного наставника = получаете крутого тимлида. Идеальная формула по версии Purrweb 💪 Внутри компании мы выращиваем тимлидов из джунов за пару лет — на меньшее не согласны. Недавно в штате руководителей команд прибыло — несколько разработчиков стали джуниор-тимлидами.
Три года назад я пришел в Purrweb джуном, а недавно мне доверили вести первый проект. Думаю, на этой должности нужно быть ответственным и коммуникабельным, а также постоянно развиваться и проецировать это на команду. Для меня, как для тимлида, важно, чтобы ребята не закрывались в себе и не застревали надолго в сложных задачах. Все недопонимания я решаю на дейли, а «глобальные» процессы налаживаю на ретро.
Максим Орлов,
младший тимлид в Purrweb
Проектные менеджеры
Организуют процесс работы и держат связь с клиентом. Главная цель проектного менеджера — вместе с командой разработки реализовать идею заказчика в срок. PM ставит задачи, следит за их выполнением, проводит регулярные встречи с командой: дейли, викли, планирование, ретро. На заметку:
Вопреки общему мнению, проектный менеджер в IT не должен разбираться в разработке на уровне программистов или дизайнеров. Вести проект может и человек без технического бэкграунда, если софт и хард скиллы подходят для этой должности.
Софт скиллы 💭 | Хард скиллы 💪 |
Эмпатия
Проектный менеджер — это почти психолог для команды. Он должен решать не только проблемы с процессом работы, но и мелкие внутренние конфликты. |
Английский язык
Клиенты из других стран не должны сидеть на созвонах с Google Translate. Беглый разговорный английский поможет наладить коммуникацию. |
Коммуникабельность
Найти подход к каждому тиммейту, наладить связь между людьми и поддерживать ее до конца проекта — все это обязанности PM. |
Переговоры
О, дипломатия! На каждой встрече — с командой ли, или с клиентом — придется много и аргументированно доказывать нужную точку зрения. Человек без специальной подготовки точно не справится. |
Стрессоустойчивость
Созвон с заказчиком из США в 12 ночи по местному времени? Внезапные изменения в задачах? Трехчасовая встреча с командой ранним утром? Да, это реальность проектного менеджера. |
Инструменты ведения проектов
Trello, Jira, ClickUp — это не новые герои вселенной Marvel, а реальные программы, которые помогают проектному менеджеру вести задачи. Без них как без рук. |
Гибкость
Иногда придется показать клиенту компетентность, а порой — согласиться с ним и переделать / убрать что-то в проекте. PM должен адекватно относиться и к той, и к другой ситуации. |
Немного в IT
Еще раз: хорошими проектными менеджерами могут стать и бывшие разработчики или люди с техническим бэкграундом. Хорошо, если PM шарит. Но если не шарит — схватит все на лету. |
Заинтересованность
Даже если в IT-компании от менеджеров не требуют глубоких профессиональных знаний, это не отменяет общий интерес к разработке. |
Для меня в работе проектным менеджером главное — это общение с командой. Работа с нашими ребятами заряжает и дает силы. Нравится наблюдать за их успехами — в такие моменты я понимаю, что без них ничего бы не было.
Александра Румянцева,
проектный менеджер в Purrweb
Фронтенд разработчики
Фронтенд разработчики проектируют и реализуют интерфейсы. Эти ребята делают все, чтобы пользователю было удобно взаимодействовать со страницей. Все, что вы видите на этом сайте — работа фронтенд разработчика или верстальщика. Смотря, кто из нашей команды делал эту задачку. 😉 Давайте разбираться, кто есть кто.
Верстальщик — боец «малого» фронта. В его задачи входит сверстать макет дизайнера с помощью HTML и CSS. Верстальщики знают основы JavaScript, но это не главная технология для их работы.
Верстальщик может стать фронтендером, если расширит базу знаний. Тогда он уже не просто верстает макеты — такой специалист знает язык программирования JavaScript и надстройку TypeScript, разбирается во фреймворках и библиотеках и активно их использует на проектах, понимает серверную часть разработки. Его не пугают препроцессоры и сборщики LESS, SASS, GRUNT, GULP, он умеет работать с DOM, API, SVG-объектами, AJAX и CORS, может составлять SQL-запросы и копаться в данных. Если к этим навыкам добавить понимание UI/UX процессов, адаптивной верстки, кроссбраузерности и кроссплатформенности, а также мобильную разработку — получаем сильного фронта, которые вывезет проект любой сложности.
Я пришел в Purrweb на позицию верстальщика, а через полгода начал стажировку по фронтенду. Хотел помогать команде с проектами на React и TypeScript — и уже во время стажировки получил первые реальные задачи.
Станислав Лаврентьев,
фронтенд разработчик в Purrweb
Знание технологий, а именно JavaScript — важный навык для разработчика. Это подтверждает статистика:
- по данным StackOverflow, JavaScript в списке инструментов фронтенда лидирует с огромным отрывом (90,5%)
- исследование компании O’Reilly, проведенное среди европейских программистов в конце 2016 года, тоже ставит JavaScript на первое месте.
Мы в Purrweb пишем на JavaScript и TypeScript, используем библиотеку React, а мобильные приложения делаем на React Native.
Бэкенд разработчики
Закройте глаза. Что видите? Правильно, ничего. Но мир вокруг не исчез. Если человек чего-то не видит, это не значит, что этого нет. Точно также работает бэкенд. Пользователь не видит серверную часть страницы, но именно она приводит в действие сайт или приложение.
Если бы проект был автомобилем, то бэкенд был бы его двигателем. И как бы хорошо не выглядела машина снаружи, если под капотом двигатель от «Жигули», далеко на ней не уедешь.
Бэкенд отвечает за логику работы сайта. Например, когда вы вводите запрос на странице поисковика и жмёте клавишу Enter, фронтенд заканчивается и начинается бэкенд. Ваш запрос отправляется на сервер Google или «Яндекса», где расположены алгоритмы поиска. Именно там случается всё «волшебство». Как только на мониторе появилась информация, которую вы искали, — вновь происходит возвращение в зону фронтенд.
По большому счёту, сервер — это тот же компьютер, только более мощный. Он хранит данные и отвечает на запросы пользователей.
Главное отличие фронтенда от бэкенда — в количестве концептов и способах их реализации. Если на фронте есть только один концепт и множество путей его воплотить, то на бэке и идей, и способов тысячи. Другими словами, фронтенд — это инструменты, а бэкенд — теория. В бэкенде много разделов: трудности возникают, когда пытаешься осмыслить фундаментальные вещи. Недавно я завершил внутреннюю стажировку по бэкенду. Учиться всегда сложно. Я давно хотел изучить новые технологии — это совпало с тем, что на проекте FitnessApp не хватало бэкендера.
Даниил Герасименко,
фуллстек разработчик в Purrweb
Мы попросили Даниила прокомментировать статистику от StackOverflow. Для справки: до 2019 года количество фронтенд разработчиков на рынке зашкаливало, а бэкендеров, наоборот, не хватало. Теперь ситуация такова:
Самые популярные профессии в IT за 2020 год по версии StackOverflow
Наш фулл-стек разработчик выделил три причины популярности бэкенда:
- Деньги — в среднем бэкендеры получают побольше фронтов.
- Саморазвитие — развиваться в бэкенде можно практически бесконечно.
- Конкуренция — вернее, ее отсутствие. Пока рынок не переполнен, у молодых бэков есть все шансы стать успешными сеньорами.
UI/UX дизайнеры
Повелители интерфейсов, властелины кнопок и варфреймов. Дизайн задает направление всему проекту, поэтому эксперты в области UI/UX не менее важны, чем разработчики. Без дизайнеров, на самом деле, и разрабатывать было бы нечего. В большинстве компаний процесс создания приложения/сайта начинается именно с дизайна. Как правило, в команде разработки один дизайнер, который исполняет обе роли.
Так происходит, потому что крутому дизайнеру важно уметь и в UI, и в UX — это сокращает время работы и улучшает ее качество.
Перед началом работы UI/UX дизайнер анализирует требования заказчика к проекту, а также определяет целевую аудиторию. Так специалист понимает «боли» тех, для кого создает приложение. Его задача — определить трудности, с которыми сталкиваются пользователи и эффективно решить их с помощью дизайна. Затем дизайнер возводит каркас приложения — вайрфрейм, схематичное размещение элементов на странице.
Иногда дизайнер использует пользовательские истории — простые описания той или иной части приложения. Юзер сториз помогают сосредоточиться на цели проекта — сделать удобный и понятный пользователю интерфейс. Пользовательскую историю пишут «на языке клиента» и часто путают с техническим заданием. В действительности юзер стори помогает понять, что нужно заказчику.
UI и UX дизайн — это, по сути, про одно и тоже. Если говорить точно, UX — это путь пользователя по приложению, а UI — способ взаимодействия. И если ты проектируешь путь, то никак не можешь не взаимодействовать с ним. Например, когда ты выбираешь цвет, размер и расположение кнопки — это UI. А когда определяешь роль этой кнопки — UX.
Юлия Вакуленко,
ведущий UI/UX дизайнер в Purrweb
Там, где кончается UX, начинается UI — дизайн интерфейса. Тут главное сделать красиво. От хорошего UI дизайна зависит впечатление пользователей, а от впечатления — вернутся ли они в приложение. Сильный UI/UX дизайн — залог успешного стартапа. Проверено на 275 проектах в Purrweb 😎
QA инженеры
QA инженер или тестировщик — это человек, который проверяет работу приложений и ищет в них всевозможные ошибки и уязвимости. Он руководствуется технической документацией, а иногда и просто здравым смыслом. Ведь тестировщик смотрит на приложение глазами не только разработчика, но и пользователя. Поэтому иногда он «вмешивается» в процесс разработки и предлагает добавить в приложение более удобные функции.
Обычно тестировщик занимается проверкой самого приложения, его работоспособности и внешнего вида. Но порой к этим задачам прибавляется проверка и технических инструкций, и баз данных, и бизнес-процессов, и нужд заказчика, и даже работы команды разработки. В своей работе тестировщик постоянно взаимодействует с представителями заказчика, бизнес-аналитиками, разработчиками и дизайнерами.
Работа QA инженера сложная, потому что нужно делать одно и то же много раз. Приложение снова и снова тестируется на разных устройствах — надо, чтобы все работало как часы. А еще говорят, тестировщики ищут ошибки разработчиков, а их ошибки не ищет никто. Разве что клиент 😇
Игорь Андреев,
QA инженер в Purrweb
Тестирование — это не только набор технических скиллов, но и особые личные качества. Собрали софт скиллы, необходимые тестировщику:
- Аналитический склад ума;
- Усидчивость;
- Системный подход к решению проблем;
- Стрессоустойчивость;
- Обучаемость.
В общем-то, стандартный набор навыков адекватного сотрудника IT компании. А что по хардам?
- Язык SQL, базы данных MSSQL, Oracle;
- Тестирование API;
- Нагрузочное тестирование;
- Тестирование безопасности;
- Автотесты;
- Английский язык для чтения документации.
Все, о ком мы говорили выше — непосредственные участники разработки. Но в команде есть те, с кого стартует любой проект. Если решите заказать у нас услугу, именно этих людей встретите в первую очередь. Знакомьтесь, бизнес-аналитики и менеджеры по продажам!
Стартапу как таковому они не нужны — вряд ли вы купите услугу аккаунт менеджера, чтобы он что-то вам продал. Однако для компании-подрядчика это такие же важные сотрудники, как и члены команды разработки. Если у вашей аутсорс компании есть аналитики и сейлзы, то вы точно получите четкую оценку проекта и комфортную коммуникацию на этапе пресейла.
Интересно, как работают пресейл и оценка у нас? Продолжай читать 😇
Бизнес-аналитики
Бизнес-аналитики в Purrweb занимаются пресейлом и оценкой. На старте любого проекта важно верно оценить время, которое понадобится разработчикам, дизайнерам, тестировщикам и другим участникам команды. Если бизнес-аналитик ошибется с оценкой, его тиммейтам придется работать до позднего вечера и по выходным.
Раньше мы делали оценку так: брали любого свободного разработчика и за час прикидывали, сколько времени уйдет на проект. В 9 из 10 случаев угадать не получалось. Долгим и сложным путем мы пришли к тому, что без нового процесса оценки и пресейла нам не выжить. А потом просто сели и сделали это:
Пресейл + оценка дизайна
Клиент — приходит в Purrweb с идеей проекта.
Менеджер по продажам — созванивается с клиентом, узнает идею, предлагает решения и называет вилку цен.
Бизнес-аналитик – получает от менеджера по продажам материалы с созвона, расписывает детали проекта.
Дизайнер — на основе информации от бизнес-аналитика оценивает проект: сколько времени команда потратит на воплощение идеи.
Деньги — дизайнер передает оценку менеджеру по продажам, чтобы тот на следующем созвоне показал ее клиенту. Если клиент одобряет наше предложение, происходит оплата.
Проектный менеджер — после оплаты проект летит к проектному менеджеру и команде. В указанные в оценке сроки мы должны реализовать идею клиента.
Готово! — когда все правки внесены, а комментарии отработаны, когда заказчик говорит «ОК!», проект считается готовым.
А если клиент захотел еще и разработку?
Иногда к нам приходят с четким запросом: сделать только дизайн, потому что есть внутренняя команда разработчиков, либо создать проект с нуля до полноценного приложения. Кто-то в процессе работы над дизайном понимает, что хочет еще и разработку. Случаи разные — подход один. Если клиенту нужно написать что-то на React, в дело включаются тимлиды. Оценка разработки выглядит так:
Оценка разработки
Проектный менеджер — составляет документ с деталями проекта разработки, прописывает юзер сториз
Тимлиды – тимлид-фронтендер и тимлид-бэкендер в течение 5-8 часов оценивают проект: декомпозируют задачи, делают из больших тасок много маленьких
Клиент — платит, когда одобряет наш большой документ
Дальше проект возвращается к проектному менеджеру, и стартует разработка.
Больше про пресейл, оценку и работу бизнес-аналитиков читайте в нашей статье
Менеджеры по работе с клиентами
Говорят, что встречают по одежке, но в IT встречают по сейлз-менеджеру. Специалист по работе с клиентами — первый человек на пути клиента, поэтому важно, чтобы он производил приятное впечатление.
Наша задача — определить с клиентом направление, в котором будет двигаться проект. Иногда после созвона мы понимаем, что заказчику не нужно дорогое кастомное решение, и предлагаем другие опции — например, сделать сайт на WordPress вместо сложной разработки. Порой важно охладить пыл клиента, донести, что проект не выгорит, и найти выход из ситуации: убрать некоторые фичи или вовсе пересмотреть скоуп проекта.
Дарья Кравец,
менеджер по работе с клиентами в Purrweb
Хороший менеджер по работе с клиентами мыслит решениями и видит не только точку отсчета проекта и процесс создания, но и результат, к которому команда приведет заказчика. А еще для аккаунт менеджера важно говорить понятным языком, чтобы сохранить прозрачность между исполнителем и клиентом.
Grand finale
Просим прощения за наш французский! Мы все. Подведем небольшой итог:
- В хорошем составе команды разработки есть все, кого мы перечислили в этой статье. Такой же состав, например, в Purrweb 💜
- Лучше нанять сработанную команду на аутсорсе, чем набирать спецов «вручную».
- Если хотите заказать у нас проект, пишите в форму ниже 👇
Лекция
КС ЭК.
Функциональные роли в коллективе
разработчиков 1
ВОПРОСЫ ДЛЯ ПРОВЕРКИ 12
Ключевые роли коллектива разработчиков
и задача определения кадровых ресурсов
проекта 14
Функциональные роли в коллективе разработчиков
Определяются
функции, выполняемые сотрудниками в
ходе развития проекта
и типичные для программных проектов
роли разработчиков; указывается,
какие роли могут совмещаться при
выполнении проекта. Представлены
решения обсуждаемых вопросов, предлагаемые
компанией Microsoft
и Центром
объектно-ориентированных технологий
IBM.
Ключевые
слова: функции
участников проекта, типовые функции,
распределение
функций, роли разработчиков, функции и
поручения, технологическая функция,
экстремальное программирование,
организационные
и производственные функции, модель
проектной группы MSF,
ролевой кластер, область компетенции,
область функциональной
специализации, кластер управления
продуктом, кластер
управления программой, кластер разработки,
кластер тестирования,
кластер удовлетворения потребителя,
кластер управления выпуском,
модель ролевой структуры проекта
компании IBM,
заказчик,
планировщик ресурсов, менеджер проекта,
руководитель команды, архитектор,
проектировщик подсистемы, разработчик,
разработчик
информационной поддержки, специалист
по пользовательскому интерфейсу,
тестировщик, библиотекарь, инициатор
работ, внешние функции менеджера,
внутренние функции менеджера,
совмещение ролей, принципы совмещения
ролей, внешние роли
проекта, перекрестное совмещение ролей.
Для
целенаправленного выполнения проекта
должен быть выполнен ряд
работ, различных как по своему назначению,
так и по квалификационным
требованиям, предъявляемым к разработчикам.
Иными словами, в
ходе развития проекта командой
разработчиков выполняются те или иные
функции.
Функции,
выполняемые разработчиками, — понятие
неформализованное.
В разных проектах оно может обретать
свое содержание. Тем не
менее типовые
функции, которые
предполагают практически все программные
проекты, можно перечислить. Так, в любом
программном проекте
есть функции кодирования,
т.е.
записи программы на алгоритмическом
языке по имеющимся спецификациям,
анализа
требований, т.е.
выявления истинной потребности в
создаваемой программе, тестирования
и
отладки.
Далее
мы рассмотрим эти и другие функции
разработчиков,
связанные с проектом, а пока лишь заметим,
что в рамках деятельности
менеджера любого проекта необходимо
организовать распределение
функций проекта между исполнителями.
Вполне
естественно считать
эти действия одной из функций менеджера.
В результате ее выполнения
члены команды, выполняющей проект,
начинают играть соответствующие
роли.
Обычно
роль объединяет родственные функции.
Также принято обозначать роли их главными
функциями. Продолжая только что
приведенную иллюстрацию функций,
выполняемых разработчиками проекта,
укажем на следующие роли: кодировщик —
действующее лицо, главной
функцией которого является кодирование,
аналитик — тот, кто занимается
анализом требований. Подобную
характеристику можно дать
и тестировщику. Что же касается функции
отладки, то в реальных проектах она
обычно подразделяется на несколько
видов: отладка компонентов,
которой занимаются разработчики
компонентов (например, те
же кодировщики) и комплексная отладка,
которая может поручаться специально
выделенным сотрудникам или рассматриваться
в качестве задачи
группы разработчиков. Часто выполняются
такие работы, как отладка
спецификаций, декомпозиция проекта и
др. Иными словами, функция
отладки обычно не рассматривается как
образующая роль, а распределяется
по нескольким ролям в соответствии с
принятой стратегией
развития проекта.
Не
следует путать функции, которые предписано
выполнять разработчику
как исполнителю определенной роли, с
поручениями
в
проекте. Поручения
— это разовые или систематические
задания, из которых обычно
и складываются действия, необходимые
для выполнения той или иной
функции. Если для функции определен
регламент выполнения поручений,
т. е. последовательность выполнения
составляющих ее поручений
не требует дополнительных разъяснений
для исполнителя, то такая функция
называется технологической.
В
случае нетехнологической функции
сотруднику, который выполняет
соответствующую роль, приходится самому
выстраивать нужную последовательность.
Иными словами, технология
здесь уступает место ремеслу.
При
разработке любых проектов естественно
стремление к повышению
их технологичности, к установлению
регламента для как можно большего
числа функций. И одним из способов
достижения этого для менеджера
является использование работников с
нужной квалификацией, для
которых поручаемые им роли оказываются
технологичными, т.е. состоящими
только из технологических функций. К
сожалению, реальность
такова, что менеджеру приходится работать
в условиях ограниченных
возможностей в подборе кадров, а потому
уровень технологичности выполнения
проекта снижается по сравнению с
идеальной ситуацией.
Таким
образом, в рамках любого проекта возникает
задача повышения
квалификации сотрудников. Для различных
схем ведения проектов
эта задача решается по-разному. Крайнюю
точку зрения на проблему
соответствия квалификации работников
требованиям проекта отражает
идея экстремального
программирования [3],
когда используется
неформальная организация группы
исполнителей проекта без четкого
распределения ролей, а значит, и
обязательств сотрудников. В этом
случае провозглашается принцип, когда
каждый в группе делает то,
что он умеет делать лучше всего. И хотя
все функции, которые должны выполняться,
остаются, создается впечатление, что в
группе исполнителей проекта исчезают
роли. В результате возможны пробелы
в разработке, в частности при анализе
и декомпозиции проектируемой
системы. Чтобы этого избежать, разработчики
должны понимать,
какую абстрактную роль они исполняют
в каждый конкретный момент,
выполнение каких проектных функций
необходимо сейчас, как
связаны между собой работы, как должны
распределяться ресурсы. Словом, они
должны обращать внимание на выполнение
распределенных
по группе менеджерских функций. И даже
в этом случае схему
экстремального программирования можно
рекомендовать лишь для слаженных групп
исполнителей с высоким уровнем
коллективной ответственности.
Функции,
выполняемые разработчиками в проекте,
подразделяются
на организационные
и
производственные.
Первые
создают условия для выполнения
проектных заданий, вторые непосредственно
связаны с этими
заданиями. Часто неудачи проекта
возникают из-за того, что менеджер
не учитывает важность выполнения
организационных функций. Так,
обычно проектное задание фиксирует
лишь то, что нужно предъявлять
заказчику в качестве результатов. С
точки зрения результатов просто не
требуется знать, например, как организована
передача проектных материалов между
разработчиками, какая процедура
отчетности предусматривается,
но игнорирование задач реализации
информационных потоков
в проекте может привести к хаосу, что в
конечном итоге отразится
и на результатах.
Понятно,
что как состав, так и значимость ролей
разработчиков и тех, кто с ними связан,
различаются в зависимости от выполняемого
проекта,
от коллектива исполнителей, принятой
технологии, от других факторов.
Неоднозначность выбора ролей приводит
к тому, что их список часто становится
непомерно велик (иллюстрацией тому
может служить
первая редакция документации по Rational
Unified
Processing
(RUP),
в которой определено свыше 20 ролей; в
последующих версиях документа
это число сокращено до обозримого уровня
[30]). Чрезмерное
увеличение числа есть следствие
отождествления роли и функции и,
соответственно,
игнорирования понятия родственности
функций. В то же время, если ролей выбрано
недостаточно, есть опасность, что не
все нужные
в проекте функции будут охвачены
планированием и управлением.
Как
конкретный разработчик может получать
одновременно несколько
ролей, так и роль может быть распределена
между несколькими исполнителями.
В рамках изложения, следуя соглашению
об абстрактных действующих лицах (см.
лекцию 1), мы вправе отождествлять роль
и действующее лицо. Но это не более
чем способ представления материала,
направленный на разделение сущностей.
Когда менеджеру в конкретных условиях
руководства коллективом придется
распределять роли, он неизбежно
столкнется с тем, что эта задача зависит
и от специфики проекта, и от
контингента исполнителей. В связи с
этим уместно упомянуть об одном из
ее решений, которое предлагается
специалистами Microsoft
в качестве
универсального подхода.
В
модели проектной группы концепции
Microsoft
Solution
Framework
(MSF)
предлагается образовывать небольшие
мобильные коллективы
как атомарные производственные единицы
с общей ответственностью за выполняемые
задания — так называемые проектные
группы [44].
Такие группы строятся как многопрофильные
команды, члены
которых распределяют между собой
ответственность и дополняют области
компетентности друг друга. Группа
состоит не более чем из 10
человек. Все они считаются обладающими
сходным уровнем профессиональной
подготовки, хотя и в разных областях
индивидуальной специализации.
Провозглашается равноправие членов
группы и коллективная
ответственность за выполняемые задания:
проектная группа — команда равных. Все
это позволяет сохранять внутри группы
неформальные
отношения.
Вместо
понятия роли для группы в целом
определяются ролевые
кластеры,
которые
заполняются точно так же, как происходит
распределение
ролей. В то время как за успех проекта
ответственна вся команда, каждый
из ее ролевых кластеров, определяемых
моделью, ассоциирован с одной
из проектных целей и работает над ее
достижением. В данной модели именно
эти цели задают роли разработчиков,
которые определяются кластерами. В
терминологии MSF
используется понятие области
компетенции,
или
области
функциональной специализации (functional
area),
обозначающее
ту или иную роль, которую выполняет
кластер группы в проекте. Принципиальное
отличие распределения исполнителей по
ролевым кластерам от распределения
ролей заключается лишь в том, что
ответственность
за это несет не менеджер проекта, а сама
группа. Менеджер проекта
выдает задания и контролирует их
выполнение лишь в целом для группы,
не вмешиваясь в ее работу.
Определено
шесть ролевых кластеров, которые
соответствующим образом
структурируют проектные функции
разработчиков (рис. 2.1).
■
Управление
продуктом (product
management).
Ключевая цель кластера
— обеспечивать удовлетворение интересов
заказчика. Для ее достижения
кластер должен содержать следующие
области компетенции:
-
планирование
продукта, -
планирование
доходов, -
представление
интересов заказчика, -
маркетинг.
> Управление
программой (program
management).
Задача — обеспечить
реализацию
решения в рамках ограничений проекта,
что может
рассматриваться
как удовлетворение требований к бюджету
проекта
и к его результату. Области компетенции
кластера:
-
управление
проектом; -
выработка
архитектуры решения; -
контроль
производственного процесса; -
административные
службы.
► Разработка
(development).
Первостепенной задачей кластера является
построение решения в соответствии со
спецификацией. Облаcти
компетенции кластера:
-
технологическое
консультирование; -
проектирование
и осуществление реализации; -
разработка
приложений; -
разработка
инфраструктуры.
•
Тестирование
(test).
Задача кластера — одобрение выпуска
продукта только
после того, как все дефекты выявлены и
устранены. Области компетенции
кластера:
-
разработка тестов;
• Удовлетворение
потребителя (user
experience).
Цель кластера — повышение
эффективности использования продукта.
Области компетенции
кластера:
-
общедоступность
(возможности работы для людей с
недостатка
ми
зрения, слуха и др.); -
интернационализация
(эксплуатация в иноязычных средах); -
обеспечение
технической поддержки; -
обучение
пользователей; -
удобство эксплуатации
(эргономика); -
графический
дизайн.
• Управление
выпуском (release
management).
Задача кластера — беспрепятственное
внедрение и сопровождение продукта.
Области
компетенции
кластера:
-
инфраструктура
(infrastructure); -
сопровождение
(support); -
бизнес-процессы
(operations); -
управление
выпуском готового продукта (commercial
release
management).
Даже
не вдаваясь в детали того, какие функции
выполняются кластерами
проектных групп схемы MSF,
мы видим, что многие задачи менеджмента
перенесены на уровень компетенции
групп. В части управления проектом
менеджер оказывается в состоянии
оперировать крупными заданиями
стратегического характера. Эта ситуация
во многом похожа на схему
экстремального программирования,
которая дополняется явным предписанием
выделять ролевые кластеры со своими
областями компетенции.
Если в конкретной ситуации не требуется
обеспечивать какую-либо
из областей компетенции, то соответствующий
кластер не образуется. Организация
проектных групп позволяет существенно
разгрузить менеджера,
что фактически и провозглашается как
цель схемы MSF.
Если
обратиться к менеджерским задачам
руководства коллективом в
проекте, то оказывается, что схема MSF
мало что регламентирует. Говорится
лишь о том, какие должны быть группы, но
вопросы их формирования
оставлены без ответа. Этого и следовало
ожидать, имея в виду постулат
невозможности формализовать руководство.
В то же время, сама схема ограничивает
действия менеджера. В подтверждение
этому приведем
один пример из опыта автора этих строк.
При работе с очень квалифицированной
программистской группой был замечен
явный рост продуктивности
ее членов, когда на собраниях присутствовала
весьма привлекательная
лаборантка, о профессионализме и
компетентности которой
не могло быть и речи. Единственное
объяснение тому — повышение духа
состязательности в коллективе, Вместе
с тем по логике MSF
для такой
работницы просто нет места в проектной
группе. Как учитывать и использовать
подобные ситуации? Единственный совет,
который можно здесь
дать, — не очень полагаться на
формализованные схемы организации
и быть как можно более наблюдательным.
Концепция
абстрактных действующих лиц проекта,
определяемых выполняемыми ими ролями,
допускает при обсуждении управления
проектами
не рассматривать структуры коллективов
на уровне персоналий.
Это позволяет более точно представить
сгруппированные в виде ролей
функции разработчиков, что в свою очередь
дает возможность проецировать
ролевую структуру проекта на любую
структуру коллектива
разработчиков.
Мы
придерживаемся ролевой структуры
проекта, которая предложена
Центром объектно-ориентированной
технологии компании IBM
[46]. Эта
структура включает достаточно полный
перечень типичных ролей, согласованный
со многими реальными дисциплинами
развития программных проектов. В то
же время она представляет роли
разработчиков в организационном
контексте, т.е. рассматривает не только
разработчиков,
но и тех, кто, не участвуя в проекте в
качестве исполнителей, оказывает
влияние на постановку задач проекта,
на выделение ресурсов и обеспечение
осуществимости развития работ. В
представленном перечне характеристика
каждой роли, по сути, задает круг
родственных организационных
и производственных функций, которые
объединяются с целью определить
роль.
-
Заказчик
(Customer)
— реально существующий (в организации,
которой
подчинена команда, или вне ее) инициатор
разработки или
кто-либо
иной, уполномоченный принимать результаты
(как текущие,
так и окончательные) разработки. -
Планировщик
ресурсов (Planner)
— выдвигает и координирует требования
к проектам в организации, осуществляющей
данную раз
работку,
а также развивает и направляет план
выполнения проекта
с
точки зрения организации. -
Менеджер
проекта (Project
Manager)
— отвечает за развитие проекта
в
целом, гарантирует, что распределение
заданий и ресурсов позволяет
выполнить проект, что работы и предъявление
результатов идут
по
графику, что результаты соответствуют
требованиям. В рамках
этих
функций менеджер проекта взаимодействует
с заказчиком и
планировщиком
ресурсов. -
Руководитель
команды (Team
Leader)
— производит техническое руководство
командой в процессе выполнения проекта.
Для больших
проектов
возможно привлечение нескольких
руководителей подкоманд,
отвечающих за решение частных задач. -
Архитектор
(Architect)
— отвечает за проектирование
архитектуры
системы,
согласовывает развитие работ, связанных
с проектом.
-
Проектировщик
подсистемы (Designer)
— отвечает за проектирование
подсистемы или категории классов,
определяет реализацию и
интерфейсы
с другими подсистемами. -
Эксперт
предметной
области (Domain
Expert)
— отвечает за изучение
сферы
приложения, поддерживает направленность
проекта на
решение задач данной
области. -
Разработчик
(Developer)
— реализует проектируемые
компоненты,
владеет
и создает специфичные классы и методы,
осуществляет кодирование
и автономное тестирование, строит
продукт. Это широкое
понятие, которое может подразделяться
на специальные роли
(например,
разработчик классов). В зависимости от
сложности
проекта
команда может включать различное число
разработчиков. -
Разработчик
информационной поддержки (Information
Developer)
—
создает
документацию, сопровождающую продукт,
когда выпускается
версия. Включаемые в нее инсталляционные
материалы, равно
как ссылочные и учебные, а также материалы
помощи предоставляются
на бумажных и машинных носителях. Для
сложных проектов возможно распределение
этих задач между несколькими
разработчиками
информационной поддержки. -
Специалист
по пользовательскому интерфейсу (Human
Factors
Engineer)
— отвечает за удобство применения
системы. Работает с
заказчиком,
чтобы удостовериться, что пользовательский
интерфейс
удовлетворяет требованиям. -
Тестировщик
(Tester)
— проверяет функциональность, качество
и
эффективность
продукта. Строит и исполняет тесты для
каждой
фазы
развития проекта. -
Библиотекарь
(Librarian)
— отвечает за создание и
ведение
общей
библиотеки
проекта, которая содержит все проектные
рабочие
продукты,
а также за соответствие рабочих продуктов
стандартам.
Первые
две позиции в приведенном перечне
отведены заказчику и планировщику
ресурсов, которые имеют лишь внешнее
отношение к разработке
проекта, — они не являются членами
команды. Заказчик — это лицо,
заинтересованное в получении результатов.
Планировщик решает задачи
распределения финансовых, трудовых и
технических ресурсов для разных
проектов внутри фирмы. При правильной
организации разработки с этими
действующими лицами приходится
сталкиваться лишь менеджеру проекта.
Мы
будем иметь возможность убедиться в
том, что заказчик как реальная
персона не является единственным лицом,
заинтересованным в получении
результатов. На задачи проекта влияют
персоналии из сфер производства и
потребления программных продуктов,
расширяя или сужая
возможности будущего программного
изделия, — так называемые инициаторы
работ (stakeholdes)*.
О
них говорить необходимо, когда обсуждение
менеджмента касается влияния на проект
внешних требований. И в
этом плане полезно воспринимать заказчика
в качестве равнодействующей всех
инициаторов работ, которая выставляет
согласованные требования и задачи.
Иными словами, там, где удобно не различать
внешние влияния
на проект, мы определяем абстрактного
заказчика.
Взаимодействие
менеджера с заказчиком, планировщиком
и другими
инициаторами работ — прямая обязанность
менеджера проекта. Таким
образом, для него закреплен круг функций,
которые
являются внешними
по
отношению к работам над проектом.
Выполнение
внешних функций создает лишь условия
для разработки.
Как видно из перечня ролей, другой круг
функций, возлагаемый на менеджера,
связан с взаимодействиями с действующими
лицами из команды
разработчиков проекта. Это внутренние
функции менеджера.
Иногда
в круг ролей, связанных с программным
проектом, включают
двух внешних менеджеров: по заказам и
по продажам. Задача первого из
них — обеспечивать приток заявок на
проекты, организовывать первичные
контакты с потенциальными заказчиками;
задача второго — поддерживать
продвижение продукта на рынке.
Ограничиваясь вопросами менеджмента
программных проектов, мы не включаем
их в состав ролей действующих лиц
проекта, поскольку их функции связаны
с разработкой лишь косвенно. Влияние
на разработку менеджера по заказам
заканчивается,
когда у менеджера проекта появляется
предварительный заказ на разработку,
после чего источник заказа становится
несущественным. Влияние
менеджера по продажам более продолжительно,
но оно не распространяется
далее выставления требований к проекту,
т.е. не выходит за рамки
активности иных инициаторов работ.
В
зависимости от проекта и условий его
выполнения роли участников
проекта могут совмещаться.
Предельный
случай — программист разрабатывает
проект для себя (по собственному заказу),
сам планирует
*Термин
«инициаторы работ» —
перевод
английского слова «stakeholdes».
В литературе можно встретить и другие
его переводы: организаторы работ,
заинтересованные лица и даже акционеры
(последнее уводит далеко в сторону).
Некоторые прибегают к транслитерации
и говорят о степк-хапдерах
проекта. Мы предпочитаем назыать всех
тех, чьи интересы в той или иной мере
затрагивают проект и его результаты,
инициаторами работ. Наряду с этим мы
употребляем термин «заинтересованные
лица», обозначая им всех тех, кто проявляет
интерес к проекту и от действия которых
может зависеть его развитие, пусть даже
косвенно. Таким образом, инициаторы
работ включают
в себя заинтересованных лиц (в частности,
разработчиков проекта), но обратное
неверно.
К примеру, акционер проекта является
инициатором работ, так как его интересы
судьба проекта,
безусловно, затрагивает. Но полагаясь
на своего брокера, он может позволить
себе даже не думать
о проекте, т.е. не быть его заинтересованным
лицом (в нашей терминологии).
распределение
ресурсов (сроки выполнения работы,
использование вычислительной техники
и др.), сам принимает проектные решения
(управляет и руководит собою) и сам же
занимается разработкой, экспертизой и
обслуживанием.
Но даже здесь полезно для себя четко
понимать, чья (в смысле
распределения ролей) задача решается
в каждый конкретный момент. Даже
здесь следует отказываться, например,
от бессмысленной документации,
не из общих соображений, а в результате
мотивированного сопоставления
издержек (время подготовки) и приобретений
(фиксация получаемых
результатов для будущего, дополнительный
опыт и т.п.)- Это избавит
от тех же ошибок бессистемности, которые
возможны и при нетехнологичном
развитии большого проекта.
Понятно,
что совмещение ролей не может быть
произвольным. Одни
совмещения нежелательны (в разной
степени), другие нейтральны, третьи
полезны для проекта. Общий регламент
для совмещения определяют
следующие принципы:
I.He
следует
допускать совмещения ролей, которые
имеют конфликтные или противоречивые
интересы. Если такое совмещение все-таки
используется, то необходимо предусматривать
механизмы, которые будут демпфировать
противоречия.
-
Представление
ролей с конфликтными интересами
различным
людям
обеспечивает равновесие противоречащих
точек зрения. -
Прибегать
к совмещению ролей для участников
проекта, основной
ролью
которых является разработка, означает
заведомое увеличение
сроков выполнения соответствующих
работ. По этой причине
для
них допустимы лишь такие совмещения,
которые действительно
необходимы в данный момент развития
проекта (например, в
некоторых
авральных ситуациях) и которые не
требуют постоянной
деятельности в течение длительного
срока. -
Если
работнику поручается несколько ролей,
то он всегда должен
знать,
какую из них он выполняет в данный
момент.
В
большинстве случаев заказчик и планировщик
ресурсов являются действительно внешними
по отношению к проекту действующими
лицами,
а потому совмещение этих ролей с другими
— нечто экзотическое. Тем не
менее роль заказчика как члена коллектива
разработчиков, аккумулирующего
точки зрения всех инициаторов работ,
весьма полезна. В частности, подход
экстремального программирования считает
это обязательным, чтобы
развитие проекта всегда гарантированно
было направлено в сторону, нужную
пользователям [3]. Поскольку в этом
подходе ролевая дифференциация
работников отходит на второй план, его
апологеты не выделяют
специально роли эксперта предметной
области. Скорее всего, они считают,
что его функции должны выполнять
заказчик, который составляет тесты
для проверки системы в целом (по крайней
мере специфицирует их),
и остальные разработчики группы, которые
по мере уяснения актуальных
пользовательских потребностей поймут,
как их воплотить в коде. Но задачи
эксперта предметной области иные: он
должен понимать структуру пользовательской
деятельности, чтобы отвечать на вопросы
об узких местах
этой деятельности, о критериях актуальности
принимаемых решений, о
содержательных формах, в которых
предоставляемые средства должны
преподноситься
пользователям. Даже если не брать в
расчет перегрузку роли заказчика
экспертными функциями, понятно, что
предположение о включении заказчика в
команду, выполняющую проект, представляется
скорее
исключением, нежели правилом. Уже из
этого примера видно, насколько
размыты границы между функциями разных
ролей, а значит, и совмещения ролей в
команде. Точное определение ролей, их
разграничения
и совмещения — область специфики
конкретных проектов. Тем не менее,
уместно сформулировать рекомендации,
основанные на опыте успешного
и неудачного менеджмента программных
проектов.
Менеджер
проекта по своему назначению является
выделенным в команде. Он берет на себя
взаимодействие с заказчиком и
планировщиком
ресурсов, с одной стороны, а с другой —
распределяет работы среди членов
команды. Последнее означает, что он
должен обладать полной информацией
о декомпозиции проекта. Как следствие,
совмещение его роли
с ролью архитектора проекта является
весьма желательным, а потому довольно
частым. Единственным условием для такого
совмещения является требование четко
знать, когда и чьи функции выполняет
данное действующее
лицо (см. общий для всех совмещений
принцип 4).
Вполне
возможно продуктивное совмещение ролей
руководителя команды
и архитектора — это дает ощутимые
результаты, когда команда достаточно
крепко связана со своим руководителем,
например, по предшествующим
работам, но при условии не слишком
высокой сложности задач
декомпозиции для данного проекта.
Совмещение
ролей руководителя команды и менеджера
допустимо, но
лишь тогда, когда осознается и учитывается
противоречивость целевых
установок этих ролей: руководитель
команды действует в условиях, которые
формируются менеджером.
Нежелательно
совмещение ролей руководителя команды
и проектировщика
какой-либо подсистемы. И это обусловлено
противоречивостью их
ролевых интересов.
•
Критерии качества
для проектировщика подсистемы лежат в
области
использования, он должен стремиться к
постановке задания, максимально
полно удовлетворяющего потребности
использования,
тогда как для руководителя команды
желательно оградить команду
от излишнего внешнего влияния, в том
числе от влияния пользовательских
потребностей (см. принцип 1).
-
Руководитель
команды должен выдавать задания исходя
из системы
реализационных
понятий, которая принципиально отличается
от
системы
понятий подсистемы в целом, соответствующей
уровню
использования.
Этот уровень отслеживается проектировщиком. -
Разделение
ролей проектировщика и руководителя
способствует
равновесию
точек зрения пользователя и разработчика
подсистемы
(см.
принцип 2).
Если
используется перекрестное совмещение
ролей руководителя команды и проектировщика
подсистемы, то возникает еще одно
противоречие
их ролевых интересов: у руководителя
могут быть предпочтения в
пользу «своего» компонента и, как
следствие, возможен дисбаланс проекта
в целом в пользу выделенных его
составляющих, который придется
компенсировать
дополнительными усилиями менеджера.
По
тем же причинам не допускается совмещение
ролей менеджера и разработчика.
Здесь запрет более жесткий, поскольку
контрольные функции менеджера
несовместимы с исполнительскими задачами
разработчика.
Даже в тех случаях, когда у менеджера
остается свободное время после
выполнения своих прямых обязанностей,
ему не следует «помогать» разработчикам.
Лучше занять себя другим делом, в
частности выступить в роли
разработчика другого проекта.
В
то же время совмещение ролей различных
разработчиков — обычное
дело для больших проектов. Оно является
частью распределения работ
по исполнителям. Решают эту задачу
совместно руководитель команды
и менеджер, когда основные архитектурные
положения утверждены. Способы
решения зависят от того, как формируется
команда. Если разработка
поручается готовой команде, то возрастает
роль руководителя, а менеджер
лишь утверждает его предложение. Когда
команда создается для
проекта, растет удельный вес менеджерских
функций в подборе кадров для работ.
Но в любом случае при совмещении ролей
различных разработчиков
нужно учитывать уровень квалификации
работников, их предпочтения
и другие индивидуальные особенности.
Необходимо знать,
что, выделяя одному действующему лицу
несколько работ, следует
стремиться к однородности заданий и
указывать их сравнительные приоритеты.
Допустимы
и другие совмещения ролей. Так, довольно
часто создание
документации распределяется между
всеми исполнителями проекта, а
на руководителя команды и менеджера
возлагается задача интеграции документов.
Для обозримых проектов функции
библиотекаря можно поручить одному
из разработчиков, соответственно
скорректировав его индивидуальное
задание (см. принцип 3). Специалистом по
пользовательскому интерфейсу вполне
может быть, например, менеджер, поскольку
именно
он осуществляет контакты с заказчиком
(в данной ситуации заказчик
либо сам является пользователем, либо
выступает как представитель
пользователя программного изделия).
Редко
бывает эффективным совмещение ролей
специалиста по интерфейсу
и эксперта предметной области. Причиной
тому — разный угол зрения,
под которым рассматривается система.
Для эксперта система представляется
прежде всего структурированным набором
функций, который обеспечивает
поддержку пользовательской деятельности,
а способ управления активизацией
этих функций вторичен. Как следствие,
возможно игнорирование
таких аспектов интерфейса, как
совместимость с другими системами, учет
сложившихся стандартов и т.п. Эффективность
обсуждаемого совмещения
ролей возможна, если в проекте необходимость
исследования интерфейсных
вопросов не очень высока, а эксперт
предметной области обладает достаточной
квалификацией в организации интерфейсов.
Как всегда, здесь обязательно
следование четвертому принципу регламента
для совмещений: четкое разделение того,
в какой роли выступает работник в данный
момент. Роль
эксперта предметной области может быть
полезна для разработчика,
так как дает дополнительные критерии
при решении его собственных проблем.
Однако эта дополнительная роль порою
чрезмерно перегружает
сотрудника и, как следствие, есть
опасность затягивания сроков
проекта или его этапа (принцип 3). То же
можно сказать и о совмещении
ролей разработчика и специалиста по
интерфейсу. Но здесь совмещение
более целесообразно, особенно для
разработчиков, которым поручены
задачи, затрагивающие вопросы интерфейса.
Причина вполне понятна: исключается
дополнительное звено между разработчиком
и заинтересованными
в качественном интерфейсе лицами.
По
поводу тестировщиков необходимы
некоторые разъяснения. Следует
различать два вида тестирования:
тестирование модулей, автономное
по своей сути, и тестирование предоставляемых
функций, которое может быть и
комплексным (проверка совместного
выполнения функций), и автономным, когда
проверяется работоспособность отдельного
аспекта системы. В первом случае задачи
тестировщика невозможно выполнить
без знания не только назначения, но и
структуры проверяемого
модуля. Лучше всего в этом разбирается
разработчик модуля, а значит, именно
ему этот модуль и отлаживать. Автономное
тестирование второго вида,
по существу, есть другая сторона проверки
работоспособности модуля,
реализующего определенную функцию. Во
многих случаях даже нет нужды
различать его и тестирование модуля.
Поэтому и здесь разумно говорить
о деятельности разработчика. В обоих
случаях самотестирование для разработчика
есть не дополнительная роль в проекте,
а часть его профессиональных
обязанностей в рамках автономной
отладки.
Но
как обеспечить «независимое» тестирование?
Весьма разумный метод
— априорное
тестирование, т.е.
создание тестов до,
а
не после
кодирования
модуля. Это одно из требований
экстремального программирования,
которое вполне может быть распространено
на другие методики ведения
проектов. В статье [32] вводится специальный
термин для обозначения программистов,
которые привыкли писать тесты до
разработки: инфицированные
тестами, и
показывается, что эта «болезнь» только
ускоряет
процесс в целом, В книге [4] Бек показывает,
как можно выполнять программные проекты
с помощью априорного тестирования,
какие преимущества
это дает для процесса разработки и для
его результата.
Другой
метод, нисколько не противоречащий
априорному тестированию,
— перекрестное
тестирование, когда
разработчики независимых компонентов
проекта тестируют функциональность
друг друга. Здесь можно
говорить о перекрестном совмещении
ролей разработчиков и тестировщиков,
поскольку для выполнения перекрестного
тестирования нужно
различное представление об испытываемом
модуле.
Содержательная
задача комплексного тестирования
предоставляемых функций
связывается прежде всего с заказчиком,
который в состоянии дать
для этого все необходимые материалы.
Действуя вне проектной команды,
он способен обеспечить проверку,
действительно независимую от критериев
и предпочтений разработчиков. Однако
заказчик чаще всего не в
состоянии сам правильно строить тесты.
Обычный максимум для него — спецификации
ситуаций использования системы,
нуждающихся в проверке.
Материалы заказчика о пользовательской
деятельности, для автоматизации
которой предназначена программа,
рассматриваются в качестве информационной
базы для комплексного тестирования.
Формирование этой базы есть прямая
функциональная обязанность эксперта
предметной области,
который, действуя на стороне разработчиков,
обеспечивает проект ориентирами,
направляющими развитие. Одна из его
задач в проекте — реконструкция
работы пользователя с системой, из
которой извлекаются реальные
комплексные тесты для проверки
предоставляемых функций. Адаптация
тестов к условиям разработки, т.е.
представление в виде, в котором запуск
и анализ прогонов будут требовать от
разработчиков минимальных
усилий, классификация тестов и т.д. *-
это основная задача тестировшика
как члена проектной команды. Дополнительные
его задачи связаны с обеспечением
технической помощи и поддержки
комплексного тестирования, с ведением
протоколов тестирования и архивов
тестов.
Сведения
о прохождении тестов, построенных так,
как описано выше,
дают объективные основания для дальнейшего
развития проекта, с одной
стороны, а с другой — позволяют передать
заказчику программистское
видение разработки. В результате обе
стороны получают информацию
для определения актуальных средств,
которые требуется реализовать, для
выбора согласованного продолжения
работ. Понятно, что и в данном
случае весьма продуктивен подход
априорного тестирования, который,
по сути своей, оказывается своеобразным
способом задания спецификаций
для разработки в целом. Во многих подходах
для организации независимого
тестирования выдвигается требование,
чтобы роли тестировщиков поручались
независимым специалистам в предметной
области, а
не членам команды. Предыдущее обсуждение
показывает, что это требование
означает лишь смешение функций разных
ролей.
В
цепочке ролей «заказчик, эксперт
предметной области, тестировшик»
нет противоречивых интересов, а потому,
с точностью до того, что заказчик
обычно является внешним по отношению
к проекту лицом, здесь совмещение
ролей оправданно. Что же касается
экстремального программирования,
провозгласившего включение заказчика
в группу разработчиков
как принцип, то при описании подхода
явно указывается, что это означает
лишь предоставление представителя
заказчика команде.
Иными словами,
имеется в виду эксперт предметной
области с дополнительными, разумеется
частичными, полномочиями заказчика.
Продуктивность данной схемы вполне
понятна. Более того, ее можно считать
проверенной временем:
по этой схеме в советские времена
работали все программистские коллективы,
выполнявшие проекты военного ведомства.
Явное участие представителя
заказчика в ключевых моментах разработок
приносило хорошие плоды,
но только при одном условии: если военпред
(как тогда называли представителя
заказчика) не сводил свою работу лишь
к выполнению контрольно-надзирательных
функций. Впрочем, его карьерная
заинтересованность
в успехе проектов чаше способствовала
выработке правильных отношений с
коллективом, чем мешала работе (что
также было нередко, о чем
не следует забывать сторонникам
экстремального программирования).
Все
сказанное выше о тестировании должно
распространяться на проверку
всех результатов, получаемых в проекте,
а не только на код программного
изделия. Таким образом, роль тестировщика
связана с деятельностью,
которая позволяет удостовериться в
правильности принимаемых
решений на всех уровнях, включая выработку
спецификаций (соответствуют ли они
требованиям инициаторов работ), построение
декомпозиции
(дает ли она оптимальную для развития
проекта архитектуру), составление
документации (допускает ли работу
пользователей, не требующую неописанных
сведений о системе), а также разработку
иных рабочих
продуктов, сопровождающих программное
изделие.
Тестирование
как способ внешней оценки продукта для
разработчика противопоказано
(противоречит принципам 1 и 3). Поэтому
часто говорят,
что оно должно быть вынесено за проект.
По-видимому, по этой причине
для экстремального программирования
внешнее тестирование связывают
с работой заказчика, являющегося членом
команды проекта. Когда
такое возможно, получается совмещение
ролей заказчика и тестировщика,
и это приводит к хорошим результатам.
В
качестве итога обсуждения совместимости
ролей для действующих лиц
проекта в табл. 1.3 приводятся краткие
характеристики совмещения ролей,
которые можно рассматривать как
рекомендации для менеджмента.
Разумеется, нельзя абсолютизировать
эти характеристики для любых проектов.
Не стоит жестко фиксировать распределение
ролей и в одном проекте.
Более того, распределение ролей можно
рассматривать в качестве
одного из инструментов, с помощью
которого менеджер может руководить
коллективом. Если этим инструментом
пользоваться умело, то удается
добиться наиболее эффективного разделения
труда, соответствующего индивидуальным
особенностям участников проекта.