Не только разработчики: типичная структура компании по разработке ПО
Архитектор, системный аналитик, техлид и не только — разбираем, какие роли существуют в командах разработки и чем они занимаются.
Лучше всего рассматривать структуру команды в компаниях от 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
Отвечает за грамотный аргументированный выбор технических решений:
- Ответственный выбор стороннего ПО для проекта;
- Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
- Определение технических особенностей в процессах производства.
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)
Специалист, который занимается составлением документации в рамках разработки различных программ. Это люди, которые призваны помогать нам овладевать новыми технологиями, будь то модное устройство или новая программа. От них отчасти зависит успех новинки, ведь именно им нужно убедить потенциального покупателя в пользе этой новинки и объяснить, как ей пользоваться.