タスクおよびリソース管理プロセスの改善

1. **Efficient Task Management**: Prioritize tasks, break large tasks into smaller ones, and use visualization tools (Trello, Asana).
2. **Proper Resource Management**: Allocate resources based on skills, track usage to avoid waste, and ensure balanced distribution.
3. **Automation and Standardization**: Utilize automation tools to increase efficiency and develop standardized processes.
4. **Continuous Review and Improvement**: Conduct regular evaluations and gather feedback to optimize workflows.
5. **Team Skill Development**: Provide training to enhance skills and improve resource utilization efficiency.

Transcript

1. よりよく、寄り添う 経費精算クラウド 株式会社ラクス 「楽楽精算」担当 〒151-0051 東京都渋谷区千駄ヶ谷5-27-5 リンクスクエア新宿 7階 mail: rakurakuseisan@rakus.co.jp www.rakurakuseisan.jp 03-6675-3811（東京） 052-218-6937（名古屋） 011-777-0945（札幌） 06-7660-1231（大阪） 092-688-0220（福岡） 082-909-2689（広島） 受付時間 平日9:30〜18:00 Confidential Cải thiện quy trình quản lý task và quản lý rủi ro của RSS (Offshore⇔Brse) 2024.6.2 BỘ PHẬN PHÁT TRIỂN RAKUS CHUNG
2. ©️ RAKUS Co., Ltd. All Rights Reserved Lưu ý nhỏ: 2 ⮚ Mục đích : Cải tiến quy trình quản lý task và quản lý rủi ro. ⮚ Mục tiêu : ✓ Mọi người hiểu được mục đích chuyển đổi sang quản lý bằng WBS. ✓ Hiểu được quy trình quản lý rủi ro ✓ Đưa ra được hành động tiếp theo. ➢ Phương thức triển khai ✓ Giải thích trong vòng 50p. Sau mỗi sheet sẽ dừng 30s để mọi người ghi lại thắc mắc ✓ Sau khi giải thích xong có 10p giải đáp thắc mắc. (Nếu không kịp sẽ ghi vào ※2) ✓ Sẽ tập trung vào phân tích cấu trúc của file WBS(Ý nghĩa, cách tạo, input,output,cải tiến…) ✓ Đưa ra quy trình quản lý rủi ro ※1: Nội dung được tóm tắt dựa trên nhiều kiến thức của tài liệu Head Fisrt PMP, bối cảnh hiện tại của RSS. Nội dung có thể có các phần được thay đổi nội dung hoặc chứa lỗi. Trong tương lai, nếu điều này được xác định, vui lòng cho phép điều chỉnh. ※2: Đã tạo file Q&A! Nếu có câu hỏi gì, xin hãy ghi vào nhé!
3. ©️ RAKUS Co., Ltd. All Rights Reserved Agenda 1. Bối cảnh hiện tại (5p) 2. Khái quát về WBS (20p) 3. Giải thích về file WBS hiện tại (10p) 4. Quy trình quản lý rủi ro (15p)
4. ©️ RAKUS Co., Ltd. All Rights Reserved 1. Bối cảnh hiện tại
5. ©️ RAKUS Co., Ltd. All Rights Reserved 1．Bối cảnh hiện tại 5 • Hướng phát triển mới của team Offshore ◦ Tăng cường hoạt động cho hệ thống phát triển toàn cầu ◦ Thực hiện nhiều task có quy mô lớn ◦ Làm việc với nhiều team khác nhau • Điều mong muốn ◦ Chủ động hơn trong công việc ◦ Có thể tự quản lý và xử lý được task không cần hỗ trợ ◦ Phán đoán được rủi ro ◦ Hoàn thành task đúng theo yêu cầu ◦ Đảm bảo được tiến độ release
6. ©️ RAKUS Co., Ltd. All Rights Reserved 1．Bối cảnh hiện tại 6 • Tình trạng hiện tại ◦ Chưa có quy trình xử lý cụ thể ◦ Chưa có công cụ phán đoán rủi ro ◦ Số lượng task tăng nhiều việc quản lý sẽ trở lên khó khăn ◦ Với mỗi loại task chưa rõ sẽ thực hiện những gì ◦ Do độ chính xác của các dự án thấp, và phát sinh việc phải sắp xếp lại lịch trình hoặc làm thêm giờ vào giai đoạn cuối, cần đảm bảo không có trường hợp thay đổi thời hạn giao hàng trong vòng 2 tuần cho đến khi hoàn thành phát triển.(Offshore KPI)
7. ©️ RAKUS Co., Ltd. All Rights Reserved 1．Bối cảnh hiện tại 7 • Để dự án hoàn thành tốt thì có các giải pháp như sau: ◦ Tạo quy trình về quản lý ▪ Thu thập yêu cầu (Collect Requirements) ▪ Xác định phạm vi (Define Scope) ▪ Tạo cấu trúc phân rã công việc (Create WBS) ▪ Quản lý được phạm vi (Control Scope) ▪ Xác nhận được phạm vi (Verify Scope) ◦ Tạo công cụ quản lý rủi ro ◦ Quan điểm đánh giá chất lượng ◦ Thiết lập kênh giao tiếp
8. ©️ RAKUS Co., Ltd. All Rights Reserved ２. Tạo cấu trúc phân rã công việc (WBS)
9. ©️ RAKUS Co., Ltd. All Rights Reserved Khái quát Quy trình cấu trúc phần rã công vệch (WBS) 9 Quy trình Tạo Cấu trúc Phân rã Công việc(Work BreakdownStruture) là quy trình quan trọng nhất trong lĩnh vực Quản lý Phạm vi vì đây là nơi thực sự chúng ta xác định tất cả công việc sẽ thực hiện. Và cũng là nơi tạo ra Cấu trúc Phân rã Công việc (hay còn gọi là WBS), đây là đầu ra chính của Quản lý Phạm vi. Mọi công việc mà bất kỳ ai trong nhóm dự án bao gồm cả chúng ta sẽ được ghi lại trong WBS. Nó phân chia dự án thành các gói công việc nhỏ, dễ quản lý hơn, từ đó giúp theo dõi tiến độ, xác định rủi ro và phân bổ nguồn lực hợp lý. Sơ đồ Gantt Biểu đồ PERT
10. ©️ RAKUS Co., Ltd. All Rights Reserved Khái niệm WBS 10 Mỗi quy trình Quản lý Phạm vi được thiết kế để giúp tránh các vấn đề phạm vi gây ra nhiều vấn đề trên dự án. Dưới đây là một số quy trình: • Thu thập Yêu cầu (Collect Requirements) • Thu thập thông tin từ các bên liên quan về những gì dự án cần hoàn thành. • Xác định Phạm vi (Define Scope) • Xác định rõ ràng phạm vi của dự án, bao gồm các sản phẩm, dịch vụ và chức năng sẽ được cung cấp. • Tạo cấu trúc phân công công việc (Create WBS) • Chia nhỏ dự án thành các nhiệm vụ nhỏ hơn, dễ quản lý hơn. • Quản lý Phạm vi (Control Scope) • Theo dõi và kiểm soát phạm vi dự án để đảm bảo rằng nó không thay đổi quá nhiều so với kế hoạch ban đầu. • Xác nhận Phạm vi (Verify Scope) • Xác nhận phạm vi dự án với các bên liên quan để đảm bảo rằng mọi người đều đồng ý. Điều này giúp khi hoàn thành công việc nhóm không bao giờ giao phải sản phẩm sai cho khách hang.
11. ©️ RAKUS Co., Ltd. All Rights Reserved Sơ đồ input & ouput 11 • Nhìn vào sơ đồ thấy được các đầu ra từ quy trình Thu thập Yêu cầu (Collect Requirements) và Định nghĩa Phạm vi (Collect Requirements) trở thành đầu vào cho quy trình Tạo Cấu trúc Phân rã Công việc (Create WBS). Điều này có ý nghĩa là thông tin và yêu cầu cụ thể về dự án được thu thập và định nghĩa trong hai quy trình trước đó sẽ được sử dụng để tạo ra cấu trúc phân rã công việc, tức là phân chia dự án thành các gói công việc nhỏ hơn và quản lý chúng hiệu quả. • Cấu trúc Phân chia Công việc (Work Breakdown Structure) không phải là đầu ra duy nhất của quy trình Tạo Cấu trúc Phân rã Công việc, nhưng đây là đầu ra quan trọng nhất. Ngoài ra, còn có Từ điển WBS(WBS Dictionary), Cơ sở phạm vi(Scope Baseline). Thu thập Yêu cầu Xác định Phạm vi Cấu trúc phân chia công việc Tạo cấu trúc phân công công việc
12. ©️ RAKUS Co., Ltd. All Rights Reserved Input 12 Các đầu vào cho Cấu trúc Phân rã Công việc (WBS) đến từ các quy trình khác. • Tài sản Quy trình Tổ chức (Organizational Process Assets - OPAs): là các kế hoạch, quy trình, chính sách, thủ tục và cơ sở tri thức đặc thù của tổ chức thực hiện, hỗ trợ và ảnh hưởng đến việc quản lý dự án. • Tài liệu Yêu cầu (Requirements Documents): là các tài liệu quan trọng trong quản lý dự án, mô tả chi tiết các yêu cầu của dự án. • Tuyên bố Phạm vi Dự án (Project Scope Statement) là một tài liệu quan trọng trong quản lý dự án, mô tả chi tiết về các mục tiêu, phạm vi và các yếu tố quan trọng khác của dự án. Tài sản Quy trình Tổ chức Tài liệu yêu cầu Tuyên bố phạm vi dự án
13. ©️ RAKUS Co., Ltd. All Rights Reserved Output 13 Các đầu ra của quy trình Tạo Bảng cấu trúc công việc (Create WBS) ⮚Quy trình Tạo Bảng cấu trúc công việc có ba đầu ra chính: Bảng cấu trúc công việc (Work Breakdown Structure), Từ điển Bảng cấu trúc công việc (WBS Dictionary), và Cơ sở cơ bản phạm vi (Scope Baseline). ⮚Nhưng cũng có các đầu ra khác. Khi bạn tạo Bảng cấu trúc công việc, thường nhận ra rằng có các phần của phạm vi mà bạn đã bỏ sót, và có thể nhận ra rằng bạn cần phải thay đổi kế hoạch của mình. Đó là lý do cho việc cập nhật tài liệu dự án. Cấu trúc phân công công việc Phạm vi cơ bản Từ điển cấu trúc phân công công việc Cập nhật tài liệu dự án
14. ©️ RAKUS Co., Ltd. All Rights Reserved Q&A 14 Các biểu mẫu và mẫu từ tài sản quy trình tổ chức của mình. Vì vậy, không cần phải bắt đầu WBS của mình từ đầu phải không? ⮚ Đúng vậy, không cần phải bắt đầu WBS từ đầu. Các tài sản quy trình tổ chức (Organizational Process Assets - OPAs) cung cấp các biểu mẫu và mẫu sẵn có để hỗ trợ trong việc tạo WBS. Sử dụng những tài nguyên này giúp mình tiết kiệm thời gian và đảm bảo tính nhất quán trong quá trình quản lý dự án. Có được phép chỉnh sửa các tài liệu đó cho phù hợp với task không? ⮚ Đúng vậy! Hoàn toàn có thể và thường được khuyến khích chỉnh sửa các tài liệu, biểu mẫu và mẫu WBS từ tài sản quy trình tổ chức (OPAs) để phù hợp với yêu cầu cụ thể của dự án của mình. Các tài liệu này được thiết kế để cung cấp một điểm khởi đầu và hướng dẫn, nhưng chúng cần phải được điều chỉnh để phản ánh đúng phạm vi và mục tiêu của dự án đang thực hiện.
15. ©️ RAKUS Co., Ltd. All Rights Reserved Các kiểu phân rã công việc 15 ⮚Một WBS có thể được cấu trúc theo các cách khác nhau để phù hợp nhất với task và nhóm dự án của mình. ⮚Hai cách phổ biến nhất để thể hiện công việc là theo sản phẩm hoặc theo giai đoạn. (Dự án bên trái đang được phân rã theo sản phẩm) ⮚Việc phân rã công việc giúp quản lý dễ dàng hơn vì điều này có nghĩa là ít có khả năng quên các gói công việc cần phải làm. ⮚Mỗi mục này được gọi là một gói công việc. Đó là một đơn vị công việc mà bạn và nhóm của bạn sử dụng để tổ chức những công việc bạn cần thực hiện để hoàn thành dự án. ⮚Gói công việc là mức thấp nhất trên WBS, các mức cao hơn được sử dụng để phân loại các gói công việc. Khi tổng hợp tất cả chúng thành một WBS lớn, sẽ có được một bức tranh hoàn chỉnh về mọi thứ mà nhóm sẽ thực hiện trong suốt quá trình dự án. Quá trình xác định, mô tả và xác nhận phạm vi của dự án. Quá trình phân chia công việc của dự án thành các phần nhỏ hơn. Quá trình xác định, đánh giá, và xử lý các rủi ro Quá trình xác định tài liệu và xác minh nhu cầu và mong muốn của khách hàng
16. ©️ RAKUS Co., Ltd. All Rights Reserved Phân rã các sản phẩm thành các gói công việc 16 ⮚Tạo sơ đồ phân chia công việc (WBS) là quá trình lấy các sản phẩm và tạo ra các gói công việc để tạo ra chúng. Khi bạn làm điều đó, gọi là phân rã, và đây là công cụ chính mà bạn sử dụng để tạo ra một WBS. Kết thúc quá trình phân tách, bạn sẽ có một số gói công việc cộng lại thành sản phẩm lớn. Artwork and Packaging Tổ chức dự án dựa trên cách bạn làm việc. Đảm bảo đội có đủ thông tin về gói công việc để hoàn thành công việc. Mỗi gói công việc cần được tổ chức một cách gọn nhẹ để dễ dàng quản lý. Work product Tiếp đó, bắt đầu phân chia dự án thành các phần nhỏ và nhỏ hơn. Vậy nên, bạn cần nói chuyện với đội. Họ có hài lòng với việc bạn đã cung cấp đủ thông tin để thực hiện công việc không? Bắt đầu với một sản phẩm lớn. Điều này có nghĩa là bạn nên bắt đầu suy nghĩ về cách bạn sẽ ước lượng các gói công việc khi bạn đang phân tách chúng.
17. ©️ RAKUS Co., Ltd. All Rights Reserved Q&A 17 Làm sao biết liệu nên sử dụng các giai đoạn (phases) hay các sản phẩm (deliverables) cho Bảng cấu trúc công việc (WBS) của mình? ⮚Điều này thực sự phụ thuộc vào dự án cụ thể. Mình muốn trình bày thông tin sao cho cho phép quản lý trong tổ chức của mình có khả năng hình dung và kiểm soát dự án của mình. Vì vậy, nếu hầu hết mọi người trong tổ chức chia dự án theo các giai đoạn, thì mình cũng nên làm như vậy. ⮚Nếu mọi người thực hiện theo cách khác nhau từ dự án này sang dự án khác tại nơi mình làm việc, thì mình có thể đưa ra quyết định của mình dựa trên cách mọi người nghĩ về công việc mà mình sẽ thực hiện. Làm sao tôi biết khi nào tôi đã phân chia công việc thành gói công việc đủ nhỏ? ⮚Câu trả lời ngắn gọn là nên phân chia công việc cho đến khi nó có thể quản lý được. ⮚Cần phải cẩn thận khi tạo ra các gói công việc cho Bảng cấu trúc công việc (WBS) của mình. Nếu phân chia công việc đến mức chi tiết nhất, có thể sẽ lãng phí thời gian của mọi người trong việc xác định chính xác mức độ nỗ lực cần thiết. Ví dụ, "viết biên bản cuộc họp" cho mỗi cuộc họp trong dự án. ⮚Vì vậy, nên phân chia công việc thành các gói nhỏ đủ để mọi người có thể hiểu được cái gì đang được làm và mô tả nó trong từ điển ... và không nên tiến xa hơn.
18. ©️ RAKUS Co., Ltd. All Rights Reserved 3. Giải thích về file WBS hiện tại
19. ©️ RAKUS Co., Ltd. All Rights Reserved Giải thích WBS 19 ⮚Sẽ sử dụng file template WBS hiện tại để giải thích ⮚ File template WBS: https://docs.google.com/spreadsheets/d/1ufKHFQ4jyL6Tv JKQD2irlx0KiP1QcnEsGTsV9epBHQ0/edit#gid=18631377 70 ⮚ Mục đích: Hiện tại và những điểm cần cải tiến để template đạt hiểu quả hơn. ⮚ Mục tiêu : ✓ Đảm bảo các tất các task ở v11.4 không bị chậm tiến độ. ✓ Trở thành dữ liệu input cho việc quản lý rủi ro.
20. ©️ RAKUS Co., Ltd. All Rights Reserved Một số quy tắc khi sử dụng WBS 20 • Quy tắc về cấu trúc WBS ◦ Mức độ phân cấp rõ ràng: WBS nên được chia thành nhiều cấp độ, từ cấp cao nhất (dự án tổng thể) đến các công việc chi tiết nhất. ◦ Phân chia công việc: Mỗi mục trong WBS nên đại diện cho một công việc hoặc một sản phẩm cụ thể cần hoàn thành. ◦ Mức độ chi tiết: Công việc nên được chia nhỏ cho đến khi có thể ước tính thời gian và chi phí chính xác cho từng phần. • Quy tắc về nội dung WBS ◦ Đảm bảo đầy đủ phạm vi: WBS nên bao gồm tất cả các công việc cần thiết để hoàn thành dự án. ◦ Tránh chồng chéo: Mỗi mục trong WBS nên là duy nhất, không trùng lặp với các mục khác. ◦ Đầu ra cụ thể: Mỗi mục tiêu trong WBS nên có một sản phẩm hoặc kết quả cụ thể.
21. ©️ RAKUS Co., Ltd. All Rights Reserved Một số quy tắc khi sử dụng WBS 21 • Quy tắc về quản lý WBS ◦ Gán trách nhiệm: Mỗi mục trong WBS nên được giao cho một người hoặc một nhóm cụ thể chịu trách nhiệm. ◦ Cập nhật thường xuyên: WBS nên được cập nhật liên tục để phản ánh tiến độ và những thay đổi trong dự án. ◦ Sử dụng phần mềm quản lý: Sử dụng các công cụ hoặc phần mềm quản lý dự án để theo dõi và cập nhật WBS dễ dàng hơn. • Quy tắc về kiểm tra và đánh giá WBS ◦ Kiểm tra tính hoàn chỉnh: Đảm bảo rằng WBS bao gồm tất cả các công việc cần thiết và không bỏ sót phần nào. ◦ Đánh giá tính khả thi: Xem xét các nhiệm vụ trong WBS để đảm bảo rằng chúng có thể thực hiện được trong khoảng thời gian và ngân sách đã đề ra. ◦ Phản hồi liên tục: Thu thập phản hồi từ các thành viên trong nhóm và điều chỉnh WBS khi cần thiết để đảm bảo tính khả thi và hiệu quả của dự án.
22. ©️ RAKUS Co., Ltd. All Rights Reserved Tạo rule khi sử dụng WBS 22 Quy trình tạo rule sử dụng: ⮚ Step 1: Sẽ lắng nghe ý kiến toàn bộ member có liên quan đến dự án (★) ⮚ Step 2: Thống nhất ý kiến và tạo ra quy tắc cho file WBS ⮚ Step 3: Công bố và áp dụng. ⮚ Step 4: Cải tiến và bổ sung.
23. ©️ RAKUS Co., Ltd. All Rights Reserved 4. Quy trình quản lý rủi ro
24. ©️ RAKUS Co., Ltd. All Rights Reserved Quản lý rủi ro 24 Xây dựng kế hoạch quản lý rủi ro (Develop risk management plan). • Đây là quá trình tạo ra một kế hoạch để nhận diện, đánh giá và ưu tiên các rủi ro có thể xảy ra, và xác định các biện pháp để giảm thiểu hoặc loại bỏ tác động của những rủi ro đó đối với một dự. Kế hoạch này thường bao gồm các bước cụ thể để xử lý rủi ro và đảm bảo rằng các biện pháp phòng ngừa và phản ứng kịp thời được thực hiện. • Phải có mục tiêu mới có rủi ro. Quy trình thực hiện: • Step1 : Xác định rủi ro (Indentify risk) • Step2: Phân loại rủi ro (Assecc risk) • Step3: Giải pháp kiểm soát rủi ro (Control risk) • Step4: Đánh giá giải pháp (Review controls)
25. ©️ RAKUS Co., Ltd. All Rights Reserved Xác định rủi ro (Indentify risk) 25 Muốn xác nhận được rủi ro phải xác nhận được mục tiêu đang làm gì. Thường có 3 nhóm mục tiêu chính : • Số lượng (Quantity) • Số lượng task release • Thời gian (Time) • Đảm bảo các task release đúng version • Chất lượng (Quality) • Không thiếu phase, code không bug. Một vài rủi ro trong RarakuSeiSan: • Phạm vi dự án (Thay đổi yêu cầu ) • Ước tính (Thay đổi schudelu) • Kỹ thuật (Không đưa được solution, không đủ server) • Quản lý dự án (Phân bổ resource cho các task) • Nhân sự (Thay đổi nhân sự) • Rủi ro bên ngoài
26. ©️ RAKUS Co., Ltd. All Rights Reserved Phân loại rủi ro (Assecc risk) 26 GOAL (Ảnh hưởng) (Khả năng)
27. ©️ RAKUS Co., Ltd. All Rights Reserved Giải pháp kiểm soát rủi ro (Control risk) 27 Thường có những hướng xử lý rủi ro sau: • Ngăn chặn (Prevent) ✓ Đây là cách tiếp cận đơn giản nhất để kiểm soát rủi ro, và nó liên quan đến việc loại bỏ hoàn toàn nguồn gốc rủi ro. • Phát hiện giảm thiểu rủi ro (Mitigation) ✓ Cách tiếp cận này liên quan đến việc thực hiện các biện pháp để giảm thiểu tác động của rủi ro nếu nó xảy ra. • Chuyển giao rủi ro (Transfer) ✓ Cách tiếp cận này liên quan đến việc chuyển giao rủi ro cho một bên khác. • Giữ rủi ro (Retention) ✓ Cách tiếp cận này liên quan đến việc chấp nhận rủi ro và tự chịu trách nhiệm về hậu quả của nó.
28. ©️ RAKUS Co., Ltd. All Rights Reserved Tổng kết 28 • Giải thích về mục đích của việc áp dụng WBS vào quá trình quản lý task của RSS. • Đa trao đổi về quy trình quản lý rủi ro • Hàng động tiếp theo: • Cải tiến WBS để tang tính hiểu quả • Thu thập ý kiến của các member liên quan(RV&Offshore) • Tạo rule khi sử dụng WBS • Tạo quy trình xử lý cho cac loại task ⚫ Tạo quy trình quản lý rủi ro ⚫ Người đảm nhiệm: Brse Chung & PM ⚫ Thời gian hoàn thành v.114
29. ©️ RAKUS Co., Ltd. All Rights Reserved 29