Quy tắc ưu tiên khi một đội nhỏ vận hành nhiều sản phẩm cùng lúc

Khi số lượng sản phẩm tăng lên, thứ gì sụp đổ trước tiên

Khi số sản phẩm tăng từ một lên ba, thứ sụp đổ trước tiên không phải là tốc độ phát triển mà là tính nhất quán trong phán đoán. Quyết định đưa ra tuần trước ở sản phẩm này bắt đầu mâu thuẫn với quyết định tuần này ở sản phẩm khác, và phải vài tuần sau đội mới nhận ra. Ngữ cảnh vỡ trước mã nguồn.

Mỗi sản phẩm có nhóm người dùng khác nhau, có tín hiệu thành công khác nhau, có quy trình triển khai và cấu trúc dữ liệu khác nhau. Buổi sáng bạn xem quy tắc chấm công của một dịch vụ quản lý điểm danh, buổi chiều bạn chỉnh thứ tự sắp xếp kết quả tìm kiếm của một dịch vụ tuyển dụng. Thứ mất đi giữa hai công việc đó không chỉ là thời gian. Cảm giác vừa hình thành ở công việc trước biến mất. Thời gian để dựng lại cảm giác ấy không bao giờ xuất hiện như một dòng trong lịch làm việc, nên đội không bao giờ biết mình đang mất bao nhiêu.

Thứ hai bị phá vỡ là tốc độ phản hồi. Khi chỉ có một sản phẩm, ai cũng có thể trả lời câu hỏi của người dùng. Khi có ba, số người trả lời được thu hẹp lại còn một, và nếu người đó đang bận với sản phẩm khác thì câu trả lời trễ thêm một ngày. Câu trả lời trễ không dừng lại ở việc trễ. Cùng một câu hỏi quay lại lần nữa, người dùng kết luận rằng dịch vụ không được chăm sóc, và gánh nặng hỗ trợ quay về lớn hơn ban đầu.

Thứ ba là hồ sơ và tài liệu. Với một sản phẩm, tài liệu sơ sài vẫn có thể bù bằng trí nhớ. Với nhiều sản phẩm, trí nhớ bắt đầu trộn lẫn vào nhau. Sự cố kiểu nhớ nhầm quy trình rồi đẩy bản dựng lên môi trường thật thay vì môi trường thử nghiệm không xảy ra vì thiếu năng lực, mà vì ba bộ quy trình khác nhau đang được cất trong đầu một người.

Có một cách đơn giản để kiểm tra đội của bạn đã ở điểm này chưa. Hỏi riêng từng người xem tuần này họ đang làm gì. Nếu câu trả lời khác nhau giữa các người, vấn đề đã bắt đầu. Hỏi tiếp sản phẩm nào đang quan trọng nhất lúc này. Nếu từ hai người trở lên nêu hai sản phẩm khác nhau, nghĩa là thứ tự ưu tiên không tồn tại. Giai đoạn mà ai cũng làm việc chăm chỉ nhưng không có gì hoàn thành bắt đầu chính từ đây.

Chúng tôi cũng đã đi qua đoạn đó. Yeowubie Interaction vận hành song song dịch vụ quản lý điểm danh onSpots, dịch vụ kết nối và định vị giữa người học và người dạy tiếng Hàn là Langtori, dịch vụ tuyển dụng tại Việt Nam là Job Connect VN, cùng nền tảng hỗ trợ vận hành cửa hàng cho hộ kinh doanh nhỏ là Winnie, đồng thời vẫn nhận phát triển cho khách hàng. Vấn đề không nằm ở chỗ thiếu người để xây. Vấn đề nằm ở chỗ chúng tôi cố đặt nhiều bộ tiêu chí phán đoán khác nhau vào cùng một cái đầu tại cùng một thời điểm. Vì vậy thay vì thêm người, chúng tôi đặt ra quy tắc trước.

Có giới hạn cho số sản phẩm chạy song song

Số sản phẩm chạy song song không được quyết định bởi số người, mà bởi số dòng quyết định đang sống. Dòng quyết định là một luồng công việc mà mỗi tuần phải có người phán đoán. Dù thêm người, nếu một người phải giữ hơn hai dòng quyết định thì chất lượng phán đoán giảm. Giới hạn trên xuất phát từ đó.

