Đảm bảo hiệu suất cao ổn định với phương pháp chặn trên chặn dưới

Làm một thứ tốt khó, làm một thứ tốt trong thời gian dài càng khó, làm nhiều thứ tốt và trong một thời gian dài cực kì khó.

Việc duy trì hiệu suất cao và ổn định ở góc độ cá nhân thì cần sự kiên trì và kỉ luật, ví dụ như Cristiano Ronaldo năm nay 35 tuổi nhưng chỉ số vẫn cao chót vót vì rất kỉ luật và có chế độ tập luyện, ăn uống cực kì nghiêm khắc suốt mấy chục năm.

Nhưng với một tổ chức từ 15-20 người trở lên, khi mà số module, đầu việc, tính năng mà tổ chức phải làm càng ngày càng nhiều lên thì việc giữ cho toàn bộ hệ thống gồm rất nhiều module này hoạt động ổn định trong khi các module mới được xây dựng đúng kế hoạch là điều cực quan trọng nhưng lại cực kì khó. Yêu cầu có phương pháp, phối hợp và chuẩn bị tốt của nhiều bên.

Nếu bạn tham gia vào quá trình xây dựng phần mềm thì quen với những việc như feature này ở máy dev thì không sao nhưng máy khách hàng thì lỗi, hay nếu bạn là công ty sản xuất thì 10 sản phẩm mẫu đầu không sao nhưng mấy trăm người mua cuối thì lại lỗi, nhầm size...

Tại OCG, trong khoảng 2 năm gần đây số lượng module, dự án, loại dự án (từ xây dựng và bảo trì phần mềm tới sản xuất, thương mại) mà công ty đang duy trì tại mỗi thời điểm là lớn dần lên với nhiều ngành mới hoàn toàn, quy mô nhân sự khá lớn ~150 người. Trong khi đó 100% khách hàng của OCG là khách hàng doanh nghiệp nên việc đảm bảo chất lượng dịch vụ ổn định, an toàn và tin tưởng với khách hàng là điều kiện then chốt quyết định sự sống còn của OCG.

Qua nhiều lần cả tổ chức thử nghiệm và cải tiến, cá nhân mình đã đúc lại ra được phương pháp "chặn trên chặn dưới" để áp dụng vào hầu như tất cả các module tại công ty để đảm bảo chất lượng vận hành sản phẩm luôn ở mức cao.

Các vấn đề khi một tổ chức lớn dần

Khi mà có nhiều người, nhiều teams tham gia vào một module, một mục tiêu nào đó và trong lúc mọi thứ đang diễn ra một cách hỗn loạn, song song thì việc chỉ ra vấn đề của cá nhân hay team nào đó là rất dễ, sẽ thành bới lông tìm vết. Vì vậy việc tập trung tìm các vấn đề cốt lõi (root-cause) để module được cải thiện đúng hướng là rất quan trọng. Cá nhân mình thấy các vấn đề của một module team thường có gốc rễ như sau:

Trong giai đoạn xây dựng một module, sản phẩm mới có rất nhiều thứ mà team chưa biết là mình chưa biết (the unknown unknowns), ví dụ khi bạn tham gia vào một ngành đặc thù mà bạn chưa biết rõ: như việc bạn đang làm nhân viên ngân hàng nhưng lại muốn đi mở quán cà phê chả hạn. (Tips nhanh của phần này mà mình học được từ đứa bạn bên FPT là luôn kiếm một người từ tổ chức cũ để lấy văn hóa và phương pháp làm việc kết hợp với một người giỏi và kinh nghiệm trong lĩnh vực mới để giảm thiểu việc unknown-unknowns)
Lưu lương sử dụng tăng lên làm cho thiết kế module không còn sử dụng được nữa như: số lượng người dùng vào web nhiều hơn cơ sở dữ liệu có thể chịu nổi, số lượng nhân sự tăng quá nhanh so với khả năng quản lý của manager, ...
Trong khi lưu lượng sử dụng làm quá tải module hiện tại thì nhu cầu xây dựng thêm các module mới lại rất cấp thiết. Trường hợp này khá giống với việc khi mà các chính phủ đặt ra mục tiêu tăng trưởng kinh tế trong năm 2020 thì covid-19 xảy ra, hay việc trong khi bạn đang phải fix lỗi của module hiện tại thì bị sếp đưa ra OKR, KPI phải build thêm 2 module mới.

3 vấn đề trên xảy ra đồng thời trong một thời gian dài sẽ dẫn tới giảm năng suất của module team, tinh thần đi xuống, nếu tổ chức có vốn ít thì khả năng dẫn tới hết tiền, thành viên chán làm, nghỉ, nhân viên nhảy việc, mọi cứ xảy ra lặp đi lặp lại như vậy.

Nếu bạn là một startup, nhóm nhỏ thì bạn yên tâm là mình đã gặp rất nhiều team, công ty cực lớn ở Việt Nam họ cũng gặp các vấn đề như vậy, cái khác là họ có đủ vốn, đủ tiền để: (1) chấp nhận lỗ cho tới khi có vòng đầu tư mới và cùng lúc đó (2) tìm cách tối ưu được cách vận hành module của mình cho hiệu quả hơn. Cá nhân mình nghĩ việc (2) tối ưu module là việc sớm muộn sẽ phải làm, nếu quá giỏi hoặc quá mải mê vào (1) tăng vốn sẽ làm cho việc (2) tối ưu module càn ngày càng trở nên khó khăn vì khi đó mức độ phức tạp của module đã rất lớn, số lượng nhân sự đi cùng module cũng lớn nên việc xây mới hoặc thay thế cực kì khó, trong các công ty cực lớn thì số lượng nhân sự kém hiệu quả này tạo nên hệ thống chính trị sẽ là cản trở cực kì nguy hiểm để tối ưu nó.

Dù covid có đang hoành hành, việc kiếm được nhân sự giỏi vẫn là rất khó. Việc các công ty dùng tiền để dành kéo nhân sự của nhau trong một tập nhận sự hữu hạn sẽ chỉ làm cho chi phí của tổ chức tăng lên một cách không an toàn (unhealthy) mà không giải quyết được vấn đề gốc rễ.

Phương pháp "Chặn trên chặn dưới" - Bottom-up, Top-down control

Vì thế mình tin đối với đặc thù mô hình doanh nghiệp Việt Nam thì nên làm chậm mà chắc:

Các module khi được thiết kế và vận hành cần được tính toán, kĩ lương và khoa học.
Việc vận hành và duy trì module cần linh hoạt để dễ dàng thay đổi ngay khi cần.
Không tăng trưởng số lượng nhân sự hay số lượng module quá nhanh khi mà khả năng quản lý chưa tới tầm vì sẽ tạo nên lãng phí và làm việc (2) tối ưu module trở nên cực kì khó khăn sau này.

Đó cũng là các điểm chính của phương pháp "chặn trên chặn dưới".

Chặn dưới - Bottom-up control

Module cần được thiết kế, lập kế hoạch kĩ càng, tính toán nhiều nhất có thể cho các trường hợp có thể xảy ra và nên được review, nhận xét của tập thể đảm bảo tính toàn vẹn, đa chiều. Cần tránh việc "nghĩ ra cái gì là nhảy vào làm luôn" hoặc "cái này cứ để tôi làm rồi tôi sẽ chịu trách nhiệm nếu nó fail".

Thường thì việc thiết kế ban đầu không quá khó vì về cơ bản các bài toán, module hiện nay đều không phải là module mới, chỉ cần google hoặc đi hỏi những người có kinh nghiệm là bạn sẽ có nhiều phương án khá tốt để triển khai. Với những module khó, sự phức tạp lớn thì cần đảm bảo người chịu trách nhiệm thiết kế module (1) có đủ khả năng và (2) được cung cấp đầy đủ tài liệu đào tạo, best practices và (3) có một phương pháp tốt để thiết kế ra module.

Nhưng cái mình thấy mọi người hay làm sai là không chịu viết kế hoạch, document một cách rõ ràng và tường minh ra cho toàn module team để có thể dàng truy cập. Những người chăm làm thì rất ít, lười mô hình hóa module ra, còn những người thích planning, mô hình hóa thì lại không mô hình hóa được một cách đơn giản và tường minh để cho toàn bộ tổ chức có thể dễ dàng hiểu và làm theo.

Tại OCG, khoảng 3 tháng gần đây mình enforce quy trình planning 5 bước theo phương pháp của Ray Dalio với một template planning rõ ràng từ mục tiêu, vấn đề tới design plan để giúp mọi người cùng dùng chung một format trong quá trình đánh giá và triển khai các module design, làm giảm rủi ro module không che đủ trường hợp, khó khăn đặc biệt.

Sau khi áp dụng quy trình 5 bước này cũng giúp cho quản lý nhìn ra điểm yếu của member rõ ràng hơn khá rõ ràng, từ đó giúp cho đội quản lý tại OCG lên được kế hoạch cải thiện tổ chức tốt hơn.

Bên cạnh Google Drive, OCG có một hệ thống wiki nội bộ (gọi là OCG Docs) dùng để lưu các tài liệu quan trọng như Training, Module Info sẽ giúp các Module Design doc dễ được truy cập hơn, giảm thiểu việc quá không tìm được file, gây khó khăn trong quá trình đánh giả thiết kế của module.

Chặn trên - Top-down control

Hiệu năng của module cần được đo đạc thường xuyên, các vấn đề của module cần được phát hiện sớm trước khi nó xảy ra.

Việc đo đạc và phát hiện vấn đề nếu diễn ra tự động, càng yêu cầu ít công sức của module team càng tốt. Tại OCG, các chỉ số của module được push tự động hàng ngày, hàng tuần vào slack qua hệ thống BI dashboards, alert tools. Nếu tổ chức của bạn không có hệ thống công nghệ hoành tránh thì có thể setup các task nhắc nhở và cho một người chuyên đi thu thập các báo cáo này liên tục.

Các chỉ số nên tập trung vào các vấn đề, và tốt nhất thì nên các dấu hiệu của vấn đề để phát hiện ra vấn đề trước khi nó xảy ra, VD: thay vì xem số lượng nhân viên nghỉ việc, thì hãy xem số lượng nhân viên không hài lòng về công việc trong tháng vừa rồi.

Ví dụ khá hay mình được nghe kể là là chủ tịch Vượng (VinGroup) chỉ quan tâm tới số lượng phàn nàn, bad review ở Vinpearl thay vì số lượng khen, ủng hộ. Và mỗi lần gặp phàn nàn là team Vinpearl sẽ phải đi làm giải trình vì sao vấn đề xảy ra.

Ngoài ra, mình khuyến khích tạo ra văn hóa minh bạch và ngang bằng, bất kì ai trong tổ chức cũng có thể xem được các báo cáo, dashboard top-down này và bất kì ai cũng có thể báo cáo vấn đề này lên. Tránh việc quản lý dấu lỗi, che khuyết điểm của đội ngũ và thành viên của mình để module team có thể phát triển bền vững và lâu dài theo Tough Love của Ray Dalio.

Các chú ý cuối

Ngoài các khái niệm chính trên, khi triển khai chặn trên, chặn dưới ở OCG, mình sẽ giao cho 1-2 người để chịu trách nhiệm 2 đầu trên dưới, các chỉ số chặn trên được đưa vào OKR để họp và review hàng tuần. Nếu các chỉ số liên tục có vấn đề thì toàn bộ module team, đặc biệt là người thiết kế module và quản lý của họ cần tự tính toán lại để tìm vấn đề gốc rễ để xử lý.

Việc duy trì và đảm bảo module hoạt động tốt nhiều khi rất mệt mỏi và khó khăn, nhưng nếu làm tốt sẽ làm cho toàn bộ module team có cảm giác đạt được thành tựu, giảm quá tải và áp lực, giúp cho tổ chức lớn mạnh hơn.