Khi nào phải đối đầu với một người lãnh đạo dự án hay ông chủ tốt

Người đứng đầu dự án của chúng tôi là một kiến ​​trúc sư phần mềm thiên tài, nói chung là một người hiền lành và chu đáo, một người lập dị và tinh tế bằng giọng nói. Nhưng, đôi khi, chúng tôi (đồng đội của tôi và tôi) khác nhau về ý kiến ​​- đặc biệt là các vấn đề kiến ​​trúc phần mềm, vấn đề thiết kế hệ thống, vấn đề giao diện người dùng, v.v., với nhà lãnh đạo của chúng tôi.

Khi nào và làm thế nào (nếu có) chúng ta nên thể hiện sự khác biệt về ý kiến?

Giả sử bạn nghĩ rằng sếp của bạn sai. Bạn có ba lựa chọn

• làm những gì anh ấy nói và cuối cùng thất vọng khi nghĩ rằng bạn làm điều gì đó ngu ngốc - lâu dài không tốt lắm
• nói với anh ta rằng anh ta là một thằng ngốc - anh ta sẽ bỏ qua nó hoặc bạn gặp vấn đề về giao tiếp - không có gì hoặc làm tổn thương bạn.
• nói với anh ta rằng bạn có những mối quan tâm cụ thể về những ý tưởng mà anh ta đề xuất và giải thích những mối quan tâm đó - bất kỳ ông chủ tốt nào cũng sẽ giải thích vị trí của anh ta và sau đó bạn có thể đưa ra quyết định có lợi cho doanh nghiệp. Rất có khả năng bạn sẽ thấy rằng ý tưởng của anh ấy tốt hơn ý tưởng của bạn và bạn đã bỏ qua điều gì đó rất quan trọng.

Luôn luôn nghĩ về kết quả. Trong hầu hết các trường hợp, bạn không muốn đúng vì lợi ích của mình, bạn chỉ cần làm tốt công việc. Tùy chọn thứ ba giúp đạt được điều đó.

Đối xử với anh ấy theo cùng một cách - nhẹ nhàng và tôn trọng khi lên tiếng phản đối.

Trở nên chuyên nghiệp ngụ ý tôn trọng đồng nghiệp và cấp trên của bạn, điều đó không có nghĩa là bạn không thể không đồng ý, điều đó chỉ có nghĩa là nó phải lịch sự và tôn trọng bản chất.

Khi nhóm của tôi có nghi ngờ hoặc không đồng ý với ý kiến ​​của tôi, tôi xem đó là cơ hội cho giáo dục, cho cả bản thân tôi và các thành viên trong nhóm.

Đây không phải là một ví dụ về ngụy biện cũ hoặc hung hăng hay thụ động?

Lựa chọn thứ ba cổ điển là sự quyết đoán, cho phép phê bình mang tính xây dựng và bất đồng lịch sự .

Quan trọng không kém - chấp nhận những lời chỉ trích mang tính xây dựng (không nhất thiết phải đồng ý với nó) và chấp nhận sự bất đồng hợp lý (không bị ám ảnh bởi một cuộc thi ai là đúng và sai).

http://en.wikipedia.org/wiki/Assertivity

Và vào cuối ngày, một loại thụ động - nói với cấp trên của bạn - luôn luôn là cần thiết. Anh ta là người có trách nhiệm cuối cùng đối với quyết định - khả năng, quyền hạn và trách nhiệm không giống nhau, nhưng ít nhất họ nên đi cùng nhau.

BTW - "Kỹ năng con người" của Robert Bolton là một cuốn sách hay (và khá rẻ) cho những thứ như thế này - kỹ năng lắng nghe, sự quyết đoán và hơn thế nữa.

http://www.amazon.com/P People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Vì bạn có vẻ tôn trọng anh ấy và anh ấy có vẻ là một người thông minh, tại sao bạn không hỏi anh ấy theo cách sau:

"Phương thức / cách / kiến ​​trúc của bạn xử lý vấn đề x như thế nào?" Nếu không, hãy nói điều gì đó như: "Làm thế nào để làm điều đó như thế này, cách xử lý vấn đề x đó?"

Bằng cách này, bạn có thể tìm hiểu nếu anh ấy nghĩ về "vấn đề x" và nếu anh ấy đã học được điều gì đó. Hoặc nếu anh ta không nghĩ, anh ta sẽ nghĩ về nó và có thể sử dụng giải pháp của bạn hoặc nghĩ về một giải pháp khác (có thể bạn sẽ cùng nhau giải quyết).

