OT thì có rất nhiều nguyên nhân, mình tạm group lại thành các nhóm nguyên nhân chính như sau:
1. Vấn đề của bidding: Estimation sai/thiếu, phương pháp estimation không phù hợp/không đủ để kiểm chứng, hạ giá để lấy dự án,…
2. Vấn đề của internal estimation: PM tin vào estimation của bidding, không thực hiện internal estimation lại; PM mới, chưa hiểu/biết cách estimation cho đúng; WBS thiếu các task chủ chốt, PM/key members không hiểu skill của member để phân task và lập schedule phù hợp
3. Vấn đề monitor actual workdone và adjust/revise schedule: cũng có những dự án làm plan ban đầu khá tốt, nhưng vấn đề lại là lúc chạy theo plan đó thì không biết/không thể monitor các actual workdone của member, từ đó không nắm được đúng tiến độ, không đưa ra action kịp thời; thậm chí có PM không biết cách monitor workdone thế nào nên không keep track được tiến độ, đặc biệt là những lúc dự án gặp critical issue,… nên member liên tục phải OT để recover tiến độ trước đó đã bị chậm.
4. Vấn đề manage, estimate và negotiate các CRs: Có nhiều dự án CRs so với requirement ban đầu scope nở ra khá nhiều nhưng việc manage, estimate và negotiate xử lý các CRs đó chưa thực sự phù hợp; có trường hợp do CRs nhiều nhưng phân tích ảnh hưởng không đủ, do vậy gây ra degrade bugs cho những module đã làm xong
5. Các vấn đề liên quan tới tinh thần làm việc, tuân thủ thời gian làm việc, đi làm đúng giờ,… thì được giải quyết bằng phương pháp khác, ở level cao hơn mức dự án nên mình chỉ chỉ ra ở đây thôi.
Với các nguyên nhân trên đây, mình cũng đề xuất một số giải pháp mà mình cho rằng nếu áp dụng thì có thể sẽ cải thiện được
1. Vấn đề của bidding:
- Giải pháp 1: Chấm dứt giải pháp estimate theo kiểu bốc thuốc bằng cách mỗi con số trong proposal cần giải thích có căn cứ, có lý do, có assumption theo skill member, data historical, và cần có 2 phương pháp estimation khác nhau để so sánh kết quả của 2 estimation, từ đó làm căn cứ ra quyết định lấy con số nào để bidding.
- Giải pháp 2: Trường hợp hạ giá để lấy dự án, vẫn cần giữ lại con số estimation ban đầu và gửi thông tin đó về cho offshore, để SM/PM offshore lấy làm input để làm estimation dự án nội bộ.
2. Vấn đề của internal estimation:
- Giải pháp 1: Không cho phép tailoring là lấy external estimation làm internal estimation để chạy dự án. Tức là 100% dự án offshore sẽ làm internal estimation bao gồm effort, duration, schedule, risk management, assumptions, dependencies,… thì PM và các key members tự họ sẽ làm internal estimation cho dự án của họ, từ đó chính họ sẽ chịu trách nhiệm cho các outcomes của dự án theo estimation của chính họ. Các căn cứ để thực hiện internal estimation cũng cần phải được giải thích hợp lý (reasonable) tức là dựa trên qualification/skill của member, năng suất (nếu có), size của công việc,… không cho phép bốc thuốc để làm estimation.
- Giải pháp 2: Với các PM mới: các PM làm internal estimation dưới 3 lần mình tạm định nghĩa họ là các PM mới, thì SM sẽ pair working với PM mới đó để làm internal estimation, đây cũng là cách để training/coaching PM trong việc tạo ra estimation có căn cứ. Mình nghĩ sẽ có phản biện là mỗi năm Fsoft có 400 PM mới, như vậy effort SM làm sao có đủ để mất time training/coaching như thế? Câu trả lời là nếu không có time như vậy, thì giả định là mỗi PM sẽ lead 7~10 ngườithì khả năng sẽ có 60% số dự án mà 400 PM mới này OT -> sẽ có 1700~2400 members phải OT hàng năm -> con số rủi ro thiệt hại là có thể tưởng tượng được. Vậy tại sao chúng ta không có gắng ngăn chặn trước?
- Giải pháp 3: Tiêu chuẩn hóa phương pháp estimation: Fsoft có khá nhiều phương pháp estimation như Function point (FP), Use-case point (UCP), Work Breakdown Structure (WBS),… nhưng mình đề xuất với các dự án theo Waterfall model thì ít nhất có estimation theo WBS; còn theo Scrum/AGILE model thì ít nhất có estimation theo FP (một dạng khác của Velocity estimation). Tức là nếu dự án định apply waterfall model, nếu k/h đã yêu cầu dự án estimate bằng pp WBS thì tốt, dự án sẽ ko mất công tự vẽ estimate theo WBS nữa, nhưng nếu k/h yêu cầu dự án estimate bằng pp FP thì dự án cần mất công thực hiện estimate theo WBS. Điều này sẽ giúp dự án sắp xếp được trình tự công việc trong dự án theo warterfall dễ dàng.
- Giải pháp 4: Estimate cả con số correction cost trong internal estimation. Thường thì nhiều PM sẽ bảo vệ ý kiến: khách hàng không cho phép/không trả tiền cho estimate correction cost vì đó là nội bộ của FPT. Chính là vì vậy, với internal estimation thì PM càng phải estimate effort correction cost. Mình đã từng thấy dự án bị đội effort lên, phải OT không phải vì plan các task create/review sai mà là vì correction cost dự án bị đội lên quá nhiều; đặc biệt các dự án có thời gian bị overlap cũng lúc phải fix những vấn đề của output trước đó đồng thời phải tạo ra các output mới.
3. Vấn đề monitor actual workdone và adjust/revise schedule:
- Giải pháp 1: Monitor actual workdone một cách định lượng. Trong báo cáo hàng ngày (hàng tuần) của member lên Team lead/PM thì con số phải định lượng. Có thể member thì tự họ sẽ khó đánh giá được workdone của họ tương đương với bao nhiêu % workdone của cả dự án, nhưng họ cần báo cáo trung thực workdone của họ. Ví dụ: Hôm nay em làm 5 tiếng task design và tạo dc 5 page DDD, 8 tiếng coding và code được 3 functions / 200 LOC, 5 tiếng IT và Testing được 50 cases,… và nhiệm vụ của PM/TL mà verify con số mà member báo lên và map nó với workdone của cả dự án. Hiển nhiên PM/TL ko thể cả ngày chỉ ngồi verify con số đó mà tip là chúng ta chỉ check random, giả định là member của dự án đều là nhân viên tốt, vậy con số họ báo cho chúng ta là con số đúng, mỗi ngày chúng ta chỉ take time random check 20% số nhân viên để đảm bảo giả định của chúng ta là đúng. Mình tin là nếu nhân viên biết được đang có người theo dõi (monitoring) công việc của họ thì đa số họ sẽ làm đúng và báo cáo đúng cái mà họ làm.
- Giải pháp 2: Adjust/revise schedule theo actual productivity của assignment. Đa số các PM/TL revise schedule chủ yếu vẫn nhìn vào deadline của deliverables chứ không theo actual productivity của assignment, do vậy ép tiến độ các member quá sức so với năng lực của member đó. Cần nghiêm túc cân nhắc theo actual productivity của assignment.
4. Vấn đề manage, estimate và negotiate các CRs:
- Giải pháp 1: Phân tích ảnh hưởng của CRs theo 3 views: Business flow/Technical resolution/current system, relevant Output work products, overall management đối với các CRs có phán đoán là high impact. Việc này thì Fsoft đã có quy định phải dùng template Change Request form nhưng mình đoán là >80% PM dự án không biết để sử dụng template and/or không biết sử dụng thế nào. Mình xin giải thích đơn giản 3 views mà mình nêu trên như bên dưới:
+ Business flow/Technical resolution/current system: CR sẽ ảnh hưởng thế nào tới hệ thống hiện tại, cách xử lý hoặc business flow thế nào. Chỉ ảnh hưởng tới 1 function hay nhiều functions, 1 sub-system hay nhiều sub-system, 1 flow hay nhiều flow. Từ đó phán đoán được mức độ khó (difficulty) của CR.
+ Relevant Output work products: CR có ảnh hưởng tới các Output của các công đoạn nào như ADD (nếu thay đổi giải pháp, kiến trúc), DDD của Requirement, Coding, Unit testcase, UT result, IT case, IT results? Để làm được phân tích ảnh hưởng này, traceability matrix là input quan trọng. Bỏ qua trường hợp ko làm traceability matrix (và/hoặc làm đối phó) thì với sự trợ giúp của nó thì chúng ta sẽ phân tích dc impact này khá rõ ràng.
+ Overall management: CRs ảnh hưởng tới những việc không phải engineering thế nào, ví dụ: Để làm dc CRs thì chúng ta cần mua thêm license để quét OSS, mua thêm máy móc để làm simulation, rồi tăng giảm HR, thay đổi dependencies… thì đều sẽ kéo theo các effort tương ứng.
Hiện nay đa số các dự án đều mới phân tích impact ở điểm đầu tiên, nên sau đó chúng ta không lường được các effort bổ sung khi bước vào công đoạn implement CR.
- Giải pháp 2: Định nghĩa rõ lại vấn đề CR để các PM hiểu: CR không chỉ đến từ khách hàng, mà đôi khi đến từ chính nội bộ, do vậy chúng ta cần tôn trọng các CR nội bộ xử lý nó như là CR đến từ khách hàng. Nhiều khi chúng ta bỏ qua CR đó để rồi sau đó bị customer gửi cho chúng ta như là một failure, và cuối cùng chúng ta vẫn mất thời gian để xử lý nó như là một failure của hệ thống. Ví dụ: Sau khi làm đúng requirement được viết trong SRS, nhưng khi team tester chạy hệ thống thì thấy không thuận tiện cho user, Tester hoàn toàn có thể phát ra một ticket CR cho team. Khi đó thì PM cũng cần cân nhắc nó như là một CR để thực hiện phân tích ảnh hưởng và re-estimate effort như là CR đó đến từ khách hàng. Hoặc để fix 1 bug thì chúng ta cần restructure một sub-system, vậy chúng ta hoàn toàn có thể phát hành nó như là một CR để thảo luận với khách hàng và negotiate với họ việc chúng ta phân tích ảnh hưởng, re-estimate và re-schedule toàn bộ dự án.
No comments:
Post a Comment