Giới thiệu
Tôi thường bắt đầu bằng một quy trình đang có vấn đề, không phải một công nghệ đang được nhắc nhiều.
Tôi là Thiên Thành (BrianV), product builder, CTO và Co-Founder của ZiniSoft. Trong 15 năm làm phần mềm doanh nghiệp, tôi tập trung biến những vấn đề vận hành thực tế thành hệ thống có thể quan sát, kiểm soát và cải thiện.
Product builder15 năm làm phần mềmCTO & Co-Founder
Câu chuyện nghề nghiệp
Bảy năm với Kindie đã thay đổi cách tôi nhìn một sản phẩm.
Kindie là sản phẩm tôi đã đồng hành trong 7 năm. Quãng thời gian đó đủ dài để thấy một sản phẩm không chỉ được xây rồi hoàn thành. Nó phải thay đổi cùng người dùng, quy trình và những tình huống chỉ xuất hiện khi hệ thống được vận hành mỗi ngày.
Các sản phẩm như OmniSpa, SavvyBot và Intake là những ví dụ khác cho cùng một cách tư duy: bắt đầu từ công việc đang diễn ra, làm rõ ai chịu trách nhiệm rồi mới quyết định phần mềm hoặc AI nên tham gia ở đâu.
Một bài học tôi phải học là tự động hóa khi quy trình chưa rõ ràng không giúp team rõ hơn. Nó chỉ làm sự mơ hồ di chuyển nhanh hơn và khó truy vết hơn.
Cách tôi làm việc
Tôi cần hiểu công việc trước khi giao việc cho máy.
- 01Tín hiệu vận hành
- 02Quy trình và trách nhiệm
- 03Chuẩn hóa hoặc xây dựng
- 04Tự động hóa có giới hạn
- 05Kết quả có thể quan sát
Trước khi hỏi doanh nghiệp có thể dùng AI ở đâu, tôi thường làm rõ năm câu hỏi:
- Tín hiệu nào cho thấy quy trình đang có vấn đề?
- Công việc đang bị nghẽn ở đâu?
- Ai cần giữ quyền quyết định?
- Phần nào phần mềm hoặc AI có thể hỗ trợ an toàn?
- Bằng chứng nào cho thấy kết quả thực sự tốt hơn?
Chỉ sau đó tôi mới cùng team quyết định nên chuẩn hóa quy trình, dùng sản phẩm có sẵn, xây phần mềm riêng hay tự động hóa một phần có giới hạn. Những quyết định ảnh hưởng đến tiền, dữ liệu, quyền truy cập hoặc uy tín luôn cần một người chịu trách nhiệm.
Chia sẻ công khai
Tôi chia sẻ cả điều đang chạy và điều phải làm lại.
Tôi không viết để chứng minh mọi hệ thống đều thành công ngay từ đầu. Operator Notes, case study và demo là cách tôi ghi lại quyết định đã đưa ra, giới hạn đã chấp nhận và bằng chứng đang có.
Để người đọc có thể kiểm tra điều tôi nói, tôi tách rõ phần đang vận hành với phần thử nghiệm, tách vai trò của mình khỏi đóng góp của team và chỉ dùng số liệu khi có định nghĩa, kỳ đo cùng nguồn rõ ràng.
Tôi chia sẻ sơ đồ đã đơn giản hóa để giải thích cách tư duy; kiến trúc nội bộ, dữ liệu khách hàng và thông tin riêng tư không thuộc phạm vi công bố.
Nếu bạn đang có một quy trình thực tế làm team mất thời gian
Chúng ta có thể bắt đầu bằng việc làm rõ vấn đề nằm ở quy trình, dữ liệu, trách nhiệm hay công cụ; sau đó mới quyết định nên chuẩn hóa, xây dựng hoặc tự động hóa phần nào.