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

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

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

Чтобы никого не ставить в неловкое положение, я не буду привязываться к конкретным именам, скажу, что это была работа в крупной телекоммуникационной компании. Я устроился на позицию ведущего архитектора и проработав 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

Подписаться
Уведомить о
guest
23 комментариев
Старые
Новые
Межтекстовые Отзывы
Посмотреть все комментарии
Соль
Соль
4 месяцев назад

Основная причина ухода – отсутствие интереса к решаемым задачам.

И с коллективном проблем не было ? Какого-то явного или не явного давления. Или взаимопонимания(непонимания).
Прочитал дальше, частично нашел ответ на свой вопрос 🙂

Соль
Соль
4 месяцев назад

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

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

Мне кажется довольно тяжело в какой-то большой сформированной (рабочей) компании людей действовать прямо «творчески». Даже на формально творческих должностях наверное есть какой-то регламент как и что ты должен сделать, как должен вести, как реагировать, как общаться с людьми, какой должен быть результат; короче набор каких-то сковывающих масок. И под регламентом я подразумеваю не ТЗ, не обозначенную цель, а цель какую-то невербальную, общую, но которую все понимают и беспрекословно выполняют и за рамки которой не выйти.

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

И я до сих пор не понимаю, как можно хотеть работать(?), особенно на кого-то; или там, в чуждом коллективе; или делать черти что не понятно что и не понятно для кого. Кто-то когда-то хорошо сказал, что нужно не работать, нужно трудиться. И как бы попсово это не звучало, но есть в этом какая-то истина. Нужно трудится, прилагать усилия туда, куда-то хочешь их прилагать. Всё остальное же является работой. 

Еще денежный вопрос. Все мы работаем ради денег, мне кажется нужно честно себе в этом признаться (в смысле не тебе лично, а это я просто как философский посыл). Хотелось бы чтобы это было интересно, но нам нужны в первую очередь от работы деньги! По крайне мере у меня мышление так работает — чем больше денег, тем больше свободы от денег. Работаем, чтобы потом не работать короче. А вот не рабочее время уже тратить на какие-то крутые интересные штуки. Хотя это очень похоже на какую-то философию каторжника наверное. Типа «на работе ты обязательно должен страдать, а свободное время отдыхать и уже тратить на что-то действительно интересное», что в моей голове делает работу априори не интересной, хотя это наверное вопрос навыков\умений и специализации. 

Так или иначе если есть возможность выбирать в этой сфере, это круто. Частенько жизнь выбора не оставляет (или нам просто так кажется).

Соль
Соль
4 месяцев назад
Ответить на  admin

Почему бы не найти интересную и денежную работу?)

Если это прямо прямой вопрос мне, я наверное просто не могу.
Мне принципиально например не нравится работать на кого-то, или с кем-то. Не знаю, может это какой-то комплекс или мои личные заморочки, мне отвратительно прислуживать за деньги. А именно так я это воспринимаю. Наверное слишком однобоко, но что есть то есть. Ведь если бы не деньги, ноги моей бы не было на работе и я слова бы этому человеку который платит за неё деньги не сказал. А почему !? А потому что я полностью удовлетворен своей свободной жизнью когда в ней нет работы. Вот прям полностью. Любая работа в данном случае воспринимается как инородный элемент в этом танце жизни 🙂

А так же наверное просто не было подходящих должностей где я мог бы прямо самореализовываться и развиваться, быть с людьми на равных.

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

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

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

Короче говоря, для кого-то интересная и денежная работа это такой мифический зверь 🙂 Хотя полагаю для кого-то и наоборот.

Соль
Соль
4 месяцев назад
Ответить на  admin

Мне кажется, что это «или/или» (или интерес или деньги) похоже на самовнушение. То есть мы сами себя в этом убеждаем. Типа страдаю, мучаюсь, работа не нравится, но ведь деньги зарабатываю!

Да ты прав, это оно и есть. Но с другой стороны это самовнушение и есть реальность в которой приходится жить.

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

Иногда приходится брать что дают. Когда большего сам взять не можешь. Ведь деньги это что?! Это твоя польза людям. И нужно быть именно полезным в первую очередь (чтобы тебе платили), а во вторую уже всё остальное. А в чем полезным, это уже определяет то, что на что будет спрос.

Программирование конечно в этом плане уникальная профессия. Это как зарабатывать на математике (на мат складе ума). Раньше было немыслимо чтобы математик был кому-то нужен кроме как в школе или университете в роли учителя, получая при этом две копейки. Сейчас условная математика расширилась в такую сферу как программирование, и это круто.

Соль
Соль
4 месяцев назад

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

Это наверно как со старыми домами. Зачастую снести и построить новый значительно дешевле и проще, чем реставрировать\ремонтировать старый.

