Tại Sao Phương Pháp Agile Lại Thất Bại - Và Làm Sao Để Sửa Chữa Điều Đó

Trung Phong
13/07/2020 - 10:00 3493     0

Chúng ta sẽ cùng đi sâu vào các lời khuyên hữu ích, khám phá cách thoát khỏi lối tư duy khuôn mẫu, và xác nhận lại niềm tin của chúng ta rằng: thử nghiệm là yếu tố vô cùng quan trọng để một đội nhóm hay một tổ chức trở nên xuất sắc.

 

 

 

Với tinh thần ngày càng thích nghi hơn, các tổ chức đã gấp rút thực hiện phát triển phần mềm linh hoạt (Agile). Nhưng nhiều người lại làm theo cách khiến nó thực sự không hề linh hoạt. Các công ty này chỉ trở nên linh hoạt hơn trong tên gọi, vì quá trình mà họ áp dụng thường kết thúc bằng những tác động tiêu cực vào động lực và năng suất kỹ thuật.

 

Phát triển phần mềm linh hoạt

Các khung phát triển phần mềm thích ứng như phương pháp Agile đã xuất hiện từ lâu và được thể hiện dưới nhiều hình thức. Nhưng cốt lõi của hầu hết các mô hình này gồm hai thứ: xây dựng các giả thuyết (ví dụ, tính năng cần phải hoàn thành là gì) và sự cộng tác giữa các lĩnh vực chuyên môn trong các thí nghiệm, tất cả đều dựa trên tinh thần học hỏi và không tiếp tục chạy theo những phần đã được chứng minh là không chính xác.

Khi phát triển phần mềm linh hoạt ra đời vào năm 2001, nó đã kết nối bốn nguyên tắc quan trọng để nâng cao kỹ thuật phát triển phần mềm và cải thiện động lực quản lý sản phẩm và kỹ thuật.

1. Các cá nhân và tương tác hơn là các quy trình và công cụ

2. Phần mềm làm việc hơn là tài liệu đồng bộ hỗn hợp  

3. Hợp tác khách hàng hơn là đàm phán hợp đồng

4. Đáp ứng với thay đổi hơn là chỉ theo kế hoạch

Trong ba năm qua, thông qua nghiên cứu về động lực của con người, chúng tôi đã phân tích công việc của các kỹ sư trong hơn 500 tổ chức khác nhau bằng cách sử dụng kết hợp các phương pháp dựa trên khảo sát và thử nghiệm. Chúng tôi đã phát hiện ra rằng những gì xảy ra trong thực tế phần lớn bắt nguồn từ những nguyên tắc đã nêu này.

Ví dụ, trong thực tế, các quy trình và công cụ đã trở thành cốt lõi của công việc, chứ không phải cá nhân và tương tác. Trưởng phòng sản phẩm kỹ thuật số trong một công ty thuộc Fortune 100 nói rằng: ”chúng tôi không được phép đặt câu hỏi về quy trình Agile.” Trong một công ty thuộc Fortune 500 khác, các nhà quản lý sản phẩm và kỹ sư giao tiếp chủ yếu thông qua các công cụ của họ, ban đầu được sử dụng để cấp trên đưa ra mệnh lệnh cho cấp dưới.

Tương tự, tài liệu thường là con át chủ bài của phần mềm làm việc. Ở một công ty công nghệ lớn, đội ngũ sản xuất ở đó tập trung phần lớn thời gian để soạn thảo những yêu cầu nhỏ (còn gọi là “câu chuyện người dùng”). Những yêu cầu này được đưa vào một hàng đợi dán nhãn và trở thành nhiệm vụ của các kỹ sư tiếp theo. Các thanh đựng tài liệu để giữ cho hàng đợi này hoạt động ngày càng cao hơn. Cuối cùng, cả quá trình chuyển thành một “thác nước” nhỏ, công việc được chuyển từ phòng sản xuất sang thiết kế rồi đến kỹ thuật. Quá trình này chính xác là điều mà phương pháp Agile muốn loại bỏ. Không có gì ngạc nhiên khi Giám đốc công nghệ (CTO) của công ty nói rằng: “Các kỹ sư của tôi cảm thấy điều này không khác gì việc làm vội một món ăn ở sau bếp.” 

