Системный сдвиг

Какое актуальное мнение:

...для программистов наступают трудные времена. Объём и сложность программ возрастают, непропорционально по отношению к зарплате. Романтический ореол непостижимости этой профессии, если он когда-либо и существовал, начинает меркнуть. На Западе стартапы* тают как вчерашний снег, а программисты начинают пополнять армию безработных. Оспаривается даже само стремление рассматривать программистов как профессионалов особого рода. Главное же — это то, что вольная армия программистов постепенно попадает в «плен» к администраторам и руководителям, которые стремятся сделать труд программиста планируемым, измеряемым, однородным и обезличенным.

— Андрей Петрович Ершов, академик АН СССР, "О человеческом и эстетическом факторах в программировании", 1972 г. * в оригинале — "софтверхаусы", которые Ершов определяет так:

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

Там же, кстати, про разделение проектирования и изготовления ПО и про конвейерный способ изготовления:

В каком-то смысле конвейер является дьявольским изобретением. Поднимая продуктивность на небывалый уровень, он в то же время в максимальной степени превращает человека в придаток машины. Конвейерный метод в программировании может либо убить интеллектуальную компоненту в труде программиста, либо вызывать неврозы** из-за противоречия между монотонностью и трудностью работы. [..] Руководители, ответственные за долговременные проекты, ищут пути к формализации этапов разработки и передаче проекта из одних рук в другие. [Но] само дело отчаянно сопротивляется такому разделению. По-видимому, правильное решение этого вопроса невозможно без учета человеческого фактора и эстетической потребности, препятствующей тому, чтобы заниматься реализацией чужих идей или не видеть самому овеществления своей идеи. Отдавать технический проект в другие руки — то же самое, что посылать своих детей в интернат.

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

В каждом проекте, где есть дизайнер и аналитик, есть главный вопрос: что должен делать дизайнер, а что аналитик? Кто за что отвечает? Это, на самом деле, большая серая зона. С одной стороны, дизайнер отвечает за оформление, тут вопросов нет. Точнее, даже так: за структуру, компоновку и оформление. А аналитик отвечает за постановку задачи разработчикам, тут тоже никто не сомневается. А дальше начинается туман и неопределенность. Например, дизайнер видит список, и на автомате рисует под ним пагинацию, а над ним блок фильтров и сортировку. И ещё строку поиска, ага. А у аналитика ничего такого не было, это новые требования! Чья это задача? Дизайнер выявил новые требования? Или аналитик не донес до дизайнера, что элементов в списке в 99,9% случаях не будет больше 7, и они поместятся на один экран? Вообще, по моему опыту, дизайнеры довольно часто придумывают новые фичи. Иногда просто так :) У меня в одном проекте дизайнеры придумали кнопку "Случайный курс", типа как в классическом интерфейсе Гугла была кнопка "Мне повезет!". Зачем? Ну потому что в этом месте должен быть какой-то элемент, чисто для равновесия! Для них это просто кнопка, а поиск — просто строка. Для аналитика же поиск — это целый новый блок функциональности, возможно — целая новая подсистема со своими настройками, версиями, отдельным деплоем и встроенным ИИ. Или нет, нужно взять ещё неделю, чтобы разобраться, как этот поиск должен работать. Бывает и в обратную сторону: когда от аналитика требуется самому спроектировать интерфейс. Ну а что, тут же всё просто, а дизайнер занят. Поэтому все решения по интерфейсу пусть примет аналитик, а дизайнер только раскрасит. приходит дизайнер, и понимает, что нарисованное аналитиком не лезет никаким боком в дизайн-систему (выпадающий список с множественным выбором и комментариями к каждому значению?! Такого вообще не бывает!) У меня сложилось два варианта взаимодействия с дизайнерами: либо совместное творчество, вот просто в онлайне на созвоне (а раньше — за одним компьютером, как парное программирование) — это в идеале, либо — прописать всё максимально чётко, но тут всё равно не получается ровно, нужно быть готовым к новым требованиям 😭 Ну или к тому, что вы написали очень много, и мы как-то не осилили все это прочитать... В общем, я для себя разработал чеклист, о чем нужно подумать, когда разрабатываешь дизайн, или передаешь задачу дизайнеру. Для каждого экрана: 1. Что это за экран, где я? 2. Что тут самое главное, что пользователь должен понять в первые секунды? 3. Какое главное действие должен сделать пользователь на этом экране? 4. Что ещё может сделать пользователь? 5. Какого типа этот экран? Он информирует, выводит список чего-то, что-то требует, предлагает что-то ввести или создать? Обычно самые сложные формы, из которых выпадает больше всего новых требований — те, где выводится список и где нужно что-то создавать. К ним отдельные требования: если у нас что-то выводится списком, то: * как это показывать? (таблицей, списком, карточками, тайлами и т.п.) * нужна ли пагинация? * нужно ли это фильтровать? и по каким принципам? * сортировать? * нужно ли в этом списке что-то искать? * нужно ли этот список выгружать в файл или куда-то передавать? Соответственно, про фильтры и сортировку — нужно ли их сохранять, и как долго? То есть, есть ли у нас сущность "сохраненный поиск"/"настроенный фильтр", или нужно хотя бы сделать так, чтобы фильтр не сбрасывался при уходе и возврате на отфильтрованную страницу? Отдельный частный случай списка — витрина. Там начинаются разные продуктовые штуки: что поднять повыше, как тасовать выдачу, чтобы было не скучно, как не обидеть разных поставщиков, если у вас их несколько, и т.п. В общем, вы уже поняли — я подхожу к дизайну максимально системно и аналитически. Пожалуй, стоит получше рассказать про алгоритм и выбор элементов для UI.

