Làm thế nào hiệu quả mà BÁN bán một thiết kế tốt trong các cuộc họp lớn

Nhiều lần tôi đã chứng kiến ​​một bi kịch buồn. Đây là những gì xảy ra:

1. Một đánh giá thiết kế nhóm cho một dự án mới.
2. Tôi thấy một thiết kế đơn giản có khá nhiều lỗ.
3. Tôi tình cờ đề cập đến các lỗ hổng và cách để tránh chúng.
4. Các cảnh báo được bỏ qua với các bình luận như "điều đó" không bao giờ "xảy ra trong cuộc sống thực"
5. Cuối cùng, những điều "sẽ" không bao giờ "xảy ra"
6. Một đánh giá thiết kế nhóm khẩn cấp cho một dự án bị hỏng.

Vậy tôi phải làm gì? Sao chép thái độ "Tôi đã nói với bạn như vậy" sẽ không giành được bạn bè và gây ảnh hưởng đến mọi người. Đôi khi nhiều năm trôi qua và những bình luận từ bước 3 dù sao cũng bị lãng quên. Tôi chắc chắn không muốn trở thành loài vật gây hại khó chịu nhắc nhở thế giới của loài khỉ. Tôi thường ngồi lại và xem tàu ​​Titanic đi châu Âu.

Thật là bực bội khi thấy các thiết kế xấu tiến về phía trước. Cũng thật bực bội khi tôi dường như không thể thuyết phục người khác về sự nguy hiểm đang chờ xử lý của con đường hiện tại. Tôi làm điều tồi tệ nhất trong các cuộc họp nhóm nơi mọi người có cách hiểu khác nhau về các điều khoản khác nhau. Ngoài ra, bản ngã có xu hướng chiến thắng lý trí và suy nghĩ. Tôi đang tìm kiếm các chiến thuật tốt để thuyết phục mọi người sử dụng một số ý tưởng mới và phức tạp.

Nếu có thể đề xuất sửa đổi sẽ không thêm thời gian đáng kể cho một dự án. Hãy thử và nhấn mạnh rằng nếu nó không được thực hiện ngay bây giờ, thì làm lại sau đó sẽ đau đớn hơn nhiều. Sẽ khó hơn nếu bạn đang cố gắng thuyết phục nhóm của mình rằng một hướng hoàn toàn mới sẽ tốt hơn, vì điều đó có thể sẽ trì hoãn dự án, v.v.

Đừng đưa mọi người vào chế độ phòng thủ trong một cuộc họp, họ sẽ chiến đấu với bạn để trở thành người chiến thắng. Bạn sẽ không khiến họ đồng ý rằng trái đất tròn. Đây là chính trị bình thường (ví dụ: bất kỳ ai trên FoxNews)

Nó thực sự giúp có được sự tôn trọng của các nhà phát triển khác. Nếu bạn là người mới trong đội, tôi nghĩ bạn là SOL. Vì vậy, chỉ cần xây dựng một số đại diện nhóm và thực sự cố gắng để đạt đến một cấp độ là bạn sẽ không bị đuổi ngay lập tức. Tất nhiên, nếu bạn luôn bi quan về số lượng, thì bạn sẽ chỉ bị coi là anh chàng "tiêu cực".

Đối với những thứ đơn giản (nghĩa là không ảnh hưởng đến lịch trình), hãy đảm bảo thực hiện công việc của bạn một cách tốt nhất. Nếu bạn đặt nỗ lực vào đầu ra ngay lập tức của mình (ví dụ: xây dựng trường hợp thử nghiệm hoặc nhận được một số tính năng đơn giản (nhưng tuyệt vời)), người khác sẽ nhận thấy rằng mã của bạn hoạt động đáng tin cậy và chịu được thử nghiệm về thời gian. Khi bạn bắt đầu chỉ cho họ một số thủ thuật gọn gàng với mã, họ sẽ nghĩ hai lần bắn hạ bạn trước mặt mọi người.

Cuối cùng, tôi đồng ý rằng bạn không muốn thực hiện thói quen "Tôi đã nói với bạn như vậy", nhưng hãy chắc chắn thử và đưa ra gợi ý cho sếp / lãnh đạo công nghệ của bạn khi điều đó thực sự đúng. Có thể gửi lại một e-mail cũ với ý kiến ​​cũ của bạn. Hỏi họ nếu điều này sẽ giúp giải quyết vấn đề "mới". Nếu bạn không làm điều này, họ thậm chí sẽ không nhớ rằng bạn là người đã đưa nó lên lần đầu tiên. Cuối cùng, họ sẽ nhận được gợi ý rằng bạn không chỉ cố gắng trở thành một người phô trương trong các cuộc họp. Lần tới họ sẽ nghĩ hai lần về việc thổi bay bạn, đặc biệt là nếu xung quanh đó là thiết kế "cũ" của bạn hiện đang thay thế thiết bị hỏng hiện tại.

