Cấu trúc cuộc họp dự án nào một nhà phát triển nên chọn?


8

Tôi là một nhà phát triển solo làm việc trong một dự án nhỏ với khoảng 3 người khác (không phải nhà phát triển). Những người khác tham gia vào dự án theo những cách không phát triển và một người cũng là quản lý của tôi. Mọi người cũng khá cởi mở để thảo luận ad hoc, quá.

Người quản lý của tôi chỉ cho tôi những gì có vẻ như là một giấc mơ trở thành sự thật - tôi được giao nhiệm vụ xác định cấu trúc cuộc họp nào sẽ hoạt động tốt nhất cho dự án. Đây có vẻ là một cách tuyệt vời để đối phó với cuộc họp quá tải và / hoặc các cuộc họp vô nghĩa .

Với sức mạnh to lớn đi kèm là trách nhiệm lớn, như bây giờ, nếu tôi đề xuất một cái gì đó cuối cùng dẫn đến lãng phí nhiều thời gian thì đó là lỗi của tôi.

Tôi chưa bao giờ có một bảng trống như vậy để nghĩ làm thế nào tôi sẽ tổ chức các cuộc họp. Suy nghĩ của tôi là:

  • Cuộc họp "chạm cơ sở / cập nhật trạng thái" hàng ngày trong 15 phút hoặc ít hơn (tương tự như các cuộc họp chờ) để truyền đạt các mục tiêu hàng ngày và xem xét ngày hôm trước. Hoặc, có vẻ như tôi chỉ cần lấy một bảng trắng và đặt nó ở bàn của tôi để truyền đạt thông tin này.
  • Khi cần các cuộc họp để đưa ra quyết định cụ thể hoặc giải quyết các câu hỏi mà bất kỳ ai trong nhóm có

... Tôi không thấy sự cần thiết của một cuộc họp dự án "tình trạng" hàng tuần. Tôi cũng không chắc viên đạn thứ hai sẽ yêu cầu nhiều cuộc họp chính thức theo lịch trình.

Mối quan tâm của tôi là những "nhà phát triển tập trung" (tức là tôi) có thể gây ra sự xa lánh với người khác hoặc khiến người quản lý của tôi cảm thấy mất kiểm soát đối với dự án, vì cấu trúc này sẽ khác biệt đáng kể so với hầu hết các dự án đang chạy.

Cấu trúc cuộc họp dự án nào một nhà phát triển nên chọn?


Phát biểu ý kiến:

Những người khác đóng góp là gì? Họ có phải là người dùng dự định của dự án này? Làm việc trên các khía cạnh không phát triển của nó (chẳng hạn như chủ đề & hình ảnh trang web hoặc DBA hoặc kiểm tra QA)? Các cấp quản lý / hành chính khác?

Họ là một số người dùng cuối cùng và quan tâm đến quy trình làm việc chung. Họ cũng đang đóng góp cho một số lĩnh vực biểu mẫu / tài liệu (định dạng sẽ không ảnh hưởng đến bất kỳ công việc phát triển nào).

Bạn có thể nhận được phản hồi từ hai thành viên khác không? Một số nhà quản lý cần có một cuộc họp được lên lịch thường xuyên hoặc họ sẽ không bao giờ có thể phù hợp với lịch trình của họ.

Có được thời gian dường như không phải là một vấn đề trong tương lai.


Những người khác đóng góp là gì? Họ có phải là người dùng dự định của dự án này? Làm việc trên các khía cạnh không phát triển của nó (chẳng hạn như chủ đề & hình ảnh trang web hoặc DBA hoặc kiểm tra QA)? Các cấp quản lý / hành chính khác?
Bobson

Bạn có thể nhận được phản hồi từ hai thành viên khác không? Một số nhà quản lý cần có một cuộc họp được lên lịch thường xuyên hoặc họ sẽ không bao giờ có thể phù hợp với lịch trình của họ.
JeffO

Câu trả lời:


3

