Поясняю на примерах, как «умещать» на одной диаграмме разные виды данных для наглядного представления сложной (многомерной) информации.

https://www.youtube.com/watch?v=pH2GztBFM2w

https://t.me/infograppa/571

https://dzen.ru/video/watch/69130a4a6f9bcc2e54da6834

В чем подвох?

Программисты — классные ребята, но они видят мир через призму кода. Для них обучение = последовательность команд:

• Нажми кнопку A

• Поверни рычаг B

• Дождись сигнала C

А реальность сложнее!

История из жизни: ТЕХНОНИКОЛЬ

Мы работали с заводом, где делают кровельные материалы. Казалось бы, простая операция — настройка намоточного станка.

Официальная инструкция: 15 пунктов, все четко расписано.

Реальность: У каждого завода свои "доделки", каждый мастер работает немного по-своему, а новички учатся месяцами методом "делай как я".

Проблема: Программисты берут официальную инструкцию и программируют тренажер строго по ней. Но это как учить водить машину только по ПДД, не рассказывая про реальные дороги.

Что такое неявные знания (и почему их не видят программисты)

Есть два типа знаний:

Явные — то, что записано в инструкциях
Неявные — опыт, интуиция, "чутье" мастера

Пример:

• Явное: "Установите температуру 180°C"

• Неявное: "Если на улице сыро, ставьте на 5 градусов больше, а если материал из прошлой партии — на 3 меньше"

Программисты видят только первое. А эффективность — во втором.

Наш подход: методология Носуленко

Мы используем спиральную модель передачи знаний:

1. Социализация — наблюдаем, как работают лучшие мастера

2. Экстернализация — переводим их опыт в понятные правила

3. Комбинация — создаем единую методологию

4. Интернализация — новичок усваивает через практику

Практически это выглядит так:

• Месяц изучаем производство

• Интервьюируем 10-15 мастеров

• Находим общие паттерны и различия

• Создаем сценарии, которые учат РЕАЛЬНО работать

Результаты, которые можно потрогать

До внедрения методологии:

• Адаптация новичка — 2-3 месяца

• Процент брака в первый месяц — 15%

• Увольнения на испытательном сроке — 40%

После:

• Адаптация — 3-4 недели

• Процент брака — 5%

• Увольнения — 15%

Забавные открытия из практики

За годы работы мы обнаружили много интересного:

На одном заводе мастер определял готовность материала... по звуку. В инструкции об этом ни слова.

На другом опытные операторы могли предсказать поломку оборудования за 2 часа до того, как сработает датчик. По каким-то микропризнакам.

Самое смешное: на одном предприятии официально было запрещено регулировать определенный параметр. Но все мастера это делали — и качество было лучше.

Все эти знания терялись, когда мастера уходили на пенсию.

А что с технологиями?

Мы не против программистов! Наоборот, технологии — это круто. Но:

Сначала методология, потом код.

У нас есть готовые технологические фреймворки для VR. Но без правильной методологии они превращаются в дорогие игрушки.

Сколько это стоит и стоит ли овчинка выделки?

Полный цикл (методология + разработка): 3-5 млн рублей
Время: 3-4 месяца вместо 18 месяцев разработки "с нуля"
Экономия: до 60% от бюджета

Окупается ли? За счет сокращения времени адаптации и снижения брака — за 6-8 месяцев.

Как понять, что ваш тренажер станет "цифровой вывеской"?

Красные флаги:

• Разработчики не изучали реальное производство

• Берут за основу только официальные инструкции

• Не говорят с опытными мастерами

• Фокусируются только на красивой графике

Выводы

VR-тренажер — не игрушка и не демонстрация технологий. Это инструмент передачи знаний. И как любой инструмент, он должен быть заточен под конкретную задачу.

Красивая картинка без методологии = дорогая вывеска
Правильная методология + технологии = работающий инструмент

P.S. Особенно интересны случаи, когда "официальная инструкция" кардинально отличалась от реальной практики. Таких историй у нас целая коллекция 😄

Введение

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

В современном мире, где внимание аудитории рассеивается под натиском информационного потока, преобразование текста в инфографику становится необходимостью для любого, кто представляет на публику свои идеи.

Критерий эффективности инфографики

