Giải thích những điều kỹ thuật cho những người phi kỹ thuật [đóng cửa]

Tôi thường phải giải thích những điều kỹ thuật và quyết định kỹ thuật cho người quản lý cực kỳ phi kỹ thuật của mình và tôi khá kinh khủng với nó. Những cách tốt để giảm bớt những thứ thiết yếu cho phần còn lại của thế giới không có niềm đam mê lập trình là gì?

Ví dụ câu hỏi tôi đã được hỏi:

• Tại sao bạn sử dụng Django thay vì Java (Không chấp nhận rằng nó rẻ hơn)
• Yêu cầu tôi viết lại những thứ không phải từ kỹ thuật, câu của tôi là "Một số thẻ HTML nhất định không được phép". Làm thế nào tôi có thể câm nó xuống?
• Những thứ khác có ý nghĩa hoàn hảo với tôi, nhưng chỉ là cơ bản nên tôi không biết giải thích nó như thế nào
• Tại sao thế này, tại sao thế kia, tại sao mọi thứ!

Ngoài ra, làm cách nào để tôi nói với người quản lý của mình tìm kiếm những thứ cơ bản trên Google, như "Pylons là gì?"

Tôi có xu hướng sử dụng các chất tương tự. Lấy bất cứ chủ đề nào, và nghĩ về một cái gì đó hoàn toàn phi kỹ thuật mà họ sẽ hiểu, và giải thích nó cho họ theo cách đó.

Ví dụ tốt nhất tôi có thể nghĩ ra bằng tay là nếu tôi cần giải thích hướng đối tượng, tôi sẽ giải thích nó bằng cách sử dụng một cỗ bài. Hoặc, khi tôi đang cố gắng giải thích ý tưởng về internet không dây cho người dì tuyệt vời của tôi (người không bao giờ sử dụng máy tính), tôi đã sử dụng điện thoại không dây để giải thích.

Tôi chưa bắt gặp bất kỳ chủ đề nào mà tôi không thể chết lặng theo cách này.

Những thứ tôi sử dụng

^{để hiệu quả tuyệt vời và không quá lớn.}

• Tương tự: Khi giải thích một tình huống hoặc một quá trình, nó thực sự hoạt động tốt nếu bạn có thể đưa nó vào các thuật ngữ mà họ sẽ hiểu.
• Thuật ngữ chung: Thay vì nói các thẻ HTML, bạn có thể nói mã . Nếu họ theo dõi yêu cầu một lời giải thích, có lẽ đã đến lúc tóm tắt ngắn gọn về HTML và cách thức hoạt động của nó. "Các trang web được xây dựng từ các khối được gọi là" thẻ. "Nếu trình duyệt của bạn không hỗ trợ một thẻ cụ thể, nó sẽ không được hiển thị chính xác."
• Tóm tắt và Tổng quan: Đôi khi nó hoạt động tốt để đưa ra một bản tóm tắt ngắn gọn trước khi đánh chúng lộn ngược đầu với thuật ngữ kỹ thuật.
• Xóa biệt ngữ: Bật "Cơ sở dữ liệu không tải cân bằng chính xác khi bị nhiều yêu cầu từ mạng con IP." vào "Cơ sở dữ liệu đang gặp sự cố khi xử lý các yêu cầu từ một số người." Nếu bạn có thể phải giải thích nó, thay thế nó bằng một cái gì đó khác. Nếu bạn phải giải thích cơ sở dữ liệu bạn đang gặp rắc rối. "Nơi để lưu trữ công cụ" là dự phòng của tôi.
• Visual Aids: Bảng trắng đá. Sử dụng chúng để lợi thế của bạn.
• Làm cho họ kỹ thuật: Giữ cho người quản lý, ông chủ và đồng nghiệp trong vòng lặp giúp. Nếu người quản lý tài khoản bối rối tại các cuộc họp vì mọi người trừ họ hiểu những gì đang được nói, điều đó có thể khiến họ muốn đọc những email mà họ đã được CC. Dành thời gian khi viết ghi nhớ hoặc email để giải thích cặn kẽ hoặc chỉ vào tài liệu tham khảo để giải thích. Có ai đó tự mình hiểu được HTML là gì sẽ tốt hơn sau đó cố gắng nhồi nhét nó vào chúng trong một cuộc họp quan trọng.

Một lần, từ lâu khi còn là sinh viên, tôi đã được yêu cầu giải thích điều gì đó vào bữa trưa Chủ nhật - một trong những trải nghiệm giáo dục nhất mà tôi từng có. Người đặt câu hỏi thật ngu ngốc không ngu ngốc - nhưng không có nền tảng, mức độ kiến ​​thức tôi cho là không có ở đó. Tôi bắt đầu trả lời, có một cái nhìn trống rỗng, thay đổi, vẫn trống rỗng, lại thay đổi, vẫn trống rỗng ... hmm ... vì vậy tôi bắt đầu giống như cách bạn bắt đầu xây dựng một ứng dụng, với những khối giải thích nhỏ mà bạn có thể xây dựng thành một cái gì đó quan trọng hơn.

