Làm thế nào tôi có thể trình bày tốt cho các bên liên quan phi kỹ thuật quan trọng?

Vào cuối tháng, tôi phải thuyết trình về một dự án phần mềm mà tôi đã tự mình làm việc để quyết định về cơ bản tôi có nhận được công việc toàn thời gian tại công ty Tôi đang thuê tạm thời bây giờ Tôi sẽ thuyết trình trước chủ tịch bộ phận của chúng tôi và hai VP. Tổng thống có ít kiến ​​thức lập trình hơn hai VP khác và cuối cùng là người tôi cần gây ấn tượng.

Những điều quan trọng nhất tôi cần truyền đạt trong bài thuyết trình là gì? Tôi đã được người quản lý của mình nói để nhấn mạnh những điều sau:

1. Tôi đang điều khiển dự án này đi đúng hướng và kiểm soát hoàn toàn mọi thứ.
2. Tôi đang hoàn thành dự án này đúng tiến độ.

Những điều khác tôi nên tập trung vào trong bài thuyết trình của mình để làm cho mình xuất hiện như là đáng thuê nhất có thể? Tôi đang nghĩ đến việc làm nổi bật những nỗ lực tôi đang thực hiện ở cấp độ thiết kế để giảm rủi ro và sự không chắc chắn trong phần mềm (hai điều tôi tưởng tượng là rất quan trọng đối với những người cấp cao hơn).

Một điều tôi đặc biệt lo lắng là tìm sự cân bằng giữa các chi tiết kỹ thuật và phi kỹ thuật trong bài thuyết trình. Nếu tôi không bao gồm bất kỳ chi tiết kỹ thuật nào, chủ tịch bộ phận của chúng tôi sẽ không biết về tất cả các tính năng "dưới mui xe" có trong phần mềm, nhưng nếu tôi quá kỹ tính, anh ta có thể bị lạc và không hiểu những điểm quan trọng trong bài thuyết trình.

Bất kỳ lời khuyên sẽ được đánh giá cao.

Biết đối tượng của bạn.

Bạn đã chinh phục quy tắc nói trước công chúng số 1 - bạn đã đánh giá chuyên môn kỹ thuật của những người bạn sẽ nói chuyện và bài thuyết trình của bạn phải được điều chỉnh phù hợp. Đừng lo lắng về việc trình bày bài thuyết trình của bạn với nhiều kỹ xảo và leet-speak.

Một cám dỗ lớn khi đối mặt với những bộ tóc giả lớn là thực sự cố gắng và WOW chúng với từ điển ấn tượng của bạn về các khái niệm kỹ thuật, lý thuyết và ứng dụng. Tất nhiên, ý tưởng là nếu bạn đủ làm say mê ông chủ , thì tất nhiên bạn phải có đủ điều kiện cho công việc này!

Điều này thậm chí sẽ hoạt động, có thể, trong thời gian ngắn để giúp bạn có được vị trí toàn thời gian mà bạn đang tìm kiếm. Tuy nhiên, tổng thống chắc chắn sẽ rời khỏi cuộc họp với suy nghĩ: "Tôi không biết anh chàng đó đang nói về điều gì", và bạn có thể đánh cược cuộc đời mình sẽ là ấn tượng mà anh ấy có về phần còn lại của cuộc đời bạn .

Tại sao điều đó là xấu? Trong thế giới kinh doanh, CEO, chủ tịch, v.v. hãy tìm những người mà họ có thể giao tiếp. Vâng, điều quan trọng là phải có những chuyên viên máy tính có khả năng kỹ thuật cao, tiên tiến trong các chiến hào, những người có thể gỡ lỗi mã C có giao diện với một cổng nối tiếp tùy chỉnh nhưng hãy đoán xem? Họ không quan tâm. Tất cả những gì họ quan tâm là bạn đang kiểm soát và họ có thể tin tưởng bạn. Cách chắc chắn nhất vào vòng trong (khuyến mãi, tiền bạc, vinh quang, hư hỏng) là giao tiếp hiệu quả với những người cấp cao hơn.

