Как стать автором
Обновить

Комментарии 38

Не раскрыта самая главная ошибка.

Ошибка 0 - ошибка менеджера/руководителя проекта, которые свалил на технического специалиста подготовку презентации.
Технический специалист - не универсальный комбайн, если он хорош в своей области - он вовсе не обязан быть хорошим докладчиком и понимать как лучше оформлять презентационные (рекламные?) материалы. Поэтому хороший технический специалист может:

1. Стремиться уместить на одном слайде как можно больше информации.

  1. Показывать свои результаты без чёткого порядка.

  2. и т.д. по списку + много чего ещё.

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

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

Пост вообще не про презентации. А про обычный питчинг перед потенциальными заинтересованным людьми.

Есть специальные книги про важность умения говорить "нет", это тоже навык, который стоит качать. У всех разные ситуации, классно, когда у вас есть специально обученный помощник, который презентует вашу работу за вас. Но не все могут позволить себе такую роскошь.

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

Пришли к выводу, что надо качать навык коммуникации. То есть софт скилл решает в карьере. Хоть у инженера, хоть у менеджера.

Согласна, как выясняется, его иногда сложнее качать, чем хард... 8(

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

А зачем показывать все данные? Покажите основные выводы. Экспертиза эксперта для этого и нужна.

какие выводы? - это обычно два листа в конце, прочитать за 2-3 минуты можно, а вот агрументация это как раз тех составляющая и ей реально будут пользоваться. тут вопрос в том шарят ли люди которым вы будете приводить примеры из своей экспертизы, или вы просто потратите свое время впустую.

В том и проблема, что часто просто выводы не воспринимаются боссами, а просто данные – им не понятны.

Вот, например, мы стартуем новый проект, и нужно объяснить директору, который нам этот проект поручил, что в сроки мы не уложимся по таким-то и таким-то причинам – выдели еще специалиста такого-то уровня.

Без пруфов директор скажет «что вы ноете – идите работайте», а чтобы пруфы сработали, надо их предъявить и показать так, чтобы директор понял. А он в конкретно вашей теме разбираться не обязан, он может более или менее технически подкован – зависит уже от специфики структуры в организации. И приходится думать, как сжать все данные об объемах работ и проблемах, которые внутри есть - до 5-10 слайдов, которые можно показать директору, чтобы он усилил команду. Под инженером же может быть и продакт – который занимается развитием продукта или ведением проекта, может быть дата-инженер, который выбивает себе дополнительные сервера или демонстрирует проблемы с данными. Не знаю, как в других фирмах, у нас этим занимались инженеры…

Когда я был молодым ученым, то послушал лекцию, а после купил книгу - Trees, maps, and theorems, on “effective communicationfor rational minds” - https://www.principiae.be/X0100.php Там и про то как делать слайды и как писать и как говорить. Общий подход основан на идеи соотношения сигнал-шум (замусоренные слайды это «шум» к вашей основной идее - сигналу). Считаю что эта книга мне сильно помогла в карьере, я пытался заставить ее читать сначала своих студентов, потом сотрудников. За прошедшие годы интерес проявила только одна девушка и кажется по другим причинам (и вроде даже не дочитала :()

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

а в переводе есть эта книга?

Если честно - не знаю, сильно сомневаюсь. Они по сути "самиздат" и конечно же ПДФку найти не составляет труда (я бумажную купили больше из принципа). Перевод может только если фанатский, но быстрым поиском я не нашел.

О да! Прекрасная книга, судя по всему! Надо взять на вооружение, спасибо за наводку. Про сигнал-шум, мне кажется, самая полезная идея. Всегда стараюсь ее использовать. Очень помогает в презентации (особенно, если обучаешь, особенно, если молодых людей).

Вот такое же влияние на меня оказала книга Cole Knaflic – Storytelling with Data – я тогда заказала ее почтой из-за рубежа в бумажном виде после того как прочитала электронную версию, настолько она мне понравилась. Конечно, по этой теме пишет много авторов, и я с тех пор прочитала еще несколько книг по теме.

Но именно первая книга мне дала толчок и позволила чуть увереннее себя чувствовать на выступлениях перед людьми. И мне даже со временном понравилось быть экспертом и преподавателем.

Как раз про визуальный шум и мусор, про гештальт принципы (близость, сходство) и визуальные атрибуты (цвет, форма, размер). Очень интересно про то, как это работает на уровне визуальной коммуникации! Со студентами кстати мне это тоже отлично помогало! Надеюсь, они потом тоже применяли эти методы в будущем… (но не уверена).

Вот да! Цель выступления – это, собственно, критический момент, про который многие забывают. А если еще помнить про цель каждой страницы, каждого графика, каждого слайда. Тогда получится намного больше пользы от презентации.

И это не так и сложно, но чудесно работает. Спасибо, что поделились своим  опытом!!

И как инженеры теряют влияние на совещаниях? Из-за презентации?

По-моему опыту - кроме инженеров мало кто умеет делать интересные презентации. Поэтому статью можно было бы назвать - как не потерять влияние на совещаниях тем, кто не смог стать инженером, содержание было бы тоже.

Инженеры умеют делать отличные презентации, если они этим занимаются. Имхо, работа с презентацией сложных данных и сложных концептов – это очень технический навык, так что инженеру по силу с ним разобраться. Не у всех это сразу получается, но и не всем это нужно.

Полагаю, те презентации инженеров, что вы видели – это были уже опытные инженеры, которые научились интересно презентовать свои данные. Далеко не все так круты.

Интересно о каких инженерах идёт речь?

- если инженер закончил вуз, то диплом он должен был писать... и если вуз технический, то и уметь защищать этот диплом... с графиками, таблицами, формулами и выводами.

...в этом тексте есть некоторые аспекты из элементарных навыков выпускника...

Или речь о ком-то другом? (Инженер - это не продавец и его влияние прямо пропорционально его знаниям и умениям решать задачи, а не качествам "сейлза"; скорее начальник должен понимать - кто в какой ситуации должен выступать, а кто проверять, комментировать, спрашивать, делать критические замечания и перед кем).

А заставлять хороших инженеров выполнять работу, которая им не очень нравится (заниматься продажами) может закончится расставанием по их инициативе... и ещё не известно кто при этом больше потеряет.

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

И у нас чем более квалифицированные инженер – тем чаще ему требовалось не только решать задачки тихо в углу у себя за компом (такие тоже есть, конечно), но и доказывать что-то на совещаниях коллегам, директорам, обучать заказчика и передавать мудрость коллегам. Управлять развитием продукта (может, у кого-то есть отдельные менеджеры такие технические и супер-экспертные, но у нас это инженеры делали).

Так вот, мне в какой-то момент пришлось работать с большим количеством данных – и в них никто кроме меня не разбирался, ни мой босс, ни тем более босс моего босса. А мне нужно было их им всем презентовать – и объяснять, что как, какие перспективы, делать аналитику, рекомендации выдавать. И еще чтобы они меня послушались надо было, а не отмахнулись и сделали какую-нибудь дичь.

Например – выбить обновление критически важного софта иногда не так просто, особенно когда ценник там с большим количеством нулей – приходится писать обоснования и все такое, показывать результаты всех предыдущих внедрений. Круто, если бы за меня это делал какой-то менеджер… но никто в этом ничего не понимал. И получается, мне все равно нужно было бы все это объяснить, показать и доказать сперва какому-то менеджеру тогда… А не напрямую боссам. Сперва у меня плохо получалось, но потом изучила немного матчасть и стало легче.

На самом деле, тоже не бином ньютона, уж инженеры быстро разберутся, что тут как)) На удивление, визуализация данных – а и менно это направление отвечает за работу с данными и компактным их представлением – очень техническая специальность. Хоть это и выглядит иногда «по-дизайнерски», «по-менеджерски», это не так. Не даром, даже ребята из анализа данных и датасаентисты – не пренебрегают визуальными методами анализа данных.