Khi nói đến việc “đáp ứng với thay đổi thay vì chạy theo kế hoạch”, ý nghĩa của nó dễ bị hiểu sai thành “đừng lên kế hoạch nào cả”. Ví dụ, trong một công ty công nghệ đang phát triển nhanh, Đội ngũ Agile không cố gắng để hiểu chiến lược chung của toàn doanh nghiệp. Kết quả là những nỗ lực lặp đi lặp lại của họ thường chỉ tập trung vào những tính năng ít giá trị hoặc không có ý nghĩa chiến lược. Không có kế hoạch, các nhóm sẽ không biết cách ưu tiên công việc, cũng như đầu tư công sức một cách hợp lý. Hơn nữa, nguyên tắc này còn khiến cho các kỹ sư tin rằng việc xây dựng khung thời gian hay đặt ra các cột mốc là không phù hợp.

Sẽ có ý nghĩa nếu như việc ứng dụng sai thực sự cải thiện động lực và hiệu quả kỹ thuật, tuy nhiên trong thực tế, điều ngược lại đã xảy ra. Phương pháp Agile, khi được thực hiện như trên, làm giảm động lực làm việc của các kỹ sư. Bởi họ không được phép thử nghiệm, quản lý công việc của họ hay trao đổi với khách hàng, họ mất dần niềm vui trong việc, khả năng và mục đích; thay vào đó họ thấy áp lực về kinh tế và tinh thần để hoàn thành công việc, trở nên trì trệ tâm lý. Họ dừng thích nghi, học hỏi và không còn đặt tối đa nỗ lực vào công việc.

Ví dụ, một đối tác quỹ đầu tư mạo hiểm chia sẻ với chúng tôi làm thế nào mà một công ty phát triển trò chơi điện tử có thể tiếp tục phát triển sản phẩm trong suốt cả năm trời, trong khi chính kỹ sư lại cảm thấy nó còn không đáng để chơi. Công ty đã nhận ra rằng họ đang lãng phí tiền bạc và thời gian.

Tiến trình Agile thất bại, bởi vì khi các công ty cố gắng nâng cao hiệu quả làm việc, họ trở nên quá tập trung vào chiến thuật (chú trọng vào quá trình và quản lý vi mô), hoặc quá thích ứng (tránh các mục tiêu dài hạn, tiến độ, hay cộng tác liên chức năng).

Bí quyết là phải cân bằng cả biểu hiện chiến thuật và thích ứng. Cho dù bạn là kỹ sư hay quản lý sản phẩm, dưới đây là một vài thay đổi bạn có thể áp dụng để tìm kiếm sự cân bằng, từ đó cải thiện hiệu suất và động lực làm việc của đội ngũ kỹ thuật (hay ở bất cứ chuyên môn nào).

 

1. Phát triển phần mềm nên là một quá trình không bàn giao, hợp tác.

Thay vì một quá trình mà một người viết các yêu cầu (ngay cả những điều nhỏ nhặt) trong khi một người khác thực hiện mà không có một định hình chiến lược, một nhóm phấn đấu vì sự linh hoạt nên tiến hành quá trình không bàn giao so với quá trình mà một người viết các đề xuất trong khi người kia xử lý. Trong một quy trình không bàn giao, người quản lý sản phẩm và các kỹ sư (và bất kỳ bên liên quan nào khác) là đối tác hợp tác từ đầu đến cuối trong việc thiết kế một tính năng.

Đầu tiên, một nhóm, bao gồm các giám đốc điều hành, nên nêu rõ các “thách thức” chiến lược. Đưa ra thách thức dưới dạng câu hỏi, luôn tập trung cải thiện kết quả hoặc tác động tới khách hàng.  Nghĩ về chúng như một nhiệm vụ dưới dạng câu hỏi là để kích thích tư duy. Các thử thách được phát triển và lặp đi lặp lại bởi toàn đội, bao gồm các nhà tài trợ (và khách hàng). Mỗi một người trong nhóm (hoặc bất kỳ nhóm nào cho vấn đề đó) được yêu cầu đóng góp ý tưởng cho mỗi thử thách bất cứ khi nào họ muốn.

Ví dụ, trong một ngân hàng, thách thức lớn là, “Làm thế nào để giúp khách hàng chuẩn bị tốt hơn cho những cú sốc tài chính có thể xảy ra?” Hay là: “Làm sao để việc duy trì thói quen tài chính lành mạnh của khách hàng trở nên thú vị hơn? Những thử thách này đã tạo ra hàng tá ý tưởng khác nhau.

Sau đó, thay vì ai đó viết đề xuất trong khi một người khác thực thi, các nhóm này phát triển và hợp tác đưa ra ý tưởng, từ dự thảo sơ bộ đến giả thuyết có thể kiểm chứng.

 

