cách để cải thiện thông tin liên lạc giữa các thành viên trên một nhóm phần mềm

Question

Khi đội tuyển tôi vào công trình để chính thức hóa và thiết lập thực hành phát triển hơn, tôi thấy rằng truyền thông dường như thất bại ở những điểm sau đây:

1. Trong một không chính thức cuộc trò chuyện về một dự án một khoảnh khắc tia lửa não trở thành một tính năng/yêu cầu mới. Những "tiện ích" này dường như thất bại thông qua các vết nứt hoặc các chi tiết trở nên mờ sau một thời gian đã trôi qua.

2. Trong các cuộc họp mà mục tiêu hoặc nhiệm vụ không được ủy quyền rõ ràng, các thành viên tham gia cuộc họp có các tài khoản khác nhau về những gì đã thực sự được thảo luận.

3. Là một nhóm chúng tôi không ngừng thử thách (nhiều hơn bây giờ chúng tôi thực sự mong muốn viết chúng) để tạo các thông số kỹ thuật và tài liệu kỹ thuật chi tiết chính xác những tính năng cần có trong dự án.

Câu hỏi của tôi là: một số gợi ý là gì và phương pháp tiếp cận để giải quyết những vướng mắc liên lạc và không hiệu quả? Không có lập trình viên thích viết tài liệu nhưng hy vọng có một cách mà chúng ta có thể tập trung sự hiểu biết và giữ cho thông tin đó rõ hơn và có sẵn trong vòng đời của một dự án ...

Cảm ơn sự giúp đỡ của bạn!

Answer 1

Dính vào chương trình làm việc. Ở lại mục tiêu. Khi mọi thứ bắt đầu tắt hẳn, hãy lên lịch một cuộc họp khác hoặc mang nó đến email sau cuộc họp.

Kết thúc từng cuộc họp với các mục hành động - một danh sách được viết về ai sẽ làm gì và thời điểm dự kiến. Có, điều này có nghĩa là ai đó cần viết/nhập nội dung nào đó trong cuộc họp.

Nếu tài liệu trở nên quan trọng và cần thiết, thì tôi khuyên bạn nên đưa ra các tiêu chuẩn đơn giản và sau đó gắn bó với chúng.

Wiki. Wiki. Wiki. Tất cả thông tin "kiến thức bộ lạc" hữu ích cho nhóm cần phải đi vào một wiki. Cách thiết lập môi trường dev, mẹo gỡ lỗi phổ biến, v.v.

Answer 2

Tại sao không chỉ ghi chú trong các cuộc họp này, trong wiki, để người khác có thể xem, và mọi người có thể sửa đổi nó để làm rõ sự mơ hồ, và sau đó bạn có lời nhắc về những gì đã được thỏa thuận.

Sau đó, bạn có thể lấy các tính năng và đặt chúng vào phần mềm theo dõi lỗi để bạn không mất dấu sự thật là có các tính năng đang chờ được triển khai.

Answer 3

Trước khi kết thúc cuộc họp, người dẫn đầu cần nêu rõ các mục hành động và tất nhiên, ai sẽ thực hiện chúng và nhận được thỏa thuận từ người hoặc người. Một người nào đó nên được chỉ định để tạo ghi chú cuộc họp và đăng chúng. Bạn có thể thử lần lượt trên các ghi chú để tất cả mọi người phải làm điều đó đôi khi. Bạn có thể thử một bậc thầy scrum (nếu bạn đang làm scrum).

Thử một wiki cho ghi chú. Các ghi chú cuộc họp nên bao gồm các mục tác vụ. Tất cả các mục tác vụ phải có ngày liên kết với chúng.

Nếu bạn không thể khiến mọi người nhận ra rằng bản ghi về những gì bạn đang làm là quan trọng, bạn có vấn đề nghiêm trọng với nhà phát triển của mình. Tất nhiên bạn có thể chụp ảnh bảng trắng và ghi chú của nó, nhưng điều đó sẽ không giúp được vấn đề về đọc và bảo trì.

Nhiều lập trình viên (bao gồm cả bản thân tôi) như viết tài liệu khá nhiều.

Answer 4

Đối với # 1: Ban quản trị có ý tưởng mới như thế nào? Tạo một vùng có khả năng hiển thị cao trong môi trường làm việc. Như ý tưởng được thảo luận slap một lưu ý nhắc nhở trên một dính và đặt trên diễn đàn. Giữ cho bảng phân vùng thành các loại (tức là giao diện người dùng, cải thiện hiệu suất, v.v.). Một thành viên có trách nhiệm có thể chịu trách nhiệm sao chép chúng vào một wiki đầy đủ, khi chi tiết cần thêm hoặc ý tưởng đủ tốt để nó xứng đáng với một số nỗ lực thực sự được chi tiêu trong thiết kế.

