Что такое неинтересная работа?

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

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

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

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

Вообще на определённом этапе своего профессионального развития я сформулировал для себя принципы, которым руководствуюсь в работе. Вот они:

1. Интерес к задаче – главная движущая сила любого проекта.
2. Люди – проекты делают люди, их нужно слушать, с ними нужно договариваться.
3. Рефакторинг – естественная и необходимая часть процесса.
4. Результат – сумма управленческих и технических решений.

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

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

Термин «интерес» довольно расплывчатый, я попробую его уточнить и сформулировать, в чем он выражается для меня.

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

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

Кажется, что это какая-то субъективная штука, целиком и полностью зависящая от исполнителя. Типа – ну и делай хорошо свою работу, кто же тебе мешает? Но на самом деле – нет, в программной разработке это не совсем так. Чаще всего серьезные коммерческие проекты – это результат усилий многих людей. Даже если мы берем только разработчиков (еще есть девопсы, тестировщики и др. участники процесса), то пишут они код сильно по-разному. Кто-то лучше, кто-то хуже, и если за этим не следить, то рано или поздно мы получим безобразно написанную систему. Может быть даже с участками хорошего кода, но в общем и целом проблемную систему с большим техническим долгом.

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

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

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

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

Я смотрел на этот код и думал: какой ужас, как вообще ребята (разработчики) в этом ориентируются? Конечно, я пытался обратить на это внимание, но руководство просто отмахнулось. Какой рефакторинг, что ты?! У нас куча бизнес задач, нам не до рефакторинга. Все разработчики заняты «серьезными задачами» и будут заняты ими еще долго. В общем «не время товарищ», но когда-нибудь потом обязательно…

Наверное, вы уже догадались, мой принцип относительно необходимости рефакторинга столкнулся с суровой реальностью и вдребезги разбился о нежелании / неспособности руководства менять налаженные процессы. Вся эта корпоративная культура – она очень тяжелая, неповоротливая. Никто особо не заинтересован делать безупречно, люди заинтересованы выполнять план, показывать красивый KPI (Key Performance Indicators), а все остальное, в том числе и качество кода, качество проектных решений идет по остаточному принципу. 

Что характерно чудовищная инерционность проявлялась буквально во всем. Решение любого, даже самого мелкого вопроса (типа получения прав доступа) – это какая-то муторная бюрократичная история, которая могла длиться неделями.

Сама разработка была на C# .NET, в основном под Windows, что меня тоже не особо радовало. Хотя я когда-то давно и писал на C#, вновь погружаться во все это Microsoft .NET тряхомудие не было ни малейшего желания. В итоге я как архитектор парил над кодом, в который хоть и периодически заглядывал, но не имел особого желания всерьез в нем разбираться. И код страшненький и технологический стек «не фонтан».

Это было, кстати, одной из моих серьёзных ошибок в этом трудоустройстве. Я искал позицию архитектора, и я ее нашел, но к ней в довесок шел C#. Тогда я не отнесся всерьез к тому, что технологический стек «не мой». Я от этого просто отмахнулся, я же архитектор, код мне писать не нужно, а тех знаний и опыта, которые я получил в свое время, работая на C#, мне должно хватить. Так оно собственно и получилось, знаний и опыт мне хватило, но вот это неприятие, отторжение к используемому в проекте языку, технологическом стеку сыграло свою роль в «неинтересности» проекта.

Ну и окончательно добило мою веру в светлое будущее этого проекта, понимание того, что референс модель, положенная в основу продукта – это практически «the road to hell». Если вы еще не сталкивались с такими моделями, то, скорее всего, вам это и не нужно, а для общего развития можно заглянуть на TMForum и попытаться изучить их SID модель (Shared Information and Data Model). Если, конечно, сможете ее скачать. Забавно, что уже на этом шаге у вас начнутся проблемы. Юзерфрендли доступ? Не, не слышали)

Чтобы было понятно, о чем идет речь, приведу одну из типичных схем, которая описывает спецификацию продукта (ProductSpecification), а точнее взаимосвязи спецификации с другими базовыми элементами.

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

