Có một yếu tố liên quan giữa thời gian họp và tiết kiệm thời gian phát triển?

Tôi đang làm việc trên một dự án và chúng tôi có các cuộc họp không chính thức (thường là hàng tuần), nơi chúng tôi thảo luận về tình trạng của dự án và GUI của dự án.

Tôi là nhà phát triển duy nhất ở đó, 4-5 người khác có nền tảng phi CNTT.

Cuộc họp này diễn ra lâu hơn bình thường, nhưng tại một thời điểm, một trong những đồng nghiệp của tôi đã hỏi về một số lĩnh vực trong chương trình và cách họ được lấp đầy. Tôi đã trả lời và trong cuộc thảo luận tôi nhận thấy rằng tôi hoàn toàn hiểu sai về quy trình.

Nhưng vì chúng tôi đã nói về nó và phát hiện ra lỗi trước đó, tôi có thể thay đổi nó khá nhanh.

Trong khi suy nghĩ về điều này, tôi đã tự hỏi mình, liệu có yếu tố nào giữa thời gian họp khi nói đến việc tiết kiệm thời gian phát triển không?

Ví dụ: 1 phút thời gian họp có thể tiết kiệm X phút thời gian phát triển.

Nếu vậy, điều này sẽ giúp xác định, tần suất và thời gian các cuộc họp của chúng tôi sẽ diễn ra.

(Chỉ cần làm rõ: Tôi không muốn tổ chức các cuộc họp tốt hơn, thậm chí có thể xác định khoảng thời gian của các cuộc họp là không bắt buộc. Tôi chủ yếu quan tâm NẾU có mối quan hệ giữa thời gian họp và thời gian phát triển! Lý do của tôi muốn hỏi: sự tò mò! )

"Miễn là họ cần, và không còn nữa."

Điều cần nhận ra ở đây là thời gian họp để tiết kiệm thời gian phát triển là không theo cách tuyến tính. Đối với nhóm của bạn, cho công ty của bạn, ví này chủ đề, sau đó 1 giờ các cuộc họp có thể tiết kiệm 2 giờ làm việc dev. Nếu bạn có 10 giờ họp, một giờ họp khác có thể tiết kiệm 0 dev công việc. Chết tiệt, nó có thể giúp bạn tiết kiệm -2 giờ làm việc do bị gián đoạn hoặc ảnh hưởng đến tinh thần.

Cuối cùng, toàn bộ quan điểm của các cuộc họp là giao tiếp và hợp tác giúp bạn hoàn thành công việc. Nếu các cuộc họp không giúp bạn hoàn thành công việc thì họ sẽ bị giết.

Không chính xác.

Hiểu khách hàng / các bên liên quan có thể tiết kiệm thời gian phát triển. Và các cuộc hội thoại cần phải đủ dài để tạo điều kiện cho sự hiểu biết. Nhưng, thảo luận về một tính năng mà bạn đã cho là hiểu sẽ không nhất thiết phải cải thiện sự hiểu biết của bạn.

Nếu không ai trong phòng có bất kỳ nghi ngờ nào về sự hiểu lầm hoặc giả định sai, hãy rời khỏi phòng. Kéo dài một cách "thảo luận" một cách giả tạo với hy vọng rằng thời gian và áp lực cắt giảm sẽ đẩy một cuộc xung đột ra ngoài và tạo ra sự hài hòa là vô vọng và làm mất tinh thần.

Và hãy nhớ rằng giao tiếp là sự kết hợp giữa kỹ năng và may mắn; thảo luận không nhất thiết ngụ ý giao tiếp (hiểu lẫn nhau). Tất cả sẽ tốt hơn khi phơi bày những giả định tồi tệ khi bạn làm việc trong lĩnh vực này lâu hơn và bạn làm việc cùng nhau lâu hơn.

Trong khi đó, "Agility" có thể hữu ích.

Giữ các cuộc họp "ngắn" và triển khai các UI hoặc mockup thô sơ càng sớm càng tốt sau mỗi cuộc họp - ngay cả trước khi bạn nghi ngờ có sự hiểu biết đầy đủ. UI / giả của bạn sẽ đóng vai trò là tài liệu để làm rõ những hiểu lầm. Thời gian giữa các cuộc họp sẽ giúp mọi người giải nén và suy ngẫm về những gì đã nói. Và nếu bạn triển khai các tài liệu giới thiệu và mã của mình , bạn cũng đã thực sự bắt đầu phát triển. (Và khách hàng / đồng nghiệp của bạn sẽ vui mừng khi nghe điều này!)

Và trường hợp xấu nhất, khi bạn đã triển khai một đoạn mã nhỏ có thể nhìn thấy : Bạn hoàn toàn không có cơ sở và bạn vứt nó đi. Nhưng, nếu bạn chỉ dành một khoảng thời gian nhỏ, khoản đầu tư sẽ mang lại kết quả lớn trong việc làm rõ sự hiểu lầm thô.

Và hãy nhớ rằng, công ty không quan tâm đến thời gian phát triển ; nó chỉ quan tâm đến thời gian cá nhân . (Là một phương tiện để tính tổng chi phí , hãy nhớ đến bạn.) Vì vậy, bạn cần tìm kiếm sự cân bằng trong đó thời gian của con người được giảm thiểu; không dành thời gian viết mã.

Tôi không tin có bất kỳ loại tương quan nào có thể được áp dụng chung. Nó thực sự phụ thuộc vào cuộc họp và những điều bạn làm ở đó liên quan đến sự phát triển.

Trong tình huống bạn mô tả, trong vài phút bạn đã đi từ yêu cầu kém hoặc hiểu kém sang có một yêu cầu tốt hơn. Chúng tôi biết rằng có những yêu cầu tốt có tác động trực tiếp đến thời gian phát triển.

Nhưng nếu cuộc họp của bạn giống như cuộc họp của công ty. Bạn chia sẻ thông tin tốt để bạn biết công ty đang hoạt động như thế nào, nhận thức được những điều khác đang diễn ra, v.v. Nhưng, phần lớn, điều đó sẽ không ảnh hưởng gì đến thời gian phát triển dự án của bạn. Tất cả thời gian đó là "lãng phí" khi nhìn nó từ góc độ phát triển.

Khi bạn đã phải đi đến đủ các cuộc họp, bạn bắt đầu nhận ra rằng một số người thực sự có năng suất (ví dụ: có một nhóm phát triển nhỏ và một loạt các yêu cầu tốt và bắt đầu quét bảng kiến ​​trúc. Bạn có thể hoàn thành rất nhiều việc nếu bạn tập trung .). Bạn cũng tìm thấy một số hoạt động không hiệu quả hoặc thậm chí có năng suất âm (một khi khách hàng đã có một cuộc tranh luận 15 phút giữa một vài người trong số họ về việc một trang đăng nhập sẽ nói "Đăng nhập" hoặc "Đăng nhập". cuối cùng, không ai biết và nó phải được lập bảng cho đến sau này).

TL / DR: Phụ thuộc vào cuộc họp, con người và mục tiêu của cuộc họp.