Если восприятие сути инфографической схемы требует меньше времени, чем понимание текста, несущего ту же смысловую нагрузку, то такая инфографика может считаться эффективной. Иными словами — инфографика эффективна, если позволяет понять материал заметно быстрее, чем текст с тем же смыслом.

От текста к инфографике

Создание инфографики основывается на решении пяти основных задач:

1. Анализ исходного контента для инфографики

2. Визуализация фактов

3. Отображение связей между фактами

4. Визуализация сравнений

5. Решение композиционной задачи

1. Анализ контента

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

2. Визуализация фактов

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

3. Визуализация связей (структуры фактов)

Структура передаётся через взаимное расположение объектов, направляющие линии/стрелки и цветовую маркировку: топология инфографической схемы (что ближе к центру, что — периферийно; какие элементы связаны) задаёт ее смысловую иерархию.

Здесь будет полезно воспользоваться диаграммой связей для фактов, к узлам которой (т.е. к фактам) надо просто подобрать нужные образы.

4. Визуализация сравнений

Тут наиболее привычны для нас числовые данные и количественные сравнения, визуализируемые посредством разнообразных графиков и диаграмм. Однако сравнивать можно не только цифры, но и качественные характеристики.

За рамками графиков визуализация сравнений производится через:

• пространство (место объекта на схеме),

• количество (повтор одинаковых элементов),

• цвет (контраст для выделения),

• форма (различные формы — разные классы объектов).

5. Решение композиционной задачи

Ранее упомянутая диаграмма связей служит основой для инфографической схемы. Соответственно, решение композиционной задачи сводится к гармоничному расположению всех элементов схемы и связей между ними в пространстве, назначенном для размещения инфографики. Например, на слайде презентации.

При решении композиционной задачи полезно принимать во внимание устоявшиеся визуальные стереотипы восприятия. В частности, так называемая «европейская матрица эмоций» (см.: Arnheim R., Art and Visual Perception) предполагает, что движение слева направо читается как прогресс; вверх — позитив, вниз — негатив. Нарушение этих правил может вызвать когнитивный диссонанс (что следует использовать осознанно).

Заключение

Можно сказать, что инфографика — это дисциплина свёртывания смысла: от текста к образу, от абстракции к наглядной структуре. Следуя описанным принципам, вы получите инфографические схемы которые не только эстетичны, но и действительно работают, как эффективное средство трансляции ваших идей вашей аудитории.

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

Кстати, термин «servant leadership» ввёл в 1970-х годах Роберт Гринлиф в своём эссе «Слуга как лидер». Он работал топ-менеджером в AT&T, и я понял то же, что и он, только спустя полвека.

Статья – чисто моё мнение и видение ситуации исходя из опыта. В роли тимлида я руководил различными командами: от 1 разработчика до группы из 20 человек (разработчики, тестеры, аналитики).

НАЧАЛО ПУТИ: ОТ ОДНОГО РАЗРАБА ДО ДВАДЦАТИ

Когда я дорос до тимлида, я попал в классическую ловушку. Думал: «Ну всё, теперь я главный, буду раздавать указания и следить за их выполнением». Но реалии были таковыми, что выполнять задачи – это полдела, а вот делать их эффективно – это надо попотеть и примерить на себя роли психолога, «старшего товарища» и лидера, которому доверяют коллеги, кто может свободно общаться с начальством о нуждах команды. По сути, такое связующее звено между эффективной командой и заказчиками. Это и есть суть servant leadership – служить команде, а не командовать ею.

Эту-то эффективность и надо выстраивать тимлиду, приводя команду к максимальной точке эффективности. Микроменеджмент долой!

К слову, обязанности тимлида, руководителя проекта и руководителя продукта в небольших компаниях переплетаются.

АВТОМАТИЗАЦИЯ РУТИНЫ

Первое, что я стараюсь сделать в этой роли – избавить команду от рутины. Настроить автоматизацию в Jira: сценарии для создания задач, автоматические переходы по статусам, уведомления, шаблоны новых задач. Разработчики, тестировщики и аналитики перестают тратить время на заполнение полей вручную, а рабочий процесс по описанию задач поставлен на рельсы.

Дальше берусь за GitLab (а в основном его сейчас используют) – включил линковку задач Jira с MR, проверки code style (линтер + SonarQube), запуск тестов. Также, MR проверяется в полуавтоматическом режиме с помощью AI.

