Dừng các cuộc thảo luận kỹ thuật vô tận và đưa ra quyết định

Tôi luôn bắt gặp những người thích đập phá trong nhiều năm qua những "thứ kỹ thuật" nhỏ nhất.

Đừng hiểu sai ý tôi, tôi là một lập trình viên đam mê những gì tôi làm, nhưng bạn biết kiểu trò chuyện.

• Mac tốt hơn Windows rất nhiều
• Không sử dụng vòng lặp For Each, sử dụng vòng lặp While
• Đừng mua PC dựa trên Intel, hãy mua PC dựa trên AMD.
• Chúng ta nên sử dụng một container IoC trên một container khác.

Tất cả những "điều" này đều có giá trị ủng hộ và hợp lệ cho cả hai bên và bạn sẽ không bao giờ nhận được câu trả lời "chính xác" và người đó sẽ không bao giờ thừa nhận quan điểm. (tất nhiên sẽ có một số nơi có câu trả lời, có thể :).

Câu hỏi của tôi (tôi đang đến đó !!) là: Trong một nhóm phần mềm, làm thế nào để bạn vượt qua những cuộc thảo luận dài này mà không ngăn cản sự đổi mới, để có thể đưa ra quyết định và bạn có thể giải quyết các vấn đề kinh doanh thực sự.

Vấn đề 1. Một số người không muốn thua cuộc. Nếu họ không gọi các bức ảnh, họ sẽ tranh luận cho đến khi họ gọi các bức ảnh thông qua tiêu hao.

Vấn đề 2. Không có gì thực sự bị đe dọa, vì vậy tranh luận được dung thứ.

Không có gì bị đe dọa? Vâng. Hầu hết các quyết định có tác động gần như bằng không. Thực tế là "đập vào lâu đời" có nghĩa là cả hai lựa chọn đều giống hệt nhau.

Phải làm sao

1. Nhận ra rằng không có gì bị đe dọa.

2. Nhận ra rằng trong 2 hoặc 3 năm nữa, toàn bộ chủ đề sẽ được mở lại vì một cái gì đó bên ngoài tổ chức đã thay đổi.

3. Tung đồng xu. Nghiêm túc. Chỉ cần chọn một cái gì đó và di chuyển trên. Một số người sẽ thấy sự điên cuồng trong tranh luận. Một số người sau đó sẽ tranh luận về bản chất của việc tung đồng xu. Nếu mọi người không thể hài lòng với việc tung đồng xu, họ có vấn đề về bản ngã và cần biết rằng (a) không có gì bị đe dọa và (b) quyết định sẽ được thay đổi trong một vài năm.

Nếu họ không thể hiểu rằng không có gì bị đe dọa, họ cần phải viết ra giá trị đồng đô la của cả hai phía của cuộc tranh luận. Tại một số điểm, ai đó có thể thấy rằng nhiều giờ hơn dành cho phân tích hơn là quyết định thực tế có giá trị. Việc tung đồng xu tạo ra giá trị tương đương với chi phí thấp hơn.

Một vài điều để suy ngẫm:

1. Chỉ chấp nhận các đối số có thể định lượng. Nếu ai đó nói rằng nó sẽ tiết kiệm thời gian yêu cầu họ định lượng nó và giữ họ để trả lời. Bằng cách này, nếu họ đang nói chuyện rác rưởi, họ chỉ nhận được một lần trước khi mọi người biết rằng họ là một người vô dụng.

2. Nhận mọi người chịu trách nhiệm cho các khuyến nghị của họ. Hãy nói rõ rằng vào cuối năm, nếu họ đã thực hiện các cuộc gọi xấu sẽ là một phần trong đánh giá của họ. Tôi không bận tâm đến những cuộc tranh luận nhưng tôi muốn những người có lòng can đảm trong niềm tin của họ - nếu bạn sẽ thề điều gì đó thật tuyệt vời và mong chúng tôi chấp nhận nó, bạn sẽ có thể sống với hậu quả tốt hơn.

