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

И заодно покажем, сколько людей вовлечено в этот процесс.

Команда разработки

Команда — это минимальная единица в ИТ-компании, разрабатывающая продукт.

Есть множество способов собрать и организовать команду, но хороший подход предложил основатель Amazon Джефф Безос. Он называется «Правило двух пицц»:

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

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

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

Иногда функциональность микроскопическая

В крупных компаниях уровня Google и Amazon команда может разрабатывать и поддерживать одну кнопку.

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

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

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

• бэкенд-разработчик;
• фронтенд-разработчик;
• тимлид;
• тестировщик;
• дизайнер;
• продакт-менеджер;
• проджект-менеджер.

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

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

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

Суть роли: придумывает идеи.

Продакт-менеджер общается с руководством компании, узнаёт его приоритеты и пожелания и превращает их в идеи по развитию продукта.

Например, в книжном интернет-магазине:

Хотим увеличить выручку в следующем квартале на 5% → Давайте будем показывать пользователям, что заказывают их друзья. Возможно, пользователи тоже решат заказать.

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

Ещё у продакта хорошая насмотренность: он видит, как похожие проблемы решают конкуренты и может адаптировать их идеи. Как, например, было с форматом «сторис»: эту продуктовую механику придумали в компании Snapchat в 2013 году. Другие компании начали её заимствовать, и сейчас она есть почти везде, даже в банковских приложениях.

Тимлид

Суть роли: оценивает возможность воплощения идеи.

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

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

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

Обдумывая ответ, тимлид оценил:

• Технологии, которые сейчас есть в проекте, к игре неприменимы. Нужен новый API на бэкенде и библиотеки для обработки графики на фронтенде.
• Навыки команды: с библиотеками никто не работал. Потребуется время на обучение или нужно нанять дополнительных людей.
• Технический контекст: недавно DevOps начали переезд на новую инфраструктуру и предупреждали, что возможны сбои. Это тоже риск.
• Сложность задачи: создавать новое всегда сложнее, чем дополнять старое. Нужно заложить больше времени на поиск багов.

И многое другое.

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

А затем оценит их код и даст советы, что можно улучшить. Плюс он проводит с ними созвоны one-to-one — это специальный формат, когда у разработчика есть час наедине с тимлидом и разработчик сам решает, как его провести.

Можно обсудить технические новинки, поговорить про хобби и жизнь или поругаться на отдел маркетинга, который «опять дотянул до талого с рождественским промо, и теперь нам всё в последний момент делать». В общем, играет и психотерапевтическую роль.

Забавный факт

Произносить one-to-one неудобно, поэтому появились альтернативные названия.

Например, такую встречу для краткости могут назвать 121 — по созвучию to и two: «Закинь 121 в календарь, плз, на чт».

Есть более жаргонный вариант — «выйти раз на раз»: «Го в чт выскочим раз на раз?» Если вам будут такое предлагать — не пугайтесь. Скорее всего, это будет милая беседа.

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

Суть роли: следит за сроками.

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

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

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

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

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

Дизайнер

Суть роли: создаёт удобные визуальные интерфейсы (UI/UX).

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

Дизайнеру нужно продумать массу вещей:

• Откуда придёт пользователь? Какой у него опыт?
• Как Х должна отображаться на разных экранах — на компьютерах, планшетах, мобилках?
• Как будет выглядеть X в случае ошибки?
• А если пользователю недоступно это действие?
• А если пользователь не залогинен?
• Как будет выглядеть X на ночной теме?

И так далее.

Результат решений дизайнера — макет, с которым уже работает остальная команда.

В крупных компаниях существуют свои дизайн-системы: то есть уже готовые компоненты вроде кнопок, карточек, иконок, полей ввода, типографики. Если задача «типовая», то дизайнер собирает макет из них. Если неординарная — создаёт новые компоненты.

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

Бэкенд-разработчик

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

В современной веб-разработке бэкенд чаще всего пишут на таких языках программирования, как Python или JavaScript (Node.js). Раньше писали на PHP и Ruby (с фреймворком Ruby on Rails), но они теряют популярность.

Почему?

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

Фронтенд-разработчик

Суть роли: воплощает визуальные интерфейсы.

Фронтендер получает макет от дизайнера и превращает его в работающий продукт с помощью HTML, CSS и JavaScript. Разумеется, тут никуда без бэкендера: сердце-то системы создаёт он. Но взаимодействовать пользователи будут с результатом работы фронтендера.

