APMP.VN

Phần 1: Tuổi của dự án và trường hợp cho Agility (sự  linh hoạt)

Những giải pháp hoàn hảo và không có mục tiêu rõ ràng – theo quan điểm của tôi – là đặc điểm của thế hệ chúng ta.

Trở lại năm 2001, Hugues Bouchard, một nghiên cứu sinh quản lý dự án chuyên nghiệp, và tôi đã viết một bài báo chào mừng mọi người đến với cái gọi là “Thời kì của dự án”, thế kỷ 21 của chúng ta. Bài báo sau đó được sử dụng để làm khởi điểm cho việc phát triển phiên bản đầu tiên của chỉ số PMI (Purchasing Managers’ Index) “Tiêu chuẩn Quản lý Danh mục Đầu tư”. Sau đó, đây là những gì chúng tôi thấy được:

Thời đại của chúng ta đặc trưng bởi:

• Áp lực cạnh tranh toàn cầu.
• Sự cần thiết phải làm nổi bật mình trong thị trường toàn cầu.
• Yêu cầu phải đáp ứng những quy tắc và quy trình quốc tế chất lượng cao, được chấp nhận ở các thị trường mới và có tính cạnh tranh cao hơn.
• Vòng đời của sản phẩm ngày càng ngắn.
• Các nhu cầu phát triển sản phẩm mới nhanh hơn.

Các tổ chức ngày nay buộc phải đầu tư nhiều tài nguyên hơn vào các dự án chiến lược trong cuộc đua giữ vững vị trí thống trị đối thủ và tăng giá trị cho chủ sở hữu, cổ đông, khách hàng, nhân viên hoặc toàn xã hội.

Trong những lĩnh vực kinh tế mới (công nghệ sinh học, viễn thông, công nghệ thông tin, thương mại điện tử…), các công ty “hỗn hợp” mà thực thi càng nhiều hoạt động hoặc nhiều công việc về khía cạnh dự án hơn là khía cạnh chức năng/ truyền thống trong việc kinh doanh, thì ngày càng ngày tham gia nhiều vào việc phát triển các văn phòng dự án, hệ thống quản lý chương trình, quản lý danh mục đầu tư và các quá trình “gating”, các cấu trúc tổ chức quản lý dự án chiến lược và các vấn đề tương tự.

Thậm chí các doanh nghiệp sản xuất truyền thống còn bị bắt buộc bởi sự cạnh tranh toàn cầu và những áp lực về thời gian đưa sản phẩm mới ra ngoài thị trường, phải đầu tư vào những dự án chiến lược để giữ vững lợi thế. Khi làm như thế, họ phải thích ứng với một nền văn hóa thực dụng mạnh mẽ, với những nhu cầu đặc biệt của việc phân phối thông qua các dự án độc đáo, “một lần và duy nhất”. Trong trường hợp này, các doanh nghiệp cũng đang phát triển những phiên bản hệ thống quản lý danh mục đầu tư dự án, các quy trình “gating”, các văn phòng hỗ trợ dự án cho riêng mình, đôi khi trong một không khí rất khó chịu. Điều này đặc biệt đúng với các doanh nghiệp vẫn phải duy trì văn hoá thực dụng mạnh mẽ, đồng thời lại cam kết sẽ dành nhiều thời gian và nguồn lực hơn cho các sáng kiến ​​dự án.

Bạn có nhận ra môi trường kinh doanh của mình? Tôi tin rằng những từ này vẫn xác định chính xác những thời điểm hỗn loạn của chúng ta. Sự hỗn loạn này thậm chí còn tăng lên gấp nhiều lần trong một số trường hợp nhất định. Ngày nay, các dự án và các hoạt động định kỳ được kết hợp với nhau, vì thế cả trật tự chức năng và những thay đổi lộn xộn đều cùng tồn tại trong hầu hết các nơi làm việc.

Một trong những khách hàng gần đây đã nói với tôi rằng :”Công ty của chúng tôi có quá nhiều dự án, vì thế một trong những thách thức hằng ngày là chúng tôi vừa phải thực hiện các dự án đó, vừa phải làm công việc vận hành theo đúng cách. Nếu so sánh quá trình vận hành hiện tại của chúng tôi với hành động lái xe, thì những dự án đó khiến cho tôi cảm thấy như thể chúng tôi phải thay đổi động cơ xe trong khi vẫn đang lái xe ở tốc độ cao nhất”.

