Forwarded from Андрей Корниенко. Про (аналитить) это
Как называть очереди в брокерах
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
Слава пришла откуда не ждали. Вчера во внутренней группе для аналитиков коллега поделился артефактом СА с таким комментарием:
Зашёл я в Инстаграм значит, а там в рилсах вот такой шаблон девушка раздает. Некоторые примеры наивные, но в целом как чек-лист о чем нужно/можно подумать аналитику наверное неплохо
Из любопытства я порылся в приложенном документе (закину в комментарии к посту) и обнаружил в нём копию своего собственного документа, который я создал на одном из проектов в 2022 году.
Неповторимый, так сказать оригинал вот он: Правила именования топиков
Создавайте правила
Мало просто правильно назвать очередь или грамотно описать артефакт. Создавайте правила, описывайте стили, внедряйте принципы организации информации. Тогда больше шансов, что команда будет работать как команда, а не просто группа случайно собранных людей, каждый со своим неповторимым почерком.
#брокеры
👍19🔥9👏3
Про (не)простые типы данных или что в имени тебе моем?
Вы, наверное, заметили, что я очень люблю стандарты. Ещё я люблю изучать разные стандарты и подходы из разных предметных областей — это тренирует насмотренность и можно подглядеть решения типовых проблем и как с ними справляются. Например, почти у всех есть задачи назначения и контроля полномочий, управления пользователями, какие-то инфраструктурные вещи (синхронизация времени для ведения журналов, например, из PCI DSS).
Я в начале своего трудового пути писал софт для медицины — цифровая обработка ЭКГ, комплекс диагностики тканей в раневой зоне в процессе заживления, ранняя диагностика катаракты глаза — было интересно. Коллеги рядом писали учетный софт для больниц — первые электронные мед.карты, статистика для страховых — тоже любопытно. Это ещё в прошлом веке было.
В медицине есть такой стандарт — HL7, Health Level 7, он ещё в 80-х разрабатывался, до XML, в общем, старинная история. Ну и за это время много кейсов в себя вобрал. Я не знаю, насколько он в России сейчас распространен, но официальный перевод существует (ГОСТ Р ИСО/HL7 27931-2015) и некоторые системы точно его поддерживают.
И вот в этом HL7 есть поле для хранения имени пациента. Ну, что тут можно изобрести? ФИО в одну строку или ФИО в трех полях, какие ещё варианты, казалось бы? В HL7 под имя заведено 15 полей. Ну ладно, под расширенное имя. Поля там такие:
XPN.1 Семейное имя. Это сложный тип, у которого в свою очередь следующие поля:
FN.1 Фамилия
FN.2 Префикс собственной фамилии ("де", "фон")
FN.3 Собственная фамилия (девичья фамилия)
FN.4 Префикс фамилии партнера/супруга
FN.5 Фамилия партнера/супруга
Префикс тут выделяется не просто так, а по прагматичным соображениям: он не участвует в сортировке (иначе все "фоны" были бы на "ф").
XPN.2 Личное имя.
XPN.3 Последующие личные имена, отчество, инициалы (через пробел)
XPN.4 Суффикс ("мл." или "III")
XPN.5 Префикс ("д-р")
XPN.6 Ученая степень / сертификат (раньше тут был справочник степеней, типа "MD" или "PHD", по нашему будет "к.т.н."; с версии 2.5 не используется, см. XPN.14)
XPN.7 Код типа имени (ссылка на справочник типов имен, он достоин быть приведенным целиком:
"псевдоним",
"имя при рождении",
"имя при усыновлении",
"для отображения на экране",
"указанное в лицензии",
"юридически признаваемое",
"девичье",
"кличка, прозвище",
"зарегистрированная кличка (для животных)",
"кодированный псевдоним для анонимизации",
"племенное имя",
"религиозное",
"имя новорожденного до получения документов",
"более неиспользуемое, деднейм",
"временное",
"неправильное",
"неизвестное")
Тут видны разнообразные кейсы, с которыми медицина сталкивается.
XPN.8 Код представления имени (это для иероглифических языков: алфавитное, идеографическое, фонетическое)
XPN.9 Контекст использования имени (ссылка на пользовательский справочник; я не нашел примеров, говорят, это актуально для австралийских аборигенов, которые называют себя разными именами в разных больницах)
XPN.10 Период действия имени (с версии 2.5 не используется, заменен на XPN.12 и XPN.13)
XPN.11 Порядок сборки имени (ссылка на справочник со значениями типа "Prefix Family Middle Given Suffix")
XPN.12 Дата начала действия (да, это ещё и темпоральная таблица!)
XPN.13 Срок действия (последняя дата использования)
XPN.14 Профессиональный суффикс (просто строка, используется только для отображения)
XPN.15 Как обращаться (например, по всем документам человек Владимир, а предпочитает, чтобы его звали Дима. Или у священнослужителей — "отец Иоанн").
Я почему-то не вижу тут признака языка, он есть только в конкретном сообщении, хотя напрашивается несколько вариантов, но видимо как-то с этим справляются.
В общем, пока это самая замороченная система хранения личных имен, которая мне встречалась. Не уверен, что всё из этого я бы стал реализовывать в каждой системе, но вот с разными написаниями, девичьими фамилиями, множественными фамилиями и именами, деднеймами и сроком действия имен приходилось сталкиваться, каждый раз это какое-то мучение.
Вы, наверное, заметили, что я очень люблю стандарты. Ещё я люблю изучать разные стандарты и подходы из разных предметных областей — это тренирует насмотренность и можно подглядеть решения типовых проблем и как с ними справляются. Например, почти у всех есть задачи назначения и контроля полномочий, управления пользователями, какие-то инфраструктурные вещи (синхронизация времени для ведения журналов, например, из PCI DSS).
Я в начале своего трудового пути писал софт для медицины — цифровая обработка ЭКГ, комплекс диагностики тканей в раневой зоне в процессе заживления, ранняя диагностика катаракты глаза — было интересно. Коллеги рядом писали учетный софт для больниц — первые электронные мед.карты, статистика для страховых — тоже любопытно. Это ещё в прошлом веке было.
В медицине есть такой стандарт — HL7, Health Level 7, он ещё в 80-х разрабатывался, до XML, в общем, старинная история. Ну и за это время много кейсов в себя вобрал. Я не знаю, насколько он в России сейчас распространен, но официальный перевод существует (ГОСТ Р ИСО/HL7 27931-2015) и некоторые системы точно его поддерживают.
И вот в этом HL7 есть поле для хранения имени пациента. Ну, что тут можно изобрести? ФИО в одну строку или ФИО в трех полях, какие ещё варианты, казалось бы? В HL7 под имя заведено 15 полей. Ну ладно, под расширенное имя. Поля там такие:
XPN.1 Семейное имя. Это сложный тип, у которого в свою очередь следующие поля:
FN.1 Фамилия
FN.2 Префикс собственной фамилии ("де", "фон")
FN.3 Собственная фамилия (девичья фамилия)
FN.4 Префикс фамилии партнера/супруга
FN.5 Фамилия партнера/супруга
Префикс тут выделяется не просто так, а по прагматичным соображениям: он не участвует в сортировке (иначе все "фоны" были бы на "ф").
XPN.2 Личное имя.
XPN.3 Последующие личные имена, отчество, инициалы (через пробел)
XPN.4 Суффикс ("мл." или "III")
XPN.5 Префикс ("д-р")
XPN.6 Ученая степень / сертификат (раньше тут был справочник степеней, типа "MD" или "PHD", по нашему будет "к.т.н."; с версии 2.5 не используется, см. XPN.14)
XPN.7 Код типа имени (ссылка на справочник типов имен, он достоин быть приведенным целиком:
"псевдоним",
"имя при рождении",
"имя при усыновлении",
"для отображения на экране",
"указанное в лицензии",
"юридически признаваемое",
"девичье",
"кличка, прозвище",
"зарегистрированная кличка (для животных)",
"кодированный псевдоним для анонимизации",
"племенное имя",
"религиозное",
"имя новорожденного до получения документов",
"более неиспользуемое, деднейм",
"временное",
"неправильное",
"неизвестное")
Тут видны разнообразные кейсы, с которыми медицина сталкивается.
XPN.8 Код представления имени (это для иероглифических языков: алфавитное, идеографическое, фонетическое)
XPN.9 Контекст использования имени (ссылка на пользовательский справочник; я не нашел примеров, говорят, это актуально для австралийских аборигенов, которые называют себя разными именами в разных больницах)
XPN.10 Период действия имени (с версии 2.5 не используется, заменен на XPN.12 и XPN.13)
XPN.11 Порядок сборки имени (ссылка на справочник со значениями типа "Prefix Family Middle Given Suffix")
XPN.12 Дата начала действия (да, это ещё и темпоральная таблица!)
XPN.13 Срок действия (последняя дата использования)
XPN.14 Профессиональный суффикс (просто строка, используется только для отображения)
XPN.15 Как обращаться (например, по всем документам человек Владимир, а предпочитает, чтобы его звали Дима. Или у священнослужителей — "отец Иоанн").
Я почему-то не вижу тут признака языка, он есть только в конкретном сообщении, хотя напрашивается несколько вариантов, но видимо как-то с этим справляются.
В общем, пока это самая замороченная система хранения личных имен, которая мне встречалась. Не уверен, что всё из этого я бы стал реализовывать в каждой системе, но вот с разными написаниями, девичьими фамилиями, множественными фамилиями и именами, деднеймами и сроком действия имен приходилось сталкиваться, каждый раз это какое-то мучение.
🔥31👍11❤3
Если судить по текстам вакансий и публикаций, самая распространенная форма фиксации пользовательских требований сейчас — Jobs To Be Done (в западных компаниях). Другие варианты гораздо реже встречаются.
Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").
Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:
Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>
Работа — это какое-то действие, что-то, что должно быть сделано, и пользователь мог бы сам это как-то сделать, но он "нанимает" ваш продукт или функцию в нём, чтобы продукт это сделал за него. В этом смысле формулировка работы выше, чем описание интерфейсов системы, правило проверки: системы нет, а работа не теряет смысла. (Это же правило работает для проверки формулировок названий юскейсов, кстати.)
Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.
Это добавления формулируются так:
Что даст мне чувство <описание эмоционального состояния пользователя после успешно выполненной работы>
И другие увидят, что я <описание отношения значимых окружающих к пользователю после решения задачи>
Никогда не видел, чтобы эти части появлялись в технических спецификациях.
А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.
Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).
Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.
Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.
Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").
Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:
Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>
Работа — это какое-то действие, что-то, что должно быть сделано, и пользователь мог бы сам это как-то сделать, но он "нанимает" ваш продукт или функцию в нём, чтобы продукт это сделал за него. В этом смысле формулировка работы выше, чем описание интерфейсов системы, правило проверки: системы нет, а работа не теряет смысла. (Это же правило работает для проверки формулировок названий юскейсов, кстати.)
Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.
Это добавления формулируются так:
Что даст мне чувство <описание эмоционального состояния пользователя после успешно выполненной работы>
И другие увидят, что я <описание отношения значимых окружающих к пользователю после решения задачи>
Никогда не видел, чтобы эти части появлялись в технических спецификациях.
А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.
Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).
Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.
Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.
27👍32🔥14👌2❤1🤝1
Как работают вызовы API внутри сервера.
Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.
Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..
Тут, кажется, стоит вернуться к основам, попробовал нарисовать.
Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.
Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.
Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.
Дальше он пытается выполнить запрос. Есть три основных варианта:
— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.
— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.
— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.
Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.
Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.
Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.
Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.
Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..
Тут, кажется, стоит вернуться к основам, попробовал нарисовать.
Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.
Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.
Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.
Дальше он пытается выполнить запрос. Есть три основных варианта:
— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.
— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.
— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.
Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.
Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.
Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.
👍27🔥18❤5
Я везде стараюсь подмечать идеи, которые могут помочь в работе. Попадаются они в самых разных местах. Например — в Третьяковской галерее, на выставке "Передвижники". К этой выставке выпущен альбом на Ясном языке. Пример текста на слайде.
Я вообще очень внимательно отношусь к текстам и языку. Возможно, вы слышали моё выступление про тексты (преза, статья).
А про проверку сложности языка я писал вот тут.
Ясный язык — это адаптированный национальный язык для людей с ментальными особенностями или другими трудностями восприятия информации. Он подходит для иностранцев, пожилых, или наоборот юных. И знаете, что? Он, кажется, отлично подходит для технических документов и требований.
Не потому, что разработчики и заказчики имеют ментальную инвалидность (хотя иногда закрадываются сомнения). А для снижения когнитивной нагрузки. Разработчики держат в голове структуру из 7-10 последовательно состыкованных модулей/классов и 3-7 уровней абстракции (а то и 10-15). Им есть, о чем подумать. У заказчиков из бизнеса тоже, я вас уверяю. И лишний раз забивать им головы и заставлять продираться через сложные тексты — просто непродуктивно.
Поэтому тексты нужно делать максимально простыми и четкими — без неоднозначностей и запутанных фраз. Ясными.
Ясным языком занимаются банки, операторы сотовой связи и — в некоторых странах — государство (не в РФ). Есть инструкция от Сбера и предварительный стандарт от фонда «Наш Солнечный Мир».
Принципы Ясного языка (про предстандарту):
* использовать ограниченный набор слов естественного языка. Для русского есть списки первых 100 и первых 1000 самых частотных слов, они покрывают 60% всех текстов.
* не заменять существительные на местоимения (он, она, этот, который)
* не использовать синонимы (одно понятие — одно название)
* избегать многозначных слов, или использовать их всегда в одном и том же смысле ("сервер" — компьютер и "сервер" — программа на компьютере)
* использовать слова только в прямом значении (плохо: "поле ввода подсвечивается", "отчет должен отражать информацию")
* избегайте специальных терминов, либо выносите их в словарь
* избегайте жаргона
* используйте одни и те же слова и конструкции, не боясь повторов и тавтологий
* не используйте отрицания
* подавайте информацию порционно: одно предложение — одна фраза
* стройте предложение от известного к новому
* используйте простые предложения
* избегайте причастных и деепричастных оборотов. Разбивайте предложения на несколько.
Практически те же рекомендации содержатся и в руководствах по написанию требований!
Но предстандарт написан лингвистами, поэтому там есть инструкции именно по языку. В частности, приемы упрощения информации:
- Исключение лишних слов и информации без ущерба для содержания.
- Замена сложной информации при помощи более понятных для целевой аудитории идей.
- Включение дополнительных объяснений сложных терминов, использование уточняющих примеров и пояснений;
В результате получается что-то в таком духе (перевод юридического документа на Ясный язык):
Я вообще очень внимательно отношусь к текстам и языку. Возможно, вы слышали моё выступление про тексты (преза, статья).
А про проверку сложности языка я писал вот тут.
Ясный язык — это адаптированный национальный язык для людей с ментальными особенностями или другими трудностями восприятия информации. Он подходит для иностранцев, пожилых, или наоборот юных. И знаете, что? Он, кажется, отлично подходит для технических документов и требований.
Не потому, что разработчики и заказчики имеют ментальную инвалидность (хотя иногда закрадываются сомнения). А для снижения когнитивной нагрузки. Разработчики держат в голове структуру из 7-10 последовательно состыкованных модулей/классов и 3-7 уровней абстракции (а то и 10-15). Им есть, о чем подумать. У заказчиков из бизнеса тоже, я вас уверяю. И лишний раз забивать им головы и заставлять продираться через сложные тексты — просто непродуктивно.
Поэтому тексты нужно делать максимально простыми и четкими — без неоднозначностей и запутанных фраз. Ясными.
Ясным языком занимаются банки, операторы сотовой связи и — в некоторых странах — государство (не в РФ). Есть инструкция от Сбера и предварительный стандарт от фонда «Наш Солнечный Мир».
Принципы Ясного языка (про предстандарту):
* использовать ограниченный набор слов естественного языка. Для русского есть списки первых 100 и первых 1000 самых частотных слов, они покрывают 60% всех текстов.
* не заменять существительные на местоимения (он, она, этот, который)
* не использовать синонимы (одно понятие — одно название)
* избегать многозначных слов, или использовать их всегда в одном и том же смысле ("сервер" — компьютер и "сервер" — программа на компьютере)
* использовать слова только в прямом значении (плохо: "поле ввода подсвечивается", "отчет должен отражать информацию")
* избегайте специальных терминов, либо выносите их в словарь
* избегайте жаргона
* используйте одни и те же слова и конструкции, не боясь повторов и тавтологий
* не используйте отрицания
* подавайте информацию порционно: одно предложение — одна фраза
* стройте предложение от известного к новому
* используйте простые предложения
* избегайте причастных и деепричастных оборотов. Разбивайте предложения на несколько.
Практически те же рекомендации содержатся и в руководствах по написанию требований!
Но предстандарт написан лингвистами, поэтому там есть инструкции именно по языку. В частности, приемы упрощения информации:
- Исключение лишних слов и информации без ущерба для содержания.
- Замена сложной информации при помощи более понятных для целевой аудитории идей.
- Включение дополнительных объяснений сложных терминов, использование уточняющих примеров и пояснений;
В результате получается что-то в таком духе (перевод юридического документа на Ясный язык):
Статья 26. Банковская тайна
Кредитная организация, Банк России, организация, осуществляющая функции по обязательному страхованию вкладов, гарантируют тайну об операциях, о счетах и вкладах своих клиентов и корреспондентов. Все служащие кредитной организации обязаны хранить тайну об операциях, о счетах и вкладах ее клиентов и корреспондентов, а также об иных сведениях, устанавливаемых кредитной организацией, если это не противоречит федеральному закону.
На Ясном языке:
Что такое банковская тайна?
Вы подписываете разные документы в банке.
В этих документах есть Ваша личная информация.
Личная информация – это:
- Ваше имя,
- Ваш адрес,
- номер Вашего телефона,
- номер Вашего паспорта,
- номер Вашего счета в банке,
- другая информация о Вас.
Банк должен хранить эту информацию о Вас.
Сотрудники банка могут читать эту информацию о Вас.
Банк не должен показывать эту информацию о Вас другим людям.
Банк может показать информацию о Вас полиции.
Банк может показать информацию о Вас налоговой службе.
Чтобы посмотреть информацию о Вас, полиция должна иметь разрешение.
🔥74👍25❤11💯2
Вы, наверное, уже читали внутреннюю памятку для сотрудников Shopify про ИИ, которая сначала утекла в сеть, а потом уже и CEO Тоби Лютке у себя в X опубликовал.
Там 6 пунктов:
1. Использование ИИ теперь — фундаментальное ожидание от каждого сотрудника Shopify.
2. ИИ обязательно использовать на стадии прототипирования GSD. Get Shit Done — это у них такая методология и инструмент ведения проектов.
3. Вопросы про использование ИИ включаются в оценку перформанса и взаимного оценивания. В том числе — кто кому помогал осваивать ИИ.
4. Поддерживается максимальный обмен практиками использования ИИ: у кого что получилось, у кого что не получилось. В цикле разработки продуктов выделяется время на эксперименты с ИИ. Результаты команд озвучиваются на ежемесячных общих встречах.
5. Прежде чем запрашивать новые ресурсы или людей, команды обязаны показать, почему они не могут сделать это при помощи ИИ. Как бы эта зона ответственности выглядела, если бы автономный ИИ-агент уже был членом команды?
6. Это относится к каждому сотруднику, включая CEO и высшее руководство.
Любопытно, что пока нет похожих утечек из других компаний, а ведь наверное многие такое вводят (хотя, может быть, не на таком всеобъемлющем уровне).
А ещё — хороший пример управленческого воздействия. Всего-то 6 пунктов, а принципы заданы основополагающие. Я похожие принципы пытался внедрить в одном фонде, когда был CTO — но не для ИИ, а для прототипирования продуктов своими силами, без привлечения разработчиков и сбора данных — основатель фонда очень хотел цифровую трансформацию. Но я тогда не дожал, а вот это выглядит как решение (но исходить должно не от CTO, конечно, а от CEO). Предполагаю, кстати, что скоро появится хайп на тему "ИИ-трансформации", какую-нибудь должность "Директор по ИИ" придумают и множество программ на эту тему от бизнес-школ.
А как у вас? Собираетесь вводить в штатное расписание ИИ-агентов?
Там 6 пунктов:
1. Использование ИИ теперь — фундаментальное ожидание от каждого сотрудника Shopify.
2. ИИ обязательно использовать на стадии прототипирования GSD. Get Shit Done — это у них такая методология и инструмент ведения проектов.
3. Вопросы про использование ИИ включаются в оценку перформанса и взаимного оценивания. В том числе — кто кому помогал осваивать ИИ.
4. Поддерживается максимальный обмен практиками использования ИИ: у кого что получилось, у кого что не получилось. В цикле разработки продуктов выделяется время на эксперименты с ИИ. Результаты команд озвучиваются на ежемесячных общих встречах.
5. Прежде чем запрашивать новые ресурсы или людей, команды обязаны показать, почему они не могут сделать это при помощи ИИ. Как бы эта зона ответственности выглядела, если бы автономный ИИ-агент уже был членом команды?
6. Это относится к каждому сотруднику, включая CEO и высшее руководство.
Любопытно, что пока нет похожих утечек из других компаний, а ведь наверное многие такое вводят (хотя, может быть, не на таком всеобъемлющем уровне).
А ещё — хороший пример управленческого воздействия. Всего-то 6 пунктов, а принципы заданы основополагающие. Я похожие принципы пытался внедрить в одном фонде, когда был CTO — но не для ИИ, а для прототипирования продуктов своими силами, без привлечения разработчиков и сбора данных — основатель фонда очень хотел цифровую трансформацию. Но я тогда не дожал, а вот это выглядит как решение (но исходить должно не от CTO, конечно, а от CEO). Предполагаю, кстати, что скоро появится хайп на тему "ИИ-трансформации", какую-нибудь должность "Директор по ИИ" придумают и множество программ на эту тему от бизнес-школ.
А как у вас? Собираетесь вводить в штатное расписание ИИ-агентов?
👍22🔥14❤6😁6
Увидел сегодня табличку для проектирования управленческих решений и их мониторинга. От управленцев, которые, в общем, довольно далеки от ИТ. Но пропагандируют решения на основе данных.
И они, конечно, не знают таких методик, как Impact mapping, или её развития — Карты гипотез от Александра Бындю, или Business Decision Records, или какого-нибудь Business Model Canvas/Value Proposition Canvas, или например Digital Policy Model Canvas, если речь идёт о госполитике в некоммерческих областях типа культуры или образования.
Зато они изобрели свой вариант. Это не канва, это просто таблица. Но, мне кажется, она может быть очень полезна для бизнес-аналитиков (в меньшей степени для системных), поэтому приведу её здесь. Вот смотрите, из чего она состоит:
1. Проблема (формулируется как конфликт: с одной стороны это, но с другой стороны вот то, и одно другому противоречит)
2. Данные, подтверждающие наличие проблемы: количественные (мы что-то измерили, это статистически значимо и репрезентативно) и качественные (конкретные вопиющие кейсы)
3. Причины или гипотезы об источниках проблемы
4. Данные, нужные для подтверждения или опровержения гипотез о причинах.
5. Источники данных (для каждой причины)
Это аналитическая часть. Теперь решенческая:
6. Меры по преодолению/устранению причин.
7. Риски
9. Ресурсы для осуществления мер:
— имеющиеся
— необходимые
10. Показатели для оценки:
— процесса (это про меры — что реально делается?)
— результатов (это про проблему — происходят ли улучшение?)
— эффективности (это про соотношение результатов и ресурсов — сколько нам стоит улучшение на N пунктов?)
— эффектов (что ещё улучшается/изменяется в результате? Улучшается ли общая картина, что-то, что выше проблемы? Не выходят ли из под контроля риски? Эффекты могут быть отложенными по времени)
Вот такие две простые таблицы, но, кажется, очень полезные на ранних этапах, для оценки инициатив. Есть ли реально проблема? Откуда знаем? Как будем решать? Как узнаем, что решили?
Дальше добавляем время: сроки реализации мер и периодичность измерений — и получаем готовый план!
А также эта таблица связывает разные уровни показателей компании: интервенцию делаем и результаты отслеживаем на уровне процессов, а эффект получаем на уровне удовлетворенности клиентов.
И они, конечно, не знают таких методик, как Impact mapping, или её развития — Карты гипотез от Александра Бындю, или Business Decision Records, или какого-нибудь Business Model Canvas/Value Proposition Canvas, или например Digital Policy Model Canvas, если речь идёт о госполитике в некоммерческих областях типа культуры или образования.
Зато они изобрели свой вариант. Это не канва, это просто таблица. Но, мне кажется, она может быть очень полезна для бизнес-аналитиков (в меньшей степени для системных), поэтому приведу её здесь. Вот смотрите, из чего она состоит:
1. Проблема (формулируется как конфликт: с одной стороны это, но с другой стороны вот то, и одно другому противоречит)
2. Данные, подтверждающие наличие проблемы: количественные (мы что-то измерили, это статистически значимо и репрезентативно) и качественные (конкретные вопиющие кейсы)
3. Причины или гипотезы об источниках проблемы
4. Данные, нужные для подтверждения или опровержения гипотез о причинах.
5. Источники данных (для каждой причины)
Это аналитическая часть. Теперь решенческая:
6. Меры по преодолению/устранению причин.
7. Риски
9. Ресурсы для осуществления мер:
— имеющиеся
— необходимые
10. Показатели для оценки:
— процесса (это про меры — что реально делается?)
— результатов (это про проблему — происходят ли улучшение?)
— эффективности (это про соотношение результатов и ресурсов — сколько нам стоит улучшение на N пунктов?)
— эффектов (что ещё улучшается/изменяется в результате? Улучшается ли общая картина, что-то, что выше проблемы? Не выходят ли из под контроля риски? Эффекты могут быть отложенными по времени)
Вот такие две простые таблицы, но, кажется, очень полезные на ранних этапах, для оценки инициатив. Есть ли реально проблема? Откуда знаем? Как будем решать? Как узнаем, что решили?
Дальше добавляем время: сроки реализации мер и периодичность измерений — и получаем готовый план!
А также эта таблица связывает разные уровни показателей компании: интервенцию делаем и результаты отслеживаем на уровне процессов, а эффект получаем на уровне удовлетворенности клиентов.
❤11👍10
Канал уверенно преодолел отметку 9k подписчиков, и это очень круто!
Кто-нибудь другой на моем месте уже создал бы курс по раскрутке телеграм-канала без бюджета (я дважды заплатил за премиум-аккаунт, это пока всё, что я потратил на развитие канала. Ну ещё ЭДО для обмена документами с рекламодателями).
Но я, к сожалению, хорошо разбираюсь только в системном и бизнес-анализе. Нет, ну видимо в контент-маркетинге я тоже что-то понимаю, но тут у меня есть несколько принципов:
— Рассказывать о чем-то новом, про что мало кто говорит. Серьёзно, я вас сильно уважаю, дорогие подписчики, чтобы тупо постить что-нибудь вроде "Основные методы HTTP и какие из них идемпотентны". А если я вдруг про это и напишу, то с какого-нибудь редкого угла рассмотрения — например, должен ли идемпотентный метод всегда возвращать один и тот же результат при одинаковых значениях параметров. Хотя и это слишком просто. Вот связь идемпотентности с функциональным программированием, абстрактными алгебрами и геометрическими проекциями — это уже интересно!
— Давать не просто интересную информацию, но и полезную, применимую сразу.
— Рассказывать максимально просто (но не проще!)
— Уважать своих читателей — поэтому я никогда не употребляю мата и тщательно фильтрую рекламу, которую размещаю.
Но что мы всё обо мне. У меня же есть традиция (хорошо, когда есть традиции!) — на круглых числах рассказывать о своих подписчиках и их каналах. Вот в прошлый раз у нас были такие каналы:
Аналитик маминой подруги — канал Валентина Заботина. Что беспокоит всех — зарплаты, собеседования, прохождение испытательного срока, инструменты, ну и просто реальная жизнь системного аналитика.
Быть продактом (быть, а не казаться!) — от Антона Куликова, действующего CPO — про научный подход, рациональность и продуктивные конфликты. И про работу CPO, конечно.
V{IT}A ZAEBYMBA | Путь корпората (извините, из названия слова не выкинешь) — канал офигенно развивается, Вита, как ты это делаешь, поделись инсайтами! Вовлеченность подписчиков нереальная. Очень авторский контент про системный анализ и про жизнь ИТшника в большой компании.
IT АНАЛитика (ещё раз извините) Виктора Вильда — много разборов важных для аналитика понятий на простом языке.
https://news.1rj.ru/str/systemny_analiz_prosto — к сожалению, на паузе. Был разбор задачек с собеседований.
https://news.1rj.ru/str/itsysdes_events — Cобытия для аналитиков и проектировщиков ИТ-систем, новости, статьи.
https://news.1rj.ru/str/sysanaly — мемы и наблюдения за жизнью системного аналитика. С интересом прочел отзыв на тренинг, который я вел, а автор канала посетил :)
Eye of the Tigress \🐯/ Системный анализ — живой авторский канал, вдумчивые посты.
Продукт и рост | Яна Доценко — канал от настоящего продакта с настоящими классными приемами и как продакту работать и искать работу в Европе.
https://news.1rj.ru/str/mialinist — Заметки об управлении школой @systems_education и исследовательские статьи о финансах, бизнесе и анализе. Самый внутренний внутрячок про школу системного анализа!
Анка Аналитик — длинные посты про системный и бизнес-анализ. Автономный транспорт! Биотех! Крутые предметные области.
Самореализация и публичность IT-специалистов — канал Smart Effect Натальи Семеновой — про подготовку к выступлениям на конференциях.
Финансовый сыч — для разнообразия, канал не про системный анализ, а про финансовый. Автор делится своим личным опытом и ценными советами по управлению финансами и личными инвестициями.
Вот такие у нас классные каналы! Все, как на подбор. Почти готовая папка получилась.
Ну а в комментариях к этому посту можете писать о своих каналах! Даешь переопыление подписчиками!
Кто-нибудь другой на моем месте уже создал бы курс по раскрутке телеграм-канала без бюджета (я дважды заплатил за премиум-аккаунт, это пока всё, что я потратил на развитие канала. Ну ещё ЭДО для обмена документами с рекламодателями).
Но я, к сожалению, хорошо разбираюсь только в системном и бизнес-анализе. Нет, ну видимо в контент-маркетинге я тоже что-то понимаю, но тут у меня есть несколько принципов:
— Рассказывать о чем-то новом, про что мало кто говорит. Серьёзно, я вас сильно уважаю, дорогие подписчики, чтобы тупо постить что-нибудь вроде "Основные методы HTTP и какие из них идемпотентны". А если я вдруг про это и напишу, то с какого-нибудь редкого угла рассмотрения — например, должен ли идемпотентный метод всегда возвращать один и тот же результат при одинаковых значениях параметров. Хотя и это слишком просто. Вот связь идемпотентности с функциональным программированием, абстрактными алгебрами и геометрическими проекциями — это уже интересно!
— Давать не просто интересную информацию, но и полезную, применимую сразу.
— Рассказывать максимально просто (но не проще!)
— Уважать своих читателей — поэтому я никогда не употребляю мата и тщательно фильтрую рекламу, которую размещаю.
Но что мы всё обо мне. У меня же есть традиция (хорошо, когда есть традиции!) — на круглых числах рассказывать о своих подписчиках и их каналах. Вот в прошлый раз у нас были такие каналы:
Аналитик маминой подруги — канал Валентина Заботина. Что беспокоит всех — зарплаты, собеседования, прохождение испытательного срока, инструменты, ну и просто реальная жизнь системного аналитика.
Быть продактом (быть, а не казаться!) — от Антона Куликова, действующего CPO — про научный подход, рациональность и продуктивные конфликты. И про работу CPO, конечно.
V{IT}A ZAEBYMBA | Путь корпората (извините, из названия слова не выкинешь) — канал офигенно развивается, Вита, как ты это делаешь, поделись инсайтами! Вовлеченность подписчиков нереальная. Очень авторский контент про системный анализ и про жизнь ИТшника в большой компании.
IT АНАЛитика (ещё раз извините) Виктора Вильда — много разборов важных для аналитика понятий на простом языке.
https://news.1rj.ru/str/systemny_analiz_prosto — к сожалению, на паузе. Был разбор задачек с собеседований.
https://news.1rj.ru/str/itsysdes_events — Cобытия для аналитиков и проектировщиков ИТ-систем, новости, статьи.
https://news.1rj.ru/str/sysanaly — мемы и наблюдения за жизнью системного аналитика. С интересом прочел отзыв на тренинг, который я вел, а автор канала посетил :)
Eye of the Tigress \🐯/ Системный анализ — живой авторский канал, вдумчивые посты.
Продукт и рост | Яна Доценко — канал от настоящего продакта с настоящими классными приемами и как продакту работать и искать работу в Европе.
https://news.1rj.ru/str/mialinist — Заметки об управлении школой @systems_education и исследовательские статьи о финансах, бизнесе и анализе. Самый внутренний внутрячок про школу системного анализа!
Анка Аналитик — длинные посты про системный и бизнес-анализ. Автономный транспорт! Биотех! Крутые предметные области.
Самореализация и публичность IT-специалистов — канал Smart Effect Натальи Семеновой — про подготовку к выступлениям на конференциях.
Финансовый сыч — для разнообразия, канал не про системный анализ, а про финансовый. Автор делится своим личным опытом и ценными советами по управлению финансами и личными инвестициями.
Вот такие у нас классные каналы! Все, как на подбор. Почти готовая папка получилась.
Ну а в комментариях к этому посту можете писать о своих каналах! Даешь переопыление подписчиками!
🍾32👍15❤🔥9❤4🔥4
Вайб-кодинг в ChatGPT — одно удовольствие! Он в последних обновлениях такой человечный стал, можно с ним болтать, как с живым программистом, только без опасений получить в ответ какое-нибудь хамство.
Для одноразовых скриптов — что-нибудь откуда-нибудь вытащить, что-то где-то подправить в пакетном режиме — просто супер.
Вот, например, понадобилось мне переименовать около сотни файлов у себя на Яндекс.Диске по определенному шаблону. Вручную это делать ну совсем неправильно. Смотрим API диска, получаем авторизационный токен, расчехляем python — и вперёд!
Как обычно, после нескольких итераций разнообразных ошибок, всё получилось.
Кстати, вы же понимаете, что программист вообще большую часть времени видит свою программу не работающей? То есть, для программиста вообще не удивительно, что программа не работает по какой-то причине — да она постоянно не работает! Когда она заработала — в этот момент программист перестает ей заниматься, и начинает работать над другой неработающей программой. Ну или ломать работающую, чтобы внести в неё изменения.
Тут на простом примере нужно было понять — какое именно API использовать (WebDAV или HTTP), нужные методы, разницу между POST, PUT и PATCH (в API Диска есть все, и все разное делают), способ авторизации, лимиты, обработку ошибок.
Приложил к посту переписку с ИИ (не всю, самое интересное). Ну правда же он милашка?
Для одноразовых скриптов — что-нибудь откуда-нибудь вытащить, что-то где-то подправить в пакетном режиме — просто супер.
Вот, например, понадобилось мне переименовать около сотни файлов у себя на Яндекс.Диске по определенному шаблону. Вручную это делать ну совсем неправильно. Смотрим API диска, получаем авторизационный токен, расчехляем python — и вперёд!
Как обычно, после нескольких итераций разнообразных ошибок, всё получилось.
Кстати, вы же понимаете, что программист вообще большую часть времени видит свою программу не работающей? То есть, для программиста вообще не удивительно, что программа не работает по какой-то причине — да она постоянно не работает! Когда она заработала — в этот момент программист перестает ей заниматься, и начинает работать над другой неработающей программой. Ну или ломать работающую, чтобы внести в неё изменения.
Тут на простом примере нужно было понять — какое именно API использовать (WebDAV или HTTP), нужные методы, разницу между POST, PUT и PATCH (в API Диска есть все, и все разное делают), способ авторизации, лимиты, обработку ошибок.
Приложил к посту переписку с ИИ (не всю, самое интересное). Ну правда же он милашка?
💯23🔥16😁4❤3👍2