Đây là những điều thực sự để thoát khỏi hai vấn đề của S.Lott - rằng một số người không muốn thua cuộc và không có gì bị đe dọa. Phản ứng của tôi bị đặt một cái gì đó bị đe dọa vì vậy không có tranh luận cho tranh luận.

1. Timebox các cuộc thảo luận. - Nếu phải mất hơn 5 phút cho mỗi bên để nêu trường hợp của họ, thì nó quá phức tạp. Chúng tôi thực sự sử dụng bộ hẹn giờ bếp cho việc này . Họ làm việc tuyệt vời, và chi phí khoảng 5 đô la.
2. Yêu cầu những người tham gia tranh luận với dữ liệu và kinh nghiệm.
3. Chúng tôi giữ các tùy chọn trên bàn. Sau khi mỗi bên có thời gian của họ, chúng tôi dành thêm 5 phút để thảo luận về ý nghĩa của mỗi phương pháp. Sau 20 phút, chúng tôi ra ngoài và làm điều đó (thực hiện nó). Nếu nó không hoạt động, thì chúng ta đi theo cách tiếp cận khác.

Quy tắc rất đơn giản. Một khi bạn không biết nên chọn cái gì - hãy nghĩ cái gì tốt hơn cho công ty.

Có, sự lựa chọn Intel v AMD không phải là dễ dàng. Nhưng cái nào tốt hơn cho công ty của bạn? Ví dụ: nếu có một người chịu trách nhiệm đặt hàng và sẽ mất nhiều thời gian để đặt mua PC dựa trên bộ xử lý AMD, nhưng dựa trên Intel có thể được đặt hàng trong một phút và bạn thực sự không quan tâm nó sẽ như thế nào - chỉ cần đặt hàng một Intel dựa trên vì nó tốt hơn cho công ty.

Thông thường những cuộc thảo luận này thực sự chỉ là đi xe đạp . Mọi người tranh luận định dạng chuyển giao nào hoặc lưu trữ dữ liệu nào sẽ sử dụng và hàng tấn các chi tiết khác cần thực sự minh bạch cho tất cả các thành phần ngoại trừ việc thực hiện rất chi tiết. Không ai đưa ra một lời nguyền miễn là thành phần đó hoàn thành hợp đồng thiết kế và những người chịu trách nhiệm về nó sẽ có thể đáp ứng các thay đổi hợp đồng trong một khoảng thời gian hợp lý.

Phần lớn tất cả các vấn đề kỹ thuật bạn gặp phải trong phát triển phần mềm là các vấn đề về đạp xe. Đơn giản vì họ đã có giải pháp và câu hỏi duy nhất là, bạn muốn chọn giải pháp nào.
Bạn không nên tự nhốt mình vào những quyết định như vậy. Bạn nên khóa các quyết định đó vào một lớp trừu tượng tách riêng ứng dụng của bạn khỏi các chi tiết đó .
Các vấn đề thực sự quan trọng trong phát triển phần mềm là các vấn đề thiết kế ở cấp độ tính năng và hệ thống. Mọi thứ khác chỉ là thứ yếu.

Vì vậy, đừng thực sự bắt đầu những cuộc tranh luận như vậy. Tập trung năng lượng của bạn trong việc chia dự án của bạn thành các phần độc lập. Điều này mang lại phần mềm, đó là mạnh mẽ và linh hoạt hơn. Và nếu bạn có thể xác định chính xác các quyết định kỹ thuật có nhược điểm rõ ràng (điều bạn chỉ có thể làm, một khi bạn có phần mềm đang chạy), thì bạn có thể đưa ra quyết định khác mà không ảnh hưởng đến phần còn lại của hệ thống.

Tiêu chuẩn hóa là một cách tiếp cận

Nhóm của bạn phải đi đến thống nhất về những gì họ sẽ áp dụng làm tiêu chuẩn để phát triển và sau đó gắn bó với nó trong một khoảng thời gian hợp lý (do nhóm quyết định). Nếu tiêu chuẩn thất bại, thì một cái mới có thể được thông qua từ một loạt các khung giải pháp mới có thể.