Я, кажется, нашел работающий вариант генерации диаграмм BPMN ИИшкой. И это, конечно, не просто промпт. Время промптов прошло, сейчас говорим про скиллы, харнесс и управление контентом. Ну и это решение для BPMN — тоже скилл, причем там на входе промпты, а потом работа скриптов: промпт думает над процессом, оформляет его в виде промежуточного описания на JSON, JSON проверяется против схемы и против правил составления бизнес-процессов, потом загоняется в движок автолейаута и наконец сериализуется в BPMN 2.0 XML и отрисовывается в SVG. Примерно такой пайплайн у меня и возник в голове, когда я несколько раз потерпел неудачу с генерацией промптом, но довести до ума не получилось. И то сказать — репозиторий этого скилла весит больше 5 Мб! В смысле, это исходные тексты, в основном .js, .md, .json и схемы. Не бывает таких промптов. Точнее, промпты теперь размазаны по этапам выполнения скилла. Например, 42 правила формирования BPMN описаны в отдельном md-файле на 1028 строк, и таких файлов там пара десятков. То есть работает это как связка из промптов и скриптов на js, объединенных в пайплайн и обвешенных автоматическими проверками. Самостоятельно вручную такой скилл любой аналитик для себя не сделает, просто времени не хватит между рабочими задачами. Либо в организации должна быть служба, создающая и тестирующая внутренние скиллы, либо пользоваться готовыми универсальными, вот как этот. Вот, кстати, ссылки на него: https://github.com/Stieges/bpmn-generator, он есть и на MCP Market: https://mcpmarket.com/tools/skills/bpmn-generator (И да, MCP-сервер там тоже встроен, качественный продукт). Сделан он под Claude Code, но может устанавливаться и в другие AI IDE, я вот поставил себе в Курсор. Соответственно, если у вас используется VSCode с какой-то локальной моделью — можно и туда поставить. Навскидку он мне сгенерировал два довольно приличных процесса, правда, у меня не было под рукой описания сложных. по крайней мере, это сильно лучше, чем всё, что я видел до этого. Установка, если вы никогда со скиллами не сталкивались, относительно простая: сначала нужно куда-то склонировать репозиторий из Гитхаба, и запустить инсталляционный скрипт (а предварительно установить node.js и npm, конечно). Тут нужно немного побыть в шкуре программиста. Когда-то была шутка про "юзабилистов на питоне", ну вот мы теперь все — аналитики на питоне и js. Когда всё установлено — просто создать папку скилла в вашем проекте (для Курсора это будет, например, .cursor/skills/bpmn-generator) и закинуть туда skill.md и ссылки на папки reference и scripts, IDE должен подхватить скилл автоматически. И всё, начинаете пользоваться — вызывая явно по имени скилла, или он сам подхватится, если в запросе будут слова типа процессы, BPMN и т.д. Забавно, что запросы внутри скилла написаны частично на немецком, соответственно, и слова-триггеры тоже на английском и немецком. Если дойдут руки, попробую как-нибудь адаптировать к русскому весь это массив запросов. В общем, кажется, сейчас курс по ИИ для аналитиков должен состоять из рассказа про VSCode/Cursor/Claude Code, какие скиллы в них установить и что написать в rules.md

"Вся цифровая инфраструктура держится на библиотеке, которую в одиночку с 2003 года поддерживает рандомный чувак из Небраски" А вы знаете, что эта картинка — ни разу не преувеличение? И вот тут ребята сделали классный сайт с неизвестными героями, на которых держатся все наши технологии: https://sheets.works/data-viz/holding-up-the-internet Пол Эггерт, преподаватель из UCLA, с 2005 года поддерживает tz database — набор файлов с актуальным описанием часовых поясов во всех странах. На эту базу опираются все функции, связанные со временем — расписание поездов, билеты на самолеты, календари, включение фонарей по вечерам и всякое такое. три миллиарда телефонов на Андроиде и миллиард на iOS, большинство серверов и почти все языки программирования. Лассе Коллин в одиночку поддерживает xz — архиватор для всех серверов на Линуксе. Однажды он пустил к исходникам некоего китайца, немедленно встроившего в архиватор бэкдор, с тех пор не рискует. Тодд Миллер, поддерживающий sudo. Неизвестный чел DRC, чья библиотека используется в каждом телефоне и браузере для открытия файлов jpg. Анонимная команда, разрабатывающая SQLite без внешнего финансирования, но с одним триллионом установок. zlib. bash. libxml2. curl. core-js. Инфраструктура реально очень хрупкая. Bus-фактор многих проектов равен 1. Сделать с этим особо ничего нельзя, про это вообще никто не задумывается. sudo? curl? это же встроенные утилиты, разве нет? Разве их кто-то специально написал? Я когда-то писал про бездумное использование общественных серверов точного времени (https://t.me/systemswing/528) Мы привыкли, что инфраструктура... ну, просто есть. Как вода. И это, кстати, интересный вопрос про видимость работы, в том числе и аналитика. Я когда-то в шутку предложил как критерий качества работы аналитика число восклицаний "О, об этом мы как-то не подумали!" в ответ на вопрос аналитика. Это шутка лишь отчасти. Я вижу — особенно в последнее время — много претензий к аналитикам, мол, а зачем вы нужны? Что вы делаете, какая от вас польза? Только задерживаете разработку. И многие аналитики даже не знают, что ответить на эту претензию (да даже и руководители анализа зачастую теряются). Так нужно сделать видимой свою работу! Как сертифицированный аудитор ISO 9000, говорю вам: записи первичны! Записи — всему голова! Что не записано, того и не было. Вот у архитекторов есть ADR — записи архитектурных решений. Ну, должны быть. Они, конечно, для памяти, чтобы не забыть, почему у нас всё так криво устроено и кто это придумал. Но и для фиксации работы архитектора. Так и для аналитика можно такие записи завести: EСR, Edge Case Record. Запись о выявленном граничном кейсе. Структура примерно такая: ID, дата, что нашли, предотвращенные последствия (что было бы, если бы не аналитик), принятое решение (тут можно дописать, сколько новых требований появилось и насколько это расширило скоуп; при желании можно даже выгоду посчитать — был ли выигрыш от исправления относительно риска потерь). Соответственно, поэтим записям для руководства считаем Shift-Left Index (Индекс раннего обнаружения): Количество критических логических ошибок и конфликтов интеграции, обнаруженных на этапе анализа, деленное на общее количество багов, найденных суммарно на всех стадиях разработки и в продакшене за тот же период. Ваш вклад — четверть или 70%? Можно ещё цену исправления прикинуть, в часах работы аналитика и остальной команды + простой. Ну и заодно можно (и нужно!) считать снижение того самого bus-фактора (описали за квартал столько-то скрытых зависимостей и восстановили документацию к X легаси-компонентам и интеграциям). И красивую инфографику со своими достижениями.

Знаете ли вы про добродетели хорошего программиста? Лень, нетерпение и высокомерие. Лень заставляет программиста не делать никакую работу дважды: как только появился похожий случай, нужно придумать универсальный способ для общего решения. Нетерпение вызывает раздражение, когда программа тормозит, и приводит к желанию искать эффективные и быстрые решения и хитрые хаки. Высокомерие (гордыня, самомнение) заставляет стремится к идеалу, чтобы никто не мог покритиковать решения, а только восхищаться ими. Эти "добродетели" свойственны людям-программистам, но можно их привить и LLM-кодеру:

Ты — опытный инженер-программист, руководствующийся тремя добродетелями: 1. Ты ЛЕНИВ: Ты ненавидишь рутину и дублирование. Пиши переиспользуемый код (по приницпу DRY), автоматизируй всё, что можно, и создавай лаконичную архитектуру. 2. Ты НЕТЕРПЕЛИВ: Ты не терпишь медленный код. Оптимизируй алгоритмы (минимизируй Big O complexity), используй кэширование и асинхронность, чтобы система работала мгновенно. 3. Ты ГОРД: Ты пишешь код так, чтобы им гордиться перед сообществом. Он должен быть чистым, безопасным, задокументированным, снабженным тестами и устойчивым к любым ошибкам. Не выдавай "просто рабочий" код, выдавай шедевр.

Эти качества придумал Ларри Уолл, создатель языка Perl. Собственно, в языке это всё как раз и проявляется: можно очень быстро решить любую проблему коротким скриптом. Лень: не нужно придумывать имена переменным, часто их даже не нужно указывать. Прямо в язык встроены регулярные выражения. There's More Than One Way To Do It, TMTOWTDI — можно одну и ту же вещь сделать совершенно разными способами, как удобно именно сейчас. Нетерпение: никакой компиляции, всё работает сразу из командной строки (помним, что это конец 80-х, и программы вообще-то компилировались, иногда десятками минут). Гордыня: на Perl можно было писать программы, которые выглядели, как произведение искусства (абстрактное, постмодернистское). Говорили, что программы на Perl write-only, разобраться в них другой программист не может; говорили, что программа на Perl выглядит одинаково до и после обфускации. В общем, язык для избранных. Или для хакеров в старинном смысле. Но в массовом производстве Perl проиграл другим подходам, например — Python. В некотором смысле Python по философии противоположен Perl'у. Есть 'Дзен Python', набор принципов разработки: 1. Красивое лучше, чем уродливое 2. Явное лучше, чем неявное 3. Простое лучше, чем сложное 4. Сложное лучше, чем запутанное 5. Плоское лучше, чем вложенное 6. Разреженное лучше, чем плотное 7. Читаемость имеет значение 8. Особые случаи не настолько особые, чтобы нарушать правила 9. Хотя практичность побеждает чистоту 10. Ошибки никогда не должны замалчиваться 11. Если не отключены специально 12. Встретив двусмысленность, отбрось искушение угадать 13. Должен быть один — и, желательно, только один — очевидный способ сделать это 14. Хотя он поначалу может быть и не очевиден, если вы не голландец (отсылка к Гвидо ван Россуму). 15. Сейчас лучше, чем никогда 16. Хотя никогда зачастую лучше, чем прямо сейчас (нетерпение, помним?) 17. Если реализацию сложно объяснить — идея плохая 18. Если реализацию легко объяснить — идея, возможно, хорошая 19. Пространства имен — отличная штука! Давайте делать их больше! Как видите, принципы местами прямо противоположны. Вероятно, это и обеспечило значительно большую популярность и распространенность Python: легче понять, легче учить, проще поддерживать. Если всё всегда делается одинаково и явно — любой разработчик может легко разобраться, подхватить чужой код. Да и не-разработчик быстро поймет и сможет использовать для своих задач. Стабильность, предсказуемость, одинаковость (чуть-чуть туповатость, может быть) — вот то, что нужно этому миру. И это тоже может быть подходом для инструктажа LLM. Не выдумывай, не извращайся, пиши в расчете на то, чтобы кто угодно потом мог легко разобраться.

Ты — ИИ-архитектор программного обеспечения, чей главный приоритет — чистота, читаемость и поддерживаемость кода. Ты строго следуешь философии "The Zen of Python": 1. ЯВНОСТЬ: Пиши код без "магии" и скрытых смыслов. Обязательно используй строгую типизацию (Type Hinting) и давай переменным говорящие, понятные имена. 2. ПРОСТОТА: Избегай оверинжиниринга. Выбирай самое простое решение из возможных. Держи структуру плоской, минимизируй вложенные циклы и условия. 3. ЧИТАЕМОСТЬ: Форматируй код идеально (по стандартам PEP 8 / Clean Code). Код должен читаться как хорошая проза. 4. ЧЕСТНОСТЬ С ОШИБКАМИ: Никогда не скрывай и не "приглушай" ошибки. Перехватывай только точечные исключения, пиши информативные логи, чтобы код не маскировал ошибки, а максимально их подсвечивал. 5. ПИШИ ДЛЯ ЧИТАТЕЛЯ: Рассчитывай, что твой код должен будет изучать, понимать и изменять кто-то другой. Помоги ему быстро во всем разобраться.

Программная индустрия решила в пользу простоты и понятности против эффективности и искусства. Сейчас все опасаются вайб-кодинга, но может нужно просто задать ИИ верные ориентиры?...

Короткая заметка: ещё весной я проводил курс по применению ИИ для системных аналитиков. Ну и до этого в нескольких вариантах: курсы, лекции, мастер-классы. Но уже летом я начал думать, как его менять. И, в общем, многое, что я там рассказывал, не особо уже актуально. Раньше в курсах ведь что рассказывали: вот есть такие модели, вот так нужно составлять промпты, такие вот формулировки использовать... Но сейчас это всё уже ушло в прошлое. Если модель вас не понимает — возьмите нормальную топовую модель, перестаньте есть кактус. Не нужно уже растолковывать модели каждый шаг и расписывать роли. Всё это ушло в системные инструкции, rules.md и скиллы. И занимаются этим специальные люди — ну, впрочем, те, кто до этого экспериментировал с промптами. Хитрые промпты были нужны, когда модель вообще не понимала, чего от неё хотят. Сейчас такого у верхних моделей уже почти не встречается. Сейчас горячие темы — управление контекстом, харнесс, гардрейлы, цепочки вызовов и проверок. Как кормить LLM контекстом и какие промежуточные артефакты она должна генерировать, чтобы и самой не запутаться, и человек мог быстро проверить, вот основные вопросы. Но ответов на них пока нет, потому что мы — сюрприз! — не до конца понимаем, что именно и как делает системный аналитик. В чем его основаная польза? Как проверить качество его работы? Где граница деятельности? Кто умеет на это отвечать, тот сможет построить ИИ-пайплайн, включающий задачи аналитика. Ну или будет пользоваться готовыми spec-kit или OpenSpec. Вот только эти SDD-инструменты пришли с запада, а там, как мы знаем, организация разработки несколько отличается, и аналитиков уже давно нет. Ну и как работать с требованиями они, значит, тоже уже забыли. Программистам это всё тоже не нужно и не интересно, они приниципиально не понимают: "На первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны." (это цитата из рандомной статьи программиста про SDD с Хабра). Требования, наверное, зачем-то нужны, ну пусть будут. Разработчика интересует, как всегда, другое — чтобы тесты были, чтобы стиль кода соблюдался, чтобы миграции нормально сформировались и применились. В этом есть очевидный (нам с вами) риск: всё сделано, как положено с точки зрения программиста, но в результате получилась какая-то фигня. Потому что требования толком никто не проверял и не анализировал. Дальше возникает интересный вопрос: нужно ли нам всё ещё сохранять две отдельные роли аналитика и разработчика (которые обе проверяют работу ИИ, но проверяют в ней разное), или у нас возникнут новые фулл-стеки, как броненосцы в сказке Киплинга — разработчики научатся видеть смысл в требованиях, а аналитики начнут понимать нюансы разработки? Или всех их просто сметет, и все эти вопросы через пару итераций погрузятся так глубоко, что только узкие специалисты будут знать, как так внутри устроены спеки/код/релизные пайплайны, как сейчас мало кто задумывается об устройстве конвейера и ветвлений в процессоре? История разделения труда дает нам двоякие примеры: с одной стороны, углубление разделения труда, с другой — наоборот, поглощение чисто навыковых профессий. Когда-то ретушер, линотипист и чертежник были отдельными профессиями, но цифра их съела. И все просто чертежники стали чертежниками-конструкторами. Кем станут аналитики, вот вопрос.

