Categories
News

Chiến Lược Xây Dựng High-Performance Team Vận Dụng Tinh Thần Agile – Phần 2

Khởi nguồn là một phương pháp tiếp cận được sử dụng trong các dự án phát triển phần mềm, Agile trong những năm gần đây đã vượt ra khỏi địa hạt này và ảnh hưởng đến nhiều lĩnh vực non-tech khác như quản lý nhân sự, marketing, quản trị và lãnh đạo. 

Câu hỏi mà chúng tôi thường xuyên nhận được từ khách hàng và đối tác của Enable Startup là: Agile có thực sự lý tưởng, “toàn năng” như cách mà người người nhà nhà đang nói về nó? Về cơ bản, câu trả lời của tôi là “Có”, bởi Agile từ góc nhìn của cá nhân tôi là một tinh thần, hơn là một bộ quy tắc, và tinh thần đó đa phần là có lợi. Vấn đề đáng nói ở đây là áp dụng Agile như thế nào trong thực tế, có những best practices nào đã được rút ra từ các dự án đi trước và cần cân nhắc những gì trong từng trường hợp cụ thể.  

Ở bài viết này, tôi sẽ trình bày một số điểm then chốt về Agile cũng như những nguyên tắc áp dụng Agile nhằm tăng hiệu quả làm việc và tính ổn định, sức bền của team (high-performance teams). Đây là những gì được đúc rút từ kinh nghiệm hơn 11 năm làm việc trong ngành phần mềm của cá nhân tôi và hiện tại đang được áp dụng trong hầu hết các dự án tại Enable Startup.

Bài viết được chia thành 2 phần:

Phần 1: Hiểu về Agile, High-performance team và các khái niệm liên quan

Phần 2: Quy trình và cách thức xây dựng high-performance team tại Enable Startup

Điều đầu tiên cần lưu ý: không có một công thức chung đúng cho mọi công ty trong việc xây dựng high-performance team. Tùy vào đặc điểm về nguồn lực cũng như văn hóa mà mỗi doanh nghiệp tự xác định cho mình những “nguyên liệu” và rút ra những best practices riêng.

Tầm quan trọng của yếu tố văn hóa

Ở đây tôi đặc biệt muốn nhấn mạnh hai chữ “văn hóa”, bởi như có thể thấy, Agile nói chung và 6 tiêu chí của high-performance scrum team nói riêng đều đặc biệt đề cao yếu tố con người, theo nghĩa từng cá nhân cũng như tương tác giữa các cá nhân với nhau. Do đó, văn hóa có thể nói là xuất phát điểm, kim chỉ nam cho mọi chiến lược lập nhóm.

Văn hóa về cơ bản bao gồm văn hóa dân tộc, văn hóa vùng miền, văn hóa doanh nghiệp. Chẳng hạn, cùng mục tiêu đảm bảo tính tôn trọng (Respect) trong team, một công ty chịu ảnh hưởng của văn hóa Á Đông có thể sẽ phải cân nhắc đến tuổi tác, số năm kinh nghiệm của các thành viên nhiều hơn so với một công ty ở Mỹ. Hay ở phạm trù văn hóa doanh nghiệp, một công ty hướng ngoại chắc hẳn sẽ có những phương thức khác với một công ty hướng nội trong việc duy trì khả năng tập trung (Focus), tần suất họp team và các kênh feedback nội bộ nhằm đảm bảo tính cởi mở (Openness) giữa các thành viên.

Nói tóm lại, việc đánh giá lại những yếu tố văn hóa chi phối đến dự án ngay từ đầu sẽ giúp bạn xác định được một số giới hạn, lường trước được đâu là những điểm có thể tùy cơ ứng biến và đâu là những quy chuẩn không nên phá vỡ, cùng với đó là có những ý tưởng, hình dung ban đầu về chiến lược lập nhóm.

Các tiêu chí và hoạt động cụ thể

Sau khi đã “lấy đà” từ việc đánh giá lại văn hóa và nguồn lực, bước tiếp theo là bắt tay vào thiết kế team. Dưới đây là những câu hỏi mà tôi cho là quan trọng nhất, cùng với đó là các phương pháp cụ thể mà Enable Startup sử dụng để trả lời chúng.