"Này, những PC đó cuối cùng cũng vô dụng, chúng ta hãy thử máy Mac!"

hoặc là

"Tôi đã nói với bạn như vậy! Mùa xuân tốt hơn nhiều so với EJB."

Và như vậy.

Có một tiêu chuẩn có nghĩa là mã trở nên dễ dàng hơn để làm việc với một nhóm, từ đó dẫn đến một môi trường năng suất cao hơn.

Tôi hiện đang thử nghiệm phương pháp tiếp cận, mã có tên là "Papal coniances" và nó khá hứa hẹn. Nó dựa trên một câu chuyện, rằng trong một trong các cuộc bầu cử của Giáo hoàng đã có một "bế tắc" và các hồng y chỉ đơn giản là không thể đưa ra lựa chọn. Thực thể tổ chức một cuộc bầu cử (rất có thể là một số thành viên chính của Thành phố) đã khóa các hồng y đầu tiên trong một tòa nhà, sau đó giảm mạnh nguồn cung cấp thực phẩm và sau đó gỡ bỏ mái của tòa nhà để khiến cuộc tranh luận trở nên ít thoải mái hơn. Như các hồng y dự kiến ​​đã đưa ra lựa chọn sau khi mái nhà được gỡ bỏ kết thúc bế tắc ba năm.

Vì vậy, cách tiếp cận của tôi là khi mọi người không đồng ý về một số thứ, họ buộc phải thảo luận cho đến khi họ đưa ra một lựa chọn. Tôi không cung cấp bất kỳ sự khó chịu nào khác, thậm chí không bị hạn chế về thời gian và tất nhiên tôi không làm gì với mái nhà :). Tất cả những gì tôi làm là liên tục đưa vấn đề lên mỗi ngày. Nếu ai đó đi "Chúng tôi không thể đưa ra quyết định" tôi sẽ trả lời với "Chà ... bạn phải". Cho đến nay tôi chưa gặp một người nào vô vọng nghiện một số chi tiết công nghệ nhỏ đến thế. Sau một loạt các cuộc họp, họ có xu hướng tìm kiếm một sự thỏa hiệp giống như các hồng y.

Tôi đồng ý rằng đây là một cuộc thảo luận bền vững hơn là cắt ngang nó. Tuy nhiên, các cuộc thảo luận không phải là vô tận và như một điểm cộng, một số người sau khi "hội nghị" như vậy có xu hướng tránh các cuộc tranh luận công nghệ nhỏ, điều này làm cho mọi thứ trở nên thoải mái hơn cho toàn bộ nhóm.

Tôi đã đọc ở đâu đó hơn là bạn không nên đi du lịch quá 6 cùng nhau nếu bạn cần đồng ý về nơi bạn sẽ đến và phải làm gì, vì bạn sẽ không đạt được sự đồng thuận.

Đây là một ví dụ điển hình về lý do tại sao cần phải có một người có quyền quyết định. Trong ví dụ cụ thể này, một người nói cần đưa ra quyết định và nói rằng "nó cần phải như thế này", và những người khác cần tôn trọng quyết định đó để có thể thực hiện được công việc thực sự.

Nếu sau đó quyết định trở nên tồi tệ, ít nhất bạn cũng biết chắc chắn và có thể học hỏi từ nó.

Một cách tiếp cận là bỏ phiếu và hoạt động tốt trong các đội có quy mô nhỏ hơn.

Trong khi hai cá nhân có thể có cuộc trò chuyện; chuyển nó đến một diễn đàn mở ... tranh luận về N lượng thời gian sau đó giữ phiếu bầu bằng cách giơ tay.

Đơn giản nhưng dân chủ và cho phép bạn tiến về phía trước.

Một câu hỏi tương tự có thể là:

Làm thế nào để ngăn chặn các cuộc chiến tôn giáo / ngọn lửa trên các diễn đàn?

Tôi nghĩ rằng @ S.Lott đã đúng trong nhận xét của mình, nếu điểm duy nhất là "thảo luận", "bỏ đi" hoặc bỏ qua nó có thể là câu trả lời duy nhất. Tôi đã sử dụng kỹ thuật đó trong quá khứ.