Tôi ước tôi có thể đưa ra một ví dụ cụ thể hơn, nhưng tôi nghĩ bạn sẽ có thể có được ý tưởng.

Tôi không nghĩ rằng bạn sẽ đến bất cứ nơi nào trước với sếp của bạn, đặc biệt nếu anh ta không phải là lập trình viên hoặc đại loại như thế.

Và không cần phải nói rằng cách của anh ta là xấu, nhưng bằng cách hỏi làm thế nào nó xử lý một số tình huống nhất định anh ta có thể nhận ra một vấn đề hoặc có thể cho bạn biết tại sao nó không phải là một vấn đề.

Tôi hi vọng cái này giúp được.

Bằng cách sử dụng từ CONFRONT, bạn đang cho thấy rằng bạn không tiếp cận vấn đề với suy nghĩ đúng đắn.

Đó không phải là một cuộc đối đầu. Đó không phải là thù địch. Nó không hiếu chiến hay tức giận. Đó là một cuộc thảo luận về các phương pháp khác nhau và chi phí và lợi ích.

Đừng đi vào với sáu khẩu súng rực. Chỉ cần nói với anh ấy những gì bạn nghĩ đến. "Nếu chúng ta làm điều đó như thế này thì sao?" Ai biết được, bạn có thể thuyết phục anh ta.

Và nếu bạn không - và đôi khi bạn sẽ không - hãy nhớ rằng anh ấy có thể biết rõ những điều bạn không, về ngân sách, lịch trình, yêu cầu, các ưu tiên khác, v.v. Anh ấy không nhất thiết là một thằng ngốc chỉ vì anh ấy không đồng ý với bạn.

Không có gì sai khi nghi ngờ về bất kỳ quyết định nào, hoặc một kiến ​​trúc thiết kế / phần mềm nhất định. Trừ khi bạn mới bắt đầu công việc đầu tiên, trong trường hợp đó bạn sẽ sai 99% thời gian vì bạn thiếu một số phần của bức tranh lớn hơn .

Khi bạn (và / hoặc nhóm) khác nhau về ý kiến, hãy hỏi người lãnh đạo dự án nếu anh ta có thời gian để thảo luận về nó, hoặc thậm chí có thể lên kế hoạch cho một cuộc họp nhỏ (15-30 phút). Thông qua ý kiến ​​của riêng bạn một cách tôn trọng và lắng nghe lý do tại sao anh ấy đưa ra quyết định khác. Nếu tôi thấy cách bạn mô tả anh ấy, anh ấy sẽ vui lòng thảo luận và chia sẻ những hiểu biết của anh ấy về vấn đề này. Anh ấy sẽ không nói "bởi vì tôi đã nói như vậy" (những người như vậy tồn tại một cách đáng buồn). Trong trường hợp đó, hãy bỏ qua ý kiến ​​của riêng bạn nếu bạn muốn giữ công việc của mình, hoặc trút giận và rời đi vì một công việc khác vì bạn sẽ trở nên không vui.

Một cuộc thảo luận tốt có thể kết thúc theo nhiều cách:

• Trưởng dự án sẽ chấp nhận giải pháp của bạn như một cách tốt hơn để giải quyết vấn đề (và anh ta có thể đã học được một công nghệ mới, mô hình, ... mà anh ta chưa có nhiều kinh nghiệm).
• Bạn và nhóm có thể thấy một phần lớn hơn của bức tranh, hoặc có được một lời giải thích tốt tại sao bạn nên làm điều đó theo cách này. Bạn sẽ học được điều gì đó mới và hiểu rằng giải pháp ban đầu là giải pháp chính xác hoặc thậm chí bạn có thể tìm cách cải thiện nó bằng thông tin mới (mặc dù đến một lúc nào đó bạn sẽ phải đồng ý).
• Các cuộc thảo luận không giúp đỡ và bạn vẫn không đồng ý. Mút nó và thực hiện giải pháp của anh ấy (vì rất có thể anh ấy sẽ có nhiều kinh nghiệm hơn), hoặc rời đi.

Dù sao, bạn nên xem nó như một cơ hội để học hỏi và miễn là bạn giữ nó văn minh và tôn trọng, bạn sẽ có những trải nghiệm tuyệt vời với những cuộc thảo luận này.

Chỉ cần mang nó lên!

Theo cách dân sự và văn minh nhất mà tôi có thể, tôi thường sẽ nói "Tôi quan tâm đến khía cạnh này, suy nghĩ của bạn về vấn đề tiềm năng này là gì?"

Tôi sẽ đưa bóng vào sân của anh ấy để giáo dục tôi.

