Как делать карьеру программисту, не решая задачи бизнеса

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

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

В своей первой статье на Хабре я рассматривал ситуацию с позиции нанимателя (бизнеса), и объяснял, принципы, которыми руководствуюсь, чтобы найти людей, которые решат задачи бизнеса. И почему это так важно.

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

Постановка задачи

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

Конфликт

Собственно, несложно придумать пример, когда есть win-win, как например, разработка проприетарного ядра СУБД, где программист решает нетиповые прикладные задачи олимпиадного уровня, тащится от этого, выступает на конференциях, а сейлзы потом повышают продажи, показывая клиентам, как за счет большей эффективности и стабильности ядра, чем у конкурентов, они сэкономят на инфраструктуре.
Но мы о таких кейсах говорить не будем. Поговорим о кейсах, с которыми сталкивается подавляющее большинство программистов, которые делают заурядные решения вновь и вновь. Еще один интернет магазин, еще одно онлайн-казино, еще один операционный день для заурядного нетехнологического банковского бизнеса…
И тут есть острейший конфликт. Потому, что своевременные, надежные, прогнозируемые, дешевые и хорошо поддерживаемые решения делаются на проверенных временем технологиях. Условно, если админка вашего интернет магазина с ядром на ASP.NET написана на WebForms, и авторы кода все еще с вами и не собираются уходить, то панель управления новосозданной рекомендательной системы тоже стоит писать на WebForms, хоть связка .NET Core + Angular + TypeScript в 1000 раз лучше, да и вообще WebForms это зашквар. Ведь, команда, написавшая 500 форм, напишет 501-ую быстро, надежно, обходя грабли. И бизнес получит хорошее решение.
Для программистов же, которые осознали ценность WebForms на рынке, писать на нем может быть подобно пытке, ведь они отлично понимают, что за время написания этой формы, они повысят ценность бизнеса, но при этом понизят свою, — ведь пока стоишь на месте, индустрия бежит мимо тебя. Поэтому, в этой ситуации любой здравомыслящий программист (даже, если он совладелец, ведь, никто не даст гарантии, что магазин будет жить вечно, а искать работу в случае банкротства магазина будет очень больно) попробует как-то получить право выполнить задачу на чем-то свежем и востребованном, разумеется, затратив при этом больше времени, допустив больше багов, наступив на больше граблей.

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

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

Пути решения

Итак, вот представим себе момент, когда программист осознал, что бизнес от него захотел ещё чуть-чуть подеградировать (ладно, скажем, отсрочить свое развитие) ради общего дела. Что можно сделать?

Подчиниться. И потерять в своих интересах. Комментарии излишни.

Прямо пойти на конфликт. Так и сказать, мол я вам не раб. Хотите примитивный копипастный код с глубоким знанием бухучета, — ищите дурака. А я такое делать не буду. Возможно, один раз прокатит. Но о карьере тут говорить не приходится.

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

История 1. Про руководителя департамента Василия

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

А тут его признали лучшим менеджером года, стали ставить всем в пример, и Василий (который в душе не переставал быть программистом) понял, что пора новые технологии подучить, да за счет своих подчиненных поэкспериментировать с новыми подходами, в частности, с DDD. Флагманский продукт департамента Василия, — автоматизированное рабочее место (АРМ) фьючерсного трейдера, помог заработать очень много денег, а за годы эксплуатации в нем выловили почти все баги, и дополировали до блеска. Из проблем было то, что он являлся десктоп приложением для Windows (в то время, как все вокруг перешли на веб), и в качестве СУБД использовал MSSQL, что, по мнению Василия, тоже было каменным веком, ведь реляционные СУБД использовали, пока люди не научились делать нормальные базы.

И вот зашла речь о необходимости написания АРМ для опционного трейдера. Проект был где-то на месяцев 6, включая вхождение в тему новой команды и бета тестирование, если форкнуть репу фьючерсного терминала, и заменить ряд модулей. Но, блин, делать еще один продукт на устаревших технологиях… Это ж неинтересно. Да и хантить людей придется выше рынка, ибо никто в такое впрягатся не хочет (а умение хантить и удерживать людей за 20% ниже рынка было киллер-фичей Василия), и, поэтому, факт хантинга выше рынка пошатнул бы его репутацию.

Поэтому, что сделал Василий, — он убедил СЕО, что ради прибыли и стабильности бизнеса, все надо писать с 0, новой командой, обязательно под веб, и не брать ни одного байта со старого решения, хоть это и займет 2 года. Учитывая свою репутацию и опыт карьерных сражений, это было не то, чтобы сложно.

Спустя два года решение было в проде. Свежие фреймворки, MongoDB, DDD, работа из браузера, ни единого байта из терминала для фьючерсов… Правда, горы копипасты, архитектура, не позволяющая интегрировать алгоритмы без костылей, переписанные с 0 модули, где элегантные алгоритмы из фьючерсного АРМ были заменены тоннами бойлерплейт кода. Василий, правда, неплохо поднял свой авторитет. Опционное АРМ еще долго приводили в пример другим менеджерам. Спустя пару лет Василий таки попал в опалу, но это уже другая история.

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

История 2. Про лид дева Антона

Антон в свои 30 лет обожал изучение новых технологий и решение олимпиадных задач. Он занимал практически идеальное место для своего типажа, — был лид девом команды инфраструктурщиков. Антон очень хорошо знал спецификации и последние архитектурные веяния. И любимым интеллектуальным вызовом Антона было придумывание обоснований, как хайповые технологии помогут бизнесу, и куда именно их стоило бы впихнуть. В этом его поддерживал и архитектор, который тоже был не прочь прощупать новые грабли лбом Антона. В итоге Антона позвали на собес с FAANG, где он без проблем прошел всю теоретическую часть, и с блеском выполнил задачу на проектирование архитектуры Ebay (хотя ничего подобного на прошлой работе не требовалось). После чего отчалил в США, и оставил после себя 3 высоконагруженных модуля в проде, которые теперь никто не хочет поддерживать и развивать, ведь никто не понимает, как (и почему) они работают.

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

История про архитектора Ивана

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

В один момент Иван стал единственным носителем знаний о написанном (кроме синиоров и миддлов, которых Сергей не особо и посвящал в общее видение). Чувствуя, что пахнет жаренным, руководство назначило Ивана архитектором с соответствующей зп в надежде, что он не уйдет. На что Иван сказал, мол, это, конечно, хорошо, но этого мало, чтобы я не ушел. Если хотите, чтобы я поддерживал то, что мы напилили с Сергеем, то разрешите мне все переписать с 0. Бизнес скрепя сердцем согласился. Иван получил зп, должность, и возможность написать все с 0 в один день.

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

Итог

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

Автор: algotrader2013

Источник