Làm thế nào chúng ta có thể lập kế hoạch dự án thực tế trong khi kế toán cho các vấn đề hỗ trợ?

Chúng tôi đang gặp vấn đề trong công việc: chúng tôi đang cố gắng sắp xếp công việc để có thể đánh giá thang thời gian và nhận ngày hết hạn.

Vấn đề là khó lập kế hoạch cho một dự án mà không biết mọi thứ sẽ xảy ra.

Ví dụ, ngay bây giờ chúng tôi đã lên kế hoạch cho tất cả các dự án của chúng tôi cho đến đầu tháng 12, tuy nhiên trong thời gian đó, chúng tôi sẽ có nhiều cuộc họp trong nhà và bên ngoài, hội nghị truyền hình và công việc làm thêm. Thật tốt và tốt khi nói rằng một dự án sẽ mất ba tuần, nhưng nếu có một tuần bị gián đoạn trong thời gian đó thì ngày hoàn thành sẽ bị đẩy lùi một tuần.

Vấn đề là 3 lần:

1. Khi chúng tôi lên lịch các dự án, quy mô thời gian được thực hiện theo nghĩa đen. Nếu chúng tôi ước tính ba tuần, thời hạn được đặt trong ba tuần, khách hàng sẽ được thông báo và không có chỗ cho gia hạn.

2. Công việc tạm thời và như vậy có nghĩa là chúng ta mất thời gian làm việc trong dự án.

3. Đôi khi khách hàng không có thời gian chúng tôi cần để thực hiện công việc, vì vậy đôi khi họ sẽ đến với chúng tôi và nói rằng họ cần một dự án được thực hiện vào cuối tháng ngay cả khi chúng tôi nghĩ rằng công việc sẽ mất hai tháng - chưa kể chúng tôi đã có việc phải làm.

Chúng tôi có một biểu đồ Gantt mà chúng tôi đang cố gắng điền vào tất cả các dự án chúng tôi có và chúng tôi điền vào bảng chấm công, nhưng chúng không được so sánh với biểu đồ Gantt. Điều này gây khó khăn khi nói "Chà, chúng tôi đã lên kế hoạch 3 tuần cho dự án này, nhưng chúng tôi đã mất một tuần ở đây nên thời hạn phải quay lại một tuần."

Nó cũng không chuyên nghiệp để giữ các thời hạn bị thiếu mà chúng tôi đã liên lạc với khách hàng.

Làm thế nào để những người khác đối phó với loại tình huống này? Làm thế nào để bạn quản lý quy hoạch của các dự án? Bạn dành bao nhiêu thời gian "thêm" vào một dự án để tính đến các công việc phi dự án xảy ra trong một dự án? Làm thế nào để bạn đối phó với các vấn đề hỗ trợ và lỗi và công cụ? Những điều bạn không thể giải thích trong quá trình lập kế hoạch?

CẬP NHẬT

Rất nhiều câu trả lời tốt cảm ơn bạn.

Vấn đề là mặc dù khó lập kế hoạch cho một dự án mà không biết mọi thứ sẽ xảy ra.

Đó là điểm quản lý rủi ro. Bạn không thể biết tất cả mọi thứ, vì vậy bạn lên kế hoạch dựa trên những gì bạn biết và xác định những gì có thể có ảnh hưởng nhất đến kế hoạch của bạn và khả năng những điều đó sẽ xảy ra. Đánh giá tác động của lịch biểu tiềm năng bằng cách nói rằng nếu X xảy ra, nó sẽ khiến lịch biểu bị trượt theo ước tính (từ khóa - ước tính) Y ngày hoặc tuần.

Tất cả đều tốt và tốt khi nói rằng một dự án sẽ mất 3 tuần,

Không bao giờ đưa ra một ước tính cụ thể như vậy. Đưa ra một phạm vi hoặc định lượng xác suất đạt được ước tính đó. Ví dụ: giả sử "dự án này sẽ mất từ ​​2 đến 5 tuần" hoặc "có 85% khả năng dự án này sẽ được thực hiện trong 3 tuần và 95% khả năng nó sẽ được thực hiện trong 4 tuần".

Khách hàng cũng không chuyên nghiệp khi nói rằng chúng tôi đã bỏ lỡ thời hạn.

Thật. Tuy nhiên, bạn đang trộn lẫn các khái niệm "ước tính", "lịch trình" và "thời hạn". Ước tính của bạn là một xấp xỉ về thời gian cần thiết để hoàn thành một nhiệm vụ hoặc dự án nhất định và xác suất đáp ứng điều đó. Hạn chót là một ngày do khách hàng áp dụng mà dự án phải được thực hiện để tăng thêm giá trị. Lịch trình là cách bạn sử dụng các tài nguyên có sẵn của mình để đáp ứng thời hạn.