Cố gắng xây dựng danh tiếng là người có thể xác định những gì sẽ hoạt động và không chỉ những gì bạn nghĩ sẽ có vấn đề trong một số trường hợp sử dụng hiếm. Khi bạn thấy những vấn đề tiềm ẩn này, chỉ cần coi chúng là một chú thích có thể cần được giải quyết sau này.

Mọi người trở nên điên rồ trong các hội thánh. Đề cập đến mối quan tâm của bạn cho một người quan trọng bên ngoài cuộc họp. Họ sẽ thấy điều này ít đe dọa hơn và có thể dành thời gian để nghe lập luận của bạn thay vì nghĩ về việc họ bảo vệ thiết kế. Họ cũng có thể mất nhiều thời gian hơn để giải thích cho bạn các trường hợp tại sao bạn có thể có điểm hợp lệ, nhưng việc giải quyết trong v1.0 là không khả thi.

Chìa khóa! Đi vào cuộc họp với sự hiểu biết đầy đủ về chương trình nghị sự của người giám sát trực tiếp của bạn là gì. Có thể họ xem đây là một dự án nhỏ và điều cuối cùng họ cần tại cuộc họp là một người tán thành dành thời gian cho những vấn đề quan trọng hơn. Yêu cầu họ giúp bạn giúp họ.

Nếu bạn muốn gây ảnh hưởng đến họ, hãy nói chuyện với họ về điều đó bên ngoài cuộc họp thiết kế. Nếu không, họ sẽ nghĩ rằng bạn đang cố gắng "ghi điểm" khỏi họ. Rất nhiều người không bao giờ muốn có những cuộc thảo luận thực sự trong một cuộc họp với "khán giả".

Tôi không thấy tình huống này khác nhiều như thế nào so với một nhà phát triển đơn độc với một ông chủ không biết gì. Thật không may, tôi đã mất số lần mà tôi đã bị 'thuyết phục' để xây dựng một dự án theo một cách nhất định và vận chuyển nó, bất chấp những cảnh báo của tôi về sự diệt vong sắp xảy ra. Điều đó khiến bạn không chỉ xây dựng mà còn tự mình lái tàu Titanic thành một tảng băng trôi.

Đúng như bạn mô tả, khi các bit chạm vào thùng tục ngữ, các cảnh báo của tôi đã bị lãng quên từ lâu. Đôi khi (may mắn cho tôi) mọi thứ trở nên tồi tệ hoặc nhiều tháng sau khi tôi không còn tham gia vào dự án. Thật không may, điều này khiến người kế nhiệm của tôi nghĩ rằng tôi phải điên, vì bạn có thể đặt cược rằng ông chủ đã từ chối bất kỳ bàn tay nào trong đó :)

Dù sao, một nhóm lập trình viên 'bị thuyết phục' có thể cũng không biết gì như một ông chủ tóc nhọn, đôi khi còn nhiều hơn bởi vì họ tự tin không biết gì, như Jeff O đề cập . Khi điều này xảy ra, bạn có nhiều thời gian để sửa chữa mọi thứ. Đừng cố gắng để làm cho một tiếng nói lý trí được nghe qua một rắm não tập thể. Nếu bạn có thể làm điều đó một cách hiệu quả, vị trí của bạn là trong đại hội, không phải đằng sau một phần mềm viết bàn.

Khi hành động mạnh hơn lời nói, bạn có thể:

• Hiển thị (với các kịch bản thử nghiệm) tại sao thiết kế sẽ thất bại trong các trường hợp bình thường. Điều này có thể sẽ dẫn đến một cuộc họp nhỏ hơn, nơi bạn là người trình bày, và có lẽ là tất cả những gì bạn cần được lắng nghe.

• Hiển thị một sản phẩm cạnh tranh giải quyết thỏa đáng những gì nhóm nghĩ chỉ là 'trường hợp góc'. Chẳng hạn, bạn sẽ ngạc nhiên về độ dài của Google để dự đoán những sai lầm trong chương trình bảng tính của mình.

• Lặp lại dự án cuối cùng yêu cầu viết lại một tuần trước khi dự kiến ​​giao hàng.