Tất cả những dự án này vẫn gây ra rất nhiều nhầm lẫn ở các doanh nghiệp, hầu hết họ vẫn chưa đưa ra một hệ thống quản lý danh mục đầu tư dự án đoàn thể phù hợp; nghĩa là, từ những quan sát và kinh nghiệm của tôi, đây là thực tế của đa số các doanh nghiệp mà tôi đã gặp phải. Về cơ bản, tôi đã tìm ra được môi trường dự án ở các doanh nghiệp đó, nó như sau:

• Các nhà quản lý cấp cao không đồng ý về số lượng dự án đang diễn ra trong công ty của họ, ước tính thường khác khoảng 10 lần.
• Hàng năm, phần lớn các nhà quản lý đều phàn nàn rằng họ có quá nhiều dự án phải thực hiện (họ không đủ người).
• Hội chứng “Dự án của ngày” luôn xuất hiện, chỉ những vấn đề cấp bách mới thì hiện tại mới được tiếp nhận.
• Các tài nguyên dành cho dự án có hoặc rất ít hoặc không có giá trị gì đối với tổ chức.
• Rất nhiều nỗ lực được dành ra khi bắt đầu những dự án kết thúc mà không bao giờ hoàn thành.

Giữa tất cả nhầm lẫn này, môi trường đa dự án cũng đã tạo ra một hình thức quản lý dự án nguyên bản mới, là người quản lý dự án bán thời gian làm việc với nhóm dự án bán thời gian.

Những gì tôi nói bây giờ không phải là kết quả của một nghiên cứu chính thức (sẽ được thực hiện trong tương lai gần), mà là một thước đo bảo thủ nói chung của động lực “Thời đại dự án”, dựa trên các cuộc khảo sát không chính thức. Mặt khác, trong các công ty tôi đã làm việc với tư cách là một huấn luyện quản lí dự án ngoài nội bộ, và trong những hội thảo dành cho hàng trăm thành viên của nhóm dự án đến từ mọi thể loại tổ chức, công ty, tôi đã nhận được những câu trả lời dưới đây, khi tôi hỏi họ về các tình huống liên quan đến dự án:

• Chỉ khoảng 1 người trong số 15 (7%) làm việc toàn thời gian với tư cách là một người quản lý dự án.
• Trong số những người làm việc toàn thời gian như một quản lý dự án trên, chỉ có 1 trong 10 chỉ làm việc với 1 dự án tại một thời điểm nhất định (nghĩa là 1 trong 150 người, ít hơn 0,7%, quản lý dự án làm việc như một quản lý dự án toàn thời gian mà chỉ thực hiện một dự án duy nhất).
• 149 người trong số 150 (99,3%) làm việc với nhiều dự án cùng lúc, chỉ có 10 người trong số họ làm duy nhất một dự án.
• 140 người còn lại (94%) làm cả các hoạt động định kỳ trong vai trò chức năng truyền thống và cả nhiều dự án cùng một lúc.
• Hơn 75% số người được khảo sát làm việc đồng thời nhiều hơn 5 dự án , 20% thừa nhận làm việc đồng thời trên 10 dự án, không thể  tinn được(trong khi họ vẫn làm công việc định kì cùng một lúc).
• Hầu hết các dự án này có tính đa chức năng, nghĩa là phần lớn nhóm dự án không đến từ cùng bộ phận chức năng với người quản lý dự án, do đó họ không báo cáo với cùng quản lý của bộ phận chức năng.
• Phần lớn những người làm cả về dự án và cả các hoạt động định kỳ đều có những đánh giá hiệu suất, dựa trên sự thăng tiến, tăng lương và tiền thưởng phụ thuộc, chứ không đánh giá hiệu suất của họ trong các dự án cũng như sự đóng góp vào kết quả dự án. (Vậy, họ có gì trong những dự án đó?)

• 8 người trong 10 (80%) nói rằng, thứ tự ưu tiên cho các dự án mà họ đang làm không rõ ràng và thay đổi liên tục, vì những lý do họ không xác định được.

Do đó, vì sự nhầm lẫn thêm vào về các ưu tiên và mục tiêu quản lý không rõ ràng này, đại đa số người được khảo sát thừa nhận rằng, trừ khi có những việc “khẩn cấp” phải làm, ví dụ như theo yêu cầu của lãnh đạo, họ sẽ quyết định sẽ thực hiện dự án nào vào một ngày nhất định, và cơ sở cho quyết định này chính là “những gì làm họ hài lòng hoặc hứng thú nhất, hoàn toàn dựa trên cấp độ cá nhân”.