Đôi khi, đơn giản là không thể hoàn thành công việc được giao trong thời hạn và tất cả các ước tính và lập lịch trình trên thế giới sẽ không tạo ra sự khác biệt.

Vì vậy, câu hỏi của tôi ... làm thế nào những người khác làm điều này? Làm thế nào để bạn quản lý quy hoạch của các dự án? Bao nhiêu thời gian "thêm" bạn lên lịch vào một dự án để tính đến bất cứ điều gì xảy ra trong thời gian trung bình?

Tôi khuyên bạn nên đọc hai cuốn sách, cả hai của Steve McConnell: Ước tính phần mềm: Làm sáng tỏ nghệ thuật đen và phát triển nhanh chóng: Lịch trình phần mềm hoang dã thuần hóa . Dự toán phần mềm là tất cả về việc đưa ra các ước tính của bạn, trình bày chúng cho khách hàng và một số khía cạnh của đàm phán và giải quyết các kỳ vọng không thực tế. Rapid Development là quản lý dự án chung, xử lý các vòng đời phát triển, lập kế hoạch, phân bổ nguồn lực và làm thế nào để lên lịch tốt nhất và các dự án ngân sách để đáp ứng các ước tính và thời hạn của bạn.

Tôi sẽ đề nghị đào sâu vào chi tiết quy trình phát triển Scrum . Nó bao gồm các hoạt động sidetracking như vậy theo focus factorsố liệu. Về cơ bản, bạn phải thực hiện 2-3 lần chạy nước rút / lần lặp và sau đó đo hệ số trọng tâm của nhóm của bạn (và đối với mỗi thành viên, điều đó cũng hữu ích). Sau này, bạn sẽ có thể cung cấp các ước tính chính xác hơn bao gồm các hoạt động hàng ngày.

Hãy xem bài viết này - "Yếu tố trọng tâm"

Nếu bất kỳ ai trong số bạn quen thuộc với phát triển Agile, có lẽ bạn đã nghe nói về yếu tố trọng tâm (hoặc yếu tố năng suất). Nó được sử dụng để lập kế hoạch để giúp xác định có bao nhiêu giờ thực tế mà bạn phải làm việc gì đó. Đó là sự khác biệt giữa giờ thực tế của người Hồi giáo và giờ lý tưởng.

Vấn đề về sự gián đoạn là đối với các cá nhân hoặc nhóm được đưa ra, họ có xu hướng xảy ra trong một phạm vi xác suất tương đối nhỏ. Ví dụ: bạn có khoảng số cuộc họp giống nhau mỗi tuần hoặc khoảng cùng số giờ dành cho việc sửa lỗi khẩn cấp mỗi tháng hoặc cùng một khoảng thời gian trả lời câu hỏi cho những người ghé qua bàn của bạn, đặc biệt là khi tính trung bình một khoảng thời gian dài

Rất nhiều kỹ thuật lập kế hoạch hiện đại có tính đến điều đó. Scrum yếu tố nó thành vận tốc. Lập kế hoạch dựa trên bằng chứng cũng sử dụng một vận tốc với khoảng tin cậy cho bất kỳ ước tính nào. Pomodoro tính đến các gián đoạn khi bạn quyết định có bao nhiêu "pomodoros" bạn có thể tin tưởng để hoàn thành trong bất kỳ tuần nào. Tất cả những điều này phụ thuộc vào việc theo dõi các phép đo lịch sử về sự gián đoạn của bạn và bao gồm chúng vào các ước tính của bạn bằng cách nào đó. Tôi khuyên bạn nên xem tất cả trong số họ và nghĩ ra một kỹ thuật sẽ làm việc cho nhóm của bạn.

Lời khuyên tốt xung quanh.

Một điều khác có thể hữu ích để giải quyết các vấn đề hỗ trợ là dành mọi người để hỗ trợ trên cơ sở "vòng tròn" cố định.

Chẳng hạn, nếu bạn có 5 nhà phát triển chỉ định một cho mỗi ngày trong tuần. Khi ngày đó đến, nhà phát triển được chỉ định làm việc cho ngày đó CHỈ hỗ trợ. Ngày hôm sau một nhà phát triển khác tiếp quản hỗ trợ. Bằng cách này, mọi người đều có cơ hội ở lại trong "dòng chảy" của mình, mọi người đều được nếm thử thức ăn cho chó.

