Báo cáo hàng ngày có thể làm giảm năng suất của nhà phát triển không? [đóng cửa]

Trong một câu hỏi khác , tôi đã hỏi về lý do tại sao các nhà phát triển có thể không thích scrum hàng ngày . Chúng tôi đã nói chuyện với các nhà phát triển và chúng tôi đã quyết định không giữ scrum hàng ngày trong một thời gian (để thử và scrum tùy chỉnh trong lần thử đầu tiên của chúng tôi). Đây là đầu ra của tư vấn với các nhà phát triển trực tiếp.

Mặt khác, chúng tôi không muốn mất đi những phần tốt của scrum hàng ngày, như có cơ hội điều phối các nhà phát triển hàng ngày hoặc xem tiến trình công việc như Chỉ số hiệu suất chính, để sớm hành động.

Thay thế cho scrum hàng ngày, chúng tôi nghĩ về việc yêu cầu các nhà phát triển cung cấp báo cáo hàng ngày với các điều kiện sau:

1. Không cần phải theo bất kỳ định dạng cụ thể. Mỗi định dạng được chấp nhận.
2. Ngay cả khi công việc không được thực hiện, chúng tôi muốn nghe số lượng tiến bộ.
3. Không cần phải đề cập đến thời gian dành cho mỗi nhiệm vụ.
4. Trở ngại phát triển và yêu cầu phối hợp nên được đề cập.
5. Không cần phải bị ám ảnh bởi các báo cáo hàng ngày. Nó không được thực hiện nghiêm ngặt.

Bạn có nghĩ rằng điều này có thể làm giảm năng suất của họ? Bạn đã có bất kỳ kinh nghiệm báo cáo hàng ngày? Bạn có gợi ý nào cho chúng tôi không, để chúng tôi có thể chắc chắn rằng chúng tôi không vi mô ?

Thay thế cho scrum hàng ngày, chúng tôi nghĩ về việc yêu cầu các nhà phát triển cung cấp báo cáo hàng ngày với các điều kiện sau:

Thật là một ý tưởng khủng khiếp.

Bạn có nghĩ rằng điều này có thể làm giảm năng suất của họ?

Đúng.

Tại sao? Một bài thuyết trình bằng lời nói tại một cuộc họp kết hợp việc viết và n người "đọc" báo cáo thành một hoạt động đồng thời. Nói chuyện cộng với Lắng nghe. Hơn và thực hiện với. Câu hỏi được trả lời ngay lập tức.

Viết báo cáo là một sự lãng phí thời gian vì sẽ có câu hỏi và bạn sẽ phải xem lại báo cáo với những người (a) có câu hỏi và (b) không thực sự đọc nó.

Báo cáo hàng ngày, sẽ không được đọc. Chúng nhanh chóng chuyển sang tiếng ồn trong hộp.

"Không cần phải bị ám ảnh bởi các báo cáo hàng ngày". Trong trường hợp nào, tại sao họ?

Bạn có gợi ý nào cho chúng tôi không, để chúng tôi có thể chắc chắn rằng chúng tôi không vi mô?

Đúng. Có một đứng lên hàng ngày. Phải mất vài phút và bạn đã hoàn tất.

Nếu việc đứng lên hàng ngày của bạn mất hơn một vài (15?) Phút, bạn đang chia sẻ quá nhiều chi tiết và cần lên lịch các cuộc họp riêng cho những chi tiết đó. Stand-up hàng ngày là dễ dàng để làm. Sau bản tóm tắt 2 phút, mọi thứ khác có lẽ là chi tiết, không phải cho toàn đội và cần được đẩy vào một cuộc họp tiếp theo. Cuộc họp chuyển sang trọng tâm của người tiếp theo trong ngày.

Tôi đã làm những điều này trong quá khứ, nhưng vào buổi sáng trái ngược với cuối ngày. Thông thường chỉ mất chưa đầy năm phút để điền vào, vì vậy không, tôi không thể thấy làm thế nào sẽ có bất kỳ sự giảm sút nào về năng suất của nhà phát triển. Điều tuyệt vời khi thực hiện vào buổi sáng là nó khiến bạn suy nghĩ về những gì bạn sẽ làm trong phần còn lại của ngày.

Phải nói rằng ...