Phần quan trọng của bài học này, đối với tôi, là (và là) chúng ta giả định bao nhiêu (không chỉ lập trình viên, mọi người) về kiến ​​thức của người khác về chuyên môn đã chọn của chúng ta trong khi thực tế, thậm chí, bạn có thể cho rằng phần lớn mọi người biết rằng 1 + 1 = 2 nhưng sau đó nó trở nên thú vị.

Vì vậy, điều đầu tiên và quan trọng nhất cần nắm bắt là mọi người không biết và không hiểu những gì bạn làm - nhưng họ hiểu những gì họ làm và khi bạn giải thích công cụ, do đó bạn cần bắt đầu đơn giản và giữ ở mức phù hợp mức độ cho khán giả của bạn.

Về mặt kỹ thuật cụ thể - Tôi nghĩ rằng @Josh K có phần khá hay - và tôi nhấn mạnh rằng Analogies là một người chiến thắng tuyệt đối.

Một điều nữa - đôi khi, có thể chấp nhận viết những điều đó thành "công cụ chuyên nghiệp", mọi người không luôn muốn giải thích đầy đủ về lý do và nếu trước đây bạn đã thể hiện sự sẵn sàng giải thích và khả năng thực hiện Vì vậy, theo cách dễ hiểu thì mọi người sẽ có xu hướng tin tưởng bạn khi bạn đề xuất rằng "lý do kỹ thuật phức tạp" được áp dụng hoặc cuối cùng bạn có thể đạt được một kết quả cụ thể bằng cách "làm công cụ chuyên nghiệp" (hoặc "công cụ lập trình viên" hoặc bất kỳ thuật ngữ nào hoạt động tốt trong môi trường của bạn).

Truyền đạt những thứ kỹ thuật cho đối tượng không có kỹ thuật (của một hoặc nhiều) là một kỹ năng, một thứ bạn có thể phát triển và một thứ bạn cần.

Cố gắng trả lời không phải về mặt công nghệ cơ bản, mà về mặt vấn đề. "khi một khách hàng sử dụng firefox cố gắng đặt hàng, trình duyệt của anh ta sẽ không hiển thị nút MUA IT - trình duyệt đó không hỗ trợ thẻ HTML mà chúng tôi đang sử dụng"

Thường thì đây thực sự là kiểu quản lý câu trả lời muốn. Nếu anh ta thực sự muốn hiểu các chi tiết cấp thấp, thì cách tốt nhất là tạo ra sự tương đồng với công nghệ mà bạn biết anh ta hiểu.

Tôi cố gắng tìm một sự tương tự với một cái gì đó tương tự trong thế giới thực. Giống như, khi tôi đề cập đến một ngăn xếp và ai đó đã hỏi đó là gì:

"Chà, bạn đã có những đứa trẻ. Chúng có bao giờ chơi với những khối gỗ nhỏ đó có chữ cái không?"

"Ừ."

"Bạn có bao giờ thấy họ tạo ra một tòa tháp lớn bằng cách xếp chồng một khối lên nhau không?"

"Ừ."

"OK, và khi bạn có một tòa tháp như thế, chỉ an toàn khi chạm vào đỉnh tháp, phải không? Bạn có thể đặt một khối khác lên, hoặc bạn có thể đưa khối lên trên, nhưng nếu bạn di chuyển bất cứ thứ gì bên dưới khối trên cùng, toàn bộ điều sẽ sụp đổ, phải không? "

Cười. "Đúng! Họ thích đập phá tòa tháp và khiến tất cả sụp đổ!"

"Chà, một ngăn xếp về cơ bản giống như làm điều đó với dữ liệu. Bạn thiết lập cấu trúc dữ liệu theo cách mà bạn chỉ có thể thêm mọi thứ lên trên cùng hoặc xóa phần tử trên đầu. Thật hữu ích để theo dõi những thứ mà bạn đang ở giữa thông qua việc làm, nhưng bạn cần phải làm một cái gì đó khác trước, và sau đó trước khi bạn hoàn thành rằng bạn cần phải làm một cái gì đó khác, v.v. " (Do đó giới thiệu ý tưởng về ngăn xếp cuộc gọi.) "Ngoại trừ việc bạn không muốn đánh sập tòa tháp trong trường hợp này."

"Ồ, tôi hiểu rồi. Tuyệt!"

