Làm thế nào để báo cáo tiến độ dự án của tôi (Agile) cho chủ nhân của tôi (người không phải là lập trình viên)?


15

Tôi có một vấn đề về báo cáo tiến độ cho chủ nhân của tôi. Tôi là một lập trình viên bán thời gian, xử lý một dự án phần mềm cho bộ phận (phi kỹ thuật) của trường tôi.

Người liên hệ:
1. Nhân viên thực sự sử dụng phần mềm và đưa ra các yêu cầu tính năng,
2. Sếp của tôi (không phải lập trình viên) và cô ấy không phải là người dùng phần mềm.

Bản chất của dự án:
Đây là một phần mềm được tạo sẵn, được mua từ bên thứ ba. Tôi phải sửa đổi hoặc thêm tính năng / chức năng cho phần mềm này để phục vụ cho nhu cầu của bộ phận. Đây là một phần mềm cần sử dụng trong suốt học kỳ. Không phải tất cả các tính năng cần phải được sử dụng ngay từ đầu.

Do đó, chúng tôi đang sử dụng mô hình Agile: Khi nhân viên cần một tính năng nhất định, họ đưa ra yêu cầu và tôi thực hiện các thay đổi. Đến cuối học kỳ, tôi cho rằng tất cả các tính năng cần thiết sẽ được nâng lên và thực hiện.

Vấn đề:
Mỗi khi sếp hỏi tôi về tiến độ như thế nào, tôi không thể trả lời, vì tôi không biết trả lời thế nào. Tôi không có danh sách đầy đủ tất cả các tính năng cần thiết. Mặc dù tôi đã hoàn thành các tính năng được nêu ra vào tuần trước, tôi vẫn không thể nói với sếp rằng tôi đã "hoàn thành", bởi vì các tính năng mới cũng sẽ xuất hiện và tôi không biết bao nhiêu. Tôi không thể nói "Chúng tôi có bao nhiêu% hoàn thành" cũng như "Chúng tôi sẽ hoàn thành nó bằng xxx". Thỉnh thoảng trong số 3 yêu cầu, tôi quản lý để hoàn thành 2, tôi sẽ nói với sếp của mình "Tôi đã hoàn thành 2, nhưng vẫn còn một tính năng chưa hoàn thành". Sau một thời gian dài, tôi nghe như "Tôi luôn có một cái gì đó không hoàn thành, sau một thời gian dài".

Không thể báo cáo tiến độ làm cho tôi trông thực sự xấu. Đó không phải là về việc tôi đã làm được bao nhiêu, mà là về cách cho mọi người biết. Nếu tôi là người quản lý và nhân viên của tôi liên tục không báo cáo tiến độ cho tôi trong nhiều tháng, tôi sẽ cảm thấy anh chàng này không có khả năng.

Các bạn có ý tưởng nào để báo cáo, hoặc trả lời câu hỏi đơn giản như "tình trạng / tiến trình sửa đổi phần mềm" là gì không?

CẬP NHẬT Sếp của tôi không liên quan trực tiếp đến nhiệm vụ phát triển, vì vậy cô ấy không có manh mối về những gì tôi đang làm hoặc cách chương trình hoạt động. Chúng tôi không gặp nhau thường xuyên vì cô ấy bận, và tôi cảm thấy sẽ lãng phí thời gian vì cô ấy không phải là người dùng chính, cô ấy không biết chi tiết về chương trình.

Tôi gặp gỡ thường xuyên với các nhân viên sử dụng và biết rõ hơn về phần mềm.

Tôi cảm thấy khó khăn để giải thích sự tiến bộ cho ông chủ của tôi.

Câu trả lời:


24

Đây là một vấn đề phổ biến khi bạn là một lập trình viên làm việc độc lập và bạn báo cáo cho ai đó không phải là kỹ thuật.

Những ông chủ như thế hầu như muốn có thể tìm ra một vài điều:

  • Người dùng hạnh phúc như thế nào?
  • Là những điều người dùng muốn thực hiện?
  • Những gì bạn đang làm có xứng đáng với số tiền bạn đang được trả không?