Chúng tôi thấy rằng đó là nhiều lần hơn không, đó không phải là phương pháp hiệu quả nhất để truyền đạt những gì chúng tôi đã làm ngày hôm trước và những gì chúng tôi sẽ làm việc vào ngày hôm đó. Tại sao? Mọi người thường không đọc chúng. Đó là một nhiệm vụ Outlook được lên lịch, vì vậy mọi người đều gửi chúng ra mỗi ngày, nhưng chúng bị che lấp hoặc chỉ bị bỏ sót hoàn toàn (trừ các khách hàng tiềm năng hoặc quản lý).

Chúng tôi thấy rằng việc đứng lên hàng ngày có giá trị hơn nhiều khi mọi người có xu hướng lắng nghe nhau. Ngoài ra, nếu có một sự hiểu lầm, nó sẽ bị xóa ngay lập tức và ở đó, điều đó có khả năng xảy ra hơn là ai đó trả lời e-mail trạng thái hàng ngày để đặt thêm câu hỏi.

Trong tất cả sự trung thực, cho phép bất cứ ai báo cáo mà không bị ràng buộc dường như là một chút quá xa với phía tự do của phương trình. Nơi tôi làm việc, chúng tôi đi theo vòng tròn và mỗi nhà phát triển đưa ra những điều sau:

1. Những gì đã được thực hiện vào ngày hôm trước. Không phải tất cả các chi tiết nhỏ, nhưng tổng thể.
   • Nếu những điều trên chưa kết thúc, nếu không, những gì cần thiết để hoàn thành và mất bao lâu.
   • Nếu việc trên hoàn thành, nhiệm vụ tiếp theo là gì, yêu cầu gì và thời gian thực hiện.
2. Chặn. Nếu bạn đang làm việc trên Foo, phụ thuộc vào Bar và Bar chưa kết thúc, điều này cần được làm rõ.

Thiết lập một lược đồ chung cho mọi người theo dõi có thể giúp việc duyệt qua một báo cáo nhất định trở nên dễ dàng. Bạn có thể dễ dàng thiết lập một số phương pháp cho mọi người để nhận email với các báo cáo hàng ngày và do đó cho phép mọi người tìm hiểu những gì đang diễn ra.

IMO bất kỳ loại cuộc họp / báo cáo hàng ngày nào đều làm giảm năng suất bởi vì nó, thẳng thắn, hôi thối của quản lý vi mô. Vâng, tôi biết về Scrum và những thứ tương tự và những thứ đó không quá tệ với điều kiện chúng là những cập nhật trạng thái ngắn ("Này, dự án X sắp tới như thế nào?") Nhưng tôi tin chắc rằng nó xúc phạm các nhà phát triển chuyên nghiệp để giữ các tab trên chúng tôi ở mức thấp đó; Nó giống như sử dụng đồng hồ bấm giờ để đảm bảo chúng tôi ở trong văn phòng 8 giờ mỗi ngày hoặc đảm bảo không có tường để bạn có thể theo dõi máy tính của mọi người để xem cửa sổ nào họ mở tại một thời điểm nhất định.

Nếu bạn phải giữ các tab trên mọi người để đảm bảo họ đang làm việc, điều đó có nghĩa là bạn không tin tưởng họ. Nếu bạn không tin tưởng họ, có một vấn đề lớn hơn trong công việc so với vấn đề bạn đang lo lắng.

Nhóm của tôi đã làm scrum khoảng một năm nay. Trước đó, chúng tôi đã có hai cuộc họp một tuần, trong đó mỗi thành viên trong nhóm đã báo cáo về hoạt động của anh ấy / cô ấy trong 2, 3 ngày trước đó. Mỗi cuộc họp kéo dài từ 30 phút đến 1 giờ. Trong trường hợp chúng tôi cần trao đổi thông tin và điều phối công việc của mình, chúng tôi chỉ sử dụng để gặp gỡ các đồng nghiệp của mình và nói chuyện với họ (tất nhiên chúng tôi vẫn làm).

Bây giờ chúng tôi đang làm scrum, chúng tôi thường có ấn tượng rằng một cuộc họp một ngày (mặc dù nó chỉ kéo dài 15 phút) là quá nhiều. Thông thường các báo cáo của một số thành viên sôi nổi: "Không có gì mới kể từ ngày hôm qua". Chúng tôi thường có ấn tượng rằng lược đồ 2 cuộc họp mỗi tuần có hiệu quả hơn.

Một nhược điểm khác là cuộc họp hàng ngày là một sự gián đoạn có kế hoạch (xem bài viết của Paul Graham , điểm 1. Tránh phiền nhiễu): vì bạn biết rằng sự gián đoạn sẽ đến, bạn sẽ không bắt đầu bất cứ điều gì khó khăn trước cuộc họp (cuộc họp hàng ngày có thể diễn ra từ một đến một tiếng rưỡi sau khi bắt đầu làm việc).

