Проблем в коммуникациях очень много и их решение всегда очень специфично для каждого случая. Сложность с некоторыми проблемами состоит в том, что они скрыты и дают о себе явно знать, когда уже слишком трудно, или поздно, что-то исправлять. Я вспомнил пять случаев, с которыми лично сталкивался. Не все получилось решить, не все решал осознано. Под катом найдёте пять историй, иллюстирующие пять признаков проблем. Каждую историю я дополнил очень сухой подсказкой об исправлении потому, что реальное решение очень субъективно.
Начало февраля — хорошее время подумать о весне, скором лете, даче, грядках, больших длинных грядках… Хорошо, что пока февраль, и поэтому поговорим о командной работе. Как там у Толстого в книге «Анна Каренина»? «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». У каждого своё понимание хорошего и плохого. На мой взгляд, у каждой команды, или компании, есть определённые черты отношения внутри коллектива и руководства к своим сотрудникам, которые являются результатом особенностей неосознанного поведения людей. Именно фактор неосознанности делает эти проблемы скрытыми, т.к. часто если человек не видит проблему, то проблемы, как бы, и нет. В реальности получается, что поведение отличаются от того, что декларируется командой, или компанией, но неявно. Вы можете заметить их только после нескольких месяцев работы в компании. Вспомнив похожие проблемы в разных ИТ-компаниях, я составил список таких черт, которые могли бы быстрее выяснить характер существующих проблем и путь поиска их решения.
1. Разработчики — просто еще один ресурс
Тип проблемы: компания vs. сотрудник
Один менеджер сказал мне: «Я отчитываюсь перед CEO и стейкхолдерами. А ты просто разработчик». Имелось ввиду, что на нём лежит большая ответственность, а на мне, как на разработчике, такой ответственности нет. Позже выяснилось, что у него не было собственного мнения о людях, которые были в его подчинении и он просто транслировал идеи своего босса. А его босс не очень тесно общался с разработчиками. В результате, управление было минимальным и в приоритете стояла только отчётность. Из-за этого отношение к людям было такое, как если бы они были винтиками в механизме. Никто не мог сказать это прямо в силу принятых норм, но дела говорили сами за себя. Никто не скажет вам, что ваши цели не важны, потому что потеряют лицо. Но, в то же время, никто не будет учитывать ваши интересы, т.к. твой менеджер точно знает, что именно ты должен делать, как думать и что чувствовать. Когда вы обсуждаете перспективы, вам могут говорить приятные вещи, которые вы хотите слышать. Но реальных действий за этим не следует, и всегда есть причина, почему что-то другое важнее. А если вы начнёте несоглашаться, вас обвинят в том, что вы не слушаете, не коммуникабельны, или, еще хуже, вносите большие риски в проект. Очевидно, что ваш босс отказывается от поиска решения, которое было бы выгодно обоим. Самое простое для него решение — это вы, делающий только то, что сказали. В компании такое отношение к сотрудникам поддерживалось на высоком уровне. В итоге, увеличилась текучка кадров. И ряд ключевых людей (разработчиков и продукт-овнеров (eng.: product owner)) покинули компанию.
Подсказка: ищите синергию
Это нормально, что у людей есть свои личные цели, а у компании — свои. Частно, они не совпадают, но важно разобраться на сколько сильно человек и компания расходятся в целях. Находя синергию с сотрудниками, вы умножаете выигрыш по сравнению со случаем, когда люди просто делают то, что им говорят.
2. Кто-то постоянно следит за вашими ошибками
Тип проблемы: менеджер vs. сотрудник
Это нормально, когда люди на работе пытаются помочь товарищам по команде, открыто и с уважением обсуждая проблемы. Эта атмосфера поддержки ломается, если её неправильно используют управляющие роли (тимлиды или менеджеры). Ситуация может развиваться непреднамеренно и сильнее всего может быть заметна с участием менеджера, нежели тимлида. Например, менеджер спрашивает вас, что бы вы хотели улучшить в команде. Вы, из лучших побуждений, рассказываете, в куче с остальным, что было бы хорошо, если бы Вася писал больше юнит тестов. Менеджер при встрече с Васей говорит ему, как бы делая укор, что тот не пишет юнит тесты. Этот пункт может быть пунктом, скажем, на перформанс ревью. Вася, видя претензии менеджера попытается выяснить у коллег что нет так, но все говорят, что всё нормально. Потому, что для коллег проблемы юнит тестов, как таковой, нет. Но в этот момент доверие начинает ухудшаться. Для Васи выглядит всё так, словно кто-то за его спиной его чернит в глазах у менеджера, но в глаза ему не говорит. Ситуация плоха тем, что никто специально его не чернит. Далее становится хуже, т.к. если менеджер не может решить эту проблему, то в такой атмосфере усиливается незащищенность людей в команде и заставляет их постоянно доказывать что-то перед другими.
Подсказка: настаивайте на открытом обсуждении
Тут следует напрячься именно менеджеру. Во-первых, не каждая жалоба, реально является проблемой. Во-вторых, следует прислушаться к сотруднику, т.к. он может давать намеки на подобную ситуацию. И в-третьих, менеджер должен поощрять людей говорить о проблемах только в присутствии другого человека. Причины и факты обеих сторон должны быть приняты во внимание.
3. Всегда есть тот, кто виноват в ошибке
Тип проблемы: команда vs. сотрудник
В то время, как анализ ошибок является нормой, постоянное напоминание о прошлых ошибках нормальным не является. Сбой может произойти по причине недостатка требований или нехватки знаний, или из-за последовательных сбоев на разных этапах разработки, таких как код ревью, QA, UAT. В этом случае продолжительное внимание к одному человеку, допустившему ошибку, подтрунивание над ним, будет иметь плохой эффект. Если такое поведение является нормой в команде, то могут появляться изгои в команде. Это поведение, обычно, поддерживается кем-то из ведущих ролей. Остальные люди в команде просто подстраиваются и следуют стилю людера. При отсутствии поддержки «сверху», такое поведение не будет долгим и быстро закончится. Конечно, человек, допустивший ошибку, должен знать об этом и понимать, как можно было её избежать, чтобы не наступать на грабли снова. Но не стоит цеплять на него ярлыки.
Подсказка: прекратите фокусироваться на ошибках
Дискуссия о сбоях должна прекратиться сразу после того, как сделаны все выводы. Товарищи по команде должны чувствовать поддержку в такой ситуации.
4. Команда приступает к задачам без описания и планирования
Тип проблемы: команда vs. заказчик
Этап планирования важен, и никто не скажет вам, что вы не должны его делать. В то же время, команда может испытывать недостаток полномочий, или недостаток поддержки со стороны руководства, чтобы отодвинуть задачи, которые не имеют описания. Руководство может сказать, что они очень сожалеют и признают ошибки в планировании, которые заставили их принять соглашения, которые нельзя откладывать. В таких условиях разработчики являются теми, кто платит окончательную цену. Руководство будет снова и снова повторять одни и те же ошибки, потому что разработчики просто делают то, что им было сказано. В то же время, все сохраняют лицо, потому что есть формальное признание проблемы и обещание её исправить… когда-нибудь. В ходе работы разработчики постоянно сталкиваются с ситуацией, когда что-то не описано в задачах. Они начинают отставать от графика, спешить и чувствовать постоянное давление со стороны руководства. В итоге, разработчики всегда крайние.
Подсказка: защищайте команду, а не себя
Тимлид, или менеджер, должны взять на себя ответсвенность по защите команды от других менеджеров и заказчиков, сопротивляться их натиску, и не спускать ответственность до уровня команды. Definition of Ready для задач должен помочь менеджерам подготавливать задачи достаточно хорошо. В этом случае это должно стать неукоснительным правилом.
5. Обход процесса
Тип проблемы: процессы vs. сотрудники
В яркой форме я встретил эту особенность в одной молодой компании, где процессы развивались очень быстрыми темпами. В личной беседе босс сказал мне: «У нас есть процесс, но тебе нужно понимать, когда его стоит обойти, чтобы быстрее выполнить задачу». Это правда: иногда обход процесса помогает достичь целей быстрее, и это бывает даже необходимо. Но когда обходить процесс приходится в 50% случаев, сам процесс начинает восприниматься, как некоторая формальность. В этом случае очевидно, что процесс является больше препятствием. С другой стороны, без процесса руководство чувствует себя незащищенным из-за слабого контроля и отсутствия доверия к разработчикам. Как следствие, все понимают проблему, но поменять процес тяжело из-за бюрократии (требуется согласие всех, это куча митингов, и пр. и пр.). Поэтому некоторые менеджеры могут предложить разработчикам обходить процесс, исходя из лучших мотивов. Но предлагая это, они ставят разработчиков в уязвимое положение, когда любой такой шаг может рассматриваться по-разному в зависимости от людей и случаев.
Подсказка: следуйте процессу попроще
Возможно, вам не нужен процесс, или правила. Вместо этого вам, может быть, нужны только рекомендации о том, как что-то делать с возможностью различного выполнения. Ну или вы можете подумать об официальном процессе обхода стандартного процесса, для некоторых случаев. Но в таком случае нужен ли вам тот процес, который медленнее?
Увидели что-то похожее? Добавляйте свои случаи коментах.
Автор: ETman