Đốt cháy Agile hoặc bất cứ điều gì khác như thế sẽ là một ý tưởng tồi tệ! Như bạn đã nói, sếp của bạn thực sự bận rộn, vì vậy họ sẽ không có thời gian để tìm hiểu về nó, và có lẽ dù sao cũng không quan tâm đến nó.

Vì vậy, nếu tôi là bạn, tôi sẽ gửi email cho họ báo cáo mỗi tuần một lần có chứa:

  • Một "bản tóm tắt điều hành" khi bắt đầu: "Hoàn thành 3 tính năng trong tuần này và nhận được 2 yêu cầu tính năng mới. Vào đầu tuần này, có 11 yêu cầu tính năng chưa hoàn thành và cuối cùng có 10."
  • Một danh sách trạng thái tính năng, với mỗi câu ngắn gọn, trong ba nhóm:
    1. Các tính năng bạn đã thực hiện trong tuần
    2. Các yêu cầu tính năng xuất hiện trong tuần
    3. Các tính năng khác trong "tồn đọng"
  • Một cuộc thảo luận ngắn gọn về bất cứ điều gì phức tạp hoặc bất thường, tốt nhất là sử dụng ngôn ngữ phi kỹ thuật.

Nếu tôi là sếp của bạn và tôi đã không nhận được bất kỳ báo cáo nào, tôi sẽ rất vui khi nhận được điều đó mỗi tuần. Và nếu tôi muốn một cái gì đó khác biệt, tôi sẽ yêu cầu bạn cho nó.


5
+1. Email cũng sẽ hữu ích cho mọi người, không chỉ ông chủ không xuất hiện bất kỳ số dự án nào. Tất cả các nhà quản lý như một danh sách nhiệm vụ đi xuống.
DBlackborough

Vâng, điều này nghe có vẻ rất hợp lý. Cũng hỏi, bạn sẽ đi đâu lâu dài - liệu có đủ để tiếp tục thực hiện các yêu cầu tính năng theo một thứ tự hợp lý nào đó không? Trong trường hợp đó, chỉ cần tiếp tục làm điều đó. Hoặc sẽ tốt hơn nếu bạn cố gắng tiết kiệm thời gian để nhìn về phía trước và nói rằng "chúng ta sẽ đạt đến điểm mà phần mềm hoàn thiện hơn" hay "chúng ta nên từ bỏ một số yêu cầu tính năng này và xếp chúng thành một số thay đổi sâu rộng hơn "? Nếu vậy, bạn có thể cần phải tự mình tìm ra điều đó, nhưng cũng nói với sếp.
Jack V.

3
Chìa khóa ở đây là biết khán giả của bạn. Nói ngôn ngữ của họ. Như câu trả lời đã nêu nhưng điều rất quan trọng là phải ngắn gọn nhất có thể cung cấp cho họ thông tin thực sự có ý nghĩa với họ. Cô ấy có thể chỉ muốn biết rằng bạn làm việc. Thật khó để một người ở vị trí có thẩm quyền không có đầu mối như voodoo mà bạn làm.
Ominus

Ban đầu tôi đã có điều này trong câu trả lời của mình, và khi suy ngẫm tôi nghĩ điều này tốt hơn. Điều đó thật đơn giản và giúp bạn dễ hiểu liệu tình trạng tồn đọng đang được cải thiện hay trở nên tồi tệ hơn.
Joe McMahon

1
Tôi sẽ xem xét thêm "ghi chú" hoặc phần tương tự để bạn có thể nhận xét về sự tương tác với người dùng dọc theo dòng "Người dùng có vẻ rất vui khi có tính năng X được thêm vào hệ thống" hoặc "Các yêu cầu gần đây đã tập trung vào phần XYZ của hệ thống ". Điều này sẽ cung cấp cho sếp của bạn một số cơ sở để trò chuyện với người dùng nếu nó xuất hiện. Tạo cơ hội để cô ấy thảo luận chính thức về ứng dụng với người dùng của bạn sẽ giúp cô ấy thoải mái hơn với tiến trình của bạn.
TomG