Một sản phẩm không phải là một bộ mã nguồn mà là một tải trọng thường trực. Ngay cả khi không viết thêm một dòng tính năng mới nào, tải trọng vẫn không về không. Chính sách xét duyệt của kho ứng dụng thay đổi, hệ điều hành lên phiên bản mới làm cách làm cũ không còn chạy, thư viện phụ thuộc có bản vá bảo mật, chứng chỉ và tên miền đến hạn gia hạn, câu hỏi của người dùng gửi tới, hóa đơn hạ tầng phát sinh hằng tháng. Tải trọng này sinh ra ở giai đoạn giữ cho sản phẩm sống, không phải ở giai đoạn xây. Vì vậy quyết định thêm một sản phẩm không phải là quyết định kéo dài lịch phát triển, mà là quyết định gánh thêm một khối tải cố định lặp lại mỗi tuần.

Ở đây cần khái niệm ô chứa. Hãy chia số chỗ mà đội đang có thành ba loại: phát triển chủ động, duy trì, và thử nghiệm, rồi cố định số lượng của từng loại. Ô phát triển chủ động là nơi tính năng mới và cải tiến thực sự được đưa vào. Ô duy trì là nơi sản phẩm vẫn sống nhưng không nhận tính năng mới. Ô thử nghiệm là nơi chạy có thời hạn với mục đích học hỏi. Điểm cốt lõi nằm ở việc cố định tổng số ô phát triển chủ động. Muốn đưa một sản phẩm mới lên phát triển chủ động thì phải hạ một sản phẩm đang ở đó xuống duy trì. Nếu không ép buộc sự đánh đổi này, danh sách phát triển chủ động sẽ dài mãi, và một danh sách quá dài rốt cuộc là danh sách không có gì tiến triển.

Giới hạn tổng khối lượng công việc đang chạy không phải ý tưởng mới. Đây là cách tiếp cận đã được dùng lâu năm cả trong sản xuất lẫn trong phần mềm. Lý do nó đặc biệt hiệu quả với đội nhỏ là vì càng ít người thì xác suất một người nằm trên nhiều luồng càng cao, và tổn thất do chuyển ngữ cảnh càng lớn.

Chế độ duy trì nếu chỉ nói miệng thì sẽ không được tuân thủ. Phải định nghĩa bằng văn bản. Công việc được phép trong chế độ duy trì gồm xử lý sự cố, cập nhật bảo mật, đáp ứng thay đổi chính sách của kho ứng dụng và nền tảng, cùng các biện pháp ngăn mất dữ liệu. Tính năng mới không được đưa vào. Những yêu cầu kiểu chỉ đổi một dòng chữ, chỉ thêm một màn hình chính là thứ gặm mòn chế độ duy trì. Yêu cầu nhỏ không kết thúc nhỏ. Sau nó là kiểm thử, là triển khai, là kiểm tra hồi quy. Khi định nghĩa chế độ duy trì, hãy viết luôn cả điều kiện thoát. Nếu đã định trước điều kiện nào cho phép đưa sản phẩm trở lại phát triển chủ động, người phụ trách có thể chờ mà không phải phá luật.

Đừng đặt giới hạn bằng cảm tính, hãy đặt bằng ghi chép. Nếu ghi lại thời gian thực tế bỏ ra cho từng sản phẩm trong hai đến ba tuần, bạn sẽ thấy phần thời gian cố định mỗi tuần không liên quan gì đến tính năng mới. Nếu tổng phần cố định đó vượt quá một nửa quỹ thời gian đội có thể dùng, thì đội đã không còn dư địa để gắn thêm sản phẩm mới. Phép tính này nếu làm bằng ước lượng thì luôn ra kết quả lạc quan. Phải ghi lại thật.

Ba trục ưu tiên: sống sót, học được gì, chi phí duy trì

Nếu chỉ xếp ưu tiên bằng một trục là triển vọng doanh thu thì phần lớn trường hợp sẽ sai. Cần nhìn ba trục cùng lúc. Thứ nhất là khả năng sống sót, thứ hai là thứ chỉ có thể học được từ sản phẩm đó, thứ ba là chi phí duy trì vẫn phát sinh dù không làm gì. Mục tiêu không phải chấm điểm mà là tạo ra một thứ tự.

