Как не стоит говорить и поступать с разработчиками

Как не стоит говорить и поступать с разработчиками

Иллюстрация Марии Рыбак

Рекомендации тимлида, проджект-менеджера, SCRUM-мастера.


Статья написана в соавторстве с Романом Мариничем, Scrum Master в JMind, и Андрєм Мирошниченком, Lead Android Developer в JMind.

То, как мы ведем себя с сотрудниками, наши слова и даже интонации — все это влияет на эффективность людей и их желание с нами работать. Согласно исследованию Американского института стресса, стресс на рабочем месте приводит к увеличению добровольной текучки кадров почти на 50%. Часто его причиной становятся не условия труда или сложные задачи, а взаимодействие с руководством.

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

Об этом мы с коллегами из JMind, компании холдинга TECHIIA, говорим в этой статье: чего не стоит делать или говорить своей команде, если вы создаете здоровую атмосферу на рабочем месте.

Мы работаем на разных позициях: CPO, тимлиды направлений. Наши советы и истории дополняют друг друга и будут полезны всем руководителям — от лидов до CTO и тех, кто планирует выйти на эти позиции.

Советы для Project Manager

Не говорите человеку, как делать его работу

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

Если же вы знаете какие-то тонкие приемы в написании куска кода или подходящую библиотеку, и это может помочь коллеге, поделитесь знанием в качестве рекомендации, а не указания. А еще лучше — в формате “что думаешь по поводу использования вот здесь вот этого?”

Не спешите оценивать трудозатратность задачи до того, как услышите мнение разработчика

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

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

Не присваивайте все заслуги и не обвиняйте во всех бедах подчиненных

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

Не наказывайте за ошибки, особенно совершенные впервые

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

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

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

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

Советы для Scrum-майстра

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

Не ругайте коллегу при всех

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

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

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

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

Не забывайте о человеческом

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

Не стоит микроменеджить и «капать на голову» сотруднику

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

А вторая беда — постоянно влезая в мелочи, вы рискуете «съесть» у разработчиков ответственность за качество работы и утонете в рутине и операционке. Команда перестанет сама предлагать решения, все будут действовать по вашим указкам.

Не думайте, что мотивы вашего поведения всем понятны. Всегда аргументируйте свою позицию и решения

Однажды после очередного Backlog Refinement команда дружно сказала, что задача понятна, и на разработку нужно N сторипойнтов. Только впоследствии выяснилось, что понимание некоторых терминов у Product Owner и команды отличались. Ребята реализовали задачу так, как поняли, и это оказалось совершенно не то, что подразумевалось в условии.

Желательно проговаривать каждую мелочь. Мы можем потратить несколько минут (на первый взгляд, лишних), но в итоге cэкономим дни или даже недели.

Эту рекомендацию могу написать только без «не»: всегда помните свои обещания!

Советы для тимлида

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

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

Был такой случай. Один из коллег намного дольше обычного придерживал задачу, при этом на вопрос «все ли в порядке?» продолжал отвечать утвердительно. Так продолжалось какое-то время, пока от него не пришло сообщение в стиле «все пропало».

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

Не будьте слишком критичны. Но и не стоит перехваливать

Постоянный конструктивный диалог дает четкое понимание основных потребностей и настроения сотрудников.

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

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

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

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

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

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

А чем бы вы дополнили наш общий список? Благодаря каким историям у вас появились собственные «не»?

Статьи и литература по теме

Оригинал статьи на dou.ua.

Подписаться на новости
Последние новости
Событие, спродюсированное WePlay Studios, фанаты со всего мира выбрали как лучшее в категории «ИИ, метавселенная и виртуальные события — Развлечения, спорт и музыка»
02.05.2024
Продакшн-компания WePlay Studios и лауреат премии "Грэмми" продюсер Лоуренс "Рэнс" Допсон объединяются для создания контента на культурную тематику.
05.03.2024
Отчет по корпоративной социальной ответственности за 2020-2023 годы
01.02.2024