Як я можу дати хорошу презентацію важливим, нетехнічним зацікавленим сторонам?

Наприкінці місяця я маю виступити з презентацією програмного проекту, над яким я працював сам, і в основному вирішуватиму, чи отримаю я штатну роботу в компанії, яку я тимчасово наймаю зараз. Я виступлю перед президентом нашого відомства та двома ВП. Президент має менше знань з програмування, ніж два інших віце-президента, і в кінцевому підсумку людина, яку я повинен вражати.

Які найважливіші речі мені потрібно передати у презентації? Мені вже сказав керівник, щоб наголосити на наступних речах:

1. Я направляю цей проект у правильному напрямку та повністю контролюю все.
2. Я завершую цей проект за графіком.

На які ще речі я повинен зосередитись під час своєї презентації, щоб зробити себе якомога достойнішим? Я думаю про те, щоб виділити зусилля, які докладаю на рівні дизайну, щоб зменшити ризик та невизначеність програмного забезпечення (я думаю, дві речі дуже важливі для вищих навчальних закладів).

Мене особливо хвилює одне - знайти правильний баланс між технічними та нетехнічними деталями у презентації. Якщо я не включаю жодних технічних деталей, президент нашого відомства не дізнається про всі функції "під капотом", які є в програмному забезпеченні, але якщо я занадто технічний, він може загубитися і не зрозуміти важливі моменти у презентації.

Будь-які поради будуть вдячні.

Знай свою аудиторію.

Ви вже завоювали правило публічного виступу № 1 - ви оцінили технічну експертизу людей, з якими ви будете спілкуватися, і ваша презентація повинна бути відповідно підлаштована. Не хвилюйтеся про те, що ви можете презентувати свою презентацію безліччю технологій та простого мовлення.

Велика спокуса, коли стикаються з великими перуками, - це по-справжньому спробувати і WOW їх вражаючим словником технічних концепцій, теорій та застосувань. Звичайно, ідея полягає в тому, що якщо ви достатньо заблудили начальника , то, звичайно, ви повинні бути кваліфіковані для цієї роботи!

Це навіть спрацює, ймовірно, за короткий термін, коли ви отримаєте штатну посаду, яку шукаєте. Президент, однак, безсумнівно піде від зустрічі, думаючи: "Я поняття не маю, про що говорив той хлопець", і ти можеш поставити під сумнів своє життя, яке складеться враження, яке він справляє на тебе до кінця життя .

Чому це погано? У діловому світі шукають людей, з якими вони можуть спілкуватися. Так, важливо мати в траншеях високодієздатних, технічно просунутих вун, які можуть налагоджувати код C, який взаємодіє із користувацьким серійним портом, але здогадуйтесь, що? Їм все одно. Їм важливо лише те, що ти контролюєш і що вони можуть тобі довіряти . Найбільш впевнений шлях до внутрішніх кіл (просування, гроші, слава, здобич) - це ефективне спілкування з вищими людьми.

Ось порада: зосередьтеся на своїх досягненнях з компанією на сьогоднішній день. Не занурюйтесь у гайки та болти та електропроводку - їх очі засклиться, і ви будете для них просто ще одним програмістом . Проведіть час, розмовляючи над речами, які вони можуть зрозуміти, і щоб ваші начальники відійшли від вас із впевненістю сказати: "Я довіряю цій людині, щоб виконати роботу".

Одна з найважливіших речей, про яку слід пам’ятати, - це не перепродавати. Якщо представити занадто багато інформації, особливо якщо мова йде про технічний проект, представлений нетехнічному персоналу, швидко втратите вашу аудиторію. Зробіть все можливе, щоб кожна тема, яку ви обговорювали, була важливою для "великої картини".

Що стосується "великої картини", нетехнічне управління, як правило, намагається перевести технічну дискусію в терміни витрат, часу та якості.

Зважаючи на це, ви можете згадати основні рішення, які ви прийняли в проекті, і виділити перевагу цих рішень з точки зору вартості, часу та / або якості. Постарайтеся вибрати 3-4 ключових рішення та нехай їх обговорення цих рішень буде коротким. Якщо вони хочуть отримати більше інформації, вони запитають (просто будьте готові відповісти!).

Я також настійно рекомендую заздалегідь запустити свою презентацію нетехнічним другом та отримати їх думку. Дуже легко подумати, що ти перебуваєш у нетехнічному стані, коли насправді ти все ще використовуєш занадто багато жаргону. Чим менше технічний ваш друг, тим краще. Спробуйте знайти когось, хто ледве може включити комп’ютер, не кажучи вже про програму. Якщо вони можуть слідувати суті того, що ви говорите, ви в хорошій формі.

Я виявив, що більшість технічних людей (включаючи мене) мають тенденцію бути надто технічними. Шанси на те, що ви здивуєтеся тому, як мало технічних речей, які вони можуть слідувати. Наприклад, якщо ви збираєтесь пояснити, що ви знижуєте ризик та невизначеність, дайте чітко зрозуміти, що всі проекти мають ризик та невизначеність, а не лише вашу, тому що вони не знають, що це знають.