Внимательный читатель наверняка заметит слово framework на сайте TMForum-а и вполне справедливо может возразить, так это же фреймворк, что ты хочешь? Возьми для примера какой-то программный фреймворк, например, PHP-фреймворк типа Yii2, сколько у тебя ушло времени на его освоение? Допустим, много, отвечу я.

А теперь внимание вопрос: кто пользуется фреймворком?  

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

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

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

Примерно 18 человек в команде и все они должны были освоить этот замороченный инструмент моделирования.

И ладно бы 18 человек, ок, я понимаю, что сами по себе исходные данные сложные, это накладывает свои требования к инструментарию. Например, пакет услуг оператора сотовой связи с учетом региональных особенностей может свести с ума своими многочисленными правилами и оговорками для «особым случаев» или «особых регионов» типа Москвы или Крыма. Это действительно сложно моделируется и особенно это сложно делать в каком-то универсальном стиле без привязки к конкретным торговым предложениям.

Даже если это боль целой команды – это хоть и неприятно, но приемлемо. Куда деваться то?! Это относительно справедливая плата за сложность предметной области. Альтернативой является разработка специализированных программных систем под каждое торговое предложение. Не берусь утверждать, что это хуже / дороже, чем универсальный подход, но очевидно, что в этом случае нужен какой-то продвинутый программный инструмент для быстрой разработки шаблонных решений. Уверен, что некоторые телекоммуникационные компании пошли по этому пути. Но это уже совсем другая история.

А теперь представьте, что вся эта история с SID распространяется за пределы команды. У нас это было именно так. Нашему руководству в свое время удалось протащить эту идею на уровне всей компании. То есть SID приняли «в верхах» и согласились, что теперь по этим правилам играют все. Разрабатываемая командой система стала поставщиком услуг по созданию таких моделей. Наша система позволяла создавать сколь угодно сложные модели (это в теории, на практике были ограничения), хранить эти модели и предоставлять к ним доступ.

Мы не инкапсулируем эту безумную сложность со всеми эти диаграммами и понятиями от TM форума внутри продукта / команды, мы распространяем ее вовне. Мы как бы говорим: ребята, вот есть такой концептуальный фреймворк (SID), а вот есть наша программная реализация, которая может создавать модели предметной области в понятиях этого фрейморка. Пользуйтесь)

Ага, вот счастье-то. Даже по самым скромным оценкам на освоение этого метальной концепции нужно около 3-х месяцев, это примерно 3 * 22 (рабочих дня) * 8 (часов) = 528 часов. Для ровного счета округлим до 500 часов. А теперь умножим на количество людей, вынужденных иметь дело с нашей системой. Я не знаю сколько их, но около полусотни активных пользователей / разработчиков «из вне» будет точно: 500 * 50 = 25000 часов. Час работы квалифицированного специалиста в такой компании примерно в диапазоне от 500-1000 руб. Это очень грубая оценка, есть специалисты, которые получают существенно больше. Оценим затраты по нижней планке 500 * 25000 = 12 500 000, т.е. только на обучение уйдет 12 с половиной миллионов рублей. И на порядок больше уйдет на разработку и сопровождение системы.

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

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

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

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

Мог ли я как архитектор повлиять на происходящее? Скорее нет, чем да. Даже понимая, что в этом проекте есть фундаментальные проблемы, я ничего не мог с этим сделать. Прийти с этим к руководству и заявить о том, что SID нужно изолировать внутри команды и никто кроме нас не должен иметь дела с SID концепцией, а проект проще переписать заново. Три раза ха. Люди пилили его 8 лет, кажется, если ничего не путаю. И тут я такой прихожу весь в белом и заявляю, что у вас тут все неправильно) В таких случаях проще уволиться.

Впрочем, ситуация эта далеко не уникальна. Я пока не встречал совсем уж беспроблемных проектов. Всегда, на любой работе, в любом проекте были какие-то сложности. Устроившись на новую работу, проработав там какое-то время, познакомившись с ее особенностями можно задать себе два вопроса: 1) насколько масштабные, фундаментальные проблемы в этом проекте, 2) готово ли руководство их устранять, а точнее выделять ресурсы на их устранение? При этом обратите внимание: готово оно на словах или на деле? Что для этого реально делается?

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

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

Валерий Чугреев, 02.07.2021