Ева Беляева, Security Vision
Введение
Раньше мы уже рассказывали, как непросто подружить разработчиков и AppSec, безопасников и коллег из ИТ. На этот раз давайте посмотрим, какие сложности могут возникнуть внутри компании при взаимодействии людей с разным подходом к работе: стратегическим и операционным.
Для упрощения сведем разбор к разбору основного конфликта внутри любой проектной деятельности – между теми, кто ставит задачи, и теми, кто занимается их реализацией. Проще говоря, между руководством и подчиненными.
Возникают такие вещи в компаниях любой направленности и размера, и судя по тому, что мне в том числе рассказывают коллеги из других организаций, ситуация системная.
Почему это проблема
Очень часто при постановке задачи и обсуждении результата возникает несовпадение между желаемым и фактическим, и обе стороны диалога не могут друг друга услышать и понять.
Возможно, если кто-то из противоборствующих сторон сможет поставить себя на место другой, то накал и градус негатива немного снизится, и можно будет лучше понять собеседника и скорректировать свою работу в более продуктивную сторону.
Ведь если мы говорим про стратегию – мы имеем в виду далеко идущие планы, обещания и деньги. Глобальные цели, без которых компания не может не просто развиваться и расти, а в целом – существовать и содержать сотрудников в штате.
Операционка же где-то ниже, там, где простая казалось бы задача обрастает мишурой более мелких задач и раскладывается на более мелкие подзадачи, каждая из которых способна застопорить весь процесс.
Рассмотрим на примерах, как такие ситуации возникают и что можно сделать.
Рабочие конфликты
Если вы хоть раз присутствовали на встрече с приемкой-сдачей работ, вы точно сталкивались с тем, что бывает после: подчиненные в случае неудачи уходят расстроенные и продолжают накручивать себя в курилке и на кухнях: как же так, мы потратили часы, недели и дни, перерабатывали, выбились из сил, и все было зря? В то же время на самой встрече руководство в открытую выражало свое отношение к проблеме: у вас была основная задача, вы потратили много времени и зачем-то вместо нее сделали две других, что с вами не так?
В итоге страдают все: те, кто ждал исполнения договоренностей в срок, задаются вопросом, что пошло не так и почему эти исполнители раз за разом проваливают поставленные задачи, а те, кто находится по другую сторону – выгорают и или опускают руки, перестав стараться, или вкладывают все больше и больше сил, туда, где, по их мнению, они больше всего нужны (но, к сожалению, не туда, куда от них ожидается).
Да, все проблемы чаще всего возникают из-за недостатка в коммуникации. Но дело в том, что не всё возможно проговорить каждый раз; иногда люди полагаются на так называемую область подразумеваемого: то, что по умолчанию уже должно быть принято обеими сторонами. Так, например, руководитель думает, что очевидно следующее: если он назначил задаче особый приоритет, она должна быть поставлена на первое место и исполнитель должен безотлагательно сообщать о возникающих проблемах. У работника же мысль иная: например, ни в коем случае нельзя давать понять туда, наверх, о том, что что-то идет не так.
Несмотря на занимаемую должность, я чаще оказываюсь внутри той самой рутины и операционки – когда вы с командой стараетесь, а там, наверху, не понимают, почему так медленно или почему так плохо. Но в силу специфики работы нередко получается взглянуть на ситуацию со стороны и понять, где не прав именно ты. Иногда получается увидеть эти моменты собственного провала и транслировать это в команду, возвращая ее к реальности: мы действительно накосячили и вот почему нас неправильно понимают. Рассмотрим подробнее подобные заблуждения.
Распространенные ошибки
Проблемы исполнителей можно разделить на два основных вектора: когда перестарались и когда недоуточнили. Зачастую конфликт складывается, когда поведение было выстроено сразу по двум из них.
Например, у исполнителя есть задача, большая и сложная. Да, ему только что сказали, что эта задача имеет самый высокий приоритет. Одновременно с этим в его беклоге на этот спринт есть еще три задачи, но попроще и с более низким приоритетом. Как начинается проблема? Исполнитель начинает с большой задачи и понимает, что он в тупике. Сказать об этом ему почему-то стыдно, а сидеть сложа руки не позволяет ответственность. Что, по мнению руководителя, должен этот исполнитель сделать по умолчанию? Конечно же, эскалировать проблему выше и сигнализировать о том, что ему нужна помощь. Но исполнитель боится подвести руководство, переживает за свою позицию в компании... и поэтому берется за три других задачи, чтобы получить хоть какой-то результат. В итоге исполнитель внутри себя спокоен: хоть он и не сделал первую задачу, он все еще компетентен и смог сделать в такой короткий срок аж три других! И он не понимает, почему им недовольны. Да, задача была важная и ему об этом сказали, но разве не все они важны?
Еще одна проблема может возникнуть тогда, когда исполнитель действительно сосредотачивается на основной задаче, но для ее решения ему нужно справиться с десятком побочных задач: например, запросить необходимые доступы или отдебажить одно место в коде, которое ну никак не может пройти юнит-тесты. Да, обычно он тратил на подобные задачи меньше времени, но сейчас что-то пошло не так. Дело может быть в чем угодно, и не всегда это проблемы с компетенцией конкретного исполнителя – возможно, задача не была правильно заэстимирована или при ее постановке не учли ее настоящий объем. Может быть и такое, что выполнение данной конкретной задачи цепляется за несколько предыдущих, и если они сделаны были плохо, то придется потратить время то, чтобы все отрефакторить там, а уже потом вернуться к действительности. Что произойдет при сдаче? Руководитель услышит, что «задача опять не готова», и для него это абсолютно не прозрачно и до конца не понятно – ему задачу пообещали выполнить, все договорились о сроках, однако презентую ему в лучшем случае половину, и то не рабочую. А времени было потрачено очень много, и на что? Даже не на другие задачи. При этом исполнители вымотаны, перегружены и раз за разом между собой обсуждают и не могут понять: а почему их не понимают? Почему их нагрузку не видят? И продолжают требовать от них все больше и больше, не видя, как им тяжело.
Ну и третий вид конфликта – когда позиция «сделать хорошо» начинает спорить с позицией «просто сделать». Предположим, были совершены обе предыдущие ошибки: сначала вместо основной задачи делались менее важные, а когда к большой задаче все же приступили, оказалось, что там не все так просто, и вместо недели она растянулась на два месяца, еще и с переработками. Руководитель со своей стороны меняет вводные: не нужно успевать сделать задачу в ее изначальном объеме и постановке, сроки скоро совсем сгорят, и нужно закрыть задачу уже как-нибудь. Исполнитель, привыкший к жесткой и подробной приемке, недоумевает и видит в этом какую-то уловку: он думает, если он не сделает задачу идеально, это не засчитается, новую постановку можно проигнорировать и продолжать делать по-старому. Он ведь хочет сделать свою работу качественно, даже в ущерб срокам, потому что посчитал это важнее: как же так мы отгрузим что-то недостаточного качества? Конфликт нарастает. Руководство смягчает требования, но результата так и не получает. Исполнитель выбивается из сил, но никак не может сдать свою работу. В конечном итоге недовольны все.
Фасилитируем и коммуницируем
Как можно понять из примеров, нередко «плохой» или «не тот» результат, как ни парадоксально, может быть вызван желанием сделать как лучше. И если забуриться в операционку и смотреть на задачи именно так, то с этим можно даже согласиться.
Но если вынырнуть чуть выше, становится понятно, что при этой деятельности не были учтены глобальные цели и даже роадмап компании: без стратегии не ясно, почему эта задача важна, а эта – не очень. Почему этой частью проверок на время можно пренебречь, почему для какой-то задачи вообще не понадобилось бы перерабатывать, если не делать что-то «не то».
Все чаще мы, видя подобные конфликты на старте, пока они еще не разгорелись до пожара, пытаемся как можно более понятно донести важность и эксклюзивность поставленного ТЗ; на каждом этапе стараемся помочь тому, что испугался или застеснялся – и помочь промониторить ситуацию, узнать, не нужна ли помощь и есть ли проблема, которую мы не учли. Причем интересно то, что боятся сказать о проблеме необязательно молодые и неопытные – так могут повести себя и те, на чей результат раньше можно было безоговорочно положиться и знать, что человек надежен и последователен.
Это работает в обе стороны – если не рассказывать руководству, почему именно было тяжело и сложно, они этого и не поймут. В нашей компании каждый сотрудник в большей или меньшей степени все-таки работает руками, несмотря на должность. Это позволяет самому понять, почему процесс устроен так, как устроен, и что пошло не так у подчиненного – ты сам наступаешь на те же грабли или видишь недостатки в коммуникации или постановках задач. Этот опыт дает возможность поговорить на одном языке и добавить к стратегии немного практики.
Выводы
Бывают ситуации в работе, когда мы неосознанно подставляем друг друга из лучших побуждений. Первый шаг к тому, чтобы этого избежать – представить себя на месте другого и посмотреть, какая на самом деле цель у наших задач. Второй шаг – дать понять собеседнику максимально прозрачно тонкости своей работы и мотивации.
Если проговаривать проблемы сразу же, как они возникают, не бояться сообщать о трудностях – со временем получится найти общий язык и стать продуктивнее без того, чтобы перерабатывать и выгорать.
.jpg)