Đây là lời khuyên: tập trung vào những thành tựu của bạn với công ty cho đến nay. Đừng đào sâu vào các đai ốc và bu lông và hệ thống dây điện - đôi mắt của chúng sẽ sáng lên và bạn sẽ chỉ là một lập trình viên khác cho chúng. Dành thời gian để nói về những điều mà họ có thể hiểu và khiến sếp của bạn rời xa bạn với sự tự tin để nói, "Tôi tin tưởng người đàn ông này sẽ hoàn thành công việc."

Một trong những điều quan trọng nhất bạn nên ghi nhớ là không bán quá nhiều. Trình bày quá nhiều thông tin, đặc biệt là khi nói đến một dự án kỹ thuật được trình bày cho nhân viên phi kỹ thuật, sẽ nhanh chóng mất khán giả của bạn. Cố gắng hết sức để đảm bảo rằng mọi chủ đề bạn thảo luận đều có ý nghĩa đối với "bức tranh lớn".

Đối với "bức tranh lớn", quản lý phi kỹ thuật thường cố gắng chuyển các cuộc thảo luận kỹ thuật về chi phí, thời gian và chất lượng.

Với ý nghĩ đó, bạn có thể đề cập đến các quyết định chính bạn đã thực hiện trong dự án và nêu bật lợi ích của các quyết định đó về chi phí, thời gian và / hoặc chất lượng. Cố gắng chọn ra 3-4 quyết định quan trọng và thảo luận ngắn gọn về những quyết định đó. Nếu họ muốn biết thêm thông tin, họ sẽ hỏi (chỉ cần chuẩn bị để trả lời!).

Tôi cũng rất khuyến nghị bạn nên chạy bài thuyết trình của mình bởi một người bạn không có kỹ thuật trước khi ra tay và lấy ý kiến ​​của họ. Rất dễ dàng để nghĩ rằng bạn đang không có kỹ thuật khi thực tế bạn vẫn đang sử dụng quá nhiều thuật ngữ. Bạn của bạn càng ít kỹ thuật thì càng tốt. Hãy cố gắng tìm một người hầu như không thể bật máy tính, nói gì đến lập trình. Nếu họ có thể làm theo ý chính của những gì bạn đang nói, bạn đang ở trong tình trạng tốt.

Tôi đã thấy rằng hầu hết những người kỹ thuật (bao gồm cả bản thân tôi) có xu hướng quá kỹ thuật. Điều lạ lùng là bạn sẽ ngạc nhiên về số lượng công cụ kỹ thuật họ có thể làm theo. Ví dụ, nếu bạn sẽ giải thích rằng bạn đang giảm rủi ro và sự không chắc chắn, hãy nói rõ rằng tất cả các dự án đều có rủi ro và sự không chắc chắn, không chỉ của bạn, bởi vì đó không phải là một cú hích mà họ biết điều này.

Nếu rủi ro và sự không chắc chắn xuất phát từ các vấn đề phi kỹ thuật và quản lý có liên quan, hoặc ít nhất là nhận thức được chúng, thì bằng mọi cách bao gồm những gì bạn đã làm.

Ngoài ra, nhấn mạnh sự tích cực, vì chúng sẽ lấy đi ít nhất là từ giọng điệu của bạn như bất cứ điều gì bạn nói. Vì vậy, đừng dành nhiều thời gian cho rủi ro và sự không chắc chắn. Nếu bạn cần đưa vấn đề này lên để che đậy bản thân sau này cho những thứ nằm ngoài tầm kiểm soát của bạn, bạn có thể muốn bao gồm những gì bạn sẽ cần từ người khác để hoàn thành nhiệm vụ đúng tiến độ. Vì đối với hầu hết các dự án, những người khác không làm những gì họ cần kịp thời là một khả năng thực sự, điều này làm giảm khả năng bạn bị đổ lỗi cho nó.

Mặc dù những người kỹ thuật sẽ nhận ra tầm quan trọng chính của các tính năng "dưới mui xe", những người không có kỹ thuật sẽ không. Có lẽ bạn không thể làm gì hơn là nói rằng dự án này có một số vấn đề kỹ thuật quan trọng cần dành thời gian, như foozbars, whatsits, và blah blahs, nhưng bạn đang làm tất cả những điều đó và mọi thứ đều đúng tiến độ.

