Я разрабатываю информационные системы уже двадцать лет. И за это время понял одну неприятную вещь.

Бас-фактор – это не строчка в чек-листе рисков. Это живой человек, у которого в голове лежит то, чего нет больше нигде.

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

План был нормальный. Человек ещё работает, мы потихоньку передаём знания, я вникаю, как оно всё устроено. Бизнес даже подготовился, насколько вообще к такому можно подготовиться.

Но рак победил раньше. Буквально за две недели человека не стало.

Что значит «один носитель знаний» на практике

Дальше начинается то, ради чего я и пишу этот текст.

Проект был сделан правильно. Не подхаченый на коленке, а по-взрослому. Требование HIPAA – значит, все данные на зашифрованном диске. Сам процесс крутится на зашифрованном диске. Безопасность на уровне.

Но есть один нюанс.

Пароль от этого диска знал только разработчик.

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

Я не могу сказать, что я плохо разбираюсь. Разбираюсь нормально. Но всё равно это тяжело. Потому что в коде лежит «как», а «зачем» лежало в голове.

«А давайте AI всё восстановит»

Знаю, что сейчас кто-нибудь скажет.

«Так это же ерунда. Даже с AI?»

Именно эту фразу я и услышал. «При чём здесь AI? С AI всё лучше».

А притом, что AI там нечего жевать. Там нет кода, который объясняет бизнес. Там нет комментария «мы делаем эту проверку, потому что клиент в 2019 году попал на штраф». AI прекрасно достроит синтаксис. Но он не достроит контекст, которого нет в файлах.

Это не задача про код. Это задача про знание, которое умерло вместе с человеком.

Так что AI здесь – не спасатель. В лучшем случае – ускоритель раскопок.

Откуда вообще берётся бас-фактор

Тут важно не сваливать всё на злой рок. Экстремальные ситуации не падают с неба. Они рождаются из экономии.

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

И именно поэтому он становится точкой отказа.

Потому что когда человек оперирует бизнесом, его знание – это не строчки. Это понимание, почему сделано так, а не иначе. И вот это понимание по документам не передаётся. Документ говорит «что». Человек знает «почему».

Бизнес экономит на дублёре, на ротации, на скучных разборах «а как это работает». Сперва это выглядит как эффективность. Один человек тянет – зачем платить двоим.

Но кто же знал, что человек смертен. Причём, как говорил классик, иногда внезапно смертен.

Документация – это не страховка

Тут принято сказать «ну надо было всё задокументировать». Согласен. Но не обольщайтесь.

Документация фиксирует состояние. А продуктовое знание – это не состояние, это способ думать. Вы можете описать все таблицы, все эндпоинты, все конфиги. И всё равно новый человек полгода будет въезжать, почему система ведёт себя именно так.

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

Значит, документация нужна. Но она – нижний уровень страховки, а не весь полис.

Чем бас-фактор отличается в продуктовой компании

Тут есть тонкость, про которую часто забывают.

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

Но это же повышает бас-фактор. Чем ценнее человек для домена, тем больнее его потерять. Не потому что код некому писать – код напишут. А потому что некому объяснить, что этот код означает для бизнеса.

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

Что с этим делать

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

  • Ни один секрет не должен жить в одной голове. Пароли, ключи, доступы – минимум в двух местах, лучше в нормальном секрет-сторе. Зашифрованный диск без второго держателя пароля – это бомба с таймером.
  • У каждого критичного куска должен быть «второй человек». Не дублёр на полную, а тот, кто хотя бы раз сам прошёл весь путь руками.
  • Передавайте «почему», а не только «что». Лучший формат – не документ, а живой разбор: посадить второго человека и провести его по бизнес-логике.
  • Делайте ротацию на скучных, но критичных задачах. Тот, кто никогда не трогал деплой, в нужный момент его не сделает.
  • Код – в общий репозиторий, всегда. Гитхаб в моей истории спас проект. Это банально, но банальности и спасают.
  • Считайте бас-фактор осознанно. Сядьте и спросите: кто у нас единственный? Если ответ есть – это уже план работ.

Заметьте, ни один пункт не про героизм. Бас-фактор лечится не подвигом, а скукой – регулярной, занудной, неинтересной передачей знаний.

Почему это важно за пределами одной грустной истории

Можно сказать – ну, редкий случай, человек умер, что теперь, паниковать.

Не паниковать. Но и не врать себе.

Человек не обязан умирать, чтобы выбить вам бас-фактор. Он может уволиться в обиде. Уйти к конкуренту. Уехать в другую страну. Просто выгореть и пропасть на месяц. Результат для проекта тот же – знание ушло за дверь, а вы остались с кодом, который надо расшифровывать.

И вот что я понял за эти двадцать лет. Бас-фактор – это всегда плата за экономию, отложенная во времени. Сегодня вы экономите на дублёре. Завтра платите реверс-инжинирингом, сорванными сроками и нервами.

Посчитайте свой бас-фактор честно. У кого в команде в голове лежит то, чего нет ни у кого больше? Обсудить можно в Telegram.