Phần mềm hướng đến doanh thu: Đánh giá theo cách sử dụng, không phải tính năng

Cách tiêu chuẩn để đánh giá một dự án phần mềm là hoàn thiện tính năng: chúng ta đã xây dựng những gì có trong đặc tả chưa? Việc phát triển phần mềm theo hướng doanh thu đặt ra một câu hỏi khác: sáu tháng sau khi ra mắt, doanh nghiệp có hoạt động tốt hơn nhờ hệ thống này không?

Hai câu hỏi đó tạo ra những dự án rất khác nhau.

# Trường hợp các dự án tập trung vào tính năng gặp trục trặc

Một hệ thống đầy đủ tính năng mà không ai sử dụng sẽ thất bại theo bất kỳ thước đo kinh doanh nào, nhưng nó đã vượt qua bài kiểm tra thành công của dự án truyền thống. Các đặc điểm kỹ thuật đã được chuyển giao. Người bán được trả tiền. Hệ thống không được sử dụng trong khi nhân viên quay lại bảng tính.

Điều này xảy ra vì những lý do có thể dự đoán được:

• Hệ thống được thiết kế theo đặc điểm kỹ thuật, không dành cho những người sử dụng nó hàng ngày
• Đào tạo là một buổi duy nhất thay vì được nhúng vào quá trình giới thiệu
• Giao diện yêu cầu mười bước cho một tác vụ mất hai bước theo cách cũ
• Nhân viên không tham gia vào quá trình thiết kế và không tin tưởng vào kết quả đầu ra

Không ai trong số này là lỗi của người dùng. Chúng là những thất bại trong thiết kế.

# Phương pháp tiếp cận Result Marketing

Jared Loo đến với công việc phát triển phần mềm với tư cách khách hàng đầu tiên. Ông điều hành công ty hậu cần tàu chở nước Terasek và một doanh nghiệp thương mại điện tử, chi mức bảy con số cho công nghệ và sống chung với hậu quả của những hệ thống được xây dựng nhưng không được sử dụng. Kinh nghiệm đó là nền tảng cho cách chúng tôi xây dựng.

Jacob Ng, người thiết kế hệ thống của chúng tôi, tập trung cụ thể vào giao diện dành cho người lao động ở tuyến đầu và người nhập cư - những người mà hệ thống phức tạp có nghĩa là họ sẽ tránh xa hệ thống. Nguyên tắc thiết kế là: nếu phải đào tạo mới học được thì thiết kế chưa hoàn thành.

Sự kết hợp tạo ra phần mềm được đánh giá bằng việc liệu những người cần sử dụng nó có thực sự làm được hay không.

# Quá trình phát triển dựa trên doanh thu trông như thế nào

Các đánh giá trong 30 ngày và 90 ngày không mang tính chất thương mại - chúng là một biện pháp kiểm tra xem mức độ sử dụng có ở mức cần thiết hay không và mọi điểm xung đột đều được giải quyết.

# Vấn đề áp dụng là vấn đề thiết kế

Khi chúng tôi thực hiện một dự án giải cứu - một hệ thống đã được xây dựng nhưng chưa được sử dụng - vấn đề gần như không bao giờ liên quan đến kỹ thuật. Hệ thống hoạt động. Dữ liệu ở đó. Vấn đề là việc sử dụng nó một cách chính xác đòi hỏi nhiều nỗ lực hơn cách giải quyết mà nhóm đã phát triển.

Công việc phát triển phần mềm tùy chỉnh của chúng tôi bắt đầu bằng quy trình làm việc chứ không phải danh sách tính năng. Người lấy hàng tại kho cần làm gì trong 30 giây? Người quản lý tài chính cần xem gì nếu không đăng nhập vào ba hệ thống? Những câu hỏi đó xác định giao diện trước khi bắt đầu bất kỳ quá trình phát triển nào.

# Chủ doanh nghiệp là người dùng thực sự

Một người dùng bị đánh giá thấp của bất kỳ hệ thống kinh doanh nào chính là chủ sở hữu. Một hệ thống cung cấp cho nhân viên quy trình làm việc tốt hơn nhưng khiến chủ sở hữu không có khả năng hiển thị sẽ không thúc đẩy doanh thu. Mọi hệ thống chúng tôi xây dựng đều bao gồm lớp báo cáo và cảnh báo giúp chủ sở hữu biết điều gì đang xảy ra — mà không yêu cầu họ đăng nhập và điều hướng.

Điều này kết nối với trang about của chúng tôi: Result được thành lập bởi một người từng là khách hàng phần mềm thất vọng trước khi anh ta trở thành nhà xây dựng phần mềm. Quan điểm không thay đổi.

Câu hỏi thường gặp

# Làm thế nào để bạn đo lường xem một hệ thống đã được áp dụng hay chưa?

Nhật ký sử dụng là thước đo trực tiếp nhất — có bao nhiêu nhân viên đăng nhập, bao nhiêu giao dịch được xử lý thông qua hệ thống so với bên ngoài hệ thống và liệu các cách giải quyết thủ công có bị loại bỏ hay không. Chúng tôi xác định các số liệu áp dụng trong quá trình xác định phạm vi.

# Điều gì sẽ xảy ra nếu nhân viên của chúng tôi phản đối hệ thống mới?

Sự kháng cự thường là tín hiệu cho thấy hệ thống khó sử dụng hơn hệ thống thay thế. Phản hồi là lặp lại thiết kế chứ không phải thúc đẩy đào tạo. Nếu hệ thống mới thực sự dễ dàng hơn bảng tính thì việc áp dụng sẽ diễn ra mà không bị ép buộc.

# Giá của bạn được cấu trúc như thế nào cho phần mềm tùy chỉnh?

Các dự án được xác định phạm vi có thể phân phối được xác định và mức giá cố định cho phạm vi đó. Chúng tôi không tính phí theo giờ cho công việc không xác định. Phạm vi bao gồm đánh giá sau khi ra mắt, do đó rủi ro áp dụng được chia sẻ chứ không được chuyển cho khách hàng.

• Đặt lịch kiểm tra hệ thống*