Музей бессмысленных метрик: число строк кода, стори-поинты, число пулл-реквестов. И наш новый экспонат: расход токенов! А у вас измеряют активность сотрудников по внедрению ИИ? Про токены, кстати, не шутка — многим моим знакомым в западных компаниях действительно выделяют бюджет в токенах на месяц, и следят за его расходованием. Причем сейчас уже пошел откат: самым активным число токенов стали подрезать, слишком дорого. В российских компаниях пока видел, как измеряют число обращений к локальным моделям, развернутым в контуре компании (только к локальным! никаких облачных провайдеров!), число вызовов определенных скиллов. Ну да, для локальных моделей число токенов не так важно, свои же. Про измерение результатов пока не слышал. Ну вот такого, чтобы кто-то рассказывал про то, как в разы ускорили подготовку документов, или уменьшили время согласования, или число уточнений спецификации на этапе разработки. Какие у нас ещё есть разумные метрики аналитического процесса? Я тут исследовал образовательные организации, и как в них внедряют ИИ. Там у них всё жестко и безальтернативно — если уж руководство решило использовать генеративный ИИ, так будут такие методы: планы развития и отчеты о работе теперь принимаются только в виде ссылок на чат с ИИ, в последнем случае — с навыком расчета премий. Вот сколько тебе ИИ рассчитал, столько и получишь. Туда же — планы занятий, генерация репортов об успехах учащегося. Мимо ИИ их просто запрещено делать. На некоторых дисциплинах в качестве ответа на задание от группы принимается тоже ссылка на чат (там, где раньше попросили бы презентацию). Такой вот подход, а не какое-то там мямление — ну хочешь, используй, не хочешь не используй, но хотя бы попробуй, а? ну разочек?.. К этому, конечно, по-хорошему должен быть прикручен контур обратной связи и постоянного совершенствования промптов, скиллов и т.п., но мотивирует этим заниматься внешнее жесткое распоряжение. Вот такие у нас механизмы управления бывают. А как у вас это устроено? Добровольно ли применение ИИ? Есть ли метрики и KPI? Есть ли безальтернативное и обязательное использование инструментов? Или наоборот всё запрещено до сих пор?

Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов? Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады: — Как эффективнее использовать возможности мозга — Какие навыки развивать аналитику и как выстроить план роста — SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика 📆 29 сентября 📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн Выбирайте удобный формат и регистрируйтесь по ссылке

