Как подготовиться к столкновению с автобусом?

Если вы работаете подрядчиком, я бы сказал, что это на 100% зависит от вашего работодателя. Скажите им, что достижение целей, которые они перед вами поставили, означает, что другие вещи, которые, по вашему мнению, должны считаться целями, не выполняются; спросите их, хотят ли они скорректировать ваши цели. Они вполне могут сказать вам, чтобы вы продолжали как есть, так как ваше время дорого, и они хотят наилучшего краткосрочного соотношения цены и качества.

Если вы работаете наемным работником, у вас может быть больше свободы для планирования преемственности (или, возможно, есть ожидание, что вы уже это делаете). Тем не менее, обсудите это со своим руководителем группы или менеджером, так как им нужно знать о проблеме и о том, как вы себя чувствуете, и считаете, что вы должны быть, тратя свое время.

Некоторые вещи, которые помогут в планировании преемственности:

• Повседневные процессы должны быть до некоторой степени задокументированы, но вполне вероятно, что другие люди в вашей команде следуют тем же процессам и могут научить им новичка. Если вы не все используете одинаковые процессы, это текущая проблема, которую следует решить; собраться вместе, обсудить, какой путь лучше, прийти к какому-то стандарту (консенсуальному или принудительному сверху) и использовать стандарт, поздравления, что стандарт может войти в вашу документацию для новичка.
• Важные вещи, о которых сообщается по электронной почте, на собраниях или в случайных беседах, должны превратиться в общий ресурс, будь то папка с документами на общем диске или вики. Существует странное убеждение (по крайней мере, там, где я работал), что если что-то отправить по электронной почте всем членам команды, то эта команда навсегда узнает об этом; это не принимает во внимание, что состав команды меняется и что любое обучение (если оно вообще происходит) никогда не передаст все знания, а только подмножество часто используемых знаний.
• (Возможно, в зависимости от программного обеспечения) Четко документируйте противоречащие интуиции процессы или проектные решения, важно определить, что процесс признан противоречащим здравому смыслу, и почему это так, несмотря ни на что. Например, если ваш клиент попросил вас сделать что-то, что кажется «неправильным» («Я не эксперт в предметной области, но вы уверены, что хотите это сделать?»), и вы объяснили, почему считаете это неправильным, и они подтвердили, что это то, что они хотели (еще лучше, если бы они объяснили, почему), то причины, по которым вы считаете это неправильным, и объяснение того, почему это было правильно, должны быть задокументированы. Что программного обеспечения, соответствующего спецификациям, будет недостаточно для замены, у них возникнет тот же вопрос, что и у вас.
• Для любой проблемы, с которой вы сталкиваетесь и для решения которой требуется много времени/исследований, задокументируйте проблему, симптомы, сокращенный путь к решению (т. е. знание того, что вы знаете сейчас, какой был самый быстрый путь от выявления симптомов до решения). ), и решение. Симптомы действительно важны для вашей замены, потому что они поразят их до того, как они полностью осознают проблему.
• Предыдущий пункт еще более важен в отношении устаревших систем, таких как библиотеки или платформы, где новые версии выпускаются, но не используются в вашем продукте. Проблемы, с которыми вы столкнетесь в своей версии (или, что еще хуже, во взаимодействии между несколькими унаследованными системами), могут быть решены в будущих версиях, и поэтому само существование уязвимости исчезнет из поля зрения, пока найти информацию о ней будет практически невозможно.

Документация.

Достаточно частые коммиты кода.

Документация.

Документируйте свои идеи, проекты и код. Любые ошибки, о которых вы знаете.

Документация.

Задокументируйте свои исправления ошибок , объяснив, в чем заключалась проблема, как вы ее исправили и почему.

И я упоминал документацию?

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

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

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

НИЧЕГО не делайте по-другому. Работайте так, как будто завтра вас НЕ собьет автобус.

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

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

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

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

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

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

• ^{О боже, я, кажется, единственный, у кого есть эта информация, мне нужно задокументировать ее, чтобы сделать доступной для всей команды.
  Черт возьми, никто не может исправить эту ошибку, кроме меня, мне нужно найти и обучить резервного парня...}

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

Я, например, хочу быть заменой ...

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

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

Спросите свою команду. Спросите у своего менеджера. Представьте им проблему точно так же, как и нам.

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

Эй, они могут даже решить, что риск стоит того. Но на самом деле решать им.

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

Я хотел протянуть руку и ответить на эти вопросы...

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

Полученный ответ отличается от извлеченного урока!

Объяснение

В основном есть два разных сценария, которые создают единую точку отказа, к которой обращается OP.

Бизнес

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

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

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

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

Работник

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

« The Go To » — это тот сотрудник, которого любит большинство менеджеров. Это тот, кому вы можете поручить практически любую задачу или проект и не беспокоиться об этом. Это люди, которые занимают свою нишу в компании и становятся нужными людьми и, скорее всего, теми, у кого есть ответы.

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

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

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

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

Вот чем мы занимаемся там, где я работаю:

а) Мы используем вики для документации. Не файлы Microsoft Word или текстовые файлы. Вики, которая доступна для поиска, полностью отслеживается изменения и т. д. (Я бы порекомендовал Confluence , но Confluence v4 — такая собака, что я предлагаю вам поискать в другом месте)

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

б) Контроль версий, очевидно

c) Система отслеживания дел/вопросов, очевидно