Nói cách khác, bước đầu tiên, bất kể bạn làm gì là đối phó với các cá nhân hoặc một nhóm (nhiều) nhỏ hơn. Nếu mối quan tâm của bạn thực sự hợp lệ, tôi chắc chắn rằng họ sẽ được nhận tốt hơn một hoặc hai tuần để phát triển. Chỉ là, như bạn đã lưu ý, tránh lập trường 'Tôi đã nói với bạn như vậy'.

Nếu có thể, hãy xem lại thiết kế trước (hoặc thậm chí sau) cuộc họp và nói chuyện riêng với các nhà thiết kế. Bắn hạ mọi người trong một cuộc họp trước tất cả các đồng nghiệp của họ sẽ có xu hướng khiến họ ngay lập tức phòng thủ và khép kín về các đề xuất của bạn, và có thể dẫn đến danh tiếng là "kẻ gây rắc rối" mặc dù bạn nghĩ rằng bạn có ích.

Một cách hay (nhưng thường khó) để trình bày "những lời chỉ trích" là đặt câu hỏi hàng đầu - hãy để người khác cố gắng trả lời câu hỏi của bạn và nhận ra lỗ hổng cho chính họ. Sau đó, nó có vẻ giống như ý tưởng của riêng họ và họ sẽ có nhiều khả năng đưa nó về phía trước. Một lần nữa, điều này hoạt động tốt nhất trong các cuộc thảo luận riêng tư, nhưng có thể là một cách thức ngoại giao và hiệu quả hơn trong tình huống họp (Lưu ý: Cố gắng tránh tranh luận hoặc thảo luận dài để thuyết phục mọi người trong cuộc họp. Chỉ cần hiểu ý và thử không nên lao vào vấn đề. Có lẽ tốt hơn là nên từ bỏ nó và sau đó trò chuyện với các nhà thiết kế sau cuộc họp để "làm sáng tỏ điều gì đó mà tôi không hiểu lắm" hơn là "anh chàng làm 30 phút đơn giản cuộc họp lãng phí cả buổi sáng của tôi ")

Một cách tiếp cận khác là gửi email các đề xuất của bạn (ngoại giao) cho nhà thiết kế chính (hoặc một danh sách phân phối nhỏ nhưng có liên quan). Nó có thể giúp xem xét ý tưởng của bạn và cũng cung cấp cho bạn "dấu vết giấy" để hỗ trợ mọi tình huống "Tôi đã nói với bạn như vậy" trong tương lai (nếu mọi thứ trở thành hình quả lê, ít nhất bạn có bằng chứng rằng bạn đã cố gắng giúp đỡ nhưng Nhưng nếu mọi thứ trở nên tồi tệ, có lẽ bạn không làm việc trong công ty phù hợp)

Cuối cùng, hãy nhớ rằng đôi khi bạn có thể "sai". Những người bạn đang nói chuyện có thể hiểu rõ hơn hoặc đầy đủ hơn về thiết kế của họ so với bạn và có lý do chính đáng cho cách tiếp cận của họ (ví dụ, gần đây tôi đã bị một thành viên trong nhóm cáo buộc tạo ra một thiết kế "không hiệu quả", nhưng đó là một thiết kế có chủ ý vì tôi biết hiệu suất vẫn có thể chấp nhận được, nhưng nó sẽ giảm một nửa chi phí phát triển - đó là một quyết định kinh doanh thay vì quyết định chất lượng mã). Chỉ cần cố gắng cởi mở về những ý tưởng của người khác - đôi khi những gì dường như là một ý tưởng tồi đối với bạn có thể là một ý tưởng tốt cho những lý do bạn chưa xem xét.

Khi gặp kịch bản "điều đó sẽ không bao giờ xảy ra", hãy nhắc nhở họ về tất cả những lần trong quá khứ khi họ phải sửa những mục "điều đó sẽ không bao giờ xảy ra". Nhưng bạn phải cẩn thận để không đi qua như "Tôi đã nói với bạn như vậy." Tôi thấy hiệu quả nhất là đưa ra các vấn đề trong quá khứ (và mức độ tốn kém và đau đớn của chúng để khắc phục) khi thảo luận về lý do tại sao bạn nghĩ rằng chúng ta nên làm gì đó cho dự án này như là ví dụ về lý do tại sao bạn nghĩ điều này quan trọng trước khi chúng mang đến " sẽ không bao giờ xảy ra "trích dẫn.