Là một nhà phát triển duy nhất, vấn đề lớn nhất của bạn là tầm nhìn. Đề nghị của tôi là thực hiện các chu trình nước rút đầy đủ, như trong một dự án Agile. Cứ sau hai tuần, hãy giới thiệu thêm một chút chức năng (điều này có thể diễn ra trong cuộc họp kéo dài nửa giờ đến hàng giờ. Mỗi ngày có một cuộc trò chuyện giải thích những gì bạn đã làm ngày hôm qua, những gì bạn sẽ làm hôm nay và bất kỳ rào cản nào bạn có.

Bằng cách này, bạn sẽ liên lạc với những người khác chính xác nơi sản phẩm đang ở bất cứ lúc nào. Họ sẽ cảm thấy có liên quan, mọi người sẽ biết chính xác tiến trình xây dựng sản phẩm đang ở đâu và các quyết định có thể được đưa ra để loại bỏ / giới thiệu các tính năng khi cần thiết.

Và 10 phút chờ đợi hàng ngày chỉ "lãng phí" một giờ mỗi tuần. Có bản demo dài một giờ mỗi hai tuần một lần giới hạn cuộc họp của bạn ở mức trung bình 1,5 giờ mỗi tuần, điều này không nhiều.


... and decisions can be made to scrap/introduce features as necessary.<--- Cái này. Vì bạn sẽ lên lịch các cuộc họp này với người dùng, việc có thể hiển thị một bản mô phỏng và ngay lập tức nhận được phản hồi về việc liệu nó có đáp ứng nhu cầu của họ hay sẽ cần sửa đổi sẽ giúp mọi người tiết kiệm thời gian.
Bobson

Thời gian chờ 10 phút trên cơ sở hàng ngày "lãng phí" một giờ mỗi tuần cho bốn người ; Điều này không đáng kể. Nếu bạn đang phân phối lặp đi lặp lại, bạn không muốn xem xét lại các tính năng đã chọn mỗi ngày @ # $%, theo cách đó là sự điên rồ;)
Steven A. Lowe

1
Thời gian chờ 10 phút có hai mục đích - để tăng khả năng hiển thị và cho phép người quản lý dự án được thông báo càng nhiều càng tốt về thời gian. Nếu bạn đợi cho đến cuộc họp hai tuần một lần để cho họ biết rằng bạn đang chạy chậm một tuần vì bạn gặp phải lỗi thực sự khó chịu này phải mất một tuần để tìm và sửa, điều đó thực sự tồi tệ cho mọi người khác trong nhóm và nó làm suy yếu họ tin tưởng ở bạn. Standup hàng ngày quản lý khía cạnh con người của phát triển phần mềm, đó là điều mà một số nhà phát triển có thể bỏ qua.
Stephen

@Stephen: nếu bạn giả định chờ 2 tuần trước khi thông báo cho người quản lý / nhóm của bạn về các vấn đề của dự án, có những vấn đề lớn hơn trong trò chơi so với gặp gỡ các chương trình nghị sự. Có một điều kỳ diệu gọi là "điện thoại" và "email" ...: Đợi đã, các nhà phát triển là con người?
Steven A. Lowe

1

không ai

Trừ khi bạn có một cái gì đó đòi hỏi một cuộc thảo luận nhóm tương tác cao ( chẳng hạn như thể hiện một lần lặp ), hoặc chỉ cần được nhìn thấy làm việc, buộc 4 người trong một cuộc họp, thậm chí trong 15 phút, sẽ lãng phí.

Các cuộc họp trực tiếp là hình thức giao tiếp băng thông cao nhất hiện có; chúng cũng là hình thức giao tiếp đắt nhất Sử dụng chúng một cách khôn ngoan, và chỉ khi cần thiết.


2
Tôi không đồng ý; nếu một dự án đủ quan trọng để được khởi động, thì điều đó đủ quan trọng để có một standup hàng ngày. Những điều này hầu như không bao giờ kéo dài hơn 5 phút; đặc biệt là nếu chỉ có một dev và một PO. Nếu bạn không kiềm chế bất kỳ cập nhật nào, bạn sẽ bị cắn vào mông bởi tất cả các cuộc trò chuyện "chờ đợi, đó không phải là điều tôi đã nghĩ", xảy ra quá muộn trong quá trình, dẫn đến những thay đổi dài, tốn kém. Đó là rút ngắn vòng phản hồi mà bạn nên theo dõi chứ không phải kéo dài nó.
Stefan Billiet

@StefanBilliet: nếu bạn muốn rút ngắn vòng phản hồi, hãy cung cấp phần mềm hoạt động và nhấc điện thoại lên. Thường xuyên. Không phải là một fan hâm mộ của standups hàng ngày, đặc biệt là cho một nhóm của một; chi phí quá cao (thời gian họp + thời gian chuẩn bị + thời gian di chuyển + thời gian chuyển ngữ cảnh + chi phí cơ hội) x 4 người x 5 ngày / tuần = $$$!
Steven A. Lowe

Tôi nghĩ rằng chúng ta đang nói về những điều khác nhau ở đây. Nổi bật của tôi / chúng tôi bao gồm tôi thức dậy, vẫy tay chào PO và đi bộ đến bảng điểm của chúng tôi, mỗi sáng, cùng một lúc. Thời gian di chuyển trung bình là khoảng 2 giây, thời gian chuẩn bị là không có, thời gian chuyển ngữ cảnh là không có (làm điều đó trước khi bạn bắt đầu làm việc) và vì chi phí cơ hội: bạn đã mất tôi. Nhấc điện thoại có thể hoạt động, nhưng vẫn kém hiệu quả hơn so với khoảnh khắc đối mặt ngắn.
Stefan Billiet

@StefanBilliet: vâng, chúng tôi đang nói về những điều khác nhau ở đây. Bạn đang nói về những nỗ lực cần thiết để bạn tham dự một cuộc nổi dậy và ngụ ý rằng không có ai khác liên quan (hoặc bạn không lãng phí thời gian chú ý đến họ nếu có);) OP nói rằng có 3 người khác nhóm và đang đề xuất một cuộc họp hàng ngày 15 phút không có mục đích rõ ràng.
Steven A. Lowe

Như tôi đã nói, nếu tất cả những người liên quan nghĩ rằng việc đứng lên là vô giá trị, thì điều đó có nghĩa là những người đã ký vào dự án, đừng quan tâm đến tiến độ của nó. Điều đó cho thấy họ không quan tâm đến thời tiết hay không phải tất cả mọi người vẫn đang đi đúng hướng và nếu có vấn đề hoặc hiểu lầm (luôn luôn có). Nếu những người đó không quan tâm đến nó, thì dự án đó nên bị hủy bỏ, bởi vì điều đó có nghĩa là họ không biết cách mang lại giá trị lâu dài, có ý nghĩa từ nó. Và tôi biết bạn sẽ đề cập đến việc nhấc điện thoại lên, nhưng việc đứng lên hàng ngày có lợi cho các cuộc tranh luận có ý nghĩa hơn là một danh bạ.
Stefan Billiet
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.