Vậy điều đó nói gì về trường hợp Agility, và chúng ta đang nói về loại Agility nào?

Theo như những gì tôi đã thấy và trải nghiệm, môi trường dự án tổ chức hiện tại không liên quan gì đến mô hình của thế giới dự án mà các nhà quản lý dự án chuyên nghiệp thực hiện với đội ngũ làm việc chuyên nghiệp. Tốt nhất, chúng ta đang nói về các doanh nghiệp mà họ chủ yếu là thực hiện các dự án ở chế độ “ma trận yếu” (không có nhà quản lý dự án toàn thời gian ở hầu hết các dự án). Đối với những doanh nghiệp mà “nhà quản lý dự án” không phải là vị trí chính thức trong cơ cấu tổ chức, đó chỉ là vai trò của một người có nhiều điều khác để làm và quản lý hơn là các dự án. Những người này làm việc trong một môi trường dự án luôn thay đổi, nơi mà các ưu tiên được xác định lại liên tục, thường là vì các lý do chính đáng nhưng không được truyền tải nghiêm túc. Môi trường như vậy đòi hỏi rất nhiều sự linh hoạt từ các nhóm dự án để thích nghi nhanh với các tình huống mới, đây cũng là ý nghĩa cơ bản của Agility.

Trong bối cảnh kinh doanh, Agility nghĩa là “khả năng thích ứng nhanh chóng và hiệu quả với những thay đổi”. Tuy nhiên, trong bối cảnh đa dự án như mô tả ở trên, thì Agility đại diện cho một thách thức lớn hơn việc chỉ kết hợp các quy trình mà con người cùng dịch chuyển “theo quy luật tự nhiên”, nhằm hướng tới mục đích chung. Chúng ta đang nói về con người cùng dịch chuyển “tâm lý” với nhau, theo một tầm nhìn chung, đồng thời phục vụ cho cả những lợi ích cá nhân khác nhau, đạt được thông qua các mục đích cá nhân, mạch lạc và phù hợp. Để đạt được điều đó một cách nhanh chóng, theo như Albert Einstein, không có cách thức tự nhiên nào sẽ bù đắp lại được cho việc nhầm lẫn giữa các mục tiêu, kéo tất cả các thành viên của nhóm dự án và cả doanh nghiệp ra xa nhau.

Agility không chỉ là điều cần thiết để vượt qua những hỗn loạn của Thời kỳ Dự án, chúng ta cùng cần có Agility để đạt được sự tự do tôn trọng, bằng cách huy động tất cả các bên liên quan dù hành động riêng lẻ, nhưng vẫn dịch chuyển thống nhất theo một tầm nhìn chung. Tất cả các nỗ lực của một quá trình quản lý dự án Agile phải tập trung vào việc đạt được sự liên kết giữa các ý kiến và mục tiêu cá nhân. Các bên liên quan của dự án phải chia sẻ một tầm nhìn chung và tiến tới một kết quả chung, một kết quả dự án “mang tính cá nhân” mong muốn, trong khi vẫn làm đồng thời với các công việc dự án và hoạt động yêu cầu khác.

Phần 2: 8 Nguyên Tắc Để Quản Lí Một Dự Án Agile

Ở phần 1, trong bối cảnh hiện nay, khi mà môi trường kinh doanh khá là hỗn loạn, chúng ta đã định nghĩa “Agile” thực sự là gì và ý nghĩa của nó đối với các doanh nghiệp và nhà quản lý dự án trong năm 2011. Kết luận được đưa ra là, ưu điểm linh hoạt của mô hình Agile sẽ giúp dự án vượt qua được giai đoạn hỗn loạn của vòng đời của dự án. Tuy nhiên để áp dụng thành công phương pháp Agile thì đòi hỏi sự tham gia của tất cả các bên liên quan, tuy hoạt động độc lập, riêng biệt với nhau, nhưng họ vẫn gắn kết chặt chẽ thành ‘’ thể thống nhất’’ với một tầm nhìn chung. Điều này chỉ có thể thực hiện được bằng cách thiết lập một khuôn khổ Agile, nhằm liên kết những người đều có các ý tưởng, mục tiêu riêng nhưng vẫn chung tầm nhìn để tiến tới một kết quả chung cho bất kỳ dự án nào … tất cả những việc đó được thực hiện đồng thời trong “môi trường làm việc đa nhiệm” vô cùng phức tạp. Tuy nhiên, nếu muốn tập hợp mọi người cùng hành động, điều cần làm đầu tiên là phải đảm bảo được lợi ích chung cho tất cả mọi người.