3

Có vẻ như bạn không có cách nào để biết bạn đã hoàn thành hay bạn sẽ hoàn thành bao xa. Vậy được rồi.

Giữ một danh sách các tính năng được yêu cầu, những tính năng được thực hiện, đang tiến hành hoặc chưa bắt đầu. Theo dõi chúng dưới dạng biểu đồ tuần này sang tuần khác trong tổng số trong mỗi danh mục. Điều này sẽ cung cấp cho bạn một tập hợp các điểm mà bạn có thể ngoại suy đến ngày kết thúc. Đó là (chỉ nhìn vào số tính năng "đã hoàn thành")

  • Tuần 1 - 2 hoàn thành
  • Tuần 2 - 5 hoàn thành (2 từ tuần 1, 3 từ tuần 2)
  • Tuần 3 - 8
  • Tuần 4 - 12

Nếu bạn có 16 tuần, bạn có thể hoàn thành khoảng 48 tính năng (đừng quá lo lắng về một số tính năng lớn hơn / nhỏ hơn các tính năng khác, sau 4-5 tuần, nó thường sẽ hết trung bình). Sau đó, bạn có thể báo cáo với mọi người rằng bạn chỉ có thể xử lý số lượng tính năng X. Vào cuối dự án, điều tuyệt đối quan trọng nhất là bạn đã cung cấp các tính năng cần thiết và bạn đã không tự sát trong hai tuần qua. Bằng cách báo cáo theo cách này, bạn có thể rút các yêu cầu chính ra càng sớm càng tốt.

Một điều khác bạn sẽ muốn báo cáo là bạn có bao nhiêu năng lực. "Tôi chỉ nhận được 2 yêu cầu tính năng, nhưng có thể xử lý 3 ... bạn có thể yêu cầu nhân viên nâng cao nhiều tính năng sớm hơn không?"

không chắc chắn tôi đã trả lời hoàn toàn câu hỏi của bạn, vì vậy hãy thoải mái đặt câu hỏi tiếp theo ...


2

Ba từ ... đốt cháy biểu đồ.

Chủ nhân của bạn, cho dù họ có phải là những người nghiện nhanh nhẹn hay chỉ là một người phụ trách các nhà phát triển sẽ đánh giá cao biểu đồ ghi điểm .

Mọi người đều thích hiểu khi nào một dự án sẽ được hoàn thành và tận dụng thời tiết của ngày hôm qua sẽ cung cấp cách thức chính xác và thực tế nhất để dự đoán việc hoàn thành một dự án.


Tôi cho rằng, để làm cho biểu đồ Burn Down hoạt động, tôi sẽ có tất cả các yêu cầu tính năng vào đầu mỗi tháng và biểu đồ đang hiển thị xu hướng tiến triển trong một tháng. Yêu cầu tính năng của tôi đến trong mỗi tuần. Tôi có nên lập biểu đồ BD cho mỗi tuần? Có vẻ lạ khi chỉ hiển thị 3 yêu cầu (ví dụ) cho mỗi tuần.
Janet Smith

Đối với một biểu đồ ghi lại để nắm bắt công việc đúng cách, tất cả các câu chuyện cho một bản phát hành sẽ có ước tính liên quan đến chúng. Tổng số ước tính đại diện cho tổng số điểm cho bản phát hành. Sau đó, khi một câu chuyện được hoàn thành, những điểm đó được thể hiện trên biểu đồ. Bạn có thể thêm những câu chuyện mới vào bất kỳ thời điểm nào ... những câu chuyện đó cứ tiếp tục tăng tổng số điểm.
Bắc Dakotah

Biểu đồ Burn Up sẽ có thể hiển thị tiến trình ngay cả khi các yêu cầu tính năng tiếp tục được truyền vào.
rwong

1

