Старт в IT: Команда разработки

Отодвинем в сторонку подготовку и обучение, поговорим об этом как-нибудь в другой раз.

Сейчас мне бы хотелось рассказать, что такое "команда разработки".

Итак, если ты готов пробовать свои силы и приступить к практике, то есть 2 основных пути:

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

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

Второй случай не так однозначен, но, если задуматься, то и тогда у тебя по факту "команда" как минимум из 2х человек: бизнес-заказчик и ты (человек-оркестр).

Что означает команда разработки

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

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

А теперь обсудим незнакомые слова и нюансы:

• Зона ответственности: Есть команды, которые отвечают за часть функционала "программы" (например, авторизация в Интернет-банке). Есть команды, которые отвечают за всю "программу" (например, команда Сайта, команда Интернет-банка). Есть команды, которые отвечают за перечень сервисов (например, сервисы по работе с Порталом госуслуг). Есть "продуктовые" команды, которые отвечают за процессы (флоу) и, соотвественно, за корректную обработку этих процессов в нескольких программах и сервисах (например, Выдача кредита, Оформление на работу). А есть целые команды "по ролям": отдельные команды фронта (frontend-разработка), команды бэка (backend-разработка) и так далее. Какие типы команд есть в компании - зависит от самой организации, нет единых требований, у каждого руководство может быть свое видение как эффективнее работать. При попадании в новую команду обязательно уточняйте этот вопрос, чтобы понимать, что делает ваша команда, а по каким вопросам надо просить "соседей" (другую команду).
• Количество человек: оно может быть абсолютно любым, хоть 50 (теоретически), но обычно все же рекомендуют не более 9 - 10 человек. Если проект большой, то состав разбивают на несколько команд, у каждой команды свой "начальник" и есть "центр координации всех команд". Почему не рекомендуют большие команды - потому что теряется управляемость (надо же всем давать задания и контролировать, а начальник тоже человек и хочет иногда спать:-) ); сильно увеличивается время на согласование (чем больше команда, тем дольше идут совещания). Минимальный состав команды = 2 человека, все же 1 человек - это не команда.
• Регулярность взаимодействия: если следовать концепции Agile (о нем мы поговорим отдельно), то команда должна созваниваться каждый рабочий день и по-быстрому рассказывать друг другу: что удалось сделать вчера, с какими проблемами столкнулся, чем команда может помочь и что планируешь делать сегодня - это называют дейлик (в до Agile-овские времена называли 15-минуткой). А также есть созвоны 1-2 раза в неделю по конкретной задаче. Если же это небольшой, не срочный проект, то регулярность общения может быть гораздо реже: 1 раз в неделю, 1 раз в спринт (2 недели) и так далее. Опять же все зависит от проекта, руководства, могут потребовать хоть каждый час быть на созвоне.
• Типы взаимодействия: личные встречи (обычно в офисе), созвоны (удаленная работа или когда часть членов команды работают в разных городах), чаты, письма.
• Командный дух: в идеальном мире вся команда нацелена на результат, общается дружелюбно и конструктивно, но жизнь обычно далека от идеала. Приходится с каждым искать свой стиль общений, способы мотивации, аргументы, чтобы тебя услышали. Это не плохо и не хорошо. Это нужно принять как факт - все мы разные и каждому нужен свой подход, и к тебе тоже :-). Поэтому будь готов к тому, что кто-то работает продуктивно, делает задачи в срок; кто-то делает вид, что работает, затягивает сроки; кто-то любит спорить и ругаться; кто-то постоянно думает о чем-то своем и уводит разговор в сторону. Если ты новичок в команде - сначала потрать свой драгоценный ресурс и присмотрись к коллегам, сделай выводы, учись эффективно (для тебя и твоих целей) взаимодействовать с каждым.

Под "программой" подразумевается отдельно существующая автоматизированная система (например, Сайт, 1С-бухгалтерия и так далее).

Виды задач для команды разработки

• Новая "фича": (разработческий сленг) или feature - это новый функционал, от новой кнопки на экране (мелкая фича) до чего-то масштабного (новый раздел на сайте, возможность подать заявку и т.д.).
• Исправление ошибок: ошибки могут возникать по-разным причинам. Например, ваша команда плохо протестировала исправленный функционал, и допущенная разработчиками ошибка дошла до пользователей вашей "программы". А может быть другая команда изменила общую библиотеку, которую вы используете, и вовремя вас не предупредила о необходимости все перепроверить. Может быть сервис, которым вы пользовались (например, узнать курс валют, чтобы отобразить на странице вашего сайта), перестал работать, и стала появляться ошибка. В любом случае, кто бы ни был виновен, вам надо найти причину ошибку (потому что это ваш процесс пострадал, никто не будет сам по себе бегать и исправлять ошибки чужого флоу) и, либо ее исправить самим, либо согласовать, чтобы исправили "соседи", либо адаптировать свой функционал под новые реалии (например, использовать другой сервис по получению курса валют).
• Рефакторинг: это переписывание части кода вашей "программы" с целью: увеличить скорость обработки запроса, применить другую версию библиотеки (например, в старой версии найдены уязвимости), чтобы сделать метод более универсальным или, наоборот, адаптировать под конкретную задачу. Причин может быть много, суть работ одна - новый функционал вы не получите, но старый код станет больше соответствовать вашим изменившимся требованиям или требованиям безопасников в вашей организации.

Надеюсь, с самим определением что есть "команда разработки" мы разобрались. Теперь давайте обсудим "роли в команде разработке".

Роли

Роль - это не должность, это перечень действий, которые выполняет сотрудник в своей деятельности, и которые можно отнести к той или иной роли. Иногда 1 член команды выполняет 1 или 2 роли, бывают специалисты из разряда "человек-оркестр" - когда один член команды выполняет очень много ролей.