Trục thứ nhất, khả năng sống sót, được đánh giá bằng tín hiệu chứ không bằng hy vọng. Vấn đề là phần lớn đội xác định tín hiệu vào lúc phải xem kết quả, chứ không phải lúc bắt đầu sản phẩm. Xác định vào lúc đó thì người ta sẽ chọn con số có lợi trong đám số đang có. Hãy xác định ngay từ đầu. Có người dùng quay lại lặp lại hay không, câu hỏi gửi tới là lời phàn nàn hay là yêu cầu tính năng, có luồng người dùng nào tự tìm đến mà không cần ai hướng dẫn hay không. Yêu cầu tính năng thường là tín hiệu tốt hơn lời phàn nàn, vì nó cho thấy người dùng có ý định tiếp tục dùng. Khi xác định tín hiệu, nhất định phải ghi kèm cả khoảng thời gian quan sát. Không có thời hạn thì phán đoán sẽ bị hoãn vô hạn.

Trục thứ hai, thứ học được, đặc biệt quan trọng với đội nhỏ. Ngay cả khi một sản phẩm chưa sinh ra tiền, nếu năng lực thu được khi xây nó chuyển được sang sản phẩm khác thì khoản đầu tư vẫn được thu hồi. Làm tử tế một lần phần đa ngôn ngữ và xử lý ngôn ngữ vùng thì ở sản phẩm sau bạn sẽ thiết kế khác ngay từ đầu. Vượt qua xét duyệt kho ứng dụng vài lần thì hình thành thói quen tránh trước các lý do bị từ chối. Từng xử lý múi giờ và qui ước hiển thị cho một dịch vụ trải trên hai quốc gia thì kinh nghiệm đó không mất đi. Tuy nhiên, sản phẩm được giữ lại vì lý do học hỏi thì bắt buộc phải gắn thời hạn. Học mà không có thời hạn chỉ là bỏ mặc.

Trục thứ ba, chi phí duy trì, không được chỉ đếm bằng tiền. Chi phí hạ tầng ai cũng thấy vì nó in trên hóa đơn, nhưng thứ đắt hơn thật sự là sự chú ý. Mỗi tuần thêm một bảng theo dõi phải xem, mỗi tháng thêm một thay đổi chính sách phải xử lý, mỗi lần sự cố thêm một bộ kiến thức nền phải nhớ để lần ra nguyên nhân. Sự chú ý không giống tiền ở chỗ không thể kiếm thêm về sau. Khi nhìn chi phí duy trì, đừng nhìn hóa đơn tháng này mà nhìn phần chú ý của con người mà sản phẩm đó sẽ lấy đi mỗi tuần từ nay về sau.

Điểm phán đoán thật sự nằm ở lúc ba trục cho ba câu trả lời khác nhau. Ở đây tôi không khuyên gán trọng số cho ba trục rồi cộng lại. Việc cộng điểm rất dễ trượt thành chuyện đã có kết luận trước rồi chỉnh trọng số cho khớp. Thay vào đó, hãy định sẵn cách xử lý cho từng tổ hợp. Tín hiệu sống sót yếu nhưng thứ học được lớn thì hạ xuống thành thử nghiệm có thời hạn. Tín hiệu mạnh nhưng chi phí duy trì lớn thì đưa chính việc giảm chi phí duy trì thành nhiệm vụ của quý đó. Tín hiệu yếu, không học được gì, mà chi phí vẫn chảy ra thì đó là đối tượng của quy tắc dừng ở phần sau. Tín hiệu mạnh và thứ học được cũng lớn thì đó chính là sản phẩm xứng đáng chiếm ô phát triển chủ động.

Sau khi có thứ tự, hãy viết thứ tự đó ra và đặt ở nơi cả đội nhìn thấy. Thứ tự ưu tiên chỉ nằm trong đầu sẽ bị thay bằng chủ đề của người nói to nhất trong cuộc họp kế tiếp. Khi đã viết ra, muốn đổi thì phải có lý do, và khi phải nêu lý do thì những thay đổi tùy hứng sẽ giảm hẳn.