2. Đơn vị phân phối của nhóm nên là các thử nghiệm tối thiểu có tính khả thi.

Các nhóm thường cảm thấy lãng phí thời gian khi phải thích nghi quá nhiều. Để tránh điều này, các ý tưởng không chỉ được xây dựng cho thách thức chiến lược, mà còn nên được thử nghiệm nhanh với mục tiêu vừa đủ để xác định đâu là cái phù hợp cho khách hàng.Nói cách khác, họ cần tối đa hóa tốc độ dẫn đến sự thật.

Để giảm bớt lãng phí và tăng quyền quyết định của nhóm, các thử nghiệm nên ngắn gọn. Mỗi thử nghiệm không nên lâu quá một tuần.

Và đôi khi điều này đòi hỏi cả nhóm phải tối thiểu hóa một tính năng bằng việc kiểm tra cả các giả định yếu nhất. Điều đó có nghĩa là nhóm không thực hiện mã hóa mà hoàn tất một thí nghiệm ngoại tuyến thông qua nghiên cứu.

 

 

3. Nhóm nên tiếp cận bằng cách lấy khách hàng làm trung tâm.

Quá trình xây dựng phần mềm (ngay cả phần mềm sử dụng nội bộ) nên lấy khách hàng làm trung tâm.

Đơn giản nhất, phải nắm được các nguyên tắc sau:

  • “Các thách thức” luôn đóng khung xoay quanh tác động của khách hàng.
  • Các cuộc họp luôn bắt đầu bằng một bản báo cáo cập nhật của khách hàng và các đại diện khách hàng cũng tham gia thường xuyên trong các cuộc thảo luận này.
  • Mỗi thí nghiệm được xây dựng xung quanh một giả thuyết lấy khách hàng làm trung tâm. Bằng cách đó, cả nhóm có thể chịu trách nhiệm về kết quả đạt được.

Tuy nhiên, quan trọng hơn là các kỹ sư thấy tận mắt khách hàng sử dụng sản phẩm của họ như thế nào. Điều này đòi hỏi vị trí tiền tuyến và các kỹ sư phải làm việc cùng nhau để xem sản phẩm có tác động tới khách hàng không.

 

4. Sử dụng khung thời gian để tập trung thử nghiệm và tránh lãng phí.

Khá thú vị khi phát triển phần mềm thích ứng khuyến khích các khung thời gian như một cách để đảm bảo thử nghiệm được đầu tư hợp lý và báo hiệu mức chất lượng chấp nhận được. Mặt khác, người thực hiện phương pháp Agile điển hình cần tránh các mốc thời gian hoặc thời hạn, vì chúng có thể tạo áp lực tinh thần. Một trong những cảm giác tồi tệ nhất đối với một nhà phát triển phần mềm là dành nhiều tháng để làm việc mà cuối cùng không thu được kết quả. Điều này khiến bạn cảm thấy áp lực tâm lý (Tôi để mọi người thất vọng) và trì trệ (tại sao tôi vẫn còn làm việc này?).

Để tránh hậu quả này, bạn cần rõ ràng về việc một kỹ sư nên đi bao xa trước khi họ kiểm tra lại xem hướng đi có còn đúng không. Giả thuyết càng không chắc chắn, rủi ro càng lớn, đường băng càng trở nên ngắn hơn so với ban đầu. Với suy nghĩ đó, khung thời gian không phải là thời hạn. Đó sẽ là ràng buộc về chất lượng và độ sâu của thử nghiệm trước khi tiến hành kiểm tra. Và theo cách này, khung thời gian có thể gia tăng sự thúc đẩy.

 

5. Nhóm nên được tổ chức để nhấn mạnh tính hợp tác.

Để đảm bảo bạn kết thúc với một quy trình không bàn giao, các bên liên quan nên hoạt động như một nhóm liên chức năng duy nhất, hay còn được biết đến là “pod”. Mục tiêu của nó là thúc đẩy sự hợp tác. Mỗi nhóm này nên bao gồm các chuyên gia đủ để tạo ra một sản phẩm tốt. Có thể gồm cả các giám đốc điều hành cấp cao. Trong một tổ chức (pod), ví dụ như một nhóm sản xuất sẽ bao gồm quản lý sản phẩm, kỹ sư đầu cuối, kỹ sư phụ trợ, nhà thiết kế, kỹ sư quản lý chất lượng, đại diện bán thời gian từ phòng dịch vụ khách hàng và giám đốc điều hành cấp cao với chức năng kiểm soát.