Tôi giả sử rằng bạn làm một lần một ít nhất một lần một tuần và có thể thảo luận về các ưu tiên của bạn với người quản lý của bạn tại thời điểm đó - điều quan trọng từ quan điểm của anh ấy / cô ấy (trước đây rất cần tính năng của anh ấy người khác, v.v.) - và do đó có thể báo cáo bao nhiêu công việc khiến người quản lý của bạn trông ổn được thực hiện so với số lượng công việc bạn có tổng cộng phải làm.

Người quản lý của bạn có thể không tìm kiếm sự cố từng phút; Anh ấy chỉ đang cố gắng xem liệu công việc đang hoàn thành hay chưa, nếu những điều quan trọng đang được chú ý nhiều hơn và rằng bạn không bị chết đuối dưới tải hoặc nhàn rỗi vì bạn bị chặn không tiếp tục.

Lưu ý rằng trong một quy trình nhanh nhẹn thực sự, bạn thực sự có công cụ luôn luôn xuất hiện, nhưng bạn và người quản lý của bạn đồng ý về những gì quan trọng nhất / cần thiết nhất và bao nhiêu trong số đó sẽ phù hợp trong giai đoạn làm việc hiện tại (cho dù đó là một tuần, hai tuần, một tháng ...), chia các công việc thành các phần nhỏ hơn nếu cần để các mảnh sẽ phù hợp với thời kỳ.

Một cuộc đại tu cơ sở dữ liệu lớn mất vài tuần có thể bị phá vỡ như thế này: thiết lập sao lưu, xác minh sao lưu là tốt, thiết kế bố cục cơ sở dữ liệu mới, viết phần mềm chuyển đổi và kiểm tra nó, thiết lập rollback và thử nghiệm nó, thử chuyển đổi máy dàn, thử quay lại cùng một chỗ, và cuối cùng thực hiện chuyển đổi. Mỗi một trong số chúng có thể được chia thành các khối 1 tuần (hoặc ít hơn). Nếu một số bước có thể mất 2 hoặc 3 tuần, bạn sẽ báo cáo bạn đã đi được bao xa trong cuộc họp tiếp theo (nhắm mục tiêu 50% cho 2 tuần, 33% trong 3 tuần, v.v.).

Lý tưởng nhất là bạn có một biểu đồ có những thứ bạn cần làm so với những thứ bạn sẽ làm bây giờ và bạn sẽ kiểm tra các mục "làm ngay" khi bạn đi cùng. Điều này cho phép người quản lý của bạn chỉ cần đi ngang qua và xem có bao nhiêu điều được đánh dấu so với những điều có trong danh sách để làm.


Tôi tin rằng người quản lý mà bạn đề cập ở đây, thường liên quan trực tiếp đến việc phát triển và phân công nhiệm vụ. Người quản lý của tôi không tham gia phát triển. Tôi đã gửi biểu đồ gannt của cô ấy trước đây, nhưng điều đó không có ích, vì tôi đã phá vỡ các nhiệm vụ theo tính năng. Cô ấy không biết chi tiết của dự án, vì vậy nó có vẻ quá sức đối với cô ấy.
Janet Smith

Tôi đang nghĩ về "biểu đồ đầu tiên", như cái này . Lưu ý rằng nó cho thấy bạn đã đi được bao xa, những gì bạn đã hoàn thành ("phải có" ở phía trên, "tốt đẹp để có" ở phía dưới) và đưa ra ý tưởng khi bạn "hoàn thành" với công việc bạn đang có Bạn cần xáo trộn xung quanh cột bên tay phải (mũi tên "chúng tôi đang ở đây" chỉ vào) khi bạn thêm công việc. Bạn vẫn nên có một đối một với người quản lý của mình để đảm bảo cột bên phải "tầm quan trọng của việc này" theo đúng thứ tự.
Joe McMahon

1

