Короткий ответ
#Оценка, которую нечем оспорить
Оценка приходит в понедельник. Перевод продукта на нового платёжного провайдера, шесть недель работы и абзац о том, что старая интеграция вплетена в систему глубже, чем кто-либо ожидал. Число больше, чем вы надеялись. Вполне возможно, что оно верное.
В этом и неприятность. Проверить вы не можете. Вы не знаете, каких частей системы на самом деле касается платёжная интеграция, поэтому не можете сказать, осторожная это оценка или с запасом. Можно спросить другого разработчика, но ему понадобятся недели, чтобы узнать то, что первый уже знает, и вы заплатите дважды за одно мнение. Поэтому вы принимаете оценку не потому, что согласны, а потому, что вам не с чем не соглашаться.
Никто в этой истории не поступил плохо. Разработчик может быть отличным и честным. История показывает устройство: единственный пригодный ответ на вопрос о вашей собственной системе есть у одного человека, и каждое решение, которое от этого ответа зависит, оценивает он.
О чём эта статья
Не о недоверии и не о том, чтобы кого-то заменить. О том, как превратить смутное ощущение зависимости в то, что можно перечислить, измерить и сократить, и при этом сохранить отношения ровно такими же хорошими, как сейчас.
#Дело не в человеке
О зависимости обычно говорят как о недостатке характера: агентство, которое всё держит в тумане, разработчик, который ничего не записывает. Иногда так и есть. Гораздо чаще зависимость создают вполне разумные люди, которые хорошо делают свою работу. Сделать работу хорошо и оставить после неё объяснение означает решить две разные задачи, а просят всегда только первую.
Хороший разработчик, который три года работает над системой, держит огромную её часть в голове. Именно поэтому с ним хорошо работать. Поэтому же его отпуск становится риском, его цену не с чем сравнить, а его уход обойдётся в месяцы. Качество человека и размер зависимости растут вместе.
Поэтому полезный вопрос не в том, доверяете ли вы ему. Полезный вопрос в том, где физически находятся знание, доступы и суждение о вашей системе и сколько из этих мест оказываются одним человеком.
#Три списка
Зависимость ощущается как одна вещь, а ведёт себя как три. У них разные причины, разная цена и разный порядок, в котором их можно разобрать. Поэтому попытка решать их как одну проблему обычно заканчивается тем, что не сделано ничего ни с одной.
Каждый из трёх списков сокращается по-своему. Пунктирный блок к зависимости вообще не относится, и его нужно назвать отдельно, иначе его примут за то, что один человек скрывает.
-
Знание: вопросы, на которые отвечает только один человек
Куда попадают персональные данные. Что работает по расписанию. Что сломается, если пропадёт конкретный внешний сервис. Каких частей системы касается оплата. У каждого такого вопроса где-то есть ответ, и в список попадают те, где это «где-то» оказывается одной головой.
Именно этот список стоит за оценкой, которую нечем оспорить.
-
Доступ: учётные записи, которые есть только у одного человека
Регистратор домена, DNS, облачный аккаунт, хостинг кода, страницы в магазинах приложений, платёжный провайдер, сервис, который отправляет ваши письма. В список попадает то, что зарегистрировано на личный адрес, оплачивается личной картой или защищено телефоном, который вам не принадлежит.
Этот список самый опасный и дешевле всего исправляется.
-
Суждение: изменения, которые может оценить только один человек
Разумна ли оценка. Безопасно ли предложенное изменение. Серьёзен ли инцидент. В список попадают решения, по которым сегодня есть только одно мнение, и это мнение того, кто будет делать работу.
Этот список никогда не станет пустым, и это не нужно.
#Мерить часами, а не ощущениями
Спросите владельца, насколько он зависим, и получите ощущение: очень, отчасти, не особенно. Ощущения не двигаются, поэтому не скажут, помогло ли что-то из сделанного. Число скажет, и самым простым числом служит время, за которое находится ответ, когда привычного человека нет на месте.
Запишите десять вопросов о системе, которые понадобятся для решения в следующем квартале. По каждому отметьте, кто может ответить, сколько это занимает без него и где ответ записан. Таблица ниже показывает форму, заполненную вымышленными значениями.
| Вопрос | Кто может ответить | Без него | Где записано |
|---|---|---|---|
| Через какие сервисы проходят персональные данные клиентов? | Ведущий разработчик | Неизвестно, вероятно дни | Нигде |
| Что работает по расписанию и кто заметит, если оно остановится? | Агентство | Утро чтения конфигурации | Частично, на старой странице вики |
| Кто может продлить домен и сертификаты? | Бывший подрядчик | Невозможно | Личный почтовый ящик |
| Чего касается платёжная интеграция? | Ведущий разработчик | Недели для нового человека | Нигде |
Два столбца важнее остальных. «Без него» показывает вашу уязвимость, то есть время, на которое решение встаёт из-за отпуска, болезни или ссоры. «Где записано» показывает ваш прогресс. Каждый раз, когда ячейка в нём меняется с «нигде» на место, которое можно проверить, зависимость становится короче ровно на один вопрос, и это видно.
Владелец заполняет десять вопросов о продукте, который сделало небольшое агентство. На семь отвечает один и тот же человек. У четырёх нет записанного ответа вовсе. На один, о продлении домена, не может ответить никто из тех, кто сейчас работает над продуктом. Реестр не показал плохое агентство. Он показал, что одна дата продления может положить весь продукт и что исправить это можно за один день.
#Сначала доступы, потому что это дешевле всего
Из трёх списков начинать стоит с доступов, и причин две. За ними стоят худшие последствия, потому что аккаунт, в который вы не можете попасть, может остановить продукт целиком, и пути назад может не быть. И исправить их дешевле всего, потому что ничего не нужно объяснять или изучать, достаточно передать.
Правило формулируется просто. Каждый аккаунт, от которого зависит продукт, принадлежит компании, зарегистрирован на адрес компании, оплачивается картой компании и защищён способами восстановления, которые контролирует компания. Люди состоят в этих аккаунтах с теми правами, которые нужны для их работы. Никогда наоборот.
- Составьте список. Домен, DNS, сертификаты, облако, хостинг кода, сервис сборки и выкладки, магазины приложений, платёжный провайдер, отправка писем, аналитика, отслеживание ошибок. Для каждого запишите официального владельца и способ восстановления.
- Передайте владение, людей оставьте. Сделайте владельцем компанию и пригласите разработчика обратно участником. Его работа не меняется. Меняется то, кто сможет войти на следующий день после его ухода.
- Отделите секреты от аккаунтов. Ключи и пароли, которыми пользуется система, хранятся там, где их контролирует компания, а не на одном ноутбуке. Знать, где они лежат, и пользоваться ими далеко не одно и то же, и владельцу нужно только первое.
Обычно это один или два дня работы разработчика, и он делает её охотно, если правильно объяснить зачем. Руководство о том, кому должна принадлежать рабочая инфраструктура, проходит этот список по одному аккаунту.
#Потом вынести ответы из голов
Знание обходится дороже всего и в хранении, и в сокращении. Традиционный ответ состоит в том, чтобы попросить документацию, и он не работает предсказуемым образом. Её написание оказывается большой задачей, за которую никто не платит, она устаревает раньше, чем её закончат, а владелец не может понять, какие её части верны.
Лучше работает другой подход. Менять нужно не того, кто пишет ответ, а то, откуда ответ берётся. Описание системы, построенное из самой системы, где у каждого утверждения указано, что его подтверждает, а каждый пробел назван пробелом, можно получить без человека, который садится писать, обновить, когда система меняется, и проверить кем-то, кроме автора.
Это меняет и роль того, от кого вы зависите, причём так, что большинство разработчиков этому радуется. Он перестаёт быть единственным источником ответов и становится проверяющим записи. Вместо того чтобы каждый месяц отвлекаться на одни и те же вопросы, он подтверждает или исправляет картину, и его исправления в ней остаются.
Где здесь 1ADK
Именно для этого списка 1ADK и существует. Человек с доступом к коду запускает анализ на своей машине с тем ИИ-агентом для программирования, которым уже пользуется. Результатом становится картина, где у каждого утверждения есть доказательство, а неизвестное оставлено на виду. 1ADK не требует доступа к репозиторию и не требует загружать нам исходный код. Списки доступов и суждений вы разбираете сами, с ним или без него.
#Суждение в последнюю очередь
Суждение образует список, который никогда не пустеет, и это нормально. Вы всегда будете полагаться на кого-то знающего, кто скажет, безопасно ли изменение и честна ли оценка. Проблема не в том, что вы полагаетесь. Проблема в том, что вы полагаетесь на того единственного человека, на чьи интересы ответ влияет, и вам не с чем его сверить.
Сократить этот список, не превращая каждое решение в аудит, помогают две вещи.
- Общая картина того, чего касается изменение. Когда обе стороны видят, какие компоненты, интеграции и хранилища данных затрагивает изменение, оценку можно обсуждать, а не просто принимать. Код вы по-прежнему не оцениваете. Но вы можете спросить, почему изменение оплаты задевает сервис отчётов, и получить ответ.
- Второе мнение по немногим важным решениям. Не по каждой задаче, а по необратимым: перенос данных, смена провайдера, переписывание. Второе мнение по карману, когда второму человеку не нужно восстанавливать картину с нуля. Поэтому этот шаг идёт после списка знаний, а не до него.
#Как поднять тему без конфликта
Владельцы часто откладывают эту работу, потому что ждут, что она прозвучит как обвинение. Так быть не должно, и подача решает почти всё.
-
Говорите о непрерывности, а не о контроле
Продукт должен переживать отсутствие любого человека, включая вас. Владельцу разумно этого хотеть, и такая формулировка делает разговор разговором о продукте, а не о человеке.
Скажите прямо: это страховка, и она защищает вас так же, как меня.
-
Попросите помочь составить списки
Тот, от кого вы зависите, лучше всех знает, на какие вопросы отвечает только он. Попросить его назвать эти вопросы значит отнестись к нему как к эксперту, которым он и является, и реестр будет написан за час, а не за неделю.
У большинства разработчиков есть свой список того, что они устали знать в одиночку.
-
Оплатите эту работу
Перенос аккаунтов и проверка картины системы требуют настоящей работы. Поставьте её в план с оценкой, как любую другую задачу, чтобы она не делалась вечерами через силу.
Неоплаченную работу на непрерывность бросают первой, как только появляется срок.
-
Измеряйте вместе
Через месяц посмотрите на реестр снова. Число вопросов с записанным ответом и время на каждый без привычного человека должны были сдвинуться. Если сдвинулись, скажите об этом.
Прогресс, который видят обе стороны, не даёт этому стать разовой уборкой.
#Запишите три списка на этой неделе
Доступы
Всё, чем владеет человек, а не компания, идёт в начало плана.
- Кто официальный владелец домена и куда приходит уведомление о продлении? Просроченный домен отключает всё сразу, а восстановление может занять недели.
- Чьей картой оплачивается облачный аккаунт и кто может сбросить его пароль? Аккаунт, на котором работает продукт, никогда не должен быть личным.
- Кто сможет выдать доступ к хостингу кода, если нынешний администратор пропадёт? Потеря доступа не удалит код, но может остановить каждую выкладку.
Знание
Каждый вопрос без записанного ответа становится строкой реестра.
- Запишите десять вопросов, которые понадобятся для решения в следующем квартале, и кто отвечает на каждый. Список вопросов полезнее любого ответа, потому что показывает, где ответов не хватает.
- Отметьте те, ответ на которые записан там, где его можно проверить. Это число и есть точка отсчёта, и обычно оно ниже ожидаемого.
Суждение
Только решения, которые нельзя отменить.
- Назовите ближайшее необратимое техническое решение в плане. Именно там второе мнение окупается.
- Скажите, может ли сегодня его оценить кто-то, кроме того, кто будет делать работу. Если нет, начинать нужно со списка знаний.
#Что делают вместо этого
Потребовать полную документацию системы.
Вместо этого Полная документация никогда не бывает закончена и проверена. Попросите, чтобы у десяти вопросов из реестра появились записанные ответы, которые можно проверить, и растите список от них.
Нанять второго разработчика, чтобы он узнал всё, что знает первый.
Вместо этого Это удваивает расходы и создаёт вторую зависимость, только медленнее. Сначала сократите список знаний, чтобы следующий человек начинал с записи, а не с человека.
Собрать все пароли за один напряжённый вечер.
Вместо этого Список паролей не делает вас владельцем, а аккаунты остаются зарегистрированы на того же человека. Спокойно переведите официальное владение каждым аккаунтом и оставьте людей участниками.
Сменить агентство, чтобы уйти от зависимости.
Вместо этого Новое агентство унаследует то же устройство и начнёт с того, что возьмёт деньги за изучение того, что знало старое. Меняйте подрядчика по другим причинам и только после того, как три списка станут короткими.
Считать неизвестное тем, что разработчик скрывает.
Вместо этого Некоторых вещей не знает никто, включая того, кто строил систему. Назовите их в записи неизвестными. Обвинение в утаивании того, чего у человека никогда не было, заканчивает сотрудничество, которое вам нужно.
#Чего это не исправит
Короткие три списка делают зависимость выбором, а не ловушкой. Прямо о том, чего это не даёт.
Чего это не делает
- Это не убирает потребность в квалифицированных людях. Вы по-прежнему будете зависеть от того, кто строит и меняет систему, и это здорово, когда это выбор.
- Это не говорит, хорошо ли человек работает. Запись о системе говорит, что существует и что с чем связано, а не насколько хорошо это сделано.
- Это не сохраняет решения, которых никогда не было в системе. Почему назначили цену или отказались от функции, знают те, кто решал, и записать это должны они.
- Это не делает оценку правильной. Это делает её обсуждаемой, а это другое и меньшее.
- Это не заканчивается. Системы меняются, люди приходят и уходят, поэтому реестр ведут, а не завершают.
Цель не в независимости от людей. Цель в том, чтобы ни один человек не был единственным способом ответить на вопрос о вашем продукте, войти в аккаунт, на котором он работает, или оценить изменение, за которое вы собираетесь заплатить.
Если человек, от которого вы зависите больше всего, станет недоступен на месяц начиная с завтрашнего дня, какой из трёх списков остановит бизнес первым?