---

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

В Blue мы используем собственные продукты.

Это означает, что мы используем Blue для создания Blue.

Этот странно звучащий термин, часто называемый "dogfooding", обычно приписывается Полу Маритцу, менеджеру в Microsoft в 1980-х годах. Сообщается, что он отправил электронное письмо с темой "Едим собственную собачью еду", чтобы побудить сотрудников Microsoft использовать продукты компании.

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

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

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

Мы уже говорили о том, почему у нас нет выделенной команды тестирования, и это еще одна причина.

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

Этот подход демонстрирует нашу приверженность продукту. Полагаясь на Blue, мы показываем нашим клиентам, что мы действительно верим в то, что создаем. Это не просто продукт, который мы продаем – это инструмент, от которого мы зависим каждый день.

Основной процесс

У нас есть один проект в Blue, aptly названный "Продукт".

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

Каждая запись – это функция или часть функции. Так мы переходим от "не было бы здорово, если бы..." к "посмотрите на эту потрясающую новую функцию!"

Проект имеет следующие списки:

• Идеи/Обратная связь: Это список идей команды или обратной связи от клиентов на основе звонков или обмена электронными письмами. Не стесняйтесь добавлять сюда любые идеи! В этом списке мы еще не решили, что будем разрабатывать какие-либо из этих функций, но мы регулярно просматриваем его на предмет идей, которые хотим исследовать дальше.
• Бэклог (долгосрочный): Это место, куда попадают функции из списка Идей/Обратной связи, если мы решим, что они будут хорошим дополнением к Blue.
• {Текущий квартал}: Обычно структурируется как "Qx YYYY" и показывает наши приоритеты на квартал.
• Ошибки: Это список известных ошибок, сообщенных командой или клиентами. Ошибки, добавленные сюда, автоматически получат тег "Ошибка".
• Спецификации: Эти функции в настоящее время специфицируются. Не каждая функция требует спецификации или дизайна; это зависит от ожидаемого размера функции и уровня уверенности, который у нас есть в отношении крайних случаев и сложности.
• Дизайнерский бэклог: Это бэклог для дизайнеров, каждый раз, когда они завершают что-то в процессе, они могут выбрать любой элемент из этого списка.
• Дизайн в процессе: Это текущие функции, которые дизайнеры разрабатывают.
• Обзор дизайна: Это место, где находятся функции, чьи дизайны в настоящее время рассматриваются.
• Бэклог (краткосрочный): Это список функций, над которыми мы, вероятно, начнем работать в ближайшие несколько недель. Здесь происходят назначения. Генеральный директор и руководитель инженерного отдела решают, какие функции назначить какому инженеру, основываясь на предыдущем опыте и нагрузке. Члены команды могут затем перенести их в "В процессе", как только они завершат свою текущую работу.
• В процессе: Это функции, которые в настоящее время разрабатываются.
• Обзор кода: Как только функция завершает разработку, она проходит обзор кода. Затем она либо возвращается в "В процессе", если нужны корректировки, либо разворачивается в среде разработки.
• Разработка: Это все функции, которые в настоящее время находятся в среде разработки. Другие члены команды и определенные клиенты могут их просматривать.
• Бета: Это все функции, которые в настоящее время находятся в бета-среде. Многие клиенты используют это как свою ежедневную платформу Blue и также предоставляют обратную связь.
• Производство: Когда функция достигает производства, она считается завершенной.

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

Теги

• Мобильный: Это означает, что функция специфична для наших приложений iOS, Android или iPad.
• {ИмяКорпоративногоКлиента}: Функция специально разрабатывается для корпоративного клиента. Отслеживание важно, так как обычно для каждой функции существуют дополнительные коммерческие соглашения.
• Ошибка: Это означает, что это ошибка, которую необходимо исправить.
• Ускоренный: Это означает, что это изменение с ускоренной обработкой, которое не должно проходить полный цикл выпуска, как описано выше.
• Основной: Это крупная разработка функции. Обычно это резервируется для крупных инфраструктурных работ, больших обновлений зависимостей и значительных новых модулей в Blue.
• ИИ: Эта функция содержит компонент искусственного интеллекта.
• Безопасность: Это означает, что необходимо проверить вопрос безопасности или требуется патч.

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

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

Наш процесс ускоренной обработки прост.

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

Пользовательские поля

У нас не так много пользовательских полей в нашем проекте Продукта.

• Спецификации: Это ссылка на документ Blue, который содержит спецификацию для этой конкретной функции. Это не всегда делается, так как это зависит от сложности функции.
• MR: Это ссылка на запрос на слияние в Gitlab, где мы храним наш код.
• Ссылка на предварительный просмотр: Для функций, которые в основном изменяют интерфейс, мы можем создать уникальный URL, который содержит эти изменения для каждого коммита, чтобы мы могли легко просмотреть изменения.
• Ответственный: Это поле указывает, какой старший инженер отвечает за обзор кода. Это гарантирует, что каждая функция получает экспертное внимание, которое она заслуживает, и всегда есть четко определенное лицо для вопросов или проблем.

Контрольные списки

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

Заключение

И это все!

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

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

Используя Blue для создания Blue, мы не просто разрабатываем продукт – мы живем им.

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

И это имеет огромное значение.