• Вопросы/неделя/пользователь. Сколько ответов давали пользователи?
• Уровень повторного поиска. Как часто посетители были вынуждены повторять поиск, чтобы найти нужный ответ? (Чем ниже, тем лучше.)
Стоунхэм подводит итог: «Это были как раз знания, необходимые, чтобы завладеть рынком, — и они изменили не только скорость наших компонентов функциональности. Из команды наемных работников мы превратились в команду заказчиков. Когда двигаешься с такой скоростью и каждый день смотришь на числа и результаты, уровень вовлеченности в работу меняется радикально».
Заключение
Для успеха нужны не только быстрое внедрение и быстрые релизы, но и умение побороть конкурентов в проведении экспериментов. Такие методики, как разработка на основе гипотез, определение и измерение воронки привлечения клиентов и A/B-тестирование, позволяют безопасно и без усилий экспериментировать с поведением пользователей, пробуждая творческий и инновационный подход к работе и создавая новый опыт на уровне всей компании. И хотя преуспеть — важно, новые знания, полученные благодаря экспериментам, дают работникам контроль над целями организации и удовлетворенностью клиентов. В следующей главе мы рассмотрим и создадим процессы проверки, анализа и координации для улучшения качества текущей работы.
Глава 18. Создайте процессы проверки и координации для улучшения качества текущей работы
В предыдущих главах мы создали систему телеметрии, необходимую для обнаружения и решения проблем в эксплуатации и на всех стадиях процесса непрерывного развертывания, а также быстрые циклы обратной связи от клиентов для получения нового опыта — опыта, пробуждающего вовлеченность в процесс и ответственность за удовлетворенность клиентов и работу всех компонентов сервиса. Все это помогает добиваться успеха.
Цель этой главы — помочь разработчикам и отделу эксплуатации сократить риск производственных изменений до того, как они сделаны. Обычно, анализируя изменения перед новым развертыванием, мы полагаемся на отзывы, проверки и согласование прямо перед самым развертыванием. Часто согласование дается чужими командами, слишком далекими от нашей работы. Принять обоснованное решение о рискованности правок затруднительно, а время на получение всех разрешений удлиняет сроки внесения изменений.
Процесс проверки работы коллегами (peer review) сервиса GitHub — яркий пример того, как критическое рассмотрение может улучшить качество, сделать развертывание более безопасным и стать частью повседневной работы. Специалисты сервиса GitHub стали первопроходцами практики pull request (