Quản lý một dự án giống như việc chèo thuyền trên dòng nước hỗn loạn, mọi người cùng chung một con thuyền và có chung một đích đến.

Để giúp bạn hiểu bản chất của các dự án, ở đây tôi sẽ sử dụng ví dụ tương tự là một cuộc hành trình tập thể, hay so sánh dễ hơn thì là một chuyến đi của gia đình, bằng thuyền và mọi thành viên đều mong muốn cùng một điểm đến. Nếu đó không phải là mong muốn của tập thể, thì cuộc hành trình cũng như đích đến sẽ chẳng còn gì thú vị nữa. Mỗi thành viên trong gia đình đều đã đồng ý thực hiện chuyến đi này, và mỗi người đều cần đóng góp sức mình để có một chuyến đi thành công cũng như đến được điểm đích mong đợi.

Để mô phỏng tốt hơn môi trường kinh doanh hỗn loạn hiện nay, chiếc thuyền nói trên không thể là một chiếc thuyền dài thông thường – chiếc thuyền hay được sử dụng để minh họa cho “làm việc nhóm” trong các áp phích cổ động. Trong những “poster” như vậy, môi trường kinh doanh hỗn độn mà các doanh nghiệp đang gặp phải hiện nay chắc chắn sẽ không được thể hiện rõ ràng lắm, khi bạn sử dụng hình ảnh dòng nước lặng yên bên dưới con thuyền dài. Khái niệm về làm việc nhóm trong các “poster” như vậy không phản ánh đúng cuộc sống thực trong các công ty. Tất cả thành viên trong đội ngũ làm việc giống như những người chèo thuyền (trừ nhà quản lý dự án, vì đây là người ra quyết định nhịp độ chèo thuyền nên sẽ không trực tiếp chèo thuyền), họ cần thực hiện động tác đồng thời, ăn khớp với nhau và dưới sự chỉ đạo của người chỉ huy. Chúng ta cũng có thể thấy rằng, những tay đua thuyền quay lưng lại đích đến của họ, vậy nên rõ ràng là các thành viên trong nhóm không cần biết mình sẽ đi đâu, họ chỉ cần chèo thuyền theo đúng chỉ dẫn.

Khi hình ảnh chiếc thuyền dài không thể minh họa được “làm việc nhóm” trong thực trạng môi trường dự án hiện nay, tôi có một đề xuất thế này, cũng như “phép so sánh thuyền” bên trên cho “teamwork”, nhưng hãy sử dụng hình ảnh những người chèo thuyền cùng nhau (giữa nhiều thứ khác) trên dòng nước đang vô cùng hỗn loạn. Để có một cuộc hành trình thành công như vậy, những người ở trên chiếc bè cần phải:

• Đồng ý là một phần của “dự án” này (họ có nhiều thứ khác có thể làm hơn trong môi trường làm việc đa nhiệm, và mọi điều cũng có thể sẽ thú vị hơn nếu có chút mạo hiểm). Họ chia sẻ một mục đích chung vì họ muốn đạt được kết quả gì đó.

• Hiểu chính xác những phần việc của mình ( họ phải chịu trách nhiệm cho phần nào trên bè) cũng như có kỹ năng gì để thực hiện chúng… Họ có vai trò, trách nhiệm rõ ràng, kiến ​​thức, kỹ năng để thực hiện chúng, và họ ý thức được trách nhiệm cá nhân trong từng hành động của mình.

• Họ khá tự chủ trong hành động, ví dụ như khi nhìn thấy một hòn đá hoặc một làn sóng lớn đang tiến tới chiếc bè, họ không được chờ đợi hiệu lệnh mới hành động… Đích đến là chung, nhưng mỗi người sẽ tự quyết định hành động của mình.

• Có thái độ nghiêm túc về vai trò của mình trên chiếc bè, vì họ biết rằng nếu họ thất bại, họ sẽ cùng chìm với con thuyền ấy… họ phải tự cảm thấy có trách nhiệm với những gì phải làm.

