Công thức đổi mới sáng tạo tại Amazon: Các nhóm nhỏ tinh gọn – Phần 4

317

Trong các phần trước, chúng ta đã tìm hiểu về văn hóa dám chấp nhận thất bại, cơ chế đổi mới thông qua các kĩ thuật tìm hiểu khách hàngmột phần cơ cấu tổ chức. Bài viết này sẽ tập trung vào cơ cấu tổ chức tại Amazon, xoay quanh nhóm nhỏ “2 chiếc Pizza” vốn đóng góp một phần không nhỏ vào công thức đổi mới sáng tạo.

Lợi ích từ nhóm nhỏ “2 chiếc Pizza”

Có một điều nghịch lý tại Amazon là việc giao tiếp giữa các nhóm lại… không được Jeff Bezos khuyến khích. Trong một cuộc trao đổi về làm thế nào để làm cho các nhóm giao tiếp với nhau nhiều hơn, Bezos đã đứng dậy và nói rằng: “Không, việc giao tiếp giữa các nhóm là một điều thật tệ hại”.  Như vậy, suy nghĩ theo nhóm lớn sẽ nhường chỗ cho các ý tưởng độc lập. Tại sao vậy? Đó là vì Bezos thích ý tưởng về một công ty phân tán, trong đó các nhóm nhỏ (với số lượng nhân sự càng nhỏ càng tốt) có thể thỏa sức sáng tạo, thử nghiệm và kiểm chứng tầm nhìn, giả thuyết tăng trưởng và giá trị của mình.

Một nguyên tắc quan trọng của triết lý này đó là quy tắc nổi tiếng hai chiếc bánh Pizza. Quy tắc này không liên quan tới… bữa tiệc nào tại Amazon cả mà đơn thuần là cách sắp xếp số lượng người trong một nhóm sao cho vừa đủ để thưởng thức hai chiếc bánh Pizza mà thôi. Bezos tin rằng công ty không thể hoạt động hiệu quả, cho dù lớn tới cỡ nào nếu như một nhóm có quá số người ăn được hai chiếc bánh Pizza nói trên.

Suy nghĩ này của Bezos có cơ sở khi một nhóm sẽ có hiệu suất giảm dần khi thêm người (quy luật hiệu suất giảm dần trong kinh tế học). Ngoài ra, nhiều nghiên cứu cũng chứng minh lập luận này. Giáo sư J. Richard Hackman cũng đã chỉ ra rằng: “Một nhóm càng lớn thì càng phát sinh nhiều vấn đề gặp phải trong quy trình thực hiện công việc. Chính việc phải quản lý những mối liên hệ giữa các thành viên khiến cho nhóm gặp rắc rối.” Một nhà nghiên cứu khác, Fred Brooks thì cho rằng: “Thêm nhân lực vào một dự án chậm tiến độ chỉ càng làm cho nó chậm tiến độ hơn mà thôi.”

Mối liên hệ giữa các thành viên tăng dần và khó kiểm soát.

Hiện có hàng trăm nhóm nhỏ như vậy tại Amazon (Thường thì cho một nhóm có từ sáu đến mười người). Việc phân thành các nhóm nhỏ giúp Amazon vận hành linh hoạt và tinh gọn. Trên hết, các nhóm này hoạt động tương đối độc lập, xoay quanh một dịch vụ, năng lực thay vì theo các dự án. (Đó có thể là phần thanh toán, hoặc quy trình xử lý đơn hàng). Tinh thần khởi nghiệp, tinh thần sáng lập cũng được nâng cao khi trưởng nhóm và tập thể nhóm chịu trách nhiệm toàn diện với sản phẩm/tính năng tạo ra.

Các nhóm được tự chủ và đặt niềm tin và trao quyền trong quá trình ra quyết định, xác định kế hoạch về mặt sản phẩm, thị trường, vận hành (và tất nhiên là có các chỉ số đo lường đi kèm, thảo luận thêm ở phần API), giúp liên tục cải tiến, tạo sự minh bạch và đưa ra cam kết cao hơn đối với kết quả về dài hạn. Tất nhiên, không phải tất cả các nhóm đều có dạng hai chiếc pizza tại Amazon nhưng những nhóm như vậy là hạt nhân lan tỏa tinh thần đổi mới sáng tạo nơi đây.

Cơ chế giao tiếp thông qua API giữa các “Nhóm 2 chiếc Pizza”

Vào năm 2002, Jeff Bezos đã ra một “Sắc lệnh API”- Application Programming Interface – giao diện lập trình ứng dụng) (Tham khảo bảng 1). Nhìn vào sắc lệnh này, ta thấy mọi nhóm tại Amazon đều phải tương tác với nhau dựa trên API. Việc này thể hiện Jeff Bezos thay vì bảo các nhóm “2 chiếc Pizza” sở hữu dữ liệu của riêng mình và không một nhóm nào có thể tiếp cận và thay đổi dữ liệu ngoài trừ kết nối thông qua API. Nếu bạn ở phòng nhân sự và cần số liệu từ phòng marketing, bạn cần phải lấy chúng thông qua API. Mọi nhóm phải xác định nguồn lực mình có để kết nối API và đều trở thành đối tác của nhau.

