Bài tập so sánh môn Quản trị dự án | Trường Đại học Thăng Long

Tiêu chí

Lý thuyết (Waterfall)

Thực tế tại Ekotek (Waterfall)

Khác biệt

Tần suất giao tiếp

Không thường xuyên, chủ yếu diễn ra ở đầu và cuối mỗi giai đoạn (phase-gate meetings).

Hàng tuần hoặc theo mốc dự án (milestone). Có thêm họp weekly nội bộ cho các dự án lớn.

Thực tế linh hoạt hơn: Ekotek duy trì họp định kỳ hàng tuần ngoài các cuộc họp mốc dự án, giúp tăng cường giao tiếp so với lý thuyết (chỉ tập trung vào phase-gate meetings).

Hình thức giao tiếp

Trang trọng, dựa trên văn bản (BRD, SRS, Change Request Forms), email chính thức, tránh trao đổi miệng.

Trang trọng, ưu tiên văn bản (email, tài liệu), ghi lại mọi vấn đề để tránh hiểu nhầm.

Tương đồng: Cả lý thuyết và thực tế đều nhấn mạnh tính trang trọng và tài liệu hóa. Ekotek tuân thủ chặt chẽ nguyên tắc tránh trao đổi miệng để giảm rủi ro.

Luồng thông tin

Từ trên xuống, tuần tự, qua các cổng giai đoạn (phase gates).

PM là đầu mối chính, tổng hợp vấn đề từ đội và truyền đạt đến khách hàng.

Tương đồng nhưng thực tế tập trung hơn vào PM: Tại Ekotek, PM đóng vai trò trung tâm trong mọi luồng thông tin, kể cả khi xử lý vấn đề, thay vì chỉ dựa vào tài liệu như lý thuyết.

Vòng lặp phản hồi

Chậm, chỉ phát hiện sai sót ở giai đoạn kiểm thử hoặc nghiệm thu cuối dự án.

Chậm, nhưng có báo cáo định kỳ (hàng tuần/2 tuần) để cập nhật tiến độ và rủi ro.

Thực tế cải thiện vòng lặp phản hồi: Báo cáo định kỳ và họp milestone giúp phát hiện vấn đề sớm hơn so với lý thuyết, dù vẫn chậm hơn Agile.

Sự tham gia của khách hàng

Chủ yếu ở giai đoạn đầu (yêu cầu) và cuối (nghiệm thu).

Tham gia ở các mốc nghiệm thu từng giai đoạn (SRS, UI/UX, beta).

Thực tế tăng cường sự tham gia của khách hàng: Ekotek tổ chức nghiệm thu từng giai đoạn, giúp khách hàng tham gia nhiều hơn so với lý thuyết.

Công cụ giao tiếp

Email, MS Project, tài liệu Word/PDF.

Email, Google Sheet, Jira, tài liệu chính thống.

Thực tế hiện đại hơn: Ekotek sử dụng các công cụ như Jira và Google Sheet, bổ sung cho email và tài liệu truyền thống, tăng hiệu quả quản lý và theo dõi.

Quản lý thay đổi

Quy trình kiểm soát thay đổi nghiêm ngặt (Change Request Forms, Change Control Board).

Thay đổi phải được phê duyệt chính thức qua tài liệu Change Request và comment trên Jira/Google Sheet.

Tương đồng: Cả lý thuyết và thực tế đều yêu cầu quy trình thay đổi trang trọng, nhưng Ekotek tích hợp thêm công cụ hiện đại (Jira) để quản lý.

Trọng tâm

Tuân thủ kế hoạch và tài liệu đã duyệt.

Tuân thủ kế hoạch dài hạn, nhưng có báo cáo tiến độ thường xuyên để điều chỉnh.

Thực tế linh hoạt hơn một chút: Báo cáo định kỳ giúp điều chỉnh kế hoạch tốt hơn so với lý thuyết, dù vẫn giữ tính cứng nhắc của Waterfall.

Tiêu chí

Lý thuyết (Agile)

Thực tế tại Ekotek (Agile)

Khác biệt

Tần suất giao tiếp

Liên tục, hàng ngày (Daily Scrum), hàng tuần (Sprint Planning, Review, Retrospective).

Hàng ngày (Daily Scrum), hàng tuần (Sprint Planning, Review), họp weekly nội bộ nếu cần.

Tương đồng: Ekotek áp dụng đúng tần suất giao tiếp liên tục của Agile, với Daily Scrum và các cuộc họp định kỳ theo chu kỳ Sprint.

Hình thức giao tiếp

Không trang trọng, ưu tiên giao tiếp trực tiếp (mặt đối mặt, video call) hơn văn bản.