Должен вам сказать, на самом деле я не отношусь к ранним последователям. Я даже скорее тормоз в этом смысле. Вот и с ИИ я только весной этого года добрался до Cursor. И вот что советую: если вы пробуете что-то делать в свой работе через чаты — бросайте эту ерунду. Это работает только в режиме "спросить что-то очень быстро" или "сгенерить очередную одноразовую картинку". Для настоящей работы над сколь-нибудь большим проектом нужно использовать среду разработки со встроенными агентами — Cursor, Claude Code, OpenCode и т.п. Мне нравится Cursor, потому что у него знакомый интерфейс VSCode (и интерфейс в принципе есть, а не просто консоль, я не консольный чувак), есть выбор из разных моделей и встроенные агенты. Это не вайбкодинг, это так сейчас программирование выглядит. Я, кстати, впервые с 2012 года взялся за написание чего-то большего, чем скрипт для анализа или парсинга данных, и сейчас в одиночку строю проект, на который раньше понадобилась бы команда из 3-5 человек. В принципе, мне даже хватает встроенных в Cursor агентов, но есть несколько скиллов, которыми я активно пользуюсь. Скиллы — это ещё один аргумент к использованию ИИ в таком варианте, а не в онлайн-чате. (Другой — что можно закинуть кучу документов в проект, и не париться ограничениями, агент их сам найдет и изучит, сколько бы их у вас там ни было). Что у меня из скиллов в постоянной работе: grill-me от Matt Pocock (https://github.com/mattpocock/skills). Скилл делает ровно то, что в названии — качественно прожаривает вашу идею, иногда прямо очень жестко. Работает он в режиме интервью, то есть задает вам вопросы. Аналитика, который бы задавал такие вопросы, любой заказчик сам бы прожарил из огнемета. А когда они исходят от тупой машины, вроде и не так обидно. На выходе получается план проекта с основными техническими решениями (grill-with-docs формирует документацию, в которой, в том числе, задан язык, которым вы описываете проблемную область). У Мэтта там целый пак скиллов, которыми можно дальше генерить проект по спеке после прожарки, но я использую в основном для обкатки идей проектов и документов. spec-kit для Cursor (https://github.com/madebyaris/spec-kit-command-cursor). Вы знаете, какое самое последнее новшество в разработке? SDD — Spec-Driven Development, разработка, управляемая спецификациями. Вот неожиданность, правда? Оказывается, ИИ лучше всего разрабатывает по детальным спецификациям, вот так новость! Скиллы от Мэтта — это тоже SDD, но я пока не придумал, как их объединить. SpecKit хорош тем, что содержит цельный воркфлоу, от написания этих самых спецификаций до их реализации. Он тоже сначала проводит с вами интервью, но более поверхностно, без прожарки. Если мне не нужно сильно вникать, я беру его. Он генерит большие объемы спецификаций (сотни задач), а потом так же неутомимо их реализует. Фактически, это таск-трекер на основе файлов, со статусами и ссылками на спецификацию (у меня в одном из проектов оно сделало сходу 61 задачу, и это только MVP!) adversarial-editorial-review (https://github.com/Halfofthesky/adversarial-editorial-review) — это тоже прожарка, но для статей (очень мне помог при написании магистерской, правда результата от людей-ревьюверов я пока не видел 😅). Он берет ваш текст и дает трем разным "ревьюверам": один считает, что доказательная база слабее, чем вы преподносите, второй — что в аргументации есть логические изъяны, третий — что вы упускаете точку зрения кого-то из вовлеченных лиц, или слишком вольно трактуете теорию, на которую опираетесь. Для научных публикаций мне очень понравился (хинт: можно не только свои брать, но и чью-то готовую опубликованную подсунуть!), нужно бы такой сделать для проектных аналитических документов — чтобы с разных сторон критиковали, а потом редактор сводил общий результат. В общем, это всё совершенно другой уровень качества, и если вы пробовали только чаты — советую попробовать и такой инструмент (в бесплатной версии он позволяет пощупать, но токены очень быстро кончаются). Я уже включил в свои ежемесячные расходы подписку, ну что же теперь делать, отказываться от этого инструмента не хочется (и, честно говоря, за многие задачи я бы просто не взялся без него).

Знаю, что в Яндексе работает много аналитиков данных, или BI-аналитиков — тех, кто перемалывает массивы данных и извлекает из них всякие интересные инсайты. В принципе, роль смежная — я и сам неоднократно решал задачи построения хранилищ для аналитики и обеспечения бизнеса актуальными и интересными данными. Но я не считаю себя крутым экспертом именно в таком анализе. Тем интереснее послушать, как это устроено в больших масштабах. Ну а заодно посмотреть на то, как ребята осваивают ИИ. У Яндекса есть подкаст от аналитиков для аналитиков "Доверительный интервал" — это регулярные встречи, где они обсуждают свои задачи и актуальные боли. Последний выпуск там был про ИИ: у них тоже идёт освоение, adoption, есть сомневающиеся, есть и ментальные блоки "ой, я попробовал, ничего эти агенты не умеют". Интересно, что все с разных сторон заходят — кто-то начал с кода, кто-то с презентаций, кто-то с разговоров с ИИ, как с оппонентом или партнером по размышлениям. А потом люди втянулись, и теперь просто каждый день используют в штатном режиме. Интересная мысль там была про агентов. Я сам где-то с весны работаю не в отдельных чатах, а в Cursor'е. Какие там агенты, где там агенты — ну, где-то внутри они есть, для меня это всё равно выглядит, как чат. Но! Этот чат (через агентов) имеет доступ к файлам на диске, к браузеру, к интерпретатору python или node, MCP, и может запускать разных агентов для разных задач. Если вы видели ИИ только в виде чата в браузере — попробуйте. Это вообще другой уровень. Те же презентации агентами гораздо удобнее собирать, в чате у меня ни разу нормально не получалось, а тут один агент думает над содержанием, другой пишет код, генерирующий pptx, и запускает его, третий думает про оформление, четвертый проверяет. А когда у вас есть подключенные системы и данные, всё вообще начинает выглядеть, как магия. В том числе и для пользователей. Я помню, как давно зрела идея, что бизнес сам сможет получать нужные данные. SQL продвигали под этим соусом, конструкторы дашбордов — ничего не срабатывало, всё равно заказчику нужно было или звать разработчиков/аналитиков, или самому становиться таким разработчиком. И вот, наконец, с ИИ — вроде начало получаться. Можно сказать, чего ты хочешь, и ты получишь это. НО! Проблема в том, чтобы убедиться, что данные достоверны. Вот это сомнение важно в заказчика заложить (и ребята в видео как раз об этом говорят), а то часто все принимают на веру. Куда в таком случае деваются аналитики, и нужны ли они? Ну, во-первых, остаются всё-таки сложные задачи (которые всё равно теперь можно делать в разы быстрее); а, во-вторых, и это даже важнее — аналитики становятся архитекторами инфраструктуры. Чтобы ИИ всё сделал, нужно ему подготовить качественные данные (и убедиться, что они качественные), описания этих данных (чтобы понял смысл) и ограничители/валидаторы (харнесс), чтобы быть уверенными, что ИИ выдал не ерунду. И это интересное свидетельство о том, какие формы применения ИИ зарождаются в индустрии: 1) усиление себя, делегирование своих задач, получая ускорение в разы или даже десятки раз; 2) передача своих функций заказчикам, оставляя за собой построение архитектуры и контроль качества. Две разных стратегии, но в обеих получается делегирование, только разное — ИИ-агентам или своим же заказчикам. А вы посередине, как царь горы 🤩

Дальше культурно-историческая теория деятельности (в изложении Энгестрема) говорит о противоречиях — contradictions, или о напряжениях — tensions. Зачастую эти противоречия уже существуют, сложились исторически ещё до внедрения ИТ-системы, а система может их гасить или усугублять, или вводить новые напряжения. Эти же напряжения являются на самом деле движущей силой для эволюции системы деятельности, в том числе для создания ИТ-систем. Интересный вопрос — какое напряжение, какое противоречие стало поводом создать вашу систему? Энгестрем выделяет структурно 4 уровня противоречий: 1. Противоречие в одном узле деятельности: например, правила противоречат друг-другу, или инструменты несовместимы/делают принципиально разное, в разделении труда одна задача назначена двум ролям, у деятельности несколько разных объектов и целей. 2. Противоречие между узлами: инструменты не соответствуют правилам, не подходят для достижения цели, разделение труда конфликтует со сложившимися сообществами, и т.д. 3. Противоречие между существующей системой деятельности и новой. Это когда мы пытаемся что-то менять. 4. Противоречие между смежными системами: теми, что соединены через общий результат, теми, кто пользуются результатом, кто дает вам правила, инструменты, сообщества, да и самих субъектов (привет, HR!) Весь этот анализ, конечно, ближе к бизнес-анализу и в частности к анализу организационных изменений, но и для системного аналитика (особенно если он считает себя системным инженером) важно иметь инструмент для понимания — почему система может не стать успешной. У противоречий есть 4 проявления: 1. Дилемма 2. Конфликт 3. Критический конфликт 4. Двойное послание Ситуация двойного послания является причиной изменения системы деятельности, Энгестрем называет это "экспансивным обучением" организации. Сначала возникают первичные противоречия, участники постоянно сталкиваются с дилеммами, выбором, неэффективностью; изобретают разнообразные обходные маневры, разделяют формальные правила и реальную деятельность. Нарастает фрустрация, но всё это может продолжаться очень долго, годами. Пока не произойдет явный критический конфликт, или все участники не попадут в ситуацию постоянной двойственности, которую не смогут выдерживать (потому что каждое действие ощущается как ошибка, какой бы вариант вы не выбрали). Тут должно произойти экспансивное обучение, система деятельности должна "переизобрести себя", предложив какой-то выход из ситуации двойного послания. По идее, новая система должна выйти на более высокий культурно-исторический уровень. Впрочем, это оптимистичный взгляд — бывает и по-плохому: * система деятельности может застрять в бесконечных воркэраундах, а люди начнут просто сгорать из-за двойных посланий; * сообщество может фрагментироваться и поляризоваться: все начнут обвинять друг-друга, и без способности объединиться никакого обучения происходить не будет, а будет происходить политический паралич; * руководство (особенно бюрократическое) может начать усиливать давление: раз правила не работают, значит, их плохо соблюдают. Давайте введем больше правил и строже штрафовать! Система сваливается в раскручивающуюся петлю обратной связи * вместо усложнения деятельности система может деградировать и вернуться к более простым, но энергетически более выгодным формам В общем, это всё ужасно интересно, и особенно — какова во всем этом роль ИТ-систем, какое перераспределение информации и власти они создают, и это, на мой взгляд, и есть самый настоящий бизнес-анализ. Только я такого ни в одной учебной программе по БА не видел.

Что-то перерывы между постами стали совсем длинными. Надеюсь в ближайшее время вернуться в ритм, и поставлять вам неочевидные приемы и темы, про которые вы вряд ли у кого-то ещё прочтете. Но сначала продолжение предыдущего поста. Итак, я сел выписывать список заинтересованных сторон. Требования ведь берутся только от заинтересованных сторон, больше неоткуда. Получился вот такой список: 💻 те, кто непосредственно работают с системой (пользователи); 🪪те, кто приводят систему в работоспособное состояние, устанавливая настройки и наполняя контентом (прикладные администраторы); 🎁те, кто получает пользу от работы системы (заказчики, клиенты); 💸те, кто выделяет ресурсы и несет риски в связи с созданием и работой системы (топ-менеджмент, инвесторы, юристы, специалисты по безопасности); 🏢те, кто будет создавать, обеспечивать работоспособность и изменять систему (разработчики, администраторы, инженеры по эксплуатации, служба поддержки пользователей); 📁те, кто обеспечивает организационные меры по созданию, запуску и развитию системы (руководитель проекта, юристы, маркетинг, отделы обучения и HR); 📲те, на кого непосредственно повлияет создание системы, как-то изменит их деятельность (сотрудники, клиенты, поставщики); 📝те, кто задает “правила игры”, обязательные требования и ограничения (регуляторы, методологи, нормировщики и т.п.); 📰те, кого почему-то заботит создание системы (медиа, общественные организации, активисты, инфлюенсеры, депутаты). Эту "китайскую классификацию" ("...нарисованные тончайшей кистью из верблюжьей шерсти...") хочется как-то упорядочить. Вообще упорядочивание и систематизация — один из главных инструментов анализа, позволяющий найти пробелы. Как таблица Менделеева, в которой вначале было много дыр — не открытых, но предсказанных элементов. Для человеческой деятельности такой общепризнанной модели пока нет, но есть некоторые теории. Интересно, что теория деятельности появилась в СССР (Выготский, Леонтьев...), и это одна из признанных в мире не технических и не естественно-научных советских теорий. Впрочем, развивает её в последнее время ученый из Финляндии, и придумал уже 4 поколение этой теории (1 - Выготский, 2 - Леонтьев, 3 и 4 - Энгестрём). У Выготского речь шла об обучении человека, а Энгестрёма — про организационный дизайн и обучение организаций/команд. Ну и про проектирование взаимодействия людей и компьютеров в очень широком смысле. Энгестрём рисует сложный треугольник: субъект (кто действует), объект (над чем производится действие), инструменты (чем производится действие). Это база от Выготского. Ниже — окружение: правила, сообщество, система разделения труда. Отдельно от треугольника — результат, измененный объект. Посмотрим на наших стейкхолдеров — они понятным образом раскладываются по этим элементам. Вот только системы деятельности у них оказываются разными. Пользователь уже имеет какую-то свою сложившуюся систему деятельности (с объектом и инструментами, и всеми остальными элементами), и в эту деятельность мы пытаемся вставить нашу систему. Система — это инструмент для пользователя. Меняется инструмент — начинает меняться вся система деятельности, ну или хотя бы вибрировать, как паутина, ведь всё со всем связано. Пользователю важно, чтобы инструмент был не хуже предыдущего, и результат тоже был не хуже (я уже не буду говорить, что объект должен быть тем же, иначе это другая деятельность). И вот у нас есть пользователи и сообщества, а члены сообществ, с одной стороны, формируют нормы и правила (они могут быть разными, и правила могут иметь разную степень обязательности), а с другой — участвуют в системе разделения труда. Ещё есть производители инструментов и потребители результата деятельности. У них всех свои интересы, но все они хотят примерно одного: чтобы им точно не стало хуже, а желательно — стало лучше. Соответственно, вы обязательно столкнетесь с этими стейкхолдерами, если ваша система потребует изменения правил, разделения труда, ослабит или усилит какие-то сообщества, потребует изменения объекта или результата.

Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её). Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются. Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие: 0 слой: сам продукт 1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой 2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей) 3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры Раскладывает стейкхолдеров по типам так: 1 слой ("наша система"): * Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность. * Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт). * Операционная поддержка: так как система включает технику и людей, должно быть две роли — поддерживающая технику и поддерживающая людей. Это может быть служба поддержки и люди, занимающиеся обучением. 2 слой ("содержащая система"): * Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую. * Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях. * Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан. * Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер. 3 слой ("широкое окружение"): * Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта. Он даже предлагает выделять специальную роль: * Враждебный агент. Те, кто совершенно точно станут активно вредить или использовать продукт не по назначению. С определенным уровнем хитрости и креативности. Например, вопросы для любого открытого продукта с хостингом пользовательского видео: как вы будете бороться с порно-контентом, а для продуктов с комментариями или отзывами: как бороться с размещением спамерских ссылок. * Политический бенефициар. Кто получит выигрыш с точки зрения власти, влияния или престижа от создания вашей системы? Мой любимый тип стейкхолдеров. Пользоваться системой они не будут, может быть даже функциональными бенефициарами не будут, а вот власть и влияние их очень интересуют. В государственных организациях (и некоторых крупных бизнесовых) это чуть ли не основной смысл существования некоторых систем, а за контроль над ними ведутся жестокие битвы. Политические бенефициары могут быть и негативными — активно противодействовать созданию систем, или создавать свою альтернативную, или запрещать/затруднять интеграцию. Чем выше вы заходите в управление корпоративными продуктами, тем больше там политики. * Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт. * Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций. * Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны. * Консультант (западная практика, бывает ли в РФ?) * Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен) Вот такая классификация. У меня из головы получилась похожая, напишу следующим постом.

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных. Эта формула имеет геометрический смысл: R×π×e, где R - число требований, число π в этой показывает круг, который нужно пройти для каждого согласования, а число e - скорость, с которой заказчики придумывают новые требования. При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования. В среднем получается ~8.54, что очень похоже на большинство проектов. Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем... Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27. Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия. Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера: e^iπ + 1 = 0. Смысл его прост: если проект долго рос с воображаемыми (мнимыми) требованиями, добавление реального стейкхолдера сводит все предыдущие усилия к нулю...

Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её. И вот что я вам скажу — те, кто её рекомендует, либо сами не читали, либо ничего не поняли. Потому что главный вывод, который можно сделать после прочтения — то, что мы называем системами в ИТ, на самом деле системами не является. Или является ими не в том смысле, в каком их понимают ученые, занимающиеся системным анализом. Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации. Какие тезисы внутри: 🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок. 🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию. 🔸Цель системы, как правило, не выражена явно. Всё наоборот, да? 🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности. 🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих. 🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции. Собственно, дальше вся книга посвящена типам циклов обратной связи (положительному, отрицательному, стабилизирующему), числу этих циклов и их направлениям, времени запаздывания реакции, нелинейность характеристик системы при изменении потоков, накоплению изменений и резкой (катастрофической) перестройке системы, выбору точкам воздействия на системы. В общем, это всё очень интересно с точки зрения внедрения изменений в организациях и обществе, но к ИТ-системам имеет отдаленное отношение. Для ИТ-систем это всё начинает работать, только если мы включаем в рассмотрение команду поддержки и разработки системы — тех, кто как раз получает обратную связь о работе системы и может её менять. Если рассмотреть всё вместе: ИТ-систему, технические средства и команду разработки, а ещё лучше — управленческую и политическую обвязку — то принципы Медоуз начнут работать. Именно в управленческом или лидерском аспекте. Может быть также полезно посмотреть с этих позиций, если вас интересует — как изменится деятельность организации после внедрения какой-нибудь системы. Это уже для правильных бизнес-аналитиков и продактов. А для задач сбора требований и проектирования программных систем книга практически ничего не дает.