Mỗi tuần một lần (tôi giả sử rằng thời gian lặp lại / chạy nước rút trong quy trình nhanh của bạn là một tuần vì lợi ích của ví dụ), hãy làm như sau :

  • giới thiệu công việc mới cho nhân viên, để đảm bảo yêu cầu của họ đã được hoàn thành
  • báo cáo với sếp số lượng yêu cầu bạn đã hoàn thành trong tuần và xác định / mô tả các yêu cầu đó. Tóm tắt ngắn gọn
  • báo cáo với sếp số lượng yêu cầu mới được thêm vào backlog / queue của bạn trong tuần và tổng số yêu cầu
  • nói với sếp những gì (yêu cầu) bạn dự định làm việc vào tuần tới; nói cách khác, các ưu tiên hiện tại. Đây là cơ hội để cô ấy xác nhận hoặc thay đổi chúng và để hai bạn rõ ràng về điều đó
  • nói với ông chủ kế hoạch là gì trong 1-2 tuần sau đó.

Tôi cảm thấy rằng ông chủ của bạn không đủ kỹ thuật để quan tâm hoặc hiểu các thuật ngữ nhanh nhẹn như vận tốc , chủ sở hữu sản phẩm hoặc biểu đồ phát sinh . Mẫu ở trên tránh biệt ngữ như vậy, sử dụng các từ đơn giản hơn như "tồn đọng" và "xếp hàng" theo nghĩa thông thường, và do đó sẽ giúp giao tiếp với sếp của bạn dễ dàng hơn.


0

Tôi sẽ sử dụng vận tốc của mình làm thống kê chính cho anh ấy / cô ấy. Điều này sẽ cho biết có bao nhiêu nhiệm vụ / tính năng mà tôi "đồng ý" để nói trong một tuần cụ thể (hoặc thời gian khác) và số lượng tôi đã hoàn thành. Từ điều này, tôi sẽ đề cập đến một số tính năng quan trọng hơn thực hiện và tại sao điều này đã thay đổi từ các lần lặp lại trong quá khứ. Bạn cũng có thể đề cập đến bất kỳ trở ngại nào mà bạn gặp phải và vượt qua và làm thế nào điều đó ảnh hưởng đến vận tốc của bạn.

Các thống kê khác mà sếp của bạn có thể muốn biết có thể bao gồm số báo cáo lỗi mới được nêu ra, báo cáo lỗi đã đóng và các yêu cầu tính năng mới được gửi. Bạn sẽ phải hỏi trực tiếp hoặc sử dụng phán đoán tốt nhất của bạn để xác định xem cái nào là quan trọng nhất. Cuối cùng, tôi sẽ đưa ra một phác thảo cơ bản về sự tiến bộ và hỏi liệu có bất cứ điều gì khác mà anh ấy hoặc cô ấy muốn biết không. Tất cả những gì ông chủ muốn biết là bạn đang tiến bộ và có bất cứ điều gì bạn cần để làm việc tốt nhất.


0

Đề nghị bạn cam kết báo cáo hàng tuần: Liệt kê các tính năng được yêu cầu. Ghi lại các tính năng thay đổi. Báo cáo những gì bạn đã làm.


0

Tôi sẽ cố gắng để dòng dưới cùng theo cách mà các nhà quản lý hiểu.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Chỉ vì người quản lý của bạn không phải là lập trình viên, đừng nghĩ điều đó có nghĩa là họ mong đợi bạn biết ngày hoàn thành chính xác. Trình bày những con số bạn có. Sau khi người quản lý thấy số lượng yêu cầu nhận được và hoàn thành, người quản lý sẽ thấy tiến trình. Nếu số yêu cầu của bạn vượt quá tầm kiểm soát, người quản lý có thể bước vào và giúp bạn ra ngoài bằng cách ưu tiên trước khi bạn bị quá tải. Và nếu bạn sắp hết việc để làm, họ có thể tìm cho bạn một số dự án phụ nhỏ. Sau tất cả, thật tuyệt khi được nghỉ ngơi một chút trong dự án khi dường như không có ngày kết thúc và ngày làm việc trôi qua nhanh hơn và có ích hơn khi bạn bận rộn.

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.