Dấu hiệu số 1 của một nhà phát triển và quản lý trưởng thành là họ có thể thừa nhận là sai. Trước tiên hãy chứng minh với sếp của bạn rằng tất cả các bạn hoàn toàn sẵn sàng thừa nhận bạn sai khi bạn làm điều đó và nói rõ với sếp rằng bạn mong đợi sự lịch sự tương tự từ họ.

Nếu bạn có một ông chủ tốt (và bạn nói bạn làm thế) thì điều này thường sẽ không thành vấn đề! Bạn sẽ thấy bạn có thể có cuộc thảo luận mang tính xây dựng và đi đến giải pháp tốt nhất cho tất cả các bạn.

Một điều bạn cần cẩn thận: đảm bảo rằng hầu hết thời gian bạn có các lý do kỹ thuật thực tế, có căn cứ để nghi ngờ thiết kế đề xuất. "Nó cảm thấy sai" nói chung là không đủ, và sẽ không đóng góp cho một cuộc thảo luận mang tính xây dựng. Nếu điều này xảy ra quá thường xuyên, sếp của bạn sẽ không có lựa chọn nào khác ngoài việc làm ngắn mạch "cuộc thảo luận" (đó là sự thật, vì vậy không thực sự là một cuộc thảo luận) và nói "xin lỗi các bạn, nhưng bạn sẽ làm những gì tôi đề nghị cho đến khi bạn có thể chứng minh với sự thật tại sao một số ý tưởng khác rõ ràng tốt hơn. ".

Đó là lý do tại sao ông chủ của bạn là ông chủ - để đưa ra các quyết định mà các nhà phát triển có thể khó đưa ra.

Theo ý kiến ​​của tôi và cách tôi thường cư xử với sếp của mình:

Luôn đưa ra ý kiến ​​của bạn và làm điều đó càng sớm càng tốt trong khi chủ đề đang nóng. Lý tưởng nhất là khi bạn đang có một scrum về một vấn đề hoặc dự án mới thay vì thực hiện sau đó khi bạn đã thu thập được lòng can đảm và các quyết định của bạn đã được đặt ra.

Bạn nên đề xuất ý kiến, mối quan tâm, vấn đề của bạn một cách cởi mở và đảm bảo rằng chúng xuất hiện dưới dạng đề xuất hoặc mối quan tâm thay vì áp đặt rằng nó phải được thực hiện theo cách như vậy.

Tạo thói quen từ đó và trở thành một người giao tiếp tốt hơn, thành viên trong nhóm và đến lượt mình, một nhóm tốt hơn. Một nhóm tốt sẽ nói chuyện cởi mở về những điều tiêu cực cũng như tích cực. Một người lãnh đạo nhóm tốt sẽ lắng nghe nhóm của anh ấy / cô ấy và đưa ra quyết định để xem xét các thông tin được cung cấp.

Chúc may mắn.

Nếu anh ấy là kiến ​​trúc sư giỏi như bạn mô tả, chỉ cần tiếp cận anh ấy một cách có học thức với những lý do hợp lý và cụ thể cho mối quan tâm của bạn.

Nếu bạn có thời gian / tài nguyên cố gắng thực hiện một số thử nghiệm về các tình huống sẽ chứng minh rằng bạn đúng, có một số dữ liệu về phía bạn là một điểm cộng rất lớn.

Một khi bạn nói chuyện với anh ta, anh ta chỉ có thể:

a) Đồng ý với bạn: Vấn đề đã được giải quyết!

b) Từ chối họ và giải thích cho bạn tại sao: có thể sau tất cả, bạn là người sai.

c) Từ chối họ mà không có lý do: nếu anh ta không hợp lý và bạn hoàn toàn chắc chắn, hãy bày tỏ mối quan tâm của bạn với dự án chịu trách nhiệm, trong trường hợp này bạn thực sự cần dữ liệu lạnh, và nếu bạn có thể, sự hỗ trợ của các thành viên khác trong nhóm. Nó sẽ không làm cho kiến ​​trúc sư rất hạnh phúc, nhưng đó là điều đạo đức phải làm (hãy tưởng tượng bạn đang thiết kế một tòa nhà và nhìn thấy một lỗ hổng trong cấu trúc ...)

Câu hỏi của tôi là: khi nào và như thế nào (cho dù?) Để thể hiện sự khác biệt trong ý kiến.

Hoàn toàn có là câu trả lời. Trừ khi bạn có một số tình huống hiếm hoi ngoài tầm kiểm soát mà thậm chí có khả năng gây nhiễu loạn hoặc mất việc vì nó quá lớn, bạn nên đối đầu với những người khác khi bạn có ý kiến ​​khác.

