Роли разработки системы руководство

Роли в разработке ИТ-продукта

Разработка ИТ-продукта – это длительный и трудоемкий процесс. В каждом проекте участвует большое количество специалистов. В небольших компаниях часто один менеджер отвечает сразу за несколько моментов, выполняя несколько ролей. В крупных корпорациях такое не приветствуется.

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

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

Стандартный список ролей

Аккаунт

Это «правая рука» заказчика. Именно аккаунт-менеджер является гарантом того, что фирма выполнит свои обязательства.

Задачи:

• развитие партнерских отношений между фирмой-исполнителем и заказчиком продукта;

• курирование команды, работающей над проектом;

• оперативное решение нестандартных ситуаций и вопросов между клиентом и командой или внутри команды;

• создание плана выполнения заказа;

• анализ рисков и гарант дедлайнов;

• документооборот по проекту.

Продакт

Менеджер продукта в команде. Он отвечает за продукт, поэтому может быть не особо осведомлен в том, как развивается проект и на каком он сейчас этапе. Зато о конечном продукте он должен знать все.

В его задачи входит:

• продумывание стратегии развития продукта;

• определение ЦА продукта, понимание ее болей;

• анализ рынка и стратегия продвижения продукта;

• знание особенностей продукта, его плюсов и особенностей;

• презентация продукта.

Проджект-менеджер

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

В его задачи входит:

• бюджет проекта;

• сбор требований по проекту и постановка целей по итогам анализа этих требований;

• делегирование задач;

• контроль за дедлайнами;

• общение с заказчиком по конкретным техническим задачам и нюансам ТЗ;

• распределение зон ответственности между ключевыми специалистами проекта;

• сбор и контроль метрических данных проекта.

Сейл

Проще говоря, это менеджер по продажам. Его основные задачи:

• найти клиента;

• произвести на него хорошее впечатление, убедить, что продукт или решение – именно то, что ему в данный момент необходимо и закроет его боли на все 100%;

• продать, то есть подписать контракт на поставку товаров и/или услуг.

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

Архитектор (Architect)

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

• составление конструкции программного обеспечения (ПО), элементов и их взаимосвязи;

• знание мировых практик разработки ПО и построение системы в зависимости от задач бизнеса, для которого она разрабатывается;

• проектирование архитектуры ПО;

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

Бизнес Аналитик (Business Analyst)

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

Задачи бизнес-аналитика на проекте:

• общение с заказчиком и выявление его желаний;

• выявление целей, для которых разрабатывается продукт, какие задачи он должен решать;

• предложение собственных идей по улучшению конечного продукта;

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

Системный аналитик (System Analyst)

Как правило, этот специалист работает в паре с бизнес-аналитиком, но в отличие от него обращает внимание не на то, как должна выглядеть и какие задачи решать система. Главное, что волнует системного аналитика – это то, как система должна работать в различных вариантах использования и какие у нее функции. Именно это детально описывает системный аналитик проекта.

Задачи системного аналитика включают в себя:

• анализ данных и метрик;

• принятие решений о том, какие именно методы использовать;

• составление технического задания (ТЗ);

• разработка и написание спецификации;

• составление списка требований к системе;

• функциональный анализ системы.

Технический писатель (Technical writer)

Без этого специалиста невозможен ни один проект, так как чаще всего именно технический писатель рассказывает о продукте и ведет его в массы.

Основными задачами такого специалиста становятся:

• написание инструкции по эксплуатации системы;

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

Проектировщик

Этот специалист нужен в проекте для построения макетов разрабатываемой системы. При этом он обязательно должен учитывать удобство ее использования клиентом.

Основные задачи проектировщика:

• создание панелей инструментов, меню и кнопок, которые были описаны в ТЗ;

• создание макета расположения графических элементов;

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

Дизайнер (Designer)

Этот специалист отвечает за оформление и внешний вид продукта. Именно он «рисует» все элементы продукта, которые видит заказчик в конечном варианте, подбирает цвета и формы.

Задачи дизайнера выглядят так:

