Источник: ain.ua
Собственным опытом делится Константин Макаров, генеральный директор сервиса рассылок SendPulse.
Мы работаем над развитием платформы для email-маркетинга SendPulse. Сейчас у нас распределенная команда, разбросанная по нескольким странам. Мы поделимся своим опытом удаленного управления разработкой сложного продукта и дадим несколько практических советов.
Коммуникации нужно регламентировать
Наша команда разработки находится в Чернигове, а топ-менеджеры компании в США — в прошлом году мы вышли на этот рынок, открыли офис продаж и активно развиваем это направление. В итоге многие руководители или «владельцы продукта» (product owner) находятся далеко от офиса разработки, они и так не всегда могут понятным для разработчика образом сформулировать свои пожелания по новой функциональности. Поэтому часто возникает ситуация, при которой топ-менеджеру пришла в голову идея по развитию продукта, а затем он описал ее в общем виде в разговоре с разработчиками, и после этого уверен, что «фича пошла в работу».
Отсутствие же проговоренных деталей и возможных тонких моментов приводит к вероятности несоответствия конечного результата ожидания продукт-оунера. Прежде всего, это касается сроков разработки — при поверхностном обсуждении казалось, что новая функция может быть реализована за 2-3 недели, а по факту оказывается, что она затрагивает работу других модулей проекта и провести интеграцию новой функциональности быстрее чем за месяц-два нельзя.
Пример таких проблем из нашей практики: в конструктор email-рассылок нужно было добавить кнопку QIWI для интернет-магазинов — она позволяет получателям писем с изображением товаров сразу купить их через эту систему. Это очень полезная и востребованная бизнесом интеграция. Сама ее разработка заняла немного времени, мы больше потратили на неструктурированные обсуждения. Без четких требований получилось так, что обойтись только обсуждениями не вышло — в ходе работы всплывали различные ограничения и сложности, после чего приходилось возвращаться на шаг назад и думать о том, как изменить решение задачи.
И если при возможности личного общения в одном офисе всплывающие сложности можно оперативно обсудить, то при удаленных коммуникациях это не так просто. В результате проблемы, которые можно было бы решить на раннем этапе, могут иметь куда более значительные последствия — например, срыв сроков разработки и релизов новой функциональности часто приводят к отставанию от конкурентов и физической потере пользователей и выручки.
Чтобы этого не происходило, удаленные коммуникации должны подчиняться строгим регламентам. Нельзя просто обсудить новую фичу и начать ее делать. После базового обсуждения должен следовать анализ того, какие части продукта будут затронуты нововведениями. По итогам анализа составляется документ с требованиями, затем пишется техническое задание, в рамках которого уже можно работать программистам.
При этом, важно сделать так, чтобы прозрачным был не только процесс работы над новой функциональностью, но и вообще любые обсуждения, касающиеся работы продукта. Сейчас коммуникации внутри нашей компании регламентированы так, чтобы всем было понятно, когда и какие вопросы обсуждаются.
Например, у нас существуют ежедневные стендапы с С-Level руководителями, на которых участники в онлайн режиме обмениваются информацией по текущим задачам для каждого отдела, в том числе и разработки. В форс-мажорных ситуациях синхронизируемся в офлайн-режиме, например, когда руководитель в командировке без доступа к Wi-Fi или 3G. Такое случается крайне редко, поэтому основные коммуникации происходят в GoToMeeting или Skype. Для быстрой связи и обсуждений мы используем чаты в Telegram.
Важный момент: упомянутые стендапы представляют собой не отчеты, а рассказы о достижениях, обсуждение возникающих сложностей. Когда член команды знает, что в определенное время сможет задать все важные вопросы руководству, это позволяет ему меньше отвлекаться по ходу дня.
Особым образом мы пользуемся и email – этот инструмент зарезервирован для коммуникаций по долгосрочным и важным направлениям работы. Главная цель — сделать так, чтобы любые важные данные было легко найти. Например, в почте могут быть зафиксированы достигнутые на митингах договоренности, а также проходить коммуникации с партнерами и обсуждения важных документов — в чатах такую информацию было бы легко потерять.
Что, как и когда будет делаться определяется регламентом — например, исправление багов или апгрейды продукта делаются в течение первых 2 недель спринта. В целом, задачи делятся на несколько типов:
- важно и срочно,
- важно и не срочно,
- не важно и срочно,
- не важно и не срочно.
Такая градация помогает нам разобраться с приоритетами и распределить время разработки в правильных пропорциях. Бывают и случаи, которые мы называем «Random pool» – это задачи, возникновение которых было почти невозможно предусмотреть. На их решение у каждого участника команда разработки зарезервирован определенный процент рабочего времени.
Наличие проработанных регламентов позволяет четче выстраивать коммуникацию с разработчиками и понимать, что и когда у них будет возможность сделать.
Процессы разработки и коммуникации нужно постоянно улучшать
Мы работаем на высококонкурентном рынке сервисов для email-маркетинга, поэтому стремимся постоянно улучшать не только сам продукт, но и процессы взаимодействия членов команды, чтобы как минимум оставаться в лидерах рынка.
Мы постепенно уменьшаем время по «выкатыванию» новой функциональности. Чем быстрее будем мы, тем больше вероятность сделать что-то первыми на рынке, оставив конкурентов позади, выиграв время на разработку будущих функций.
Команда разработки в своей работе опирается Agile ценности и принципы. Наша разработка сейчас построена по Scrumban и мы активно ищем варианты улучшений и возможности повышения производительности команды разработки.
У нас итеративная (выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы — ред.) разработка и любая наша интеграция планируется и проходит через этап анализа, фиксирования ожиданий и формулирования требований к реализации. В процессе разработки текущего спринта рабочая группа вместе с партнером обсуждает варианты интеграции, нашими дизайнерами создается прототип, утверждается и заранее спрогнозированной дате мы готовы брать в работу следующую интеграцию. То есть итеративная разработка у нас применяется на разных стадиях производственного процесса — как на этапе анализа (отдельный процесс), так и на этапе разработки (также отдельный процесс).
Синхронизация итераций разных команд лежит на плечах команды менеджеров, которые, выстраивают процессы в компании SendPulse — эти менеджеры физически находятся в одном офисе с разработчиками.
Кроме того, один из способов улучшения коммуникаций при удаленной разработке — это найм в офис с программистами бизнес-аналитика. Такой специалист должен уметь одинаково хорошо разговаривать и с топ-менеджерами, и с разработчиками. В результате после обсуждений с владельцами продукта именно он прорабатывает требования к функциональности таким образом, чтобы они были понятны программистам. Наличие такого профессионала позволяет экономить до 50% времени на разработку новых фич.
Нужно быть готовым к сложностям
Построение международной компании — непростой процесс, в ходе которого сложностей избежать не удастся. Важно понимать, что при удаленных коммуникациях важно сохранять высокий уровень доверия.
Если руководитель, находящийся за границей, будет получать искаженную или неполную информацию от команды, это может плохо повлиять на продукт. А искажения возникают в том числе тогда, когда люди боятся совершать ошибки и признаваться в этом. Такой подход свойственен некоторым крупным аутсорсинговым компаниям, однако для распределенного продуктового стартапа он не подойдет.
При возникновении проблем, люди зачастую ищут причину в сторонних факторах, а не в себе или в своих действиях. Когда сотрудники понимают, что ошибаться — это нормально, то не бояться экспериментировать. При этом, итеративная разработка позволяет быстро выявлять недочеты и неточности.
Сейчас мы каждые 2 недели проводим ретроспективы, брейнштормим по выявленным ошибкам («преградам» ) и выстраиваем план их устранения. Только когда мы зафиксировали кто, что , когда и как будет исправлять преграду мы начинаем работать над устранением. Иначе задача зависнет на полпути и не будет доведена до конца.
Кроме того, когда члены разных команд и департаментов не сталкиваются друг с другом в офлайне, у них меньше понимания того, чем занимаются коллеги из других городов. Это тоже может приводить к проблемам, поэтому мы уделяем много внимания повышению прозрачности процессов и стимулируем участников разных команд активнее делиться знаниями внутри компании.
Например, после совещаний и брейнштормов мы фотографируем схемы, нарисованные в ходе обсуждения, и записанные идеи, а затем публикуем их в Trello или выкладываем на Google Drive. Так коллеги из других локаций могут тоже подумать над темой и предложить свои идеи — в итоге получается плод командной работы.
Заключение: возможна ли полностью удаленная разработка
Как показал наш опыт, связанные с разработкой коммуникации не могут быть полностью удаленными. К примеру, мы часть времени работали с удаленным от команды менеджером проектов, который территориально находился в Нью-Йорке. Разница с командой программистов в Чернигове составляла 7 часов — и это оказалось большой проблемой.
Сложилась неприятная ситуация с несовпадением графиков: когда у разработчиков в Чернигове начинается рабочий день, в Нью-Йорке ночь; когда разработчики завершают рабочий день в Нью-Йорке он только начинается в Чернигове — естественно о продуктивных коммуникациях нельзя было и мечтать. Большую часть времени разработчики работали без менеджера и вопросы которые появлялись, либо ждали послеобеденного времени, либо решались на усмотрение разработчика в случае срочности.
Возможно, для каких-то компаний это может оказаться приемлемой ситуацией, но у нас менеджер проектов — это ключевая позиция в процессе разработки. Возможно, если бы таких менеджеров было бы несколько, или удаленный сотрудник хотя бы располагался в том же или более близком часовом поясе для большей доступности, проблема была бы не такой острой.
Есть и другие не всегда очевидные трудности — обычно встреча руководителя с разработчиков лицом к лицу более эффективна, чем созвон в Skype. Кроме того, не сталкиваясь постоянно с человеком сложно замечать перемены в его настроении, в результате можно упустить тот момент, когда сильный специалист задумается о смене работы, и в результате потерять важного члена команды.
Все это говорит о том, что для повышения эффективности команда разработки не может существовать в полном отрыве от руководителей компании. Несмотря на наличие продвинутых технологий коммуникации личный контакт все равно важен, поэтому в офисе рядом с программистами должны находиться как минимум менеджеры проектов, которые уже обеспечивают коммуникацию с руководителями за границей.
Самые актуальные новости - в 