Chìa khóa thực sự ở đây là Khi nào và như thế nào.

Thứ nhất là 'Khi nào': Mọi môi trường đều khác nhau, nhưng một số nơi có cuộc họp hàng tuần hoặc thảo luận bàn tròn / mở trong đó đưa ra một số chủ đề nhất định là đấu trường thích hợp để thực hiện điều này. Điều chính bạn không muốn làm là làm cho nó giống như bạn đang coi thường hoặc công khai một số đối số thiết kế cá nhân nằm giữa bạn và chỉ 1 hoặc 2 người khác. Những người bạn đang thử thách sẽ không đánh giá cao việc bị thách thức và thậm chí có thể xấu hổ trước công chúng. Đối với những tình huống này, hãy cố gắng sắp xếp cuộc họp 1 trên 1 với người được đề cập để nêu chi tiết suy nghĩ của bạn.

Thứ 2 'Làm thế nào': Nếu bạn đang đến với một Người cao tuổi, hãy đảm bảo rằng bạn có tất cả các con vịt của bạn liên tiếp để ủng hộ những suy nghĩ của bạn. Bạn không thể lan man vào văn phòng của những người cấp cao nói rằng "Tất cả các biểu mẫu web phải được dừng lại và chúng tôi phải thực hiện MVC!". Khi được hỏi "Tại sao?" và bạn nói, "Vâng đó là những gì mọi người đang làm và nó có trong tất cả các tạp chí", nó sẽ không đi xa. Hãy chuẩn bị cho cuộc thảo luận qua lại và được hỏi về việc chứng minh suy nghĩ của bạn về kiến ​​trúc, mã hóa, thiết kế, thực tiễn tốt nhất, v.v. cũng giúp Điều quan trọng ở đây là không tham gia vào trận chiến bản ngã hoặc cho phép cảm xúc dâng trào.

Cuối cùng, nếu bạn có những gợi ý chắc chắn, chính đáng và hợp lý thì chúng nên được tính đến. Tuy nhiên, cũng nên chuẩn bị rằng chỉ có một số người không hợp lý trên thế giới này không muốn lắng nghe bất cứ ai trừ chính họ. Hy vọng rằng bạn không bị dồn vào một góc với loại tính cách này.

Chúc may mắn!

Tôi không chắc làm thế nào bạn có thể trở thành một kiến ​​trúc sư phần mềm xuất sắc mà không mắc lỗi và bị nghi ngờ về chúng. Tôi nghĩ thật an toàn khi cho rằng anh ấy đã ở trong tình huống này trước đây.

Người thông minh, trưởng thành, chuyên nghiệp không thể cưỡng lại sự hấp dẫn của những ý tưởng tốt hơn. Ngay cả khi anh ấy buồn bã lúc đầu bằng cách đặt câu hỏi về ý tưởng của mình, cuối cùng anh ấy cũng nên đi xung quanh và bạn sẽ có được sự tôn trọng với nó. Nếu anh ấy không trưởng thành cũng không chuyên nghiệp, bạn có một vấn đề lớn hơn, và có lẽ điều này sẽ làm sáng tỏ nó.

Nếu anh ấy là một kiến ​​trúc sư chuyên nghiệp, anh ấy sẽ tôn trọng và chấp nhận một ý kiến ​​thứ hai. Tuy nhiên, trong mọi trường hợp, bạn cần chuẩn bị tốt sự thay thế dựa trên sự thật / chuyên môn và cũng trình bày nó. Ngoài ra, hãy nhớ rằng về kiến ​​trúc về cơ bản có hai khả năng khác nhau cho các vấn đề như vậy:

1. Một cách tiếp cận / thiết kế có thể chỉ đơn giản là đúng hoặc sai, như trong toán 2 + 2 = 4 chứ không phải năm. Trong trường hợp sai, bạn cần đưa ra giải pháp đúng càng sớm càng tốt, dựa trên sự phản đối thực tế.
2. Cho đến nay, hầu hết các chủ đề trong thiết kế hệ thống là những cách tiếp cận có thể không độc quyền. Có những lựa chọn thay thế khác cũng hoạt động, lựa chọn tùy thuộc vào kinh nghiệm, hương vị, thiên vị, hình ảnh tổng thể, v.v. Để không giám sát một cách tiếp cận có thể tốt hơn, thường có các bài thuyết trình và thảo luận, khi các nhà phát triển được khuyến khích nói và chia sẻ ý kiến ​​của họ. Nhưng cũng nên nhớ, có những giai đoạn thảo luận và giai đoạn để thực hiện, trong lập trình nhanh, các giai đoạn này được xác định rõ.