• определение формы и цвета каждого элемента продукта, чтобы вместе они составляли единую картину;

• прорисовка графических элементов;

• отрисовка баннеров и логотипов для продукта;

• конечное оформление продукта.

Верстальщик (Web developer / Front end developer)

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

Задачи верстальщика:

• постановка правил, как браузер должен отобразить тот или иной элемент на web-странице;

• создание эффектов переходов и кликабельности;

• выравнивание текста.

Разработчик / Программист (Developer) (backend & frontend)

Этот специалист в команде занимается реализацией требований, которые ранее были прописаны аналитиками.

Задачи разработчика включают в себя:

• воплощение в жизнь функций, которые должна иметь система;

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

Тестировщик (Testing Engineer)

Именно он первым получает возможность запустить продукт и пользоваться им. Его основные задачи:

• выявление ошибок и недочетов в работе системы;

• давать фидбек по продукту.

Локализатор

Этот специалист часто участвует исключительно в международных проектах, то есть работает только с теми продуктами, которые будут распространяться не только в стране разработки, но и за рубежом.

В задачи локализатора входит:

• перевод всех слов и команд на другой язык, где планируется распространение и продажа продукта;

• контроль за внешним видом переведенного продукта.

Тимлид

Это управленец с техническими навыками. Такой специалист, как правило, требуется, если проект масштабный и техническое управление просто необходимо.

Задачи тимлида, обычно включают в себя:

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

• Принятие решений по вопросам стратегии разработки.

• Делегирование задач между специалистами. Контроль за дедлайнами.

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

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

В разработке продукта принимают участие большое количество человек, при этом у каждого из них свои задачи. Чтобы добиться эффективного взаимодействия между ними, важно правильно подобрать команду и ведущих специалистов, имеющих определенные hard и soft навыки. Только в таком случае можно добиться качественного и эффективного взаимодействия, продуктивной коммуникации внутри команды.

Важно обращать внимание на масштабы проекта, готовится ли он для распространения на зарубежном рынке.

Станислав Триерс

эксперт программы для студентов Moove от бизнес-школы «Сколково» и МТС, гендиректор компании Tess Technology

Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR.

На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.

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

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

Этапы создания ПО:

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

На каждом этапе должен быть свой отдел со своими задачами:

• проектный офис;
• отдел проектирования программного обеспечения;
• отдел тестирования и документирования;
• отдел разработки;
• отдел внедрения и сопровождения.

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

• менеджеры проекта;
• программисты;
• тестировщики;
• разработчики документации;
• инженерные психологи;
• технологи по разработке ПО.

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

• группа менеджмента и маркетинга продукта;
• специалисты по технической поддержке ПО;
• администраторы бета-тестирования.

По сути в любой команде, занимающейся разработкой продукта, можно выделить следующие роли в команде:

Developer

Занимается производством программных продуктов.

Это роль исполнителя: руководитель ставит задачу на автоматизацию того или иного процесса, разработчик ее выполняет. Эта роль часто сегментируется:

по разделению ответственности:

• Backend developer — разработчик программно-аппаратной части комплексного ПО;
• Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

по платформам:

• Web;
• Mobile;
• Server-Side;
• и так далее.

User Experience Designer (UX)

Занимается производством карт пользовательского опыта.

Этот человек изучает и оценивает, как пользователи относятся к разрабатываемому программному обеспечению. На нем лежит ответственность за то, чтобы продукт был прост в использовании, восприятии ценности, полезности и эффективности. Он продумывает и оценивает процессы и сценарии использования ПО.

Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Занимается производством графической составляющей интерфейсов.

Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.

Quality Assurance (QA)

Занимается проверкой результата.

QA занимается тестированием всего, как бы странно это ни звучало.

Системный подход специалиста QA позволяет тестировать как программный код, так и продуманность карт пользовательского опыта.

Human Resource (HR)

Занимается первичным подбором кандидатов.

Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

Отвечает за работу группы специалистов.

