Третий в нашей серии конспект по книге о рабочем общении «Team Geek: идеальная IT-компания» Брайана Фитцпатрика и Бена Коллинз-Сассмэна выводит читателя на минное поле: отношения с коллегами, далекими от IT, или того хуже – руководством. Речь здесь пойдет о печальных сценариях: как наладить жизнь в компании, если работа поставлена неэффективно и отношения становятся основным средством удержаться на плаву.

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

Какие формы может принимать плохая организация? Фитцпатрик и Коллинз-Сасмэн приводят несколько самых распространённых вариантов.

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

Какой бы ни была обстановка в компании – хаотичной, давящей или излишне официозной – итог один: в ней трудно вести продуктивную работу. Просто общаться с коллегами из других отделов, следуя принципам скромности, доверия и уважением, недостаточно, чтобы добиваться своих целей. У разработчиков из нездоровой корпоративной среды (а таких, как сожалению, большинство) нет иного выхода, как идти на хитрости и уловки.

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

Определить «неофициальные» границы допустимого

Суть этой техники в том, чтобы держать в голове поговорку:

Иногда проще попросить прощения, чем разрешения.

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

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

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

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

Создавать альтернативы

Коллинз-Сассмэн делится с читателями девизом, который услышал от своего наставника:

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

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

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

Подобная схема проведения решения снизу вверх, впрочем, имеет и свои недостатки. Так, автору, скорее всего, бесполезно будет рассчитывать на признание за свою идею – она понемногу превратится в глазах окружающих в нечто витающее в воздухе. Может выйти и так, что какой-нибудь ушлый коллега выдаст ее за свою. Здесь можно вспомнить о том, что говорилось в самом начале: разработка ПО – командный вид спорта. Если то, что вы пытаетесь внедрить в жизнь, в самом деле облегчит всем жизнь и даст хорошие результаты, возможно, стоит поступиться лаврами.

Найти оптимальное место в вертикали

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

Очень многие отвечают на этот вопрос отрицательно уже потому, что им претит мысль о том, чтобы играть в карьерные игры и «показывать товар лицом». К тому же те, кто в общем удовлетворен своими обязанностями, зарплатой и командой, часто просто не видят смысла создавать для себя лишние сложности. Всё это справедливо, но нельзя забывать о важной закономерности: чем ниже человек стоит в «пищевой цепочке», тем он уязвимее перед лицом перемен. Иными словами, для сотрудника из низших рангов гораздо выше вероятность внезапно оказаться в совсем другой команде, проигрышном проекте или у некомпетентного начальника без надежды что-либо оспорить. И напротив: чем выше должность, тем больше появляется возможностей управлять своей судьбой.

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

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

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

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

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

Печальная реальность такова, что при всей важности оборонительной работы, далекие от IT люди, как правило, считают ее в лучшем случае второстепенной. Из-за своей «подкапотной» природы она просто не воспринимается как нечто стоящее больших затрат ресурса. Если отдельный разработчик или команда больше половины времени тратят на оборонительные задачи, то у людей со стороны может создаться впечатление, что они вообще ничего толком не делают и продукт не развивается.

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

Найти оптимальное место в горизонтали

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

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

Помощь другим – сама по себе неплохая вещь: она поднимает нас в собственных глазах и позволяет научиться чему-то новому. Но помимо этого ее можно считать своего рода инвестицией: какие-то из ваших вкладов будут безвозвратно утрачены, другие принесут небольшие деньги, а третьи когда-нибудь обернутся огромными дивидендами. Кстати говоря, здесь есть еще один интересный момент: «счет взаимовыручки», как правило, не обнуляется даже при уходе из компании – если увольнение проходило более-менее мирно, возможность попросить помощи у бывших коллег остается за вами.

Другой составляющей страховочной сетки являются ценные знакомства – хотя Фитцман и Коллинз-Сассмэн вкладывают в это понятие свой смысл. Речь здесь идет не о том, чтобы стараться втереться в руководящие круги или дружить с друзьями начальника, а о том, чтобы иметь прямой доступ к «информационным центрам» компании. К таким центрам относятся две разновидности сотрудников:

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

Эвакуироваться

Можно пытаться адаптироваться под систему, можно пытаться ее переделать, но в конечном итоге существует грань, за которой всё это теряет смысл. Если на создание условий для работы приходится тратить больше сил, чем на саму работу, и улучшений не видно – ни к чему наращивать энтропию. Бывает, что с работой просто не складывается, и всегда лучше прийти к этому выводу первым.

Если у вас опускаются руки – перестаньте расходовать ресурсы на борьбу и перебросьте их на подготовку к отступлению: обновите резюме, подтяните какие-то навыки, начните расспрашивать друзей о вакансиях. IT дает одно большое преимущество – это востребованная сфера, поэтому у разработчиков гораздо больше свободы и возможностей управлять своей карьерой, чем во многих других профессиях. Поэтому никогда не забывайте об опции «выйти из игры».
*
Двигаясь от центра к периферии, мы прошли путь ‘индивид – команда – компания’. Следующий, и последний слой человеческого измерения – внешний мир, куда уходят создаваемые разработчиками продукты.

Брайан Фитцпатрик, Бен Коллинз-Сассмэн «Team Geek: идеальная IT-компания»: выживание в неидеальной корпорации