Điều tuyệt vời của việc già… hơn, uhm ý tôi là, có nhiều kinh nghiệm hơn… chính là bạn có thể nhớ được các cách quản lý dự án khác nhau trong những thời điểm khác nhau. Trong bài viết này, tôi sẽ hướng dẫn bạn một số phương pháp quản lý dự án chính được sử dụng cho các dự án công nghệ thông tin (CNTT – IT) ngày nay và cung cấp thêm một chút thông tin lịch sử của từng phương pháp. Tôi cũng sẽ đưa ra các đề xuất về thời điểm phù hợp nhất để áp dụng từng phương pháp.
Prototyping
Đây không hoàn toàn là một phương pháp quản lý dự án, prototyping được vay mượn từ lĩnh vực kỹ thuật và kiến trúc. Giống như hầu hết các bản kế hoạch, các bản thiết kế được tạo ra – và tại một thời điểm nhất định, các kỹ sư hoặc kiến trúc sư sẵn sàng biến kế hoạch của mình thành sản phẩm bằng cách xây dựng một mô hình mẫu và thử nghiệm nó. Dự án càng phức tạp thì càng cần nhiều mô hình mẫu và thử nghiệm liên tục.
Đôi khi phương pháp này được gọi là “bằng chứng về khái niệm (proof-of-concept)”, có thể thực hiện một số chu kỳ của mô hình/công trình (với các mô hình lớn hơn và tốt hơn chẳng hạn, kiểm tra dần dần trong thời gian lâu hơn, nghiêm ngặt hơn). Tất nhiên, prototyping sẽ dẫn đến các chi phí liên quan; một số hoặc tất cả sản phẩm mẫu không thể sử dụng và bị loại bỏ; quá nhiều cái tốt có thể giết chết một sản phẩm mới, đặc biệt nếu ngân sách bị hạn chế.
Nhưng trong thế giới công nghệ thông tin (CNTT) – cho dù là xử lý phần mềm, phần cứng hay thứ gì đó mang tính khái niệm như đám mây (cloud) – thì prototyping vẫn là một phương pháp phù hợp và cần được cân nhắc nếu các điều kiện thích hợp.
Prototyping được khuyến nghị sử dụng cho:
- Các dự án còn nhiều điều chưa chắc chắn, hoặc nhóm không hoàn toàn biết họ đang xây dựng cái gì
- Các tình huống xây dựng hoặc bắt đầu hoạt động lần đầu (khi có rất nhiều điều chưa biết trong dự án)
- Khi chất lượng hoặc độ chính xác là mối quan tâm chính (ví dụ: hiểu đúng ý tưởng, không bị ảnh hưởng thời gian hoặc chi phí)
Prototyping KHÔNG được khuyến khích cho:
- Các cải tiến nhỏ cho các sản phẩm hoặc hệ thống hiện có
- Các dự án nhỏ với kết quả có thể dự đoán được
- Các dự án khẩn cấp với thời hạn chặt chẽ
Waterfall
Có lẽ đây là phương pháp lâu đời nhất trong số các phương pháp mà tôi sẽ đề cập, phương pháp thác nước (waterfall) đã được sử dụng từ 70 năm trước hoặc lâu hơn thế, kể từ khi các máy tính lớn của IBM sử dụng thẻ đục lỗ vào những năm 1950 cho đến ngày nay. Mặc dù ngày nay, phương pháp waterfall đôi khi bị miệt thị do các phương pháp hiện đại hơn được ủng hộ, nhưng tôi khẳng định, waterfall vẫn có một vị trí quan trọng trong lĩnh vực công nghệ thông tin của những năm .
Dựa trên một loạt các giai đoạn (khám phá> yêu cầu> thiết kế> xây dựng> thử nghiệm> triển khai), waterfall được đặt tên như vậy vì mỗi giai đoạn dẫn đến giai đoạn tiếp theo. Waterfall có thể là cấu trúc phân tầng và được thiết lập với các cổng giai đoạn cùng tiêu chí chấp nhận nghiêm ngặt, hoặc nó có thể là một khuôn khổ lỏng lẻo mà các nhóm sử dụng để thực hiện công việc của họ.
Dù bằng cách nào, waterfall vẫn là một phương pháp hoàn toàn hợp lý cho các dự án CNTT, đặc biệt là khi có khách hàng nội bộ hoặc bên ngoài – khả năng cao là họ không có chuyên môn kỹ thuật – cần dịch vụ CNTT nhưng không biết rõ mình muốn gì. Mặc dù sẽ có một số rủi ro cố hữu khi thực hiện “một vụ nổ lớn” trong lần triển khai đầu tiên, nhưng thực sự waterfall có thể tiết kiệm chi phí về lâu dài bằng cách giúp xác định rõ ràng những gì khách hàng cần hoặc muốn, và tất nhiên là sửa chữa trước khi xây dựng hoặc cài đặt bất kỳ thứ gì.
Cơ hội thành công của bạn với waterfall cũng được cải thiện nếu bạn kết hợp nó với một số hình thức protoyping trong quá trình thực hiện. Ví dụ: hiển thị mô hình màn hình thô cho khách hàng của bạn trong giai đoạn thiết kế và sau đó thu thập phản hồi có thể đảm bảo rằng mọi người liên quan đều hiểu cùng một vấn đề.
Waterfall được đề xuất cho:
- Các tổ chức làm việc với khách hàng, đặc biệt khi thông tin của khách hàng về yêu cầu của họ còn thô sơ, mơ hồ hoặc không được tất cả các bên đồng ý (ví dụ: khi bộ phận tiếp thị muốn một thứ và bộ phận vận hành muốn một thứ khác)
- Nhóm đang gặp phải một lĩnh vực kiến thức mới, có thể thông qua một khách hàng mới
- Các dự án quy mô vừa với mức độ rủi ro có thể chấp nhận được
Waterfall KHÔNG được khuyến nghị cho:
- Các dự án rất lớn có thể mang lại lợi ích khi chia thành hai hoặc nhiều dự án
- Nâng cao các sản phẩm hoặc hệ thống hiện có trừ khi đó là một sự thay đổi lớn
- Các dự án mà chi phí là ràng buộc chính yếu
Một số phương pháp tiếp theo mà tôi sẽ thảo luận hôm nay được coi là các phương pháp luận “Agile”. Nhưng không phải lúc nào cũng vậy. Trên thực tế, hai trong số các phương pháp quan trọng nhất hiện nay được coi là không thể thiếu đối với agile thực sự còn xuất hiện trước Tuyên ngôn Agile. Nhưng trước khi chúng ta tìm hiểu sâu hơn về các phương pháp này, hãy tìm hiểu một chút về lịch sử của nó.
Quay trở lại những năm 1940 ở Nhật Bản, Toyota bắt đầu một chương trình được gọi là sản xuất đúng lúc. “Phương thức Toyota” đã lan truyền đến Hoa Kỳ, nơi nó được gọi là sản xuất tinh gọn (lean) vào những năm 1980. Lean cuối cùng đã trở thành một hệ thống cải tiến quy trình chung, lan rộng sang các ngành công nghiệp khác khi các tập đoàn áp dụng và điều chỉnh các nguyên tắc và phương thức thực hành mà Toyota đã khởi nguồn.
Lĩnh vực chăm sóc sức khỏe, ngân hàng, xây dựng và các lĩnh vực phi sản xuất khác đã sử dụng một số hoặc tất cả các kỹ thuật tinh gọn – một số thành công, một số ít hơn – để “chuyển đổi” thành các doanh nghiệp tinh gọn. Lĩnh vực công nghệ thông tin cũng vay mượn phương pháp Lean nhằm cố gắng trở nên hiệu quả hơn và ít mắc lỗi hơn.
Ảnh hưởng lịch sử lớn thứ hai đối với các phương pháp quản lý dự án CNTT đến vào khoảng năm 1995 với sự ra đời của Internet và sự bùng nổ trong công nghệ web ngay sau đó. Nếu bạn đã từng tham gia vào việc cập nhật nội dung trên một trang web, bạn có thể hình dung nhu cầu thay đổi code nhanh chóng và thường xuyên đã tăng lên như thế nào trong những năm đầu của Internet – và nhu cầu này có thể và đã xung đột với các phương pháp nặng về tài liệu giống như waterfall như thế nào.
Chu kỳ code – thử nghiệm – triển khai được rút ngắn trong cuối những năm 1990 và đầu những năm 2000, toàn bộ nhóm phát triển và nhân viên kinh doanh đều đang kêu gọi tìm kiếm những cách tốt hơn để cập nhật phần mềm và các sản phẩm kỹ thuật số khác.
Kanban
Công cụ quan trọng nhất được sử dụng trong kanban là bảng kanban, hỗ trợ nhóm hình dung công việc và sắp xếp các nhiệm vụ. Bảng Kanban rất phù hợp và lý tưởng khi sử dụng cho các nhóm nhỏ, các thành viên cùng làm việc một chỗ (thay vì làm việc từ xa) và cho phép mọi thành viên trong nhóm biết trạng thái của nhiệm vụ cũng như những điều sắp xảy ra tiếp theo. Bạn có thể dễ dàng nhận thấy đây sẽ là lợi thế lớn trong kỹ thuật ô tô. Và đúng thế, kanban có nguồn gốc từ Nhật Bản như một phần của “Phương thức Toyota”. Tuy nhiên, nó vẫn chưa được áp dụng để phát triển phần mềm cho đến giữa những năm 2000 khi nó bắt đầu được sử dụng tại Microsoft.
Hình 1: Kanban Board. Của Andy Carmichael – Own work, CC BY-SA 4.0
Giống như các phương pháp agile khác, một lợi thế chính của kanban là công việc được đưa vào hoạt động khi khả năng cho phép, và không nhất thiết phải theo yêu cầu của các đối tác kinh doanh. Với các công cụ hiện đại mô phỏng một bảng kanban trực tuyến, việc nhóm cùng làm việc một chỗ đồng thời cũng không còn là một yêu cầu bắt buộc.
Kanban được khuyến nghị cho:
- Các nhóm nhỏ tập trung vào một nỗ lực duy nhất
- Các dự án mà mục tiêu là cải tiến liên tục sản phẩm
- Các dự án với các đối tác kinh doanh hợp tác, những người hiểu giá trị của các bản phát hành với giá trị gia tăng
Kanban KHÔNG được khuyến khích cho:
- Các dự án lớn yêu cầu nhiều nhóm với nhiều sự phụ thuộc lẫn nhau
- Các dự án không có tầm nhìn hoặc lộ trình rõ ràng
- Các tình huống mà tài liệu có thể là chìa khóa thành công lâu dài
Scrum
Scrum có lẽ là phương pháp quản lý dự án phổ biến nhất đang được sử dụng hiện nay. Thuật ngữ “scrum” được mượn từ trò chơi bóng bầu dục và lần đầu tiên được sử dụng trong bài báo Harvard Business Review năm 1986 của Hirotaka Takeuchi và Ikujiro Nonaka. Các tác giả gọi là một nhóm đa chức năng “làm việc cùng nhau như một đơn vị để mang quả bóng xuống sân”, cụ thể là trong việc phát triển sản phẩm. Sau đó, Ken Schwaber và Jeff Sutherland áp dụng Scrum vào phát triển phần mềm và cuối cùng thành lập Scrum Alliance vào năm 2002.
Điểm mạnh chính yếu của scrum bao gồm cách tiếp cận lặp đi lặp lại để gia tăng giá trị cho sản phẩm, tập trung vào tính minh bạch và cải tiến liên tục cũng như khả năng thích ứng khi đối mặt với các yêu cầu thay đổi. Scrum cũng cải thiện hiệu quả của các nhóm làm việc bằng cách phân chia công việc theo thời gian thành các đơn vị có thể quản lý được – thường là khoảng thời gian hai tuần – và chuyển công việc loại bỏ các trở ngại cho Scrum Master và tránh xa các thành viên trong nhóm. Mặt khác, scrum không chỉ cách xác định và giải quyết các mối quan hệ phụ thuộc giữa các nhóm, cũng như không hỗ trợ việc lập kế hoạch dài hạn.
Scrum được khuyến nghị cho:
- Các nhóm cho tối đa 10 người – với Scrum Master là người thứ 11
- Các dự án vừa và nhỏ với ít sự phụ thuộc vào các nhóm bên ngoài
- Các tổ chức quan tâm đến việc cải tiến liên tục về hiệu suất của nhóm và cả sản phẩm
Scrum KHÔNG được khuyến nghị cho:
- Các dự án rất lớn với nhiều nhóm và sự phụ thuộc lẫn nhau
- Các dự án không có quyền liên hệ liên tục với người dùng cuối hoặc một chuyên gia am hiểu về chủ đề
- Các nhóm có hơn 10 thành viên
SAFe
Scaled Agile Framework, hay SAFe, ra đời khi các tổ chức nhận ra sự cần thiết phải mở rộng các hoạt động thực hành agile trên nhiều nhóm. Ra mắt vào năm 2011, SAFe cố gắng kết hợp các tính năng tốt nhất của tư duy agile, tinh gọn và suy nghĩ hệ thống, điều này là đầy tham vọng nếu không muốn nói là khó hiểu.
Tuy nhiên, những ý tưởng tốt nhất được đưa vào SAFe – việc sử dụng các cuộc họp lập kế hoạch chung, xác định sự phụ thuộc giữa các nhóm và điều phối các bản phát hành – là những phương pháp hợp lý và giải quyết một số thách thức nảy sinh khi nhiều nhóm đang thực hiện Scrum dạng silo.
Hình 2: SAFe 5 cho những doanh nghiệp tinh gọn
SAFe cũng yêu cầu sự tham gia của các nhà quản lý và điều hành doanh nghiệp trong việc thiết lập các mục tiêu và ưu tiên, cấp vốn cho danh mục đầu tư và nắm quyền làm chủ các vấn đề của tổ chức. Mặc dù việc thực thi SAFe thành công trong thực tế thường phụ thuộc vào kỹ năng của các nhà lãnh đạo hơn là các nhóm, nhưng SAFe chắc chắn là con đường rộng mở cho những nỗ lực kỹ thuật số lớn và phức tạp.
SAFe được khuyến nghị cho:
- Các doanh nghiệp đang phấn đấu trở nên tinh gọn, hoặc những doanh nghiệp đang tăng trưởng rất nhanh và cần phương thức thực hành cho tổ chức
- Các dự án rất lớn, phức tạp với nhiều nhóm và sự phụ thuộc lẫn nhau
- Các tổ chức có ban quản lý tích cực hỗ trợ và hiểu cách SAFe có thể đóng góp vào dòng giá trị của sản phẩm/tổ chức
SAFe KHÔNG được khuyến nghị cho:
- Các công ty nhỏ đã thực sự nhanh nhẹn
- Công việc mang tính thử nghiệm hoặc đột phá mà một nhóm đang làm lần đầu tiên
- Các dự án rủi ro cao đối với khách hàng bên ngoài
Cuối cùng, với tư cách là giám đốc danh mục, giám đốc dự án và Scrum Master, tất cả chúng ta đều phải đối mặt với các quyết định về cách điều hành một dự án và khi nào là phù hợp để áp dụng một kỹ thuật nào đó. Bạn hoàn toàn có thể lựa chọn các ý tưởng và kết hợp các phương pháp khi nó phù hợp với dự án mình. Bạn có thể chạy nước rút qua các giai đoạn của waterfall hoặc scrum-ban thông qua các sự phát triển (increments) của SAFe.
Hãy suy nghĩ cẩn thận về các đặc điểm dự án của bạn, phản ánh một chút về lịch sử của các phương pháp và chọn những gì phù hợp nhất để dự án tiếp theo của bạn thành công.
Nguồn: https://www.projectmanagement.com
Viện Quản lý dự án Masterskills
Quản lý dự án theo mô hình linh hoạt Agile Scrum
Ưu điểm của mô hình Waterfall
12 nguyên tắc của Agile