Chà, mô tả về dự án của bạn rất mơ hồ, nhưng tôi sẽ thử.

Tôi tưởng tượng ứng dụng bạn xây dựng là một sự thay thế cho một ứng dụng khác hoặc một công cụ để tự động hóa một quy trình đã hoặc vẫn được thực hiện thủ công.
Thực hiện phân tích trường hợp cho các kịch bản khác nhau so sánh quy trình làm việc trước và sau khi giới thiệu phần mềm của bạn. Những điều tôi muốn thấy:

• chỉ ra cách bạn sắp xếp hợp lý các tình huống rất phổ biến
• hiển thị các phiên bản, có những sai sót trong trải nghiệm người dùng và cách bạn nâng cao chúng. cho thấy cách bạn thực hiện thông tin phản hồi được cung cấp cho bạn.
• hiển thị một số số hoặc bảng so sánh thời gian, năng suất, tính năng, vv trước và sau. Đây là những gì tôi nghe được "Bằng cách sử dụng static noisevà more static noisechúng tôi đã giảm thời gian cần thiết để làm X theo Y% "

Cá nhân, tôi không quan tâm đến những gì xảy ra dưới mui xe và các nhà quản lý của bạn thậm chí còn quan tâm ít hơn (thực tế tôi dành rất nhiều thời gian cho nó và tận hưởng điều đó, nhưng tôi biết rằng tôi không tạo ra giá trị bằng cách làm rối tung mọi thứ sẽ không bao giờ nhìn thấy). Một sản phẩm phần mềm (thành phần, thư viện, khung hoặc ứng dụng) cần có thể sử dụng được (mạnh mẽ, nhanh chóng, linh hoạt, có thể dự đoán được) và hợp lý trong tương lai.

Nếu tôi thuê bạn, tôi muốn được thuyết phục, rằng bạn coi trọng những phẩm chất này. Tôi muốn bạn giải thích cho tôi bằng cách đó có nghĩa là bạn cố gắng đạt được chúng và tại sao bạn chọn những phương tiện đó. Tôi muốn thấy rằng bạn sử dụng các công cụ tốt. Chỉ cho tôi số liệu thống kê của các dự án theo dõi. Hãy cho tôi một cái nhìn tổng quan về các phương pháp phát triển mà bạn sử dụng, giải thích ngắn gọn và những ưu điểm của chúng (đối với mọi thứ trên trái đất, có một lớp lót hai lớp lạ mắt làm cho nó nghe có vẻ thuyết phục). Chỉ cho tôi cách làm việc với bạn sẽ dễ chịu, cách bạn có thể phản ứng với nhu cầu luôn thay đổi của tôi và cách giao tiếp với bạn rất dễ chịu, bởi vì bạn không chỉ ném chi tiết kỹ thuật cho tôi, nhưng tất nhiên là cung cấp giải pháp được triển khai ở cấp độ kỹ thuật, nhưng bạn sẽ có thể trình bày theo các thuật ngữ mà tôi hiểu và có liên quan đến tôi.

Xem xét cấu trúc của preso như một câu chuyện trên báo: công cụ quan trọng trước tiên (dự định bắt đầu muộn và bị cắt sớm), và bao gồm ai, cái gì, tại sao, khi nào, ở đâu và như thế nào. Tôi thích các mẫu một trang của Trình quản lý một phút, chúng buộc tôi phải xử lý mọi thứ một cách độc đáo.

Phong cách trình bày lại:

