Luận văn đề tài quản lý cửa hàng bán linh kiện máy tính CSMS


Đề tài:
QUẢN LÝ DỰ ÁN

Quản lý dự án
TP.Hồ Chí Minh
Trang 2
Quản lý dự án
MỤC LỤC
MỤC LỤC 3
LỜI NÓI ĐẦU 4
1.Khởi động dự án 5
1.1.Phân tích lựa chọn dự án 6
1.2.Tuyên bố dự án (Project charter) 7
1.3.Phạm vi dự án (Scope Statement) 8
1.4.Lựa chọn thành viên và tiêu chí nhóm 9
1.4.1.Thông tin thành viên (CV) 9
1.4.2.Lựa chọn nhóm trưởng 10
1.4.3.Sơ đồ tổ chức 11
1.4.4.Thông tin hội họp 11
1.4.5.Tiêu chí nhóm (Team Contact) 12
2.Lên kế hoạch 15
2.1. Phân rã công việc 15
2.1.1.Cấu trúc phân rã công việc (WBS) 15
2.1.2.Lược đồ Grantt (GranttChart) 17
2.1.3.Ma trận phân bổ trách nhiệm (RAM) 19
2.2. Phân bổ thời gian 22
2.3.Ước lượng rủi ro và giải pháp 24
2.4.Ước lượng chi phí 26
3.Thực thi và kiểm soát dự án 29
3.1.Quản lý chất lượng 29

3.1.1.Coding convention 29
3.1.2.Document convention 29
3.1.3.Quản lý source code 30
3.1.4.Quy trình áp dụng 31
Trang 3
Quản lý dự án
3.2.Cập nhật tiến độ công việc 32
4.Kết thúc dự án 32
4.1.Bài học kinh nghiệm 32
4.2.Đánh giá kết quả 33
4.3.Hướng phát triển 34
Tài liệu tham khảo 34
LỜI NÓI ĐẦU
Quản lý dự án là một kỹ năng rất cần thiết đối với những kỹ sư công nghệ
thông tin khi đi vào làm việc trong thực tế. Kỹ năng này không chỉ giúp nhà quản
trị vạch ra đường hướng đúng đắn trong lựa chọn nguồn tài nguyên (con người,
Trang 4
Quản lý dự án
tư liệu), lựa chọn phương hướng kỹ thuật tiếp cận trong dự án; mà còn giúp họ
ước lượng thời gian, chi phí, rủi ro, cách đánh giá, kiểm soát chất lượng nhằm có
thể quản trị dự án một cách thành công về mặt thời gian, vật chất và kỹ thuật.
Vì chính tầm quan trọng của kỹ năng này trong tương lai, nên nó trở thành
một môn học rất cần thiết, nhằm giúp sinh viên một phần nào tiếp cận với những
dự án thật sự trong tương lai. Với những kiến thức của môn học, chúng tôi đã
cùng nhau thực hiện dự án CSMS (Computer Store Management Software) để áp
dụng những kiến thức ấy vào thực tiễn, đánh giá và nhận biết sự khác biệt những
khó khăn giữa lý thuyết và thực tiễn. Nhưng do năng lực nên không thể trình bày
đầy đủ và cũng có thể gây thiếu sót, sai lầm trong cách nhận thức và trình bày.
Mong thầy cô và các bạn góp ý để bài báo cáo và dự án của chúng tôi có thể
hoàn thiện tốt hơn.