• Hiểu rằng họ phải giúp đỡ lẫn nhau, bởi vì chỉ cần một người không thể vượt qua được chướng ngại vật,  họ sẽ có khả năng bị chìm … Họ sẽ có cảm giác phụ thuộc lẫn nhau (điều mà bất kỳ một nhóm đích thực nào cũng có) và, như một đội ngũ, họ thấy phải có trách nhiệm chung đối với sự thành công của cuộc hành trình.

• Cuối cùng, hiểu rằng cuộc hành trình cũng như điểm đến cuối cùng sẽ phải sửa đổi trong suốt chuyến đi… Họ cần linh hoạt và thích nghi được với hoàn cảnh mới để đảm bảo hành trình suôn sẻ và đạt được kết quả mong đợi.

Các điều kiện thành công trên cũng giống như các điều được phản ánh trong 8 nguyên tắc của nền tảng Agile mà tôi đề xuất dưới đây. Những nguyên tắc này không phải là mới, chúng đã được thảo luận toàn bộ hoặc một phần trong nhiều cuốn sách về quản lý dự án the phương pháp Agile / Lean. Tuy nhiên, chúng không nhất thiết phải được trình bày như là các nguyên tắc BẮT BUỘC phải áp dụng nếu muốn đạt được những dự án thành công một cách nhất quán.

Để có được sự gắn kết cần thiết với các lợi ích cá nhân, khuôn khổ Agile được thực hiện phải đạt ít nhất hai mục tiêu:

• Làm cho các bên liên quan của dự án cảm thấy có trách nhiệm cá nhân đối với phần công việc họ đóng góp trong dự án, đồng thời biết rằng họ là một phần của nhóm – nhóm mà các cá nhân đều phụ thuộc lẫn nhau, đều chịu trách nhiệm cho sự thành công của cả dự án lẫn cuộc hành trình đi đến đích cuối cùng đó.

• Tạo điều kiện và cơ chế để đảm bảo rằng tất cả mọi người trong các bên liên quan đều thấy, hiểu và muốn có chung một con đường và đích đến, do đó họ có cùng nhận thức về những gì đang diễn ra và những gì đang thay đổi, vì dự án và môi trường của dự án sẽ tiến triển theo thời gian .

5 trong số 8 nguyên tắc sẽ nhắm đến việc xây dựng trách nhiệm cá nhân và trách nhiệm tập thể, trong khi đó 3 nguyên tắc khác có mục tiêu là tạo ra một môi trường làm việc – nơi sự tiến triển của dự án được theo dõi và chia sẻ chung.

Để xây dựng trách nhiệm cá nhân và trách nhiệm tập thể, 5 nguyên tắc sau đây phải được áp dụng cho các công việc trong dự án:

1. Nguyên tắc: “Người hoạch định cuối”. Người thực hiện công việc cũng là người sẽ lập kế hoạch. Thông thường, người lên kế hoạch cuối cùng và quan trọng nhất chính là người dùng cuối của sản phẩm cuối dự án, và thường thì chúng ta luôn bỏ qua bên liên quan này trong dự án.

2.Nguyên tắc: “Năng lực”. Mọi người làm việc trong một dự án phải có đủ thông tin về dự án để có thể cùng chia sẻ tầm nhìn của dự án cũng như cảm thấy có mối liên hệ với các thành viên khác trong nhóm. Họ nên cảm thấy như là một phần quan trọng của một tập thể quan trọng.

• Kiến thức và kỹ năng để đáp ứng được những mong đợi về mình.
• Tài nguyên vật chất và hỗ trợ liên quan để thực hiện được mong đợi.
• Thời gian cho các mức độ nỗ lực để đáp ứng thành công mong đợi.

Nếu những điều kiện đó không được đáp ứng, họ sẽ không sẵn sàng nhận trách nhiệm về việc sẽ thực hiện những gì được mong đợi. Họ thậm chí có thể từ chối trực tiếp hoặc làm cản trở công việc

3. Nguyên tắc: “Sự khao khát”. Lợi ích cá nhân sẽ không gắn liền với dự án:

• Nếu thực tế là làm việc trong một dự án cụ thể nhưng không có một “phần thưởng” nào cho người thực hiện công việc (câu hỏi đặt ra là “Tôi được gì từ dự án này?”).

• Nếu phần thưởng này không tỉ lệ thuận với nỗ lực để thực hiện tốt công việc (“Có đáng không?”).

Vì vậy, nếu lợi ích cá nhân của một thành viên trong nhóm không được quan tâm, người này có thể sẽ muốn làm những công việc khác – phần thưởng xứng đáng hơn – thay vì là dự án của bạn.

4. Nguyên tắc “Theo dõi từng hứa hẹn nhỏ của mỗi cá nhân”. Các thành phẩm của dự án được chia thành những lời hứa nhỏ, “có thể quan sát được”, trong khoảng thời gian rất ngắn. Ví dụ, mỗi tuần một lần và chia thành các sản phẩm có mức nỗ lực là 80 giờ lao động hoặc ít hơn. Những hứa hẹn đó là từ mỗi thành viên trong nhóm, chứ không phải là các lời hứa của ông chủ hoặc người quản lý dự án.

5. Nguyên tắc: “Nhóm tích hợp”. Bạn phải mở rộng nhóm dự án “truyền thống” để bao quát và tích hợp hết tất cả các bên liên quan thành một phần của nhóm càng sớm càng tốt. Đối với một số người, nhận ra sự phụ thuộc lẫn nhau, kết nối các bên liên quan cũng như phát triển trách nhiệm chung là vô cùng quan trọng.

3 nguyên tắc để tạo và duy trì một môi trường Dự án «Sẻ chia»

Giống như các nguyên tắc được thảo luận ở trên, tôi cũng sẽ đưa ra những mô tả ngắn gọn về ba nguyên tắc hỗ trợ việc tạo lập và duy trì môi trường dự án “chia sẻ”.

Điều mà chúng ta nên cố gắng đạt được thông qua việc sử dụng các nguyên tắc này là sắp xếp các nhận thức. Tôi tin rằng một trong những nguyên nhân chính dẫn đến thất bại của dự án chính là vì các bên liên quan không có nhận thức chung về dự án, về tình hình hiện tại của nó, cũng như nó đã thay đổi và đang tiến triển như thế nào. Quản lý dự án có nghĩa là quản lý nhận thức, không làm được như vậy là một sai lầm lớn và có thể dẫn một dự án thất bại. Để đưa ra môt môi trường dự án mang tính “chia sẻ”, phải áp dụng 3 nguyên tắc sau đây vào công việc trong dự án:

1. Nguyên tắc: “Gần gũi”. Các khách hàng, nhà tài trợ, nhà cung cấp, nhà thầu, chuyên gia dự án, người sử dụng cuối cùng không chỉ là một phần của nhóm dự án tích hợp, mà họ phải nhận được phản hồi liên tục về những gì đang xảy ra. Mọi thay đổi của dự án đều cần được truyền đạt và phản hồi trở lại nhằm đảm bảo cho sự nhận biết chung. Không nên có bất kì bên nào bị loại ra khỏi sự kết nối đó.

2. Nguyên tắc: “Không có gì để ngạc nhiên”. Đây là một nguyên tắc hỗ trợ để chắc chắn rằng chúng ta thực sự gần gũi (hỗ trợ cho  nguyên tắc “gần gũi”). Cuối cùng nguyên tắc này được sử dụng để loại bỏ, càng nhiều càng tố,t những bất ngờ của bất kỳ một bên liên quan nào khi dự án diễn ra các thay đổi. Khi thời gian giữa sự thay đổi một sự kiện và thời điểm nó được công bố càng kéo dài, sự bất ngờ sẽ càng lớn … và cảm giác bị giữ trong bóng tối và “mù thông tin” lại càng lớn. Bằng cách loại bỏ hiệu ứng “bất ngờ lớn”, các bên liên quan sẽ được chuyển sang chế độ “thích ứng” với những thay đổi thường xuyên của dự án (cơ chế để trở nên “agile” được) thay vì là chế độ « phòng chống» vì những thay đổi họ không nhìn thấy.

3. Nguyên tắc “Tăng cường lợi ích”. Bạn càng nhanh chóng có được lợi ích từ dự án – điều đó nghĩa là trong suốt cuộc hành trình của dự án, không chỉ vào cuối dự án – thì càng tốt. Xét cho cùng, chúng ta đang ở trong một dòng nước hỗn loạn và chúng ta không chắc sẽ đi về đâu, vậy tại sao không đạt thu hoạch “lợi ích” ngay khi có thể. Trên thực tế, nếu có một nguyên tắc luôn gắn liền với Quản lý Dự án Agile thì chính là nguyên tắc này, như nó đã được mình họa bằng mục đích của các kĩ thuật timeboxing cũng như scrum – những nền tảng của hầu hết mọi phương pháp Agile. Các lợi ích rõ ràng, có thể nhìn thấy được, cùng với những thành phẩm hữu hình của dự án là một trong những cách hiệu quả nhất để đảm bảo các bên liên quan đều thấy được một sự tiến triển chung của dự án, vì mọi người cũng chia sẻ kết quả cụ thể, dễ hơn là chỉ chia sẻ ý tưởng và các lợi ích vô hình.

Tôi phải nói thêm rằng những lợi ích được đề cập ở đây không chỉ là kết quả đạt được chính thức của dự án, mà chúng còn là các lợi ích gắn liền với việc đáp ứng được các quyền lợi cá nhân của thành viên trong nhóm. Việc không đem lại những lợi ích như vậy là chống lại nguyên tắc “Sự khao khát”, và khi đó, bạn sẽ đặt cả cuộc hành trình và điểm đến của  dự án vào tình trạng nguy hiểm.

Tóm lại, trên đây là 8 nguyên tắc cơ bản của khuôn khổ Agile hiệu quả, như tôi thấy:

• Nguyên tắc người hoạch định cuối
• Nguyên tắc năng lực
• Nguyên tắc sự khao khát
• Nguyên tắc theo dõi từng hứa hẹn nhỏ của mỗi cá nhân
• Nguyên tắc nhóm tích hợp
• Nguyên tắc gần gũi
• Nguyên tắc không có gì để ngạc nhiên
• Nguyên tắc tăng cường lợi ích

Phần 3: 4 Kỹ thuật Quản lý Dự án Agile Và Tại sao đôi khi chúng lại không thành công?

Có rất nhiều kỹ thuật liên quan đến điều mà ngày nay chúng ta gọi là quản lý dự án Agile. Trong đó, 4 kỹ thuật có vẻ như được sử dụng ở hầu hết các dự án là:

1. Dynamic planning (Quy hoạch động), còn được gọi là “quy hoạch sóng lăn”

2. Timeboxing

3. Scrum

4. Các đường cong thể hiện sự phát triển của thành phẩm, thường được gọi là “biểu đồ burndown hoặc burnup”, “biểu đồ vận tốc” hoặc “các đường cong thể hiện phần trăm hứa hẹn được hoàn thành”, hay ngắn gọn là “đường cong PPC”.

Mục đích ở đây không phải là để giải thích chính xác lý thuyết của những kỹ thuật trên, mà là cách chúng thường được áp dụng đối với 8 nguyên tắc Agile được đề cập trong Phần 2 như thế nào. Để biết thêm thông tin về từng kỹ thuật này, bạn có thể đọc những Tài liệu được đề cập trong chú thích.

Trên đây là bản tóm tắt các quan sát của tôi về số lượng các doanh nghiệp, tổ chức sử dụng 4 kỹ thuật đó. Các kỹ thuật này thường được sử dụng một cách mù quáng và rập khuôn, giống như một “công thức nấu ăn” vậy, và nó cũng hay tuân theo các tham số cứng nhắc. Tôi đã rất ngạc nhiên khi có những tranh cãi về các thông số rất cụ thể với người chịu trách nhiệm việc thực hiện Agile (đối với người này, có nghĩa là thực hiện “Timeboxing” và “Scrum”) trong một công ty rất lớn, và hầu hết mọi dự án đều liên quan đến CNTT. Tôi đang chuẩn bị một hội nghị cho bên đó về chủ đề quản lý dự án Agile. Tôi dự định đưa ra một số ví dụ về các giai đoạn của “Timeboxing” và thời gian thực hiện một “Scrum”. Tôi đã được yêu cầu gửi trước những tài liệu trình bày của tôi để xác nhận, sau đó tôi được cho biết rằng theo nguyên tắc của họ, một “Timebox” không được hơn 15 ngày và một “Scrum” phải kéo dài 10 phút … và tôi cần sửa đổi bản trình bày cho phù hợp. Tôi hiểu rằng việc thực hiện các kĩ thuật trên chẳng liên quan gì đến 8 nguyên tắc của Agile, nhưng thật đáng buồn khi bạn lại tìm kiếm một công thức phổ quát để giải quyết cho một vấn đề, nhu cầu cần sự linh hoạt trong công ty. Thế hoá ra, các công thức này đang quảng cáo cho một thứ đi ngược hoàn toàn với “sự linh hoạt”.