Vì sao một người nên phụ trách trọn vẹn một sản phẩm

Nếu chia nhỏ một sản phẩm cho nhiều người mỗi người một mảnh, tổng thời gian bỏ ra như nhau nhưng kết quả sẽ tệ hơn. Thời gian dựng lại ngữ cảnh nhân lên theo số người, và quyết định liên tục bị hoãn. Khi một người phụ trách từ khâu làm rõ yêu cầu đến phát triển, triển khai và hỗ trợ sau đó, phán đoán nhanh hơn và vị trí trách nhiệm cũng rõ ràng.

Trước hết phải định nghĩa phạm vi của cụm từ phụ trách trọn vẹn. Nó gồm làm rõ yêu cầu, xây dựng, triển khai, tiếp nhận đầu tiên câu hỏi của người dùng, và giữ tài liệu của sản phẩm đó luôn cập nhật. Nếu định nghĩa phạm vi quá hẹp thì chế độ phụ trách trọn vẹn chỉ còn cái tên. Nếu một người chỉ lo phát triển còn người khác lo hỗ trợ, thì người hỗ trợ lần nào cũng phải đi hỏi và người phát triển lần nào cũng phải dừng việc đang làm. Cả hai đều thiệt.

Nói đến mô hình này thì lập tức có một phản biện: nếu người đó vắng mặt thì sao. Đây là câu hỏi chính đáng, nhưng không phải lý do để bỏ mô hình. Có ba cách phòng. Mỗi sản phẩm chỉ định một người dự phòng, người này bình thường không phát triển mà chỉ cần giữ khả năng đọc hiểu tài liệu. Quy trình triển khai và khôi phục được đặt trong tài liệu và kịch bản tự động, không đặt trong trí nhớ. Và mỗi quý một lần, người dự phòng thực sự thực hiện một lần triển khai. Tài liệu có đúng hay không thì đọc không biết được, phải chạy thử mới biết.

Việc mà người dẫn dắt phải làm là thực sự trao quyền quyết định cho người phụ trách. Nếu tuyên bố phụ trách trọn vẹn nhưng mọi quyết định vẫn phải người dẫn dắt duyệt, thì người phụ trách vẫn chỉ là người chuyển lời và nút thắt cổ chai vẫn nguyên đó. Hãy vạch trước ranh giới về việc quyết định nào người phụ trách được tự quyết. Thông thường bố cục màn hình, cách hiện thực, thứ tự các cải tiến nhỏ đều có thể để người phụ trách quyết mà không gây vấn đề. Chỉ những thứ khó đảo ngược như cấu trúc thu phí, chính sách lưu trữ dữ liệu, thời điểm công bố ra bên ngoài mới cần đưa lên trên. Không có ranh giới này thì mọi quyết định đều dồn lên, và người dẫn dắt rơi vào vị trí phải phán đoán chi tiết của toàn bộ sản phẩm đang vận hành cùng lúc. Quyết định sinh ra ở vị trí đó không thể tốt.

Cũng có những thứ không nên chia theo người phụ trách. Xác thực, chuẩn bảo mật, đường ống triển khai, mã màu và thành phần giao diện dùng chung là những thứ mà làm khác nhau ở từng sản phẩm chỉ tổ thiệt. Hãy tách chúng thành một lớp chung, quyết định một lần và để tất cả tuân theo. Nếu làm riêng cho từng sản phẩm thì phải quản ba bộ, và khi có vấn đề bảo mật thì phải sửa ba nơi. Ngược lại, nếu lớp chung phình quá to thì tính linh hoạt cần thiết cho từng sản phẩm sẽ chết. Tiêu chí phân ranh khá đơn giản. Nếu sai thì thiệt hại chỉ dừng ở một sản phẩm thì để trong sản phẩm, nếu lan sang nhiều sản phẩm thì đưa lên lớp chung.

Điểm yếu của mô hình này là kiến thức bị nhốt lại. Nếu ai cũng chỉ nhìn sản phẩm của mình thì trình độ kỹ thuật của cả đội không lên đều. Hãy tạo một buổi chia sẻ ngắn theo định kỳ. Chỉ cần mỗi người nói một chỗ từng bị tắc và một cách đã gỡ là đủ. Nếu bắt chuẩn bị tài liệu trình bày thì rồi sẽ không ai làm, nên giữ hình thức thật nhẹ sẽ bền hơn.

