Всем привет, меня зовут Иван Михеев, я Chief Technology Officer маркетплейса авторских туров YouTravel.me, где руковожу разработкой, поддержкой и всем, что связано с технической частью бизнеса. Сегодня я хочу вам рассказать о том как делегирование влияет на эффективность команды, и что нужно, чтобы правильно делегировать.  

Кто такой руководитель?

Роль руководителя формально сводится к четырём основным задачам: планирование работы команды, организация процессов, мотивация сотрудников и контроль выполнения плана. Формула идеального распределения рабочего времени руководителя — 80% стратегического развития и 20% операционных задач. Конечно, это условные значения и все зависит от вашего контекста, но я убежден, что если “операционка” занимает больше половины времени — это проблема.

Часто бывает, что у руководителя нет времени на непосредственно управление, потому что он регулярно вынужден уделять внимание вопросам команды, решать мелкие проблемы и частные случаи. Команда в таком случае страдает “выученной беспомощностью” — сотрудники не видят в себе силы решать проблемы самостоятельно и не готовы брать на себя ответственность за принятие решений. Это не значит, что сотрудники намеренно саботируют работу или некомпетентны, —, руководитель своим поведением даёт им понять, что без его помощи они не справятся. Задача руководителя — научиться грамотно выстраивать эффективный процесс делегирования задач и сделать команду более автономной.

Сегодня поговорим про SSR — что это, зачем использовать, как с этим работать, чтобы все получалось.

Что такое SSR?

SSR — это Server Side Rendering, то есть, генерация страницы на стороне сервере, а не в браузере, когда сервер отдает уже сгенерированный HTML.

Любая страница сайта или простейшая веб‑версия приложения — это HTML‑код, который отображается в браузере в виде набора визуальных элементов — текстовых блоков, изображений, ссылок и кнопок. Рендеринг — сборка html кода для браузера пользователя, из блоков кода исходного vue‑файла. Это происходит тогда, когда мы заходим на сайт — то есть, отправляем запрос на сервер, а с него получаем js‑код vue приложения, html c пустыми местами, в которые будет рендериться контент уже на стороне пользователя. И, конечно, мы хотели бы, чтобы это происходило моментально.

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

Для этого и существует SSR. При этом методе весь HTML‑код страницы генерируется на сервере и передается пользователю в браузер.

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

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

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

Для сбора инсайтов на этапе выбора и оформления тура мы создали внутренний канал в Slack — инструменте, которым пользуемся каждый день, — и назвали его FeedbackHarbour. Каждый сотрудник команды может принести в этот канал новую идею, интересный инсайт, предложение или критику по продукту. Сообщения помечаются тегами — #идея, #проблема или #отзыв. 

Какое-то время назад мы столкнулись с проблемой: сроки нашей разработки и темпы реализации начали сильно стопориться. При запуске фичей команда сталкивалась с отсутствием прозрачности при отображении объема задач в спринте. У одного разработчика в работе могло находиться сразу несколько задач, поэтому было непонятно над какой из них он трудится сейчас. Кроме того, задания при переводе обратно на разработчика никак не маркировались, что повышало риск того, что они не будут замечены вовремя.  В итоге, разработчики “буксовали” на одних и тех же задачах в ожидании ценных указаний, а важные доработки терялись. Исправить ситуацию нам помог новый подход к визуализации задач на командной доске.

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

Когда мы только берём задачу в работу, она попадает в Tech Design, затем задача перемещается в Development — основной этап разработки. После того, как разработка фичи окончена, задача отправляется на Review, где мы проверяем написанный разработчиком код. Затем два этапа тестирования, и, соответственно, две колонки — QA (Quality Assurance) и UAT (User Acceptance Testing). Финальная колонка — Ready to Release, то есть, фича, попавшая в неё, уже готова к выпуску в прод.

Сегодня хотим рассказать о том,  как нам в YouTravel.me удалось снизить количество дефектов в 30 раз — с 400 до 13 — менее чем за полгода. Для наглядности — вот как выглядит это на графике:

Изображения играют важную роль в продаже авторских туров. Когда стартап в сфере туризма, маркетплейс авторских туров YouTravel.me начал обрабатывать 2,5 млн запросов на картинки и отдавать 50 GB в сутки, команда разработки задумалась, как хранить изображения, чтобы они не теряли качество, и при этом не тратить космические бюджеты.