Статья Программист не должен решать задачи бизнеса вызвала неслабое обсуждение (и даже ответ с прямо противоположным утверждением).
И, забавно, что все свелось к догматическим рассуждениям из разряда «программист должен», или «бизнес должен». Как будто, речь идет о системе, работающей ради единой цели, и проблема только в том, чтобы ее корректно настроить.
По факту же, все намного сложнее, и бизнес с программистом имеют сильно разные цели. Поэтому, говоря о том, кто, кому, и что должен, это выглядит, как утверждение, что покупатель не должен воровать в магазине товар. Да, не должен. Точнее, должен не воровать, если уж высказаться по правилам формальной логики. Простое, понятное, принятое подавляющим большинством утверждение. Ну и что? Означает ли это, что магазин может уволить охранников и снять камеры?
В своей первой статье на Хабре я рассматривал ситуацию с позиции нанимателя (бизнеса), и объяснял, принципы, которыми руководствуюсь, чтобы найти людей, которые решат задачи бизнеса. И почему это так важно.
Но есть один нюанс, и он в том, что люди, которых на дух не переносят собеседователи вроде меня, при должной сноровке добиваются большего, чем те, кто приносят пользу. И этому есть веское обоснование, — они успешно максимизируют скилл, который наиболее коррелирует с доходом программиста, — умение продать себя. Каким образом, — расскажу в этом посте.
Прежде всего, разберемся, чего хочет достичь каждая из сторон:
Бизнес хочет дешевого и своевременного решения своих айтишных задач, удовлетворяющего ожидания, а, в случае продвинутого руководства, еще и создания новых возможностей развития бизнеса.
Программист же хочет взращивать свою ценность на рынке труда, максимизировать условия работы (включая $, график, жесткость контроля, benefits & perks), решать задачи, которыми можно поднять свой авторитет, и получить удовлетворение от решения.
Собственно, несложно придумать пример, когда есть win-win, как например, разработка проприетарного ядра СУБД, где программист решает нетиповые прикладные задачи олимпиадного уровня, тащится от этого, выступает на конференциях, а сейлзы потом повышают продажи, показывая клиентам, как за счет большей эффективности и стабильности ядра, чем у конкурентов, они сэкономят на инфраструктуре.
Но мы о таких кейсах говорить не будем. Поговорим о кейсах, с которыми сталкивается подавляющее большинство программистов, которые делают заурядные решения вновь и вновь. Еще один интернет магазин, еще одно онлайн-казино, еще один операционный день для заурядного нетехнологического банковского бизнеса…
И тут есть острейший конфликт. Потому, что своевременные, надежные, прогнозируемые, дешевые и хорошо поддерживаемые решения делаются на проверенных временем технологиях. Условно, если админка вашего интернет магазина с ядром на ASP.NET написана на WebForms, и авторы кода все еще с вами и не собираются уходить, то панель управления новосозданной рекомендательной системы тоже стоит писать на WebForms, хоть связка .NET Core + Angular + TypeScript в 1000 раз лучше, да и вообще WebForms это зашквар. Ведь, команда, написавшая 500 форм, напишет 501-ую быстро, надежно, обходя грабли. И бизнес получит хорошее решение.
Для программистов же, которые осознали ценность WebForms на рынке, писать на нем может быть подобно пытке, ведь они отлично понимают, что за время написания этой формы, они повысят ценность бизнеса, но при этом понизят свою, — ведь пока стоишь на месте, индустрия бежит мимо тебя. Поэтому, в этой ситуации любой здравомыслящий программист (даже, если он совладелец, ведь, никто не даст гарантии, что магазин будет жить вечно, а искать работу в случае банкротства магазина будет очень больно) попробует как-то получить право выполнить задачу на чем-то свежем и востребованном, разумеется, затратив при этом больше времени, допустив больше багов, наступив на больше граблей.
Понятно, что названная ситуация утрирована. Но суть остаётся той же вне зависимости от домена и технологий.
Несложный код на проверенном временем, нехайповом, хорошо знакомом команде решении даёт бизнесу предсказуемость и надёжность, а команде деградацию. Код на новом хайповом фреймворке и/или с высокой алгоритмической сложностью даёт развитие команде, но бизнес за это терпит риски. Фокус на глубоком понимании предметной области программистом позволяет значительно нарастить ценность бизнесу (писать именно то, что требуется, и не писать то, что не надо), но не наращивает ценности программиста (на собесах программистов на зп выше рынка редко спрашивают знание бухучета) а фокус на технологиях и алгоритмах, наоборот.
Ведь хорошо знающий алгоритмы и технологии программист легко находит работу с повышением, в то время, как для бизнеса большинство знаний есть избыточными и неприменимыми. И написанный на модных фреймворках сервис с корректным применением паттернов и правильной алгоритмической сложностью не сильно поможет бизнесу, если делает не то, что ожидалось.
Да, есть побочные факторы. Например, хайповые темы упрощают найм, а адское легаси снижает отток существующих кадров (люди хотели бы уйти, но некуда), но это уже нюансы, и они не так важны.
Итак, вот представим себе момент, когда программист осознал, что бизнес от него захотел ещё чуть-чуть подеградировать (ладно, скажем, отсрочить свое развитие) ради общего дела. Что можно сделать?
Подчиниться. И потерять в своих интересах. Комментарии излишни.
Прямо пойти на конфликт. Так и сказать, мол я вам не раб. Хотите примитивный копипастный код с глубоким знанием бухучета, — ищите дурака. А я такое делать не буду. Возможно, один раз прокатит. Но о карьере тут говорить не приходится.
Убедить бизнес, что им надо именно то, что и тебе. Вот это для программиста едино правильный вариант. Да, он труднодостижим при высоком техническом уровне менеджера и низких навыках убеждения у программиста. Но попробовать стоит всегда. Проиграв, всегда можно выбрать п1, и пойти копить силы до следующего раза. А выиграв, получаешь уважение и чувство значимости у бизнеса и свой профессиональный рост одновременно.
Вопрос только один, — как же получить этот священный грааль?
Тут то мы и рассмотрим несколько увлекательных историй.
Василий был одним из самых опытных программистов в корпорации. За двадцатилетнюю карьеру он дорос от младшего программиста до руководителя департамента. Имел 40 человек прямых подчиненных, решал вопросы напрямую с основателем, а не с CEO и его заместителем, как другие менеджеры его уровня. И все еще пописывал код, чтобы оставаться в форме. Свою карьеру он сделал благодаря тому, что имел исключительный интеллект, и, кроме того, с ним бизнес мог общаться на одном языке. До этого Василий был в постоянной гонке. Давал обещания, и всеми силами достигал их. За это его обожали. Да, поговаривали, что он всегда запрашивает слишком большие сроки, но, зато, сдвигал он их куда реже других начальников департаментов.
А тут его признали лучшим менеджером года, стали ставить всем в пример, и Василий (который в душе не переставал быть программистом) понял, что пора новые технологии подучить, да за счет своих подчиненных поэкспериментировать с новыми подходами, в частности, с DDD.
Флагманский продукт департамента Василия, — автоматизированное рабочее место (АРМ) фьючерсного трейдера, помог заработать очень много денег, а за годы эксплуатации в нем выловили почти все баги, и дополировали до блеска. Из проблем было то, что он являлся десктоп приложением для Windows (в то время, как все вокруг перешли на веб), и в качестве СУБД использовал MSSQL, что, по мнению Василия, тоже было каменным веком, ведь реляционные СУБД использовали, пока люди не научились делать нормальные базы.
И вот зашла речь о необходимости написания АРМ для опционного трейдера. Проект был где-то на месяцев 6, включая вхождение в тему новой команды и бета тестирование, если форкнуть репу фьючерсного терминала, и заменить ряд модулей. Но, блин, делать еще один продукт на устаревших технологиях… Это ж неинтересно. Да и хантить людей придется выше рынка, ибо никто в такое впрягаться не хочет (а умение хантить и удерживать людей за 20% ниже рынка было киллер-фичей Василия), и, поэтому, факт хантинга выше рынка пошатнул бы его репутацию.
Поэтому, что сделал Василий, — он убедил СЕО, что ради прибыли и стабильности бизнеса, все надо писать с 0, новой командой, обязательно под веб, и не брать ни одного байта со старого решения, хоть это и займет 2 года. Учитывая свою репутацию и опыт карьерных сражений, это было не то, чтобы сложно.
Спустя два года решение было в проде. Свежие фреймворки, MongoDB, DDD, работа из браузера, ни единого байта из терминала для фьючерсов… Правда, горы копипасты, архитектура, не позволяющая интегрировать алгоритмы без костылей, переписанные с 0 модули, где элегантные алгоритмы из фьючерсного АРМ были заменены тоннами бойлерплейт кода. Василий, правда, неплохо поднял свой авторитет. Опционное АРМ еще долго приводили в пример другим менеджерам. Спустя пару лет Василий таки попал в опалу, но это уже другая история.
Итого, в сухом остатке: Василий разобрался в новых технологиях, раздул штат, увеличив свою значимость, а бизнес остался в полной уверенности, что он помог бизнесу и в очередной раз выполнил обещания.
Антон в свои 30 лет обожал изучение новых технологий и решение олимпиадных задач. Он занимал практически идеальное место для своего типажа, — был лид девом команды инфраструктурщиков. Антон очень хорошо знал спецификации и последние архитектурные веяния. И любимым интеллектуальным вызовом Антона было придумывание обоснований, как хайповые технологии помогут бизнесу, и куда именно их стоило бы впихнуть. В этом его поддерживал и архитектор, который тоже был не прочь прощупать новые грабли лбом Антона. В итоге Антона позвали на собес с FAANG, где он без проблем прошел всю теоретическую часть, и с блеском выполнил задачу на проектирование архитектуры Ebay (хотя ничего подобного на прошлой работе не требовалось). После чего отчалил в США, и оставил после себя 3 высоконагруженных модуля в проде, которые теперь никто не хочет поддерживать и развивать, ведь никто не понимает, как (и почему) они работают.
Итого, в сухом остатке: Антон четко знал, чего хочет и пришел к своей цели, взяв максимум от своего работодателя. Бизнес тоже был уверен, что Антон очень ценный сотрудник, ведь, как я уже упомянул, он всегда тщательно продумывал обоснования, даже, когда для людей в теме они были дикими.
Тимлид Иван совместно с тимлидами Владимиром и Юрием пилили продукт под предводительством архитектора Сергея. Всех троих привел в компанию Сергей, и они вчетвером принимали ключевые решения. После того, как за 4 года работы продукт вышел в прод, но все еще был далек от стабильности, на Сергея наехало руководство, и он ушел с гордо поднятой головой. Вслед за ним ушли и Владимир с Юрием.
В один момент Иван стал единственным носителем знаний о написанном (кроме синиоров и миддлов, которых Сергей не особо и посвящал в общее видение). Чувствуя, что пахнет жаренным, руководство назначило Ивана архитектором с соответствующей зп в надежде, что он не уйдет. На что Иван сказал, мол, это, конечно, хорошо, но этого мало, чтобы я не ушел. Если хотите, чтобы я поддерживал то, что мы напилили с Сергеем, то разрешите мне все переписать с 0. Бизнес скрепя сердце согласился. Иван получил зп, должность, и возможность написать все с 0 в один день.
Итого: Иван правильно понял, в чем проблема бизнеса, — бизнес панически боится, что то, что они напилили во времена Сергея, может дать сбой, и некому будет разобраться. И отжал бизнес по-максимуму.
Хотите вы этого или нет, но ради карьеры, $ и возможности заниматься интересными для себя вещами придется, как минимум, говорить и думать о ценности для бизнеса. Да, можно ее приносить, не приносить, или даже приносить отрицательную. Но в этой системе отношений чем длиннее выглядит контролируемая вами цепочка создания ценности для того, кто платит, тем сильнее будет переговорная позиция и возможность делать то, что вы хотите, а не декларируете.
И, забавно, что все свелось к догматическим рассуждениям из разряда «программист должен», или «бизнес должен». Как будто, речь идет о системе, работающей ради единой цели, и проблема только в том, чтобы ее корректно настроить.
По факту же, все намного сложнее, и бизнес с программистом имеют сильно разные цели. Поэтому, говоря о том, кто, кому, и что должен, это выглядит, как утверждение, что покупатель не должен воровать в магазине товар. Да, не должен. Точнее, должен не воровать, если уж высказаться по правилам формальной логики. Простое, понятное, принятое подавляющим большинством утверждение. Ну и что? Означает ли это, что магазин может уволить охранников и снять камеры?
В своей первой статье на Хабре я рассматривал ситуацию с позиции нанимателя (бизнеса), и объяснял, принципы, которыми руководствуюсь, чтобы найти людей, которые решат задачи бизнеса. И почему это так важно.
Но есть один нюанс, и он в том, что люди, которых на дух не переносят собеседователи вроде меня, при должной сноровке добиваются большего, чем те, кто приносят пользу. И этому есть веское обоснование, — они успешно максимизируют скилл, который наиболее коррелирует с доходом программиста, — умение продать себя. Каким образом, — расскажу в этом посте.
Disclamer
Речь будет идти о примерах бизнеса, где технологии не являются конкурентным преимуществом. Совпадения с реальными людьми случайны. Примеры приведены для технической карьеры без ответвлений в сторону продукта, ПМства, продаж, то есть, Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.
Постановка задачи
Прежде всего, разберемся, чего хочет достичь каждая из сторон:
Бизнес хочет дешевого и своевременного решения своих айтишных задач, удовлетворяющего ожидания, а, в случае продвинутого руководства, еще и создания новых возможностей развития бизнеса.
Программист же хочет взращивать свою ценность на рынке труда, максимизировать условия работы (включая $, график, жесткость контроля, 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 в один день.
Итого: Иван правильно понял, в чем проблема бизнеса, — бизнес панически боится, что то, что они напилили во времена Сергея, может дать сбой, и некому будет разобраться. И отжал бизнес по-максимуму.
Итог
Хотите вы этого или нет, но ради карьеры, $ и возможности заниматься интересными для себя вещами придется, как минимум, говорить и думать о ценности для бизнеса. Да, можно ее приносить, не приносить, или даже приносить отрицательную. Но в этой системе отношений чем длиннее выглядит контролируемая вами цепочка создания ценности для того, кто платит, тем сильнее будет переговорная позиция и возможность делать то, что вы хотите, а не декларируете.
BugM
История 1:
Вы вообще хоть когда-нибудь видели 20 летний легаси проект? Он работает да. И часто неплохо работает. Но там костыль на костыле и как и почему оно работает уже обычно никто не знает. Перетаскивать такое на другую платформу это пусть страданий и боли. Да-да писать only Win сейчас это тупик. Телефоны, маки без них проиграешь. В вашем примере трейдер точно хочет и то и другое.
Иногда надо говорить все, точка. Пришло время переписать. Если у бизнеса есть время и деньги на такое это же великолепно.
Срок жизни развивающегося проекта в 20 лет это уже перебор. За это время изменилось примерно все.
История 2:
Про басфактор вы тоже не слышали? Внутреннее обучение, лекции от Антона, митапы для поговорить. Да-да это все потеря денег и вообще разработчики работать должны, а не за пиццей обсудать уже сделанные вещи. Зато команда будет в курсе что почему и как сделано.
Если вам достался разработчик уровня FAANG используйте его правильно. Он на самом деле может клевые вещи делать.
История про архитектора Ивана:
Что это у вас за сеньеры которые не в курсе общего виденья? Это же их прямая работа. Знать на каком-то уровне всю или хотя бы большую часть кодовой базы своей команды разработки.
И опять тот же басфактор. Кто мешал потратить время на то чтобы сеньры разобрались во всем? Просто ставить им задачи из разных частей проекта. Будет не так быстро, зато басфактор вырастет. И увольнения пары человек можно будет не бояться.
algotrader2013 Автор
Ок, проясню немного, чтобы не плодить домыслы.
История 1: 20 лет было карьере Василия, а продукту было года 4, причем до него Василий с командой уже имели опыт написания АРМ для фьючерсного трейдинга, и тот, продукт, о котором идет речь, уже был переписанной версией с учетом архитектурных проблем и костылей. Ну а насчет желаний трейдеров работать со смартфона, — такое требование не имеет смысла, ведь трейдеры в данном случае это люди на зарплате, и работают исключительно со своих корпоративных рабочих станций. Разве что, могло бы иметь место какое-то простенькое веб-приложение для отчетности, чтобы главный трейдер и топ-менеджеры могли посматривать, но не более.
История 2: в данном конкретном случае не готовы были руководители к правильному использованию таких, как Антон. Но речь о том, как они потеряли шанс, а о том, как Антон, невзирая на это, использовал ситуацию по максимуму.
История 3: а кто сказал, что архитектор Сергей, имевший карт-бланш на процессы у себя, имел цель оптимизировать бас-фактор? Он тоже фармил свое CV. Снова таки, я говорю не о том, как бизнес дошел до такой жизни, а о том, как оперируя понятием ценности бизнесу, люди добивались своих целей. Да, неэтично, и эксплуатируя дыры.
BugM
1. Ок. При таких вводных наверно и нет смысла.
Трейдеры на зарплате и снаружи нельзя? Я вижу точку для роста. Пустить всех желающих и брать с них процент. Не знаю потенциальных ограничений, но выглядит решаемо. И тогда уже и веб и все окупится.
2. Это проблема руководстсва и менеджеров, а не Антона. Он любит и умеет писать код и проектировать системы. Он этим и занимается. Бегать и организовывать всё остальное должны менеджеры. От него только подготовиться и рассказать другим разработчикам. Что-то еще требовать от разработчика в таком случае это лишнее.
3. Басфактор 1. Почему один человек все решает? Почему никто не в курсе что сеньеры не в курсе всего проекта и у них нет задач на разобраться и допилить доселе неизвестные им куски? Чем там вообще менеджеры занимаются? Почему все сложное свалено на одного, а остальные просто безвольные кодеры своих маленьких кусочков (не факт но очень похоже с виду)?
Как раз тут везде ключевое как бизнес дошел до такого. Это все назревает годами. Поправить можно пока не взорвалось. Везде фигурируют люди которые должны быть в курсе и должны тратить свое время на увеличение бас фактора.
Если таких людей много, то пора технических менеждеров заводить. Которые будут в курсе чем живет команда разработки. И которые должны ходить к руководству с рассказами что у нас один человек все знает и никого не пускает. Поправить надо.
Но фичи при этом будут пилиться медленнее, да и разработка станет дороже. Кажется что это главная проблема.
algotrader2013 Автор
Раз так хотите подискутировать о том, как решать задачу, обратную теме поста, то давайте, почему нет)
Решение с закручиванием гаек вроде этого https://m.habr.com/ru/post/501244/comments/#comment_21595022 кажется самым простым. В частности, технические менеджеры, которые прожимают нерадивых технарей, разводя стукачество, это шаг к тому, чтобы перестать требовать от программиста ценности бизнесу, а требовать исполнения конкретных задач.
Но вопрос в том, почему считаете, что это работает (даже ценой понижения темпа)? Все таки, программист же не траншеи копает?) Если бы зажимание в рамки работало, то все бы сидели на IBM Rational и аналогах. Почему-то же мир пошёл в другую сторону...
BugM
Не надо никого прожимать. И гайки закручивать не надо. И упаси боже никакого стукачества.
Все обсуждается в начале с теми кто все гребет под себя. Обычно люди достаточно адекватные и когда к ним придут с вопросом Почему у тебя команда не разбирается в проекте? они расскажут причины. И дальше можно обсудить что делать для изменения ситуации. Обычно вполне хватает снижения скорости разработки новых фич и выделения времени на рефакторинг и на разобраться. В конкретном случае человек может запросить что-то еще, надо думать и обсуждать именно его предложение как решить эту проблему. Но да для этого нужен человек со стороны который будет в курсе что в команде происходит. Обычно это технический менеджер. Допускаю что должность может называться по другому.
Люди которые принципиально не хотят отдавать компетенции чтобы быть незаменимыми откровенно вредят бизнесу. Тут уже не стукачество, а спасение команды разработки. В таком коллективе все нездоровое. Спасать срочно надо.
Я наоборот за расширение рамок.
Если у вас есть выдающиеся разработчики, пусть рассказывают другим о своих лучших решениях. Да и вообще об архитектурных решениях. Выдайте им время на подготовку к рассказу и уговорите что это полезно. И организуйте все.
Если у вас есть сеньеры идеально знающие свой уголок проекта, то пусть тратят свое время чтобы разобраться в других частях. Пока не разберутся они будут приносить меньше пользы бизнесу. Но зато басфактор растет. Компетенции распределяются.
Я про устоявшиеся и достаточно большие и сложные проекты. Стартапы естесвенно не так работают. Там делаем, получаем финасирование, переделываем заново и снова переделываем. И все это за год или меньше. Гоним вперед до вырастания в большой и сложный проект или до продажи. А потом уже как обычно. Басфактор, менеджеры, компетенции.