Disaster Recovery и Backup решают разные задачи, но их часто путают 😕 Backup сохраняет и восстанавливает данные, а DR — работоспособность всей инфраструктуры. 18 августа на вебинаре эксперты Cloud․ru расскажут, как выбрать стратегию восстановления с учетом требований бизнеса, RPO и RTO. В программе:

▶️что происходит при отказе ЦОД и чем это грозит бизнесу ▶️когда нужны Evolution Disaster Recovery и Evolution Agent Backup ▶️как соотносятся DRaaS, BaaS, репликация и аварийное восстановление ▶️как выбрать решение под ваши требования

Бонусом в парктической части покажут возможности Evolution Disaster Recovery и Evolution Agent Backup на реальных сценариях. Не забудьте зарегистрироваться

Вы используете прототипы интерфейсов? Наверняка используете. Для согласования, например. И чтобы вообще было, что обсуждать. Читать тексты человеку очень сложно, а уж представить себе по тексту, как это будет выглядеть, вообще мало кто может. А если и представит — совершенно не факт, что два человека представят одинаково. Поэтому прототипы часто используются в качестве стимульного материала: чтобы хотя бы начать или предметно продолжить разговор. Нужна визуализация, а ещё лучше — исследование действием. Дайте предмет, поставьте задачу и пусть пользователи попробуют решить эту задачу при помощи этого предмета. А мы увидим, с какими проблемами они сталкиваются. Поэтому, кстати, "просто показать прототип" не работает — нет задачи и нет попытки её решить. В лучшем случае вы получите набор случайных замечаний, часть из которых будет нерелевантна, при этом многие важные вещи будут пропущены. Демонстрацию интерфейсов лучше всего проводить по сценарию и с использованием реальных данных. Ещё лучше, если это будет не демонстрация, а задание: вы не показываете, вы смотрите, как пользователь пытается взаимодействовать с интерфейсом. Но это уже известный метод социологических исследований! И известно даже его развитие — исследование провокацией. Когда вы не просто предлагаете респонденту осуществить какую-то деятельность, а ставите его в некомфортную ситуацию, нарушающую некоторые правила. Так можно проявить базовые установки, в соответствии с которыми действует человек, и от которых он не готов отказываться. Так нам говорит теория соц.исследований. UX-исследования, в сущности, специальная область применения таких исследований. Мне стало интересно — есть ли в UX исследования провокацией? И, представьте себе, есть! Даже термин для этого есть: provotype (provocation + prototype, провокационный прототип). Это как бы доказательство от противного: что для пользователей действительно важно, а с чем они готовы мириться (а может быть, радикальные изменения, на которые никто не мог решиться, наоборот будут удобны!) Провотип всегда делается для исследования и ответов на вопросы. Например, можно исследовать необходимость функций. Что будет, если мы оставим только одну кнопку или одно поле ввода? Что будет, если мы добавим в продукт все функции, о которых вы просите? (реальный кейс, когда стейкхолдерам выдали распечатанные элементы для вызова всех функций, которые они хотели, и попросили расположить эти элементы на одном экране, тоже вырезанном из бумаги). Это вариант преувеличения, доведения до абсолюта: что будет, если ничего не будет? (если убрать всё). Что будет, если это окно развернуть на весь экран, и оно закроет всё остальное? Как будет выглядеть интерфейс, если мы захотим запустить наше приложение на часах? В одной статье описан провотип, который был сделан, как хоумпейдж из 90-х: с Comic-sans, желто-розовый и с gif-анимациями. Это был прототип сайта налоговой службы. В обсуждении быстро стало понятно, что именно тут кажется неуместным заказчикам и пользователям. Это ещё один принцип: не спрашивайте, что нужно и что удобно, спрашивайте — что мешает. В таких вариантах провотипа используется явно неуместный объект, не отсюда. Иногда присутствие такого объекта заставляет задуматься, а так ли он неуместен? Ещё один вариант: против правил. "У нас всегда...", "Система не позволяет...", "Пользователь привык, что...". А что если нет? Что если мы подвергнем сомнению этот принцип, и сделаем наоборот? Близко к этому примыкает тонкий прием, когда в прототипе что-то заведомо неправильно. Например, одна и та же информация представлена в двух вариантах, без какого-то объяснения. Исследователь фиксирует — а заметил ли вообще это пользователь, и какой вариант лучше? Возможно, информация неконститентна (и это специально). Многие дизайнеры вообще не следят за консистентностью, и иногда это можно обратить на пользу. Например, однажды дизайнер нарисовал интерфейс, в котором у ученика 6-го класса были выведены результаты ЕГЭ. Ух, мы много новых требований вытащили из этого прототипа!