Team Leader обеспечивает комфортные условия работы коллектива и поддерживает высокий уровень эффективности команды. Этот человек не обязательно должен знать специфику работы команды досконально. Например, Team Leader в группе разработчиков не обязан быть программистом, ему достаточно понимать как организовать работу, понимать процессы, протекающие во время производства.

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.

Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

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

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

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

Технический писатель (Technical writer)

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

Разработка ИТ-продукта – это длительный и трудоемкий процесс. В каждом проекте участвует большое количество специалистов. В небольших компаниях часто один менеджер отвечает сразу за несколько моментов, выполняя несколько ролей. В крупных корпорациях такое не приветствуется.

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

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

Стандартный список ролей

Аккаунт

Это «правая рука» заказчика. Именно аккаунт-менеджер является гарантом того, что фирма выполнит свои обязательства.

Задачи:

• развитие партнерских отношений между фирмой-исполнителем и заказчиком продукта;

• курирование команды, работающей над проектом;

• оперативное решение нестандартных ситуаций и вопросов между клиентом и командой или внутри команды;

• создание плана выполнения заказа;

• анализ рисков и гарант дедлайнов;

• документооборот по проекту.

Продакт

Менеджер продукта в команде. Он отвечает за продукт, поэтому может быть не особо осведомлен в том, как развивается проект и на каком он сейчас этапе. Зато о конечном продукте он должен знать все.

В его задачи входит:

• продумывание стратегии развития продукта;

• определение ЦА продукта, понимание ее болей;

• анализ рынка и стратегия продвижения продукта;

• знание особенностей продукта, его плюсов и особенностей;

• презентация продукта.

Проджект-менеджер

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

В его задачи входит:

• бюджет проекта;

• сбор требований по проекту и постановка целей по итогам анализа этих требований;

• делегирование задач;

• контроль за дедлайнами;

• общение с заказчиком по конкретным техническим задачам и нюансам ТЗ;

• распределение зон ответственности между ключевыми специалистами проекта;

• сбор и контроль метрических данных проекта.

Сейл

Проще говоря, это менеджер по продажам. Его основные задачи:

• найти клиента;

• произвести на него хорошее впечатление, убедить, что продукт или решение – именно то, что ему в данный момент необходимо и закроет его боли на все 100%;

• продать, то есть подписать контракт на поставку товаров и/или услуг.

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

Архитектор (Architect)

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

• составление конструкции программного обеспечения (ПО), элементов и их взаимосвязи;

• знание мировых практик разработки ПО и построение системы в зависимости от задач бизнеса, для которого она разрабатывается;

• проектирование архитектуры ПО;

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

Бизнес Аналитик (Business Analyst)

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

Задачи бизнес-аналитика на проекте:

• общение с заказчиком и выявление его желаний;

• выявление целей, для которых разрабатывается продукт, какие задачи он должен решать;

• предложение собственных идей по улучшению конечного продукта;

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

Системный аналитик (System Analyst)

Как правило, этот специалист работает в паре с бизнес-аналитиком, но в отличие от него обращает внимание не на то, как должна выглядеть и какие задачи решать система. Главное, что волнует системного аналитика – это то, как система должна работать в различных вариантах использования и какие у нее функции. Именно это детально описывает системный аналитик проекта.

Задачи системного аналитика включают в себя:

• анализ данных и метрик;

• принятие решений о том, какие именно методы использовать;

• составление технического задания (ТЗ);

• разработка и написание спецификации;

• составление списка требований к системе;

• функциональный анализ системы.

Технический писатель (Technical writer)

Без этого специалиста невозможен ни один проект, так как чаще всего именно технический писатель рассказывает о продукте и ведет его в массы.

Основными задачами такого специалиста становятся:

• написание инструкции по эксплуатации системы;

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

Проектировщик

Этот специалист нужен в проекте для построения макетов разрабатываемой системы. При этом он обязательно должен учитывать удобство ее использования клиентом.

Основные задачи проектировщика:

• создание панелей инструментов, меню и кнопок, которые были описаны в ТЗ;

• создание макета расположения графических элементов;

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