Trong nhiều tổ chức, có những dấu hiệu rõ ràng về “nhóm giả mạo” (faux pod), những nhóm tự nhận mình là “pod” nhưng thực tế không hoạt động như vậy. Dấu hiệu của “faux pod” bao gồm:

  • Các chuyên gia ở trong các đội sắp xếp riêng biệt, không phải cùng một đội. Ví dụ: một nhóm sản xuất có các phân nhóm chuyên môn. Các nhóm này không phải là “pod”.
  • Sử dụng các công cụ ngăn chặn sự cộng tác. Ví dụ, khi hỏi một nhóm kỹ thuật tại sao họ lại chọn các công cụ phần mềm linh hoạt mà họ đang sử dụng, họ nói: “Các công cụ này sẽ ngăn các giám đốc điều hành tham gia vào công việc của chúng tôi.” Điều này làm mất sự tin tưởng.
  • Bộ phận Kỹ thuật và Sản xuất thực sự có các mục tiêu khác nhau từ ban đầu. Các giám đốc điều hành trong cả hai bộ phận sử dụng quyền hạn cao cấp của họ để cấp dưới ưu tiên hơn mục tiêu của bộ phận đó, gồm cả mục tiêu của nhóm liên kết. Những xung đột này ngăn cản hoạt động nhóm  cuối cùng dẫn đến sự sụp đổ của cả nhóm.
  • Các quy trình phân cấp năng lực cứng nhắc, như xếp hạng năng suất, phân cấp chức danh, áp lực để được thăng chức và các hệ thống lên chức hoặc bị đuổi việc phá hủy tinh thần đồng đội cần thiết để giúp cho các nhóm hoạt động tốt. Các hệ thống này sẽ khiến cho các thành viên trong nhóm chú ý đến ông chủ hơn là khách hàng hoặc làm cho các thành viên phải cạnh tranh lẫn nhau. Dù theo cách nào họ cũng sẽ không hoạt động như một nhóm.

Nói cách khác, cấu trúc silo của tổ chức càng mạnh, càng nhiều người giải quyết được nhu cầu trong silo của họ, so với nhu cầu của cả nhóm. Điều này khiến cho việc hợp tác và đồng thuận trở nên rất khó để đạt được nếu không có sự leo thang liên tục. 

 

 

6. Nhóm nên liên tục đặt câu hỏi về quy trình của họ.

Có một câu châm ngôn nổi tiếng trong kỹ thuật được gọi là Luật Conway. Nó chỉ ra rằng: bất kỳ tổ chức nào thiết kế một hệ thống sẽ tạo ra một thiết kế có cấu trúc là bản sao giống với cấu trúc thông tin của nó. Nói cách khác, nếu bạn là một tổ chức nguyên vẹn, bạn sẽ tạo ra các thiết kế nguyên vẹn. Nếu bạn tổ chức theo phân khúc người dùng, sản phẩm của bạn sẽ tối ưu hóa cho cấu trúc đó.

Nếu muốn loại bỏ Luật Conway, cách tốt nhất là liên tục điều chỉnh cấu trúc và quy trình để phù hợp với vấn đề hiện tại. Điều này đòi hỏi các nhóm xây dựng trên quy trình và cấu trúc đơn giản để liên tục đặt câu hỏi và điều chỉnh.

Vì vậy, thay vì áp đặt phương pháp Agile như tôn giáo, các nhóm kỹ thuật nên giữ thói quen liên tục chẩn đoán và lặp lại mô hình vận hành nhóm của riêng họ. Lấy một ví dụ khá thành công: hàng tháng, các nhóm chẩn đoán mô hình hoạt động của họ và quyết định xem có cần thay đổi gì để tạo ra sản phẩm tốt hơn không.

***

Khả năng thu hút, truyền cảm hứng và giữ chân nhân tài trong ngành kỹ thuật số đang trở thành nhiệm vụ vô cùng quan trọng đối với mọi tổ chức. Hầu hết các tổ chức đang trở thành con mồi của một thông điệp đơn giản - thực hiện phương pháp Agile như một loạt các nghi lễ thì mọi thứ sẽ trở nên tốt hơn. Không may rằng, điều này không có nhiều ý nghĩa khi giá trị con người bị lược bỏ. Bằng cách quay trở lại nền tảng để gia tăng động lực và năng suất thích ứng, bạn hoàn toàn có thể xây dựng tổ chức một cách thật sự linh hoạt

Nguồn : THEO SAGA.VN
Trung Phong
Trung Phong

Saga App

Saga App