Почему Senior инженеры допускают провал неудачных проектов

Когда я был junior-инженером, мой руководитель иногда делился со мной своими разочарованиями на наших еженедельных встречах один на один. Он указывал на проект, над которым работала другая команда, и говорил: «Я не верю, что этот проект куда-то продвинется, они решают не ту проблему». Я тогда задавался вопросом: «Но вы же очень опытный специалист, почему бы вам просто не поговорить с ними о своих опасениях?» Мне казалось, что его влияние будет потрачено впустую, если он ничего не скажет.

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

Ответ в том, что быть правым и быть эффективным — это разные вещи.

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

Плохие проекты

Под «плохим проектом» я подразумеваю многое:

• UX: усложнение продукта, решение несуществующей проблемы, нарушение существующих рабочих процессов
• Технический: чрезмерно сложный дизайн, неправильная библиотека, плохо работающая архитектура
• Политический: погоня за хайпом, существует в основном для оправдания повышения по службе

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

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

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

Но я отчетливо помню, как сидел в комнате во время объявления, повернулся к своему руководителю и прошептал: «У этого проекта нет шансов на успех, верно?» Он повернулся ко мне и просто сказал: «Да». Мы оба сразу поняли проблему. Проект полностью основывался на просьбе команды разработчиков платформы отказаться от контроля над основным пользовательским потоком: технически это был правильный шаг, но ни один руководитель или менеджер проекта никогда бы не уступил права на что-то настолько важное другой команде. С политической точки зрения, этот проект был полной фантазией.

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

Почему вы не можете остановить их все

Когда я начал замечать «плохие проекты» и почувствовал, что могу поделиться своим опытом, у меня возникло искушение начать указывать на них. Связаться с командой, которая этим занимается, сказать им: «Это не имеет смысла», и объяснить почему. Использовать факты и логику, чтобы убедить.

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

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

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

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

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

Управляйте своим влиянием как банковским счетом.

Итак, если вы не можете остановить все плохие проекты, что же делать? Нужно действовать стратегически. Вместо того чтобы пытаться исправить все, рассматривайте свое влияние как банковский счет. У вас есть определенный объем «влияния», поступающий каждый месяц, пока вы выполняете свою работу, помогаете людям, успешно запускаете проекты и в целом поддерживаете низкий уровень трения.

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

• Чек на 5 долларов: Придирка к проверке кода. Недорогие ежедневные расходы.
• Чек на 500 долларов: Оспаривание архитектурного решения или перенос сроков. Требует определенных сбережений.
• Чек на 50,000 долларов: Попытка сорвать любимый проект вице-президента. Это огромные траты. Возможно, вы можете позволить себе это только раз в несколько лет.

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

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

Когда стоит использовать своё влияние

Учитывая, что мы уже смирились с тем, что не можем высказывать своё мнение по всем вопросам, нам нужно понять, когда это имеет смысл.

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

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

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

1. Насколько близок проект к моей команде?
2. Если что-то пойдёт не так, насколько сильно это повлияет на мою команду?
3. Если что-то пойдёт не так, насколько серьёзной будет проблема для компании?

Близость. Если проект близок к вам, «цена» высказывания ниже. Если это внутри вашей собственной команды, стоимость практически равна нулю, потому что вы пользуетесь высоким уровнем доверия, и быстрый разговор часто решает проблему. Если это в вашем отделе в целом, цена возрастает; вам придётся потратить социальный капитал и потенциально поставить под угрозу свою репутацию. Если это за пределами вашего направления? Стоимость часто оказывается непомерно высокой. У вас нет рычагов влияния, разные цепочки подчинения, и для прекращения проекта потребуется масштабный вывод средств.

Влияние на команду. Иногда другая организация делает что-то, что глубоко влияет на вашу работу. Например, поскольку Perfetto (инструмент для анализа производительности, над которым я работаю) используется по всему Google, иногда команда просит нас утвердить очень сложную интеграцию. Это классический риск: если все идет хорошо, они получают похвалу, но если что-то идет не так, ваше руководство может ожидать, что вы поможете решить проблему, которую вы не создавали. В таких случаях, если вы выскажете свое мнение, вы получите большую выгоду, потому что вы защищаете свою команду.

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

Как действовать в случае с неудачными проектами

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

Когда вы вмешиваетесь

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

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

Затем есть более мелкие вмешательства, подталкивающие ситуацию в правильном направлении. Они идеально подходят, когда команда собирается сделать что-то, что имеет смысл на высоком уровне, но они делают это неправильным путем. Я часто сталкиваюсь с этим в случае с Perfetto: команда присылает проектную документацию, предлагающую сложное использование Perfetto, которое, как я знаю, создаст им проблемы в будущем. Я сажусь с ними, выясняю их реальную проблему и помогаю им найти лучшее решение. Это занимает час, но экономит им месяцы. Если всё сделать правильно, вас могут даже воспринимать как помощника, а не как помеху, даже если вы замедляете работу команды.

Когда вы не вмешиваетесь

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

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

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

Управление командой в этом процессе

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

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

Заключение

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

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

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

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

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

Источник