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

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

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

Рекомендации тимлида, проджект-менеджера, 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.

Подписаться на новости
Последние новости
Співзасновник ENESTECH Software Сергій Пуріш обійняв посаду CEO компанії. Він замінив Ельчина Алієва, який вирішив розвивати власний бізнес.
27.03.2023
Українська контент-продакшн компанія WePlay Esports, що входить до холдингу TECHIIA, стала офіційним партнером проєкту i am u are. Він створений задля репрезентації у світі сучасної України та її креативної економіки. Перший захід пройде у Нью-Йорку з 24 по 26 березня 2023 року.
23.03.2023
Официальные плюшевые Рисенок и Квусь уже появляются на полках крупнейших украинских сетей магазинов «Будинок Іграшок», «Антошка», «Эпицентр», Myplay и Fragstore. Героев мультфильма «Мавка. Лесная песня» изготовила украинская компания WP Merchandise.
15.03.2023