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

Вице-президент по инженерным вопросам Хуан Гутьеррес (Juan Gutiérrez) описал роль лидера проекта в своей статье «Не подходит фреймворк? Вы все равно можете внести свой вклад!»

У каждой миссии есть капитан, который отвечает за нее: постановка, выполнение, методы работы и результат. Как правило, капитан миссии — это разработчик, но потенциально им может быть любой инженер (независимо от стажа). Капитан миссии тесно сотрудничает с продакт-менеджером в течение всего жизненного цикла миссии. Также он отвечает за экипаж миссии и кто в него входит.

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

Но иногда жизнь преподносит нам сюрпризы. Поэтому, когда продакт-менеджер обратился ко мне с предложением принять этот вызов, я была уверена, что он шутит. Сначала я сомневалась, ведь что может предложить QA-инженер вроде меня? У меня не было технических навыков разработчика. Но потом меня осенило. Я поняла, что у меня есть уникальный шанс сделать все по-другому.

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

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

Будучи QA-инженером, я подошла к этой задаче, опираясь на структурированное мышление и сосредоточившись на нескольких ключевых аспектах.

Эффективная коммуникация

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

• Все важные обсуждения должны проходить со всей командой. Использование приватных чатов только с некоторыми коллегами приводит к разобщенности и/или лишает других возможности внести свой вклад в принятие решений. Этого стоит избегать.

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

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

Хорошо подготовленный скоуп и команда

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

• Вместе с менеджером проекта сократить и разбить скоуп работ на несколько этапов. Какую наиболее ценную часть нужно доставить в первую очередь? Что можно отложить, если будет нехватка времени? Что, скорее, будет плюсом, но не является обязательным?

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

• Достичь понимания решения на техническом уровне и продумать его сложность. Какие поля отсутствуют в базе данных и какие эндпоинты нужно добавить в API? Нужно ли проводить рефакторинг? Чтобы ответить на эти вопросы, нетехнический лидер проекта должен обратиться за помощью к разработчику.

Прозрачное отслеживание прогресса

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

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

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

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

Командный дух

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

• Заботиться о своей команде. Спрашивайте коллег, как у них обстоят дела: не чувствуют ли они себя перегруженными, не испытывают ли излишний стресс, не нужна ли им какая-либо помощь. Давайте позитивную обратную связь, чтобы поддержать их настрой.

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

• Не забывайте отдыхать и вместе отмечать маленькие победы! По возможности, чаще устраивайте совместные обеды. Отмечайте начало и окончание миссии. Сходите куда-нибудь выпить или закажите пироги/пиццу.

Заключение

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

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

Буду ли я рекомендовать другим QA-инженерам, чтобы они иногда брали на себя инициативу? Несомненно, да! Я призываю каждого человека использовать возможности для экспериментов и раскрытия своего потенциала в разных ролях. Однако в данном случае очень важно собрать опытную команду — желательно, чтобы в ней был хотя бы один старший разработчик, способный принимать активное участие в решении сложных задач. В противном случае все может стать еще сложнее и негативно сказаться на общем успехе миссии. Но в целом мой опыт показал, что выходить из зоны комфорта стоит, если за спиной у вас сильная и опытная команда.

А в завершение всех действующих тестировщиков приглашаем на открытый урок, посвященный настройке связки Jmeter с Grafana и InfluxDB. Встреча пройдет завтра, записаться можно по ссылке.