Câu hỏiGiải pháp
1. Team nên gồm bao nhiêu thành viên?Team size từ 3-7 thành viên (không tính Scrum Master và Product Owner)
2. Làm sao để lựa chọn thành viên cho team?Hai tiêu chí cần cân nhắc: Tính đa dạng (Diversity) và khả năng bổ trợ lẫn nhau (Complementarity)
3. Giao tiếp trong team nên diễn ra như thế nào?Meetings & Feedback Loop
4. Trong trường hợp cần bổ sung nhân lực, nên áp dụng chiến lược tuyển dụng nào?Peer Recruitment
5. Những hoạt động nào là cần thiết để nuôi dưỡng nguồn lực cho team?– Xây dựng lộ trình phát triển cá nhân (Career Progression)
– Thực hành song song hai loại hình team: chuyên môn hóa (functional) và đa chức năng (cross-functional)
Bảng 1. Xây dựng team – các câu hỏi cần đặt ra và giải pháp cụ thể

Mô hình 5 giai đoạn phát triển nhóm của Tuckman

Trước khi đi vào phân tích chi tiết từng giải pháp, tôi muốn giới thiệu ngắn gọn về mô hình 5 giai đoạn phát triển nhóm của Tuckman (The five-step Tuckman stages of group development) – một khung lý thuyết mà cá nhân tôi rất tâm đắc và áp dụng sâu sát trong quá trình vận hành Enable Startup. 

Giai đoạn 1 – Forming. Tại bước đầu tiên này, team cần xác định rõ tầm nhìn và mục tiêu chiến lược. Từ đó cần thống nhất các quy tắc, quy trình cần thiết trước khi team bắt đầu vận hành. Một điều rất quan trọng là các mục tiêu cần có khung đo lường cụ thể và minh bạch, đủ để tất cả thành viên nắm được và cùng tham gia giám sát trong suốt chiều dài dự án. 

Giai đoạn 2 – Storming. Tại thời điểm này, áp lực và những khác biệt về quan điểm có thể bắt đầu xuất hiện. Đây là giai đoạn mà các nguyên tắc trong giao tiếp và tranh luận nên được tạo ra để cả team dễ dàng đạt được đồng thuận, từ đó thúc đẩy hiệu suất cá nhân và gián tiếp tạo ra hiệu suất chung của team. 

Giai đoạn 3 – Norming. Bước sang giai đoạn này các thành viên bắt đầu làm việc nhịp nhàng và hiểu nhau hơn. Trong nội bộ team cũng sẽ bắt đầu xuất hiện những nguyên tắc ngầm định để giúp công việc trở nên hiệu quả hơn. Ở thời điểm này các chỉ số về hiệu quả (Performance Metrics và Delivery Metrics) nên được hiệu chỉnh sao cho phù hợp và ổn định, cả team bắt đầu có khả năng dự đoán về tiến độ cũng như có những sáng kiến để nâng cao tính sáng tạo, cải thiện hiệu năng sản phẩm. 

Giai đoạn 4 – Performing. Một khi đã xây dựng được sự gắn kết và đồng cảm, nhóm bắt đầu hoạt động hiệu quả như một thể thống nhất, đủ sức đảm nhận các nhiệm vụ quan trọng hơn và đạt được mục tiêu dễ dàng hơn.

Giai đoạn 5 – Adjourning. Sau một khoảng thời gian nhất định, nhóm sẽ nhìn lại hiệu suất của mình, rà soát lại những điểm được và chưa được. Ở giai đoạn này, mỗi thành viên trong team cần nhận được sự ghi nhận xứng đáng và có thể được trao nhiều nhiệm vụ quan trọng hơn.

Việc nắm rõ được vòng đời nói trên giúp chúng tôi nhận ra rằng, muốn phát triển team nhanh nhất thì nguyên tắc là phải làm sao để tăng tốc cho từng giai đoạn

Từ đó, các giải pháp cụ thể như ở Bảng 1. được đề ra. Dưới đây chúng ta sẽ cùng đi sâu vào chi tiết.

Quy mô nhóm (Team size)