Không trang trọng, ưu tiên họp trực tiếp/online và chat nhanh qua Slack/Discord/Google Chat.

Tương đồng: Ekotek áp dụng tốt giao tiếp không trang trọng, sử dụng các kênh chat nhanh và họp trực tiếp/online, đúng với tinh thần Agile.

Luồng thông tin

Đa chiều, cộng tác, minh bạch, thông tin được chia sẻ tự do giữa các thành viên.

Đa chiều, văn hóa giao tiếp mở, Dev có thể làm việc trực tiếp với QA/BA khi cần.

Tương đồng: Ekotek khuyến khích giao tiếp chéo vai trò và văn hóa mở, đúng với nguyên tắc cộng tác đa chiều của Agile.

Vòng lặp phản hồi

Rất nhanh, cuối mỗi Sprint (1-4 tuần), với phản hồi từ khách hàng trong Sprint Review.

Rất nhanh, phản hồi từ khách hàng trong Sprint Review, issue được giải quyết tức thời qua chat.

Thực tế cải tiến: Ekotek bổ sung kênh chat nhanh (Slack/Discord) để xử lý issue ngay lập tức, tăng tốc độ phản hồi so với lý thuyết.

Sự tham gia của khách hàng

Tham gia liên tục, đặc biệt trong Sprint Review để điều chỉnh yêu cầu.

Tham gia trong Sprint Review, nhận báo cáo tiến độ hàng tuần, làm việc trực tiếp khi có issue nghiêm trọng.

Thực tế tăng cường giao tiếp với khách hàng: Ngoài Sprint Review, Ekotek gửi báo cáo tiến độ định kỳ và liên hệ trực tiếp khi có vấn đề, giúp khách hàng tham gia sâu hơn.

Công cụ giao tiếp

Jira, Trello, Confluence, Slack, bảng trắng.

Jira, ClickUp, Slack, Discord, Google Chat, Notion, Google Docs.

Thực tế đa dạng hơn: Ekotek sử dụng thêm ClickUp, Discord, Google Chat và Notion, mở rộng bộ công cụ so với lý thuyết, phù hợp với môi trường làm việc hiện đại.

Quản lý thay đổi

Thay đổi được chào đón, dễ dàng tích hợp vào Product Backlog.

Thay đổi được tích hợp qua Sprint Planning, phản hồi từ khách hàng được cập nhật vào task mới.

Tương đồng: Ekotek áp dụng đúng tinh thần linh hoạt của Agile, tích hợp thay đổi nhanh chóng dựa trên phản hồi từ Sprint Review.

Trọng tâm

Thích ứng với thay đổi, cung cấp giá trị liên tục.

Thích ứng với thay đổi, tập trung vào mục tiêu Sprint và phản hồi khách hàng.

Tương đồng: Ekotek đặt trọng tâm vào việc cung cấp giá trị và thích ứng, đúng với nguyên tắc Agile.

Vai trò

Lý thuyết

Thực tế tại Ekotek

Khác biệt

Project Manager (PM)

Cầu nối giữa các bên, báo cáo lên lãnh đạo, truyền đạt xuống đội, điều phối với khách hàng, tổ chức họp, giải quyết xung đột.

PM kiêm Product Owner trong Agile, chủ trì Sprint Planning, gửi báo cáo định kỳ, liên hệ trực tiếp với khách hàng khi có issue. Trong Waterfall, PM là đầu mối xử lý mọi vấn đề.

Thực tế tích hợp vai trò: PM tại Ekotek thường kiêm luôn vai trò Product Owner trong Agile, tăng trách nhiệm trong việc quản lý backlog và làm rõ yêu cầu. Trong Waterfall, vai trò của PM cũng được nhấn mạnh hơn khi xử lý mọi vấn đề.

Tech Lead

Dịch yêu cầu nghiệp vụ thành kỹ thuật, giải thích quyết định kỹ thuật, hướng dẫn Dev, báo cáo rủi ro kỹ thuật.

Không được đề cập rõ trong tài liệu thực tế, nhưng có nhắc đến Dev làm việc trực tiếp với BA/QA, ngụ ý Tech Lead có thể tham gia khi cần làm rõ vấn đề kỹ thuật.

Thiếu thông tin cụ thể: Tài liệu thực tế không mô tả rõ vai trò giao tiếp của Tech Lead, có thể do vai trò này được tích hợp vào PM hoặc Dev trong một số trường hợp.

BA/Comtor

Lắng nghe, khơi gợi yêu cầu, tài liệu hóa, làm rõ yêu cầu, chuyển ngữ (nếu có yếu tố văn hóa).

BA làm việc trực tiếp với Dev khi yêu cầu chưa rõ, tài liệu hóa qua Google Docs/Notion. Comtor không được đề cập cụ thể.

Thực tế đơn giản hóa: Vai trò BA được áp dụng đúng lý thuyết, nhưng không có thông tin về Comtor, có thể do dự án không liên quan đến yếu tố đa ngôn ngữ/văn hóa.

Tester/QA

Báo cáo lỗi rõ ràng, thông báo rủi ro chất lượng, phối hợp với Dev, trình bày Test Plan.

Dev chủ động hỏi QA khi test gặp lỗi, QA bình luận trực tiếp trên Jira/ClickUp.

Thực tế nhấn mạnh giao tiếp chéo: Ekotek khuyến khích QA và Dev giao tiếp trực tiếp để xử lý lỗi nhanh chóng, đúng với tinh thần hợp tác của Agile.

Developer (Dev)

Báo cáo tiến độ, đặt câu hỏi làm rõ, giao tiếp qua code và Pull Request.

Báo cáo tiến độ trong Daily Scrum, hỏi trực tiếp BA/QA khi cần, bình luận trên Jira/ClickUp.

Tương đồng: Vai trò giao tiếp của Dev tại Ekotek rất sát với lý thuyết, đặc biệt trong việc chủ động làm rõ yêu cầu và báo cáo trở ngại sớm.

Khía cạnh

Lý thuyết

Thực tế tại Ekotek

Khác biệt

Tính cởi mở và hai chiều

Lý thuyết nhấn mạnh giao tiếp hai chiều và cởi mở, đặc biệt trong Agile, nơi mọi thành viên được khuyến khích đặt câu hỏi, phản hồi, và đóng góp ý kiến (nguyên tắc "Tính Hai chiều và Cởi mở" trong PMBOK® Guide). Trong Waterfall, giao tiếp có xu hướng một chiều, từ trên xuống.

Ekotek khuyến khích văn hóa giao tiếp mở trong Agile, với giao tiếp chéo vai trò (Dev-QA, Dev-BA) và sử dụng kênh chat nhanh (Slack, Discord). Trong Waterfall, PM là đầu mối chính, hạn chế giao tiếp trực tiếp giữa Dev và khách hàng, giữ tính một chiều.

Tương đồng trong Agile, khác biệt trong Waterfall: Ekotek áp dụng tốt văn hóa cởi mở trong Agile, nhưng trong Waterfall, giao tiếp vẫn mang tính một chiều hơn lý thuyết, do PM đóng vai trò trung gian tuyệt đối, có thể hạn chế sự tham gia trực tiếp của các thành viên khác.

Tôn trọng và xây dựng

Lý thuyết yêu cầu giao tiếp mang tính xây dựng, tránh chỉ trích, đặc biệt khi Tester báo cáo lỗi hoặc Dev đặt câu hỏi làm rõ.

Tester tại Ekotek báo cáo lỗi qua Jira/ClickUp với bình luận chi tiết, Dev chủ động hỏi BA/QA khi cần làm rõ, thể hiện văn hóa hợp tác. PM cũng giao tiếp với khách hàng một cách tôn trọng, đưa ra hướng giải quyết cụ thể.

Tương đồng: Ekotek duy trì văn hóa giao tiếp tôn trọng và xây dựng, đặc biệt trong việc xử lý lỗi và làm rõ yêu cầu, đúng với lý thuyết.

Sự gắn kết đội nhóm

Lý thuyết nhấn mạnh giao tiếp thường xuyên và minh bạch để thúc đẩy tinh thần đội nhóm và sự tin tưởng lẫn nhau. Agile khuyến khích "osmotic communication" (Cockburn, 2004), nơi thông tin chảy tự nhiên trong nhóm.

Daily Scrum và họp weekly tại Ekotek giúp cả nhóm cập nhật tiến độ, phát hiện vấn đề sớm, và duy trì sự gắn kết. Văn hóa giao tiếp mở (Dev chủ động hỏi QA/BA) cũng tăng cường sự tin tưởng.

Tương đồng mạnh: Ekotek áp dụng tốt nguyên tắc giao tiếp để gắn kết đội nhóm, đặc biệt trong Agile. Việc sử dụng các công cụ như Slack hỗ trợ giao tiếp thẩm thấu, gần giống với lý thuyết.

Khía cạnh

Lý thuyết

Thực tế tại Ekotek

Khác biệt

Phát hiện rủi ro sớm