Cụ thể hơn, mỗi một sản phẩm ở Amazon đều phải có API (giống hệt như khi phát triển sản phẩm cho một khách hàng ở ngoài). Các đội dự án có thể hoạt động mà không phụ thuộc vào tốc độ làm việc của nhau cũng như bàn giao công việc cho nhau dễ dàng hơn, nhanh hơn. Ngoài ra, các nhóm có thể vận hành nhanh, tinh gọn, tự động hóa, tạo nền tảng cho việc đổi mới sáng tạo tại Amazon. Mức độ hiệu quả của nhóm nhỏ được đo bằng một hàm gồm các chỉ số đo lường dài hạn, đo độ ảnh hưởng, tác động (Amazon gọi tập hợp các chỉ số đo lường này là hàm sức khỏe – Fitness Function).

Cơ chế API thể hiện tầm nhìn của Bezos về một công ty phân quyền, tại đó quyết định được phân tán thay vì tập trung và dồn vào một chỗ. Tại đây, các nhóm nhỏ có thể độc lập sáng tạo và hoạt động mà không bị các nhóm hay cá nhân khác chi phối.

Bảng 1. Sắc lệnh API của Bezos

Vào quãng thời gian năm 2002, Jeff Bezos đã ra một “sắc lệnh”:

  • Mọi nhóm sẽ mở dữ liệu và các tính năng thông qua giao diện cung cấp dịch vụ.
  • Các nhóm phải giao tiếp với nhau thông qua giao diện này.
  • Không hình thức liên lạc nội bộ nào được phép thay thế. Hình thức liên lạc duy nhất là giao diện dịch vụ.
  • Không quan trọng công nghệ nào bạn đang dùng. HTTP, Corba, Pubsub, các giao thức tùy chọn khác. Bezos không quan tâm.
  • Mọi giao diện dịch vụ, không một ngoại lệ nào, đều phải được thiết kế ngay từ đầu sao cho có thể mở ra bên ngoài. Điều này có nghĩa là nhóm phải lên kế hoạch và thiết kế để đủ khả năng mở giao diện này ra cho cộng đồng phát triển phần mềm bên ngoài. Không có ngoại lệ nào cả.
  • Những cá nhân không thực hiện việc này sẽ bị cho nghỉ việc.

Microservice

Sắc lệnh API tại Amazon đã phần nào cho chúng ta biết về việc Amazon chú trọng vào một hệ thống phân tán, trao quyền cho nhóm nhỏ ra quyết định tinh gọn. Amazon đã chuyển từ kiến trúc Monolith sang Microservice để thực hiện hóa việc này (thể hiện rõ nhất tại AWS). Tất nhiên, mỗi kiến trúc đều có mặt hạn chế và tích cực. Chúng ta sẽ tìm hiểu mặt tích cực của kiến trúc này trong phần này.

Sự chuyển đổi từ Monolith sang Microservice. Nguồn: Amazon.
Sự chuyển đổi từ Monolith sang Microservice. Nguồn: Amazon.

Đầu tiên, hãy thảo luận về kiến trúc Monolith (kiến trúc một khối), đây là trường phái cổ điển khi mọi cấu thành của phần mềm gắn chặt với nhau (Hãy tưởng tượng chúng như đĩa mì spaghetti, khó lòng tách chúng ra với nhau được) và thực hiện nhiều việc. Nếu một quy trình trong ứng dụng có sự gia tăng đột biến nhu cầu thì toàn bộ kiến trúc này phải mở rộng quy mô lên. Việc thêm một tính năng trong ứng dụng có kiến trúc dạng này trở nên phức tạp hơn. Ngay cả một thay đổi nhỏ trong hệ thống cũng cần nhiều nỗ lực lên kế hoạch, sẵn sàng về nguồn lực nhân sự từ các nhóm, làm chậm lại chu trình ra sản phẩm.

Các nhóm chức năng như kiểm thử, triển khai, trải nghiệm người dùng (UI), nhóm backend… sẽ làm việc cục bộ và khó khăn khi truy trách nhiệm tới từ ai khi có bug (lỗi). Sự phức tạp này làm hạn chế việc thử nghiệm và đưa vào ý tưởng mới.

Chu trình phát triển trên kiến trúc Monolith. Nguồn: Amazon.

Với kiến trúc Microservice, phần mềm được chia thành các các cấu thành dịch vụ hoạt động độc lập (như từng chiếc bánh trong một hộp bánh, có thể lấy ra từng chiếc), thực hiện một việc duy nhất, giao tiếp qua APIs. Ví dụ, tính năng hiển thị phần “mua hàng” và tính năng hiển thị “sản phẩm cùng loại”, mặc dù xuất hiện trên cùng một màn hình đối với người dùng nhưng lại là những dịch vụ khác nhau. Nếu có thay đổi hoặc sửa bug gì thì có thể sửa mượt mà mà không ảnh hưởng tới các dịch vụ khác.

Các dịch vụ này được quản lý và chịu trách nhiệm bởi các nhóm nhỏ, độc lập. Kiến trúc microservice giúp các ứng dụng dễ dàng nhân rộng quy mô hơn và nhanh chóng hơn khi xây dựng và phát triển. Với các nhóm công nghệ, lập trình viên có thể vừa viết spec vừa triển khai.

Microservice không chỉ thay đổi về kiễn trúc kĩ thuật, Microservice còn thay đổi cả về văn hóa khi có các thành viên tham gia nhóm được tập hợp từ các nhóm chức năng khác nhau. Nếu trước đây nhóm UI/UX thành một khối riêng thì ở cơ chế này nhóm UI, UX sẽ được tách ra và làm tại các nhóm khác nhau. Do vậy các cá nhân có các góc nhìn đa dạng từ các phòng ban chuyên môn.

Chu trình phát triển trên kiến trúc Microservice. Nguồn: Amazon.

Quan trọng nhất: Cơ chế ra quyết định tinh gọn tại Amazon

Bí quyết để Amazon trao quyền cho các nhóm nhỏ vận hành nằm ở tư duy trong quá trình ra quyết định, phân ra làm hai loại: Quyết định loại I và Quyết định loại II. Quyết định loại I được vị như chiếc cửa một chiều. Đó là những quyết định mang tính ảnh hưởng lớn và ảnh hưởng tới chiến lược lớn của công ty. Một khi thông qua thì không thể đảo ngược và phải được lên kế hoạch một cách có hệ thống, cẩn thận, chậm rãi một cách tỉ mẩn. Khi bạn đã bước qua khỏi cánh cửa như vậy bạn không thể trở lại được nữa.

Ngược lại, quyết định loại II không như vậy, đó là quyết định mang ít tính rủi ro hơn, được ví như là cửa hai chiều: có thể thay đổi, trở ngược lại. Nếu bạn ra một quyết định dưới chuẩn, bạn có thể nhanh chóng mở cửa và quay lại. Những quyết định loại II sẽ được thực hiện nhanh chóng bởi cá nhân hoặc nhóm nhỏ. Hầu như các quyết định đều nằm ở loại II.

Một công ty có thể có cả hai các quyết định này. Tuy nhiên, các công ty, thường là công ty lớn thường nhầm lẫn giữa hai loại quyết định này. Khi các công ty có quy mô lớn thì sẽ có xu hướng sử dụng quy trình ra các quyết định loại I đối với mọi quyết định, bao gồm cả quyết định loại hai. Điều này sẽ tạo nên sự trì trệ, tư duy ngại rủi ro và không đưa ra thử nghiệm thích hợp. Kết quả là làm giảm sức đổi mới sáng tạo của công ty.

Quyết định loại I và loại II được phân chia rạch ròi. Đối với những quyết định loại I, Bezos sẽ đóng vai trò là “Giám đốc làm chậm quá trình” và đòi hỏi nhiều tiêu chí, bao gồm tính khác biệt, tính nhân rộng quy mô, tỉ lệ ROI. Với những quyết định loại hai, thường dưới dạng đổi mới tăng dần (Incremental Innovations), Amazon tạo ra cơ chế “nhiều con đường dẫn tới câu trả lời có”. Một nhân viên có ý tưởng và kế hoạch dự án có thể được phê duyệt và bật đèn xanh bởi nhiều người trong công ty, tránh tình trạng thắt nút cổ chai.

Kết luận

Như đã thảo luận trong bốn phần, công thức đổi mới sáng tạo của Amazon không có gì là thần kì cả, đó là một hàm gồm các biến số là văn hóa, tổ chức, cơ chế vận hành, kiến trúc. Tuy nhiên không phải công ty nào cũng có thể thực hiện nó, phần lớn là do văn hóa. Trong các biến số này, văn hóa đóng vai trò quan trọng nhất. Văn hóa ấy đã được truyền lửa từ lãnh đạo cấp cao nhất và lan tỏa và thẩm thấu xuống những nhân viên cấp thấp nhất trong tổ chức. Chính những yếu tố như vậy đã giúp Amazon duy trì tinh thần đổi mới sáng tạo, dù đã bước qua tuổi 26.

Hoàng Nam Lê – FPT Ventures

Bí mật công thức đổi mới sáng tạo tại Amazon – Phần 1
Công thức đổi mới tại Amazon: Phát triển sản phẩm ngược từ khách hàng – Phần 2
“Amazon là nơi tốt nhất trên thế giới để… thất bại” – Phần 3

Tin liên quan: