APMP.VN

Để phục vụ cho bài viết, tôi đã xem qua những đặc điểm của phương pháp quản lý dự án truyền thống (TPM) trong cuốn Hướng dẫn về những kiến thức cốt lõi trong Quản lý dự án (PMBOK) do Viện Quản lý Dự án (PMI) công bố. Trong khi PMI không đưa ra một tên gọi cụ thể nào cho phương pháp quản lý dự án truyền thống, thì hầu hết các công ty vẫn thường gọi đó là waterfall (thác nước) – mỗi giai đoạn của dự án sẽ được chuyển đến giai đoạn tiếp theo (sau khi đã kết thúc hoàn toàn thành công công việc) giống như dòng chảy của thác nước và chỉ chảy theo một hướng, không thể quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước không thể chảy ngược). Đó là một trong nhiều lý do khiến nhiều công ty ào ạt  chuyển sang áp dụng phương pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc nhanh hơn, chi phí thấp hơn, và sẽ không có biểu đồ Gantt nữa!

Nhiều người tỏ ra rất nhiệt tình ủng hộ việc áp dụng những phương pháp thay thế, họ luôn luôn biết cách thuyết phục các nhà quản lý, nhà tài trợ cấp cao bằng những lời hứa lớn lao, những trích dẫn ví dụ về nhiều dự án thất bại và không đem lại kết quả. Nhưng thật không may, hiện tại nhiều công ty đang phải vật lộn với Agile hoặc thất bại hoàn toàn chỉ vì một lý do đơn giản: họ không nắm được những đặc điểm của TPM đã được quy định trong PMBOK, không hiểu được tại sao những gì họ thực hiện trong thực tế lại là nguyên nhân gây ra sự không hiệu quả và Agile/Scrum đem lại sự mới mẻ như thế nào. Do đó, họ cố gắng thực hiện một số một số dự án theo kiểu “agile” mà không hề giải quyết những vấn đề đã nảy sinh mầm mống ngay từ giai đoạn đầu của dự án. Những cuộc họp linh động hàng ngày và một kế hoạch không cầu kỳ hóa không đảm bảo cho việc dự án sẽ được thực hiện nhanh hơn.Bài viết này sẽ giới thiệu đến độc giả ba bài học thiết yếu để giúp các nhà quản lý dự án hiểu được khi nào là lúc thích hợp để áp dụng phương pháp Agile / Scrum và những nguyên tắc cơ bản cần phải nắm vững để thành công với phương pháp này .

Bài học số 1: Agile/Scrum khác một dự án không có kế hoạch

Để hiểu tại sao nhiều công ty phải vật lộn để chuyển đổi bằng được cách thức quản lý dự án, trước hết chúng ta cần phải hiểu được một vài điểm khác biệt cơ bản giữa TPM (Phương pháp quản lý dự án truyền thống) và Agile/Scrum cũng như những thách thức mà người quản lý phải đổi mặt. Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án. So sánh với quá trình phát triển Agile, thì trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có nghĩa là vai trò của một người quản lý dự án Agile hoàn toàn không giống với một người quản lý dự án TPM. Tuyên ngôn của Agile (The Agile Manifesto) thừa nhận sự cần thiết của việc chuyển giao kết quả trung gian, nhưng không nhấn mạnh vai trò của người quản lý trong việc tạo ra hoặc kiểm soát chúng.

Quá trình chuyển đổi từ TPM sang Agile quả thực là một quá trình khó khăn đối với nhiều nhà quản lý dự án. Sự chuyển đổi này thường thì không thay đổi được bản chất (áp dụng phương pháp kế hoạch theo định hướng nhưng lại gọi nó là Scrum bởi các cuộc họp nhóm diễn ra hằng ngày thay vì một cuộc họp báo cáo tình hình dự án theo giai đoạn), hoặc họ mặc định Agile/Scrum nghĩa là không có kế hoạch. Có một sự khác biệt lớn giữa việc không có kế hoạch và lên kế hoạch cho những gì bạn biết và có thể thực hiện trong một thời gian nhất định.

Bài học số 2: Biết được sự khác biệt

Nhiều doanh nghiệp và nhà quản lý thất bại trong việc thực hiện quá trình chuyển đổi phương pháp quản lý dự án vì họ không đánh giá cao sự khác nhau giữa TPM và Agile/Scrum. Có kiến thức và hiểu biết trong trường hợp này là các công ty đã nắm được một nửa phần thắng trong việc đi lên Aglie/Scrum. Dưới đây là một số sự khác biệt quan trọng mà bạn bắt buộc phải biết và nắm rõ:

1. Kế hoạch hóa so với tập trung vào giá trị

Agile/Scrum đưa ra cách tiếp cận hướng tới giá trị trong khi TPM lại hướng tới mục tiêu để lên kế hoạch cho toàn bộ dự án. Điều này không có nghĩa là một dự án Agile/Scrum thì không có kế hoạch. Với Scrum, mỗi phân đoạn đều có một kế hoạch, nhưng các kế hoạch tập trung vào việc ưu tiên các tính năng mang lại giá trị nhất. Điều này hoàn toàn khác với TPM, nơi một kế hoạch hoàn chỉnh được tạo ra trước khi đi vào chi tiết hoạt động và nhiệm vụ cần thiết cho dự án.

2. Tiên đoán so với Thực nghiệm

Quản lý dự án truyền thống sử dụng phương pháp tiên đoán, có nghĩa là ban giám đốc sẽ dự đoán kết quả có thể đạt được dựa trên các giả định, để từ đó xây dựng một kế hoạch “trả trước” và một khi kế hoạch này được thiết lập, yêu cầu thay đổi phải được đánh giá theo từng trường hợp. Việc thiết kế được khuyến cáo là không nên thay đổi sau khi kế hoạch đã được chấp thuận, và việc sản xuất, phát triển không nên bắt đầu cho đến khi thiết kế hoàn tất. Điều này hoàn toàn khác biệt so với Scrum, theo Jeff Sutherland, đồng sáng tạo ra Scrum, ” Thực hiện một phương pháp thực nghiệm dựa trên lý thuyết kiểm soát quá trình”. Đó là cách mọi người ưa thích khi nói về việc các Scrum Master và nhóm nghiên cứu cần thích ứng với kết quả hiện tại và của các sprints trước đó để điều chỉnh các mục tiêu về năng suất và thực hiện thay đổi để tăng tốc độ dự án. Mỗi iteration (phân đoạn lặp) được điều chỉnh dựa trên dữ liệu từ sprint trước đó và phải tập trung làm thế nào để mang lại nhiều giá trị hơn trong sprint tiếp theo.

3. Cấp trên quản lý so với nhóm tự quản

Một trong những vai trò căn bản của một người quản lý dự án truyền thống là phải tích cực tổ chức và sắp xếp sao cho hợp lý đội ngũ của mình, phân công các vai trò và trách nhiệm cho mỗi thành viên trong dự án. Còn một Scrum Master sẽ lùi lại và cho phép nhóm tự tổ chức. Người quản lý dự án phải tạo điều kiện, cung cấp môi trường để nhóm tự giao tiếp và thực hiện công việc.

4. Quản lý các bên liên quan so với sự gắn bó

Trong TPM, việc quản lý các bên liên quan là một phần quan trọng trong công việc của người quản lý. Thông thường, điều này được thực hiện thông qua các báo cáo tình hình công viêc, biểu đồ tiến độ, và  báo cáo của người quản lý ở những cuộc họp cập nhật tình hình dự án.Với Scrum thì khách hàng- những chủ sản phẩm được coi là một phần của đội ngũ dự án. Bởi vì các bên liên quan là một phần của nhóm phát triển và là một bên đưa ra tất cả quyết định về việc sử dụng điều kiện phức tạp và báo cáo tiến độ là không cần thiết.

5. Lập kế hoạch từ dưới lên so với trên xuống

Quản lý dự án truyền thống theo hướng lập kế hoạch từ dưới lên, có nghĩa là một dự án được lên kế hoạch ngay từ đầu bằng cách lên chi tiết các công việc của mỗi cá nhân trong Cơ cấu phân chia công việc (Work Breakdown Structure – WBS), từ đó dẫn đến một kế hoạch dự án hoàn chỉnh trước khi bắt đầu dự án. Scrum thì ngược lại, nó theo hướng lập kế hoạch từ trên xuống, nghĩa là một lộ trình được phát triển trong giai đoạn đầu của dự án được xây dựng dần dần thành các phân đoạn release (bản phát hành) và sprint (phân đoạn).

Bài học 3: Học cách để triển khai

Có một vài thói quen và thủ tục của TPM dường như không thể phá vỡ được. Một người quản lý dự án sẽ cần phải loại bỏ những thói quen này nếu họ muốn đi tới thành công của quá trình chuyển đổi. Mặc dù việc này thì khá đơn giản, nhưng hầu hết các công ty lại không muốn từ bỏ thói quen này vì sợ hãi. Mặc dù đây là nguyên nhân khiến cho một dự án TPM không đem lại được hiệu quả, nhưng những thói quen này dường như rất dễ nhận thấy trong các giải pháp Agile mà nhiều công ty thực hiện. Việc loại bỏ những thói quen của cách quản lý truyền thống là điều cực kỳ quan trọng để các nhà quản lý dự án có thể xây dựng được lòng tin nơi tổ chức của mình. Giả pháp là nên thí điểm Agile ở một dự án nhỏ hoặc sử dụng một phương pháp tạm thời đã được cân nhắc kỹ lưỡng. Thông thường, ta không thể thoát khỏi những thói quen cũ cho đến khi toàn bộ đội ngũ đã hiểu các triết lý Agile và sẵn sàng đón nhận chúng.

Thói quen #1 – Lập kế hoạch trước mọi thứ