• Kịch bản nó, và thực hành trước thời hạn. Tạo một video của chính bạn, xem nó vào sáng hôm sau. Thực hành lại.
• Đi theo tốc độ của riêng bạn (một số người làm việc tốt hơn nếu họ tạm dừng và xoay cà phê, nhưng bạn có thể tưởng tượng ra một Robin Williams chậm không?), Nhưng hãy kết hợp một số tạm dừng và phục hồi theo kế hoạch cho những điểm quan trọng. Thời gian ... thật khó, nó cần thực hành.
• đừng, đừng, đừng làm cho một số PPT bạn đứng đó và đọc. Đừng tạo PPT bạn có thể đứng đó và đọc, vì đó chính xác là những gì bạn sẽ làm. Sử dụng PPT để hiển thị đồ họa, để chỉ hiển thị một hoặc hai từ khóa. Bạn muốn họ tập trung vào bạn, không phải là preso. Khuyến nghị 10/20/30 của Kawasaki là tốt.
• Thực hành trước thời hạn :) vì vậy bạn có một vài chu kỳ dự phòng để giao tiếp bằng mắt, xem các manh mối để thích nghi và để bạn biết bạn đang rơi gì nếu chúng bắt đầu kéo bạn đi lạc hướng.

Nội dung lại:

• Sau phần tóm tắt của tờ báo, bao gồm các yêu cầu - và bao gồm một số yêu cầu bị trì hoãn (những điều bạn đã học nhưng không phù hợp với phạm vi của nỗ lực hiện tại) ... bao gồm một số điều bạn coi là yêu cầu lúc đầu nhưng có thể rũ bỏ khi bạn điều tra.
• Rủi ro chính của nhà nước trong điều khoản kinh doanh - họ sẽ không quan tâm đến rủi ro rằng "dữ liệu RDF sẽ không tốt", họ quan tâm rằng bạn đã cân nhắc rủi ro "quy mô mô hình dữ liệu sẽ yêu cầu làm lại nếu chúng ta có được dữ liệu khách hàng ngày càng phức tạp" và điều đó bạn có phản hồi cho mọi rủi ro: làm sao họ biết nếu sự kiện rủi ro xảy ra (số liệu của bạn) và bạn đã làm gì về nó, nhóm sẽ làm gì về nó nếu nó xảy ra.
• Nó có thể là một rủi ro vẫn chưa được xác định rõ, được xử lý dưới mức, hoặc là thảm khốc và không thể khắc phục nếu nó xảy ra - nói như vậy. Bạn đi được bao xa vào đống rủi ro tùy thuộc vào đối tượng (y tế? Trò chơi?), Vì vậy đây là lĩnh vực mà phán đoán của bạn sẽ thể hiện.

Subtext: Bạn đã từng làm việc một mình và điều đó luôn gây ra một chút đáng sợ cho quản lý - vì vậy, hãy đảm bảo bạn bao gồm các chỉ số về cách bạn giữ cho người khác thấy tiến bộ, cách bạn học được các yêu cầu thực tế và đã nêu. Quản lý tin rằng bộ phận công nghệ là tẻ nhạt và cần những người thông minh, nhưng cuối cùng luôn luôn có thể làm được ... các công ty hiếm khi thành công hay thất bại dựa trên các kỹ năng công nghệ, và họ biết rằng, vì vậy đừng quá cố gắng gây ấn tượng với họ, đừng cố gắng dạy họ công nghệ. Thay vào đó, hãy gây ấn tượng với họ bằng cách bạn điều tra và đóng khung một vấn đề, xúc tác cho một cuộc thảo luận, truyền đạt tiến trình của bạn.

Hai mối quan tâm chính không yêu cầu bất cứ điều gì về kỹ thuật cho sự định hướng và tính kịp thời của tiến trình của bạn. Nhận phản hồi từ những người khác đã tham gia. Bạn không muốn có bất kỳ câu hỏi hoặc thắc mắc bất ngờ nào trong bài thuyết trình.

Tập trung vào hướng của dự án. Họ có thể cần xem xét lại tất cả những gì về điều này hoặc họ có thể không tham gia vào bất kỳ kế hoạch nào. Đưa ra ví dụ về cách bạn đang thực hiện điều này.

Các cột mốc hiện tại của dự án và hiệu suất của bạn. Đề cập đến bất kỳ thay đổi đặc điểm kỹ thuật có thể đã thay đổi dòng thời gian.

Đừng tránh đề cập đến bất kỳ vấn đề trong dự án. Điều quan trọng là làm thế nào bạn có thể vượt qua họ. Điều này sẽ cung cấp cho họ cái nhìn sâu sắc về khả năng của bạn để xử lý các thách thức trong tương lai.