1. Khởi động dự án
Trước khi bắt tay vào làm một dự án phần mềm ta phải có một bước gọi là
bước khởi động cho dự án sắp bắt đầu . Điều này là cần thiết vì dư án cần bắt đầu
với một lời tuyên bố , một cuộc họp ra mắt để các thành viên biết rõ họ đang làm
về các gì .
Thêm vào đó là đề ra tiêu chí hoạt động cho các thành viên trước khi bắt tay
vào xây dựng dư án .
Trang 5
Quản lý dự án
1.1.Phân tích lựa chọn dự án
Việc lựa chọn dự án cũng là một việc rất quan trọng , người nhận dự án phải
biết xem xét dự án nào phù hợp với nhóm làm việc với nhóm của mình và chi phí
của dự án nào sẽ có lợi hơn .
Một trong những kĩ thuật dùng trong việc lựa chọn dự án là dùng “ cây quyết
định” . Cụ thể trước đó nhóm cần phân tích và quyết định lựa chọn một trong hai
dự án : Quản lý cửa hàng bán linh kiện máy tính (CSMS) và Quản lý cửa hàng
bán cây cảnh.
Từ hai dự án trên ta lập ra hai bảng tiềm năng . Bảng này dựa trên một số tiêu
chí mà nhóm đưa ra để đánh giá dự án :
Bảng điểm tiềm năng của phần mềm bán linh kiện điện tử
Tiêu chuẩn thành công Điểm
Có kinh nghiệm về qui trình bán đồ điện tử 5/10
Nắm rõ công nghệ cần sử dụng 5/10
Chịu làm việc nặng – Nhân viên tập trung 5/10
Các công ty bạn có kinh nghiệm về đề án này 5/10
Tổng 20/40
Hình 1.1 – 1. Bảng tiềm năng của phần mềm bán linh kiện điện tử(CSMS)
Bảng điểm tiềm năng của phần mềm bán cây cảnh
Tiêu chuẩn thành công Điểm
Có kinh nghiệm về qui trình bán cây cảnh 0/10

Nắm rõ công nghệ cần sử dụng 5/10
Chịu làm việc nặng – Nhân viên tập trung 5/10
Trang 6
Quản lý dự án
Các công ty bạn có kinh nghiệm về đề án này 0/10
Tổng 10/40
Hình 1.1 – 2. Bảng tiềm năng của phần mềm bán cây cảnh
Từ hai bảng trên thì nhóm cũng đã đánh giá được phần nào lợi ích của
từng dự án dựa trên các tiêu chí : kinh nghiệm về dự án ,công nghệ , nhân viên…
Các tiêu chí này có thể thay đổi tùy theo nhóm đề ra .
Từ đó , ta có thể xây dựng một bảng như sau(thay vì vẽ dưới dạng cây):
Hình 1.1 - 3. Bảng đánh giá thay cho cây quyết định
Ta thấy:
- Phần mềm bán linh kiện máy tính:
EMV = (70.000.000 * 0.5) + (-50.000.000 * 0.5) = 10.000.000.
- Phần mềm bán cây cảnh:
EMV = (50.000.000 * 0.25) + (-20.000.000 * 0.75) = -2.500.000.
Vì EMV của phần mềm bán linh kiện điện tử cao hơn nên làm phần mềm này
độ rủi ro sẽ thấp hơn và có nhiều thuận lợi hơn nên phần mềm quản lý cửa hàng
linh kiện điện tử là dự án được chọn.
1.2.Tuyên bố dự án (Project charter)
Bước đến giai đoạn này , Bản tuyến bố dự án được viết là tài liệu để cho biết
là dự án được bắt đầu . Nội dung văn bản này bao gồm :
• Tên dự án (Cụ thể là Dự án phần mềm bán linh kiện máy tính)
• Ngày bắt đầu , ngày kết thúc
Trang 7
Quản lý dự án
• Ngân sách phải chi cho dự án
• Tên người quản lý dự án (project manager)
• Các kế hoạch cho dự án : khảo sát , thiết kế , lập trình , test , triển khai

• Một bảng vai trò của những người trong dự án : bên dưới là bảng gồm tên
và vai trò của từng cá nhân trong dự án CSMS .
Vai trò Tên Chức vụ Thông tin liên
quan
Người đỡ đầu
dự án
Phạm Thi Vương Director
CIO Nguyễn T. Thanh Trúc Vice –
Director
Project
Manager
Võ Đinh Duy Senior
Manager
Designer Trần Công Danh
Developer NguyễnThanh Hoàng
Tester Đoàn Nhật Trực
• Cuối cùng là chữ ký của những người tham gia
1.3.Phạm vi dự án (Scope Statement)
Sau khi đã có được bản project charter , ta tiến hành lập tài liệu đề ra phạm vi
dự án , một dự án nếu không giới hạn phạm vi thì dễ dàng sai lệch với yêu cầu đề
ra của khách hàng .Thêm vào đó sẽ gây ra trường hợp làm dư những cái không
cần thiết gây tổn hao về mặt nhân lực.
Mục tiêu của Scope Statement là đưa ra những yêu cầu cho dự án , ràng buộc
dự án vào một phạm vi nào đó : bao gồm cả nhu cầu chức năng lẫn phi chức
năng.
Với mục tiêu như thế , nhóm đã đề ra phạm vi cho dự án CSMS như sau :
1. Dễ dàng sử dụng đối với nhân viên nhập/ xuất
2. Cung cấp đầy đủ tính năng tìm kiếm, xem thông tin
3. Lưu trữ thông tin linh kiện, nhân viên, khách hàng
4. Lưu vết hóa đơn nhập hàng, xuất hàng