Trong một dự án Agile/Scrum, bạn sẽ không biết tất cả các yêu cầu trước khi bắt đầu dự án và chúng sẽ luôn luôn có xu hướng thay đổi theo tiến bộ của dự án. Một bản kế hoạch đầy đủ và chi tiết trong quản lý dự án truyền thống cần được thay thế bằng việc lên kế hoạch “Đúng sản phẩm – với đúng số lượng – tại đúng nơi – vào đúng thời điểm cần thiết”” (JIT) cho các bộ phận của dự án để mang lại giá trị cao nhất và được hiểu rõ nhất vào bất kỳ thời điểm nào. Về lý thuyết, JIT sẽ giúp bạn rất dễ để tạo ra sản phẩm vừa lòng khách hàng. Bạn đã quản lý bao nhiêu dự án nơi mà biểu đồ Gantt hoặc kế hoạch dự án được lên ý tưởng ban đầu  chỉ vài giờ sau cuộc họp? Thực tế cho thấy trong hầu hết các công ty đó, các nhà tài trợ muốn biểu đồ Gantt như một sự xác nhận rằng người quản lý dự án có quyền kiểm soát dự án và biết họ đang làm gì.Trong một dự án Agile / Scrum, nhà tài trợ (chủ sản phẩm) là một thành viên tham gia nhóm dự án và họ nhận ra giá trị nhanh hơn, từng bước thay đổi ý định và điều chỉnh sản phẩm khi họ nhìn thấy dự án cùng với đội phát triển.

Thói quen #2 – Quản lý và quản lý

Một dự án Scrum cơ bản là một dự án mà nhóm phát triển được trao quyền để đưa ra quyết định vì chủ sản phẩm cũng là một phần của quá trình. Bằng việc tước đi quyền tự ra quyết định và thay đổi của đội ngũ làm việc, nhiều tổ chức đang tự khiến cho dự án trở nên không có hiệu quả. Nếu một nhóm dự án không có quyền đưa ra quyết định, không đưa thêm một mục đề nghị cần thực hiện cho ban lãnh đạo vào tháng tới thì họ vẫn chưa được cho phép để thành công.

Thói quen số #3 – Thời gian, Phạm vi hoặc Ngân sách

Quản lý dự án truyền thống giới thiệu khái niệm về Bộ ba ràng buộc: Thời gian, Phạm vi và Ngân sách. Quản lý dự án “Tam giác sắt” phải được ban giám đốc quản lý chặt chẽ trong TPM. Trong một dự án Scrum, thời gian và chi phí được cố định (“time boxed”) trong mỗi chu trình sprint và phạm vi được xác định bởi chính nhóm quản lý và bị khoá ngay khi bắt đầu một sprint mới. Vai trò của người quản lý trong Scrum không phải là quản lý và thiết lập chúng. Đây sẽ là một cuộc vật lộn thật sự cho một số người quản lý dự án vì lợi ích các nhân để luôn cố mở rộng phạm vi, cắt giảm ngân sách hoặc rút ngắn thời hạn công việc. TPM cho phép quản lý dự án đánh giá những yêu cầu thay đổi và xử lý chúng, điều này thường dẫn đến những biện pháp chữa cháy và khoa trương, khiến cho kế hoạch dự án không còn được triển khai như ban đầu. Trong một dự án Agile/Scrum, chủ sản phẩm phải buông bỏ điều này và đồng ý cam kết phạm vi công việc trong quá trình lên kế hoạch sprint. Rủi ro sẽ giảm theo thời gian của chu trình sprint, do đó tiến trình có thể được thay đổi vào cuối chu trình sprint, thay vì quay lại giai đoạn thiết kế sau 6 tháng.

Kết luận

Các công ty đang cố gắng trở nên “Agile” hơn bằng cách áp dụng khái niệm Agile/Scrum cho dự án phát triển phi phần mềm. Mặc dù các khái niệm này có thể làm giảm nhiều điểm gây tổn thương mà họ đã phải giải quyết trong nhiều năm qua và Agile có vẻ rất minh bạch, thì điều quan trọng vẫ là đừng để bị lừa bởi tính đơn giản của cuốn Scrum Guide- Hướng dẫn áp dụng phương pháp Scrum (chỉ là 17 trang thôi mà!) hoặc nghĩ rằng bạn chỉ việc áp dụng các khái niệm dễ dàng mà không cần đánh giá chu đáo các nguyên tắc cơ bản. Các doanh nghiệp nên xem xét các vấn đề mà họ đang phải cố gắng giải quyết bằng cách chuyển sang áp dụng Agile / Scrum, liệu TPM có vấn đề hay vấn đề thực sự nằm ở nội bộ công ty? Nếu là lý do thứ hai, thì Agile/Scrum sẽ không phải là thần dược. Có rất nhiều cạm bẫy trên con đường chạm đến Agile/Scrum, việc bạn kém hiểu biết nhưng vẫn cố chấp áp dụng Scrum có thể sẽ tồi tệ hơn nhiều lần việc chưa làm tốt các phương pháp quản lý dự án truyền thống. Vậy hãy cẩn trọng với quyết định của mình.