Полем грядки вовремя, или 5 признаков скрытых проблем в команде

    Проблем в коммуникациях очень много и их решение всегда очень специфично для каждого случая. Сложность с некоторыми проблемами состоит в том, что они скрыты и дают о себе явно знать, когда уже слишком трудно, или поздно, что-то исправлять. Я вспомнил пять случаев, с которыми лично сталкивался. Не все получилось решить, не все решал осознано. Под катом найдёте пять историй, иллюстрирующие пять признаков проблем. Каждую историю я дополнил очень сухой подсказкой об исправлении потому, что реальное решение очень субъективно.

    Начало февраля — хорошее время подумать о весне, скором лете, даче, грядках, больших длинных грядках… Хорошо, что пока февраль, и поэтому поговорим о командной работе. Как там у Толстого в книге «Анна Каренина»? «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». У каждого своё понимание хорошего и плохого. На мой взгляд, у каждой команды, или компании, есть определённые черты отношения внутри коллектива и руководства к своим сотрудникам, которые являются результатом особенностей неосознанного поведения людей. Именно фактор неосознанности делает эти проблемы скрытыми, т.к. часто если человек не видит проблему, то проблемы, как бы, и нет. В реальности получается, что поведение отличаются от того, что декларируется командой, или компанией, но неявно. Вы можете заметить их только после нескольких месяцев работы в компании. Вспомнив похожие проблемы в разных ИТ-компаниях, я составил список таких черт, которые могли бы быстрее выяснить характер существующих проблем и путь поиска их решения.

    1. Разработчики — просто еще один ресурс


    Тип проблемы: компания vs. сотрудник

    Один менеджер сказал мне: «Я отчитываюсь перед CEO и стейкхолдерами. А ты просто разработчик». Имелось ввиду, что на нём лежит большая ответственность, а на мне, как на разработчике, такой ответственности нет. Позже выяснилось, что у него не было собственного мнения о людях, которые были в его подчинении и он просто транслировал идеи своего босса. А его босс не очень тесно общался с разработчиками. В результате, управление было минимальным и в приоритете стояла только отчётность. Из-за этого отношение к людям было такое, как если бы они были винтиками в механизме. Никто не мог сказать это прямо в силу принятых норм, но дела говорили сами за себя. Никто не скажет вам, что ваши цели не важны, потому что потеряют лицо. Но, в то же время, никто не будет учитывать ваши интересы, т.к. твой менеджер точно знает, что именно ты должен делать, как думать и что чувствовать. Когда вы обсуждаете перспективы, вам могут говорить приятные вещи, которые вы хотите слышать. Но реальных действий за этим не следует, и всегда есть причина, почему что-то другое важнее. А если вы начнёте не соглашаться, вас обвинят в том, что вы не слушаете, не коммуникабельны, или, еще хуже, вносите большие риски в проект. Очевидно, что ваш босс отказывается от поиска решения, которое было бы выгодно обоим. Самое простое для него решение — это вы, делающий только то, что сказали. В компании такое отношение к сотрудникам поддерживалось на высоком уровне. В итоге, увеличилась текучка кадров. И ряд ключевых людей (разработчиков и продукт-овнеров (eng.: product owner)) покинули компанию.

    Подсказка: ищите синергию


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

    2. Кто-то постоянно следит за вашими ошибками


    Тип проблемы: менеджер vs. сотрудник

    Это нормально, когда люди на работе пытаются помочь товарищам по команде, открыто и с уважением обсуждая проблемы. Эта атмосфера поддержки ломается, если её неправильно используют управляющие роли (тимлиды или менеджеры). Ситуация может развиваться непреднамеренно и сильнее всего может быть заметна с участием менеджера, нежели тимлида. Например, менеджер спрашивает вас, что бы вы хотели улучшить в команде. Вы, из лучших побуждений, рассказываете, в куче с остальным, что было бы хорошо, если бы Вася писал больше юнит тестов. Менеджер при встрече с Васей говорит ему, как бы делая укор, что тот не пишет юнит тесты. Этот пункт может быть пунктом, скажем, на перформанс ревью. Вася, видя претензии менеджера попытается выяснить у коллег что нет так, но все говорят, что всё нормально. Потому, что для коллег проблемы юнит тестов, как таковой, нет. Но в этот момент доверие начинает ухудшаться. Для Васи выглядит всё так, словно кто-то за его спиной его чернит в глазах у менеджера, но в глаза ему не говорит. Ситуация плоха тем, что никто специально его не чернит. Далее становится хуже, т.к. если менеджер не может решить эту проблему, то в такой атмосфере усиливается незащищенность людей в команде и заставляет их постоянно доказывать что-то перед другими.

    Подсказка: настаивайте на открытом обсуждении


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

    3. Всегда есть тот, кто виноват в ошибке


    Тип проблемы: команда vs. сотрудник

    В то время, как анализ ошибок является нормой, постоянное напоминание о прошлых ошибках нормальным не является. Сбой может произойти по причине недостатка требований или нехватки знаний, или из-за последовательных сбоев на разных этапах разработки, таких как код ревью, QA, UAT. В этом случае продолжительное внимание к одному человеку, допустившему ошибку, подтрунивание над ним, будет иметь плохой эффект. Если такое поведение является нормой в команде, то могут появляться изгои в команде. Это поведение, обычно, поддерживается кем-то из ведущих ролей. Остальные люди в команде просто подстраиваются и следуют стилю лидера. При отсутствии поддержки «сверху», такое поведение не будет долгим и быстро закончится. Конечно, человек, допустивший ошибку, должен знать об этом и понимать, как можно было её избежать, чтобы не наступать на грабли снова. Но не стоит цеплять на него ярлыки.

    Подсказка: прекратите фокусироваться на ошибках


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

    4. Команда приступает к задачам без описания и планирования


    Тип проблемы: команда vs. заказчик

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

    Подсказка: защищайте команду, а не себя


    Тимлид, или менеджер, должны взять на себя ответственность по защите команды от других менеджеров и заказчиков, сопротивляться их натиску, и не спускать ответственность до уровня команды. Definition of Ready для задач должен помочь менеджерам подготавливать задачи достаточно хорошо. В этом случае это должно стать неукоснительным правилом.

    5. Обход процесса


    Тип проблемы: процессы vs. сотрудники

    В яркой форме я встретил эту особенность в одной молодой компании, где процессы развивались очень быстрыми темпами. В личной беседе босс сказал мне: «У нас есть процесс, но тебе нужно понимать, когда его стоит обойти, чтобы быстрее выполнить задачу». Это правда: иногда обход процесса помогает достичь целей быстрее, и это бывает даже необходимо. Но когда обходить процесс приходится в 50% случаев, сам процесс начинает восприниматься, как некоторая формальность. В этом случае очевидно, что процесс является больше препятствием. С другой стороны, без процесса руководство чувствует себя незащищенным из-за слабого контроля и отсутствия доверия к разработчикам. Как следствие, все понимают проблему, но поменять процесс тяжело из-за бюрократии (требуется согласие всех, это куча митингов, и пр. и пр.). Поэтому некоторые менеджеры могут предложить разработчикам обходить процесс, исходя из лучших мотивов. Но предлагая это, они ставят разработчиков в уязвимое положение, когда любой такой шаг может рассматриваться по-разному в зависимости от людей и случаев.

    Подсказка: следуйте процессу попроще


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

    Увидели что-то похожее? Добавляйте свои случаи комментах.
    Поделиться публикацией

    Комментарии 14

      0
      4 и 5 в нашей компании сплошь и рядом, но я проблем не вижу. Да, стартуем без ТЗ, да, заказчик меняет требования. Но всё это не бесплатно…
      Зато в статье «токсичные» сотрудники упомянуты только в контексте тимлидера, но, тимлидерам-то это зачем? Они за разработку головой отвечают, им надо, чтобы команда работала по-полной. А вот среди команды «токсичные» часто бывают, и если тимлидер не противодействует, то атмосфера к команде становится невыносимой.
        0
        Ой, ну это просто очередная статья на тему тонкости душевной организации разработчика и неотёсанности остальных. Такие статьи обычно пишут люди, не работавшие лидами даже небольшой команды и никогда не отвечавшие ни за кого, кроме себя. Бизнес заставляет кодить так, как ему надо, а не как красиво и изящно — подумаешь, потрачу не 40 часов, а 160, зато с душой! Дизайнеры заставляют делать тяжёлый и избыточный интерфейс — подумаешь, миллионам пользователей удобно, но я-то знаю, как лучше! Аналитики заставляют писать громоздкий и неоптимальный код — подумаешь, сроки у них там вывода на рынок и инженеры гарантируют мощности, зато я могу сделать максимально оптимальный код и тратить на 32Мб памяти меньше! Вообще не буду с ними работать, они не понимают ничего и токсичные, а я вот молодец, я не винтик механизма, я его мозг, главный нерв и вообще.
          0
          вы сваливаете всё в одну кучу. проблемы бизнеса можно решать по-разному. но есть принципы, которых, на мой взгляд, следует придерживаться, если хочется построить нормальную крепкую команду. и это не относится к проблемам разряда «потрачу не 40 часов, а 160, зато с душой!».
          но вы сами решаете что вам и вашей команде важно.
            0
            Безусловно, в бизнесе в первую очередь важны люди, если бизнес хочет долго и плодотворно зарабатывать деньги, а не выжимать все соки сегодня или не сидит на нефтяной трубе. Но в статье крайне однобокий взгляд и явное отсутствие понимания, как работает бизнес за пределами тестовой среды и репозитория с боевым кодом. Из-за такого непонимания 90% разработчиков считают всех вокруг токсичными, а себя неоценёнными гениями, и лишь 10% готовы хотя бы послушать другую сторону (цифры из личного опыта).
              0
              не понятно на каком основании вы делаете вывод об однобокости. это ваша субьективная оценка. предоставьте факты, тогда обсуждение будет предметным. хотя бы примеры какие-то.
                0
                Странный вопрос. На основании своего карьерного опыта по обе стороны баррикад, например. Скан трудовой книжки прислать?
                Какие примеры? Всё уже сказано – если разработчик не имеет опыта хотя бы руководства маленькой командой, то пишет вот такие вот статьи. Не понимаю, что сюда добавить. Примеры, когда отношение к людям как к винтикам оправдано? Когда нужно делать плохой код и быстро?
                  0
                  Хм… Это ваш опыт вам подсказывает так однобоко воспринимать информацию в статье?
                  Спасибо за мнение.
                    0
                    Напомните номер ИСО, регламентирующего объективность восприятия статей?
                    0
                    а не только у вас есть опыт «по обе стороны баррикад».

                    Я, кстати могу понять единичные случаи, когда нужно «фигачить код» и нарушать «процессы». У бизнеса бывают такие «дни, которые определяют года», так что не грех и напрячься и срезать углы.
                    Но это совершенно точно не должно быть систематическим явлением, потому что это прямой путь к выгоранию.
                    Отношение же к людям как «к винтикам» или вспоминать про баг, который был сделан полгода тому назад — это уже за гранью добра и зла, а разве что для сект БДСМ (ну т.е. если это и было целью: давать людям деньги за добровольное полоскание мозгов и для личного самоутверждения — тогда ОК).
                      0
                      Так и я о том же. Нарушать хороший процесс это, конечно, только в случае аврала. Я говорил изначально о том, что программисты нередко считают себя выше бизнес-требований и как раз процессов, потому что аналитик «не кодит 10 лет и не понимает ничего».

                      А что плохого в отношении как к винтикам, если винтики вовремя смазывают хорошим маслом, чистят антикоррозийным покрытием и крутят аккуратно и исключительно подходящим ключом с динамометром?
                      0
                      Это не только для разработчиков.
                      В силу отсутствия определенных управленческий навыков и культуры в русскоязычном бизнесе, обычный карьерный путь начинается так — как только человек становится руководителем кого-то, кроме себя и набивает первые шишки, он начинает мнить, что познал управленческий Дзен, и что главная цель руководителя заключается в том выдавливать из команды результат. И что в неком «реальном» нешаблонном не стендовом мире вся эта теория управления не работает. Начальник все равно должен быть немного тираном, а работник обязательно должен быть немного дураком. Даже если вслух об этом не говорят.

                      Потом, по мере движения вверх, некоторые все же возвращаются к шаблонам и стендам, которые уже не кажутся такими наивными и неработающими.
            0
            .
              0
              Ну вот хорошо же написано.

              Есть момент:
              Подсказка: ищите синергию

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

              К сожалению, этот ключевой принцип, который в цивилизованном мире бизнеса звучит как «компания должна строиться вокруг целей и ценностей», тут не будет принят, или будет принят в штыки. Но я глубоко убежден, что в постсовковой ментальности ломать стереотипы и старые модели управления нужно именно путем вбивания в голову этого принципа. Миссия и ценности компании должны быть выше детский комплексов топ-менеджмента.
                0
                для начала «миссия и ценности компании» должны просто быть. Увы, пока что я чаще наблюдаю либо «зарабатывать денег» и «работать работу на работе», либо что-то вроде Сима-Ленда, которые с трудом отличить от секты

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое