Иллюстрация Марии Рыбак
Рекомендации тимлида, проджект-менеджера, SCRUM-мастера.
Статья написана в соавторстве с в JMind, и в JMind.
То, как мы ведем себя с сотрудниками, наши слова и даже интонации — все это влияет на эффективность людей и их желание с нами работать. Согласно , стресс на рабочем месте приводит к увеличению добровольной текучки кадров почти на 50%. Часто его причиной становятся не условия труда или сложные задачи, а взаимодействие с руководством.
В университете, на курсах и тренингах нам часто говорят, что и как мы должны делать на конкретной должности, как действовать в той или иной ситуации. Но редко говорят, чего делать НЕ стоит — с точки зрения человеческих взаимоотношений.
Об этом мы с коллегами из JMind, компании холдинга TECHIIA, говорим в этой статье: чего не стоит делать или говорить своей команде, если вы создаете здоровую атмосферу на рабочем месте.
Мы работаем на разных позициях: CPO, тимлиды направлений. Наши советы и истории дополняют друг друга и будут полезны всем руководителям — от лидов до CTO и тех, кто планирует выйти на эти позиции.
Советы для Project Manager
Не говорите человеку, как делать его работу
Любого специалиста, включая разработчика, нанимают за его знания и навыки. Ваша ключевая задача — наладить взаимодействие между людьми с разными навыками и держаться на другом уровне абстракции. Не учите каждого из них хардскиллам, которые у них наверняка прокачены лучше, чем у вас — иначе вы бы работали на их месте. Вам прежде всего важен рабочий результат в оговоренные сроки.
Если же вы знаете какие-то тонкие приемы в написании куска кода или подходящую библиотеку, и это может помочь коллеге, поделитесь знанием в качестве рекомендации, а не указания. А еще лучше — в формате “что думаешь по поводу использования вот здесь вот этого?”
Не спешите оценивать трудозатратность задачи до того, как услышите мнение разработчика
Даже сам коллега может недооценить или переоценить сложность и нужное время для задачи — а он точно глубже понимает свои возможности. Ни один руководитель не может знать всех компетенций своей команды, особенно если она кросс-функциональная.
Поэтому, даже если кажется, что вы лучше знаете, выслушайте мнение тех, кто непосредственно будет заниматься задачей, и только потом выставляйте эстимейты. Плюс шаг, плюс обсуждение, но это сэкономит вам и коллегам нервы на входе в задание и на этапе реализации.
Не присваивайте все заслуги и не обвиняйте во всех бедах подчиненных
Позиция руководителя требует как раз обратного подхода. При успехе важно подчеркивать, что это заслуга команды, и все вложились в результат. Если же что-то пошло не так, берите максимум ответственности за это — так вы поймете, как более эффективно организовать процесс в будущем.
Не наказывайте за ошибки, особенно совершенные впервые
У нас в JMind и в других командах TECHIIA даже сложилось негласное правило: на первый промах в задаче не обращать внимания. Без ошибок не бывает экспериментов, а без экспериментов — больших достижений. Мы скорее поощрим за смелость и сделаем продуктивные выводы, чем ткнем пальцем в инструкцию.
Другое дело, когда сотрудник ошибается систематически и не потому, что пробует новое. Но даже в этом случае не спешите обвинять. Ошибка сотрудника плотно связана с ошибками менеджера. Выясните, по силам ли этому конкретному человеку эта задача, всех ли ресурсов ему достаточно. Одинаково ли вы с коллегой понимаете тонкие моменты техзадания, и четко ли оно сформулировано? Помните: если вы что-то не указали в ТЗ, значит при любом выполнении задача решена верно.
В этом же пункте рекомендую не замалчивать большую картину (helicopter view) и причины принятия тех или иных решений — даже таких, которые кажутся незначительными для выполнения задачи. Подавайте пример — аргументируйте свои решения. Это поможет и минимизировать ошибки, и наладить открытость в команде.
Наконец, не нагнетайте обстановку и не умножайте негатив. Нужно показать команде, что даже из проблемной ситуации есть выход.
Советы для Scrum-майстра
На любой должности при работе с командой актуальны одни и те же темы: организация процессов, атмосфера на рабочем месте, фидбек и то, как его стоит преподносить. Я руководствуюсь принципами SCRUM, но написанное ниже универсально для любой методологии.
Не ругайте коллегу при всех
Сюда же добавлю: если случился инцидент, не ищите виновных. Сначала решите проблему. Разборы полетов с ответственными лучше делать, когда пожар потушен.
Придерживайте негативный фидбек для беседы тет-а-тет. Даже если эмоции зашкаливают. Публичная порка убивает профессиональное творчество и поляризует команду: появляются «жертвы», «спасители», «преследователи». Вы даете и другим право на травлю, закладываете фундамент для токсичности.
Особое зло — эмоциональный фидбек, хоть лично, хоть при команде. Если сотрудник и сам осознает свой промах, ваш повышенный тон только загонит его в больший стресс и помешает сделать здравый профессиональный вывод. А дискуссий с вами коллега будет избегать, ведь будет знать, что вы можете легко перейти на личности.
При этом хвалить полезно на общих собраниях. Особенно тех, кто объективно вложился в достижение команды. Не льстите, просто обозначьте факты и поблагодарите за вклад. Так создается здоровая конкуренция — при условии, что у вас как у руководителя достаточный авторитет.
Не забывайте о человеческом
Разработчик — не только рабочие руки, но и личность со своими интересами, проблемами и обстоятельствами. Они могут по-разному влиять на его продуктивность в конкретный момент. Иногда может быть полезно поинтересоваться состоянием дел вне работы, чтобы перераспределить нагрузку, подключить HR компании и вовремя поддержать человека.
Не стоит микроменеджить и «капать на голову» сотруднику
Гиперконтроль и гипервмешательство чреваты двумя бедами. Первая — ваш коллега, скорее всего, будет только раздражаться от ваших постоянных уточнений. Из-за этого он отдаст сырое решение, лишь бы вы побыстрее отвязались. Ваши взаимоотношения это тоже вряд ли улучшит.
А вторая беда — постоянно влезая в мелочи, вы рискуете «съесть» у разработчиков ответственность за качество работы и утонете в рутине и операционке. Команда перестанет сама предлагать решения, все будут действовать по вашим указкам.
Не думайте, что мотивы вашего поведения всем понятны. Всегда аргументируйте свою позицию и решения
Однажды после очередного Backlog Refinement команда дружно сказала, что задача понятна, и на разработку нужно N сторипойнтов. Только впоследствии выяснилось, что понимание некоторых терминов у Product Owner и команды отличались. Ребята реализовали задачу так, как поняли, и это оказалось совершенно не то, что подразумевалось в условии.
Желательно проговаривать каждую мелочь. Мы можем потратить несколько минут (на первый взгляд, лишних), но в итоге cэкономим дни или даже недели.
Эту рекомендацию могу написать только без «не»: всегда помните свои обещания!
Советы для тимлида
Не вешайте на сотрудников ярлык супергероев
Будьте готовы прийти на помощь любому из них. Иногда даже люди с опытом сталкиваются со сложностями, которые кажутся им неразрешимыми или требующими очень много времени. В некоторых ситуациях синергия и взаимоподдержка очень позитивно влияют на результат работы и отдельных коллег, и всей команды.
Был такой случай. Один из коллег намного дольше обычного придерживал задачу, при этом на вопрос «все ли в порядке?» продолжал отвечать утвердительно. Так продолжалось какое-то время, пока от него не пришло сообщение в стиле «все пропало».
Пришлось погружаться в ситуацию. Немного изучив проблему, я пришел к выводу, что не знаю решения, но казалось, что оно очень близко. Созвонились, я постарался быть конструктивным, узнал, какие попытки и подходы уже применялись. Мы запустили сессию парного программирования — и спустя короткое время нашли решение. Обязательно похвалил коллегу и нас двоих. А самое главное — избавил его от тревоги за то, что он не успевает выполнить задачу в срок.
Не будьте слишком критичны. Но и не стоит перехваливать
Постоянный конструктивный диалог дает четкое понимание основных потребностей и настроения сотрудников.
Недавно один из коллег предложил в проект инновацию. К сожалению, он не посоветовался и вместо предложения пришел к нам с конкретной реализацией. Большинству членов команды она показалась избыточной и несвоевременной. Они предложили отложить ее применение или попытаться найти более элегантное решение.
Вместо того чтобы принять за основу решение команды и закрепить его, я решил поддержать коллегу и попытаться мотивировать его на поиск лучшего решения. Но сделал неверный выбор. Дискуссия превратилась в бурный спор, мы потратили намного больше времени, чем требовала ситуация. Результат — немного раздосадованный инициатор и раздраженные коллеги.
В спорных ситуациях лучше прибегать к аргументированному мнению команды. А предложения и улучшения сначала выносить на обсуждение, обязательно отметив инициативу. И только после этого приступать к реализации с учетом комментариев.
Не позволяйте развиваться личностным или рабочим конфликтам. Но и спускать их тоже не стоит
В спорах рождаются хорошие решения, а в спорах с переходом на личности — бомбы замедленного действия, которые могут разорвать команду. Обращайте внимание на случаи, когда дискуссия выходит за профессиональные границы и теряет конструктив. Проводите ретроспективу споров и вырабатывайте четкий механизм решения схожих проблем.
В качестве превентивной меры своевременно собирайте, анализируйте и передавайте фидбек от команды. При этом важно учитывать, что не все готовы лично выражать мнение о коллегах. Особенно в условиях работы онлайн, когда людям сложно выстраивать отношения и прямо высказывать мнение о других сотрудниках. Здесь ваша задача быть фасилитатором и создавать мосты доверия.
А чем бы вы дополнили наш общий список? Благодаря каким историям у вас появились собственные «не»?
Статьи и литература по теме
- Jurgen Appelo —
- Patrick Lencioni —
- Игорь Манн —
- Дениел Пинк —
Оригинал статьи на .