Các quan sát được tóm tắt trong Bảng trên cần phải được kiểm tra khoa học bằng các cuộc khảo sát thích hợp. Tuy nhiên, tôi tin rằng chúng là đại diện của nhiều cách triển khai kỹ thuật Agile khác nhau. Nhiều doanh nghiệp cố gắng duy trì một môi trường làm việc được đánh giá là “có kiểm soát” (đối với hầu hết hiện trạng), hơn là thích ứng với một môi trường làm việc hỗn độn và nhiều thay đổi thông qua các giá trị mới như “hợp tác”, “làm việc nhóm” hay “trách nhiệm tập thể”. Bằng cách làm như vậy, họ đã phá hủy mục tiêu của cách tiếp cận Agile mà họ đang cố gắng thực hiện. Họ “chiến đấu” để giữ nguyên hiện trạng, trong khi Agile yêu cầu họ phải chấp nhận thay đổi và quản lý nó.

The “Theory Of Constraints” (Tạm dịch: Lý thuyết điểm hạn chế) và Lý do vì sao tích hợp Nguyên Tắc Agile vào việc thực hiện phương pháp Agile hiện tại còn nhiều thiếu sót.

“Timeboxing” và “Scrum”, như tên gọi, là các kỹ thuật Agile có nguồn gốc từ ngành Phát triển phần mềm. “Dynamic planning” và “Theo dõi các sản phẩm / hứa hẹn hữu hình” với “đường cong PPC” có liên quan đến cả thế giới phát triển phần mềm và thế giới của Lean Construction Management (Tạm dịch: Quản lí xây dựng Lean) –  được thúc đẩy bởi Viện Xây dựng Lean. Tuy nhiên, phải chắc chắn rằng những lời hứa đó được thực hiện bởi các cá nhân cung cấp, có liên quan đến nguyên tắc “Người hoạch định cuối” (The Last Planner) – một nguyên tắc không hề được tán thành và trình bày một cách tổng quát bởi các chuyên gia phát triển phần mềm viết sách về Agile. Quản lý dự án xây dựng Lean cũng khuyến khích “nhóm dự án tích hợp”.

Tôi đảm bảo rằng 8 nguyên tắc Agile đã được tôi đề cập đến trong Phần 2 là sự kết hợp giữa các nguyên tắc được áp dụng trong những dự án phát triển phần mềm Agile và trong các dự án xây dựng Lean. Bên cạnh nguyên tắc “Người hoạch định cuối” và “Nhóm tích hợp”, còn một yếu tố khác mà chúng ta có thể tìm thấy trong các sách và bài viết về quản lý xây dựng Lean, nó thường không được thảo luận trong tài liệu về phát triển phần mềm Agile. Yếu tố này giải thích:

• Tại sao nguyên tắc “Người hoạch định cuối” và “Nhóm Tích hợp” là cần thiết.

• Tại sao chúng ta cần thêm 2 nguyên tắc “Năng lực” và “Khao khát” để đạt được thành công trong dự án.

Tôi đang nói về việc tích hợp “Lý thuyết điểm hạn chế” của Goldratt trong việc quản lý dự án. Xây dựng tinh gọn đề xuất quản lý xung quanh các ràng buộc và nâng nó lên theo yêu cầu.

Trong các bài viết trước, tôi đã nói tất cả các dự án đều phải thay đổi. Tôi đề xuất rằng, trong bất kỳ một nỗ lực liên quan đến thay đổi nào, hạn chế đều liên quan đến nguồn nhân lực, chứ không phải nguồn lực vật chất hay kinh tế. Tôi xác định được hạn chế này là “năng lực và ý chí” để thay đổi chúng, điều này giải thích nhu cầu bao gồm tất cả các bên liên quan và đảm bảo rằng họ có thể và muốn thực hiện thay đổi. Trong bối cảnh này,  “Lý thuyết điểm hạn chế” của Goldratt là cách tiếp cận được cho là đã áp dụng cả 4 nguyên tắc thường thiếu sót khi thực hiện các kỹ thuật Agile trong hầu hết các dự án phát triển phần mềm. Không nghi ngờ gì nữa, bằng cách tuân thủ cách tiếp cận quản lý hạn chế của Goldratt, các dự án phát triển phần mềm sẽ trở nên tinh gọn và có kết quả tốt hơn. Tôi tin rằng, bằng cách áp dụng 8 nguyên tắc Agile, các dự án tại bất kỳ địa điểm nào cũng sẽ càng làm thỏa mãn hơn tất cả các bên liên quan và do đó sẽ thành công hơn.