Nếu vấn đề là đi đến một giải pháp, hãy cân nhắc ưu / nhược điểm cho tên miền đang đề cập, đặt giới hạn thời gian và (gật đầu với Nike) chỉ cần làm điều đó.

Lý tưởng nhất - IMO - lãnh đạo công nghệ hoặc nhân vật có thẩm quyền nói, "được thôi, cảm ơn vì những điểm của bạn, chúng tôi ..." âm thanh của xúc xắc "... đi với ý tưởng tương tự." và mọi người đi và ngồi xuống.

Sự đam mê về các điểm rất nhỏ đã làm lãng phí một lượng lớn thời gian gặp mặt của tôi và tôi không muốn nghe điều đó nữa. : - /

Tôi thấy rằng khi bạn tập trung vào cuộc trò chuyện không phải là lựa chọn nào là đúng mà là hậu quả của việc chọn sai là gì, bạn có xu hướng không quá sa lầy. Nếu chúng ta có thể đi đến thống nhất rằng ngay cả khi A đúng, B sẽ không giết chúng ta, không ai có thể làm gì nếu chúng ta kết thúc với B. Nếu chúng ta không thể đi đến sự đồng thuận đó, thì nói chung là vì có vấn đề thực sự mà chúng tôi phải giải quyết.

Điều chính là chúng ta phải trưởng thành và hiểu rằng chúng ta không thể luôn đồng ý với nhau, điều lớn và trưởng thành là học hỏi lẫn nhau, tại sao chúng ta có những vị trí chúng ta có, và có lẽ liên quan đến chính tôi Câu hỏi, tìm hiểu những kinh nghiệm và lý do tại sao. Sau đó, chúng ta có thể đưa ra ý kiến ​​thông báo của riêng mình và bị nguyền rủa hay không.

Cá nhân tôi không cần hoặc mong người khác đồng ý với tôi, điều đó sẽ tốt, nhưng không quan trọng. Và đến thời điểm này, tôi trích dẫn Voltaire.

"Tôi có thể không đồng ý với những gì bạn nói, nhưng tôi sẽ bảo vệ cho đến chết, bạn có quyền nói điều đó." -Voltaire, triết gia thế kỷ thứ 5

Mỗi cuộc họp nên có một chủ tọa chịu trách nhiệm về chương trình nghị sự và giữ trật tự (và mất vài phút, mặc dù họ có thể ủy thác nhiệm vụ này cho người khác nếu cuộc họp quá lớn để họ xử lý mọi việc). Nhiệm vụ của chủ tọa là bảo ai đó ngừng tranh luận ("các bạn, làm ơn hãy ngoại tuyến" trong bài phát biểu của công ty).

Nếu cuộc họp không đáng để bổ nhiệm chủ tịch, thì đó không phải là cuộc họp đáng để có. Bạn cũng có thể có một cuộc trò chuyện tại watercooler.

Người ta có thể nói "nói dễ hơn làm, quant_dev". Chà ... một chủ tịch tự nhiên là trưởng nhóm, quản lý dự án, quản lý nhóm. Họ nên có thẩm quyền cần thiết. Các cuộc họp mà không ai biết ai thực sự dẫn dắt các cuộc họp là dấu hiệu của sự hỗn loạn trong tổ chức, một vấn đề sâu sắc hơn cần được giải quyết.

Trước tiên, giải quyết các vấn đề chung: chúng ta cần một máy chủ web, máy chủ ứng dụng, DB, v.v.

Đối với các cuộc tranh luận về việc sử dụng DB hoặc máy chủ nào, hãy đỗ các mục đó cho một cuộc họp khác.

Trong các cuộc họp tiếp theo, cho phép thảo luận để "liệt kê ngắn" các dịch vụ tiềm năng, ví dụ MySQl, MS SQL Server, Postgres, v.v.

Cho phép các thành viên trong nhóm nói lên ý kiến ​​của mình, nhưng yêu cầu họ sao lưu chúng với sự thật. Sản phẩm X hút! Không cắt nó, Sản phẩm Y không mở rộng! Là quá mơ hồ. V.v.

Một khi tất cả các chi tiết được đưa ra và trên bàn, bạn cần phải đưa nó vào một cuộc bỏ phiếu hoặc khi trưởng nhóm đưa ra quyết định điều hành.

Nếu bạn cần loại bỏ một người chiến thắng rõ ràng hoặc xác nhận hỗ trợ / thiếu tính năng / khái niệm, hãy dành chút thời gian để thực hiện POC (Proof Of Concept) nhưng nhận ra điều này sẽ mất thời gian và có xu hướng các nhà phát triển muốn chạy với bất cứ điều gì họ đã bắt đầu với ... Hãy chắc chắn xác minh bất kỳ rào cản / mối quan tâm công nghệ nào trước khi đi với POC.

Là một trưởng nhóm, tôi cảm thấy nó phụ thuộc vào việc quyết định phải được đưa ra ở đây và bây giờ.

Nếu nó phải sau đó tôi tìm kiếm một trong những chi phí đảo ngược thấp nhất. Điều quan trọng luôn là, với tư cách là một nhóm phát triển, để biết rằng quyết định của bạn có thể sai, bạn có thể phải đưa ra lựa chọn bóng bẩy và thay đổi suy nghĩ của mình. Chi phí để làm như vậy phải luôn luôn được giảm thiểu.

Nếu nó có thể chờ thì hãy xem xét thực tế là cả hai bên không đồng ý đều sở hữu tất cả các sự kiện. Yêu cầu họ bỏ đi và nghiên cứu thêm và thực hiện nghiên cứu của riêng bạn.

Chúng ta luôn luôn làm điều này trong sức nóng của trận chiến? Không, đặc biệt khi tôi là một trong những người có quan điểm nóng bỏng (tôi không cho là hoàn hảo). Nhưng tôi nghĩ rằng đây là cách để tiếp cận những tình huống như vậy. Time-boxing dường như không bao giờ dẫn đến tất cả mọi người đồng ý, nó chỉ dẫn đến một cuộc tranh cãi không có kết quả.

Trừ khi bạn có một thành viên trong nhóm khó khăn, bạn thường không có cuộc tranh luận bất tận trừ khi không có lợi thế rõ ràng cho cả hai cách tiếp cận. Sau đây là một số cách tiếp cận tốt để phá vỡ một cà vạt:

• Hãy để người thực sự phải thực hiện nó quyết định.
• Đối với các vấn đề UI, hãy để người nhận thức rõ nhất các yêu cầu của khách hàng quyết định.
• Hãy để người có nhiều kinh nghiệm nhất về chủ đề hoặc một phần của cơ sở mã quyết định.
• Hãy để người có các ràng buộc lịch trình nghiêm ngặt nhất hoặc giới hạn nhân lực và nguồn lực quyết định.
• Hãy để người quyết định ai có cụ thể hơn là phản đối lý thuyết.
• Tìm một sự thỏa hiệp giữa các phương pháp.
• Thu thập thêm thông tin và quyết định trong cuộc họp tiếp theo, mang lại nhiều trọng lượng hơn cho những người rõ ràng đã dành thời gian nghiên cứu kể từ cuộc họp cuối cùng.

Theo như cách thông báo quyết định, bạn chỉ cần nói, "Được rồi, chúng ta sẽ làm điều này vì điều này ." Nếu mọi người cảm thấy như bạn đã cho họ một phiên điều trần công bằng và bạn không mơ mộng với tư cách là một nhà lãnh đạo, họ sẽ đi cùng với quyết định của bạn. Đối với những người đặc biệt cứng đầu, bạn có thể hứa sẽ đánh giá lại sau khi một số lượng thực hiện nhất định đã được thực hiện, nhưng hầu hết mọi người sẽ bỏ nó vào thời điểm đó.

Một người điều phối cuộc họp tốt có thể tạo điều kiện cho các loại thảo luận này mà không để chúng ra khỏi tầm tay.