Sự chuyển dịch về nơi giá trị tồn tại
Việc tạo bản nháp đầu tiên đã trở nên rẻ
Trong cả thương mại và công việc tri thức, việc tạo ra bản nháp đầu tiên có vẻ hợp lý: một bản ghi nhớ, một truy vấn, một thiết kế, một bộ slide, một khối mã: giờ đây chi phí gần như bằng không. Các hệ thống tự động tạo ra đầu ra đầy tự tin theo yêu cầu. Điều chúng không thể làm là quyết định xem đầu ra đó có trả lời đúng câu hỏi hay không.
Sự chuyển dịch đó đẩy đòn bẩy của một chuyên gia lên thượng nguồn. Kỹ năng khan hiếm không còn là việc gõ phiên bản đầu tiên. Nó là định khung vấn đề, viết đặc tả, phân rã công việc, đặt câu hỏi chính xác và đánh giá kết quả được trả về.
Bài học này đào sâu vào bốn kỷ luật có tính cộng dồn:
- Định nghĩa vấn đề: tách biệt triệu chứng biểu hiện ra khỏi vấn đề thực sự.
- Quy cách (Specification): chuyển đổi một yêu cầu mơ hồ thành các tiêu chí thành công và ràng buộc chính xác, có thể kiểm tra được.
- Phân rã (Decomposition): cấu trúc một vấn đề lớn thành các vấn đề con độc lập, có thể xác minh được.
- Đặt câu hỏi đúng: với một bên liên quan, một tập dữ liệu, hoặc một hệ thống tự động, nơi độ chính xác của câu hỏi đặt ra giới hạn trên cho giá trị của câu trả lời.
Một câu trả lời tự tin cho một câu hỏi sai còn tệ hơn là không có câu trả lời, vì nó trông như đã hoàn thành và sẽ được triển khai. Công việc của người chuyên nghiệp là đảm bảo rằng câu hỏi đáng để trả lời trước khi bất kỳ ai trả lời nó.
Yêu cầu từ Ban Giám đốc
Tách biệt Triệu chứng khỏi Vấn đề
Một triệu chứng được trình bày là điều mà ai đó báo cáo. Vấn đề thực sự là tình trạng gốc rễ đã tạo ra triệu chứng đó. Giải quyết tốt một triệu chứng có thể khiến vấn đề thực sự vẫn bị bỏ ngỏ, và việc giao hàng đầy tự tin sẽ che giấu sự thất bại đó cho đến khi nó bộc lộ một cách đắt đỏ về sau.
Một Giám đốc điều hành (VP) bước đến và nói: "Bảng điều khiển bán hàng của chúng ta quá chậm. Hãy xây dựng cho chúng tôi một bảng điều khiển nhanh hơn trước cuối quý." Đó là một triệu chứng được đóng khung như một giải pháp. Chỉ dẫn đã đặt tên cho một công nghệ (bảng điều khiển) và một sự sửa chữa (nhanh hơn), điều này âm thầm loại bỏ các lựa chọn tốt hơn.
Chi phí của việc giải quyết đúng đắn một vấn đề sai chính là cái bẫy. Một đội ngũ có thể phát hành một bảng điều khiển nhanh một cách tuyệt đẹp, đáp ứng hạn chót, nhận được lời khen ngợi và vẫn thất bại, bởi vì thực tế VP cần phát hiện rủi ro khách hàng rời đi kịp thời để hành động, và ngay từ đầu đã không bao giờ xem bảng điều khiển hàng ngày.
Từ Yêu Cầu Mờ Màng Đến Tiêu Chí Có Thể Kiểm Thử
Đặc tả biến ý kiến thành bài kiểm thử
Một yêu cầu mơ hồ ("cải thiện quy trình onboarding", "dọn dẹp dữ liệu", "thêm tính năng tìm kiếm") không thể được giao hàng hoặc xác minh, vì không ai có thể nói khi nào công việc đã hoàn thành. Một đặc tả thay thế các tính từ bằng các bài kiểm thử. Nó nêu rõ các tiêu chí thành công theo cách mà ai đó có thể đo lường được, cùng với các ràng buộc mà giải pháp phải tuân thủ.
Hai thành phần làm cho một đặc tả trở nên thực tế:
- Tiêu chí thành công có thể kiểm thử: một điều kiện mà bạn có thể kiểm tra là đạt hay không đạt mà không cần tranh cãi. "Nhanh" là một ý kiến; "thời gian phản hồi p95 dưới 400 ms ở mức 200 yêu cầu mỗi giây" là một bài kiểm thử. "Onboarding tốt hơn" là một ý kiến; "80% người dùng mới hoàn thành bước 3 trong phiên đầu tiên của họ" là một bài kiểm thử.
- Các ràng buộc rõ ràng: các ranh giới mà giải pháp phải nằm trong đó: ngân sách, hạn chót, dữ liệu không được phép chạm đến, các hệ thống không được phép thay đổi, các quy định phải tuân thủ. Ràng buộc không phải là trở ngại; chúng là một nửa trong định nghĩa của một câu trả lời đúng.
Một kỷ luật hữu ích. Với mỗi tính từ trong yêu cầu, hãy viết ra phép đo sẽ xác định tính đúng/sai của nó, và ràng buộc giới hạn nó. Nếu bạn không thể viết bài kiểm tra, điều đó có nghĩa là bạn chưa hiểu đủ rõ yêu cầu để bắt đầu.
Khi bản nháp đầu tiên có chi phí tạo ra thấp, đặc tả (spec) là thứ cho bạn biết bản nháp đó có tốt hay không. Một đặc tả chính xác là một tiêu chí đánh giá có thể tái sử dụng. Nó chấm điểm mọi câu trả lời ứng viên theo cùng một cách.
Các bài toán con độc lập, có thể kiểm chứng
Chia tảng đá thành những viên đá có thể kiểm tra
Một bài toán lớn khó đánh giá vì bạn không thể xác định phần nào đang sai. Phân rã cấu trúc hóa nó thành các bài toán con, mỗi phần đủ nhỏ để có thể kiểm chứng độc lập. Một phép phân rã tốt có hai đặc tính.
- Độc lập: các bài toán con ít chồng chéo nhất có thể, để thay đổi ở phần này không vô tình phá hỏng phần khác. Khi các phần độc lập, chúng có thể được xử lý, kiểm thử và thậm chí tự động hóa song song, và một sự cố sẽ được cô lập thay vì lan rộng.
- Có thể kiểm chứng: mỗi bài toán con mang theo bài kiểm tra thành công riêng của nó, để bạn có thể xác nhận nó đã được giải quyết trước khi lắp ráp toàn bộ. Một phần mà bạn không thể kiểm tra là một phần mà bạn không thể tin tưởng.
Một bài toán được phân rã tốt cũng cho bạn biết nên hướng sự phán đoán quý giá của con người vào đâu. Hầu hết các bài toán con là thường quy và có thể giao cho một hệ thống tự động hoặc một người thực tập, sau đó kiểm tra đối chiếu với bài kiểm thử của chúng. Một hoặc hai phần là cốt lõi, có độ bất định cao, hậu quả lớn và dễ bị sai một cách tự tin. Những phần đó giữ sự chú ý của chuyên gia.
Hãy cảnh giác với sự phân rã giả: các phần chỉ trông có vẻ tách biệt nhưng chia sẻ một sự phụ thuộc ẩn, khiến các mảnh "hoàn thành" không ghép lại thành một tổng thể hoạt động được. Thử nghiệm của một phép phân rã là việc giải quyết mọi phần, mỗi phần đã được kiểm chứng, có thực sự giải quyết được bài toán gốc hay không.
Câu Hỏi Đặt Trần Cho Câu Trả Lời
Câu hỏi rác vào, câu trả lời rác tự tin ra
Dù bạn truy vấn một bên liên quan, một tập dữ liệu hay một hệ thống tự động, độ chính xác của câu hỏi đặt ra một trần cho giá trị của câu trả lời. Một câu hỏi mơ hồ không thất bại một cách ồn ào. Nó trả về một câu trả lời trôi chảy, tự tin và hợp lý cho một câu hỏi mà bạn không có ý định hỏi, và câu trả lời đó trông có vẻ đã hoàn chỉnh.
Hãy xem xét một yêu cầu dữ liệu mơ hồ: "Hãy lấy cho tôi danh sách khách hàng tốt nhất của chúng ta." Mọi từ mang tính then chốt đều chưa được định nghĩa. Tốt nhất theo tiêu chí nào: tổng doanh thu, biên lợi nhuận, tỷ lệ giữ chân, tốc độ tăng trưởng, hay giới thiệu? Trong khoảng thời gian nào: trọn đời, mười hai tháng gần nhất, hay quý này? Những khách hàng nào được tính: chỉ khách hàng đang hoạt động, bao gồm cả khách đã rời bỏ, hay bao gồm cả khách dùng thử? Một tập dữ liệu sẽ sẵn lòng trả lời bất kỳ phiên bản nào mà truy vấn tình cờ mã hóa, và người yêu cầu sẽ hành động dựa trên nó như thể nó chính là điều họ đã nghĩ trong đầu.
Một câu hỏi chính xác sẽ chốt chặt bốn điều: đại lượng hoặc thực thể cụ thể, quần thể mà nó áp dụng, khung thời gian, và các tiêu chí phân biệt hoặc ngưỡng. Kỷ luật tương tự áp dụng cho con người ("khi bạn nói 'tốt nhất', bạn có ý nói có lợi nhuận nhất trong năm nay, hay khả năng gia hạn cao nhất không?") và cho hệ thống tự động, nơi một prompt thiếu quy định sẽ tạo ra một câu trả lời tự tin cho một câu hỏi sai.
Kỹ năng chuyên nghiệp là nhận ra sự mơ hồ TRƯỚC KHI câu trả lời đến, bởi vì một câu trả lời sai nhưng tự tin rất tốn kém để phát hiện sau khi sự việc đã xảy ra. Độ chính xác trong câu hỏi rẻ hơn nhiều so với việc sửa chữa sau khi sự việc đã xảy ra.
Nơi đòn bẩy của bạn hiện đang nằm
Bản nháp đầu tiên rẻ; việc đặt vấn đề và phán đoán thì không
Hãy kết nối các yếu tố lại với nhau. Khi một phiên bản đầu tiên khả thi của hầu hết mọi thứ có thể được tạo ra theo yêu cầu, công việc mang lại giá trị là công việc mà một hệ thống tự động không thể làm thay bạn: quyết định vấn đề nào đáng để giải quyết, quy định ý nghĩa của "đúng", chia nhỏ vấn đề để có thể kiểm tra, đặt câu hỏi một cách chính xác và phán đoán xem câu trả lời được trả về có thực sự đáp ứng quy định hay không.
Hãy mang danh sách kiểm tra về cách đặt vấn đề này vào bất kỳ tác vụ nào mơ hồ, trước khi tạo ra bất kỳ bản nháp nào:
- Vấn đề: Triệu chứng biểu hiện là gì, và vấn đề cốt lõi nằm ở đâu? Chi phí của việc giải quyết sai vấn đề là bao nhiêu?
- Thành công: Các tiêu chí có thể kiểm chứng cho "hoàn thành và chính xác" là gì? Liệu hai người có thể có quan điểm khác nhau về việc mỗi tiêu chí đã được đáp ứng hay chưa? Nếu có, hãy làm rõ hơn.
- Ràng buộc: Những ranh giới nào mà giải pháp phải tuân thủ: ngân sách, hạn chót, dữ liệu, hệ thống, quy tắc?
- Phạm vi: Điều gì được chủ động loại trừ khỏi phạm vi?
- Phân rã: Vấn đề này được chia thành những sub-vấn đề độc lập, có thể kiểm chứng riêng lẻ nào? Sub-vấn đề nào là then chốt đối với sự phán đoán của con người?
- Câu hỏi: Đối với bất kỳ truy vấn nào gửi đến một người, tập dữ liệu, hoặc hệ thống, chỉ số, quần thể, cửa sổ thời gian và quy tắc xử lý trường hợp hòa (tie-breaker) đã được xác định rõ ràng chưa? Sự mơ hồ nào có thể dẫn đến một câu trả lời sai nhưng vẫn đầy tự tin?
- Phán đoán: Khi câu trả lời được đưa ra, bài kiểm tra nào cho tôi biết nó là đúng thay vì chỉ đơn thuần là trôi chảy?
Chuyên gia của thời đại này không phải là người tạo ra bản nháp đầu tiên nhanh nhất. Đó là người đặt khung cho vấn đề đủ tốt để một câu trả lời tốt trở nên có thể kiểm tra được, và một câu trả lời sai trở nên dễ nhận thấy.
Những gì bạn mang theo
Hai câu để ghi nhớ
Bạn đã thực hành tách biệt triệu chứng khỏi vấn đề, viết các tiêu chí thành công có thể kiểm chứng với các ràng buộc rõ ràng, phân rã một vấn đề thành các phần độc lập có thể xác minh, và làm sắc bén một câu hỏi để nó không thể trả về một câu trả lời sai nhưng đầy tự tin. Bốn động thái đó là một kỹ năng duy nhất: định khung (framing).
Giải quyết đúng vấn đề một cách xuất sắc là sai lầm đắt đỏ nhất trong công việc tri thức, vì nó trông giống như thành công. Và độ chính xác của câu hỏi bạn đặt ra sẽ đặt ra trần cho giá trị của bất kỳ câu trả lời nào, dù đến từ con người, tập dữ liệu hay hệ thống tự động.
Việc tạo ra bản nháp đầu tiên giờ đây đã rẻ và ngày càng rẻ hơn. Định khung vấn đề, viết đặc tả và đánh giá kết quả chính là nơi đòn bẩy của một chuyên gia nằm ở đó. Hãy mang theo danh sách kiểm tra. Hãy đặt câu hỏi sắc bén hơn. Hãy định nghĩa "hoàn thành" trước khi bạn bắt đầu.