г) комментировать свою работу. Это самая тонкая вещь, и этому так сложно научить, но как подрядчик/независимый человек вы можете понять следующее: комментарии должны объяснять ваш мыслительный процесс и то, почему вы делаете. Ссылки на документацию, Stack Overflow и т.п. уместны. Абзацы и страницы комментариев уместны. Объяснение вещей, которые вы пробовали и НЕ делали, уместно. Одна из самых больших проблем кода заключается в том, что мысли и пот, потраченные на то, чтобы заставить что-то работать одним способом (а не другим), теряются. Есть книга, что-то вроде «красивый код» или что-то в этом роде, в которой есть фрагмент блоков комментариев в модуле одной из больших открытых систем контроля версий ( Subversion или Git )., Я думаю). Это красиво, потому что рассказывает историю. Вот что делает этот код. Вот как это работает. Вот как это устроено. (Я признаю, что этот блок, насколько я помню, может не углубляться в вопрос «почему».)

Следствием этого является: сколько людей возвращаются и редактируют код только для того, чтобы добавить комментарии? Мы все должны... много. Но на практике почти никто не делает.

У Netflix есть система, которую они называют ChaosMonkey . По сути, он «ломает» или имитирует взлом определенных систем случайным образом.

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

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

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

После написания этого ответа мне стало известно о https://www.fdic.gov/news/news/financial/1995/fil9552.html . По сути, FDIC рекомендует банкам налагать обязательные оплачиваемые отпуска не менее чем на 2 недели подряд для ключевых сотрудников банка. Благополучие сотрудников является второстепенным фактором. Основное соображение заключается в том, что это заставит банки назначать кого-то другого для выполнения обязанностей освобождающегося сотрудника. Если увольняющийся сотрудник присваивает себе деньги, схема развалится под наблюдением нового сотрудника. Это также означает, что банк не будет уязвим для автобусной атаки.

я бы начал с

1. Стандартизация

   Моя последняя позиция перед моей нынешней использовала методологию типа Дикого Запада. Каждый использовал те инструменты, которые хотел, с которыми был знаком. Важно было, чтобы проекты были сданы в хорошем рабочем состоянии и в срок. Это было сделано для ужасного обслуживания кода, когда один проект разрабатывался с использованием GWT в качестве уровня представления и JUnit исключительно для всех видов модульного тестирования, а другой разработчик придерживался необработанных JSP, а еще один добавлял в смесь JSF. Все были прикованы к своим проектам, и уход в отпуск для многих был немыслим и звучал похоронным звоном для код-ревью и оптимизации.

   Я предложил стандартизировать ряд стандартных отраслевых технологий и инструментов, которые гарантировали, что мы все спим в одном направлении кровати (SoapUI для ws-тестирования, JSF для веб-уровня и с умеренным успехом, Spring для серверной обработки и еще пару вещей). И все мы жили долго и счастливо. Препятствуйте любой индивидуальности, когда дело доходит до инструментов торговли, которые будут создавать файлы с проприетарным расширением (или, по крайней мере, пытаться смягчить его); я

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

2. Регулярные и обязательные обзоры кода/проекта

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

3. Командный дух

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

4. Очевидно Документ . Это старая песня. Я не буду петь это снова

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

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

Процесс обычно включает:

• Выявление областей риска
• задокументировать вовлеченные процессы
• определить подходящие ответы на различные сценарии
• Принять планы, чтобы справиться со сценариями

Что бы я сделал, если бы меня предупредили за две недели?

Я сделал быстрый набросок и начал записывать на видео свой экран и голос. В него вошли:

1. Где я все храню.
2. Примеры текущих запросов и то, где я нахожусь в процессе.
3. Демонстрация того, как выполнять некоторые из более уникальных или сложных задач на тот случай, если менее техническому специалисту придется управлять вещами в краткосрочной перспективе.
4. Как находить вещи в базе данных, которую я создал в первый день, чтобы управлять всеми мелочами (когда вы впервые начинаете работу, вы действительно обнаруживаете то, чего не знаете).

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

Наши ежедневные правила против людей, уносящих знания в могилу:

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

По сути, «вещи, которые еще не перечислены/не протестированы, для нас не существуют». Надежны только те вещи, которые перечислены.

Мы называем это « тайным знанием » (хранящимся только в чьей-то голове), и все отказываются действовать в соответствии с ним.

Очевидно, что это не работает между техническими и нетехническими темами. Но мы также не ожидаем, что технари смогут взять на себя финансовые расчеты от бухгалтерии. Так что даже наша бухгалтерия могла бы унести "знания в могилу", если бы хотя бы 1 бухгалтер делал эти расчеты.

Потому что есть предел. Если команда слишком мала, то всегда найдется кто-то, кого собьет автобус.

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

• Работайте в соответствии с устоявшимися стандартами, установленными для вашей области или организации.
• Документируйте то, что вы делаете.
• Подробно документируйте, если вы отклоняетесь от общепринятых стандартов и почему вы это сделали.
• Задокументируйте, как документировать для вашей организации.
• Если вы находитесь на вершине цепочки системного администрирования и владеете учетными записями root/super user; создать учетную запись с максимально возможным уровнем безопасности. Сгенерируйте для него длинный случайный пароль. Распечатайте его на бумаге. Подписать его. Запечатайте его в конверт и передайте совету директоров, а не генеральному директору . Потому что генеральный директор может расстаться с компанией на плохих условиях и при этом сохранить этот пароль. Скажите им, чтобы они хранили его безопасно, за пределами сайта и использовали (это может дать вам статус суперпользователя в сети в случае вашего отсутствия или по другим причинам, которые могут возникнуть).