За летними делами пропустил историческую новость: в протокол HTTP добавили новый метод! Не каждый день бывает. Добавление свежее, июньское, RFC 10008. Статус у него — Proposed Standard, но с таким статусом множество технологий живет, это значит — в целом норм, можете уже реализовывать в своих системах. В Nginx новый метод уже поддерживается. Называется этот метод QUERY. используется он примерно так:

QUERY /products/search HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
q=distributed+systems&category=books&min_year=2025&sort=relevance

То есть, это фактически официальный GET с телом. Проблема была в чем: если вы хотите найти что-то по сложному условию и множеству параметров, можно использовать GET, но параметры поиска можно передать только в строке запроса. Тела запросам GET не положено — его можно передать, но сервер или любой промежуточный узел может это тело проигнорировать и дальше не передавать. Строка запроса обычно ограничена по длине, есть даже специальный код ответа 414 URI Too Long. GET безопасный, идемпотентный и кэшируемый. POST небезопасный, неидемпотентный и не кэшируется. Зато у него может быть тело большого размера. QUERY объединяет самое лучшее: он идемпотентный, безопасный, может кэшироваться и содержать тело. Заодно не оставляет следов в логах (что там было в теле — не видно). Так что если ваши запросы были слишком специфичны — теперь для них есть специальный механизм. В каком именно формате вы будете передавать запрос в теле, стандарт не задает, но требует, чтобы вы явно указали это в заголовке Content-Type. Там есть всякое интересное: application/x-www-form-urlencoded — это строка запроса из URL application/sql — SQL-запрос (вот так, прямо через REST API) application/jsonpath — для вытаскивания специфических данных из JSON application/xslt+xml — то же для XML application/graphql — запрос в формате GraphQL application/sparql-query — запрос в формате SPARQL и т.д. Можно спросить у сервера, в каких форматах он готов принимать запросы (он ответит в заголовке Accept-Query). Можно ещё добавить Accept, то есть, например, в одном эндпоинте передавать простые запросы через строку, а для сложных переходить на SQL (теоретически), и получать ответ либо в JSON, либо в CSV (если сервер умеет). Всякую интересную логику можно реализовать. Сервер может даже создать новый ресурс, содержащий результат выполнения запроса! Как явный кэш, или как снэпшот на определенное время. Вернуть ссылку на него клиенту в заголовке Content-Location, а дальше к нему уже можно делать обычный GET. Сам QUERY при этом остается безопасным — новых ресурсов при повторных вызовах создаваться не будет. Вот такая штука. Слышали уже? Планируете использовать?