Дизайнер (Designer)

Этот специалист отвечает за оформление и внешний вид продукта. Именно он «рисует» все элементы продукта, которые видит заказчик в конечном варианте, подбирает цвета и формы.

Задачи дизайнера выглядят так:

• определение формы и цвета каждого элемента продукта, чтобы вместе они составляли единую картину;

• прорисовка графических элементов;

• отрисовка баннеров и логотипов для продукта;

• конечное оформление продукта.

Верстальщик (Web developer / Front end developer)

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

Задачи верстальщика:

• постановка правил, как браузер должен отобразить тот или иной элемент на web-странице;

• создание эффектов переходов и кликабельности;

• выравнивание текста.

Разработчик / Программист (Developer) (backend & frontend)

Этот специалист в команде занимается реализацией требований, которые ранее были прописаны аналитиками.

Задачи разработчика включают в себя:

• воплощение в жизнь функций, которые должна иметь система;

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

Тестировщик (Testing Engineer)

Именно он первым получает возможность запустить продукт и пользоваться им. Его основные задачи:

• выявление ошибок и недочетов в работе системы;

• давать фидбек по продукту.

Локализатор

Этот специалист часто участвует исключительно в международных проектах, то есть работает только с теми продуктами, которые будут распространяться не только в стране разработки, но и за рубежом.

В задачи локализатора входит:

• перевод всех слов и команд на другой язык, где планируется распространение и продажа продукта;

• контроль за внешним видом переведенного продукта.

Тимлид

Это управленец с техническими навыками. Такой специалист, как правило, требуется, если проект масштабный и техническое управление просто необходимо.

Задачи тимлида, обычно включают в себя:

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

• Принятие решений по вопросам стратегии разработки.

• Делегирование задач между специалистами. Контроль за дедлайнами.

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

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

В разработке продукта принимают участие большое количество человек, при этом у каждого из них свои задачи. Чтобы добиться эффективного взаимодействия между ними, важно правильно подобрать команду и ведущих специалистов, имеющих определенные hard и soft навыки. Только в таком случае можно добиться качественного и эффективного взаимодействия, продуктивной коммуникации внутри команды.

Важно обращать внимание на масштабы проекта, готовится ли он для распространения на зарубежном рынке.

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

Менеджер продукта (Product Manager)

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

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

Менеджер проекта (Project Manager)

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

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

Простыми словами, продукт менеджер решает ЧТО сделать, проджект менеджер отвечает за КОГДА и КАК сделать.

Архитектор (Architect)

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

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

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

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

Бизнес Аналитик (Business Analyst)

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

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

Системный аналитик (System Analyst)

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

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

Технический писатель (Technical writer)

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

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

Проектировщик

Занимается построением макетов создаваемой системы с учетом удобства ее использования, превращает описанные в ТЗ функции в панели инструментов, кнопки, поля, таблицы и прочее, что видит и с чем взаимодействует пользователь. Результат его работы – макет, как правило черно-белый без графических элементов, который показывает расположение элементов интерфейса и возможные переходы между элементами и страницами (экранами) продукта. Пример макета ниже на картинке.

Дизайнер (Designer)

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

Простыми словами, дизайнер берет черно-белый макет проектировщика и заливает его красками. Пример такого макета ниже на картинке.

Верстальщик (Web developer / Front end developer)

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

Благодаря верстальщикам на сайтах появляются красивые эффекты нажатия на кнопку (и другие!), текст выровнен по правильному краю, а сайтом удобно пользоваться как с ноутбука, так и с мобильного телефона.

Ошибки в верстке случаются очень часто, кладезь для тестировщика 🙂

Разработчик / Программист (Developer)

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

Разработчик реализует написанные аналитиком требования. Его задача воплотить в жизнь все функции, которая должна уметь делать система.

Обычно разработчиков делят на Front end и Back End.

Front end – это внешний вид программы, с чем непосредственно взаимодействует пользователь. По факту Front end разработчик – это верстальщик,  о котором было написано ранее (п. 9).