Соль
Соль
4 месяцев назад
Ответить на  admin

Само собой, никому этого не надо. Как человеку менять себя даже чуть чуть, страшно тяжело, так же и налаженную кое как систему.

Соль
Соль
4 месяцев назад
Ответить на  admin

Я уже как-то смирился что где-то это просто «вот так работает» (а так много где). Ты либо это сразу смекаешь и принимаешь это общее настроение инертности, либо проходишь мимо.

Пытаться менять, это как об стену биться; и в самом деле это не нужно никому кроме тебя самого, ты сам не хочешь быть в таких условиях. Это как если ты пришел к человеку в гости, а у него беспорядок — тебя напрягает беспорядок ведь ты привык у себя дома и в жизни к порядку, а вот человек наоборот привык к беспорядку, и наводить порядок его напрягает. Но так как ты в гостях, что тебе остается с этим сделать? 🙂

Соль
Соль
4 месяцев назад

В общем «не время товарищ», но когда-нибудь потом обязательно…

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

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

Тем не менее я могу это понять, действительно до тебя это все как-то работала, не ты все это построил, не тебе и менять. Одно дело предложить идею, другое дело предложить готовый сформированный продуманный план. Но проблема в том, что даже если у тебя такой план будет — его даже не будут рассматривать… Ну или как-нибудь потом, обязательно 🙂

К слову вишенкой на торте является то, что действительно хорошие небольшие идеи, у тебя еще могут и украсть, отмахнувшись от них сейчас, предлагают потом начальству, чтобы получить балов в копилку. Это для меня было настоящим откровением, что существуют реально такие люди, с такой вот мотивацией реально делающих такие финты ушами. Хотя наверное поработаешь с 10-20 лет в одной и той же компании еще грешным делом таким же станешь.

Соль
Соль
4 месяцев назад

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

Опять таки, это можно понять, почему люди так работают. Люди ходят за деньгами, люди ходят за стабильностью — туда энергия и уходит.

С такими принципами безупречности тебе либо безупречно годами перекраивать корпоративную культуру пришлось бы; Либо безупречно делать так — как диктует регламент и условия работы(то есть в данном случае безупречно делать — это делать обычно\нормально\минимально и не более); Или безупречно уйти 🙂

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

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

Соль
Соль
4 месяцев назад

В руководстве команды были лучшие из лучших, умнейшие люди!

Эко противоречие. Люди умнейшие, а система такая муторная и неудобная.
Почему интересно у них тогда не получилось всю эту систему сделать так же мудро. Или это проблематика верховной власти, с которой невозможно бороться ? 🙂

Lee-s
Lee-s
4 месяцев назад
Ответить на  admin

Абсолютно типично для телеком-гиганта. Думаю проблема не в том, что денег не нашлось на рефакторинг, а скорее в обратном.

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

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

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

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

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

Lee-s
Lee-s
4 месяцев назад
Ответить на  admin

Привет, Валера! Рад что снова к тебе заглянул.

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

Тоже видимо хлебнул полной ложкой всего этого корпоративного счастья?!)

Есть такое. 6 лет опыта в телекоме, 10 лет в ИТ. Появилось определенное представление что, где и как бывает))

Про KPI, очень похоже на правду.

Правда скажу что по моему опыту рефакторинг факапят даже специализированные ИТ компании. Вот например такая история.

Первое место где я работал разрабом была ИТ компания у которой был большой и серьезный продукт для крупных компаний.

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

Это привело к тому что со временем в систему стало невозможно вносить какие-либо мало мальски серьезные изменения, а незначительные изменения требовали много времени и стоили очень дорого. Если багу исправляли в одном месте, что-нибудь ломалось в 3-х других местах.

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

Единственным решением для компании оказалось написать новую версию с нуля. С нуля, Карл!

При тех размерах кодовой базы которая была и том объеме функциональности, это заняло у компании 3 года. При этом над новой версией все эти три года работала фулл-тайм выделенная команда из более чем 10 человек (13-15 может быть). Одновременно другая команда того же размера занималась поддержанием старой версии.

Надо ли говорить во сколько им обошлась новая версия и завал рефакторинга? Это нереально большие деньги.

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

Вот такая история из жизни о важности рефакторинга.

Lee-s
Lee-s
3 месяцев назад
Ответить на  admin

Да, я видел что на strateg.org структура уже стала проще. Похоже новая версия ожидается еще проще.

В любом случае, хотя мне и старая версия нравится, но и на новую было бы интересно посмотреть))

Надеюсь у тебя найдется время 🙂

Соль
Соль
4 месяцев назад

Глупо отрицать наличие проблем или бегать из одного проекта в другой.

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

Соль
Соль
4 месяцев назад

Если руководство не хочет, не готово их устранять, лучше искать другую работу. 

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