Tôi nghĩ có lẽ vấn đề của bạn là bạn nói rằng bạn tình cờ đề cập đến một cách để tránh một vấn đề, Có lẽ bạn nên trang bị thêm thông tin và chỉ cho họ chi tiết hơn tại sao điều này lại gây rủi ro cho hệ thống. Đôi khi điều đó có nghĩa là đưa ra chủ đề trong cuộc họp thứ hai sau khi bạn có thời gian để thực hiện một nghiên cứu nhỏ. Xây dựng một trường hợp kinh doanh với giá rẻ như thế nào để làm bây giờ ngược lại với chi phí đắt đỏ để làm sau này.

Âm thanh như đặt cược tốt nhất của bạn là làm việc để có được vị trí Trưởng nhóm. Sử dụng những cơ hội này để chỉ ra những sức mạnh mà bạn đã thấy điều này sẽ đến và nó có thể tránh được. Bạn không cần phải bán đội ngũ hiện tại của bạn ngắn để làm như vậy.

"Bình thường" trong "tình cờ đề cập đến các lỗ" dường như là một vấn đề. Cố gắng sử dụng (hoặc mang vào nếu nó không tồn tại) một số quy trình viết ra để phân tích rủi ro dự án. Thông thường, kết quả của cuộc họp phân tích rủi ro là một bảng hai cột đơn giản: rủi ro và chiến lược đã được thống nhất để giảm thiểu rủi ro là gì ("chúng tôi nghĩ rằng không bao giờ xảy ra" là một giảm thiểu chấp nhận được; điều quan trọng là ghi lại suy nghĩ hiện tại về vấn đề tại thời điểm đó). Hãy chắc chắn rằng các vấn đề của bạn được ghi nhận là rủi ro. Rủi ro nên được xem xét thường xuyên; rất có thể nhiều người sẽ đi theo quan điểm của bạn từ lâu trước khi cuộc khủng hoảng thực sự xảy ra và đánh giá rủi ro sẽ hoạt động như một "OMG xảy ra; chúng ta sẽ điên rồ khi tiếp tục như vậy "chất xúc tác. Về lâu dài, một dấu vết giấy là bằng chứng hữu ích để nói" nhìn này, chúng ta dường như có một vấn đề về thể chế ở đây "và có thái độ đối với thiết kế hoặc bất cứ điều gì thay đổi.

Làm thế nào để thực hiện ý tưởng của bạn

Đầu tiên trong các cuộc họp đề cập đến các vấn đề như những thách thức. Bạn khắc phục vấn đề, bạn vượt qua thử thách. Thử thách là điều tốt, vấn đề thì không.

Bắt đầu chậm và sử dụng kỹ thuật này trên một thử thách duy nhất tại một thời điểm. Lần tới bạn muốn sếp chấp nhận một trong những ý tưởng của bạn, hãy làm như sau:

• Phát triển ba cách tiếp cận tương tự nhưng khác nhau
• Nói với sếp của bạn rằng bạn cần sự giúp đỡ của anh ấy với một cái gì đó
• Giải thích rằng bạn không chắc chắn phương pháp nào trong ba phương pháp là cách hành động tốt nhất để giải quyết vấn đề
• Yêu cầu anh ấy / cô ấy giúp bạn chọn một trong ba

1. Điều này là vô cùng mạnh mẽ. Những gì bạn đang làm là cung cấp các lựa chọn không phải là tối hậu thư. Ultimatums thường xuyên hơn sau đó không bị bắn hạ vì đó không phải là ý tưởng của họ và chỉ có một lựa chọn.

2. Việc sử dụng từ ngữ của bạn là rất quan trọng ở đây. " Tôi cần sự giúp đỡ của bạn ".

3. Để sếp chọn "A", "B" hoặc "C". Trong thực tế, hãy để ông chủ tạo tùy chọn "D" bằng cách kéo ra các phần từ "A", "B" và "C". Những gì bạn đang làm là để cho sếp của bạn đưa ra lựa chọn.

Tại thời điểm này, bạn có thể quan tâm ít hơn những lựa chọn anh ấy chọn, bởi vì tất cả chúng là ý tưởng của bạn. Anh ấy sẽ nghĩ rằng anh ấy thực sự giải quyết vấn đề bởi vì bạn để cho quyết định trở thành của anh ấy.

Có Proof of Conceptý tưởng của bạn thực hiện. Nếu bạn chỉ cho nhóm của bạn một cái gì đó hoạt động và giải quyết vấn đề hiện tại trong tầm tay thì họ sẽ thích nó.