Ясно. "Data Analyst" или "Data Scientist" - это те о ком и необходимо говорить. Им конечно необходимы навыки презентаций своих дэшбордов - т.к. это и есть их работа в конечном итоге (включая некоторые навыки работы с базами и соотв. стеком).

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

Для общения и трансляции сложных вещей - есть аналитики, продакты - которым по роду их деятельности положено понять стейкхолдеров и объяснить, при случае, кому будет необходимо, что необходимо и в адекватной форме.

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

Возвращаясь к историям на основе данных, к дата-сторителлингу,  да, он пригодится дата-инженерам, дата-аналитикам и дата саентистам, им нужно доносить до кого-то свои выводы – иначе что они с ними будут делать?

Круто, если у них есть менеджер который хорошо разбирается в их теме и все поймет с полувзмаха ресниц… Но это все-таки не очень реалистично. К тому же, многие дата-инженеры планируют свою карьеры дол продакта – где уж без этого навыка точно никак.

Просто, мое мнение – инженерам этот скилл будет полезнее, так ка даже немного знаний сильно их продвинут в этом вопросе. У инженеров этот скилл часто ниже всего. И соответственно, они больше всего выгоды смогут получить, овладев им. Так как я сама инженер – я и общаюсь с этой аудиторией, как наиболее понятной мне.

Но и начальнику или менеджеру или преподавателю он тоже будет полезен. То есть любому, кто вообще вынужден кому-то что-то объяснять и аргументировать это данными а не только своим красноречием.

Когда я работал инженером, мне было глубоко плевать ( даже грубее), понимают меня на совещании или нет. Тем более я клал огромный болт, на их отчёты, презентации и прочую шелуху, потому, что этих много, а нормальный инженер я был один. Потому каждый должен заниматься своим делом, и рисовать графики, писать отчёты и презентации, в список умений инженера, может не входить, этот юнит для других целей. Теперь как хозяин компании, мне и в голову не придёт, требовать этого от инженеров.