Back end – это логика, которую не видит пользователь, но благодаря которой все функции системы выполняются верно. back end производит обработку пользовательской информации, полученной из front end, и возвращает front end’у результат в понятной форме.

Например, регистрация на сайте. Front end разработчик сделает красивую форму и разместит ее в нужное место на сайте. Back end разработчик реализует логику, по которой после заполнения полей и нажатия на кнопку “Регистрация”, данные о вашей учетной записи будут занесены в базу данных в правильные поля, а также сделает проверку, благодаря которой вы не сможете 2 раза зарегистрироваться в системе на один и тот же email.

Тестировщик (Testing Engineer)

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

Локализатор

Специалист, занимающийся адаптацией ПО к национальным особенностям страны (язык, менталитет). Роль актуальна, если ваш продукт будет распространяться не только в России, но и других странах. Важно не только перевести все слова и предложения, которые используются в вашем продукте на нужные языки, но и посмотреть как слова на разных языках впишутся в ваш интерфейс. Если на русском языке слово “утро” состоит из 4 букв, то на эстонском “hommikul”p 8 букв. Вдруг эти 8 букв не уместятся в вашем интерфейсе. Особенно надо быть внимательными с арабским языком (слева направо, а не справа налево), с иероглифами.

Заказчик (Customer)

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

Пользователи (Users)

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

Заинтересованные лица (Stakeholders)

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

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

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

Обычно роль объединяет родственные функции. Также принято обозначать роли их главными функциями. Продолжая только что приведенную иллюстрацию функций, выполняемых разработчиками проекта, укажем на следующие роли: кодировщик — действующее лицо, главной функцией которого является кодирование, аналитик — тот, кто занимается анализом требований. Подобную характеристику можно дать и тестировщику. Что же касается функции отладки, то в реальных проектах она обычно подразделяется на несколько видов: отладка компонентов, которой занимаются разработчики компонентов (например, те же кодировщики) и комплексная отладка, которая может поручаться специально выделенным сотрудникам или рассматриваться в качестве задачи группы разработчиков. Часто выполняются такие работы, как отладка спецификаций, декомпозиция проекта и др. Иными словами, функция отладки обычно не рассматривается как образующая роль, а распределяется по нескольким ролям в соответствии с принятой стратегией развития проекта.

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

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

Таким образом, в рамках любого проекта возникает задача повышения квалификации сотрудников. Для различных схем ведения проектов эта задача решается по-разному. Крайнюю точку зрения на проблему соответствия квалификации работников требованиям проекта отражает идея экстремального программирования
[
3
]
, когда используется неформальная организация группы исполнителей проекта без четкого распределения ролей, а значит, и обязательств сотрудников. В этом случае провозглашается принцип, когда каждый в группе делает то, что он умеет делать лучше всего. И хотя все функции, которые должны выполняться, остаются, создается впечатление, что в группе исполнителей проекта исчезают роли. В результате возможны пробелы в разработке, в частности при анализе и декомпозиции проектируемой системы. Чтобы этого избежать, разработчики должны понимать, какую абстрактную роль они исполняют в каждый конкретный момент, выполнение каких проектных функций необходимо сейчас, как связаны между собой работы, как должны распределяться ресурсы. Словом, они должны обращать внимание на выполнение распределенных по группе менеджерских функций. И даже в этом случае схему экстремального программирования можно рекомендовать лишь для слаженных групп исполнителей с высоким уровнем коллективной ответственности.

Функции, выполняемые разработчиками в проекте, подразделяются на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями. Часто неудачи проекта возникают из-за того, что менеджер не учитывает важность выполнения организационных функций. Так, обычно проектное задание фиксирует лишь то, что нужно предъявлять заказчику в качестве результатов. С точки зрения результатов просто не требуется знать, например, как организована передача проектных материалов между разработчиками, какая процедура отчетности предусматривается, но игнорирование задач реализации информационных потоков в проекте может привести к хаосу, что в конечном итоге отразится и на результатах.

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится непомерно велик (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня
[
30
]
). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.

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

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответственностью за выполняемые задания — так называемые проектные группы
[
44
]
. Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профессиональной подготовки, хотя и в разных областях индивидуальной специализации. Провозглашается равноправие членов группы и коллективная ответственность за выполняемые задания: проектная группа — команда равных. Все это позволяет сохранять внутри группы неформальные отношения.

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