Làm thế nào bạn THỰC SỰ chọn để phân chia công việc hỗ trợ thường xuyên không thực sự quan trọng (việc cướp vòng trong tuần chỉ là một ví dụ). Điều quan trọng là giới hạn thời gian hỗ trợ cho các khoảng thời gian cố định. Điều này làm cho thời gian phát triển trở nên dễ đoán hơn với sự đánh đổi rằng bạn không thể "mọi người bỏ mọi thứ" để giải quyết các vấn đề hỗ trợ.

Đây là một kỹ năng thực sự đi kèm với kinh nghiệm và thường mọi người được hỏi trước khi họ có thể đánh giá chính xác một điều như vậy. Tôi đã luôn làm việc trong một nhóm khá gần gũi với phong cách không chính thức, nhưng chúng tôi đã phát triển một vài quy tắc có vẻ như giữ vững.

Đầu tiên, không có nhiệm vụ mất ít hơn một tuần. Luôn ước tính trong vài tuần, ngay cả khi một nhiệm vụ chỉ có vẻ như sẽ mất vài ngày để hoàn thành. Sẽ có một số lý do nó sẽ không được thực hiện trước cuối tuần.

Thứ hai, hãy nỗ lực hết sức để ước tính thời gian thực hiện nhiệm vụ, bao gồm các gián đoạn, các vấn đề hỗ trợ khách hàng, thực hiện thử nghiệm, v.v. Bây giờ, hãy nhân đôi con số đó. Đó là ước tính của bạn (tính theo tuần).

Thứ ba, đảm bảo người quản lý của bạn chưa thêm một số phần đệm vào ước tính của bạn. Nhóm của chúng tôi đã có một người quản lý phàn nàn về ước tính của chúng tôi. Hóa ra anh ta đã nhân nó lên 2.1 (ước tính đệm có nguồn gốc thực nghiệm của anh ta) và chúng tôi đã nhân đôi nó trước khi nói với anh ta.

Nó không phải là một công cụ ưa thích, và có thể không phải là một phương pháp hoàn hảo, nhưng nó hoạt động tốt đáng ngạc nhiên.

Những người làm cần ước lượng để hiểu rằng không có đội là bao giờ 100% trên một dự án. Bạn được nghỉ ốm, nghỉ phép, làm nhiệm vụ bồi thẩm đoàn, nghỉ tang chế, các cuộc họp nhân sự cần thiết (đó là thời gian có lợi!), Các cuộc họp nhóm không liên quan đến dự án, trì hoãn không thể tránh khỏi, nghỉ trong phòng tắm, hỗ trợ làm việc trên các mặt hàng đã được sản xuất, xử lý email, , định cấu hình máy tính mới sau khi máy tính cũ bị chết, trả lời các câu hỏi về công việc trong tương lai và ước tính cho công việc đó, tư vấn cho đàn em, v.v. phải được chứng minh. Thật vô trách nhiệm khi người ước tính giả định hơn 6 trên 8 giờ có sẵn mỗi ngày. Đó là một đảm bảo thời hạn không thể được đáp ứng. Nếu bạn đang đảm bảo thời hạn không thể được đáp ứng, bạn đang đảm bảo một khách hàng không hài lòng.

Bạn hoàn toàn chính xác - thật khó để lập kế hoạch cho một dự án mà không biết mọi thứ sẽ xảy ra. Nhưng điều rất quan trọng là phải theo dõi những thứ là một tiêu chuẩn cũng như các nhiệm vụ mà người đi trước của bạn. Đây là nơi quản lý lịch trình đóng một phần. Tôi đã sử dụng quản lý dự án của Microsoft (phiên bản tiêu chuẩn) bao gồm các tính năng là một phần của phần mềm lập lịch quản lý dự án.

Bạn có thể truy cập http://www.microsoft.com/project/en/us/schedule-man Quản lý.aspx để biết thêm thông tin.

Có vẻ như có rất nhiều nỗ lực tiềm ẩn được rút ra từ các nhóm dự án của bạn mà qua đó bạn đang mất tập trung và vận tốc. Nó có thể là không chính đáng để thực sự tách nhiệm vụ để xử lý

.. vấn đề hỗ trợ và lỗi và công cụ?

cho một nhóm người cụ thể để các thành viên khác trong nhóm có thể tập trung vào các nhiệm vụ phát triển mới. Thông qua đó, tổng sản lượng của họ có thể giảm một chút nhưng chất lượng sẽ được cải thiện vì ít bị phân tâm hơn. Đổi lại điều này sẽ làm giảm số lượng lỗi, do đó, một công việc phi thường khiến nó trở thành dự án của bạn.

Về phần lập kế hoạch, tôi hoàn toàn đồng ý với câu trả lời của Thomas Owens.