Năm ngoái tôi xem video này về văn hóa làm việc ở Spotify, và BÙM! CLGT? tôi sướng vãi hết cả ra quần. Tôi thực sự thấy yêu Spotify!. Video giải thích mô hình/ cách thức/ phương pháp luận phát triển sản phẩm ở Spotify. Spotify cà 1 công ty 100% Agile. Họ bắt đầu với Scrum, nhưng khi đông lên, họ thấy 1 số điều bất trong phương pháp Scrum không phù hợp với họ. Vì vậy, họ quyết định phá vỡ 1 số vai trò, sự kiện, quy tắc của Scrum.

"Tuân theo các quy tắc là tốt cho khởi đầu, sau đó hãy phá bỏ chúng"
“Rules are a good start, then break them”

Các kỹ sư ở Spotify phát hiện ra rằng Agile quan trọng hơn Scrum, và các nguyên lý quan trong hơn mọi quy tắc thực hành cụ thể. Spotify đổi tên Scrum Master (Ông chủ Scrum) thành Agile Coach (Huấn luyện viên Agile) bởi vì họ muốn "servant leaders" (Lãnh đạo kiểu Đầy tớ - như lời Bác Hồ dạy ấy) hơn là "process masters" (Ông chủ Quy trình). Họ cũng đổi Scrum Team thành Tiểu đội (Squad).

Tiểu Đội là gì?

Là 1 team nhỏ, đa chức năng, tự quản, thường có ít hơn 8 thành viên. Các thành viên cùng có trách nhiệm chung, làm việc cùng nhau hướng đến 1 sứ mệnh dài hạnh của đội. Trong Đội, yếu tố quan trọng nhất là Tự chủ.

Mỗi Đội được tự chủ khi quyết định sẽ làm cái gì, làm sao để làm ra nó, và làm việc với nhau như nào trong khi làm ra nó. Tuy nhiên, Đội cũng cần định hướng đến sứ mệnh của Đội, chiến lược sản phẩm, và các mục tiêu ngắn hạn.

"Hãy tự chủ, nhưng đừng tối ưu cục bộ!"
“Be autonomous, but don’t sub-optimize!”

Tại sao cần Tự chủ?

Tự chủ tạo cho các thành viên cảm giác sở hữu tập thể. Họ là 1 phần của tổng thể lớn hơn, là các thành viên chủ động (chứ không bị động) của đội, đang "tạo ra các đóng góp tổng thể tích cực cho tổ chức" - Griffin và Moorhead, 2008 (Organizational Behavior Managing People and Organizations, 2009 Ed).

Ủy thác > kiểm soát
Trust > control

Mọi người làm việc với sự tự quản, tự chủ, tính mục đích (autonomy, mastery, and purpose). Tự chủ thúc đẩy động lực, và con người có động lực sẽ xây dựng nên những thứ tốt hơn, nhanh hơn. Tự chủ giúp chúng ta nhanh hơn vì cho phép các quyết định được đưa ra từ nội bộ Đội thay vì bởi người quản lý/ ban lãnh đạo.

Vai trò của Đội

  • Việc của leader: Truyền tải vấn đề gì cần được giải quyết. Và tại sao.
  • Việc của Đội: Phối hợp với nhau để đưa ra giải pháp tốt nhất.
"Các đội có tính định hướng mạnh, và tính lệ thuộc yếu (vào đội khác)"
“Loosely coupled, tightly aligned squads”

Tại sao cần Định hướng?

Định hướng cho phép & thúc đẩy tự chủ. Một điều quan trọng là, tất cả mọi người cần hiểu văn hóa công ty/ văn hóa khởi nghiệp. Khi tính định hướng càng cao thì chúng ta càng có thể tự chủ.

"Tự chủ có định hướng giúp tăng động lực, chất lượng, và tiến độ (release nhanh hơn)"
Nguồn: Spotify Engineering Culture — Part 1

Phương pháp của Spotify

Spotify hầu như không có các quy chuẩn. Họ tin rằng thụ phấn chéo tốt hơn chuẩn hóa (cross-pollination is better than standardization). Ví dụ, khi có nhiều Đội sử dụng 1 công cụ thì công cụ ấy trở thành 1 "con đường với ít chướng ngại" và các Đội khác có xu hướng cùng chọn công cụ ấy. Sau khi các Đội khác cũng chọn công cụ này, thử nghiệm với nó, tương tác & chém gió với nhau, thì công cụ này tự nhiên trở thành chuẩn.

Nhất quán x Linh động

Spotify thực hiện 1 mô hình mã nguồn mở nội bộ, với văn hóa chia sẻ hơn là sở hữu (their culture is more sharing than owning). Dựa trên văn hóa "tôn trọng hơn là tự trọng" (coi trọng nhau hơn là cái tôi của mình), Spotify đẩy mạnh việc peer code review, theo đó, bất cứ ai cũng có thể thêm/sửa code bất cứ lúc nào. Sau đó, 1 bạn có thể review code và đưa ra các điều chỉnh. Mọi người tương tác và lan toả tri thức! Họ cũng có 1 văn hóa tập trung vào động lực, với văn hóa ấy, họ trở thành 1 môi trường làm việc có danh tiếng rất tốt.