Trang 8
Quản lý dự án
5. Lưu trữ thông tin linh kiện theo nhóm, nhà sản xuất,… với đầy đủ chi
tiết về linh kiện, chi tiết nhập.
6. Phân quyền quản lý thông tin linh kiện (Admin, …)
7. Khả năng thay đổi linh hoạt một số thông tin: thông tin tiền tệ, thông
tin nhà sản xuất, thông tin các nhóm được phân quyền, thông tin khách
hàng…
Ngoài ra , cuối bản Scope Statement còn đề ra các tài liệu liên quan đến
dự án :
1. Kết quả khảo sát, phân tích và xác định yêu cầu : Kết quả tìm hiểu các
hệ thống đã có ở các công ty như Hoàn Long , Phong Vũ
2. Kết quả phân tích, thiết kế hệ thống
3. Đánh giá của quản trị dự án
4. Tài liệu về bản dự án (Project Charter)
5. Tài liệu về thỏa thuận nhóm (Team contact)
6. Tài liệu về phạm vi dự án (Scope statement)
7. Tài liệu phân rã cấu trúc công việc (WBS)
8. Bảng trình bày dự án sau cùng (Final project presentation)
9. Báo cáo bài học đã gặt hái được (Lession – learned reports)
10.Các tài liệu khác.
Các tài liệu trên là các tài liệu cần thiết trong quá trình làm dự án . Một số tài
liệu trước khi bắt đầu dự án : Project charter , Scope Statement , Team
Constract . Một số tài liệu trong quá trình thực hiện : tài liệu phân tích thiết kế ,
WBS . Và một số tài liệu sau khi kết thúc dự án : learned reports , Manual .
1.4.Lựa chọn thành viên và tiêu chí nhóm
1.4.1. Thông tin thành viên (CV)
Để quản lý tốt nhóm tốt và nắm rõ thông tin của các thành viên trong
nhóm , mỗi thành viên khi tham gia dự án đều phải có một bản CV (Thông tin
các nhân ). Các thành viên có thể dựa vào bản CV này để nắm bắt thông tin của

người cùng tham gia với mình
Dựa vào các CV của thành viên , nhóm trưởng cũng có thể nắm được khả
năng của mỗi người , điểm mạnh yếu để có thể phân công công việc một cách
phù hợp với thế mạnh của người đó .
Trang 9
Quản lý dự án
Hình 1.4.1 – 1. Mẫu CV của thành viên trong nhóm
Các CV của các thành viên cần theo một mẫu thống nhất (như trên). Vì
trong một số dự án, CV của các thành viên có thể gửi cho khách hàng để tăng
mức độ tin cậy.
1.4.2. Lựa chọn nhóm trưởng
Một nhóm muốn hoạt động thì cần phải có nhóm trưởng để điều hành và quản
lý nhóm, giao task cho các thành viên, kiểm soát được thời gian và năng lực các
thành viên trong nhóm.
Một nhóm trước khi hoạt động cần bầu ra một nhóm trưởng để chịu trách
nhiệm cho toàn nhóm. Việc chọn nhóm trưởng trong dự án CSMS dựa trên
những tiêu chí về kĩ năng chuyên môn lẫn kỹ năng mềm.
Trang 10
Quản lý dự án
Hình 1.4.2 – 1. Bảng đánh giá kĩ năng của các thành viên trong dự án CSMS
Dựa vào bảng đánh giá trên : mỗi thông tin kĩ năng có một trọng số nhất
định (tùy vào mực độ mà trọng số cao hơn) . Số điểm chấm cho mỗi kĩ năng
là thang điểm 100 . sau đó lấy trung bình cộng ta sẽ được kết quả cuối cùng .
Nhóm trưởng là người có số điểm cao nhất (Võ Đinh Duy – 62.25)
1.4.3. Sơ đồ tổ chức
Hình 1.4.3 – 1. Sơ đồ tổ chức cho nhóm CSMS
Dựa vào sơ đồ tổ chức trên , nhóm trưởng sẽ có trách nhiệm lấy yêu cầu từ
stake holder và phân bố công việc cho các thành viên trong nhóm : các thành
viên trong nhóm có thể một trong 4 vai trò : analyst , designer , developer , tester.
1.4.4. Thông tin hội họp

Mọi thông tin hội họp trong nhóm đều phải được lưu lại dưới dạng một tài
liệu meeting report , nhằm ghi lại những quyết định trong buổi hội họp đó , để
sau này có tranh chấp về mặt phân công hay quyết định thì có thể lấy tài liệu này
ra để xem xét lại.
Trang 11
Quản lý dự án
Theo tiêu chí của nhóm CSMS , đầu mỗi buổi nhóm trưởng sẽ chỉ định một
thành viên nhiệm vụ ghi chú lại thông tin hội họp cho cả nhóm.
.
Hình 1.4.4 – 1. Mẫu ghi lại thông tin hội họp
Nội dung ghi lại gồm : ngày tháng hội họp , chủ đề cuộc họp ( nếu có ) ,
các nội dung chính trong cuộc họp , phân công công việc (nếu có ) , nếu cần thiết
sẽ ghi thêm tên người ghi bản ghi chú này .
1.4.5. Tiêu chí nhóm (Team Contact)
Khi làm việc nhóm cần đề ra một số tiêu chí trong nhóm , một số quy định
khi làm việc chung với nhau . Để công việc có sự thống nhất , đảm bảo được tiến
độ của dự án . Tài liệu Team contract phục vụ cho việc này nhằm đưa ra các tiêu
chí hoạt động nhóm , các thức làm việc và hội họp .
Dưới đây là một số tiêu chí của nhóm CSMS :
Quy tắc ứng xử:
• Làm việc chủ động tích cực , đề xuất ý kiến , dự đoán rủi ro.
• Nắm rõ các thông tin về thành viên trong nhóm.
• Tập trung làm việc một cách hiệu quả.
Cách thức làm việc:
• Trung thực và cởi mở trong các hoạt động.
• Khuyến khích sự đa dạng.
• Tạo cơ hội để các thành viên nêu ra ý kiến.
• Tiếp cận vấn đề một cách khách quan và tiếp thu ý tưởng
mới.
Trang 12

Quản lý dự án
• Có các cuộc họp tại một thời điểm.
• Liên lạc với nhóm trưởng khi có khó khăn (trễ deadline ,
bugs ….), thông báo nếu vắng mặt trong các cuộc họp.
Phương tiện liên lạc:
• Ưu tiên hàng đầu là Group chung của nhóm:
projectmanagement
Hình 1.4.5 – trang google groups của nhóm CSMS
• Phương tiện liên lạc chung là Yahoo Messenger. Ngoài ra có
thể liên hệ qua mail , số điện thoại ( có trên group ).
• Lịch họp nhóm theo hàng tuần ( gặp trực tiếp ): sáng thứ 5
hàng tuần.
• Các ý kiến nêu trên group cần ngắn gọn , rõ ràng.
Trang 13
Quản lý dự án
• Trong một thời điềm nhóm chỉ thảo luận về một vấn đề và
có một thành viên ghi chú lại (không nhất thiết phải là nhóm
trưởng ).
Cách thức giải quyết vấn đề:
• Khi gặp vấn đề với dự án , các thành viên đều tham gia giải
quyết ( trực tiếp / gián tiếp ).
• Tránh chỉ trích , đỗ lỗi cho nhau .
• Tôn trọng ý tưởng của nhau .
• Công việc có thề phân chia lại để thành viên có thể tập trung
giải quyết vấn đề . ( ví dụ : sẽ giảm nhẹ task cho thành viên
gặp rắc rối để tập trung sửa lỗi).
Hướng dẫn hội họp:
• Trong một tuần phải có ít nhất một cuộc họp gặp trực tiếp
(sáng thứ 5 ).
• Các thành viên cần đi học thường xuyên.

• Có thể liên lạc qua hình thức Yahoo Messenger , nhưng hạn
chế họp online.
• Nhóm có thể có cuộc họp phụ nếu cần thiết.
• Trong mỗi cuộc họp đều có ghi chú lại nội dung của cuộc
họp và thông báo trên Group
projectmanagement
• Trong các cuộc họp cần lấy thêm ý kiến của khách hàng .
Cuộc họp thành công là do sự đóng góp ý kiến của các thành viên trong
nhóm, các thành viên cần tích cực tham gia ý kiến .

Trang 14
Quản lý dự án
2. Lên kế hoạch.
2.1. Phân rã công việc
2.1.1. Cấu trúc phân rã công việc (WBS)
Giai đoạn Công việc
1. Initiation Stage
1. Kick-of project
2. Trainning: Read &
Understand the SDLC
3. Observer the real environmet
of computer store
4. Do Project Charter
5. Do Scope Statement
6. Do Team Contract
7. Do CSMS_WBS
8. Review & Approve
2. Definition & Solution Stage
1. Requirements Definition
1.1. Define user requirements

1.2. Develop prototype
1.2.1. Login Screen
1.2.2. Import Screen
1.2.3. Export Screen
1.2.4. Report Screen
1.2.5. Promotion Screen
1.2.6. Employee Management
Screen
1.2.7. Main Screen
1.2.8. Product Screen
1.2.9. Manufacturer Screen
1.2.10.Supplier Screen
1.2.11.Product Screen
1.3. Review Prototype
1.4. Develop GUI Design
1.5. Review & Approve GUI
Design
2. Design
2.1. Develop Architecture (Class
Diagram)
2.2. Review & Approve
Architecture
2.3. Database design
2.4. Detail design (DBDesign)
2.5. Review Detail design
Trang 15
Quản lý dự án
2.6. Approve Design
3. Construction & Transition
Stage

1. Training MVC
2. Coding
2.1. Writing Code
2.1.1. EmpolyeeManagementForm
2.1.2. ImportForm
2.1.3. ProductForm
2.1.4. ExportForm
2.1.5. ProductTypeForm
2.1.6. SupplierForm
2.1.7. ManufacturerForm
2.1.8. WarrantyForm
2.1.9. PromotionForm
2.1.10.ReportForms
2.2. Review code
2.2.1. EmpolyeeManagementForm
2.2.2. ImportForm
2.2.3. ProductForm
2.2.4. ExportForm
2.2.5. ProductTypeForm
2.2.6. SupplierForm
2.2.7. ManufacturerForm
2.2.8. WarrantyForm
2.2.9. PromotionForm
2.2.10.ReportForms
2.3. Perform unit test
2.3.1. EmpolyeeManagementForm
2.3.2. ImportForm
2.3.3. ProductForm
2.3.4. ExportForm
2.3.5. ProductTypeForm

2.3.6. SupplierForm
2.3.7. ManufacturerForm
2.3.8. WarrantyForm
2.3.9. PromotionForm
2.3.10.ReportForms
2.4. Fix bugs
2.4.1. EmpolyeeManagementForm
2.4.2. ImportForm
2.4.3. ProductForm
2.4.4. ExportForm
2.4.5. ProductTypeForm
2.4.6. SupplierForm
2.4.7. ManufacturerForm
2.4.8. WarrantyForm
Trang 16
Quản lý dự án
2.4.9. PromotionForm
2.4.10.ReportForms
2.5. Perform Integration
3. System Test
3.1. Develop remaining system test
cases
3.2. Perform system test
4. Deployment
4.1. Compose User Manual
5. Complete Construction & Transition
Stage
4. Termination Stage
1. Writing Report
1.1. Init Project

1.2. Plan Project
1.3. Estimate Cost
1.4. Manage Quanlity
1.5. Review
2. Close project
2.1.2. Lược đồ Grantt (GranttChart)
Hình 2.1.2 – 1: Lược đồ Grantt cho 4 giai đoạn chính của dự án
Dự án CSMS được chia thành 4 giai đoạn để thực hiện. Bao gồm:
1. Giai đoạn khởi động dự án (bắt đầu từ 13/09/2009 –> 25/09/2009): lựa
chọn thành viên, đưa ra nguyên tắc làm việc nhóm, tổng hợp yêu cầu người
dùng, xác định phạm vi của dự án.
2. Giai đoạn thiết kế (bắt đầu từ ngày 28/09/2009 -> 18/11/2009): thiết kế
giao diện, cơ sở dữ liệu, kiến trúc của dự án.
3. Giai đoạn thực thi, coding (bắt đầu từ ngày 18/11/2009 -> 02/01/2010):
coding, kiểm thử, tích hợp hệ thống, viết tài liệu hướng dẫn sử dụng.
4. Giai đoạn kết thúc dự án (bắt đầu 05/01/2010 -> 13/01/2010): thực hiện
báo cáo, kết thúc dự án.
Trang 17
Quản lý dự án
Sau đây là chi tiết của mỗi giai đoạn được thể hiện qua biểu đồ Grantt, ứng
với mỗi dòng là một công việc trong WBS:
Hình 2.1.2 – 2: Lược đồ Grantt trong giai đoạn 1: Khởi động dự án
Hình 2.1.2 – 3: Lược đồ Grantt trong giai đoạn 2: Thiết kế
Trong giai đoạn 2, dự án được chia thành hai giai đoạn nhỏ: xác định,
phân tích yêu càu người dùng và thiết kế dữ liệu, kiến trúc dự án.
Trang 18
Quản lý dự án
Hình 2.1.2 – 4: Lược đồ Grantt trong giai đoạn 3: Thực thi coding
Trong giai đoạn này gồm có những giai đoạn như:coding, review coding,
thực hiện kiểm thử, sửa lỗi, tích hợp, kiểm thử toàn hệ thống, viết hướng dẫn sử

dụng.
Hình 2.1.2 – 5: Lược đồ Grantt trong giai đoạn 4: Kết thúc dự án
2.1.3. Ma trận phân bổ trách nhiệm (RAM)
STT WBS Activities
HoangN
T TrucDN DanhTC DuyVD(PM)
1 Initiation
2 Kick-of project D D D D
Trang 19
Quản lý dự án
3 Trainning: Read & Understand the SDLC D D D D
4 Observer the real environmet of computer store I I I D
5 Do Project Charter I I D I
6 Do Scope Statement I D I I
7 Do Team Contract D I I I
8 Do QLCHLKMT_TaskList I I I D
9 Review & Approve R R R A
10 Definition & Solution Stage
11 Requirements Definition
12 Define user requirements R I D A
13 Develop prototype
14 Login Screen I I D I
15 Import Screen D I I I
16 Export Screen D I I I
17 Report Screen I D I I
18 Promotion Screen I I I D
19 Employee Management Screen I I D I
20 Main Screen I D I I
21 Review Prototype R R R A
22 Develop SRS

23 Review & Approve SRS D R R D/A
24 Design
25 Develop Architecture D D I I
26 Review & Approve Architecture I I R R/A
27 Database design R D R D
28 Detail design D I D I
29 Review Detail design I R I R
30 Approve Design I I I A
31 Construction & Transition Stage
32 Training D D D D
33 Coding
34 Compose unit test plan D D D D
35 Review Unit Test Plan R R R R/A
36 Writing Code D D D D
37 Review code R R R R/A
38 Perform unit test D D D D
39 Fix bugs D D D D
40 Perfomr Integration D D D D
41 System Test
42 Develop remaining system test cases D D R R
43 Perform system test R R D D
44 Deployment
45 Compose User Manual I I I D
46 Compose Release Notes D I I I
47 Review Release Notes I R R I
48 Perform final inspection R D D A
49 Install/Deliver Software Package D D I A
Trang 20
Quản lý dự án
50 Support for Acceptance Test I I I I

51 Complete Construction & Transition Stage I I I A
52 Termination
53 Survey customer satisfaction I I I A
54 Archive project asset I I I A
55 Conduct project postmortem I I I A
56 Close project I I I A
Trang 21
1. R Reviewer
2. A Approver
3. D Do
4. I Informed
Quản lý dự án
2.2. Phân bổ thời gian
Trang 22
Quản lý dự án
Chúng tôi dùng sơ đồ AON để minh họa cho kế hoạch phân bổ thời gian
cho công việc
2.2.1. Giai đoạn 1 : Khởi động dự án
Hình 2.2.1 – 1. Sơ đồ mạng AON cho giai đoạn 1 Khởi tạo dự án
2.2.2. Giai đoạn 2 : Thiết kế
Hình 2.2.1 – 2. Sơ đồ mạng AON cho giai đoạn 2 Thiết kế
2.2.3. Giai đoạn 3 : Thực thi coding
Trang 23
Quản lý dự án
Hình 2.2.1 – 3. Sơ đồ mạng AON cho giai đoạn 3 Thực thi coding
2.2.4. Giai đoạn 4 : Kết thúc dự án
Hình 2.2.1 – 4. Sơ đồ mạng AON cho giai đoạn 4 Kết thúc dự án
2.3.Ước lượng rủi ro và giải pháp
Mã rủi ro Nguyên nhân Cách giải quyết
Trang 24

Quản lý dự án
R001 Nhân sự: Một thành viên trong nhóm
bất đồng ý kiến với những thành viên
còn lại nên rời khỏi nhóm.
Tuyển chọn thành viên mới. Xem
xét lại cách thức làm việc nhóm. Cần
thống nhất các tiêu chí giải quyết khi
xảy ra mâu thuẫn.
R002 Nhân sự: Một thành viên trong nhóm
bắt buộc rời khỏi nhóm trong một thời
gian để giải quyết việc cá nhân.
Xem xét lại những công việc của
thành viên ấy, chia sẽ một phần cho
những thành viên khác; kéo dài thời
hạn deadline; hoặc phân công nghiên
cứu những công việc sẽ giúp ích cho
dự án trong tương lai.
R003 Nhân sự: Hai thành viên trong nhóm
xảy ra mâu thuẫn, khi cùng làm việc với
nhau; 2 hướng giải quyết khác nhau cho
cùng một vấn đề, dẫn đến trễ thời hạn
nộp task; năng lực giao tiếp kém.
Nhóm trưởng đứng ra xem xét, lựa
chọn cách giải quyết phù hợp nhất.
Đưa ra những phương hướng giải
quyết chi tiết khi xảy ra mâu thuẫn
như báo cáo nhóm trưởng, tìm hiểu
cách giải quyết vấn đề của thành
viên kia, cũng cố lập luận để trình
bày cách giải quyết của mình.

R004 Nhân lực: Có sự khác nhau về năng lực
chuyên môn giữa các thành viên.
Tìm hiểu rõ điểm mạnh yếu của từng
thành viên đối với từng lĩnh vực.
Dành một khoảng thời gian tự
nghiên cứu cho thành viên ấy, xem
đó như là một phần của công việc.
Phân công thành viên mạnh ở lĩnh
vực ấy làm việc cùng với thành viên
yếu hơn. Thống nhất quy tắc làm
việc, giúp đỡ nhau cùng tiến bộ.
R005 Nhân lực: Năng lực quản lý lãnh đạo
của nhóm trưởng không tốt.
Ban đầu các thành viên hỗ trợ cho
nhóm trưởng liệt kê công việc, theo
dõi tiến độ. Sau 2 tuần mà công việc
tiến triển không theo ý muốn, thì cả
nhóm họp lại để lựa chọn nhóm
trưởng mới.
R006 Thời gian dự án: Các thành viên không
giao nộp task đúng thời hạn, dẫn đến
thời gian dự án kéo dài.
Tìm hiểu nguyên nhân dẫn đến việc
trễ hẹn như do năng lực chuyên
môn, giao tiếp giữa các thành viên
kém, việc cá nhân; mà có cách giải
quyết khác nhau. Nhóm trưởng cần
ước lượng, đánh giá thời gian hợp lý
hơn, đưa ra thời gian dự trữ phù hợp.
R007 Quản lý source doe: Các thành gặp khó

khăn trong việc sắp xếp, merge các
phiên bản source code lại với nhau
Dùng công cụ SVN để quản lý
source. Trainning cách update,
commit source, các xử lý khi xảy ra
Trang 25