Đừng cảm thấy tồi tệ. Tôi đã phải giải thích bản sao trên văn bản có nghĩa là gì đối với một nitwit hoàn chỉnh và hoàn toàn vào tuần trước. Thật khủng khiếp, nitwit đó là một trong những nhà cung cấp của chúng tôi.

Nếu trực tiếp, hãy tìm một bảng trắng, hoặc ít nhất là một số giấy để bạn có thể trở thành một lớp trừu tượng của con người.

Nếu làm việc với ai đó từ xa, có rất nhiều công cụ phác thảo / bảng trắng có sẵn.

Cố gắng đơn giản hóa một cái gì đó trừu tượng, bằng cách trừu tượng hóa nó hơn nữa, mà không có một số loại trợ giúp trực quan chỉ là sự điên rồ. Nó sẽ dẫn đến những thứ như lạm dụng ma túy và rượu, tước quyền từ gia đình và đồng nghiệp của bạn và tệ hơn là sự tàn ác kỳ lân.

+1 cho bất cứ ai nói về sự tương tự, +1 cho bất cứ ai nói về bảng trắng hoặc giấy và bút chì làm phương tiện trực quan.

Một mẹo khác tôi đã học được, đó là một số người tôi đã tìm thấy nếu tôi viết 5 trang về lý do tại sao một cái gì đó, họ thực sự sẽ đọc nó - tôi có thể nói, bởi vì một tháng sau họ sẽ nói điều gì đó và tôi biết nó từ tài liệu tôi đã viết.

Điều kỳ lạ là, tôi chắc chắn rằng tôi đã cố gắng giải thích chính xác điều tương tự bằng lời nói trước đó (ngay cả với các phương tiện trực quan và tương tự) và họ đã không hiểu. Tôi thấy điều này đặc biệt hữu ích trong các tình huống chính trị hoặc cảm xúc hoặc khi sự gián đoạn thường xuyên làm mọi thứ trở nên khó khăn.

Tuy nhiên, hãy đảm bảo thực sự giải thích vấn đề - và giải thích lý do tại sao về lợi ích kinh doanh. Khi tôi giải thích khái niệm nợ kỹ thuật cho Giám đốc điều hành của chúng tôi - và bây giờ, chúng tôi có thể sử dụng điều này như một cách viết tắt trò chuyện. "Tại sao bạn muốn làm điều này ba ngày? Trang web đó có vẻ tốt với tôi!" "Nó sẽ xóa nợ kỹ thuật, trong lần tới chúng tôi phải sửa nó, mọi thứ sẽ diễn ra nhanh hơn nhiều." Sau đó, cuộc trò chuyện có thể trở nên nhanh hơn bao nhiêu.

Bạn đang làm cho mình một sự bất đồng về cảm xúc và nghề nghiệp bằng cách khó chịu khi phải giải thích các chi tiết kỹ thuật cho những người không có kỹ thuật. Thực tế là những người không có kỹ thuật cần bạn dịch các quy trình kỹ thuật sang các quy trình kinh doanh phi kỹ thuật và ngược lại là những gì bạn đã làm việc. Bạn càng thành thạo trong việc dịch giữa hai miền vấn đề, bạn càng trở nên có giá trị đối với nhà tuyển dụng.

Làm quen với các kỹ thuật sản xuất và giải thích quy trình phát triển theo các quy trình dây chuyền lắp ráp.

Ví dụ, giải thích việc xử lý các thẻ html (và do đó không thể sử dụng chúng) có thể được thể hiện dưới dạng khuôn đùn, được biết đến phổ biến trong play-doh.

Giải thích các vấn đề của quá trình phát triển, chẳng hạn như thay đổi yêu cầu, cập nhật giao diện, lỗi sản phẩm, v.v., về chi phí tắt dây chuyền, thời gian và chi phí dành cho việc xây dựng đường dây và phải sửa đổi khi yêu cầu hoặc điều kiện thay đổi v.v.

Tôi đã đi vào chi tiết hơn trong một câu trả lời khác.

• Hãy coi đó là một cơ hội tuyệt vời để trau dồi kỹ năng thuyết trình của bạn.

• Hãy coi đó là một cơ hội tuyệt vời để xem xét các nguyên tắc cơ bản kỹ thuật của bạn.

• Nói bằng ngôn ngữ của khán giả, KHÔNG phải ngôn ngữ của bạn.

• Điều tra TẠI SAO người không công nghệ muốn thông tin này. Lý do cơ bản là gì? Anh ấy chán à? Tò mò muốn tìm hiểu thêm? Muốn xuất hiện có thẩm quyền? Thích làm bạn phát điên? Siêu hướng ngoại không có ai để nói chuyện? Thất vọng vì sự thiếu tiến bộ của bạn mặc dù ước tính lạc quan của bạn (đó là một điều phổ biến!)?