Microsoft отключает свой Language Portal, но есть и хорошая новость
С 30 июня Microsoft отключает свой сайт с терминологической базой — Language Portal, я лично часто им пользовалась, чтобы посмотреть использование технических терминов в контексте, также там можно удобно посмотреть переводы, которые используются в локальных версиях продуктов и в глоссарий Microsoft — https://www.microsoft.com/en-us/language
Но одни добрые люди уже скачали все, что можно в формате TBX, а другие — подняли альтернативный ресурс на основе этих терминологических баз
https://termic.me/
Наверное в большей степени это новость для локализаторов и техписов, но если вам иногда приходится писать, например, тексты для интерфейсов или у вас возникают вопросы по тому, как использовать или адаптировать термин, сохраняйте и пользуйтесь.
Коллега на внутренней конференции рассказывала всем, чем полезно (кроме очевидных пойнтов, что у людей есть нужные знания) внутреннее управление знаниями:
- Помогает развиваться в профессиональном плане, находить новые связи между концепциями и новые идеи
- Позволяет выстраивать связи между командами и между коллегами, занимающимися схожими задачами
- При передаче знаний можно придумать неожиданные идеи, например, если тебе зададут вопрос, который раскроет тему с необычной стороны
- Если знания зафиксированы и распространяются, сокращаются простои, когда ты просто ищешь ответы на вопросы и не можешь работать
- В процессе обмена знаниями мы строим социальные связи, учимся взаимодействовать, поддерживаем друг друга и даже создаем сообщества
У нас внутри компании есть инициативная группа, где люди налаживают процессы управления знаниями, в ней собираются энтузиасты из совсем разных проектов, если интересно, буду иногда рассказывать о результатах и сложностях.
Снабди своего тимлида информацией
На прошлой неделе смотрела конференцию Write The Docs и в докладе Jennifer A Swallow Winning Over Coworkers, Collaborators, and Customers to a New Knowledge Experience почерпнула интересную практику — когда у тебя нет непосредственного “доступа к телу” менеджеров C-level, то полезно максимально снабдить информацией о том, что ты делаешь своего прямого лида.
Автор доклада развивает базу знаний для клиентов в Splunk, причем условно в одиночку, поэтому подготовила для своего лида готовые питчи на встречах с более высоким менеджментом.
Пример такой информации:
- Какую ценность проект приносит бизнесу и (если есть) как помогает каким-то из OKR или north star metric (одна метрика, отражающая основную ценность, которую продукт предоставляет клиентам)
- Как проект интегрирован с другими проектами и системами компании и как им помогает (если есть настоящие отзывы коллег - идеально)
- Какие направления проекта или его дополнительные функции могут приносить перекрестную пользу главам других департаментов (например, база знаний поддержки может помогать целям маркетинга, внутренних коммуникаций, обучения сотрудников)
- Какие планы по масштабированию и как в них вовлечены другие подразделения компании (например, есть какое-то подразделение, которое занимается внедрением LLM, а у вас в проекте есть конкретный запрос на ее применение, можно предложить помощь в формулировании юз кейса, написании внутренних материалов и в альфа-бета-тестировании)
- Каких ресурсов и поддержки от руководства не хватает сейчас, чем конкретнее, тем лучше (люди, подписка на инструмент, публичное признание)
- Через какие каналы можно узнать о проекте, где получить дополнительную информацию
В идеале нужны готовые ответы на эти вопросы, которые ваш лид сможет адаптировать под ситуацию.
От себя добавлю, что у многих из вас есть 1-1 с лидами, так вот его можно и нужно тратить во имя своего проекта — спроси менеджера, какие есть митинги тимлидов и, если это уместно в рамках ваших отношений, проси рассказывать какие топики есть в агенте таких митингов, чтобы удачно встроиться со своим проектом.
Также можно поступать не только с прямым лидом, но и с другими лидами, если вы плотно общаетесь, то их можно сделать своими “чемпионами”.
Собрали с классными авторами каналов про тимлидство и около него папку, которую вы можете добавить себе.
Там есть каналы на любой вкус — про управление командами и людьми, про коммуникации, про фасилитацию встреч, про хайринг, собесы и работу с людьми, конечно же про управление знаниями как инструмент тимлида.
Можете подписаться сразу на все каналы (рекомендуемый вариант 😉), а можете оставить выбрать те, что кажутся более релевантными.
Если ничего не отображается, то обновите Telegram, эта функция доступна, начиная с версии 9.6.0.
Интересный сервис ChatPDF — в него можно загрузить многостраничный PDF-файл (или дать ссылку на него), он его прочитает и затем сможет ответить на вопросы в формате диалога.
Попробовала на рабочей задаче, перед мозговым штурмом надо было быстро прочитать длинный репорт Стенфордского университета про AI. Вроде получилось вполне годно.
Miro запустила свои AI функции и вот мои первые впечатления
Уже доступны следующие функции:
- генерировать майнд меп, диаграмму, пользовательские истории по краткому описанию задачи + набор готовых
- генерировать заметки по теме
- генерировать картинку или код
- сделать кластеризацию и саммари группы заметок.
Генеративные функции типа драфт UML диаграммы, user stories или майнд мепа по теме неплохи, я бы использовала их в качестве продвинутого темплейта, когда генерируешь что-то и затем переписываешь часть по себя. У генерации майнд мепа есть еще несколько функций, ее затем можно попросить расширить - вопросами, темами, идеями. В моем кейсе идеи вышли совсем не связанные с изначальной картой.
Генерация картинок - странная, пока не нашла ей применения и качество не на уровне Midjourney.
Генерация заметок тоже OK для генерации идей с дальнейшим их развитием, но пока самое классное — это саммари из группы заметок.
Буду продолжать использовать и, возможно, расскажу подробнее на примере реальной задачи.
AI-based поиск по документации: уже стандарт?
Последнее время многие компании выкатывают свои эксперименты по прикручиванию AI/GPT к поиску по документации. Cтандартом это пока не стало, но как будто это не за горами.
Причем пробуют внедрять такую фичу как разработчики инструментов для документации, так и компании для своей собственной документации в качестве альтернативы поиску. Цель у них одна — чтобы пользователь решил свою задачу/проблему, получил ответ на вопрос.
Вот как минимум несколько примеров:
- Платежная платформа Stripe использует GPT-4, чтобы отвечать на запросы пользователей с помощью информации из их документации https://openai.com/customer-stories/stripe
- Следом платформа по извлечению, преобразованию, загрузке данных Airbyte выкатила свой подход к организации поиска по документации с помощью Relevance AI: можно попробовать на их сайте https://docs.airbyte.com/ или посмотреть короткую демонстрацию: https://www.loom.com/share/cef53d57e12a46e092c9fd653340bd65
- Дальше подключились разработчики инструментов — Motif объявили о запуске: http://markprompt.com GPT-4-based поисковая платформа, позволяющая тренировать модель на файлах в форматах MD, Markdoc и MDX, со встроенной аналитикой
- Затем GitBook представил альфа-версию Lens — AI дающего ответы на базе вашей документации https://docs.gitbook.com/product-tour/searching-your-content/lens Пока бесплатно на всех планах
- Наконец недавно анонсированные Copilot for Docs и DocsGPT, которые вообще перевернули правила игры и ищут по всей открытой документации к любым тулам, модулям и библиотекам и стараются найти ответ. По сути это альтернатива чтения документации и поиска ответов на StackOverflow, но без необходимости переключать контекст, например, выходить из IDE. Но умение задавать хорошие вопросы все еще нужно.
Вопрос открыт: станет ли это и когда таким же стандартом в инструментах для документации/баз знаний, как сейчас поиск или аналитика? И кто среагирует следующим?
Подоспели результаты опроса от DevCrowd
Ребята опросили 570 тимлидов, руководителей разработки и СТО о том, в чем заключаются их задачи, какие навыки важны в работе, какие у них трудности и какие каналы, ресурсы и книги читают.
Вот некоторые результаты:
- В топе задач у всех тимлидов безотносительно уровня — собеседования, развитие людей в команде и оценка их перфоманса
- Половина руководителей пишет код или занимается другой инженерной работой.
- В топ-3 навыков руководителя — работа с людьми, работа с командой, выстраивание эффективных процессов разработки и поставки продукта
- Топ-3 навыка, которые тимлиды хотели бы усилить: стратегическое видение, самоорганизация и коммуникации
Интересно, что непосредственно сохранение и передача знаний ни в одном пункте не содержится, но уверена, тимлиды этим часто занимаются, например, в рамках развития команды и найма новичков.
👉 Посмотреть результаты
ChatGPT лишает работы архитекторов ПО
В четверг, в 19:30 мы в режиме реального времени проверим, насколько ChatGPT может справится с задачами архитектора программного обеспечения.
Мы будем пытаться создать структуру обмена данными, давая на вход криво сформулированные данные и добьёмся, чтобы chatgpt самостоятельно уточнил необходимое. Ну и поиграемся с разными формулировками, конечно.
Спойлер: мы не верим, что chatgpt заменит специалистов, но готовы к удивительным открытиям!
Ссылку для трансляции запощу в канал незадолго до.
Привет, друзья! В условиях временного перерыва у KnowledgeConf, важно, что энтузиасты все равно проводят классные мероприятия про управление знаниями.
Приглашаю вас принять участие в конференции по управлению знаниями и эффективной совместной работе TEAMLY. В рамках конференции вы узнаете, как выстроить систему управления знаниями с нуля, как сохранять проектные знания и повторно использовать их в работе, а также как сократить время онбординга и выстроить эффективные корпоративные курсы.
Спикеры представят реальные кейсы из бизнеса и госкорпораций, а также расскажут, чем можно заменить западные сервисы Confluence и Notion.
Эксперты из Skillbox, «Объединенной авиастроительной корпорации», OZON, QSOFT, Московской школы управления СКОЛКОВО и других поделятся своим опытом и лучшими практиками в области управления знаниями.
Не упустите возможность узнать новое и полезное для вашей работы, даже если вы занимаетесь этим "подпольно", а не по основной должности 😉. Конференция пройдет офлайн, вживую, в Москве, 19 апреля. Сохраняйте дату в календаре.
Подробности и регистрация на сайте: teamly.ru/conf.
Снова нейросети в помощь — наткнулась на сервис, Explain like I'm five, он умеет объяснять сложные концепты простым языком, как будто вам 5 лет.
Перед запросов можно выбрать уровень от Pretty Dumb до Pretty Smart и включить или выключить сарказм. Ответ про knowledge management вполне сносный.
Ссылка на сервис тут.
Что я планирую послушать на TeamLeadConf
Для тимлидов и руководителей команд тема управления и обмена знаниями всегда актуальна, они же зачастую ее главные фасилитаторы.
Универсальных рецептов, как наладить эти процессы нет, но всегда стоит послушать профессионалов и обменяться опытом.
27 и 28 февраля 2023 в Москве пройдёт идеальная площадка для этого — мультиформатная конференция для тимлидов и руководителей TeamLead Conf 2023.
Я планирую и вам не могу не рекомендовать послушать вот эти доклады:
- Максим Цепков о профстандартах и моделях компетенций и почему невозможно сделать единую отраслевую рамку для всех.
- Адель Шадрина о наставничестве, как его внедрять и когда оно нужно.
- Владимир Малов о bus-факторе и как его считать. Или не считать.
- Рустам Агамалиев о том, как вести заметки, чтобы это было полезно всем и вам в первую очередь.
- Доклады из Яндекс-трека — это отдельная секция с топовыми спикерами, посвященная тому как в IT - компаниях устроены R&D - департаменты и как работать над инженерной культурой.
А еще мы с TeamLeadConf решили подарить одному из подписчиков канала онлайн-билет. 🎁
Условия простые: напишите в комментарии под этим постом любое сообщение, например, Хочу на конфу. А мы в ближайший понедельник в 18-00 по Москве рандомно выберем одного победителя, который сможет послушать все доклады онлайн, посмотреть виртуальные стенды партнеров и побыть в виртуальных кулуарах.
Прочитала вчера эпичный тред в Твиттере о том, как сделать документацию в команде лучше.
Там много полезных советов, вроде сделать ее частью процесса, включить в определение сделанной задачи, поощрять и вознаграждать, устраивать документационные "хакатоны" или "read-only" пятницы.
Но мне больше всего запомнился вот такой совет:
"Постройте культуру "see something, say something".
Вообще-то это теглайн кампаний по обнаружению признаков терроризма или чрезвычайных ситуаций, но он подходит и здесь.
Увидел что-то странное или неочевидное в коде - скажи и зафиксируй. Долго разбирался в каком-то вопросе или участвовал в треде в Слаке на 100 сообщений — скажи и зафиксируй.
Немного науки на каникулах не помешает
В декабре выступала на конференции Write The Docs Australia. Несмотря на то, что доклад был про научные основы в техническом писательстве, думаю, что и в деле управления знаниями информация будет полезной — рассказываю на какие принципы в когнитивной науке, психологии, нейрофизиологии и лингвистике можно опираться, когда пишешь документацию.
Запись доклада на английском и сессии вопросов и ответов после публично доступна по ссылке.
Разрабатывая фичу думайте, как бы вы ее анонсировали
Совет, который я услышала дважды за неделю, один раз из внутренней лекции руководителя отдела маркетинга и второй, когда читала про письменные практики в Амазоне.
Когда придумываете или даже уже разрабатываете какую-то фичу — попробуйте набросать короткий анонс для соцсетей или технического ресурса вроде TechCrunch.
Представьте, как ваш маркетинг менеджер будет ее анонсировать, это может открыть неожиданные инсайты, потому что формат анонса предполагает, что нужно встать на позицию пользователя, сформулировать его боли и предложить решения. Этакая разработка в обратную сторону.
В Амазоне есть похожая практика, но в усложненном виде. Один из важных документов в проекте — это PR/FAQ, его пишут до старта проекта, и он включает три секции — пресс-релиз, внутренний FAQ и внешний. Вот colin-bryar/working-backwards-how-write-an-amazon-pr-faq">тут можно почитать чуть подробнее, а вот тут есть примерный шаблон со всеми секциями.
На прошлой неделе на встрече программного комитета KnowledgeConf (да, мы скоро возвращаемся, про это отдельно) разгоняли темы этого года, и я спонтанно придумала новый термин — фактор трактора, это когда у вас в команде фактор автобуса был вроде высокий, не критичный, ключевые знания распределены между 3-4-5 людьми, есть перекрестные код-ревью, но вдруг сразу несколько ключевых сотрудников "заводят трактор" и становятся недоступны или ограниченно доступны.
Это история одновременно про непрерывную фиксацию знаний и про качественный оффбординг, как быстро собрать все нужные знания с сотрудника, который станет недоступен ну буквально вот завтра.
Спасибо Нику Волынкину @docops за идею картинки.
Всем привет!
На прошлой неделе из папки с тимлидскими каналами сюда пришло много новых людей, поэтому представлюсь.
Меня зовут Лана, по job title я технический писатель, но по факту люблю брать на себя роль подпольного менеджера по знаниям и помогать тимлидам сохранять знания, онбордить новичков, чинить сломанные каналы и вообще делать так, чтобы у людей была необходимая информация в нужный момент и в нужном формате.
О чем я тут пишу:
- О разных практиках управления знаниями в ИТ-командах
- Об опыте других компаний, слушаю интересные доклады на тему и делаю конспекты для вас
- Об инструментах, которые могут облегчить выстраивание процессов управления знаниями в команде, делаю короткие обзоры и пробую разное за вас
- О технических и письменных коммуникациях на проектах
А вот несколько постов из истории канала, которые мне кажутся полезными:
- Как считать/выявлять bus factor на проекте
- Кому не нужно управление знаниями
- Онбординг через эпики в Jira
- AI-based поиск по документации: уже стандарт?
Atlassian объявил о запуске собственного AI ассистента Atlassian Intelligence
И это же прям готовый список юз кейсов для использования AI в управлении знаниями 🥇:
- Саммаризация и обобщение: например, можно попросить его написать обобщающий абзац для заметок со встречи или выделить из них все принятые решения, создать из длинного тикета лаконичный ответ для сервис деска.
- Работа с внутренними терминами и сокращениями — ассистент может выделить из статьи термины и найти их определения в других источниках.
- Ответы на вопросы — уже можно сказать классический Q&A интерфейс заменяющий поиск по базе знаний.
- Конструирование JQL или SQL кверей по человеческому описанию, просто напишите ему, что хотите сделать и он напишет запрос на языке Jira или Confluence.
С AI зачастую сложнее сформулировать ограниченные и понятные юз кейсы, поэтому опыт Atlassian тут может быть очень полезен.
Пользуйтесь: https://www.atlassian.com/software/artificial-intelligence
В догонку еще отдельно покажу функции кластеризации заметок по ключевым словам, может быть удобно после мозгового штурма, я взяла реальный мозговой штурм для примера, первая кластеризация вышла сомнительная и местами случайная, а вот вторая - вполне такая, с которой можно работать.
Есть еще функция кластеризовать по настроению, например, когда вы на ретроспективе высказываетесь по поводу чего-то, можно поделить заметки на положительные/нейтральные/отрицательные по эмоциям.
Вот эту функцию группировки мыслей очень бы хотелось бы, чтобы они продолжили улучшать.
Хотите упростить онбординг в команду — используйте сторителлинг
Наткнулась на интересную статью, в которой предлагается использовать элементы сторителлинга при онбординге инженера в команду. Вот несколько советов:
1. Расскажите немного об истории: дайте новичку контекст, расскажите как проект развивался, в чем была его миссия, почему вы принимали те или иные инженерные решения, например, выбирали стек. Объясните, в чем ценность вашей команды для компании.
2. Объясните архитектуру не с точки зрения кода, а с точки зрения пользовательского пути. Это поможет новичку выстроить цельную картину и заодно получше разобраться в бизнесе.
3. Визуализация помогает: нарисуйте простую схему взаимодействия компонентов, ее можно использовать в дальнейших сессиях и обновлять по ходу.
4. Не вдавайтесь в низкоуровневые детали реализации в первое время: новички итак первое время перегружены информацией, лучше рассказывать о проекте на более высоком уровне абстракции, затем вдавайсь в детали по отдельным задачам.
Читать тут: https://betterprogramming.pub/improve-onboarding-in-teams-through-the-magic-of-storytelling-31b7fc479483
Наткнулась на канал, который в мемах (!) рассказывает о реальности применения гибких методологий. Сейчас репостну пару моих любимых мемов оттуда, переходите и подписывайтесь, чтобы посмотреть больше @agile_minutes
Читать полностью…В дружественном канале @lovely_it_hell сегодня намечается отличный эксперимент — Игорь будет в режиме реального времени формулировать запросы в космос ChatGPT, чтобы они из неструктурированных данных создали стройную архитектуру. Присоединяйтесь сегодня в 19-30 по московскому времени!
Microsoft Loop (конкурент Notion) объявил о запуске публичного превью
Попробовать бесплатно можно тут.
Набор элементов на странице пока базовый: текст, заголовки, таблицы, картинки, эмоджи, списки задач, таблица для голосования, дата, тег.
Иерархию страниц можно отображать в виде дерева или по последним действиям. Причем, в дерево можно добавить и ссылку на внешний ресурс. Есть базовые шаблоны для страниц.
Также можно создавать свои компоненты, например, текст, таблицу или список, а затем кидать кому-то в чат, чтобы он его отредактировал, при этом содержимое поменяется везде. Интересный подход, можно использовать для быстрых ревью. Или, например, кинул всем повестку встречи в чат, они ее покомментировали, отредактировали, она осталась на странице в виде компонента.
Чего пока не хватает лично мне: возможности делать канбан-борды на страницах, а я активно использовала их для личного и семейного планирования в Notion.
Это пока быстрые впечатления, будет интересно посмотреть, куда они пойдут с этим.
Никогда еще не публиковала тут вакансии, но не могу удержаться — это очень крутые задачи на стыке управления знаниями и техписательства
Вакансия Технического писателя для внутренней документации в команду Платформы Ozon, классный способ совмещать технические задачи, копание в коде, с коммуникацией с множеством SME. Если любите заниматься археологией и хочется прокачать техническую мышцу и много почерпнуть от классных разрабов —самое то. Когда-то я сама начинала именно как технический писатель для внутренней документации и это классная школа.
Что редкость, там уже все хорошо документировано, есть процессы постановки задач, сбора информации и ревью, надо встроиться в готовый зрелый процесс.
Апплаиться тут: https://job.ozon.ru/vacancy/tekhnicheskii-pisatel-platforma-instrumenti-avtomatizatsii-77993056/
Вот прямо сейчас стартует митап от Лаборатории Касперского База знаний здорового техписа, присоединяйтесь, спикеры отличные: https://www.youtube.com/watch?v=uWU0oPimbDQ
Читать полностью…Ребята из DevCrowd проводят исследование руководителей разработки, тимлидов и СТО, думаю, среди моих подписчиков такие есть. Вот какие вопросы их интересуют:
- Какие навыки для руководителей самые важные
- По каким критериям оценивают их работу
- Сколько времени уходит на написание кода
- Как попадают в профессию, и куда из нее уходят
- Полезные для развития каналы, курсы и книги
Пройдите опрос, расскажите про ваш опыт и помогите сделать охват исследования максимально широким. Его результаты будут в открытом доступе, и помогут вам сравнить свои ожидания от технических руководителей с рыночными, построить план своего развития, и просто понять, что происходит с индустрией! Результаты будут в марте.
👉 Пройти опрос
Podlodka #302 – Онбординг
Все мы слышали истории плохого онбординга новичков в компанию: начиная c того, что в течение месяца сотруднику не выдавали ноутбук, заканчивая тем, что первые недели работы целиком состояли из буллшитных встреч про ценности и миссию. Вместе с Евгением Антоновым, опытным тимлидом и консультантом, мы разобрались с принципами хорошего онбординга и тем, как можно построить простой и качественный процесс в вашей собственной команде.
🎧 Слушать выпуск
Вчера на конференции для аналитиков Flow 2022 посмотрела доклад Натальи Буравовой из Контура Технический писатель-аналитик. Кто он такой и чем занимается в команде разработки
Зацепила одна мысль, потому что я и сама всегда так делала, работая техписателем в команде разработки: сначала нужно сформулировать проблему/боль пользователя, какая информация до него не доходит, затем понять, каким способом можно этот канал "починить" и не всегда способом будет именно написать документацию.
Иногда это просто организовать процесс, поставить регулярную встречу, заснять видео, внедрить/изменить практику код ревью, сделать шаблон задачи, документация не единственный вариант решения и не всегда лучший, потому что ее нужно поддерживать.
Наталья рассказала, что они формулируют гипотезы, как решить проблемы пользователя и выбирают наилучший вариант.