Cần có quy tắc để quyết định dừng lại

Đội chỉ có quy tắc bắt đầu mà không có quy tắc dừng sẽ chồng sản phẩm mãi. Nếu viết sẵn điều kiện dừng ngay từ lúc khởi động sản phẩm, về sau có thể quyết định mà không bị cảm xúc chi phối. Dừng không phải là tuyên bố thất bại mà là một hành động vận hành để giải phóng một ô. Có trống ô thì mới bắt đầu được việc tiếp theo.

Dừng có ba mức, và nếu không phân biệt ba mức này thì thảo luận luôn bị đẩy về hai thái cực. Mức thứ nhất là chuyển sang chế độ duy trì: dịch vụ vẫn chạy như cũ, chỉ dừng phát triển mới. Mức thứ hai là tạm giữ: đóng đăng ký mới hoặc luồng người dùng mới, chỉ giữ người dùng hiện có. Mức thứ ba là đóng: gỡ dịch vụ và xử lý dữ liệu. Trong phần lớn tình huống thứ cần dùng là mức một hoặc mức hai, nhưng vì từ dừng lập tức bị hiểu thành mức ba nên thảo luận trở nên khó. Đặt tên riêng cho từng mức sẽ khiến trao đổi dễ hơn nhiều.

Khi khởi động một sản phẩm, hãy viết sẵn ba điều. Khoảng thời gian quan sát kéo dài đến bao giờ, trong khoảng đó nhìn thấy gì thì coi là tiếp tục, và nếu không thấy tín hiệu đó thì hạ xuống mức nào trong ba mức trên. Ba dòng này viết vào lúc bắt đầu không tốn nhiều thời gian. Để đến lúc cần mới viết thì đã có sự gắn bó và chi phí đã bỏ ra bám vào, không tiêu chí nào được đồng thuận nữa.

Nếu đã quyết dừng thì phải coi chính việc dừng là một hạng mục công việc. Buông tay không phải là dừng mà là bỏ mặc. Hãy báo trước cho người dùng từ khi nào thì điều gì thay đổi, mở đường để họ mang dữ liệu của mình đi, dọn trạng thái đăng ký trên kho ứng dụng, kiểm tra hạn tên miền và chứng chỉ, tắt phần hạ tầng còn lại, và nếu còn khả năng mở lại thì để lại tài liệu ghi rõ cần gì để mở lại. Không làm phần kết này tử tế thì sản phẩm đã dừng vẫn tiếp tục lấy đi chi phí và sự chú ý. Tình huống tưởng đã dừng mà hóa đơn vẫn về hằng tháng sinh ra từ đây.

Để phán đoán này không mang tính tùy hứng, tốt hơn là biến nó thành một buổi định kỳ. Mỗi quý một lần, đặt toàn bộ sản phẩm đang vận hành lên bàn, xem lại ba trục và điều chỉnh cách xếp ô. Sẽ có những quý mà không có gì thay đổi sau buổi đó. Dù vậy đừng bỏ buổi này. Nếu không định kỳ thì thảo luận về việc dừng chỉ bắt đầu khi vấn đề đã lớn, và khi đó lựa chọn còn lại chỉ có mỗi việc đóng.

Quy tắc dừng nói ở đây là một công cụ vận hành, không phải một thủ tục nhắm vào sản phẩm cụ thể nào. Nó khác với việc báo trước rằng sẽ khai tử một sản phẩm. Mục đích của việc lập sẵn quy tắc thật ra nằm ở chiều ngược lại. Khi đã có cách dừng, việc bắt đầu một thử nghiệm mới trở nên dễ hơn. Đội trì hoãn khởi động khi cảm thấy không thể quay lại, và bắt đầu nhỏ và nhanh khi biết có quy trình để quay lại. Quy tắc ưu tiên và quy tắc dừng không nhằm làm cho đội trở nên rụt rè, mà là bộ công cụ tối thiểu để giữ chất lượng phán đoán trong khi vẫn chạy nhiều sản phẩm với ít người.