Cuối cùng nhưng không kém phần quan trọng, trong khi phản hồi sớm có lợi thế ("Ồ, bạn đang giải quyết vấn đề đó, chúng ta nên thảo luận về vấn đề đó!"), Đôi khi sẽ hiệu quả hơn khi bắt đầu một cuộc thảo luận khi bạn đã sắp xếp ý tưởng của mình trong đầu , bạn có câu hỏi cụ thể và bạn cảm thấy sẵn sàng để thảo luận. Thay vào đó, các báo cáo hàng ngày có thể nhanh chóng gây ra rất nhiều động não không cần thiết và không có cấu trúc. Vì vậy, hãy cẩn thận với phản hồi quá sớm : nó có thể làm bạn bối rối và làm bạn chậm lại.

Vì vậy: trong một số trường hợp, các báo cáo hàng ngày đã làm giảm năng suất của chúng tôi. Trung bình, tôi không có cảm giác rằng họ làm cho công việc của chúng tôi hiệu quả hơn.

CẬP NHẬT

Tôi đã viết câu trả lời ban đầu của tôi vài năm trước, và trong khi đó tôi đã chuyển đổi đội. Trong nhóm hiện tại của tôi, chúng tôi đang thực hiện các cuộc họp hàng ngày theo yêu cầu, tức là khi chúng tôi cảm thấy cần cập nhật trạng thái ngắn. Vì vậy, mỗi ngày có khả năng có một cuộc họp như vậy nhưng chúng tôi không làm điều đó nếu không ai yêu cầu. Chúng tôi có một cuộc họp hồi cứu hàng tuần. Điều này về cơ bản rất giống với cách tiếp cận ban đầu chúng tôi đã sử dụng trong nhóm không nhanh nhẹn trước đây của tôi: các cuộc họp hàng tuần cố định cộng với các cuộc họp theo yêu cầu bổ sung trong suốt phần còn lại của tuần.

Nếu những gì bạn thực sự muốn là một trạng thái thô và để ghi chú về bất kỳ trở ngại nào, cách tốt nhất là yêu cầu họ cho một "email trạng thái hàng ngày" ngắn. Nếu bạn nhấn mạnh quá nhiều vào nó, hoặc lập danh sách những thứ không nên / không nên thì ít nhất một số nhà phát triển của bạn sẽ dành thêm thời gian để tạo ra nó để đáp ứng yêu cầu. Thay vào đó, chỉ cần yêu cầu một email đơn giản. Khi mọi thứ diễn ra trong ngày, hãy nói những câu như "ồ, hãy đặt nó vào email cuối ngày của bạn" và nếu bạn nhận được email cuối ngày thực sự dài, hãy đề cập một cách tình cờ "bạn không cần phải chi tiết như vậy mỗi ngày".

Thật hữu ích khi hiểu rõ về mục đích của bất kỳ cuộc họp hoặc báo cáo nào, đặc biệt là một cuộc được thực hiện bởi mọi người mỗi ngày. Bạn nói lý do là:

chúng tôi không muốn mất đi những phần tốt của scrum hàng ngày, như có cơ hội điều phối các nhà phát triển hàng ngày,

Bạn có ý nghĩa gì khi phối hợp các nhà phát triển ? Những loại công việc cần phối hợp và không được phối hợp bởi các nhà phát triển và người quản lý của họ khi cần thiết? Có lẽ có một số cách bạn có thể xác định các nhiệm vụ sẽ cần phối hợp và chỉ giao tiếp trong những trường hợp đó?

hoặc xem tiến độ công việc như một Chỉ số hiệu suất chính, để sớm hành động.

Nhiều KPI tốt (như thời gian phản hồi của trang web hoặc số lỗi nghiêm trọng) sẽ có thể đo lường được về mặt cơ học và bạn không cần phải trả chi phí cho các nhà phát triển để thực hiện.

Tôi đã phải làm báo cáo hàng ngày ở một số định dạng khác nhau tại nơi làm việc. Nói chung, tôi nghĩ rằng các báo cáo hàng ngày có xu hướng chỉ thêm giá trị cho các nhà quản lý, không phải cho chính các nhà phát triển. Mặc dù các nhà quản lý đạt được lợi ích từ các báo cáo hàng ngày bằng cách có thể cho biết tình trạng chung của từng dự án và khối lượng nhiệm vụ của mỗi nhân viên trong một khoảng thời gian ngắn, nhưng theo kinh nghiệm của tôi, hầu hết các nhà phát triển không bận tâm đọc báo cáo trạng thái của nhau.