Поэтому основные шишки получит он.

В среде разработчиков отношение к фронтендерам часто снисходительное: мол, решают какие-то косметические задачки, в то время как настоящие хардкорщики... Но это не так.

Ведь это нетривиальная задача — обеспечить одинаковый опыт для пользователя, когда он может зайти на сайт с четырёх-пяти разных браузеров (Chrome, Safari, Opera, Firefox, Yandex и так далее) и с трёх возможных устройств (планшет, мобилка, десктоп).

Причём если речь про мобилки, то там существует целый зоопарк Android-устройств с разными соотношениями экранов и со своими мобильными версиями браузера. А у каждого браузера — своя спецификация. Какая-то функциональность может работать в Chrome, но не работать в Opera для мобилок. В общем, фронтендерам скучать не приходится.

В современности немногие фронтендеры работают с чистыми HTML, CSS и JavaScript — чаще используют специальные фреймворки: React, Vue или Angular. Они ускоряют разработку, но требуют дополнительных знаний. Тут мы углубляться не будем, это информация чисто для общего развития.

Тестировщик

Суть роли: защищает пользователей от багов.

Когда идея продакт-менеджера уже реализована, но ещё не опубликована, в игру вступает тестировщик. Его задача — пройти путь пользователя и проверить, всё ли работает корректно.

Он проверяет работу и бэкендера (API), и фронтендера (запросы к API, вёрстку). Если находит ошибку (баг), то заводит задачу на её устранение.

Тестирование бывает ручным и автоматизированным.

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

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

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

---

Отлично, с членами команды разобрались. Теперь давайте посмотрим, как обычно происходит сама разработка.

Процесс разработки

В один прекрасный день продакт-менеджер возвращается от руководства и говорит: «Ребята, мы запускаем новый продукт. Нам нужно разработать сайт, который делает „вау“, а ещё показывает картинки с котиками».

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

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

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

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

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

Когда в команде закончат спорить об архитектуре и стеке, нужно будет понять: а что, собственно, делать? Ведь для «вау» надо как минимум уметь авторизовывать пользователя, а для показа картинок с котиками надо эти картинки откуда-то брать.

А ещё хоть у нас и сайт, но всё равно надо написать много кода, а также сделать симпатичные странички, ведь на некрасивый сайт никто ходить не будет. Разделение большой задачи на простые и маленькие (например, «сделать окно логина пользователя», «написать логику подбора картинок с котиками») называется декомпозицией. Как вы уже поняли, это задача для тимлида.

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

Предположим, наша команда, как и подавляющая часть ИТ-команд по всему миру, работает по связке Scrum + Agile. Это методологии гибкого управления проектами, главная цель которых — достижение конкретного результата за короткие промежутки времени. Это даёт возможность адаптироваться к изменениям и проблемам, возникающим на пути реализации проекта.

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

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

Во время планирования диалог будет примерно таким:

— Нам надо создать минимальный прототип сайта за этот спринт.

— Я могу взять главную страницу с разделами!

— А я сделаю показ котиков, но там будет всего две картинки, больше не успеем…

— Тогда давайте я пока подготовлю систему управления картинками.

— Отлично, должны успеть за спринт!

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

Они как-то связаны с юмором?

Нет, просто название совпало.

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

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

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

В список задач добавляют две новые: «починить ошибки в модуле с котиками» и «разобрать ошибки в модуле управления».

Наступает следующая неделя, снова планируется спринт, снова распределяются задачи. Вдруг разработчик, отвечающий за картинки с котиками, говорит: «Мне для тестов надо несколько серверов с настроенным [дальше что-то на программистском]».

Этот запрос уходит к важному человеку — DevOps.

Расшифровывается это как «оперирование разработки», и это специальные люди, которые занимаются всеми сопутствующими разработке задачами — от подготовки окружения (настройки репозиториев и управления сервисами, где позднее будет размещён код) до настройки CI/CD.

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

CI/CD — это часть инфраструктуры. Расшифровывается как «непрерывная интеграция и деплой». Это специальная автоматика, которая собирает воедино разные части кода и запускает сайт либо в тестовом режиме, либо в финальном, предназначенном для клиентов (он называется production).

У CI/CD много задач: она информирует разработчиков, если изменения, внесённые ими локально, на их компьютерах, ломают проект.
Также позволяет тестировщикам видеть последнюю актуальную рабочую копию проекта, продакту — смотреть, как сейчас выглядит сайт, и показывать его руководству.

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

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