Số lượng thành viên trong team không chỉ đơn giản là một con số. Việc thêm hay bớt một thành viên sẽ dẫn đến những sự thay đổi quan trọng sau đây:

  • Số lượng mối quan hệ trong team như được minh họa bởi công thức dưới đây
  • Thời gian mỗi thành viên phải dành ra trong ngày để quản lý các mối quan hệ này (lưu ý: một phần trong quỹ thời gian đó dành cho các nội dung ngoài lề công việc)

Các rủi ro liên quan đến mức độ hài lòng trong từng mối quan hệ.

Con số được đề xuất trong Scrum Guide là 3-9 thành viên, không tính Scrum Master và Product Owner. Tuy vậy từ 3 đến 9 là một khoảng cách đáng kể, nhất là nếu như quy ra thành số lượng mối quan hệ cần quản lý (3 vs. 36 theo như cách tính ở trên).
Từ các kinh nghiệm thực tế cũng như đối chiếu với các nghiên cứu trong Scrum Team Size, con số mà chúng tôi thường áp dụng cho các dự án tại Enable Startup là 3-6 thành viên mỗi team, không tính Scrum Master và Product Owner. Trong trường hợp dự án yêu cầu nhiều hơn 7 thành viên, phương án sẽ là chia thành 2 team nhỏ. Quy mô nhóm như vậy cho thấy hiệu quả tối ưu cho các dự án phát triển MVP kéo dài từ 3-12 tháng.

Tính đa dạng và khả năng bổ trợ của các thành viên (Diversity & Complementarity)

Agile nói chung và Scrum nói riêng nhấn mạnh tính linh hoạt và những cơ chế trao đổi, sửa sai giữa các thành viên để giúp dự án liên tục được tối ưu, bởi vậy tính đa dạng là một tiêu chí không thể thiếu.

Tính đa dạng trong một high-performance team không chỉ bao gồm phương diện tuổi nghề, kiến thức, kỹ năng chuyên môn mà còn cả về tính cách, góc nhìn hay kể cả giới tính. 

Câu hỏi đặt ra là đa dạng đến đâu thì đủ và như thế nào sẽ là thừa, hay nói cách khác phản tác dụng?

Một lần nữa, không có câu trả lời nào là chuẩn cho mọi trường hợp. Tuy vậy, một nguyên tắc tối quan trọng là không nên “cố đấm ăn xôi” để đảm bảo tiêu chí đa dạng, mà vô tình làm tổn thương các tiêu chí khác cũng quan trọng không kém như cơ hội công bằng cho mọi người hay tính minh bạch. 

Họp nhóm (Meetings)

Mục đích của meetings là nhằm đảm bảo các thành viên đều nắm được tình hình công việc và nhiệm vụ kế tiếp. Mô hình Scrum đã đề xuất một hệ thống phân loại meetings khá toàn diện và “đo ni đóng giày” cho các dự án phát triển phần mềm, bao gồm Daily Standup Meeting, Sprint Planning Meeting, Sprint Review Meeting, Retrospective Meeting, Product Backlog Refinement Meetings.

Dựa trên mô hình này, bạn có thể điều chỉnh cho phù hợp với dự án cụ thể, tuy nhiên cần đảm bảo các yếu tố then chốt như tính đều đặn, được lên kế hoạch một cách khoa học và có những bài học rút ra vào cuối mỗi meeting. 

Về nội dung thảo luận trong meeting, ngoài các vấn đề chuyên môn, các yếu tố tác động đến cảm xúc như áp lực công việc, bất đồng ý kiến, sai sót về cách thực hiện, kết quả không như ý cũng cần được đặc biệt lưu ý. Scrum Master, ngoài vai trò duy trì việc thực hành các tiêu chuẩn Scrum cũng như các Scrum best practices, còn là người có trách nhiệm quan sát và tạo điều kiện nhằm đảm bảo mỗi thành viên luôn có một sức khỏe tinh thần tốt nhất, từ đó đáp ứng hiệu suất chung của dự án.

Liên tục phản hồi (Feedback Loop)

Feedback giúp các thành viên hiểu nhau hơn, thúc đẩy sự ghi nhận cũng như kịp thời phát hiện các điểm còn thiếu sót. Hoạt động này nên được thực hiện thường xuyên thông qua các buổi họp, trong đó mỗi cá nhân được dành riêng một thời lượng để nêu lên tiếng nói của mình và các thành viên còn lại được yêu cầu lắng nghe, đưa ra ý kiến cũng như phản biện nếu có. Feedback không chỉ nói ra rồi để đấy, mà cần được rút lại thành các bài học cụ thể (lessons learned).

