Что нужно знать заказчику для работы с удаленной командой

Введение

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

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

Роль заказчика в проекте

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

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

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

Процессы, в которые должен быть вовлечен заказчик

Формирование общего скоупа работ

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

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

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

ВАЖНО: В процессах планирования необходимо ваше участие, потому что только при тесном содействии продукт получится таким, каким вы его видите.

Составление роадмапа

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

ВАЖНО: Роадмап — это гибкий инструмент, поэтому дедлайны и набор функционала могут меняться в зависимости от скорости работы команды, требований пользователей и других внешних факторов. Его основная цель — видение дальнейшего развития продукта.

Расстановка приоритетов

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

ВАЖНО: Приоритеты могут выставляться как отдельным задачам, так и логически цельному функционалу — фичам. Например, если функционал решает основную проблему пользователя, то ставится высокий приоритет, а если он из серии “было бы здорово сделать, но неизвестно, будет ли этим кто-то пользоваться” — низкий.

Планирование спринтов

Для того, чтобы постоянно видеть прогресс, а также безболезненно менять направление работы проекта, разработка делится на короткие итерации в 1–2 недели (спринты).

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

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

ВАЖНО: Помимо основного функционала, есть и другие задачи в проекте: написание автотестов, решение технического долга, написание технической документации и починка багов. Все эти аспекты должны быть учтены при планировании и расстановке приоритетов.

Демонстрации

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

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

ВАЖНО: На первых этапах баги на демонстрациях и в тестовой среде — это нормальное состояние, которое свидетельствует о том, что команда работает над продуктом. Для уменьшения количества багов в проект можно подключить QA-специалиста или, говоря простыми словами, тестировщика, а также писать автотесты.

Приемка задач

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

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

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

Написание тестов

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

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

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

Общая коммуникация

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

Обычно есть 4 основных источника коммуникации между участниками проекта:

• Slack/Skype: в них команда отписывает ежедневные стендапы, договаривается о встречах, обсуждает задачи в проекте и проблемы. Структура каналов обсуждается индивидуально для каждого проекта.
• JIRA(или другой таск-менеджер): здесь ведутся все задачи и описывается процесс работы по ним. Вся работа ведется в рамках какой-либо задачи. Если задача не была создана в таск менеджере, есть очень большая вероятность того, что она выполняться не будет. Проектное окружение должно быть одно, в нем централизованно будут храниться все задачи. Это нужно, чтобы не потерять задачи в разных документах, а вся команда понимает, что им предстоит делать в будущем.
• Email используется исключительно для отправки отчетов или других официальных проектных документов. После каждого отправленного отчета необходимо назначить личную встречу либо созвониться, чтобы обсудить детали и провести анализ.
• Созвоны / личные встречи необходимы для длительных обсуждений. Состав команды определяется в зависимости от темы обсуждения. Например, для планирование задач, обсуждение идей для нового функционала может привлекаться вся команда. Для того чтобы обсудить отчет по работе или подготовить задачи в бэклог будет достаточно проектного менеджера и тимлида. Перед встречей или созвоном необходимо отправить всем участникам план разговора, чтобы у каждого была возможность подготовиться.

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

Что заказчик может требовать от команды

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

Минимальные требования для этого — создание и настройка проектного окружения, включая таск менеджер, чаты для коммуникаций, а также репозиторий. У вас всегда должен быть доступ к тому, что делает команда. Однако к этому нельзя относиться как к данности. Если у вас есть информация — пользуйтесь!

Ниже приведу примеры того, что может вам помочь быть с командой на одной волне.

Ежедневные стендапы

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

Например, разработчик не понимает, какие задачи ему нужно делать. Это может быть сигналом того, что планирование было организовано неправильно. Чтобы решить проблему, нужно вместе с проектным менеджером проанализировать, что именно пошло не так, и исправить при следующем планировании. Или, например, разработчик пишет, что заболел — в таком случае будет вполне ожидаемо, что сроки сдвигаются. Технические трудности обычно решаются внутри команды.

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

Ворклоги

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

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

Инструменты для ежедневного мониторинга задач

Базовый мониторинг может основываться на чтении стендапов, однако, зачастую этого недостаточно. В дополнении к стендапам можно настроить фильтры или доски в жире так, чтобы система сама уведомляла вас об изменениях в проекте. Например, можно попросить менеджера настроить отправку уведомлений на почту со списком задач, обновленных в течение 24 часов или можно синхронизировать JIRA и gitlab со Slack: так вы сможете получать уведомления о коммитах, изменениях статуса задач, а также других событиях в зависимости от ваших пожеланий.

Отчеты

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

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

Донесение проблем и их решение

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

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

Ниже перечислю пару примеров проблем и их решений:

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

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

Заключение

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

Выход есть! Чем больше вы работаете с командой, тем меньше будет проблем и причин для беспокойства: сорванных сроков, неудачных демонстраций, недоработок и недовольства со стороны конечных пользователей.