Ниже под "продуктом" имеется в виду один из двух вариантов:

- автоматизированная система и весь перечень услуг, которые она предоставляет (например, Портал госуслуг и команда, соответственно, отвечает за весь продукт, за всю автоматизированную систему).

- конкретный перечень услуг пользователям/клиентам, которые могут предоставляются через разные "программы" (например, услуга записи к врачу - через Сайт или Мобильное приложение для Android. Чтобы оказать услугу пользователю, запрос на услугу должен пройти обработку в нескольких системах и команда, соответственно, отвечает за перечень услуг, а не за конкретную автоматизированную систему).

В команде не все роли есть обязательно должно быть (например, часто бизнес не считают частью команды разработки, частью проекта - да, но не разработки; в этом случае в команде разработке будут только "технические" специалисты).

Итак какие основные роли бывают:

• Владелец продукта (Бизнес-руководитель): это тот, кто приходит с идеей новой фичи, финансовым эффектом от нее, сроками и бюджетом на разработку. Раньше таких людей называли "стейкхолдеры" (владельцы продукта).
• Дизайнер: прорисовывает макеты пользовательского интерфейса согласно принятым в компании стилям и предоставляет frontend-разработчикам свойства элементов для дальнейшей верстки страницы. Дизайнер начинает свою работу по задаче от бизнеса.
• Бизнес-аналитик: тот, кто описывает подробно бизнес-требования к новой фиче или изменению старого функционала. Глубина описания может быть очень разной (зависит от договоренностей в команде и уровне компетенций аналитика). Это могут быть простые описания User Stories (краткое описание с позиции пользователя). Могут быть достаточно подробные - с макетами согласованного дизайна, диаграммой последовательностей шагов пользователя или этапов обработки и другой информации. В небольших командах эту роль выполняет Владелец продукта. Подразумевается, что Бизнес-аналитик не обязан знать техническую сторону вопроса. Какие доработки и в каких автоматизированных системах нужны для выполнения требования, названия сервисов, методов, какой язык программирования или протокол используется - эти знания относят роли системного аналитика, читай ниже.
• IT-лид: это технический руководитель команды разработки, можно примерно приравнять его к начальнику отдела. Разработчики, тестировщики, системные аналитики (все технические специалисты в команде, бизнес в них не входит) - это его ресурсы, которыми он управляет. IT-лид проверяет, что состав команды оптимальный, все выполняют задания качественно и в срок, помогает решать проблемы с доступом к ресурсам компании, участвует в оценке срока выполнения задач, декомпозиции (разбивка задачи на этапы) и планировании их выполнения, приходит с техническими задачами по ошибкам и рефакторингу.
• Team-лид: тоже руководящая роль. Обычно это старший и наиболее опытный разработчик по конкретному направлению, который проверяет код (ревью кода) группы разработчиков, помогает им, подсказывает, распределяет задачи. Бывают Тимлиды бэка (максимум - 1 на команду разработки), Тимлиды фронта (максимум - 1 на команду разработки), Тимлиды тестирования (максимум - 1 на команду разработки) и так далее. Все задачи на группу разработчиков проходят через Team-лида, он назначает ответственных, участвует в согласовании сроков и архитектуры решения. Бывают группы разработчиков без тимлидов, тогда они получают задачи напрямую от системных аналитиков.
• Системный аналитик: технический специалист, на основе бизнес-требований пишет технические Постановки задач на разработку, спецификации, UML-диаграммы, техническую документацию. Системный аналитик должен знать текущую архитектуру проекта, участвовать в обсуждениях по ее изменению, знать перечень автоматизированных систем и сервисов, которые влияют на подответственные команде процессы.
• Архитектор: вместе с IT-лидами, Team-лидами, системными аналитиками принимает решение о разработке новых сервисов, микросервисов, схем взаимодействий между ними. Часто он в команде не на 100%, а работает с несколькими командами, иногда он один на всю компанию. Новая задача далеко не всегда требует изменений текущей архитектуры.
• Разработчик: программист, получающий от системного аналитика Постановку задачи с техническим описанием доработки. Часто бывают команды, когда разработчику в задаче передают только бизнес-требования и этап системного анализа, разработку технической документации он выполняет сам, без системного аналитика. Но все же основная задача разработчика - написать код, тесты на одном или нескольких языках программирования, использовать готовые фреймворки. Различают frontend- и backend-разработчиков, разработчиков баз данных (основные группы, бывают и другие).
• Тестировщик: тестирует измененный функционал по Постановке задачи, разрабатывает новые тесты.
• Релиз-менеджер: обновляет систему/сервис на стенде (тестовый стенд, ПРОД и другие) либо для тестирования, либо для предоставления нового функционала пользователям.
• Девопс-инженер: настраивает сервера, сетевую инфраструктуру и другое программное и аппаратное обеспечение для корректной работы систем/сервиса.

Пример небольшой команды

Зона ответственности: Выдача и продление медицинских полюсов на Сайте больницы.

1. Владелец продукта = 0,5 человек/месяц (в этой команде работает только 1/2 часть своего времени)
2. Бизнес-аналитик = 1 человек/месяц
3. Системный аналитик = 1 человек/месяц
4. Backend-разработчики = 2 человек/месяц
5. Frontend-разработчик = 1 человек/месяц
6. Тестировщики = 2 человек/месяц
7. Релиз-менеджер = 0,5 человек/месяц (в этой команде работает только 1/2 часть своего времени)

Итого численность команды (постоянной ее части) = 8 человек.

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

Подводим итоги

Если ты пришел в новую команду:

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

Другие статьи:

• Старт в IT: Разбираемся вместе. Ты все сможешь!

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