Роли и ответственности участников типового проекта разработки ПО можно условно разделить на 5 групп:

1. АНАЛИЗ

Извлечение, документирование и сопровождение требований к продукту.

Группа анализа включает следующие роли:

· Бизнес-аналитик (построение модели предметной области)

· Бизнес-архитектор (разработка бизнес-концепции системы, определение общего видения продукта, его интерфейсы, поведение и ограничение)

· Системный аналитик (отвечает за перевод требований к продукту в функциональные требования к ПО)

· Специалист по требованиям (документирование и сопровождение требований к продукту)

· Менеджер продукта/функциональный заказчик (представляет интересы пользователей к продукту)

2. УПРАВЛЕНИЕ

Определение и управление производственными процессами.

Группа требования состоит из:

· Руководитель проекта (отвечает за достижение целей по срокам, бюджету и содержанию)

· Куратор проекта (оценка планов и исполнения проекта)

· Системный архитектор (разработка технической концепции системы, ключевых проектных решений)

· Руководитель группы тестирования (определяет цели, стратегию и управляет тестированием)

· Ответственный за управление изменениями, конфигурациями, за сборку и поставку программного продукта

3. ПРОИЗВОДСТВО

Проектирование и разработка ПО.

В производственную группу входят:

· Проектировщик (проектирование компонентов и подсистем в соответствии с общей архитектурой и разработка архитектурно-значимых модулей)

· Проектировщик баз данных

· Проектировщик интерфейса пользователя

· Разработчик (проектирование, реализация, отладка отдельных модулей).

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

4. ТЕСТИРОВАНИЕ

Тестирование ПО.

Группа тестирования в проекте состоит из ролей:

· Проектировщик тестов (разработка тестовых сценариев)

· Разработчик автоматизированных тестов

· Тестировщик (тестирование продукта, анализ и документирование)

5. ОБЕСПЕЧЕНИЕ

Производство дополнительных продуктов и услуг

Группа обеспечения, как правило, не входит в команду проекта, выполняет работу в рамках своей процессной деятельности. Сюда относятся следующие роли:

· Технический писатель (работа по ведению документации, написание инструкций и т.п.)

· Переводчик

· Дизайнер графического интерфейса

· Разработчик учебных курсов

· Тренер (обучение пользователей)

· Продажа и маркетинг (продвижение)

· Системный администратор

· Специалист по инструментальным средствам и др.

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

Один человек может исполнять несколько ролей. Возможно такое совмещение:

· Руководитель проекта + системный аналитик (системный архитектор)

· Системный архитектор + разработчик

· Системный аналитик + проектировщик тестов (+ технический писатель)

· Системный аналитик + проектировщик интерфейса пользователя

 
Имидж профессионалов IT сферы в массовой культуре кардинально изменился за последние годы. Абсурдные стереотипы ушли в прошлое, а программисты стали настоящей элитой 2010-х.

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

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

Наша команда включает в себя профессионалов с различными ролями, которые работают для получения лучшего решения, удовлетворяющего целям и требованиям клиента.

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

 
Бизнес-аналитик

Бизнес-аналитик вовлечен в проект с первой стадии, сразу после заключения сделки, а иногда даже до нее. Главная обязанность бизнес-аналитика заключается в коммуникации как с клиентом, так и с командой разработчиков.

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

Но между целями клиента и функциями приложения лежит целая пропасть. Следовательно, бизнес-аналитик (сокращенно БA) должен точно определить, что хочет заказчик и что ему нужно.

БA собирает требования клиента к желаемому продукту, анализирует то, как он должен выглядеть и какие функции нужно включить в разработку, а также зачем и как это должно быть сделано.

