Если знает только один человек, это уже проблема.
В iGaming технический отдел работает в среде, где постоянно появляются новые GEO, источники, домены, трекеры, прокси, лендинги и интеграции. Вместе с инфраструктурой растет и объем знаний внутри команды.
И почти всегда постепенно появляется человек, который начинает знать «все»: где находятся серверы, как настроен Keitaro, какие используются прокси, где лежат доступы, как подключить новый лендинг и где искать проблему, если перестал идти трекинг.
Пока этот человек на связи, система работает. Но стоит ему уйти в отпуск, заболеть или просто оказаться недоступным в нужный момент — становится понятно, что компания построила не систему, а зависимость от одного специалиста.
Такая зависимость редко появляется намеренно. Обычно все начинается с одной задачи.
Например, один человек первым настроил антидетект-браузер и дальше по привычке всегда выдавал доступы баерам. Пока команда небольшая, это удобно. Но с масштабированием оказывается, что никто больше не знает ни как все настроено, ни что делать, если этого человека нет на связи.
То же самое постепенно происходит с серверами, трекерами, прокси, доменами и другими частями инфраструктуры.
Сначала специалист просто знает процесс лучше остальных. Затем коллеги начинают обращаться к нему со всем, что связано с этим направлением. Новые сотрудники обучаются через него. Сложные задачи автоматически уходят к нему.
И в какой-то момент в команде появляется фраза:
«Это всегда делал Петя».
Для меня сейчас это один из главных редфлагов. Как и «я не знаю, как это делать» в отношении критического процесса.
Потому что следующий этап — ситуация, в которой Петя недоступен, а вместе с ним недоступен и сам процесс.
Цена такой зависимости особенно хорошо становится видна во время сбоев.
У нас был случай, когда ночью упал важный сервер, а доступы и основные знания о проекте находились у одного человека. Именно в этот момент он был недоступен. В итоге вместо того, чтобы сразу устранять причину сбоя, команде пришлось сначала восстанавливать доступы, подключать людей, которые раньше не работали с проектом, и параллельно разбираться в его устройстве. Ситуацию удалось решить, в том числе благодаря бэкапам, но времени на это ушло гораздо больше.
Такие ситуации работают как снежный ком:
не работает сервер → команда не может запуститься → откладывается тестирование → теряется время и потенциальный доход.
То есть проблема довольно быстро перестает быть технической. Она начинает влиять на скорость других отделов и бизнеса в целом.
Поэтому задача руководителя — не найти одного человека, который умеет все, а построить систему, в которой критически важные знания не заканчиваются на одном сотруднике.
Для каждого критического процесса должно быть минимум три составляющих:
основной специалист + резервный специалист + инструкция.
Например:
| Процесс | Основной |
Резерв |
| Создание PWA | Tech 1 | Tech 2 |
| Keitaro | Tech 2 | Tech 3 |
| Прокси | Tech 3 | Tech 1 |
| Лендинги | Tech 1 | Tech 3 |
| Серверы | Tech 2 | Tech 1 |
При этом не нужно стремиться к тому, чтобы каждый технический специалист знал абсолютно все.
Зоны ответственности можно разделять по направлениям: Infrastructure — серверы, SSL, DNS и домены; Tracking — Keitaro, postback и интеграции; Traffic Infrastructure — прокси и технические аккаунты; Web — лендинги, PWA, редиректы и техническая часть сайтов.
Главное, чтобы у критического направления был второй человек, способный подхватить работу.
И здесь есть важный нюанс: если сотрудник числится резервным, но ни разу самостоятельно не выполнял задачу, настоящего резерва у вас нет.
Второй слой системы — документация.
С ростом команды очень легко оставить ее «на потом»: процессы уже работают, быстрее спросить человека в чате или созвониться и попросить показать.
Мы сами проходили через обучение в формате «давай созвонимся — покажу и расскажу». Пока не становится очевидно, что один и тот же процесс гораздо эффективнее один раз записать и сохранить в базе, чем объяснять каждому новому человеку заново.
При этом документация не должна существовать ради документации.
В первую очередь стоит описывать реальные повторяющиеся сценарии: запуск нового домена, подключение лендинга, проверку трекинга и postback, подключение нового источника, восстановление доступа, действия при недоступности сервиса.
Хорошая документация должна отвечать не только на вопрос «как у нас всё устроено?», но и на вопрос «что мне делать прямо сейчас?».
И ее наличие еще не означает, что знания действительно переданы.
Рабочая схема выглядит примерно так:
1. Один специалист выполняет задачу, второй наблюдает;
2. Следующий раз они делают ее вместе;
3. Затем второй выполняет задачу самостоятельно;
4. Первый только проверяет результат.
Только после этого процесс действительно перестает быть привязан к одному человеку.
Можно идеально распределить знания внутри команды и все равно зависеть от одного специалиста, если только у него есть нужные доступы.
На раннем этапе мы тоже сталкивались с тем, что логины и пароли не были собраны централизованно и часть доступов фактически находилась у одного человека.
Для критических сервисов такая модель опасна.
Доступы к серверам, Cloudflare, трекерам, прокси, доменным регистраторам и другим важным инструментам должны быть централизованно организованы, разграничены по ролям, защищены и доступны нескольким ответственным сотрудникам.
При этом пароли не должны храниться в обычной документации.
Когда процесс понятен, описан и распределен между людьми, следующий этап — автоматизация повторяющихся операций.
Это может быть мониторинг доменов и серверов, отдельные этапы настройки инфраструктуры и другие действия, которые команда регулярно выполняет вручную.
Но автоматизация не должна маскировать отсутствие процессов.
Последовательность здесь простая:
понять → описать → стандартизировать → распределить → автоматизировать.
Иначе вместо одной точки отказа можно получить автоматизированную точку отказа.
Чтобы понять, насколько технический отдел зависит от отдельных людей, не обязательно начинать с большого аудита.
Можно выбрать любой критический процесс и спросить:
Кто выполнит эту задачу, если основной специалист завтра не выйдет на работу?
Где находится актуальная инструкция?
У кого есть необходимые доступы?
Если на первый вопрос ответ — «никто», на второй — «инструкции нет», а на третий — имя того же специалиста, зависимость уже существует.
Сильный специалист может знать больше остальных — и это нормально. Проблема начинается тогда, когда вместе с его отсутствием останавливается работа.
Поэтому незаменимый сотрудник — не показатель зрелости технического отдела.
Зрелая команда — это не команда, где каждый умеет все. Это система, в которой знания распределены, критические процессы имеют резерв, документация работает на практике, доступы не заканчиваются на одном человеке, а повторяющиеся операции постепенно автоматизируются.
Хороший технический отдел — не тот, где есть человек, способный решить любую проблему. Это тот, где для решения проблемы не нужно ждать конкретного человека.
Ваш менеджер 
Website 
0 
Удалось как то налить им, 900~ фтд где-то вышло. До сих пор даже капает. Может чуть позже еще вернусь снова по ревшаре полить, а то в кейсах у коллег уж больно сладкие RD, надо проверить.
Ребята аффы написали вчера говорят вернуться траф дать)) ну отзыв попросили оставить, мне в целом не сложно, но вот как есть)