Как мы начали выпускать функции в два раза быстрее (пример из практики)

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

Мы — команда Active Collab , приложения для управления проектами с постоянно растущим набором функций и значительной пользовательской базой. Это означает, что даже самое незначительное изменение функциональности затронет большое количество людей.

Дальнейшее чтение на SmashingMag:

• Как внедрять новые функции, не нанося вреда лояльным пользователям
• Контрольный список запуска веб-сайта — 15 основных проверок перед запуском
• Ориентированный на пользователя подход к веб-дизайну для мобильных устройств
• Как запустить что угодно
  

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

Тревожный звонок

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

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

Очевидно, пришло время перейти к более гибкому подходу. Мы взяли то, что нам понравилось из разных agile (и не очень) методов, соединили это с опытом и придумали свой вариант, который с тех пор дает отличные результаты.

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

От предложения к функции

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

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

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

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

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

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

• Какие преимущества эта функция принесет пользователям?
• Соответствует ли это нашей философии продукта?
• Не добавит ли это ненужной сложности?
• Хорошо ли он сочетается с существующим интерфейсом и функциональностью?
• Есть ли у нас ресурсы, чтобы доставить его в разумные сроки?

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

Дизайн для пользователя

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

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

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

Используйте сочетания клавиш. Вы можете создать свой собственный набор горячих клавиш и ожидать, что пользователи их выучат (вероятно, они этого не сделают). Или вы можете добавить те, которые люди уже используют. Например, многие наши пользователи уже используют Slack, поэтому мы добавили ярлык, с которым они уже знакомы ( Command + K для быстрых переходов работает и в Active Collab ).

Когда пользовательские потоки готовы, наш UX-дизайнер макетирует дизайн в Sketch. Мы редко используем HTML на ранних стадиях. Хорошо продуманные визуализации Sketch дают нам достаточную гибкость, поэтому нам не нужно делать какие-либо возвраты, когда мы начинаем кодирование. Первоначальный дизайн обычно соответствует примерно 80% конечного продукта. Остальное добавляется и корректируется по ходу дела.

Еще одним важным этапом процесса проектирования является копирование. Наши копирайтеры уделяют большое внимание каждому слову. У нас даже есть собственное руководство по стилю, чтобы оно звучало максимально доступно и было максимально простым для понимания. Например, фраза «сертификат безопасности» вместо «сертификат SSL» означает, говоря простым языком, что-то, с чем обычный пользователь может быть не знаком.

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

Время начинать

Наши стартовые встречи — это не скучные мотивационные встречи. Это возможность для команды разработчиков (состоящей из младших и старших разработчиков) встретиться с менеджером проекта и владельцем продукта.

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

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

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

После встреч у команды будет вся необходимая информация:

1. Какой? Это объем функции , который включает в себя все, что необходимо сделать, а также потенциальные блокираторы и узкие места. Мы стараемся предвидеть как можно больше сценариев и крайних случаев. Предсказать их все непросто; они часто появляются, когда мы идем.
2. Почему? Владелец продукта оценивает ценность функции для бизнеса и объясняет, почему она стоит затраченных усилий. Таким образом, команда получает четкое представление о преимуществах для клиентов и продукта. Главным мотиватором здесь является то, что каждый должен понимать, почему его работа важна и какой вклад она вносит в компанию в целом.
3. Как? Описывая шаги, необходимые для завершения функции , мы гарантируем, что наши разработчики никогда не потеряют свой ориентир. Мы также устанавливаем реалистичные ожидания, добавляя тег сложности. Мы остановились на размерах футболок — размер S можно решить за несколько часов, а на определение размера XXL уходит несколько недель или даже больше.
4. ВОЗ? Руководитель группы отвечает за своевременное завершение функции или задачи и за информирование владельца продукта о ходе выполнения. Другие члены команды назначаются на свой набор подзадач, так что совершенно ясно, кто за что отвечает. Сохранение этого как можно более прозрачным помогает нам увидеть, борется ли кто-то или вызывает задержки.
5. Когда? Принимая во внимание все, определяется срок родов . Если задача задерживается, мы анализируем причины и используем этот опыт в следующий раз. Таким образом, пропущенный срок становится возможностью обучения, а не источником стресса.

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

Мы проходим этот контрольный список перед началом работы:

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

Это момент, когда задача перемещается в столбец «Выполняется».

Пришло время кодирования!

Работа в команде на дисплее

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

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

Показать и сказать

По графику команда проведет демо для владельца продукта. Цель демонстраций — показать, насколько хорошо функция работает в ее текущем состоянии и где ее нужно доработать. Это проверка реальностью, которая не допускает отговорок типа «Нужно лишь несколько последних штрихов» (штрихов, на которые уйдет еще месяц). Кроме того, если что-то пойдет не так, владельцы продукта смогут быстро отреагировать.

Еженедельные встречи

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

Тестирование

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

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

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

Вот наше определение «готово»:

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

Задача достигла заключительного этапа, который называется «Выпуск Q».

День выпуска

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

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

День бесплатных мероприятий

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

День охоты за ошибками

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

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

Что в итоге?

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

Итак, если у нас есть для вас один вывод, то вот он: создание корпоративной культуры, которая устраняет страх перед изменениями, сделает вашу команду лучше в том, чем она занимается. Называете ли вы это Scrum, Kanban или Lean, не имеет значения, если это помогает вашей компании расти. Эксперименты и инновации лежат в основе любого гибкого подхода. Не бойтесь тестировать разные решения, измерять результаты и на их основе изменять существующие практики. Хорошие результаты последуют.