Бизнес-аналитик также проводит исследование конкурентов вместе со специалистами в области маркетинга для обеспечения устойчивости продукта на рынке и его конкурентоспособности с уже существующими продуктами.

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

Таким образом, роль бизнес-аналитика заключается в планировании оптимального процесса разработки, интерпретации требований заказчика, подготовке документации и осуществления эффективной коммуникации между клиентом и командой.

 
Менеджер проекта

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

Чтобы точнее объяснить роль PM, давайте рассмотрим его основные задачи. Как и бизнес-аналитик, менеджер проекта также может быть включен в коммуникацию с клиентом, однако главной задачей PM является работа непосредственно с командой разработчиков программного обеспечения.

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

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

 
UI/UX дизайнер

Это тот человек, от которого идет большая часть креативности в проекте. Главная ответственность UI/UX дизайнера заключается в создании приятного интерфейса и отличного пользовательского опыта.

Дизайнер использует вайрфреймы, созданные клиентом или бизнес-аналитиком, чтобы “нарисовать” мокапы и создать дизайн интерфейса мобильного приложения (UI) согласно действующим гайдлайнам и трендам. Он также планирует пользовательский опыт, который сделает продукт удобным для использования.

В Smartum Pro наши дизайнеры применяют InVision для создания динамических прототипов, которые отражают поведение и внешний вид будущего продукта, позволяя протестировать прототип на реальном устройстве до начала процесса разработки.

Клиенту удобно видеть модель приложения, а программистам прототип просто необходим, чтобы написать код. Это как дизайн-проект комнаты для профессионалов, которые будут её декорировать — необходимо видеть, что должно получиться в результате работы. Наши дизайнеры в Smartum Pro также предоставляют графические элементы для магазинов приложений, мокапы и логотипы.

 
Разработчики/программисты

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

Существуют различные уровни в команде разработчиков программного обеспечения, включающие junior, middle и senior уровни, которые зависят от опыта работы и уровня экспертизы.

Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Поэтому и существует такое “разнообразие” разработчиков, вовлеченных  в один проект. Например, стандартный проект разработки мобильного приложения требует участия как минимум Android, iOS и backend-разработчиков.

 
QA

QA (Quality Assurance) специалисты необходимы для каждого процесса разработки и обеспечения высокого качества продукта. Они тестируют его, проходят через все приложение и определяют баги и ошибки с последующим предоставлением отчета команде разработки, которая проводит их исправление.

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

 
Специалист по маркетингу

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

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

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

Суммируя все вышесказанное, стоит отметить то, что команда разработки программного обеспечения — это не только программисты.

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

Приветствую в это нелегкое время. Я продолжаю цикл статей для предпринимателей и несколько следующих хочу посвятить краеугольному камню любого IT проекта или продукта — команде.

Специфика IT

В отличие от многих сфер бизнеса, где “чем главнее, тем круче”, IT больше похож на медицину. Линейный разработчик, как и практикующий врач в частной клинике, может получать огромные деньги, значительно выше менеджмента.

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

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

Все эти аспекты необходимо будет учитывать как при формировании своей команды, так и при работе со сторонней компанией.

Структура команды

В IT очень много вариантов построения связей в командах, и нет единого правильного рецепта. Структура зависит от рынка, типа продукта, стадии его развития и многого другого. Кому-то необходимы собственные юристы, отделы продаж и поддержки, но есть и компании из 5ти человек, работающие с такими гигантами как Meta. Поэтому я решил выбрать наиболее популярный тип продукта — облачный сервис, имеющий сайт и мобильное приложение. Также сделаю допущение, что продажи автоматизированы. Тогда мы получим следующую верхнеуровневую структуру.

Во главе продукта стоит Product manager или Product owner. Разница есть, но для нас она не существенная. Он работает с рынком, общается с пользователями и инвесторами, определяет вектор развития продукта, генерирует гипотезы и пользовательские истории, приоритезирует их и много другое. Если упростить, он на основе данных решает, какие потребности и в каком порядке необходимо закрыть.

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