Lý thuyết nhấn mạnh giao tiếp cởi mở để phát hiện rủi ro sớm (nguyên tắc "Nhận diện và Giảm thiểu Rủi ro"). Trong Agile, Daily Scrum và Sprint Review giúp phát hiện vấn đề nhanh chóng. Trong Waterfall, rủi ro thường được phát hiện muộn hơn do giao tiếp không thường xuyên.

Ekotek sử dụng Daily Scrum để phát hiện rủi ro sớm trong Agile (Dev báo cáo blockers). Trong Waterfall, PM tổng hợp vấn đề từ đội và báo cáo qua họp milestone hoặc email, nhưng vẫn chậm hơn Agile.

Thực tế cải tiến trong Agile: Ekotek tận dụng tốt Daily Scrum để phát hiện rủi ro sớm, đúng với lý thuyết. Trong Waterfall, báo cáo định kỳ hàng tuần giúp cải thiện việc phát hiện rủi ro so với lý thuyết, nhưng vẫn chậm hơn Agile.

Xử lý rủi ro

Lý thuyết yêu cầu giao tiếp kịp thời để xử lý rủi ro (nguyên tắc "Tính Kịp thời"). Agile khuyến khích giải quyết ngay lập tức qua giao tiếp trực tiếp. Waterfall yêu cầu quy trình chính thức (Change Request).

Trong Agile, Ekotek xử lý rủi ro qua kênh chat nhanh (Slack) hoặc sau Daily Scrum. Trong Waterfall, PM là đầu mối xử lý, yêu cầu ghi lại vấn đề qua Change Request hoặc Jira.

Thực tế hiệu quả hơn trong Agile: Ekotek xử lý rủi ro nhanh chóng trong Agile nhờ kênh chat và văn hóa giao tiếp mở. Trong Waterfall, quy trình xử lý rủi ro vẫn mang tính chính thức, đúng với lý thuyết, nhưng có thể chậm hơn do phải qua PM.

Báo cáo rủi ro cho khách hàng

Lý thuyết khuyến nghị thông báo rủi ro cho khách hàng một cách minh bạch và kịp thời, đặc biệt trong Agile qua Sprint Review. Trong Waterfall, rủi ro thường được báo cáo ở các mốc nghiệm thu.

Ekotek báo cáo rủi ro cho khách hàng qua email/call khi có vấn đề nghiêm trọng (Agile) hoặc trong báo cáo tiến độ định kỳ (Waterfall). PM chủ động liên hệ khách hàng để đưa ra hướng giải quyết.

Thực tế chủ động hơn: Ekotek cải thiện việc báo cáo rủi ro bằng cách liên hệ trực tiếp với khách hàng trong cả hai mô hình, thay vì chỉ chờ đến các mốc chính thức như lý thuyết.

Khía cạnh

Lý thuyết

Thực tế tại Ekotek

Khác biệt

Công cụ giao tiếp

Lý thuyết đề xuất các công cụ như Jira, Trello, Confluence, Slack (Agile) hoặc email, MS Project, Word/PDF (Waterfall) để quản lý thông tin và đảm bảo tính nhất quán (nguyên tắc "Tính Nhất quán").

Ekotek sử dụng Jira, ClickUp, Slack, Discord, Google Chat, Notion, Google Docs (Agile) và email, Google Sheet, Jira (Waterfall).

Thực tế đa dạng và hiện đại hơn: Ekotek mở rộng bộ công cụ so với lý thuyết, đặc biệt trong Agile, với các công cụ như ClickUp, Discord, Notion, giúp tăng tính linh hoạt và khả năng cộng tác.

Tích hợp công cụ

Lý thuyết không đi sâu vào việc tích hợp công cụ, nhưng nhấn mạnh rằng công cụ phải hỗ trợ minh bạch và dễ truy cập.

Ekotek tích hợp Jira/ClickUp để quản lý task, Slack/Discord để chat nhanh, và Notion/Google Docs để tài liệu hóa, tạo hệ thống giao tiếp tập trung.

Thực tế vượt trội: Ekotek xây dựng một hệ sinh thái công cụ tích hợp, giúp thông tin được lưu trữ và truy cập dễ dàng, cải thiện tính minh bạch và nhất quán so với lý thuyết.

Ứng dụng công nghệ trong họp

Lý thuyết đề cao giao tiếp mặt đối mặt (Agile) hoặc họp chính thức (Waterfall), nhưng không đề cập nhiều đến công nghệ họp online.

Ekotek sử dụng Google Meet/Slack Huddle cho họp online trong cả Agile và Waterfall, hỗ trợ làm việc từ xa.

Thực tế phù hợp với xu hướng hiện đại: Ekotek áp dụng công nghệ họp online, đáp ứng nhu cầu làm việc từ xa, điều mà lý thuyết chưa đề cập rõ ràng.