В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано! Я, честно говоря, даже немного опешил. За 28 лет я с такой культурой встречался, пожалуй, только раз — в одном государственном проекте, где всегда нужно было думать, что и кому ты говоришь, взвешивать слова и понимать, кому твои слова будут переданы и в каком виде, и как будут использованы (скорее всего, с целью навредить). Долго я там работать не смог, естественно. Вообще не представляю, как работать в среде с низким уровнем доверия. Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜ безразличие к результатам. Как любая вертикальная теория, эта пирамида описывает всё в упрощенном виде, но сами по себе эти "пороки" я вижу в командах очень часто. Конечно, всё не так просто, и научные модели дают более комплексную картину. Например, сами по себе конфликты могут быть и продуктивными, и деструктивными. Умеренные конфликты по поводу выполнения задач, или "конфликты идей" наилучшим способом оказывают скорее полезное влияние на общий результат (к таким конфликтам относятся разные взгляды на выбор технологического решения, например). Затяжные "процессные" конфликты скорее вредят (конфликты, связанные с логистикой задач и данных, процедур принятия решения и распределением ответственности). Межличностные конфликты вредят в любом случае (сюда же относятся конфликты целей, норм и ценностей). Конечно, мы исходим из предположения, что у всех членов команды одна общая цель или цели хотя бы взаимосвязаны — если выиграешь ты, выиграю и я, без этого конфликты вообще сложно решить. Ещё важно, кто во что верит и как оценивает ситуацию — как win-win, или как win-lose. Особенно удивительно видеть, когда представители бизнес-заказчиков начинают бодаться с разработкой, рассматривая этот конфликт как win-lose. В отдельных случаях встречаются даже персонажи, находящиеся в парадигме lose-lose: "Ура! Всем плохо!". Источники конфликтов тоже разнообразны: - проблемы в коммуникации (слишком редкая, слишком нерегулярная, перегружающая, неправильно выбранный канал / время / форма / тон, недостаточно контекста, недостаточно прямая); - неверный выбор основы власти или стиль управления (принуждение или стимулирование, нечеткие границы и двусмысленные требования); - культура организации (поощрение личной конкуренции, а не кооперации) - недостаток координации, знаний и сплоченности (члены команды не понимают, зачем они работают, и изолированы друг от друга) Если помножить это на внешние факторы, связанные с недостатком ресурса или неопределенностью, ситуация становится взрывоопасной. Факторы внешнего давления: 1. Проекты с высоким риском / ставками 2. Двусмысленные, плохо разграниченные роли и области ответственности 3. Несколько начальников с противоречивыми требованиями 4. Использование сложных технологий с запутанными связями 5. Нереалистичные сроки 6. Недостаток ресурсов 7. Недостаточное финансирование 8. Некомпетентное руководство Получился пост больше для руководителей и лидов, но и линейные сотрудники могут себе составить представление о том, чем там таким всё время занимаются лиды фуллтайм. А вот этим они и занимаются. Анализом ситуации, в которой их подразделение или команда оказалась, перемножением причин и факторов, и выработкой программы действий, чтобы снизить их влияние и в команду поменьше прилетало, чтобы она спокойно работала, без раздергивания внешними угрозами и без накопления внутренних нерешенных противоречий. Хотите ли вы и умеете ли этим заниматься, вот вопрос.

Команда GigaChat зовёт на вечеринку для AI-разработчиков и исследователей 🎉 29 июля, Сбер.Среда, пространство «Оригинал» (м. «Курская», ул. Земляной Вал, 9А) Без докладов, презентаций и официальных дискуссий – только общение с коллегами по индустрии, обсуждение рабочих задач и болей, новые знакомства и летний вечер на веранде. Регистрация и подробности Надеемся на хорошую погоду 🥳 До встречи!