Marketing team отвечает за позиционирование продукта и привлечение пользователей. Support team — команда клиентской поддержки, отвечающая на вопросы пользователей. На старте продукта вам будет достаточно одного маркетолога, а клиентской поддержкой могут заниматься продакт и проджект менеджеры, получая при этом очень ценную обратную связь. Поэтому я не буду разбирать эти направления и сконцентрируюсь на команде разработки.

Development team

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

Project manager

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

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

Analysts

Аналитики бывают разные: бизнес-аналитики общего профиля; аналитики, специализирующиеся на конкретной области(логистике, медицине, …) и системные аналитики, чья деятельность подразумевает наличие компетенций разработчика и архитектора.

Бизнес-аналитики составляют бОльшую часть всех аналитиков в рамках стартапов, поэтому разберу именно их. Компетенции БА я разделяю на две больших области: продуктовая аналитика и формирование требований.

О продуктовой аналитике, которую необходимо провести до начала реализации, я писал в прошлых двух статьях: Есть идея IT-продукта. Что делать дальше? и Зачем нужен MVP. Помимо описанных там анализа ЦА, конкурентов и рынка, проведения проблемных и решенческих интервью, арсенал продуктового аналитика включает в себя большой спектр инструментов, позволяющих находить точки роста. Итогом этой части работы становятся пользовательские истории — формулировки вида “как покупатель, я хочу фильтровать товары, чтобы выбирать только среди релевантных” с различными дополнениями и ограничениями вроде названий фильтров или максимально рентабельной стоимости разработки. Это своего рода условия задачи.

Когда пользовательские истории сформированы, то есть понятно, какие потребности нужно закрыть, аналитик переходит к поиску решений. Использовать сторонний сервис или реализовать самим, делать эффективнее, но дороже и дольше или упростить, уменьшив стоимость и сроки и тд. Определив вариант реализации, проконсультировавшись с лидами других направлений, он приступает к его проработке: детализирует требования, проверяет их на полноту(все аспекты учтены) и непротиворечивость с уже реализованным функционалом. В итоге получается ТЗ.

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

Leads

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

Лиды определяют “правила игры” в своем отделе: какие инструменты, подходы, технологии и тд будут использоваться. Если каждый сотрудник в направлении будет делать по-своему, об эффективности можно забыть.

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

Designers

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

Работу дизайнера можно условно разделить на 3 части:

Tech Lead

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

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

Принцип работы приложений

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

Клиент — веб или мобильное приложение — эта та часть, которую видит пользователь. Например, пользователь интернет-магазина, находясь в разделе кроссовки, выбрал в фильтре по бренду Nike. Тогда клиент посылает запрос на сервер, говоря “пришли мне все кроссовки Nike”. Сервер получает и обрабатывает этот запрос: команда проекта заранее определила, что пользователям должны показывать только товары, которые есть в наличии. Сервер обращается к базе данных, которая формально может быть как на этом, так и на другом сервере: “пришли мне все кроссовки с брендом Nike, которые есть в наличии”. В ответ сервер получает список товаров, но, если отправить все сразу, страница у пользователя может грузиться очень долго. Поэтому на сервере товары дробятся на страницы, а на клиент приходит ответ: “Всего нашлось 147 товаров, я разделил их на 8 страниц по 20 товаров, держи первые 20”. В итоге у пользователя отображаются первые 20 кроссовок Nike.

Большое приложение может иметь множество серверов и баз данных, но описанные выше принципы будут неизменны.

Front-end developers

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

В процессе работы он больше всего взаимодействует с дизайнерами по вопросу макетов и с серверными разработчиками(back-end developers) по обмену данными.

Mobile developers

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

Мобильных разработчиков по используемым технологиям можно разделить на нативных и кроссплатформенных. Первые пишут приложения для конкретной ОС(iOS или Android), вторые сразу под обе.

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

Back-end developers

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

QA

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

Итоговая цель любого тестировщика — обеспечить высокое качество продукта.

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

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

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

Заключение

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

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