Nói chậm. Bình tĩnh. Đừng quên thở.

Mặc dù bạn có thể nêu bật các quyết định đã đưa ra, các công nghệ được sử dụng và các vấn đề được khắc phục, quản lý cấp trên thường sẽ tập trung vào các vấn đề mấu chốt:

• Thực hiện dự án này, theo cách này, giúp chúng tôi kinh doanh nhanh hơn, tốt hơn và với chi phí thấp hơn ...
• Chi phí ước tính của dự án này là X, tiết kiệm ngắn hạn là Y và tiết kiệm dài hạn là Z. (Bạn có thể thoát khỏi X lớn hơn Y, nhưng tốt hơn là ít hơn Z)

Một số điểm tốt nhất sẽ là nếu bạn đang làm việc trong dự án, bạn đã tìm ra những cách giúp tăng mức tiết kiệm hoặc hiệu suất khi so sánh với thiết kế dự án ban đầu. Chúng tôi có thể hy vọng / giả định rằng dự án sẽ không được bắt đầu trừ khi quản lý nghĩ rằng họ sẽ kiếm / tiết kiệm tiền ... nếu bạn tăng điểm mấu chốt thậm chí còn tốt hơn.

Các loại số liệu này rất quan trọng bởi vì một điều họ đang xem xét là chi phí để giữ bạn bên cạnh, và tự hỏi liệu lợi ích của việc đó sẽ được thêm vào hoặc trừ đi từ điểm mấu chốt.

Quy tắc PowerPoint 10/20/30 từ Guy Kawasaki sẽ là gợi ý của tôi nếu bạn sử dụng PowerPoint trong bản trình bày của mình vì các nguyên tắc anh ấy phác thảo là khá tốt khi chỉ có 10 slide, 20 phút, v.v.

Một vài điều bạn cũng có thể xem xét:

Giải trí chúng. Đừng là một chú hề nhưng một chút đam mê hoặc hài hước sẽ khiến họ chú ý hơn.

Làm chậm lời nói của bạn xuống và thêm tạm dừng để nhấn mạnh.

Giao tiếp bằng mắt với mọi người trong phòng, không chỉ người ra quyết định hay sếp, vì những người khác cũng có thể có ảnh hưởng đến sếp ...

Hãy cố gắng có một vài câu chuyện .. Hãy kể cho họ nghe về những điều buồn cười đã xảy ra với bạn trong dự án, hoặc thậm chí là những điều tồi tệ .. Làm cho họ sống theo tâm trạng với bạn ...

Tóm tắt , tóm tắt, tóm tắt ... Luôn theo kịp họ ...

Một gợi ý hay: Nhấn mạnh vào các vấn đề kỹ thuật mà họ có thể theo dõi .. Làm cho họ cảm thấy họ cũng hiểu phần kỹ thuật .. Nó sẽ mang lại cho họ cảm giác tốt ...

Sử dụng các câu như Đó là một câu hỏi hay nhất có thể ...

Bạn đã viết,

"Một điều tôi đặc biệt lo lắng là tìm sự cân bằng giữa các chi tiết kỹ thuật và phi kỹ thuật trong bài thuyết trình."

Garr Reynold là một trong những chuyên gia hàng đầu về nghệ thuật trình bày và trong một trong những bài đăng trên blog của ông từ năm 2005 (vẫn kịp thời), ông đã so sánh phong cách trình bày của Steve Jobs và Bill Gates. Ngay cả khi bạn không đọc bài viết sâu sắc, bạn vẫn có thể nhận được gợi ý từ các ảnh chụp màn hình so sánh trình chiếu của Bill và trình chiếu của Steve về phần trình bày nào hấp dẫn hơn và bài nào có khả năng đưa khán giả vào giấc ngủ (gợi ý: tất cả các gạch đầu dòng và kiểu dáng quá mức).

http://presentationzen.bloss.com/presentationzen/2005/11/the_zen_ saloneti.html

Từ năm 2005, Bill đã cải thiện phong cách trình bày của mình và Garr trình bày những cải tiến của Bill trong một bài đăng trên blog từ năm 2010.

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