Я — Максим Цепков приветствую Вас на своем сайте
Now: Коммуникация при различной структуре мышления - таксономия против фолксономии
|
Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте или OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 742 статей IT-тематики. | |
Последний пост блогаВ пятницу 27.03 заглянул на конференцию технических писателей Tech Writer Days. Конференция двухдневная, но у меня получилось только один день, делюсь своими впечатлениями. Я на этой конференции первый раз, хотя это – уже третья конференция. Три трека, два дня. Я с удовлетворением хочу сказать, что этот новый проект Влада Орликова вполне успешен. Сообщество технических писателей получило свою конференцию. Общие впечатления: DocsAsCode и ИИВообще вопросами организации документации в практическом залоге я занимался очень давно, в конце 90-х, когда еще не существовало вики-систем. Мы тогда для наших проектов делали систему ведения документации в разметке sgml (это предшественник html), которая позволяла вести документацию в текстовых файлах под системой контроля версий, а также собирать с одних исходных текстов word (rtf) для печати и гипертекст html-chm, который использовали как справку по системе. Сейчас этот подход называется docs-as-code и является основным, хотя часть команд продолжает использовать вики-системы, а кое-кто по-прежнему предпочитают word. Впрочем, про word замечу, что основной вопрос не к команде проекта, а к заказчику. Если он хочет работать с word-файлами, да еще активно проходиться по ним в режиме редактирования, то doc-файлы наиболее эффективны. Вообще к выбору способа документации надо относиться прагматически. У меня по этой и смежным темам было выступление на TeamLead Conf Управление знаниями: какие документы нужны и что в них фиксировать. Тема docs as code – одна из основных на конференции, и я послушал пару докладов о современных средствах ведения такой документации – MkDocs и Hugo. И на одном из них увидел, что идет не просто изменение технических средств, а об изменении задач бизнеса по отношению к документации: документация превращается в информационный портал, бизнесу важно видеть метрики использования и проводить A/B-тестирование. А еще в одном докладе речь в нем шла о том, как дешево включать в документацию видео – современные технологии это позволяют. Заметим, что подход docs as code тут является рамкой: видео делают для маленьких фрагментов, где это востребовано, и обновляют по необходимости. Отмечу, что среди выступлений про docs as code получилась забавная пара: Денис Лимарев, рассказывая про MkDocs, сказал, что его вдохновило на это выступление Никиты Груздева на предыдущей конференции, а Никита Груздев рассказывал, как они переходят с MkDocs на Hugo из-за требований бизнеса к возможностям тестирования A/B-тестирование документации. А основная тема этой конференции для меня было использование ИИ. Я с удовлетворением хочу отметить, что, несмотря на кликбейтные заголовки о замене людей ИИ-агентами, содержание доклады вполне прагматично: люди оценивают возможности использования LLM-систем и включают их в рабочие процессы там, где это уместно. Я это отмечал еще на осенних конференциях SQAdays, Highload, ArchDays и Teamlead и AnalystDays (ссылки ведут на мои отчеты). И это – радует. Потому что еще летом такого однозначного впечатления не было, и прагматичные доклады перемежались с рассуждениями о полной замене людей и другими подобными темами, популярными в инфополе. Вообще, когда я в октябре был в китайских технологических компаниях (Baidu, Xiaomi, SenseTime и других) меня сильно поразила разница в отношении к ИИ там и у нас. Об этом я писал в отчете, а на днях опубликовал статью на habr «ИИ не конкурент, а помощник и друг – китайский опыт» с подробным анализом. Если тема Китая интересна, то в статье есть ссылка на отчет о поездке. Выступления про ИИ-агенты навели меня на следующую мысль. Каждый раз, когда мы делаем ИИ-агента, мы меняем систему разделения труда. Эта система имеет два измерения, одно – горизонтальное, это всем известный workflow выполнения работы. А другое – вертикальное, касается методов проектирования workflow и порождения необходимых для этого знаний. Например, если мы вставляем шаг code review для того, чтобы обеспечить лучшее качество кода, то нам надо договориться о том, какой именно код считаем качественным, выработать политики, чтобы code review не превратилось в поле битвы между сеньорами, представления которых о прекрасном коде сильно различаются, а также зафиксировать цели, чтобы review не превратилось в карго-культ. Тоже самое касается и работы архитекторов, и внедрения автотестов и встраивания ИИ-агентов. И вот про вертикальную составляющую системы разделения труда отдельно не говорят, часто полагаются на здравый смысл, а в результате – наступают на грабли типовых ошибок. Поэтому, думаю, будет востребован один или несколько обзорных докладов на эту тему – она мне знакома. Особенно имея ввиду ситуацию с ИИ, который, в отличие от людей, по умолчанию пассивен: не рефлексирует собственную работу, и не поднимает вопросы ее осмысленности. Хотя его можно об этом отдельно спросить. Ну а теперь я закончу с общими впечатлениями и перейду к докладам. Я их привожу не в том порядке, в котором слушал, а по темам: сначала ИИ-агенты, потом – Docs As Code, заем – остальные. Камила Мазаева из Альфа-Банк. Кому доверить ревью API — техпису или искусственному интеллектуСсылка Кому доверить ревью API — техпису или искусственному интеллекту. Реально доклад был о встройке ИИ в workflow процесса подготовки и публикации документации в качестве отдельного шага – промежуточного ревью, в ходе которого проверяется убирается ряд технических проблем. В результате разгрузились технические писатели, ревью которых стало узким горлом с ростом числа команд, а аналитики, которые у них готовят документацию, стали получать обратную связь за минуты, не ожидая, когда технический писатель освободиться, и это ускорило процесс в целом. Естественно, этой встройке предшествовало исследование о возможностях ИИ-агента и его настройка с помощью промптов, с проверкой на наборе тестовых кейсов, в роли которых выступали ранее выполненные ревью человека. Агент сделан на основе AlfaGen – LLM, развернутой внутри Альфа-банка, что снимает проблемы безопасности. А теперь подробнее. Речь идет про OpenApi в формате yaml, ошибки и неточности в нем критичны, так как смежные команды опираются на описания при интеграции. У них был следующий workflow публикации описаний API: аналитик готовит черновик, техпис проверяет на соответствие требованием и стилям, а также по содержанию, например, по соответствию описаний ошибок назначению API в целом, потому что очень часто при копировании забывают что-то поправить, одобряет или возвращает для доработки, а после одобрения – публикация. Почему workflow именно такой, она рассказывала на одной из прошлых конференций. С ростом числа команд ревью техписом превратилось в узкое горло, так как ревью – не единственная его задача. Основное у него ведение документации в целом: общие вводные страницы и реструктуризация. И они решили провести исследование, в какой мере ИИ может помочь техпису, а, возможно, вообще заменить его на этой задаче. ИИ «из коробки» – как стажер-редактор, который умный, потому что прочитал все на свете, но при этом у него нет своего мнения и опыта в конкретном проекте, и он часто притворяется. И prompt – способ описать свою модель, дать ему свои правила, поставить задачу. Это мини ТЗ технического писателя. И они дали на ревью ИИ действующие черновики параллельно с их ревью техписом. Промпт: роль – Техпис в банковской сфере с опытом больше 10 лет, глоссарий терминов, стилистический гайдлайн и конкретные задачи по проверке: орфография, пунктуация, json-схемы, соответствие между видами кодов (успех-ошибка и его описание). Он длинный. Протестировали два подхода к промпту: негативный – только выдать ошибки, и второй – привести в соответствие к стандарту, улучшить. По результатам сознательно отказались от варианта, когда ИИ переписывает документацию. Потому что если он полностью переписал – очень сложно выверить, результат, а он может не только улучшить стиль, но и внести при этом ошибки. Поэтому ИИ выдает отчет – список ошибок, где указан уровень критичности, место ошибки в описании, описание проблемы и предложения по исправлению. Предложения по исправлению для многих ошибок очевидны, но вот когда изменяется style guide, они существенны. В AlfaGen создали агента с промптом, и дальше любой может создать чат с ним. И дальше сравнивали результаты для трех вариантов работы: только техпис, ИИ, и ИИ и техпис вместе. Метрики сравнения: граматика и орфография, читаемость (короткие предложения и простые слова), стиль и консистентность, полнота, скорость. Что получилось? Скорость возрастает 10-30 раз. Хорошо обеспечивается формальная корректность – орфография, пунктуация, забытые параметры, единый вид. Особенно важно – всякие английские слова, где люди часто делают ошибки. В презентации есть таблица. Где ИИ уступает?
Доработать промпты, чтобы увеличить контекст, можно, но получается, что надо постоянно дописывать этот промпт, потому что контекст меняется. Примеры из практики.
Похтому получился такой процесс: аналитик пишет черновик, отдает ИИ-стажеру-редактору, далее аналитик исправляет то, что считает нужным, и отдает техпису, который делает финальный апрув. В результате загрузка техписа изменилась от 30-120 минут до 10-30 минут. По качеству – стало не хуже, а местами – лучше. Профит: не нужно несколько циклов с доработками на ревью техписа. Рекомендации понятны: Экспериментировать, Стандартизировать – для промпта будет нужно, Интегрировать в действующий workflow, не просто экспериментировать, Обучать команду, включая внешних. Ответы на вопросы в тезисном виде.
Я хочу сказать спасибо за доклад. А еще? емея ввиду передачу ИИ большого контекста и обучение его решению задач по сложным правилам, хочу рассказать интересный кейс. Анатолий Левенчук с июня 2025 года дорабатывает системный подход, чтобы он стал применим для личности и сообществ. И делает это с помощью ИИ-агентов, и чтобы они эффективно работали, потребовалось сначала их самих научить современному системному подходу – по умолчанию у них всплывает версия 1960-х, потому что она наиболее распространена. Метод – описать правила системного подхода на английском языке, при этом не разговорном, а в стиле промышленных стандартов – ИИ с этим хорошо работает. Уже осенью в процессе работы был получен результат, который начал использовать не только сам Анатолий, но и другие люди из сообщества для обсуждения своих проектов. Система правил – большая, более 2 млн знаков, но ИИ подхватывает. Так что можно использовать этот опыт, и в для вашей области: Анатолий достаточно плотно описывает, как именно он работает, в своем блоге, так что можно посмотреть на метод работы и на организацию правил. В декабре я был на семинаре у Анатолия, и в моем отчете есть опорные ссылки для тех, кому интересно. Александр Яковлев. Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex CloudМасштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud Это рассказ о том, как делали агента, помогающего писать документацию. И об архитектуре конструкции агента – тем, что лежит между системным промптом и промптом, который пишет пользователь, и снабжает агента необходимым контекстом для эффективного применения в рамках конкретного проекта. А мотив, который побудил Александра заняться этим был таков. За время вдоха-выдоха подготовленный агент пишет статью. И потому надо возглавить процесс использования агентов, а не ждать, когда сделают за тебя. Гипотезы
Документация у них объемная на GitHub, для нее применяют стандартный GitFlow. Пока агента запускают вручную. Но они ждут переезда на свою платформу хранения, чтобы запускать в репозитории. Правила использования.
Первоначально была идея сделать библиотеку промптов для разных задач. Но она себя не оправдала, потому что промпты получались громоздкие, с большим количеством повторений. В результате выросли промежуточные уровни и получилась архитектура агента с такими слоями.
Метрики для оценки эффективности: время автономной работы, уменьшение количества исправлений – вмешательство человека. И упрощение промптов – экономия когнитивного ресурса человека, которая обеспечивается наращиванием промежуточных уровней. Вызов: где агент даст реальный выигрыш? После экспериментов остановились на нескольких направлениях создания структурированной документации: описание справочников, пошаговые инструкции, разделы в обзорных статьях. В них можно ожидать предсказуемости. В разных руках агенты работают по разному. Есть мнение, что агент – джун. Нет, Агент – усилитель навыков человека, и он будет настолько хорош, насколько человек хорошо ставит задачи. Впрочем, я тут не вижу противоречия: эффективность работы джуна тоже сильно зависит от его наставника. Документацию надо не только создавать, но и обновлять. Есть ряд сигналов.
Еще есть интересная задача – анализ актуальности документации. Уволился человек, работавший в базами данных. Нагрузка распределилась, обновления пошли хуже. Предложил агенту сверить документацию с актуальным кодом и ответами продукта в консоли. Решение потребовало 1.5 млн токенов для анализа истории за год. Выявлены проблемные точки, что-то правили агенты, что-то – люди. Агент может проводить анализ исходников: ссылки, метаданные, формулировки, схемы. Все не бесплатно. Модели снаружи – все больше типов промптов, которые тарифицируются по-разному, от типов токенов – вопрос, ответ, поход и в интернет. В собственном контуре есть затраты на железо, инфраструктуру, работу людей. Примерный цифры в токенах. Создание инструкции – 50 тыс. (при том, что правила – 20 тыс.) Работа с разделом – ограничена контекстным окном, 150 тысяч. Новый проект (новый справочники, переписать доку, убрав недоступные снаружи – 200 тысяч и больше) Внедрение – состоялось. Агенты могут создавать и обновлять определенные типы документации, они ускорили рутинные операции в разы. К гипотезам. Агенты не могут создавать всю документацию, но разрыв уменьшается. Промптыов он писал много, но сейчас пишет все меньше, снова переключился на доки, то есть уже промптов наработал достаточно. На первый план после промптов и моделей пришло другое – настройка контекстов, правил и так далее. По поводу прогресса как беспокоился, так и беспокоится. Что недоступно?
Я подозреваю, что над этим просто не работали. Потому что эмпатия ИИ вполне доступна, есть исследования, что пациенты оценивают ИИ-психологов как более эмпатичных, чем людей, есть кейсы создания ИИ-агентов для конкретных задач, например, для работы с зависимыми людьми. И про проблемы пользователя можно спросить, версии агент может порождать, если ему описать контекст и сформулировать вопрос. И спросить тоже может, пусть не голосом, а через мессенджер – если научить. Потому что делают агентов, которые напоминают и договариваются о проведении встреч, и ничто не мешает делать это по условным правилам. Агенты – работают. Поддержка агентов требует ресурсов, там много задач, которые скучные по сравнению с промптопитанием. Работы меньше не стало, просто делает больше, а число висящих на нем тикетов снизилось на 10%. Никита Авилов. Сам себе редактор: ИИ для вычитки текста и локализацииСам себе редактор: ИИ для вычитки текста и локализации Выступление было о практическом опыте – как использовать ИИ для вычитки текстов и локализации. Но в начале было немного ликбеза. Чат-боты порождают ответ слово за слово, на цепи Маркова. T9 подсказки, без истории. Чем меньше корпус данных – тем менее точный результат. Промпты – добавляют конкретики. Роль + Задача + Формат, Роль + Контекст + Задача. Не просто «переведи это», а «ты редактор перевода по промбезопасности, проверяешь переводы, проверь такой перевод и ответь одним словом, верно или неверно». Но промптов недостаточно, надо использовать агент-подход, добавлять информацию – док и данные. Режим агента – ИИ не просто отвечает, а погружается в контекст и действует самостоятельно. Ты не просто задаешь роль, а полноценно формируешь персонажа. Например, рассказываешь про целевую аудиторию приложения и так далее. RAG – web-поиск и поиск по базе знаний – он ходит в источники, добавляет информацию к запросу и генерирует ответ с ее учетом. С чат-ботами можно
Не рекомендуется искать информацию и факты – может быть много галлюцинаций и неточностей. «Как зовут жену Ильяхова?» – «Людмила Сарычева», хотя она лишь соавтор. Ollama – там много моделей, которые можно развернуть у себя. И установить клиента. Собственный ИИ-сервис – добавили многие модели. Большой плюс – можно создавать папки, где задаем системные промпты для каждого проекта, и можно выбирать разные модели. Можно описать продукт, описать редполитику, дать инструкции по поиску. Для техписателей. Проверка стилистики, создание описания терминов, генерация изображений – диаграммы с объяснениями. Описание термина – выделили слово и получили определение на основе контекста статьи. И генерация uml-диаграммы на основе plantUML. Получается неплохо. Модели интегрируют в системы разработки, например, разработки документации: выделить текст, и запустить промпт на него. Как сейчас в браузере – «объясни». В промпте описываешь: организация оформления, особенности стиля и единообразие Проверять на целый стайл гайд – не особо получается, потому что нет критериев, что ИИ весь гайд взял. Если проверяешь по отдельным статьям (оглавления, синтаксис и так далее), то рекомендации хорошие. И весь документ тоже не проверяется, надо выделять смысловые кусочки. Подключить модель к глоссарию – пока не получается, но пробуют. Что актуально сейчас – проверка русского текста на англицизмы и заимствованиями, имея ввиду новые законы. Но они не делали промпт на основе законов, а используют общие знания ИИ. Сценарии для локализации. Есть плугин для Chrome и SmartCat. Можно переводить, и проверять. Но локально, без учета контекста и глоссария и памяти переводов. Удобно переводить на третий язык. Английский, русский, немецкий тоже примерить. У них есть лингвистические автотесты – спеллинг, качества текста и так далее. Редактура с чат-ботом снимает число инцидентов. Вычитка на статью 2 тыс знаков сократилась вдвое 30 минут – 15 минут, локализация тоже вдвое, при этом качество релизов возросло. ИИ не создает нового и не принимает решения. Он не заменит писателя, но умение его интегрировать в flow повысит ваш скилл. Как раньше умение работать с компьютерами. Денис Лимарев. Имбовый портал документации на MkDocs: Markdown, Docs as Code и CD. Что сегодня и что завтраИмбовый портал документации на MkDocs: Markdown, Docs as Code и CD. Что сегодня и что завтра Фишка их технологии использования – локальный сервер сборки mkdoks – в контейнере на своей машине – ты правишь файлы, он это отслеживает и в онлайн показывает. А вообще на использование MkDocs Дениса вдохновило выступление Никиты Груздева. Дальше – тезисно про использование, что я успевал помечать.
Никита Груздев из VK Tech. Особенности национальной миграции с MkDocs на HugoОсобенности национальной миграции с MkDocs на Hugo Миграция с MkDocs на Hugo была вызвана бизнес-требованиями.
На этом преимущества Hugo заканчиваются, и начинаются недостатки. MkDocs – это Python, открытое большое сообщество, там есть много готовых решений, а Hugo – Golang, закрытое сообщество, все делают сами. Не хватало функционала, который они использовали - Печатные формы – не было - Автор и дата обновления документа - Открытие картинок по клику – там скрины, их увеличивать надо - Единый источник – его не было, а тут заявзка - Hot reload и быстрая локальная сборка – это было Однако, у Hugo из коробки есть много тем, а в MkDocs, по факту, одна, остальные для фана. И Возможности кастомизации выше, можно внедрить свои компоненты. В MkDocs для этого надо делать свою тему, а это очень дорого. У них была своя команда разработчиков Hugo, и они были уверены, что необходимое докрутят. Перед решением они оценивали, сколько займет доработка Hugo и MkDocs. По Hugo получили 2 человеко-месяца. А в MkDocs получался исследовательский проект, потому что бизнес-требования он не поддерживал. Поэтому и приняли решение. Какие были проблемы.
Разработка – сделала. И печатные формы в pdf тоже сделала. Так что главный вопрос для переезда – есть ли у вас команда, которая все сделает. Найти готовое не реально. Ольга Стрельцова. От кастомизации ПО к кастомизации документации: видеоинструкции для уникальных решенийОт кастомизации ПО к кастомизации документации: видеоинструкции для уникальных решений Компания, где работает Ольга, выпускает микроконтроллеры. Их используют в станках, разных стартапах, а также для разных хобби. При этом они заказывают какие-то индивидуальные характеристики, которые обеспечиваются при изготовлении и в прошивке. И для всего этого нужна документация. При этом есть тонкость: микроконтроллер встраивают в устройство, например, в станок, квалифицированные инженеры, владеющие техническим языком и умеющие понимать сложные технические документы. Но дальше пользователями этого устройства являются конечные потребители, например, простые рабочие. А микроконтроллер не полностью скрыт, с ним надо выполнять технологические операции, настраивать конфигурацию, которая будет влиять на работу устройства. Как это делать, зависит от прошивки, и с новой версией прошивки способ действия может измениться – надо поддерживать актуальность. Инструкции должны быть написаны на доступном для них языке – просто, мало букв и так далее, как сейчас привык массовый потребитель. Да и инженеры сейчас тоже поменялись. Это инженеры старой школы умели читать длинные инструкции и находить. А теперь поколение тиктока, которые не читают. Все они начинают писать в техподдержку, техподдержка загибается. И техподдержка тоже не читает документацию, там тоже новое поколение. Когда-то была идея, что надо сделать видеоинструкции. Но это отложили, потому что дорого. А теперь достали, появились новые технологии: снять можно смартфоном, многое обработает постпрдакшн – ИИ рулит. И обновлять можно быстрее. Но от документации не отказались – у видео нет полноты и точности техописания, полное видео все равно дорого. Сделан гибрид: есть док, и есть видео по точечным, самым больным моментам, именно на них снимают. Видео – не end-to-end, это длинно, никто не досмотрит. Пишем шаги, а внутри – маленькие порции видео. Длительность одного ролика – до минуты, больше человек не запоминает. Если какие-то изменения затрагивают болевые точки – видео обновляем. Но ролики короткие, и эти точки меняются редко. Как это делают?
ИИ.
Снимают метрики: сколько раз пришли, посмотрели ли до конца, опросники, благодарности суппорта. От техписа требуются новые навыки, чтобы все это сделать: сценическое мастерство и другие. И техпис эволюционирует. И оценка не по числу страниц. Эксперименты стоит поощрять. В презентации есть ссылка – весь доклад в одном рилсе. Там меньше минуты на 15-минутный доклад. Антон Жуков. UI Kit как источник истины: путь от макета до продуктаUI Kit как источник истины: путь от макета до продукта Сложность больших продуктов – постоянные мосты: между разработкой и бизнесом – решение общих задач, между бизнесом и интерфейсами чтобы не было красивой картинки и между интерфейсами и разработкой Первоначально – был флагманский продукт с сильным дизайнером. А потом в департамент приехала легаси-платформа, которую предстояло разделить на три новых продукта: бизнес-метрики, А/B эксперименты и работа с гипотезами. Вместо одного продукта – 4. И в одном современный интерфейс, в остальных – старое. Есть перспектива продуктов будет больше. Если действовать старыми методами, то все расползется, каждый продукт пойдет по-своему. Они поймали проблемы заранее и решили ,что нужен единый источник истины для разработки всех продуктов, этим источником стал UIkit – единая дизайн-система, о ней и был рассказ. Какие были требования? Консистентность, Масштабирование, Единый источник истины и Общий язык – для аналитика, разработчика, документации. Консистентность – единый стиль для всех продуктов линейки. И готовые кирпичики для новых продуктов, чтобы сосредоточиться на бизнес-логики. Источник истины – уважаемый стандарт. Общий язык – для аналитика, разработчика, документации. Первая боль разработчиков: одни и те же компоненты переписывают несколько раз. Идея написать однократно и все проработать. С ней пришли к дизайнерам, они тоже устали от рисования одного и того же. И техписы – процесс сбора терминологии, место четкой документации, и можно делать стандарты. Основа UIkit – Storybook, стек – react и figma. Storybook – витрина компонентов, каталог, в котором про каждый элемент можно во всех вариациях посмотреть, какой он бывает. Это полигон, где разработчик может отлаживать компоненты: как ведет себя кнопка загрузки, как показывают пустую таблицу или таблицу где 100к строк. И там же можно описывать use case. B это – мост к дизайнерам, компонент можно привязывать к фрейму в фигме и сравнивать как работает на макете и внутри. И все это можно сделать до того, как улетит в прод. Внедрение Storybook потребовало усилий.
В Storybook – код снипится. Разработчику не надо искать примеры в коде, он может увидеть реализацию любого компонента и скопировать. Есть встраивание в фигму – можно вставить компонент, и иметь навигацию. И наоборот, можно компонент фигмы вставить в storybook, и проваливаться в него. Получается сквозная навигация: фигма и ссылка на конкретную ноду story book. Процесс. Конкретный вариант design review. Длинный процесс: бизнес-требования и задача в jira, ux-исследование конкурентов, проектирование дизайна, технический эпик – разработка, когда готово – проверка дизайнером на соответствие макетам, а продукт по бизнес-требованиям, финальная тестирование и релизы, потом мониторинг результатов.
Роли в системе.
В презентации были скрины – примеры компонентов и фич. Очень помогает внутренний блог с сообществом. Они пишут, какие процессы, как решались конкретные задачи и так далее – чтобы другие внутренние команды брали опыт. Коллеги – читают, и это облегчает онбординг, и приносят новые идеи по улучшениям. А еще блог оставляет следы решений. Елена Стеблюк. Внутреннее продвижение базы знаний: от справочника до культуры работы с информациейВнутреннее продвижение базы знаний: от справочника до культуры работы с информацией Компания edna создает продукты для уведомлений: запись к врачу, смс от банка и так далее, она там работает несколько лет. База знаний досталась по наследству, туда практически никто не заглядывал. До edna она работала в superjob, там базу знаний активно использовали. Она пошла к пользователям, они говорят: не удобно, долго, ответа не будет, проще пойти к коллеге или в чате спросить. Но из ее опыта результат – ошибки, снижение качества и другие потери. И потому начала работать над исправлением ситуации. Получается успешно, в выступлении делится опытом. Пользователи – менеджеры по продажам и поддержка. Им надо с минимальными затратами получить ответ. Их пользователи вообще не любят многобукв. Что надо? Актуальный контент. Приятный визуал, форматы, понятный процесс работы с базой, помощь и обучение. Как она двигалась?
Они изучили как пользуются, выслушали ожидания, выписали разрывы сделали предварительный план. И пошли работать над контентом, делают статьи понятнее, в презентации был пример – преобразование статьи из текста в схемы. А параллельно провели – первое обучение. Обучение записали, и отдали с инструкциями тому, кто отвечает за онбординг. И начали интегрировать в разные точки внимания. Сейчас – работа продолжается. Тут был кейс – вечно занятый руководитель принес контент. Оказывается его настолько часто начали спрашивать по работе с соцсетями, что он записал инструкцию. Активное общение с пользователям дало проблемы. Например, выяснили, что во многих описаний продуктов не хватает продажной специфики – целевая аудитория и так далее. И начали добавлять. Какие на этом пути возможны ошибки? Нельзя думать, что можно обновить один раз и отпустить на свободу, это – постоянный процесс. И нельзя доводить за крайности, когда эксперты просто шлют ссылку на базу знаний, надо общаться с пользователями. Актуализация базы – больной вопрос. Тут они работают по ключевым точкам. Например, при выходе ключевых фич для менеджеров проводится обучение, и к обучению обязательно должна быть готовы материалы по этим фичам. Семён Факторович из documentat.io. Пора классифицировать работодателейПора классифицировать работодателей Выступление Семена включало две части.
И каждая из частей включала предложения услуг documentat.io, адресованных тестировщикам и направленных на развитие иституализации профессии. Для меня – открытый вопрос, как к этому относиться. Потому что, с одной стороны, это – реклама услцуг конкретной компании. Но, с другой – компания претендует на почти институциональную позицию для профессии техписа, и если это признать, то это уже не реклама, а информация. Почему идет сокращение ИТ? У них интересный ответ. Тренд начался еще в 2023 году и не в России – Америка, Европа. Причина – сдувание ковидного пузыря. В ковид многие увидели, что ИТ можно нанимать на удаленку дешевле, чем в офис – не только зарплата, но и помещение и компьютеры не нужны. И начали увеличивать штат при том же бюджете. В 2023 это начало сдуваться. Так что они видят такой сценарий развития будущего: ИИ профессии не угрожает, но спрос пока невысок и не увеличится, поэтому компании буду более требовательны. Это – не предсказание: бизнес не предсказывает будущее, а выбирает сценарий развития рынка или несколько, а дальше исходя из него строит стратегию и планы в ее рамках. Если их сценарий верен, то сейчас для всех хорошее время подумать над повышением ценности и видимости на рынке. А еще подумать о своем резюме: HR сейчас анализируют предложения с помощью ИИ, и уже потом смотрят сами, и резюме стоит формировать с учетом этого. И тут у них есть предложение. По их оценкам, Documentat – марка качества. Даже если ты не работал, а просто проходил курс или проходил собеседование, но не попал. Поэтому они решили провести эксперимент, который даст возможность любому упомянуть Documentat в резюме, чтобы повысить ранг. Два варианта сертификации. Первое – «пригодность к найму в Documentat» – mock-собеседование, свидетельство техписательской годности. Второе – сертификат на профстандарт, это будет по-взрослому, с тестами. При этом в профстандарт заложено много специализаций в рамках профессии, так что дополнительно вы узнаете свой профиль. Тут вот что интересно. В ряде компаний сейчас для повышения зарплаты предлагают пройти собеседование и принести офер, и тогда они сделают контр-офер. Достаточно ли будет собеседования в Documentat для этого? Теперь про результаты опроса. На 02.2025 медиана 140к, в 02.2026 – 150к, прирост выше инфляции, и это – хорошо. Когда показываешь такую медиану, то есть две реакции: «а что так мало?» и «а что так много?» И Они решили посмотреть распределение. Выборка дает вилку 40-380, при этом распределение – сложное, с несколькими пиками. Для таких распределений есть способ исследования – представить его как сумму нормальных. Было исследование зарплат программистов в Европе, США и Индии – обнаружили, что там сумма трех нормальных с медианами 1к, 2к и 3-5к евро. Предположение, что это отражает зарплаты в трех категориях компаний: локальные компании, федеральные (Европа целиком) и бигтех. Но это – лишь предположение, так как респонденты не указывали компанию. Зарплаты техписов в России – сумма двух нормальных горбика: медиана 133 тыс (40-225) и медиана 235 тыс. (80-380), первая категория вдвое гуще, чем вторая. В чем разница, понять не получилось, потому что конкретную компанию респонденты не называют, только ее характеристики. Было много гипотез, которые не подтвердились: это не столица – регионы, не ИТ – инхауз, не государственная – коммерческая, не квалификация джун-сеньор или число лет работы. Данные не позволяют определить в чем разница. У них возникла гипотеза: разница в том, насколько бизнес понимает ценность документации. Там, где понимает – он строит зрелые процессы, делает комфортную работу писателей и ценит их труд. Но это лишь гипотеза, данными не подтверждено. И это породило вторую идею – сделать компаниям аудит, чтобы оценить зрелости документационной культуры. Будет сертификат как лычка. Впрочем, из зала было возражение: а зачем компании это надо? Чтобы кандидаты видели лычку и просили вдвое больше? У меня, если честно, большие сомнения в этой гипотезе. Не знаю, как с техписателями, но по разработчикам и тестировщикам я знаю, что кандидаты от некоторых работодателей просят больit в полтора-да раза «за политику», которой приходится заниматься – компенсируют таким образом будущий стресс, на который идут сознательно. И со зрелостью процессов это не связано, потому что политика обычно включает в себя еще и бюрократию. Конечно, в компаниях-то считают, что это не бюрократия, а «высокая культура формальных согласований», отражающая зрелость процессов, но у кандидатов – другое мнение. Может, и тут дело в этом. А вторая моя гипотеза – что есть компании, где перед техписами стоят достаточно простые, регулярные задачи, а есть – где высокая сложность или неопределенность. Во второй придирчивее отбирают и больше платят. При этом квалификация не нормирована, в обоих типах компаний есть джуны-мидлы-сеньоры, чтобы обеспечить карьерный рост. Косвенное подтверждение гипотезы – что ситуация, когда в одной компании ты сеньор, а в другой – джун или чуть больше – относительно типичная. По поводу идей сертификации из зала прозвучал вопрос: а не становятся ли таким образом техписы на тот печальный путь, которым идут учителя и ряд других профессий, где государство это все сделало обязательным и взяло в свои руки. Семен этого точно не хочет, и обещал подумать, как этого избежать. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация открывает новые возможности развития, поэтому создавая ИТ-системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы и профессиональных сообществ, вхожу в программные комитеты конференций SECR и AnalystDays, и открыт к общению с коллегами по ИТ на различных площадках и в соц.сетях. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Блоги друзей |