Đối với # 2: Nếu đội của bạn gặp khó khăn trong việc nhắm mục tiêu, thì chắc chắn người tổ chức mtg phải dành thời gian để chuẩn bị chương trình nghị sự và xét xử cuộc trò chuyện về chủ đề và nhấn mạnh rằng cuộc họp kết thúc đúng giờ. Rời khỏi cuộc họp biết ai phải làm gì.

Đối với # 3: Ai đó phải dẫn đầu khoản phí, hãy tìm các ví dụ về các loại tài liệu và thông số mà bạn muốn xem và lên lịch một thời gian với nhóm để xem xét và thảo luận.

Answer 5

Tôi thấy điều quan trọng là phải ghi lại lý do đưa ra quyết định trên Wiki hoặc bảng sau. Nếu không có nó, trên các mặt hàng quan trọng, nơi hai tùy chọn có thể được triển khai, bạn sẽ thấy một nhà phát triển đảo ngược một số mã của một nhà phát triển khác. Cả hai đều có thể có lý do hợp lệ, nhưng nó là một dấu hiệu rõ ràng của việc thiếu thông tin liên lạc.

Để tránh các vấn đề như thế này, các quyết định quan trọng từ các cuộc họp cần phải được lặp lại, thậm chí tới một tháng sau đó.

Answer 6

Tài liệu mọi thứ, chứ không phải trong email!

Sử dụng thứ gì đó có lịch sử. Tôi đã bị cám dỗ sử dụng Google Wave để theo dõi "Phát triển" của dự án (yêu cầu thay đổi, diễn giải, v.v.). Một wiki cũng sẽ hoạt động nhưng có rào cản cao hơn để chỉnh sửa và có thể được cập nhật bởi ít người hơn. Lửa trại cũng là một phương pháp tốt.

Phương pháp mới (Lửa trại/Sóng) là bản ghi trò chuyện được ghi lại cơ bản mà bạn luôn mở. Lửa trại không có cách nào để "Quảng bá" các quyết định quan trọng, tôi nghĩ rằng họ sẽ bị lạc trong cuộc trò chuyện chung - nhưng với Google Wave và Wikis, bạn có thể liên tục cắt bỏ thông tin không liên quan hoặc cũ. Wikis sẽ cung cấp cho bạn nhiều khả năng định dạng lại mới.

Thực ra, sự kết hợp giữa Wave/Wiki có thể là tốt nhất. Chỉ cần sử dụng wave để nói chuyện loại IM hàng ngày và kéo các chủ đề/quyết định quan trọng lên Wiki.

Một số thực tiễn trong XP (Agile) cũng trợ giúp ở đây. Nếu bạn chọn FULL ON xp (không chỉ gọi các cuộc họp hàng ngày của bạn "Scrums"), bạn sẽ tìm thấy một số trợ giúp quan trọng như yêu cầu theo dõi trên thẻ được cập nhật liên tục hoặc có khách hàng trên trang web để trả lời các câu hỏi quan trọng. Toàn bộ ý tưởng về XP/Agile được dựa trên thực tế là yêu cầu thay đổi và những thay đổi đó cần được theo dõi và chúng có hiệu lực trong lịch phát hành.

Answer 7

Tôi nghĩ rằng một wiki hoặc blog nội bộ có thể tuyệt vời để ghi lại các thủ tục hữu ích cho tất cả các thành viên trong nhóm.

Nhưng một điểm thú vị khác là giao tiếp giữa các lập trình viên khi một số lập trình viên có một nghi ngờ thực hiện. Ví dụ: một lập trình viên không biết cách thực hiện một số chức năng. Vì vậy, nó có thể gửi nghi ngờ của bạn trong một "ứng dụng tin nhắn ngắn", giống như một twitter (nhưng với hơn 140 ký tự). Sau đó, một số nhà phát triển biết cách giải quyết nghi ngờ của mình có thể đăng giải pháp. Tất cả các tin nhắn sẽ được lưu trữ cho đến khi giải pháp được tìm thấy. Vì vậy, tất cả các thành viên khác của nhóm sẽ xem xét giải pháp này trong tương lai.

Tôi nghĩ rằng lược đồ này là tốt đẹp, bởi vì đôi khi các nhà phát triển không muốn "lãng phí rất nhiều thời gian" viết một bài đăng trên blog hoặc một cái gì đó trên wiki.

Answer 8

Tôi sử dụng BaseCamp để quản lý dự án của mình. Các cuộc họp trở thành các buổi động não thú vị, công việc sau đó được ủy nhiệm trên trang web.

Answer 9

Nếu chúng ta đang nói về việc giữ liên lạc theo cách thay thế giọng nói và văn bản, hãy xem http://CircleHubb.com. Không chỉ bạn có thể có một cuộc thảo luận giữa các thành viên của cùng một nhóm nhưng bạn có thể chia sẻ pdf và tài liệu từ, hình ảnh và video. Bạn cũng có thể đặt nhóm của mình ở chế độ riêng tư hoặc công khai. Ứng dụng của họ cũng sẽ sớm xuất hiện.