Выглядит это так:

• Разработчики написали код.
• Отправили изменения в репозиторий.
• CI/CD активизировалась и собрала сайт в тестовом режиме.
• Тестировщики открывают сайт и приступают к работе.

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

Тогда приходит тестировщик-автоматизатор. Он настраивает систему так, что при каждом запуске CI/CD код прогоняется через автоматические тесты. И если не проходит их, то новая версия сайта не собирается, а разработчики получают уведомление и быстро исправляют ошибку.

Но мало того, оказывается, модули сайта, отвечающие за «вау» и за котиков, регулярно ломают друг друга при обновлениях, и с этим надо что-то делать. Тогда DevOps при поддержке разработчиков добавляет тесты, которые проверяют, что будет при обновлении, а заодно — заработают ли вместе текущая версия котиков и «вау». Это называется интеграционное тестирование, оно проходит сразу после автоматического.

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

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

Тимлид вздыхает, беззвучно ругается, но быстро приходит в себя и говорит: «Конечно можем». И идёт рассказывать о новостях разработчикам — чтобы им было что обсудить на one-to-one.

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

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

До одного прекрасного дня, когда оказывается, что на тестовых серверах кончилось место под фото котиков. А надо больше, потому что их никогда не бывает достаточно. Наша команда заказывает у админов больше дисков на сервера, но просто так добавить их нельзя, ведь это затронет и соседние отделы.

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

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

Так или иначе, новые диски поставили в сервера, и команда успешно завершила проект, сделав классный сайт с фото котиков, которые можно свайпать, и с функционалом «вау», который хотел заказчик.

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

Методологии разработки

Выше мы уже упомянули, что наша команда работает по Agile + Scrum. Это не единственная методология, есть ещё парочка популярных.

Например, канбан.

Он может быть совмещён с Agile, а может быть и самостоятельным. Все задачи в этом подходе представлены карточками, они группируются по текущему статусу. Самая простая визуализация — это бумажки-стикеры, на которых написана задача, приклеенные в углу доски с надписью «Новые задачи».

Когда разработчик берёт такую задачу, он переносит стикер в угол «В работе», а когда задача готова — в угол «Надо протестировать». В итоге все участники видят, что происходит на проекте. Если надо взять новую задачу, достаточно посмотреть в угол с новыми. Если надо понять, что сейчас в работе, — в угол с соответствующим названием. А тестировщики просто берут стикеры из угла «Надо протестировать».

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

Проще всего эту модель сравнить со строительством небоскрёба. Есть план, заливаем фундамент, ставим каркас здания, воздвигаем стены, создаём инфраструктуру, потом отделка. И вы точно не предполагаете, что посередине строительства небоскрёба кто-то придёт и скажет: «А давайте лучше дачные домики поставим».

Вот и всё! Мы постарались собрать все самые часто встречающиеся ИТ-практики. Теперь вы знаете (в общих чертах), как разрабатываются продукты, которыми вы пользуетесь.

Для удобства мы собрали понятия из этого параграфа:

• Планирование архитектуры — сумма решений о том, из чего и как именно будет состоять проект.
• Стек — набор технологий и подходов, используемых в проекте.
• Декомпозиция — разбиение задач или большой функциональности на меньшие задачи.
• Agile — гибкая методология управления проектом, которая предполагает постоянную готовность к изменениям и неожиданным сложностям.
• Scrum — гибкая методология разработки, суть которой — в делении работы на спринты, по итогу каждого из которых происходят заметные улучшения продукта.
• Спринт — отрезок времени (обычно кратный неделе или нескольким неделям), за который команда реализует задачи.
• Планирование — оценка и распределение задач на спринт в начале спринта.
• Стендап — ежедневные встречи команды, которые помогают участникам проще синхронизировать свои действия.
• CI/CD — автоматизированная система сборки проекта.
• DevOps — и специалист, и процесс, которые помогают разработчикам настраивать инфраструктуру: от подготовки тестовых окружений до настройки автоматизации.
• Тестирование — процесс проверки продукта.
• ITSM/ITIL — набор принципов управления ИТ-инфраструктурой и их изменениями.
• Канбан — очевидная для каждого из участников методология разработки, по которой задачи заносятся в таблицу, где каждый столбец подписан в соответствии со статусом: «Новые задачи», «В работе», «Надо протестировать» и т. д.
• Waterfall — модель разработки, состоящая из циклов, последовательность которых не подлежит изменению.

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