Tuyển dụng đồng cấp (Peer Recruitment)

Trong trường hợp cần bổ sung thành viên cho team, peer recruitment, tạm dịch là tuyển dụng đồng cấp, là phương pháp mà chúng tôi khuyên dùng. Lý do đơn giản là vì không ai có thể hiểu về những gì team cần hơn là chính các thành viên trong team.

Điều này có thể không đúng với các mô hình tổ chức team truyền thống, nơi mà mỗi thành viên chỉ tập trung vào một góc nhỏ của dự án. Tuy nhiên, một khi đã đi theo Agile, mỗi thành viên đã được mặc định phải hiểu về dự án tương đối toàn diện. Bởi vậy peer recruitment áp dụng ở đây trở nên đặc biệt đúng chỗ.

******************

Nếu như các nguyên tắc kể trên được áp dụng trong khuôn khổ từng nhóm dự án, thì một câu hỏi quan trọng không kém là những hoạt động nào là cần thiết trong một công ty nhằm nuôi dưỡng nguồn lực bền vững, sẵn sàng cấu thành nên các nhóm dự án này? Tại Enable Startup, có hai giải pháp chính để giải quyết vấn đề: 1. Ở mức độ cá nhân , chúng tôi xây dựng, theo dõi lộ trình phát triển bài bản cho từng thành viên; 2. Ở góc độ tập thể, chúng tôi vận hành song song hai loại hình tổ chức team: chuyên môn hóa (functional) và đa chức năng (cross-functional).

Xây dựng và theo dõi lộ trình phát triển cho từng thành viên (Career Progression)

Đây là một điểm cực kỳ quan trọng nhưng lại thường xuyên bị coi nhẹ.

Thật vậy, một tổ chức muốn đạt được hiệu quả cao không thể bỏ qua trải nghiệm của từng cá nhân tạo nên nó. Bên cạnh việc nhắc đi nhắc lại về mục tiêu cần đạt được cho khách hàng và công ty, mỗi thành viên cũng cần được nhìn nhận những gì đã đóng góp, phân tích đánh giá chất lượng làm việc cũng như định hướng các nấc thang phát triển của họ trong tương lai.

Việc xây dựng một framework về Career Progression bởi vậy là tối quan trọng để giúp các cá nhân có lộ trình phát triển phù hợp, từ đó có động lực mạnh mẽ hơn và đóng góp nhiều giá trị cho tổ chức. Không ít người nghĩ rằng career progression chỉ cần thiết cho các công ty lớn. Cá nhân tôi tin rằng quan điểm này hoàn toàn sai lầm. Việc trực tiếp quan sát và hỗ trợ lộ trình phát triển của từng nhân viên thực sự là một trong những trải nghiệm tuyệt vời và ý nghĩa nhất mà tôi có được ở vị trí điều hành một công ty nhỏ.

Vận hành song song hai loại hình tổ chức team: chuyên môn hóa (functional) và đa chức năng (cross-functional)

Functional Team

Functional team có thể hiểu tương đương như một đơn vị kinh doanh chiến lược (business unit), chuyên sâu về một lĩnh vực nhất định, có chức năng tuyển dụng, nghiên cứu, đào tạo, đánh giá nhân lực trong khuôn khổ chuyên môn đó. Tại Enable Startup, chúng tôi có những functional team như Account Management, Marketing, UX-UI, Web & Mobile Apps Development, Data Science và IoT. Mục tiêu của các team này là nhằm tuyển chọn, nuôi dưỡng những cá nhân có đủ trình độ để sẵn sàng tham gia các cross-functional team.

Cross-functional Team

Đây là loại hình tổ chức nhóm ngắn hạn được thành lập khi có dự án mới, product mới, và đi từ đầu đến khi kết thúc dự án hoặc sản phẩm.

Như vậy functional teams là được xem như một talent pool nhằm chuẩn bị “nguyên liệu” cho cross-functional teams, hạn chế tối đa việc tuyển dụng một cách bị động, dẫn đến nhiều rủi ro như thiếu hiểu biết văn hoá công ty, trình độ chuyên môn không đủ đáp ứng, phong cách làm việc không phù hợp.

Việc song hành 2 loại hình tổ chức nhóm này cực kỳ phù hợp để một mặt, đáp ứng các nhiệm vụ chiến lược, dài hạn về phát triển nguồn nhân lực; mặt khác đảm bảo khả năng luân chuyển nội bộ linh hoạt nhằm phục vụ cho các dự án ngắn hạn hoặc mục tiêu trong từng giai đoạn nhất định của tổ chức.

Lời kết

Tư duy Agile là một hướng tiếp cận tốt nhằm xây dựng high-performance team. Tuy vậy thực thi nó bằng cách nào lại đòi hỏi mỗi tổ chức hiểu sâu sắc về điều kiện nội tại của team cũng như các yếu tố khách quan của từng dự án.

Việc nghiên cứu và đúc rút thành một bộ quy tắc, quy trình, tiêu chí chặt chẽ cho việc xây dựng high-performance team dành riêng cho từng doanh nghiệp là điều cực kỳ quan trọng. Nên nhớ, bạn không cần đợi công ty của mình lớn bằng bất kỳ công ty XYZ nào mới bắt tay vào công việc này. Ngược lại, bạn làm nó càng sớm công ty của bạn lớn càng nhanh.

Rất hy vọng những kinh nghiệm trên đây của Enable Startup sẽ giúp ích cho những doanh nghiệp vừa và nhỏ đang nỗ lực xây dựng các high-performance team. Chúng tôi cũng háo hức nhận được những ý kiến phản biện hoặc chia sẻ về quan điểm, trải nghiệm của bạn ngay dưới phần bình luận hoặc qua hòm mail [email protected]!

    Categories
    News

    Chiến Lược Xây Dựng High-Performance Team Vận Dụng Tinh Thần Agile – Phần 1

    Source: unsplash.com

    Khởi nguồn là một phương pháp tiếp cận được sử dụng trong các dự án phát triển phần mềm, Agile trong những năm gần đây đã vượt ra khỏi địa hạt này và ảnh hưởng đến nhiều lĩnh vực non-tech khác như quản lý nhân sự, marketing, quản trị và lãnh đạo. 

    Câu hỏi mà chúng tôi thường xuyên nhận được từ khách hàng và đối tác của Enable Startup là: Agile có thực sự lý tưởng, “toàn năng” như cách mà người người nhà nhà đang nói về nó? Về cơ bản, câu trả lời của tôi là “Có”, bởi Agile từ góc nhìn của cá nhân tôi là một tinh thần, hơn là một bộ quy tắc, và tinh thần đó đa phần là có lợi. Vấn đề đáng nói ở đây là áp dụng Agile như thế nào trong thực tế, có những best practices nào đã được rút ra từ các dự án đi trước và cần cân nhắc những gì trong từng trường hợp cụ thể.  

    Ở bài viết này, tôi sẽ trình bày một số điểm then chốt về Agile cũng như những nguyên tắc áp dụng Agile nhằm tăng hiệu quả làm việc và tính ổn định, sức bền của team (high-performance teams). Đây là những gì được đúc rút từ kinh nghiệm hơn 11 năm làm việc trong ngành phần mềm của cá nhân tôi và hiện tại đang được áp dụng trong hầu hết các dự án tại Enable Startup.

    Phần 1: Hiểu về Agile, High-performance team và các khái niệm liên quan

    Trước khi đi sâu vào cách thức, điều đầu tiên cần làm rõ là phân biệt Agile, high-performance team và các khái niệm liên quan như Scrum, Lean Startup. Chúng là gì, khác nhau ở đâu và liên hệ với nhau như thế nào?

    Agile

    Cùng bắt đầu với Agile. Nói nôm na, Agile là một tinh thần, một triết lý trong quản lý dự án.

    Triết lý Agile nhấn mạnh tính linh động, tối giản hóa các quy trình, hệ thống cấp bậc và đề cao tương tác cũng như khả năng giải quyết vấn đề của mỗi cá nhân, nhờ đó đẩy nhanh năng suất, hiệu quả công việc, phản ứng nhanh với biến động, hạn chế lãng phí nguồn lực và tạo ra nhiều giá trị gia tăng cho dự án.  

    Trong ngành phần mềm, trước khi Agile ra đời thì cái tên thống trị là “waterfall” – mô hình thác nước, hoặc quản lý dự án theo kế hoạch – “plan-driven”. Các trường phái truyền thống này được đặc trưng bởi cách triển khai dự án theo tuần tự tuyến tính, đầu ra của giai đoạn này là đầu vào của giai đoạn tiếp theo, không có sự chồng chéo. Tuy nghe qua có vẻ chặt chẽ, các cách tiếp cận này lại bộc lộ nhiều bất cập khi áp dụng vào thực tế. (add stats) Lý do chính là vì yêu cầu của khách hàng thường thay đổi liên tục, khả năng tiên liệu của team cũng ít khi được chính xác như trên lý thuyết, dẫn đến một thực tế là lên kế hoạch càng dài và càng tham vọng thì càng dễ vỡ, kết quả là lãng phí nguồn lực. Bởi vậy mà Agile ra đời. Ngược lại với waterfall hay plan-driven, đặc trưng của Agile là dự án được chia thành các vòng lặp nhỏ với các mục tiêu ngắn và khả thi, song song với đó là quá trình phản hồi và tối ưu diễn ra liên tục.

    Tinh thần Agile được truyền tải khá trọn vẹn thông qua “Tuyên ngôn Agile” (“Agile Manifesto” – một bộ quy tắc nhận được sự đồng thuận rộng rãi của nhiều chuyên gia trong ngành phần mềm), trong đó có thể tóm gọn bởi 4 gạch đầu dòng sau đây:

    • Chú trọng vào từng cá nhân và từng tương tác hơn là các quy trình và công cụ
    • Tài liệu mô tả có thể không hoàn hảo, miễn là phần mềm chạy tốt
    • Khách hàng là để cộng tác cùng phát triển, không phải chỉ để thảo luận về hợp đồng
    • Tùy theo hoàn cảnh mà linh hoạt thích ứng, thay vì bám theo kế hoạch một cách cứng nhắc.

    Scrum

    Như vậy, khi nói đến Agile, ta đang mới chỉ dừng ở một lối tư duy, một triết lý khá chung chung. Để thực hành triết lý này, cần có một số phương pháp, quy trình thực thi cụ thể. Scrum chính là một trong số đó, bên cạnh những cái tên khác như KanBan, Extreme Programming (XP), ScrumBan, Crystal hay Lean Startup.
    Sở dĩ tôi nhấn mạnh Scrum là bởi đây là phương pháp được áp dụng phổ biến nhất tại Enable Startup, cũng đồng thời chiếm đến 58% “thị phần” trong số các phương pháp Agile được áp dụng hiện tại trên thế giới, theo khảo sát của VersionOne năm 2020.

    High-performance Team

    Ok, tới đây chúng ta đã hiểu cơ bản về Agile và Scrum. Vậy high-performance team (tạm dịch là đội hiệu suất cao) nằm ở đâu trong các mô hình này? Câu trả lời là ở đầu ra.

    High-performance team chính là sản phẩm trực tiếp của các phương pháp tổ chức, quản lý dự án nêu trên, từ đó góp phần phục vụ mục tiêu tối thượng là tối ưu hóa năng suất, sức bền, hiệu quả làm việc và cuối cùng, tạo ra nhiều giá trị.

    Để có được “high performance” trong một dự án vận hành theo nguyên lý Agile, hay cụ thể hơn là Scrum, mỗi thành viên trong team cần một sự gắn kết sâu sắc với tổng thể dự án và toàn tâm toàn ý hướng đến mục tiêu chung. Chính động lực và tầm nhìn này là chất kết dính thúc đẩy cả team tiến về phía trước. Để có được điều này, mỗi thành viên cần hội tụ các phẩm chất nêu trong mô hình dưới đây:

    Câu hỏi đặt ra là: Làm sao để đạt được các phẩm chất có phần hơi định tính nêu trên? Ở phần tiếp theo, tôi sẽ trình bày cách mà những mục tiêu này được cụ thể hóa bằng các quy trình và tiêu chí có-thể-đo-lường.

    Phần 2: Quy trình và cách thức xây dựng high-performance team tại Enable Startup

    Nội dung chính:

    • Tầm quan trọng của yếu tố văn hóa
    • Các tiêu chí và hoạt động cụ thể