Contents
Chào mừng bạn đến với Fx Studio. Bài này truy con số về tính năng không ai dùng mà cả ngành phần mềm trích suốt hai mươi năm, xem nó thật sự được đo trên cái gì.
Tập 3 của series Nghĩa địa skill — về những skill tui viết cho Claude Code rồi không mở lại lần nào. Tập này hỏi vì sao chúng chết. Câu trả lời mượn một con số cả ngành phần mềm trích suốt hai mươi năm để nói về tính năng không ai dùng — nhưng truy về gốc thì con số đó đo trên đúng bốn ứng dụng nội bộ. Một phép đo độc lập rộng hơn nhiều lại cho kết quả còn tệ hơn: kết luận sống sót, chỗ đứng của nó thì đổi chủ.
Tập trước tui chứng minh được là skill chết có giá, và giá đó không trả bằng dung lượng ổ cứng. Biết vậy rồi thì đáng ra hành vi phải đổi.
Nhưng tui biết chắc là tháng sau tui vẫn sẽ viết thêm một skill nữa, và có khả năng cao là cũng không gọi lại nó lần thứ hai.
Biết mà vẫn làm thì không phải chuyện thiếu thông tin. Nên tập này tui đi tìm chỗ khác.
Tin đỡ buồn trước: tính năng không ai dùng là bệnh của cả ngành
Chuyện xây ra thứ không ai dùng không phải bệnh riêng của mấy người nghịch skill lúc rảnh. Nó là bệnh của cả ngành phần mềm, và có hẳn một con số cho nó.
Standish Group: bốn mươi lăm phần trăm tính năng trong một sản phẩm phần mềm điển hình chưa bao giờ được dùng, thêm mười chín phần trăm nữa thì hiếm khi. Cộng lại thành sáu mươi tư phần trăm — con số vẫn được trích tới hôm nay để biện hộ cho việc làm sản phẩm gọn hơn.
Đọc tới đây thì dễ chịu hẳn. Ai cũng vậy mà. Không phải mình dở.
Đó chính là lúc nên dừng lại.
Con số 64% của Standish Group từ đâu ra
Tui đi tìm nguồn, và hoá ra có người đã đi trước từ lâu.
Mike Cohn (đồng sáng lập Scrum Alliance) thấy con số này bị lặp đi lặp lại tới mức người trích không còn hiểu nó từ đâu ra, nên ông liên hệ thẳng Standish Group để hỏi cho rõ. Phía Standish trả lời rất hợp tác.
Kết quả: dữ liệu mà Jim Johnson trình bày, và được lặp lại suốt từ đó tới nay, đến từ một nghiên cứu trên bốn ứng dụng.
Bốn. Và toàn bộ là ứng dụng dùng nội bộ. Không có sản phẩm thương mại nào trong đó.
Nói cách khác, con số vẫn đang được dùng để mô tả “một sản phẩm phần mềm điển hình” thực ra được đo trên bốn phần mềm nội bộ của bốn công ty.
Con số được nói ra lần đầu ở đâu: keynote XP 2002
Con số này được nói ra lần đầu tại một hội nghị, và đoạn đó đáng kể lại vì có người ghi chép ngay tại chỗ.
Con số được Jim Johnson, chủ tịch Standish Group, trình bày trong một bài keynote tại hội nghị XP 2002 ở Sardinia. Martin Fowler (tác giả cuốn Refactoring) ngồi dưới hội trường và viết bài tường thuật hội nghị đó. Trong bài của ông, con số được ghi lại hơi khác cách người ta trích hôm nay: bốn mươi lăm phần trăm tính năng chưa bao giờ được dùng, và chỉ hai mươi phần trăm được dùng thường xuyên hoặc luôn luôn.
Cùng bài nói đó, Johnson còn dẫn một nghiên cứu khác của DuPont, theo đó chỉ hai mươi lăm phần trăm tính năng của một hệ thống là thật sự cần.
Tức là ngay từ ngày đầu, con số này đã được trình bày như một trong nhiều mẩu dữ liệu trong một bài nói, chứ không phải như một hằng số của ngành. Hai mươi năm trích qua trích lại đã bào mòn hết phần bối cảnh, chỉ còn lại cái tỉ lệ trần trụi.
Phản biện: đừng vội quẳng con số Standish đi
Đây là phần tui suýt bỏ, và bỏ thì bài này thành một bài đập cho sướng tay.
Có người phản bác lại Cohn, và lý lẽ của họ không tệ. Đại ý: nghiên cứu này là nghiên cứu thật với dữ liệu thật, và nó đáng tin, dù phạm vi có hẹp. Việc bắt mọi người phải kèm theo hàng loạt chú thích chi tiết mỗi lần trích sẽ chỉ làm rối người mới, và làm mất giá trị dạy học của nó.
Họ cũng chỉ ra rằng Standish quay lại chủ đề này năm 2014 với dữ liệu rộng hơn, và kết luận vẫn cùng chiều: phần lớn tính năng có giá trị thấp hoặc không có giá trị.
Tui không nghĩ phe nào sai hẳn. Chỗ hai bên thật sự bất đồng không phải là “con số đúng hay sai”, mà là một con số hẹp thì được phép đi xa tới đâu.
Và có một cách thoát khỏi cuộc cãi đó: đi tìm thêm một phép đo khác, độc lập.
Phép đo độc lập: báo cáo Pendo trên 615 thuê bao
Pendo là công ty làm phân tích sản phẩm, tức là họ ngồi sẵn trên dữ liệu dùng thật.
Trong báo cáo Feature Adoption 2019, họ phân tích mức sử dụng tính năng trên sáu trăm mười lăm thuê bao, chỉ lấy những khách hàng đã dùng Pendo hơn một năm. Kết quả: tám mươi phần trăm tính năng trong một sản phẩm phần mềm trung bình hiếm hoặc không bao giờ được dùng. Và mười hai phần trăm tính năng tạo ra tám mươi phần trăm lượng dùng hằng ngày.
Sáu trăm mười lăm, so với bốn.
Đáng chú ý là con số Pendo còn tệ hơn con số Standish. Nên cú truy nguồn của Cohn không lật đổ kết luận — nó chỉ lật đổ cái quyền được nói “đây là hằng số của ngành” dựa trên bốn ứng dụng nội bộ.
Kết luận sống sót. Chỗ đứng của nó thì đổi chủ.
Vậy vì sao skill chết
Giờ quay về thư mục của tui, với chỗ đứng đã vững hơn.
Kiểu chết thứ nhất: viết cho một người không tới. Tui đã kể ở tập 1. Mỗi skill được viết cho phiên bản kỷ luật hơn của tui — cái phiên bản mỗi lần đụng việc đều nhớ ra mình có sẵn công cụ. Người tới mỗi sáng thì đang vội và chỉ nhớ ba bốn cái tên quen tay.
Chỗ này nối thẳng vào con số ở trên. Trong sản phẩm thương mại, tính năng chết vì được xây cho một người dùng giả định mà đội sản phẩm tưởng tượng ra. Trong thư mục cá nhân, skill chết vì được xây cho một bản thân giả định. Cùng một lỗi, chỉ khác là ở nhà thì không ai họp để phản biện giùm.
Kiểu chết thứ hai: viết đúng lúc hào hứng, không đúng lúc cần. Cái này khó thấy hơn, vì lúc đang hào hứng thì cảm giác giống hệt lúc đang cần. Mình vừa phát hiện ra một chỗ dùng được, và muốn đóng nó lại thành công cụ trước khi cảm giác đó nguội. Nhưng “vừa phát hiện ra một chỗ dùng được” và “sẽ còn phải làm việc này nhiều lần nữa” là hai chuyện hoàn toàn khác nhau. Cái thứ nhất chỉ cần một lần làm. Cái thứ hai mới đáng một skill.
Kiểu chết thứ ba thì tui để dành. Nó không nằm ở người viết mà nằm ở quan hệ giữa các công cụ với nhau, và nó là cửa vào tập sau.
Cái tui mang về từ cú truy nguồn
Tập này lẽ ra chỉ có một bài học. Cuối cùng nó có hai, và cái thứ hai tui không định trước.
Cái thứ nhất: skill chết chủ yếu vì được viết cho một phiên bản mình không sống thành, hoặc viết vào đúng cái khoảnh khắc hào hứng nhất và cũng ít tỉnh táo nhất.
Cái thứ hai đến từ chính quá trình đi tìm. Tui định mượn một con số để nói rằng mình không cô đơn, và trong lúc đi tìm chỗ dựa đó thì phát hiện chỗ dựa mỏng hơn mình tưởng. Con số vẫn dùng được, nhưng phải kèm theo lai lịch của nó.
Và tui nghĩ đó là một thói quen đáng giữ hơn cả con số. Con số được trích nhiều nhất thường là con số ít người truy về gốc — chính vì nó tiện, nên không ai thấy cần kiểm.
Cú truy nguồn thường hay hơn cả con số.
Tập 4: cái sống sống nhờ gì.
Nguồn
- Mike Cohn, Are 64% of Features Really Rarely or Never Used? — Mountain Goat Software. Ông liên hệ trực tiếp Standish Group; dữ liệu gốc dựa trên bốn ứng dụng nội bộ.
- Martin Fowler, The XP 2002 Conference — tường thuật tại chỗ bài keynote của Jim Johnson, gồm cả con số DuPont.
- Phản biện: A Response to Mike Cohn’s Comments on 64% of Software Features Rarely or Never Used — Scrum Crazy Blog. Dẫn thêm tài liệu Standish 2014.
- Pendo, The 2019 Feature Adoption Report — 615 thuê bao, khách hàng dùng trên một năm; 80% tính năng hiếm hoặc không bao giờ dùng; 12% tính năng tạo 80% lượng dùng hằng ngày.
Cảm ơn bạn đã đọc bài viết này!
Related Posts:
