Khi một bản cập nhật đổi chỗ mọi thứ, tôi muốn giữ được cách làm việc của mình, để không phải học lại một công cụ mình đã thạo.
When an update moves everything, I want to keep my way of working, so I do not relearn a tool I had mastered.
Hoàn cảnh của Job
- Ai
- Người dùng thành thạo một công cụ
- Khi nào
- Mỗi lần có bản cập nhật
- Điều kích hoạt
- Mở lên và không tìm thấy thứ mình dùng hằng ngày
- Tình thế
- Thay đổi được quyết bởi người không dùng nó để làm việc
- Giới hạn
- Không có cách nào giữ lại bản cũ
5 Pains
Mọi thứ đổi chỗ sau một bản cập nhật
NặngVà không ai hỏi trước.
Gốc rễ: Quyết định thay đổi nằm hoàn toàn ở phía nhà cung cấp
Tính năng đang dùng bị gỡ đi
NặngVì thống kê nói ít người dùng.
Gốc rễ: Quyết định gỡ dựa trên số lượt chứ không trên mức phụ thuộc
Không có cách quay lại bản cũ
NặngCập nhật là bắt buộc.
Gốc rễ: Duy trì hai phiên bản tốn gấp đôi công của nhà cung cấp
Phải dạy lại cả đội sau mỗi lần đổi
VừaVà không ai tính công đó vào đâu.
Gốc rễ: Chi phí đào tạo lại rơi vào tổ chức dùng chứ không vào bên đổi
Góp ý gửi đi không đi tới đâu
VừaKhông bao giờ có hồi âm.
Gốc rễ: Kênh góp ý được lập để thu chứ không để trả lời
5 Desired Outcomes
Biết trước điều gì sắp đổi
Chức năngGiữ được tính năng mình phụ thuộc
Chức năngCó cách dùng bản cũ thêm một thời gian
Chức năngKhông phải đào tạo lại cả đội
Chức năngBiết góp ý của mình có tới nơi không
Xã hội
5 Existing Solutions
Giải pháp không đồng nghĩa với sản phẩm, khách hàng thuê được cả một hành vi hay một cách chống chế.
Hoãn cập nhật càng lâu càng tốt
Cách chống chếMua được thời gian, và cuối cùng vẫn phải cập nhật.
Viết lại hướng dẫn nội bộ sau mỗi lần đổi
Hành viCách duy nhất giữ đội chạy được, và nó là việc lặp lại mãi.
Gửi góp ý qua kênh chính thức
Sản phẩmViệc đúng cần làm, và gần như không bao giờ có hồi âm.
Tìm cách làm thay thế trong chính công cụ
Cách chống chếCách phục hồi nhanh nhất, và nó hỏng ở bản cập nhật sau.
Chuyển sang một công cụ khác
Hành viTín hiệu mạnh nhất gửi đi được, và nó tốn hơn nhiều so với việc chịu đựng.
2 Opportunity Gaps
Quyết định gỡ một tính năng dựa trên SỐ LƯỢT DÙNG vì đó là thứ hệ thống đếm được, còn thứ quyết định thiệt hại là MỨC PHỤ THUỘC của một nhóm nhỏ, thứ phép tổng hợp xoá sạch.
Vì sao giải pháp hiện có không đủ: Một tính năng được hai phần trăm người dùng dùng mỗi ngày và chín mươi tám phần trăm không bao giờ chạm tới sẽ luôn thua trong mọi biểu đồ, trong khi với hai phần trăm đó nó có thể là lý do duy nhất họ còn ở lại.
Cơ hội: Đọc phân bố thay vì đọc tổng, và liên hệ trực tiếp nhóm phụ thuộc nặng trước mỗi lần gỡ.
Lợi ích của một thay đổi thuộc về NHÀ CUNG CẤP, sản phẩm gọn hơn, dễ bảo trì hơn, còn chi phí học lại và đào tạo lại thuộc hoàn toàn về TỔ CHỨC DÙNG.
Vì sao giải pháp hiện có không đủ: Chi phí đào tạo lại không xuất hiện trong bất kỳ sổ sách nào của nhà cung cấp, nên khi cân nhắc một thay đổi thì một vế của phép so đơn giản là không có mặt, và điều đó khiến việc đổi luôn trông rẻ hơn thực tế.
Cơ hội: Đưa chi phí học lại của người dùng thành một con số trong chính quyết định thay đổi.