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