Đội làm việc như nào?

Vì Spotify có rất nhiều Đội nên họ phải tạo ra 1 cấu trúc. Mỗi Đội được nhóm lại vào 1 Làng (Tribe, Bộ tộc) trong đó có các Tộc (Chapter, Dòng tu). Họ cũng có các Hội (Guild, Hiệp hội), là các cộng đồng có chung 1 sở thích/ mối quan tâm, và có 1 mailing list hoặc 1 phương pháp liên lạc khác.

Nguồn: Spotify Engineering Culture — Part 1
  • Làng: Là 1 ma trận gọn nhẹ, tập trung vào việc đưa ra sản phẩm đều đặn và chất lượng.
  • Tộc: Là 1 nhóm được lập theo lĩnh vực chuyên môn như Đảm bảo chất lượng, Huấn luyện Agile, Lập trình web.
  • Hội: Là 1 cộng đồng gọn nhẹ chung sở thích, nơi mọi người trong toàn công ty tham gia và chia sẻ tri thức về 1 lĩnh vực cụ thể. Bất kỳ ai cũng có thể vào hoặc rời Hội bất cứ lúc nào.
"Hầu hết mọi sơ đồ tổ chức đều chỉ là ảo giác"

Hầu hết mọi sơ đồ tổ chức đều chỉ là ảo giác. Spotify tập trung vào cộng đồng xuyên cấu trúc hơn là vào sự phân tầng trong cấu trúc. Họ thấy rằng 1 cộng đồng đủ mạnh có thể hiệu quả mà không cần cấu trúc loằng ngoằng. Nếu bạn cần phải biết chính xác ai là người sẽ ra quyết định, thì bạn đang đi ngược lại văn hóa Spotify rồi.

"Nếu bạn cần phải biết chính xác ai là người sẽ ra quyết định, thì bạn đang làm sai cơm mẹ nấu văn hóa của chúng ta rồi."
Nguồn: Spotify Engineering Culture — Part 1

Họ đưa sản phẩm của họ lên môi trường thật dễ dàng ra sao?

Mục tiêu chính là release nhỏ & nhanh. Họ đầu tư vào tự động hóa và vào hạ tầng cho việc release liên tục. Khi quy trình release khó thì ngay cả các release đơn giản cũng khó được thực hiện. Ngược lại, khi việc release là dễ thì các release sẽ được thực hiện thường xuyên hơn!

Thay vì tạo ra các quy tắc và quy trình cồng kềnh để quản lý các release, Spotify đơn giản hóa quy trình để khuyến khích các release nhỏ và nhanh. Họ thay đổi kiến trúc để cho phép các release riêng lẻ được thực hiện độc lập / không phụ thuộc nhau thông qua cơ chế gọi là "bộ khung nhúng": Mỗi phần trên website (hay trên ứng dụng của họ) giống như 1 khung độc lập mà 1 đội có thể trực tiếp release vào đó (và các khung này được nhúng vào với nhau để tạo nên toàn thể ứng dụng).

Muốn biết cơ cấu tổ chức của chúng tao, hãy nhìn vào giao diện sản phẩm.
--xem thêm Luật Conway--

Spotify có 3 loại Đội khác nhau dựa trên mô hình tự phục vụ.

  • Đội tính năng: Tập trung vào 1 vùng tính năng.
  • Đội ứng dụng khách (Client App Squad): Tập trung vào việc làm cho các release được dễ dàng trên 1 phạm vi nền tảng cụ thể.
  • Đội hạ tầng: Tập trung vào việc làm cho các Đội khác hiệu quả hơn bằng cách cung cấp các công cụ và cách thức cho họ.

Chuyến tàu release - bật tắt tính năng

Mỗi ứng dụng khách có 1 chuyến tàu khởi hành theo lịch trình đều đặn, thường là mỗi tuần hoặc mỗi 3 tuần.  Chuyến tàu khởi hành thường xuyên, nhưng không cần khăng khăng phải theo kế hoạch từ trước.

Thú vị là, Spotify release các tính năng ẩn.  Ví dụ, nếu chuyến tàu tiếp theo rời bến với 1 tính năng chưa hoàn thành 100% thì họ sẽ (vẫn) release tính năng này dưới dạng ẩn. Tại sao họ làm thế? Câu trả lời khá đơn giản! Release các tính năng chưa hoàn thành và ẩn chúng đi cho phép phát hiện các vấn đề tích hợp sớm và tối thiểu hóa nhu cầu phải phân nhánh source code. Thông minh vãi đái!

Nguyên lý > Quy tắc thực hành
Principles > Practices

Các ý tưởng thú vị:

  • Hầu hết mọi bức tường ở Spotify là bảng trắng.
  • Mỗi Đội có không gian riêng của họ với 1 phòng khách và phòng họp.
  • Tính năng ẩn được release để phát hiện sớm các vấn đề tích hợp.

Không sợ hãi, không ra lệnh - Hãy liên tục thử nghiệm!

Chú ý:

Sau khi đọc phần 1 này, đừng quên đọc phần 2 ở đây (sắp viết :D)

Tham khảo


Nguồn: Spotify Squad framework — Part I