Lên kế hoạch và follow-through

Đây là 1 trong những cái mình thấy quan trọng và khó nhằn nhất khi quản lí 1 team nói riêng hay 1 tổ chức nói chung. Lên kế hoạch để làm thì khá dễ hiểu, tuy nhiên lên kế hoạch sao cho hợp lí, tạo ra giá trị và đạt được sự thống nhất thì không đơn giản, đồng thời follow-through (tạm dịch là "làm tới cùng") thường là phần còn khó hơn.

Thông thường, trong những buổi họp sẽ hay có nhiều ý tưởng mới được đưa ra nhằm giải quyết 1 vấn đề gì đó, nhưng cái thường gặp là đến buổi họp lần sau, mọi người chợt nhớ ra là "à, cái bữa trước đó huh, à thì hình như đang triển khai (nhưng tới đâu thì ... chưa rõ)" hoặc là buổi họp lần sau lại ... chuyển qua bàn kế hoạch ý tưởng để giải quyết vấn đề khác mất rồi.

Việc này theo mình có thể cải thiện từ 2 phía:

1. Tactical
Bao gồm những việc cơ bản, ai cũng biết nhưng không phải team nào cũng đủ kỉ luật để theo đuổi lâu dài, bao gồm

Gởi tóm tắt chủ đề cần trao đổi trước cuộc họp. Viết meeting minute sau cuộc họp, ghi rõ những việc cần thực hiện, ai chịu trách nhiệm, thời gian dự kiến hoàn thành
Đảm bảo review lại minute trên trước khi bắt đầu buổi họp sau. Tránh viết meeting minute nhưng rồi gió thoảng mây trôi :)
Đối với những dự án lớn, cần có các buổi kick-off meeting chính thức bao gồm các thành phần liên quan chính để mọi người cùng hiểu và nhận thức sự quan trọng của dự án và kì vọng nào đặt ở từng team, từ đó sẽ có động lực tiếp tục thực hiện

2. Strategy
Team, tổ chức cần nghiêm túc suy nghĩ về việc "làm sao để mọi người nắm được những định hướng chung và vai trò của từng phòng ban là thế nào".

Việc trên sẽ rất rõ ràng đối với cấp lãnh đạo vì chính họ là người nghĩ đến, bàn bạc, thống nhất và hoàn thiện nó. Tuy nhiên đối với team họ, và những team dưới nữa thì không phải lúc nào cũng có cùng thông tin và góc nhìn. Do đó, việc "cascade down" thông tin ra toàn bộ tổ chức thế nào luôn là 1 qui trình cần nghiêm túc thực hiện.

Khi mình làm ở các công ti MNC, họ tổ chức OGSM. Sau này khi đọc về các công ti startup, họ thực hiện OKR. Tên gọi thì mỗi nơi mỗi khác nhưng điểm chung vẫn là, làm sao

lan tỏa những mục tiêu, định hướng của công ti đến mọi phòng ban, mọi nhân viên
đánh giá mức độ thực hiện những mục tiêu định hướng này
có cơ chế điều chỉnh mục tiêu linh hoạt

Những điểm chung trong các qui trình này (nó cũng khá tương đồng với cách tiếp cận làm product)

Mục tiêu cần rõ ràng, đo được và truyền cảm hứng.

Đo được để khi nhìn lại đánh giá, mình có thể nói đơn giản là mục tiêu này đã đạt được hay không, yes/no, không dựa vào cảm tính nào cả.

Để được vậy, việc định ra mục tiêu cần sự đầu tư suy nghĩ, bàn bạc và thậm chí là trả giá (negotiate) giữa các bên (nghĩa là không phải chỉ sếp bảo sao nhân viên đặt mục tiêu vậy). Những việc đó nhằm đảm bảo mục tiêu thống nhất cuối cùng là cái do-able, có thể thực hiện chứ không phải chỉ đặt mục tiêu cho kêu, cho lớn (vì đặt xong làm không được cũng đâu ai bị sao).

Do "đặt ra là để làm" nên 1 tiêu chí cũng quan trong nữa là chất lượng hơn số lượng (less is more), 1 số ít mục tiêu được chọn lựa kĩ càng sẽ có giá trị hơn 1 danh sách dài mục tiêu đề ra cho có. Ngoài ra, việc này sẽ truyền tải thông điệp rằng có 1 số thứ mình sẽ "yes" (quất), 1 số cái mình sẽ "no" (seen).

Đồng thời, mục tiêu còn cần phải có yếu tố "stretch" trong đó, nghĩa là làm sao để các team thực hiện phải rướn, phải vượt qua khả năng của họ để thực hiện được. Đây là yếu tố thu hút người có năng lực, họ thích thử thách, thích vượt qua giới hạn, thích làm những cái mà sếp bảo "cái này có vẻ khó nè anh em".

Ngoài ra, mục tiêu khi được đóng góp xây dựng bởi nhiều bên thì chính những người tham gia sẽ cảm thấy có trách nhiệm hơn trong việc hoàn thành nó (họ thấy có skin in the game, có góp phần vào cuộc chơi). Bởi vì đây là "hoàn tất cái bữa mình lỡ chốt, mà cãi 1 hồi mình thấy cũng có lí" chứ không phải là "phải thực hiện nhiệm vụ nào đó ở trên giao xuống". Họ sẽ thấy mình chủ động hơn.

1 số yếu tố khác cần lưu ý khi đặt mục tiêu

Nên có các mục tiêu "kiểm tra chéo" nhau, ví dụ nếu có mục tiêu về số lượng (viết thêm tính năng mới trong thời gian ngắn) thì cần đi kèm mục tiêu đảm bảo chất lượng (tính năng không có quá bao nhiêu bug)
Các mục tiêu nên ghi rõ những phòng ban/team liên quan sẽ cần tham gia hỗ trợ và có trao đổi trước để đạt được buy-in từ những phòng ban/team này (tránh tới khi tổng kết mới phát hiện ra là bị chậm không phải do mình mà do cần đợi những bên liên quan, và bên đó với họ dự án này chưa phải ưu tiên cao).
Chọn mục tiêu có ảnh hưởng cao, có tính chiến lược (do the right things) và có khoảng thời gian thực hiện từ 3 tháng, 6 tháng hoặc 1 năm (ngắn hơn thì sẽ thành tactical, dài hơn thì khó lên kế hoạch chính xác). Đây thường là vai trò của người leader (họ sẽ chọn việc đúng để làm và xây dựng, tạo môi trường để team làm việc ấy 1 cách đúng đắn)
Cần có sự ủng hộ top-down về chuyện "nếu đã thống nhất thì cần rất hạn chế việc mục tiêu, kế hoạch mới chen ngang", cho dù đó là từ cấp lãnh đạo đi nữa. Nếu không, mọi người sẽ cảm thấy không serious trong việc lên kế hoạch vì "lên chi, lâu lâu sếp buồn buồn nghĩ ra cái mới lại cũng chen hàng vô kêu làm thôi" :)

2. Mục tiêu cần được lan tỏa

Mục tiêu cần được công khai, đặc biệt từ cấp quản lí. Đây là cách thể hiện sự cam kết (commitment) của họ và lan tỏa tinh thần này đến mọi team.
Việc lan tỏa (cascade down) cần được thực hiện thường xuyên và định kỳ, top-down ví dụ trong các buổi họp team. Khi những thành viên trong team thấy manager của họ nghiêm túc thực hiện việc xác định mục tiêu và các team khác cũng vậy, từ từ họ sẽ bị thuyết phục
Cần chấp nhận việc triển khai qui trình mới sẽ cần thời gian, không thể thấy hiệu quả ngay. Và cần làm sao để mọi người hiểu và chủ động làm theo nó (enthusiastic compliance) chứ không chỉ làm theo vì bị yêu cầu (bereaucratic compliance). Ngoài ra, có thể triển khai qui trình này ở từng team nhỏ trước khi áp dụng rộng rãi toàn công ty, không nhất thiết khi vừa triển khai là mọi người đều sử dụng ngay.

3. Mục tiêu cần được đánh giá và điều chỉnh.

Cho dù mục tiêu khi được thống nhất ban đầu có kĩ lưỡng và chăm chút tới mức nào thì vẫn sẽ có những tình huống phát sinh dẫn đến cần đánh giá và điều chỉnh. Việc này cần được coi là bình thường, là 1 phần của qui trình chứ không phải có điều chỉnh thay đổi nghĩa là "plan dở", là "execute dở"

Việc đánh giá cần có tính định kỳ (tránh chỉ gặp nhau review khi kết quả tốt và qua loa khi trao đổi về kết quả chưa tốt)

Ngoài ra, các team nên biết tình hình thực hiện công việc của nhau, để xem có gì hỗ trợ được không và cũng giúp có context về công việc của team mình rõ ràng hơn.

Cuối cùng, người leader cần đảm bảo các thành viên cảm thấy thoải mái khi chia sẻ ý kiến, đặc biệt là việc cảnh báo risk (mục tiêu có thể không đạt được) cần được đề cao và khuyến khích.

Các cách đánh giá mục tiêu

Report gởi định kì
Dashboard giúp những số liệu quan trọng được tiếp cận dễ dàng bởi những người cần biết nó
Các công cụ chia sẻ kế hoạch, mục tiêu, tiến độ thực hiện của team cho toàn công ty có thể xem
Meeting định kì

Có 1 số tổ chức mình biết cũng muốn áp dụng ví dụ OKR nhưng thất bại. Theo mình là vì họ chưa hiểu cái "essentials" trong đó và chưa critical để đặt câu hỏi vì sao việc triển khai chưa hiệu quả.

Nghệ thuật không phải ở chỗ nó "từ Google nên nó phải xịn", nghệ thuật không phải ở cái tên nghe hay hay dễ nhớ, nghệ thuật không phải OKR được quản lí bằng Excel hay bằng hệ thống, nghệ thuật là nhận ra những cái là commensense (ai cũng thấy đúng) nhưng không ai đủ kỉ luật để triển khai tới cùng (và khi thấy nó fail, mình nghĩ nó không đúng và lại đi tìm 1 qui trình OKR phẩy khác).

Ngoài ra, mình còn cần thấy OKR/OGSM/etc có thể hiệu quả ở 1 công ti, không phải vì chỉ vì chính qui trình đó, mà còn vì những yếu tố khác, ví dụ

Văn hóa bình đẳng tranh luận: mọi người có thể tự tin chia sẻ thoải mái ý kiến của mình với manager hay không, cái này ảnh hưởng lớn đến chất lượng của mục tiêu được thống nhất và liên quan việc mình có phát hiện ra những bất cập khi triển khai sớm hay không
Văn hóa chia sẻ thông tin (transparency): đây là yếu tố giúp các mục tiêu, kết quả của các team được chia sẻ với nhau, bao gồm cả những điểm thực hiện chưa tốt.

Vậy, ở công ti hoặc team của bạn, những yếu tố phụ trợ đó đã có hay chưa ?

Sau khi nhận ra những điều đó, cái khó nhất mà bài viết này không thể làm giùm bạn (và ngay cả người viết này cũng bị), đó là cần bắt đầu kỉ luật hơn trong việc triển khai và cải tiến nó, kỉ luật với bản thân mình, kỉ luật với team, kỉ luật triển khai từ chính những người quản lí.

Idea is cheap, execution (& follow-through) is key.