Для тестировщиков будет удобным настроить систему логирования ошибок в проде – Sentry.

Конечно, не стоит забывать и о том, что разработчики должны выстроить архитектуру самого проекта по понятной и устойчивой модели. Настроить так, чтобы тратилось меньше времени на исправление багов. В помощь им в среде разработки ставятся уже проверенные временем плагины.

Таким образом, команда получила больше времени на то, что действительно важно – на написание кода. И, хочу заметить, что всё это должен проконтролировать тимлид (ну и техлид, если имеется).

ЗАЩИТА КОМАНДЫ ОТ НАЧАЛЬСТВА

Отдельная история – это утилиты для сбора статистики по работе сотрудников. Начальство любит цифры, и мы их должны предоставить. Вместо того, чтобы заставлять разработчиков писать отчёты – обычно автоматизируются выгрузки отчётов о закрытых задачах, времени их выполнения в разрезе по каждому разработчику. Всё это можно настроить через Jira API, либо платные плагины. Получилось «два в одном»: менеджмент доволен красивыми графиками, а команда не отвлекается на отчётность.

РИТУАЛЫ БЕЗ ФАНАТИЗМА

Насчёт стандартного набора тимлида: дейлики, ретро, планирование с Planning Poker. Главное – не переусердствовать. Всё для команды, а не команда для процессов. Если какая-то практика не работает, меняем или убираем.

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

Также хорошей практикой будет совместный поход в бар/квест с коллегами.

SCRUMBAN КАК КОМПРОМИСС

Насчёт методологий – никто в чистом виде их не использует. Обычно в моей практике получается так называемый Scrumban – помесь Scrum и Kanban. Почему? Потому что чистый Scrum слишком жёсткий для фронтенда (особенно когда постоянно прилетают «горящие» задачи), а чистый Kanban не особо предназначен для планирования.

Scrumban даёт гибкость Kanban с планированием из Scrum. Команда может быстро реагировать на изменения, но при этом не теряет фокус на основных целях спринта.

ВСЁ ВЫШЕ И ВЫШЕ И ВЫШЕ…

Отдельный навык servant leadership – это умение защищать интересы команды перед руководством. Когда разработчик хорошо работает, но по каким-то причинам не получает повышение зарплаты, моя задача – это исправить.

Готовлю аргументы, собираю метрики производительности, иду к начальству и «выбиваю» повышения. Не всегда получается, но попытки нужно делать. То же касается и обновления оборудования, или повышения в должности. После ответа руководства для самого разработчика перспективы работы в этой компании будут видны чётче. Команда должна знать, что тимлид на её стороне, что тимлид первым принимает удары и берёт ответственность за подчинённых и их ошибки.

Разбор ошибок с командой – всё это делается на общих встречах, а частные проблемы разбираются один на один (не при всех).

ПОЧЕМУ ЭТО РАБОТАЕТ

Servant leadership работает по простой причине: когда разработчики видят, что ты работаешь для них, а не против них, они начинают работать лучше. Не из страха, а из уважения и желания не подвести.

Плюс, такой подход снимает множество конфликтов. Команда понимает, что тимлид – это не «надсмотрщик», а партнёр, который помогает решать проблемы и защитит, если необходимо.

ЗАКЛЮЧЕНИЕ

За примерно шесть лет тимлидерства я понял: лучший руководитель – тот, кого не замечают, потому что всё работает как часы. Моя задача в роли тимлида – создать систему, где команда может эффективно работать без постоянного контроля и не отвлекаясь на посторонние дела.

Servant leadership – это не про мягкотелость или попустительство. Это про создание условий для максимальной продуктивности команды. И да, иногда приходится быть жёстким – но всегда в интересах команды, а не для демонстрации власти.

Если ты ещё не в деле – попробуй этот подход. Возможно, твоя команда станет не только эффективнее, но и счастливее. А счастливые разработчики пишут лучший код.

PS: Я не описал здесь про решение конфликтных ситуаций, но это тоже надо уметь делать деликатно. О чём будет одна из последующих статей.

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»

Смотреть на других платформах:

https://rutube.ru/video/72db332a3482852635f5c0a1a6421ece

https://dzen.ru/video/watch/687f64f25c2e7921efd3f46f

https://vk.com/video106245820_456239025