Когда я был ещё джуном, мой менеджер иногда на наших еженедельных встречах тет-а-тет делился своим возмущением. Он указывал на проект, над которым работала другая команда, и говорил: «Я не верю, что этот проект достигнет какого-то успеха. Они решают не ту задачу». Я отвечал любопытством: «Но вы же старший, почему бы просто не пойти и не поговорить с ними?» Мне казалось странным, что при наличии возможности повлиять на ситуацию человек предпочитает молчать.
И ирония не обошла меня стороной. На прошлой неделе я сам поймал себя на том, что рассказываю новичку, почему соседней команде придётся кардинально менять свой проект, так как они изначально пошли не тем путём. И он справедливо задал мне тот же вопрос, что и я задавал многие годы назад: «А почему вы просто не поделитесь с ними своим мнением?» С тех пор эта ситуация засела в моей голове, так как я осознал, что за прошедшие годы моя позиция по этому вопросу изменилась.
Ответ в том, что быть правым и быть эффективным — это разные вещи
В крупных компаниях приветствуется высказывание своих сомнений в отношении, как вам кажется, «неудачного проекта». Но только в мягкой форме. Иногда признаком старшинства и опыта является понимание, ��то спорить с людьми, которые всё равно тебя не послушают, того не стоит, и лучше оставить своё мнение при себе.
Плохие проекты
Под «плохим проектом» я понимаю очень много аспектов:
UX: усложнение продукта, решение несуществующей проблемы, ломание текущих рабочих потоков.
Технические: излишне усложнённый проект, неподходящая библиотека, слабая архитектура.
Политические: погоня за кривой Гартнера — существует в основном для оправдания повышения.
Важно отметить, что большую часть жизненного цикла проекта оценка того, насколько он «плох», будет крайне субъективной. Разработка ПО во многом сопряжена с компромиссами и принятием пусть не идеальных, но лучших из возможных решений, исходя из доступной информации. По части правильности тех или иных выборов часто есть разногласия, и истинно верные варианты становятся очевидны лишь намного позже или даже спустя годы после поставки проекта.
Но по мере своего карьерного взросления вы вырабатываете «чутьё» и начинаете видеть в некоторых проектах «неразумность». И именно это чутьё указывает мне на «плохой проект», судьбу которого ты видишь наперёд, когда другим она ещё не очевидна.
Если брать мой личный опыт, то самый запоминающийся пример случился пару лет назад в Google. Тогда на одном из совещаний прозвучало громкое заявление о «переломном» проекте, разработка которого происходила на стыке двух очень крупных организаций. Звучало всё очень элегантно и технически продумано. Проект пестрил умными решениями для реально серьёзных проблем.
Но я отчётливо помню, как сидел в зале для совещаний и, повернувшись к своему лиду, шёпотом сказал: «Но ведь это же бесперспективный проект?» На что он тоже повернулся и ответил: «Да». Мы оба сразу поняли проблему. Проект полностью основывался на том, что команда разработки платформы просила команду основного продукта передать им управление над User Flow. С технической стороны решение правильное, но ни один лид или менеджер проекта никогда не отдаст управление чем-то столь фундаментальным другой команде. В политическом смысле этот проект был абсолютно фантастичен.
В итоге он почти два года худо-бедно волочился где-то на фоне. Каждый раз, когда приближался момент запуска, его тормозили как «ещё не готовый». Со временем мы стали слышать о нём всё меньше, пока в конечном итоге мне на почту не пришло письмо о «стратегическом повороте». Ресурсы проекта перераспределили, а код удалили. Нам сказали, что компания «многому научилась из этого опыта». Но для меня его обречённость была очевидна с самого начала. Политика и решения правильных задач не менее важны, чем техническая изящность.
Почему ты не можешь их всех остановить
Когда я начал замечать «плохие проекты» и чувствовал, что у меня есть полезный для них опыт, меня так и подмывало предложить помощь. Хотелось обратиться к команде со словами: «Так делать неразумно» и пояснить почему, оперируя логическими доводами.
И я пробовал. Но только весьма недолго, пока не понял, что это влечёт за собой ряд проблем.
Во-первых, компании-разработчики программного обеспечения по своей природе склонны действовать быстро. В них ц��нится скорость написания и поставки ПО. Всякого рода сомнения всё только замедляют и означают, что нужно анализировать аспекты, которые в бюджет не закладывались. Поэтому прислушаются к вам, только когда выраженные опасения окажутся поистине важными. На деле же вас наверняка просто проигнорируют.
И даже если команда отнесётся к вашим замечаниям серьёзно, вам не следует с ними частить. Один или два раза вас могут воспринять как человека, ратующего за «качество». Если же вы начнёте лезть с советами слишком часто, то быстро превратитесь в «отрицательную персону», которая постоянно создаёт проблемы, а не решает их. Вы редко будете получать признание за предотвращённые катастрофы — поскольку ничего страшного не случилось, люди быстро об этом забывают.
Ещё одна проблема в том, что всякий раз, когда вы тормозите какой-то проект, то потенциально вредите чьему-то повышению, или же это оказывается «пет-проект» какого-нибудь вице-президента (VP). В итоге вы рискуете сжечь полезные мосты и завести «врагов», как минимум в некотором смысле. Наличие в компании нескольких не согласных с вами людей вполне естественно, а вот когда их слишком много, это уже начинает вредить вашей основной работе.
Наконец, здесь присутствует психологический аспект. В компании есть сотни инженеров, работающих в областях, где может пригодиться ваш опыт. Но вы лишь один, и ресурс вашего внимания ограничен. А вот способность большой компании генерировать плохие идеи — бесконечна. По своему опыту могу сказать, что излишнее стремление исправить всё и везде быстро сделает вас очень цин��чным в отношении окружающего мира. И такой мир вам явно не понравится.
Распоряжайтесь своим влиянием как банковским счётом
Итак, если вы не можете остановить все эти плохие проекты, что же делать? Действовать стратегически. Вместо того, чтобы пытаться исправить всё, рассматривайте свой ресурс влияния как банковский счёт. У вас есть определённый объём «влияния», который вы получаете каждый месяц, выполняя свою работу, помогая другим, поставляя успешные проекты и не вызывая лишних трений.
В таком случае, когда это окажется действительно важным, вы должны быть готовы к «снятию» накопленных средств. Всякий раз, когда вы тормозите какой-то процесс или выражаете сомнения, вы выписываете чек на расход с баланса, каким бы малым он ни казался. При этом чеки бывают разные:
Чек на $5: придирка к код-ревью. Дёшево, суточный расход.
Чек на $500: возражение по поводу архитектурного решения или сроков реализации проекта. Требует накопления ресурсов.
Чек на $50 000: покушение на пет-проект вице-президента. Это огромный расход, который вы можете себе позволить не чаще одного раза в пару лет.
Проблема возникает, если вы тратите по $5 на каждый мелкий недочёт, который встречаете. Если вы постоянно говорите «нет» таким малым вещам, то к моменту, когда потребуется выписать весомый чек для остановки реальной катастрофы, ваш счёт окажется пуст.
Если вы уйдёте в минус, то окажетесь в состоянии политического банкрота. Люди перестанут приглашать вас на встречи, спрашивать вашего мнения. По сути, они начнут обходить вас стороной. Когда вы банкрот, ваше влияние падает до нуля. Теперь для вас становится проблематичным не только влиять на происходящее, но выполнять собственные задачи.
Когда тратить влияние
Итак, мы согласны, что не можем повлиять на всё, и теперь нужно понять, когда вообще есть смысл стараться это делать.
Первое и самое главное — это быть сдержанным и всякий раз оценивать, реально ли у вас достаточно опыта, чтобы лезть с советами. Опытные специалисты часто имеют своё мнение. Но эти мнения не всегда опираются на достаточно прочную почву. К примеру, хоть у меня и есть некоторый опыт во фронтенде, я не чувствую себя достаточным знатоком, чтобы давать по этой теме какие-то углублённые советы. Моих знаний просто хватает, чтобы справляться с собственными задачами и двигаться дальше, но я не обладаю глубокой мудростью, приходящей в результате длительного управления продуктом. Легко упустить из внимания тот факт, что для качественной оценки ваше мнение должно опираться на чёткое понимание контекста. Если вы оказываетесь в подобной ситуации, то взгляните на себя как на предвзятого наблюдателя и остановитесь.
Вам также нужно уяснить, что ваши слова не обязательно являются истиной. Вы лишь выражаете своё мнение, а не издаёте указ. Так что, если какая-то команда не станет слушать ваши замечания и решит продолжать двигаться в своём направлении, то вам нужно просто это принять. В конце концов, вы такой же инженер, а не директор, имеющий над ними власть.
Учитывая все эти нюансы, прежде чем высказать своё мнение, я отвечаю на три вопроса:
Насколько этот проект близок к моей команде?
Если в нём возникнут проблемы, насколько сильно это повлияет на мою команду?
Если в нём возникнут проблемы, насколько это повредит компании?
Близость. Если проект близок к вашей работе, то «цена» возражений на его счёт снижается. Если он реализуется внутри вашей же команды, это сводит цену практически в ноль, так как здесь вы пользуетесь высоким доверием, и для разрешения вопроса зачастую будет достаточно короткой беседы. Если же проект относится к каким-то удалённым частям организации, цена растёт. Вам потребуется потратить свой социальный капитал и потенциально поставить под удар свою репутацию. А если дело касается вообще другой организации? В таком случае затраты часто окажутся слишком высоки. Здесь у вас нет рычагов и действовать нужно через другие цепочки подчинения, так что остановка процесса потребует колоссального расхода накоплений.
Влияние на команду. Бывает так, что действия другой организации глубоко влияют на вашу работу. К примеру, поскольку Perfetto (инструмент оценки производительности, над которым я работаю) используют в разных подразделениях Google, иногда какая-нибудь команда просит нас одобрить запланированную ими очень сложную интеграцию. И здесь возникает классический риск. Если всё пройдёт гладко, они получат свою выгоду, но если что-то пойдёт не так, ваше руководство может повесить на вас решение проблем, которые вы не создавали. В таких случаях высказаться очень важно, так как вы защищаете свою команду.
Внутри компании. Ну и последнее — учитывайте радиус воздействия проекта. Некоторые являются замкнутыми. Если они ломаются, то никого за собой не тянут. Но бывают и такие, которые настолько вплетены во внутренние системы, что их провал приводит к обширному урону или создаёт технический долг, который сохраняется годами. Вот они могут оказаться смертельными для долгосрочного благополучия вашего собственного проекта.
Как действовать в отношении плохих проектов
В этом вопросе также важно не просто понимать, когда высказаться, но и как именно. Существует много вариантов действий, которые можно предпринять в зависимости от наблюдаемой проблемы.
Когда вы вмешиваетесь
Самый жёсткий вариант — это прямо сказать «так делать не надо» и попытаться остановить проект. Такое действие почти всегда требует уведомления руководителей вашей команды и команды, реализующей обсуждаемый проект. Нужно будет привести убедительные аргументы в защиту своих доводов и объяснить, что проект принесёт реальный вред. Но в некоторых случаях это правильный выбор, особенно, если результат молчания может кардинально ударить по вашему собственному проекту или команде.
Чуть более мягкий, но всё ещё довольно рисковый вариант — это выразить свою обеспокоенность непосредственно перед командой. Обычно это делается в рамках совещания либо в виде чётко сформулированного документа с «опасениями» или «возражениями». Задача — выразить свою мысль в достаточно убедительной форме, чтобы команда могла сама прийти к выводу, что этот прое��т не является такой уж хорошей идеей.
Есть и ещё менее резкий вариант вмешательства в виде подталкивания проекта в нужном направлении. Этот вариант отлично подходит, когда команда планирует реализовать что-то вполне разумное, но подходит к этому неправильно. Я часто вижу такое в Perfetto. Команда отправляет диздок с предложением комплексного использования инструмента, которое, как я сразу вижу, принесёт им боль в будущем. Тогда я собираю их специалистов, вникаю в задачу и направляю к более эффективному решению. В итоге я трачу час времени сейчас, но экономлю им месяцы в перспективе. Если сделать это правильно, то вас воспримут как помощника, а не препятствие, даже если вы замедлите движение проекта.
Когда вы не вмешиваетесь
Иногда вы понимаете, что потенциальная отдача не оправдывает прямого вмешательства — политический аспект слишком силён, или проблема слишком мала. В таком случае ваши действия зависят от того, насколько это касается вашей команды.
Если проблемный проект сильно пересекается с вашей работой, то может оказаться разумным реализовать какой-то аварийный план — уменьшить зависимость от этого проекта или создать абстракции для защиты в случае его провала. Ещё здесь можно сыграть вдолгую. Даже плохой проект обычно всё равно содержит внутри хорошую идею — конкретную задачу, которую он нацелен решить, или некий инсайт, на котором был основан. И если эта идея сочетается с вашей работой, то зачастую правильным решением будет попробовать встроить в свой проект более удачный вариант её реализации. В таком случае, если плохой проект встанет или будет отменён, вы будете действовать превентивно, а не просто разгребать внезапные последствия.
Если же вашу работу проблемный проект никак не затрагивает — просто не вмешивайтесь. Можете поделиться с близкими коллегами лично, выразить сочувствие, но в публичном поле смиритесь с реальностью.
Проработка внутри команды
Ну и последнее — вам также нужно проработать этот момент с командой. Если вы видите в проекте недочёты, то и другие старшие разработчики наверняка их видят. Не пытайтесь их газлайтить или «следовать линии компании», притворяясь, что плохой проект на самом деле хорош. Такое поведение разрушает доверие.
Лучше будьте честны насчёт очевидных фактов без углубления в политические детали. Скажите своим коллегам, что сделаете в этих стеснённых условиях всё возможное.
Заключение
Так что же я ответил своему подопечному джуну?
«С опытом я понял, что быть правым и быть эффективным — это разные вещи. Я вполне мог пойти и сказать им о своём беспокойстве. Но они наверняка не станут слушать, и я просто растрачу часть своей репутации. А через полгода никто и не вспомнит, что я предупреждал. Люди запомнят лишь то, что я пытался затормозить их работу».
Когда вы ещё только начинаете свой карьерный путь, вам хочется верить, что хорошие идеи заслуживают признания, что если вы просто всё хорошо объясните, то люди поймут. И мне потребовалось немало времени, чтобы понять — в больших компаниях так не работает.
Но это не значит, что нужно просто забить. Это лишь значит, что вам следует тратить свои очки репутации стратегически. Выбирайте те битвы, в которых реально можете повлиять на исход; где ваша команда окажется под угрозой, если вы промолчите; когда цена вашей ошибки мала, а цена провала проекта зашкаливает.
А в остальных случаях? Просто делитесь с коллегами, стройте запасные планы и наблюдайте. Иногда вы чему-то учитесь. Иногда вы ошибаетесь, и проект реально преуспевает. А иногда у вас возникает мрачное чувство удовлетворённости от того, что вы предвидели его развал.
Ничто из этого не приносит того удовлетворения, какое приносит исправление всех ошибок. Но такая схема работает и позволяет мне сохранять рассудок.