У всех свой карьерный путь и задачи на работе. Здорово, что вы могли себе позволить решать, что именно делать, а что нет. И что был специально обученный менеджер, который работал с начальством вместо вас. Круто! Не всем так везет! У нас был небольшой отдел, так что некоторые выполняли по 2-3 функции.

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

 

Подскажите, а как владельцу компании, вам с клиентами, инвесторами и партнерами не нужно общаться и предъявлять им некоторые идеи, выводы или предложения? Я понимаю, что не во всех бизнесах это требуется. Просто в IT секторе без данных уже мало кому кто на слово верит. Так что приходится учиться их предъявлять.

Если сделать как в СССР - руководитель должен иметь научно-техническое образование, то рекомендации по презентациям нужно будет писать не для инженеров, а для гуманитарных обезьян!

Полегче, пожалуйста, с эпитетами для уважаемых коллег из гуманитарных наук.

Как делать презентации хорошо описано в книге «iПрезентация. Уроки убеждения от основателя Apple Стива Джобса».

По теме очень много классных книг! Эта одна из них - но она скорее про ораторское мастерство и владение вниманием - тоже очень полезно, но мне кажется, не все к такому склонны... Я скорее пишу о том - как данные предъявлять людям. Потому что это более житейская и насущная проблема сейчас... Мне кажется, там не так сложно узнать несколько трюков и методик, чтобы специалист любого уровня мог достойно отчитываться о своих результатах.

Конкретно про визуализацию данных есть книги на русском от Коул Нафлик, Александр Богачев, Альберто Кайро, Эдвард Тафти, Джин Желязны - но у них тоже по разным темам - от журналистики на основе данных, до творческих визуализаций. А если конкретно про донесение мысли - Коул Нафлик мне нравится. Еще хочу почитать:

Better Data Visualization и Better Presentations от Jonathan Schwabish, Info We Trust от RJ Andrews, Effective Data Storytelling: от Brent Dykes. Но это пока на будущее.

В итоге к хорошим специалистам теряется доверие, а наверх всплывают нетонущие легкие фракции, способные мыслить на уровне начальника-гуманитария. Итог, в общем, налицо.

Мне кажется, инженер тоже может овладеть нужными навыками, если ему это видится важным для его работы или карьеры. Тем более, визуализация данных - навык довольно технический - гуманитариям с ним сложнее.

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

Автор, так и «Как инженеры теряют влияние на совещаниях»?

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

Кликбейт?

Это мой личный опыт, я допускала все эти ошибки, пока матчасть по теме работы с данными и их презентацией не подтянула))

Заголовок и правда получился вызывающим х) Когда я допускала такие ошибки на совещанях, я ощущала, как теряю влияние в департаменте. А женщине инженеру и так непросто развиваться в мужском коллективе, так что я переживала на эту тему. Не думаю, что эта проблема уникальна) поэтому про это и пишу. Желязны - супер! Вот бы все его почитали... Коул Нафлик в целом про то же)

Полагаю, надо было детальнее расписать каждый пункт с кейсами, а то вышло слишком обще. 8( сейчас тестирую способности разных инструментов, может, про этот прикладной кейс будет полезнее материал)

Спасибо за отличную статью. Тема донесена хорошо. Буду рекомендовать коллегам, по необходимости.

Спасибо!

Главная идея: если люди ничего не поймут в вашем докладе, они будут уверены, что вы тупой (а не они) 🤷‍♂️

Да, это правда серьёзный риск. А второй шанс будет не всегда.

Отличная статья, минусаторы видимо просто не дошли до позиции где надо презентовать идеи

Спасибо! Может, в будущем им это все же пригодится.

А мне понравилась статья, сама этому учу сотрудников ) На защитах квартала особенно то позасовывают в слайд чего не попадя, то наоборот данных не добавят :D

Единственное, было бы ещё круче, если бы вы прям добавили наглядные примеры о том, как вы делали тогда (воссоздать), и как бы сделали сейчас. Как мне кажется, было бы ещё наглядней )

Вот да, я уже жалею, что не расписала подробно каждый пункт с примерами, картинок-скетчей явно не хватило. Но я недавно на платформе - пока не понимаю, насколько подкованная (и строгая!) тут аудитория!) Кстати надо найти этот проект - у меня кажется скриншот сохранился. Он правда был ужасен! Комикс очень реалистичен - там был пайчарт где-то на 50 секторов!! И общий смысл дашборда сводился к тому - "смотрите, я умею делать дашборд!" Спасибо за идею! Думаю, буду еще писать более подробные статьи по теме, перейду к конкретике, в абстракции мне самой не очень комфортно, да и читателям не очень нравятся общие слова.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории