Взгляд архитектора софта на проблемы, которые не решаются кодом

Если бы мне лет 15 назад сказали, что я буду писать про корпоративную культуру и культуру управления, я бы сильно удивился. Скорее всего, подумал бы: «Какая ещё культура? Я разработчик софта в IT-компании. Нужно код шарашить и алгоритмы разрабатывать. А ещё нужно много размышлять и анализировать, потому что тогда код получается значительно лучше и алгоритмы эффективнее».

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

Итак, сегодня про культуру.

В этой статье не будет стройного последовательного изложения. Скорее, это будет набор «этюдов», несильно связанных между собой, но ложащихся на общую глобальную тему.

Мысли, которые немного – или сильно – в стороне от генеральной темы, буду убирать под спойлеры (разворачиваемые блоки).

Поехали!

Сотрудник – не собственность менеджера

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

Вот реальная история из этой корпорации. Мне посчастливилось (или не посчастливилось) наблюдать её со стороны.

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

Минут через 10 в их разговор вмешивается менеджер второго разработчика, сидевший неподалёку. Причём это был менеджер второго звена, то есть «старший менеджер». И он обращается к первому «эксперту»:

— Не отвлекай его. Поговори, лучше, со мной. Он важным делом занят.

Помню, когда я это услышал, мне показалось, что я то ли сплю, то ли в злую сказку попал.

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

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

Хороший менеджер знает, что сотрудник ему не принадлежит. Более того: менеджер не распоряжается временем сотрудника. Неужели два сотрудника уровня «эксперт» не смогут сообразить, как им правильно распорядиться своим временем?

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

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

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

Ещё пример на тему менеджерского собственничества. Каждый раз, когда в одной транснациональной корпорации появляется новый сотрудник, его менеджер объявляет об этом с помощью e-mail рассылки по сотрудникам соответствующего департамента (а это сотни человек). Какой бы менеджер в каком бы департаменте ни написал такое письмо, в нём неизменно есть следующие слова: “Vasya Pupkin reports directly to me”. То есть «Вася Пупкин подчиняется напрямую мне». Ну или если вдруг не напрямую, то описывается тот способ подчинения, который справедлив в отношении Васи Пупкина. (Вася Пупкин – это имя нового сотрудника. Если его зовут не Вася Пупкин, то будет другое имя, конечно же).

Признаться, это единственная известная мне компания, где при найме каждого сотрудника делается акцент на том, кому он принадлежит подчиняется. В компаниях со здоровой корпоративной культурой про подчинение кого-то кому-то почти никогда не говорят. Вместо этого говорят о принадлежности к какой-то команде. Например, в рассылке о найме сотрудника будет сказано, что «У нас в такой-то команде появился Вася Пупкин. Прошу любить и жаловать. В ближайших планах Васи то-то и то. И т.д и т.п.» Узнать же менеджера Васи Пупкина или Люси Тапочкиной, если вдруг понадобится, всегда можно через корпоративные системы, в которых есть доступ к оргструктуре (Outlook, Workday и тому подобное).

«Бизнес хочет»

Обожаю эту фразу. Уверен, очень многие её неоднократно слышали.

Фраза из заголовка – это про ещё один симптом нездоровой корпоративной культуры – про манипулятивный менеджмент.

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

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

В последнее время во многих крупных компаниях стали привычными фразы «бизнесу надо», «бизнес хочет». Так вот… у этого «бизнеса», который «хочет», всегда есть имя и фамилия. Почти всегда это один-единственный человек. Чаще всего из маркетинга или продаж. Например, старший директор или вице-президент по продажам. Соответственно, в компаниях, где хорошо прижилась фраза «бизнес хочет», позиции сэйлов и маркетологов неоправданно сильны, а позиции разработчиков наоборот чрезмерно слабы. Ибо если старший директор по продажам объявил себя «бизнесом» (и все вокруг в это поверили), то подразумевается, что всем остальным надо бежать и беспрекословно исполнять то, что он скажет/закажет. Потому что это «бизнесу» надо. То есть масштабной структуре, а не одному-единственному человеку.

Если же во фразе «бизнес хочет» всегда заменять слово «бизнес» на имя конкретного человека – «Вася Пупкин хочет» – то получатся совсем другие дискуссии. Из них пропадёт оттенок безапелляционности. Потому что когда «бизнес хочет», то здесь вообще не до оценок и не до дискуссий; надо просто пулей нестись и исполнять, иначе бизнесу капец…

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

«Бизнес хочет» – это хоть и грязная манипуляция, но достаточно умелая. Поэтому она и прижилась так широко. А вот пример грязной, но менее умелой манипуляции.

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

И получилось так, что всего за полгода до выхода конечного продукта в природе существовала только экспериментальная версия, а для продуктовой версии не было даже высокоуровневого дизайна. Меня позвали, чтобы разработать детальную архитектуру конечного решения. То есть даже не то, чтобы позвали… Я на тот момент работал в другом подразделении и над другими продуктами. Так вот: мне предписали поставить на паузу мои текущие работы и прикомандировали к подразделению, разрабатывавшему тот самый новый продукт.

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

И вот на мои возражения о том, что за полгода спроектировать и реализовать конечный продукт почти нереально, руководитель разработки заявляет:

— Слушай, есть немасштабируемое решение [это он имел в виду экспериментальную версию, сильно зависящую от ручных операций]. В чём проблема сделать из него масштабируемое решение [то есть полностью автоматическое, с пропускной способностью в сотни тысяч раз выше, чем ручное]?

Действительно, в чём проблема? Где здесь манипуляция? Звучит так, будто всё уже есть. Остаётся только внести «маааалюсенький» такой штрих. Но есть одно маааалюсенькое «но».

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

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

Пожары в том подразделении, куда меня временно прикомандировали, случались часто, а квалифицированных сотрудников вечно не хватало. Оно и понятно почему…

Манипулятивный менеджмент, с которым невозможно конструктивно обсуждать проблемы – большой стресс для сотрудников. Вот ещё один пример.

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

— Вы вот софт делаете, а я делаю на нём бабки!

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

Финишируем

Финишируем со статьёй, но не с темой. У меня есть ещё чего сказать о корпоративной культуре и её «поломках». Так что впереди ещё одна статья на эту тему. В следующий раз поговорим про капризных разработчиков, самодурство и корпоративные интриги…

Спасибо всем читателям! До встречи в эфире!

Также эта статья доступна на английском (ибо коллеги частенько просят английский перевод): [ссылка на перевод появится в течение одного-двух дней]