Привет! Меня зовут Лёша Руденко, во фронтенде уже более семи лет, сейчас работаю фронтенд‑лидом в финтехе. А ещё я ментор на курсе «Мидл фронтенд‑разработчик» в Практикуме.
В этой статье я расскажу о работе в команде, которая только начала формироваться. Отталкиваться буду от своего опыта менторства и работы. Статья будет полезна не только студентам курса, но и всем, кто работает с другими людьми. В конце я немного расскажу о том, что делать, если застрял с задачей, и зачем просить обратную связь у руководителя.
Во втором модуле курса студенты объединяются в команды, чтобы создать совместный проект — игру в браузере. Я часто вижу, что в начале работы страдает эффективность. Это понятно: вокруг совершенно новые люди, много разных задач и непонятных терминов. Часто студентам трудно договориться об инструментах и подходах — у всех разный опыт за плечами, и точки соприкосновения ищутся сложнее.
Спустя 2–3 недели работы ритм обычно выравнивается, люди привыкают друг к другу, им помогают менторы с кураторами. Но иногда я обнаруживаю, что неразрешённые проблемы заметаются под ковёр, а команды двигаются вперёд вопреки сложностям. Я встречал такие ситуации не только среди студентов, но и в рабочих дистанционных командах.
Давайте сначала разберёмся, что такое команда:
Команда — это группа людей, прикладывающих совместные усилия для достижения общей цели.
Исходя из этого определения перейдём к первому пункту построения команды — определению этой цели.
Определитесь с целью
Представьте, что вам нужно поднять новенький 100-килограммовый холодильник на 11-й этаж. Есть у вас лифт или нет, сделать в одиночку это невозможно. А вот если рядом есть пара крепких друзей или группа грузчиков — всё в порядке, холодильник точно окажется где нужно.
Именно приверженность конкретной цели помогает собрать настоящую команду. Для этого участникам нужно ответить на несколько вопросов:
Для какой работы мы собрались?
Почему её лучше делать в команде?
Что мы получим в результате?
Крайне важно, чтобы цель была чётко сформулирована и понятна всем участникам. Если этот критерий не соблюдается, то случаются неожиданные ситуации.
Например, команда разработчиков получает задачу на разработку MVP‑версии нового сервиса. Не сильно вникая в детали, в процессе работы команда генерирует несколько идей об архитектуре сервисов, которые будут появляться в продукте.
Предположим, для этого потребуется немного переписать код транспортного слоя между сервисами — и вот уже небольшая архитектурная идея превращается в задорный рефакторинг с неясными временными перспективами, где одно улучшение влечёт веерные изменения большого количества смежных сущностей.
Продакт‑менеджера, инженеров по качеству и других коллег ждёт не самый радостный сюрприз. Изначальная задача была в быстром проектировании и релизе нового сервиса для тестирования. В это время каждый член команды разработки уверен, что делает всё ради стабильности и складности системы, которую разрабатывает.
Немного другой пример: на нашем курсе мы объединяем студентов в команды, чтобы они вместе написали игру. Кто‑то может подумать, что это и есть наша общая цель, на которой нужно фокусироваться. На самом деле это не совсем так.
Наша цель — освоить вполне конкретный перечень технологий и подходов. Фокус мы держим больше на самом процессе, чем на достижении выдающегося результата. Именно поэтому наши менторы настаивают на том, чтобы студенты не доводили геймплей до уровня ААА‑изданий, а делали что‑то простое, но понятное.
Формулировать измеримые и конкретные цели поможет система SMART. Понимание целей поможет отбрасывать лишнее в процессе работы и быть уверенным, что все действительно поднимают холодильник на 11-й этаж: никто не уехал на лифте и не ждёт у подъезда.
Выберите лидера
Роль тимлида может объединять в себе много разных обязанностей и функций. Лиды могут менторить, обучать, планировать, приоритизировать, коммуницировать со смежными отделами, ставить цели. Зачастую (но не всегда!) именно лид представляет команду на демо и зачётах.
Лидер команды — это не только почётная роль, но и дополнительная ответственность. Я предлагаю свести роль тимлида до простого определения в рамках нашей статьи:
Лидер — это человек, который всегда помнит об общей цели и помогает направлять усилия команды к ней.
Зачастую неформальный лидер сам собой появляется в команде. Это наиболее проактивный и инициативный человек. Важно явно обозначить лидера и вслух обсудить его обязанности. Очень часто это человек с наибольшей технической экспертизой, но знак равно между самым сильным игроком и лидом ставить не нужно.
Договоритесь о базовых принципах взаимодействия
Всем участникам команды нужно определить, как они будут работать вместе. Небольшой набор договорённостей поможет всем понимать, как себя вести в определенных ситуациях, — это даст согласованность и поможет избежать конфликтов.
Для разных команд, разных задач и областей правила могут быть разными, но некоторые из них можно определить почти для любого случая. Для небольшой команды разработки из 5–7 человек я бы предложил подумать о таких моментах:
Способ принятия решения. Модель принятия решений должна быть чёткой и понятной всем членам команды. Понятная модель описывает, кто принимает решение и как в нём будут участвовать другие.
Вы можете принимать решение большинством голосов, добиться согласия всех участников или найти компромисс. Кому‑то комфортнее, когда финальное решение принимает лидер, а участники команды только аргументируют в пользу одного из вариантов.
Формат общения команды. Определитесь, где будут проходить коммуникации между участниками: в слаке, зуме или на других площадках. Насколько часто это будет происходить? Должны ли участвовать все или достаточно собрать кворум?
Код‑ревью. Сколько человек должны дать апрув вашему коду? Как вы сообщаете, что код готов к проверке? В течение какого времени ваш пулл‑реквест должен быть проверен и что делать, если это не случилось вовремя?
Структура проекта. Это самый горячий вопрос, открывающий пространство для дискуссий, но его обязательно проговорить и зафиксировать результат обсуждения.
Как правило, структура проекта отражает архитектурные решения. Какой подход вы используете? Например, храните ли вы контроллеры и вью в разных папках или объединяете файлы по предметной области, которую они реализуют?
Общие инструменты и основные технологии. Постарайтесь избежать путаницы, обсудите ключевые инструменты и подходы на старте, а по мере появления новых инструментов фиксируйте и их. Иногда я сталкиваюсь с тем, что участники команд используют Yarn и npm одновременно или пишут CSS, используя разные технологии.
Часто общие правила определяет тимлид, самый давний участник команды, или они определяются на уровне всей компании.
На курсе всё немного иначе, так как все студенты оказываются в команде с момента её основания. Это отличная возможность поучаствовать в формировании правил жизни — у всех студентов разный опыт, из которого они могут взять лучшие практики. Это помогает создать справедливую и прозрачную рабочую атмосферу.
Обсудите и добавьте ритуалы
Сегодня очень распространены гибридный и дистанционный формат работы многих команд. Например, в моей команде есть люди из России, Бразилии, Кипра и Турции.
К сожалению, это создаёт определённые сложности: не всегда есть ощущение общей цели, а внимание может сместиться с текущих задач на чувство разочарования или гнева по поводу прогресса команды.
В таких условиях важно общаться вслух, чтобы калибровать ожидания, цели и процессы. Я очень рекомендую организовать небольшие ритуалы, например регулярные созвоны, где вы кратко обсудите текущую ситуацию и поделитесь сложностями. Вы наверняка слышали про утренние стендапы или дейли‑митинги, но совсем необязательно проводить их утром или каждый день. В вопросе регулярных встреч нужно отталкиваться от потребностей команды в конкретной ситуации.
Расскажу пример из своей практики: полгода назад я предложил начинающему сотруднику объёмную задачу — миграцию фреймворка на актуальную версию. Мы вместе распланировали задачи и очертили сроки — я был уверен, что уложиться в дедлайн вполне реально, но вот мой коллега переживал.
Я предложил дополнительный синк во второй половине дня — просто для обсуждения того, что удалось сделать и были ли какие‑то сложности. В течение всего периода работы на этих синках мы с коллегой обсуждали текущие задачи и трудности.
Позднее на ретро он поделился, что эти встречи дали ощущение плеча и не создавали атмосферы дополнительного контроля.
Чтобы резюмировать, вот далеко не полный список ритуалов, которые можно ввести:
Ежедневные короткие созвоны. Помогут синхронизироваться и обмениваться информацией. Такие встречи часто называют daily‑standup, но они не должны быть обязательно ежедневными.
Ретроспективы. По окончании очередной итерации полезно обсудить, что удалось хорошо, что можно улучшить и какие шаги можно предпринять или сохранить для оптимизации процессов в следующем спринте.
Демо‑сессии. По завершении этапа разработки команда может устроить демонстрацию результатов работы коллегам из смежных команд и отделов.
Мозговой штурм. Встречи для поиска решения и генерации идей.
Неформальные встречи. Проводятся для сплочения команды. Часто происходят по пятницам в барах, но могут проходить в палатках на природе, за настольными играми в кафе или просто в зуме.
Такие практики помогут нормализовать развитие команды, а её участники преодолеют несоответствие, которое они могли ощущать между своими индивидуальными ожиданиями и реальностью командного опыта.
Говорите и слушайте — это помогает
В молодых командах или среди начинающих специалистов я сталкиваюсь с убеждением, что все проблемы нужно решать самостоятельно. Люди боятся, что, если они будут обращаться за помощью, это подвергнет сомнению их профессионализм. Также я часто встречаюсь с синдромом самозванца и в целом с переживаниями о работе.
Чтобы справиться с этими заблуждениями и переживаниями, нужно всего лишь говорить и слушать. Давайте разберём на примерах для наглядности:
Не бойтесь спрашивать. Бывает так, что вы застреваете надолго с задачей. Она может вовсе не быть сложной: иногда глаз просто замыливается, или вы теряете контекст. Кроме того, бывает так, что вы исчерпали собственные варианты решения задачи и вообще не понимаете, с какой стороны подступиться.
Ещё вы можете не знать или забыть, как работает какая‑то часть продукта. Самое удивительное, что такое нередко случается с разработчиками уровня тимлидов или синьоров — они могут быть менее осведомлены о нюансах реализации отдельных модулей.
Помните про определение команды? У вас есть общая цель, а это значит, что результат работы нескольких людей зависит и от вас тоже. Когда проблемы обнаруживаются и обсуждаются вовремя, команда может сосредоточиться на их решении до того, как они превратятся в серьёзные затруднения и повлияют на сроки.
Признать, что ты что‑то не знаешь, и обратиться за помощью или советом к коллеге — нормально.
Уметь находить ответы — это часть вашей работы как разработчика и очень важный навык. Вполне нормально признать, что вы в тупике или чего‑то не знаете, и позволить коллегам помочь. Это сбережёт время, позволит приобрести опыт или знания. В конечном итоге это развивает культуру доверия друг другу в команде.
Давайте и принимайте обратную связь. Обратная связь — важный элемент для собственного развития. Она помогает критически взглянуть на свою работу, а иногда и сигнализирует о необходимости изменений.
Особенно важен фидбек для ребят джуниор‑уровня — он наглядно иллюстрирует успехи и достижения, сообщает о том, что можно попробовать улучшить, чтобы двигаться к целям эффективнее. Такая обратная связь называется развивающей.
Приведу пример, который демонстрирует важность фидбека: моя знакомая уже полгода работает в классной студии UI/UX‑дизайнером. Она пришла туда с опытом дизайна более года — уверенным джуниором.
Поинтересовавшись её ощущениями от места, в которое она мечтала попасть, я с удивлением услышал, что она не понимает до конца, насколько эффективно выполняет свою работу и соответствует ожиданиям команды.
Мы подумали и выяснили, что рост есть — ей уже доверяют общение с заказчиками и сбор требований, разница в задачах по сравнению с первыми неделями также достаточно ощутимая. Кажется, мы поймали за хвост её синдром самозванца. Помочь ей и направить мог бы фидбек от руководителя, ведь задача обратной связи — уменьшить расхождение между субъективными ожиданиями и объективными результатами работы. К сожалению, если специалист начинающий, он не всегда догадывается попросить об обратной связи.
Поэтому я посоветовал знакомой обратиться к руководителю или опытному коллеге, которому она доверяет, и попробовать выяснить, насколько успешно она справляется с поставленными задачами и какие области стоит улучшить.
Кстати, эта ситуация иллюстрирует, что сотрудники синьорного уровня также часто недооценивают важность обратной связи для коллег. Так что не стесняйтесь давать развивающий фидбек.
Немного о том, как давать и запрашивать фидбек, можно почитать в статьях: Почему всем нужна обратная связь, как её принимать и запрашивать и Гайд по фидбеку: как давать и принимать обратную связь.
Хвалите коллег. Это бонусный совет:) Мы не всегда видим, сколько усилий прикладывают наши тиммейты к своим ежедневным обязанностям. Старайтесь искренне обратить внимание на то, что получается у коллег классно: выступление на ретроспективе, тестирование задачи или вдумчивое решение проблемы в коде. Это помогает укрепить отношения в команде и сделать их чуть более доверительными.
В заключение давайте вернёмся к нашему определению из начала статьи:
Команда — это группа людей, прикладывающих совместные усилия для достижения общей цели.
Важно помнить, что любая группа людей характеризуется разнообразием мнений, может иметь внутренние противоречия и сложности. Каждый человек может занимать на работе определённые роли. В этих ролях формируются разные ожидания, которые могут расходиться с реальностью. Таким образом, любое несовершенство процессов в команде связано лишь с ожиданиями от ролей других тиммейтов.