Tuy nhiên, có vẻ như bằng cách không thực thi định dạng cho các báo cáo hàng ngày của bạn, bạn làm cho các báo cáo khó đọc hơn và xử lý cho cả người quản lý và nhà phát triển đồng nghiệp, do đó làm trầm trọng thêm vấn đề mất thời gian của nhà phát triển.

Nếu bạn quyết định chuyển tiếp với các báo cáo hàng ngày cho các nhà phát triển của mình, tôi có thể đề xuất sử dụng wiki nội bộ thay vì báo cáo qua email không? Bằng cách đó, bạn không spam hộp thư đến của mọi người, trong khi vẫn duy trì lịch sử trạng thái hàng ngày của mọi người.

Đó là một ý tưởng tuyệt vời để tùy chỉnh các phương thức Agile của bạn để làm cho chúng phù hợp với bạn - vì vậy, danh tiếng cho điều đó.

Vì vậy, thay vào đó, các báo cáo hàng ngày thay vào đó, tôi nói rằng điều này không tốt hơn nhiều so với một cuộc họp hàng ngày, nó vẫn giống như cách tiếp cận "nói cho tôi biết bạn đang làm gì", bạn chỉ khiến mọi người viết nó ra thay vì nói ra.

Đây là một cách tiếp cận khác: thay vì sử dụng các kỹ thuật 'bỏ phiếu' này khi bạn hỏi từng nhà phát triển về tình trạng của họ, thay vào đó bạn sử dụng kỹ thuật 'đẩy'. Nếu nhà phát triển không có gì nhiều để báo cáo, họ không nên báo cáo bất kỳ và tất cả các vấn đề và tiến triển khi chúng xảy ra. Vì vậy, khi họ hoàn thành một mô-đun, họ nên gửi email cho tất cả nhóm đã hoàn thành, đó là trong SCM, nơi có thể tìm thấy tài liệu và tóm tắt ngắn gọn về nó là gì, cách thức hoạt động và / hoặc cách sử dụng nó Nếu họ gặp vấn đề, họ nên gửi email cho nhóm yêu cầu tư vấn, trợ giúp hoặc bất kỳ lời khuyên nào. (vâng, giống như ngày xưa, nơi các đội giao tiếp tốt mà không có sự quản lý vi mô mà chúng ta phải chịu ngày nay)

bạn sẽ thấy rằng điều này hiệu quả hơn và mang tính xây dựng hơn. Bạn sẽ không nhận được báo cáo vô nghĩa vì lợi ích của họ và bạn sẽ có được một nhóm có động lực hơn vì mọi người đều muốn thông báo cho đồng nghiệp của họ về công việc của họ.

Tôi cũng đồng ý rằng việc thay thế các báo cáo hàng ngày bằng một báo cáo là một ý tưởng tồi. Một stand-up hàng ngày là một nơi tuyệt vời để phát âm các ý tưởng và vấn đề. Đây là một trong những lý do tôi thích bảng trắng cũ (mà chúng tôi sử dụng cùng với Jira + Greenhopper). Bảng trắng là nơi nhóm 'trò chuyện' và chia sẻ thông tin, mọi thứ đều ở đó, mọi thứ đều có thể nhìn thấy, mọi người di chuyển và thay đổi các hình dán mà họ làm việc, điều đó cũng rất thú vị.

Bạn không thể trích xuất thông tin này từ các công cụ khác của bạn?

• Hiện tại bạn đang làm việc trên cái gì? Những vé tôi đã chỉ định.
• Tiến bộ của bạn là gì? Đối với vé tôi có hơn 1 ngày, xem ý kiến ​​trong vé hoặc cam kết tin nhắn của chi nhánh. Vé tôi có ngắn hơn: có thể được thực hiện vào ngày mai (bạn không kiếm được hơn 5 vé ngày, vâng?)
• Tiến độ chung là gì? xem tỷ lệ mở / đóng vé
• Những gì cần phải được tổ chức? vé bạn được chỉ định trở lại, với phản hồi trạng thái cần thiết và mọi thứ được thảo luận trong IRC của nhóm bạn, Phòng lửa trại, bất cứ điều gì.

Khi bạn có câu hỏi cụ thể hơn để trả lời, tôi sẽ thấy sự cần thiết phải báo cáo cụ thể, nhưng không có điều đó, báo cáo của bạn trông giống như một kết thúc.