[Перевод] Нормализация девиантности. Как неправильные практики становятся нормой в нашей отрасли
У вас когда-нибудь бывало такое, что вы говорите нечто совершенно нормальное для вас, но все остальные очень удивлены? Со мной такое случается постоянно, когда я описываю то, что считали нормальным в фирме, где я работал. По какой-то причине лицо собеседника постепенно переходит из приятной улыбки в гримасу крайнего изумления. Вот несколько характерных примеров.
Есть одна очень хорошая компания, одно из самых приятных мест, где я когда-либо работал, сочетание всех вкусностей Valve и Netflix. Люди здесь удивительные, а вам дают почти полную свободу делать всё, что вы хотите. Но как побочный эффект такой культуры, в первый год от них уходит примерно 50% новых сотрудников, некоторые добровольно, а некоторые нет. Абсолютно нормально, да?
Есть компания, которая невероятно скрытно относится к своей инфраструктуре. Например, боится сообщать о багах поставщику оборудования, потому что тогда ошибки будут исправлены, а конкуренты смогут использовать исправления. Этого нельзя допустить. Решение: запросить прошивку и исправить баги самостоятельно! Нормально.
Совсем недавно я познакомился со специалистами, которые пытались воспроизвести алгоритм, опубликованной в статье той компании. Они не смогли воспроизвести результат. Более того, алгоритм из статьи привёл к необычно высокому уровню нестабильности. Когда об этом спросили одного из авторов, он ответил: «Ну да, есть некоторые хитрости, которые не попали в статью», и отказался делиться этими трюками. То есть компания намеренно опубликовала непродуктивный результат, чтобы не выдавать детали, как она обычно и делала с багами.
Компания угрожает мгновенно уволить любого сотрудника, который допустит утечку информации. Это рассказывают каждому новичку с примерами людей, уволенных за утечку (например, один парень слил информацию, что концерт будет происходить в определённом офисе). Каждое такое увольнение громко освещается и доводится до всех сотрудников. В результате такой политики многие боятся пересылать электронные письма даже с невинной информацией вроде обновления данных по страховке. Вместо этого они распечатывают письмо с другого компьютера — и передают в бумажном виде. Или фотографируют на телефон. Нормально.
В одном офисе я как-то спросил, почему двое конкретных сотрудников вроде как избегают друг друга. Мне сказали, что их вражда длится уже десять лет. На самом деле в последнее время ситуация улучшилась. В течение многих лет они буквально не могли находиться в одной комнате, иначе один из них слишком разозлится и сделает что-то прискорбное. Но теперь парни остыли, так что их можно иногда встретить в одном крыле офиса или даже в одной комнате. И это не просто случайные люди. Это менеджеры двух единственных команд в этой компании. Нормально!
Есть компания с настолько странной культурой, что о ней можно написать небольшую книгу. В самом деле, я недавно начал писать пост об этой компании, и уже написал более 100 тысяч слов — больше, чем все посты в моём блоге, вместе взятые.
В этой компании мне объяснили, что решения гораздо лучше принимать не на основе данных, а на основе политических связей, и что идея принятия решений на основе данных в любом случае является мифом — никто так не делает.
В этой компании мне назвали четыре причины работать у них. Все четыре оказались ложью. В итоге мои трудовые обязанности свелись к тому самому, что при приёме на работу я договорился ни в коем случае не делать.
Когда я пришёл в эту компанию, моя команда в течение нескольких месяцев не трогала систему контроля версий. Пришлось побороться, чтобы заставить всех её использовать. Эту битву я выиграл. Но так и не смог убедить сотрудников сначала запускать тесты. Поэтому сборка ломается несколько раз в день.
В разговоре с руководством я заикнулся, что считаю это проблемой производительности нашего отдела. Мне ответили, что это нормально. Такая ситуация у всех сотрудников, так что все в равных условиях. Моя задача — ранжировать их, так что если проблема одинаково сказывается на всех, то нет причин для беспокойства.
Ещё одна компания запустила множество масштабных инициатив по привлечению женщин-разработчиков, но женщин по-прежнему отсеивают на собеседованиях вопросами типа «У вас был опыт работы с алгоритмами или только кодирование?» Я думал, что моя кандидатка с очень хорошей рекомендацией пройдёт через этот барьер, но забыл, насколько нормальной была компания.
В другой фирме я работал в команде из четырёх человек над проектом с бюджетом в несколько сотен миллионов долларов и годовым эффектом в миллиард долларов. При этом запросы на вещи стоимостью в сотни долларов рассматривались месяцами или отклонялись.
Вам может показаться, что я работал только в необычайно плохих компаниях. Но нет, у них хорошая репутация, а две из них считаются одними из лучших компаний для трудоустройства. И я слышал подобные истории и от сотрудников других компаний, даже с отличной инженерной репутацией. Разница только в том, что теперь уже я был в шоке, а собеседник считал, что всё нормально.
Многие компании используют библиотеку Flaky, добавляющую питоновские аннотации к ненадёжным тестам, которые то проходят, то нет. Я спросил сотрудников трёх разных компаний, что делает Flaky. Все они предположили, что она многократно запускает тест и сообщает в случае неудачи. Близко, но не совсем. Технически можно её и так использовать, но на практике она многократно перезапускает тест и сообщает об удачном прохождении. Flaky разработала компания, которая занимается инфраструктурой хранения данных, при этом библиотеку активно использует её крупнейшей конкурент. Помечать как пройденные тесты с потенциальными багами совершенно нормально.
Есть компания, которую знают за хорошие инженерные практики. Когда я последний раз проверял, у неё был аптайм 99,99%, что полностью объясняется принятыми там инженерными практиками. Если какой-то стартап равняется на Twitter или Reddit, то ему достаточно одной девятки, но мы говорим об инфраструктурной платформе, которой действительно необходимо две. Многие компании, которые строят инфраструктуру для двух девяток, считают полностью нормальными свои практики, которые приводят к такой надёжности.
Насколько я могу судить, многие из этих компаний прошли большой путь. Сначала они фокусировались только на росте продукта. Это абсолютно разумно, потому что изначально стоимость компании примерно равна нулю. Она не внедряет грамотное системное администрирование или реальную безопасность, потому что ей нечего терять. Ну, за исключением пользовательских данных, когда их неизбежно взламывают, а если вы поговорите с сотрудниками безопасности крупных частных стартапов (их называют «единорогами», unicorn), то это происходит постоянно.
В результате рождается культура, чрезмерно сосредоточенная на росте, без учёта рисков. Эта культура часто сохраняется даже когда компания выросла до миллиарда долларов и ей уже есть что терять. Если человек раньше работал в Google, Amazon или другой компании с солидными процедурами, то ситуация его шокирует. Часто он пытается что-то исправить, но ничего не может сделать и увольняется.
Вероятно, у Google сегодня лучшие операционные практики и методы обеспечения безопасности среди всех IT-компаний в мире. Легко сказать, что следует брать с неё пример. Но поучительно посмотреть, как они этого достигли. И что творилось раньше. Если посмотреть на кодовую базу, вы увидите много сервисов, названия которых заканчиваются на z, а также удивительно большое количество переменных. Один из старых сотрудников сказал, что когда-то давно кто-то хотел добавить мониторинг. Было не очень безопасно выставлять для мониторинга google.com/somename, поэтому они добавили z, то есть google.com/somenamez — для безопасности. Это в компании, которая сейчас считается лучшей в мире по безопасности.
Теперь она настолько далеко продвинулись в безопасности, что новые сотрудники яростно отрицают такие практики в прошлом. При этом называют причины, которые на самом деле не имеют смысла (например, чтобы избежать коллизии имён).
Огромный прогресс Google в области безопасности — от добавления буквы z до лучших в мире практик ИБ — произошёл не потому, что кто-то произнёс зажигательную речь или написал убедительное эссе. Он начался после нескольких «факапов». Только тогда безопасникам дали полномочия для решения фундаментальных проблем. У хороших и правильных компаний почти всегда реформы начинаются именно таким образом. Над Microsoft много лет смеялись, но потом несколько катастрофических эксплойтов заставили их изменить своё отношение к безопасности. Это только звучит просто. Но очевидцы говорят, что перемены были жестокими. Несмотря на указание сверху, инерция оставалась очень сильной. Зачем менять то, что работало? Поэтому ощущалось очень сильное давление со стороны людей, которые привыкли всё делать по-старому.
Такие вещи можно увидеть в любой отрасли. Классический пример, который часто приводят технические специалисты, — мытьё рук врачами и медсёстрами. Хорошо известно, что микробы существуют, а мытьё рук с мылом очень сильно снижает вероятность передачи микробов и тем самым значительно снижает уровень смертности в больницах. Несмотря на это, даже опытные врачи и медсестры по-прежнему часто не делают этого. Требуется вмешательство. Знаки, напоминающие мыть руки, спасают жизни. А ещё лучше, чтобы живые люди стояли и требовали мыть руки: так спасается ещё больше жизней. Люди могут игнорировать знаки, но не смогут пройти мимо ответственного лица.
Примерно так IT-компании пытаются внедрить лучшие практики. Если вы говорите сотрудникам, что делать, это немного помогает. Если же внедрить проверку кода, то эффект проявляется сразу.
Статистика ясно показывает, что люди действительно плохо осваивают рутинные привычки, которые не дают видимого эффекта, однако неопровержимо снижают риск редких, но катастрофических событий. Человеку кажется, что срезать путь — это правильный, разумный маршрут. Для этого есть специальный термин: «нормализация девиантности». Он хорошо изучен в ряде других контекстов, включая здравоохранение, авиацию, машиностроение, аэрокосмическую технику и гражданское строительство, но ещё не обсуждался в контексте программного обеспечения.
Можно ли учиться на чужих ошибках, а не на своих? Состояние отрасли не даёт повода рассчитывать на это, но давайте попробуем. Джон Банья написал краткий доклад о нормализации девиантности в здравоохранении, выводы которого можно применить к разработке ПО. Можно отметить, что лечение пациентов можно сравнить с действиями девопсов. Впрочем, нормализация девиантности происходит также в культурном контексте, где аналогия не так очевидна.
В первом разделе статьи подробно описан ряд катастрофических ситуаций, как в здравоохранении, так и в других областях. Вот один типичный пример:
Случай катастрофической небрежности, который автор наблюдал в качестве свидетеля-эксперта, был связан с отключением анестезиологом аппарата искусственной вентиляции лёгких по просьбе хирурга, который хотел сделать рентген брюшной полости пациента (Банья, 2005, стр. 87–101). Аппарат искусственной вентиляции лёгких должен был отключиться всего на несколько секунд, но анестезиолог забыл его включить обратно или думал, что включил, но не включил. Пациентка находилась без кислорода достаточно долго, чтобы началась полная аноксия, которая погрузила её в вегетативное состояние. Она так и не оправилась. Через 9 дней её отключили от искусственной вентиляции лёгких, а ещё через 2 дня умерла. Позже было обнаружено, что анестезиологическая сигнализация и контрольное оборудование в операционной были намеренно запрограммированы на режим «приостановки на неопределённый срок» таким образом, что анестезиолог не получал предупреждения о проблеме с аппаратом искусственной вентиляции лёгких. Сама сигнализация была на месте, но отключена, возможно, потому что персонал операционной находил раздражающим постоянный писк прибора.
Выключить или игнорировать уведомления, потому что их слишком много и они слишком раздражают? Действовать вручную с риском ошибиться? Да я могу навскидку назвать сразу несколько компаний, где разбор полётов после катастрофы начинается именно с этих пунктов, разве что в итоге никто не умирает, а теряется лишь несколько миллионов долларов. Если вы читали много разборов таких происшествий в IT, то каждый пример в статье Баньи покажется вам знакомым, пусть детали и отличаются.
Раздел завершается таким выводом:
Как правило, эти бедствия объясняются «длительным нарушением правил, противоречивыми событиями, которые накапливались незамеченными, и неверным культурным представлением об опасностях. Все вместе эти факторы помешали произвести вмешательство, которые могло предотвратить вредные последствия». Особенно поразительно, как многочисленные нарушения правил и ошибки объединяются вместе, чтобы появилась возможность для катастрофы.
Опять же, текст словно из статьи о технических сбоях. Поэтому заслуживает внимания следующий раздел, посвящённый причинам этих сбоев. А причины таковы.
В статье приводится пример введения лекарств новорождённым. Чтобы предотвратить «утечку лекарств», медсестра должна ввести пароль на компьютере. Она получает доступ к ящику с лекарствами и берёт нужное количество лекарства. Чтобы убедиться, что первая медсестра ничего не украла, за процессом должна наблюдать вторая медсестра. Потом она должна ввести в компьютер свой пароль как подтверждение, что наблюдала правильную процедуру обращения с лекарством.
Звучит знакомо. Немало отчётов об инцидентах начинаются с того, что «кто-то пропустил некоторые шаги, потому что они неэффективны». Например, «программист запушил плохую конфигурацию или плохой код, потому что был в ней уверен и не хотел тратить время на staging или тестирование». Печально известное отключение Azure в ноябре 2014 года произошло именно по этой причине.
Примерно в то же время у одного из конкурентов Azure разработчики отменили правило, запрещающее пушить в ветку Canary конфигурацию, которая не проходит тесты. Разработчики были уверены, что конфигурация в порядке. Когда Canary начал глючить, они отменили правило, запрещающее деплоить из Canary в Staging с ошибкой. Они были уверены, что конфигурация в порядке, а сбой вызван чем-то другим. Последующий анализ показал, что конфигурация была технически правильной, но с ней проявлялся баг в основном программном обеспечении. Чистая удача, что скрытый баг, выявленный конфигурацией, не был таким серьёзным, как баг Azure.
Люди плохо понимают, как ошибки накладываются друг на друга. Поэтому мы принимаем правила для безопасного деплоя. Но по той же самой причине, почему люди плохо понимают, как ошибки накладываются друг на друга, эти правила кажутся глупыми и неэффективными!
Понятие нормы не является врождённым. Когда в компанию приходят новые люди, они легко усваивают также и девиантные процессы, которые стали нормой.
Джулия Эванс описала мне, как это происходит:
приходит новичок
новичок: WTF WTF WTF WTF WTF
ветеран: да, мы знаем, мы этим занимаемся.
новичок: WTF WTF wTF wtf wtf w…
новичок привыкает
приходит второй новичок
новичок №2: WTF WTF WTF WTF
новичок: да, мы знаем, мы этим занимаемся.
Самое коварное, что люди действительно принимают идею WTF, и потом могут сами распространять её в других местах на протяжении всей своей карьеры. Однажды я работал с одним опенсорсным проектом, который регулярно падал. Мне сказали, что это нормально, а их продукт лучше среднего. Я проверил и обнаружил, что он худший в своём классе почти по всем показателям. И набросал идею, как относительно малыми усилиями выпускать билды, которые будут почти всегда проходить тесты. Самый распространённый ответ был таким: «Вау, этот парень, должно быть, работает с суперзвёздными программистами. Но будем реалистами. У всех сборка ломается хотя бы несколько раз в неделю». Как будто выполнение тестов (или, если уж на то пошло, даже попытка компиляции) перед проверкой кода требует сверхчеловеческих усилий. Но как только люди верят, что какое-то отклонение является нормальным, то зачастую действительно впитывают идею.
В статье приводится пример врача, который нарушает правило, что при поиске вены следует надевать перчатки. Он считает, что ношение перчаток затрудняет поиск вены, поэтому придётся тыкать ребёнка иглой несколько раз. С этим трудно поспорить. Никто не хочет причинять ребёнку лишнюю боль!
Второй по масштабу сбой из всех, какие я видел в жизни, случился по этой причине. Кто-то заметил подтормаживание БД. Они быстро написали патч, а чтобы деградация не распространялась дальше, проигнорировали правило медленного, поэтапного деплоя. Вместо этого они накатили патч на все машины. С этим трудно поспорить. Никто не хочет, чтобы клиенты столкнулись с деградацией сервиса! К сожалению, патч выявил ошибку, которая вызвала глобальное отключение сервиса.
Большинство людей воспринимают себя как хороших и порядочных, поэтому могут считать свои нарушения правил как полностью рациональный и этически приемлемый ответ на проблемные ситуации. Они уверены, что не делают ничего плохого, и будут возмущены и часто яростно защищать себя, если столкнуться с доказательствами обратного.
По мере роста компании приходится вводить систему безопасности, которая не позволяет каждому сотруднику иметь доступ практически ко всему. И когда это происходит, в большинстве компаний некоторые сотрудники действительно расстраиваются: «Вы мне не доверяете? Если доверяете, то почему лишаете доступа к X, Y и Z?»
Известно, что Facebook долгое время предоставлял сотрудникам доступ к профилю любого пользователя. Некоторые рекрутеры даже упоминали это в качестве преимущества работы в Facebook. И я знаю не один уважаемый стартап, где по-прежнему у каждого сотрудника есть доступ практически ко всей информации, даже после одной или двух утечек информации. Нужна определённая политическая воля, чтобы ограничить доступ людей к тому, что они считают нужным или привычным по праву. Во многих модных стартапах заявлены базовые ценности «доверие» и «прозрачность», которые мешают обосновать ограничение доступа.
Некоторым людям я не хочу высказывать своё мнение, потому что они могут встретить его в штыки, а сказанные слова уже не вернуть. В упомянутой научной статье автор приводит пример врача с плохим почерком. Тот злится, когда кто-нибудь просит разъяснить, что он написал. В результате люди гадают, а не спрашивают.
В большинстве компаний сложилась культура, что обратная связь затруднена. Многие проекты затягивались на несколько месяцев, а потом прекращались, потому что каждый сотрудник боялся с самого начала высказать своё мнение, опасаясь критики в свой адрес. Проблема присутствует даже в культурах, которые поощряют вежливость: там тоже трудно высказать искреннюю критику. Получается, в одних компаниях люди боятся говорить, потому что на них нападёт кто-то злой. В других боятся говорить, потому что их самих заклеймят как злых. Трудная проблема.
В научной статье говорится, как информация о проблеме размывается при передаче по цепочке вверх. Один из примеров — как руководитель предпринимает неоптимальные действия, чтобы не выглядеть плохо перед начальством.
Я был потрясён, когда увидел это в первый раз. Люди понимают, что делают что-то явно неправильное. Но если произвести оптимизацию, существует ненулевая вероятность неудачи, и тогда будет очень неловко. Поэтому проще оставить всё как есть. С годами профессионального опыта я лучше понимаю, как и почему люди играют в эту игру, но всё ещё нахожу её абсурдной.
Предположим, у вашей компании типичная проблема: людей награждают за героизм в тушении пожаров, а не за их предотвращение. И люди получают повышение за выпуск новых функций, а не за выполнение критических работ по техническому обслуживанию и исправлению ошибок. Как это изменить?
Самый простой вариант — просто делать правильные вещи самостоятельно и игнорировать то, что происходит вокруг. Вы принесёте некоторую пользу, но масштаб вашего влияния ограничен. Далее, можете убедить свою команду делать правильные вещи: я делал это несколько раз для внедрения практик, которые считаю действительно важными.
Но если стимулы направлены против вас, потребуются постоянные и ненормированные усилия, чтобы заставить людей делать правильные вещи. В этом случае проблема в том, чтобы уговорить кого-то изменить стимулы, а затем убедиться в том, что изменения работают как положено. Как убедить руководство изменить стимулы — тема отдельной статьи. Что касается осуществления изменений, я видел много «очевидных» ошибок, которые повторяются в разных компаниях.
Небольшим компаниям это даётся легко. Когда я работал в компании из ста человек, там была простая иерархия: индивидуальный участник (IC) → тимлид (TL) → гендиректор (CEO). Вот и всё. Директор особо не вмешивался, но если он что-то говорил, это беспрекословно исполнялось. Важно, что он отлично знал, чем занимается каждый сотрудник, и мог в целом регулировать вознаграждения в режиме реального времени. Если вы сделали что-то хорошее для компании, то могли рассчитывать на повышение. Не через девять месяцев, когда подошёл следующий цикл анализа эффективности персонала, а практически сразу. Не у всех маленьких компаний это эффективно работает, но при правильном руководстве такое возможно. В крупных компаниях никак.
В одной крупной компании была такая проблема. От руководства пришло распоряжение поощрять сотрудников за выполнение критической, но малозаметной работы. Сотрудников было слишком много, чтобы сразу распределить бонусы, но менеджер мог анализировать отчёты, принимать решения о выборочной проверке и выдавать бонусы, так что со временем правильные стимулы станут частью культуры. По моему личному мнению, компания так и не достигла паритета между скучной работой по техническому обслуживанию и блестящими новыми проектами. Но люди хотя бы начали работать над инфраструктурой и исправлением ошибок без особого ущерба для своей карьеры.
В другой крупной компании рядовые сотрудники согласились, что неправильно более щедро вознаграждать за создание новых функций, чем за выполнение критической работы. Когда я разговаривал с менеджерами, они тоже часто соглашались. Тем не менее, повышение получали в основном разработчики блестящих новых штучек. Руководство предприняло попытки культурных и технологических изменений. В основном, в виде вдохновляющих заявлений от людей с причудливыми должностями. Для действительно важных вещей нужно было посмотреть видео и пройти обязательный тест с несколькими вариантами ответа после просмотра видео. Единственным результатом этой кампании стало общее мнение, что руководство очень далеко от жизни рядовых сотрудников.
Немного забавно, что в конечном итоге всё сводится к проблеме стимулов. Мы в отрасли много думаем, как стимулировать потребителей делать то, что мы хотим. Но внутри компании создаём себе систему стимулов, которая толкает на неправильные вещи. Эдакая смесь испорченного телефона и культа карго. В старые времена образцом для подражания была Microsoft — мы копировали их методы и задавали головоломки собеседования. Теперь образцом стала Google — и мы задаём вопросы по алгоритмам. Если посмотреть на модные компании, которые моложе Google, большинство из них в основном копируют систему должностей Google, с некоторыми незначительными изменениями. Хорошая новость в том, что Google хорошо продумала большинство своих процессов, а решения принимаются на основе данных. Плохая новость в том, что Google во многих отношениях уникальная компания. Их практики зачастую не действуют для остальных, так что люди просто практикуют карго-культ. Причём ещё долгое время после того, как в Google уже отказались от этой практики.
Такая диффузия происходит и в технических решениях. Stripe построил надёжную очередь сообщений поверх Mongo, поэтому мы тоже будем строить надёжные очереди сообщений поверх Mongo1. Карго-культ спускается по цепочке вниз2.
В медицинской статье есть специальные подразделы о том, как предотвратить нормализацию девиантности.
- Обращайте внимание на слабые сигналы.
- Сопротивляйтесь желанию быть неоправданно оптимистичным.
- Научите сотрудников вести эмоционально некомфортные разговоры.
- Системные операторы должны чувствовать себя в безопасности, высказывая мнение.
- Осознать, что надзор и мониторинг не прекращаются никогда.
Давайте посмотрим, как работает первый принцип, когда в компанию приходит новичок и начинает испускать вопли «WTF WTF WTF».
Когда своё мнение высказывает вице-президент, люди обычно прислушиваются к нему. Это сильный сигнал. Если нет, вице-президент всё равно знает, как претворить в жизнь своё решение. Новичок не знает, за какие рычаги потянуть, с кем поговорить. Они выдаёт слабые сигналы, которые легко игнорировать. К тому времени, когда он достаточно изучит систему, чтобы выдавать сильные сигналы, он уже акклиматизируется.
«Обращайте внимание на слабые сигналы» звучит хорошо, но как это сделать? Сильные сигналы немногочисленные и редкие, поэтому на них легко обратить внимание. Слабых сигналов слишком много. Как отфильтровать шум? И как заставить всю команду или организацию в реальности сделать это? На такие вопросы нет простого ответа, нужно уделить этому значительное внимание.
К сожалению, компании редко это делают. Стартапы много думают о росте. Хотя все говорят, что их очень волнует инженерная культура, на практике это не так. За некоторыми исключениями, крупные компании не сильно отличаются. В одной их таких компаний я видел слайды конкурентного анализа, и они потрясающие. Изучаются мельчайшие детали в сотнях продуктов для гарантии, что пользователи получат идеальное качество по всем показателям, от внедрения до взаимодействия с конкурирующими продуктами. Если хоть один параметр сложнее или запутаннее, чем у любого конкурента, люди расстраиваются и пытаются исправить ситуацию. Это очень впечатляет.
Затем компания принимает новых сотрудников, и у каждого третьего отсутствует или аккаунт в системе, или место в офисе, или компьютер — и такое состояние может сохраняться неделями или месяцами. Слайды конкурентного анализа говорят, что у вас только один шанс произвести первое впечатление, а затем у сотрудников создаётся впечатление, что компания не способна о них позаботиться. И что постоянно нарушать рабочие процессы — это нормально.
Компания не может понять даже основы онбординга, не говоря уже о таких действительно сложных вещах, как аккультурация. Причины понятны. Внешние показатели, такие как рост или уменьшение аудитории, поддаются измерению, в отличие от аккультурации новичков, чтобы они не игнорировали слабые сигналы. Но это не значит, что последнее менее важно. Много говорят, как новые языки или методы, такие как TDD или Agile, повышают продуктивность, но наличие сильной инженерной культуры — гораздо более мощный мультипликатор.
1. Кажется, люди думают, что я шучу. А попробуйте погуглить mongodb message queue. Вы найдёте заявления вроде «наборы реплик в MongoDB очень хорошо обеспечивают избыточность и автоматическую отработку отказа». Практически все известные мне компании, которые попробовали это в большом масштабе, сочли систему неоптимальной, мягко говоря. Но вы ничего об этом не найдёте. Только статьи и презентации от компаний, которые попробовали и очарованы этой СУБД. Это характерно для многих технологий. На публике блестящие рекомендации, а в частном порядке люди расскажут вам обо всех проблемах. Если сегодня запустить такой поисковый запрос, вы найдёте массу восхищённых статей о том, как здорово построить очередь сообщений поверх Mongo, найдёте эту статью и, может, нескольких статей в блоге Кайла Кингсбери, в зависимости от конкретной поисковой фразы. [вернуться]
Если произойдёт серьёзный сбой, вы увидите разбор полётов с техническим описанием. Но мы любим делать такой разбор для аварий типа «Сайт отключился на 30 секунд», но редко разбираем ситуации типа «Это требует в 10 раз больше усилий, чем альтернативный вариант, и это смерть от тысячи порезов» или «Мы плохо спроектировали систему, и теперь очень трудно внести изменения, которые должны быть тривиальными», или «Наш конкурент смог сделать то же самое, затратив на порядок меньше усилий». Я иногда провожу неформальный разбор полётов, задавая всем причастным наводящие вопросы, но это больше для себя, потому что я не уверен, что люди действительно хотят услышать правду. Особенно если несколько сотрудников получили повышение за разработку этого проекта. Похоже, чем более испорчен проект, тем чаще за него награждают. Чем больше проект, тем он заметнее и тем больше бонусов, даже если его можно было бы сделать с гораздо меньшими усилиями.
2. Я часто задавал этот вопрос и в успешных компаниях, и в других, где всё плохо. Там, где всё плохо, у каждого есть идеи. Но там, где всё хорошо, никто не имеет представления, почему всё работает, как в упомянутой небольшой компании с директором, который особо не вмешивается в дела. Удивительно. Люди буквально говорят, что всё похоже на какую-то другую компанию, где они работали, за исключением того, что там было всё плохо, а здесь волшебно хорошо. По причинам, которые они не понимают. Но это не магия. Это тяжёлая работа, которую мало кто осознаёт. Я много раз видел, как уходит вице-президент — и в компании становится неприятно работать. Постепенно до людей доходит: вице-президент следил, что все сотрудники были счастливы на своих рабочих местах. Трудно это понять, пока ситуация не испортится. Если вы не видите ничего явно неправильного, то либо не обращаете внимания, либо кто-то приложил массу усилий, чтобы всё шло гладко. [вернуться]