Якщо ризик та невизначеність пов'язані з нетехнічними питаннями та менеджментом, вони стосуються або, принаймні, обізнані з ними, тоді обов'язково включайте те, що ви зробили.

Також підкресліть позитив, оскільки вони відберуть принаймні стільки від вашого тону, скільки все, що ви скажете. Тому не витрачайте багато часу на ризик та невизначеність. Якщо вам потрібно буде довести це, щоб пізніше прикрити себе речами, що не піддаються вашому контролю, ви, можливо, захочете покрити те, що вам знадобиться від інших людей, щоб виконати завдання за розкладом. Оскільки для більшості проектів інші люди не роблять того, що їм потрібно вчасно, це реальна можливість, це зменшує шанси на те, що ви звинувачуєтесь у цьому.

Хоча технічні люди усвідомлять ключове значення "під капотом", нетехнічні люди не стануть. Ви, мабуть, не можете більше сказати, що в цьому проекті є деякі технічні проблеми, на які важливо витратити час, як-от foozbar, whatsits і bla blas, але ви все робите, і все відбувається за графіком.

Ну, опис вашого проекту дуже розпливчастий, але я спробую.

Я думаю, що створений вами додаток є або заміною на інший додаток, або інструментом для автоматизації процесу, який був або все ще виконується вручну.
Зробіть аналіз випадку для різних сценаріїв, порівнюючи робочий процес до та після впровадження програмного забезпечення. Я хотів би бачити:

• покажіть, як ви упорядкували дуже поширені сценарії
• покажіть версії, які мали вади у користувальницькій роботі та як ви їх покращили. покажіть, як ви реалізували надані вам відгуки.
• показати деякі числа або таблиці, порівнюючи час, продуктивність, функції тощо до і після. Ось те , що я чую «При використанні static noiseта more static noiseми зменшили час , необхідний , щоб зробити X на Y% »

Особисто мені не байдуже, що відбувається під кришкою, а ваші менеджери піклуються ще менше (я насправді витрачаю на це багато часу і насолоджуюся цим, але я знаю, що я не отримую цінності, воюючи з речами, нікому коли-небудь побачить). Програмний продукт (компонент, бібліотека, рамка або додаток) повинен бути корисним (надійним, швидким, гнучким, передбачуваним) та обґрунтованим для майбутнього.

Якщо я найняв тебе, я хочу переконатися, що ти цінуєш ці якості. Я хотів би, щоб ви пояснили мені, якими засобами ви намагаєтесь їх досягти і чому ви вибрали ці засоби. Я хочу бачити, що ви використовуєте хороші інструменти. Покажіть мені статистику трекера проектів. Дайте мені огляд методів розробки, якими ви користуєтесь, коротко поясніть їх та їх переваги (приблизно для кожної речі на землі є два вигадливих два вкладиші, що дозволяє звучати переконливо). Покажіть мені, як працювати з вами буде приємно, як ви зможете реагувати на мої постійно мінливі потреби та як спілкування з вами дуже приємне, адже ви не просто кидаєте на мене технічні деталі, а пропонуєте рішення, звичайно реалізуються на технічному рівні, але це ви зможете представляти в термінах, які я розумію і які стосуються мене.

Подумайте, як структурувати презу, як газетну історію: спочатку важливі речі (плануйте починати пізно і рано відрізатись), а також висвітлити, хто, що, чому, коли, де і як. Мені подобаються односторінкові шаблони One Minute Manager, вони змушують мене добре зіпсувати речі.

Повторно стиль презентації:

• Напишіть це та практикуйте достроково. Зробіть відео про себе, подивіться його наступного ранку. Тренуйтеся знову.
• Ідіть у своєму власному темпі (дехто працює краще, якщо вони зупиняються і кружляють кавою, але ви можете уявити собі повільний Робін Вільямс?), Але включіть деякі заплановані паузи та перерахунки на важливі моменти. Час ... це важко, йому потрібна практика.
• не робіть, не робіть, не робіть PPT, який ви стоїте там і читаєте. Не робіть PPT, щоб ви могли там стояти і читати, тому що саме тоді ви будете робити. Використовуйте PPT для відображення графіки, щоб показати лише ключове слово або два. Ви хочете, щоб вони були зосереджені на вас, а не на пресо. Рекомендація 10/20/30 Kawasaki хороша.
• Тренуйтеся заздалегідь :), тому у вас є кілька запасних циклів для встановлення контакту з очима, спостереження за підказками для адаптації, і ви знаєте, до чого ви кидаєте, якщо вони почнуть вас відтягувати.

Повторний вміст:

• Після підсумків газет, висвітліть вимоги - і включіть деякі відкладені вимоги (речі, які ви дізналися, але не входять в обсяг поточних зусиль) ... включіть деякі речі, які ви спочатку розглядали як вимоги, але були спроможні відмовитися від вас досліджували.
• Основні ризики в бізнесі - вони не піклуються про ризик того, що "дані RDF не будуть добре розбиватись"; вони переймаються тим, що ви вважали ризик "масштабування моделі даних вимагатиме переробки, якщо ми отримаємо все більш складні дані клієнтів" і що у вас є відповідь на кожен ризик: як вони дізнаються, чи відбувається подія ризику (яка ваша метрика) і що ви вже зробили з цим, що команда зможе зробити з цим, якщо це станеться.
• Можливо, ризик все ще недостатньо визначений, недостатньо оброблений, або є катастрофічним і незмінним, якщо він виникає - скажімо так. Наскільки далеко ви потрапляєте у групу ризику, залежить від предмета (медичні ігри?), Тож це область, де буде показано ваше судження.

Підтекст: Ви працювали над собою, і це завжди трохи страшно для менеджменту - тому обов'язково включіть показники того, як ви інформували інших про прогрес, як дізналися заявлені та реальні вимоги. Керівництво вважає, що технічна частина є втомливою і потребує розумних людей, але в кінцевому підсумку завжди виконується ... компанії рідко досягають успіху або не вдається на основі технічних навичок, і вони знають це, тому не намагайтеся надто сильно вразити їх цим, не робіть спробуйте навчити їх технологіям. Швидше вразіть їх тим, наскільки добре ви досліджуєте та вирішуєте проблему, каталізуєте дискусію, повідомляєте про свій прогрес.

Дві основні проблеми не вимагають нічого технічного для напрямку та своєчасності вашого прогресу. Отримайте відгуки від інших людей, які брали участь. Ви не хочете, щоб під час презентації виникали сюрпризи або питання.

Зосередьтеся на напрямку проекту. Можливо, їм знадобиться переглядати, про що це йдеться, або вони, можливо, не брали участі ні в одному з планувань. Наводить приклади того, як ви це виконуєте.

Представте основні етапи проекту та вашу ефективність. Згадайте будь-які зміни специфікації, які могли змінити шкалу часу.

Не уникайте згадування будь-яких проблем у проекті. Ключове значення полягає в тому, як ви змогли їх подолати. Це повинно дати їм уявлення про вашу здатність вирішувати майбутні проблеми.

Говоріть повільно. Бути спокійним. Не забувайте дихати.

Хоча ви можете виділити прийняті рішення, використовувані технології та подолати проблеми, верхнє управління, як правило, буде зосереджене на питаннях нижнього рядка:

• Реалізація цього проекту таким чином допомагає нам робити бізнес швидше, краще і за меншу ціну ...
• Орієнтовна вартість цього проекту становить X, короткострокові заощадження - Y, а довгострокові заощадження - Z. (Ви можете піти від того, що X більше Y, але краще бути менше Z)

Одні з найкращих моментів полягають у тому, що коли ви працювали над проектом, ви знайшли способи, що збільшили економію чи ефективність порівняно з оригінальною розробкою проекту. Ми можемо сподіватися / припускати, що проект не буде розпочато, якщо керівництво не подумає, що вони збираються заробити / заощадити гроші ... якщо ви збільшите підсумок, що ще краще.

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

10/20/30 Правила PowerPoint від Гая Кавасакі було б моєю пропозицією, якщо ви використовуєте PowerPoint у своїй презентації, оскільки принципи, які він викладає, є досить добрими щодо того, що ви маєте лише 10 слайдів, 20 хвилин тощо.

Ви можете також врахувати кілька речей:

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

Уповільнити свою промову і додати паузи для наголосу.

Зробити зоровий контакт з кожного в кімнаті, а не тільки ЛПР або боса, так як інші можуть мати вплив на боса , а також ...

Спробуйте мати кілька історій .. Розкажіть їм про смішні речі, які траплялися з вами під час проекту, або навіть про погані .. Змусьте їх жити з вами настрій ...

Підсумовуйте , узагальнюйте, підсумовуйте ... Завжди тримайте їх за собою ...

Хороший натяк: наголос на технічних питаннях, які вони можуть виконувати. Дайте їм відчути, що вони також розуміють технічну частину. Це дасть їм гарне відчуття ...

Використовуйте такі заяви, як це гарне запитання , наскільки ви можете ...

Ви написали,

"Одне, що мене особливо хвилює, - це знайти правильний баланс між технічними та нетехнічними деталями у презентації".

Гарр Рейнольдс - один з провідних експертів з мистецтва презентації, і в одному зі своїх публікацій в блозі від 2005 року (все ще вчасно) він порівнює стилі презентації Стіва Джобса та Білла Гейтса. Навіть якщо ви не читаєте проникливу статтю, ви можете отримати підказку із скріншотів, порівнюючи слайд-шоу Білла та слайд-шоу Стіва про те, яка презентація є переконливішою та яка з більшою ймовірністю укладе аудиторію спати (підказка: та, з якою всі точки кулі та завищена укладка).

http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html

З 2005 року Білл вдосконалював свій стиль викладу, а Гарр висвітлює вдосконалення Білла в публікації в блозі з 2010 року.

http://www.presentationzen.com/presentationzen/2010/08/the-naked-transformation-of-bill-gates-the-presenter.html