Từ một dòng GAP tới giải pháp khách chốt được

Tiêu chí hoàn thành của một dòng GAP (DoD GAP)

Đặt lại tiêu chí hoàn thành trước khi đi tiếp, vì tiêu chí sai thì mọi thứ phía sau lệch theo.

Một dòng GAP chưa xong khi bạn viết xong cột giải pháp, và cũng chưa xong khi khách đã đọc. Nó xong khi khách chọn được một phương án, biết mình đánh đổi cái gì khi chọn nó, và lựa chọn đó được ghi lại ở chỗ mà cả hai bên tra ra được.

Từ tiêu chí đó thì công việc còn lại chia làm hai phần. Phần đầu là tìm cho ra những phương án đáng đưa lên bàn, phần sau là dẫn cuộc trao đổi tới chỗ có người quyết. Bài này nói về cả hai, còn quy tắc viết cột giải pháp thì tôi đã nói ở bài về Fit-Gap Analysis.

Thang bốn nấc tìm phương án

Khi đứng trước một yêu cầu mà hệ thống chưa đáp ứng, phần lớn người mới nhảy thẳng vào câu hỏi cấu hình được không hay phải code. Câu đó không sai, nhưng nó là câu thứ hai chứ không phải câu thứ nhất, và bỏ qua câu thứ nhất là lý do rất nhiều hạng mục bị báo giá cao hơn mức cần thiết.

1. Nấc đầu tiên, và cũng là nấc bị bỏ qua nhiều nhất, là dùng lại một tính năng đã có sẵn kể cả khi nó đang phục vụ một việc hoàn toàn khác.
2. tiếp theo mới tới cấu hình, tức bật tắt tính năng, dựng quy tắc, khai báo bảng giá, đặt ngưỡng và phân quyền.
3. sau đó là tùy biến bằng công cụ kéo thả, không cần lập trình.
4. và cuối cùng, chỉ khi cả ba nấc trên đều không giải quyết được, mới tới lập trình hoặc tích hợp với bên thứ ba.

Ranh giới giữa ba nấc dưới là một chủ đề riêng đủ dài nên tôi để ở bài về cấu hình và customize, còn ở đây bạn chỉ cần nhớ rằng chúng là ba nấc chứ không phải hai, bởi gộp ba thành hai chính là lý do rất nhiều hạng mục bị đẩy thẳng xuống nấc đắt nhất mà không ai kiểm tra lại xem nấc giữa có làm được không.

Cần lưu ý một điều kiện quan trọng ở nấc thứ ba: công cụ kéo thả của Odoo thuộc bản Enterprise. Nếu khách hàng của bạn đang dùng bản Community thì thang này chỉ còn ba nấc thật, và mọi thứ không giải được bằng cấu hình đều rơi thẳng xuống nấc lập trình. Đây là chi tiết phải làm rõ ngay từ đầu dự án chứ không phải lúc báo giá.

Nấc bị bỏ qua nhiều nhất

Lấy một yêu cầu thật để thấy nấc thứ nhất trông như thế nào.

User muốn theo dõi được các bản báo giá mà nhà cung cấp gửi tới, để khi cần thì mở ra đối chiếu xem đơn hàng đã đặt có đúng giá đã chào hay không. Nghe qua thì đây là một chỗ lưu trữ mới, và người mới thường nghĩ tới việc thêm một đối tượng dữ liệu quản lý báo giá nhà cung cấp kèm màn hình riêng.

Tuy nhiên, nếu bạn bóc tách yêu cầu thành các đặc tính thay vì đọc theo tên gọi thì bức tranh đổi hẳn. Cái khách cần là một tệp gắn với đúng một đơn mua hàng, mở ra xem được, và không cần tìm kiếm hay thống kê gì trên nội dung bên trong nó, đó đúng là mô tả của tính năng đính kèm tệp trong chi tiết đơn mua hàng, thứ hệ thống đã có sẵn. Dòng GAP đó chuyển từ phải làm mới sang đáp ứng hoàn toàn, và cột giải pháp chỉ ghi dùng phần đính kèm trong đơn mua hàng, kèm quy ước đặt tên tệp để về sau tra ra được.

Một case tương tự nhưng ở quy mô lớn hơn là yêu cầu quản lý các đề nghị đặt hàng của đại lý, thứ hóa ra chính là tính năng báo giá đã có sẵn trong phân hệ Bán hàng.

Bên cạnh đó cần lưu ý một chuyện chung cho cả hai case: bạn phải nói rõ với khách rằng cái họ sẽ thấy trên màn hình mang tên gọi của hệ thống chứ không mang tên gọi trong nghiệp vụ của họ. Nếu bỏ qua câu đó thì tới buổi kiểm thử sẽ có người nói hệ thống làm sai, trong khi thực chất chỉ là chưa ai giải thích.

Nguyên nhân bỏ sót nấc thứ nhất

Lý do không phải là người viết tài liệu lười, mà nằm ở cách người ta học hệ thống.

Phần lớn người mới học Odoo theo tên tính năng: phân hệ này có báo giá, đơn hàng, hóa đơn; phân hệ kia có yêu cầu báo giá, đơn mua, phiếu nhập. Học như vậy thì khi gặp một yêu cầu mang tên lạ, não tự động kết luận là hệ thống không có, bởi trong danh sách tên mà bạn thuộc không có cái tên đó.

Cách nhìn dùng được hơn là bóc mỗi tính năng ra thành ba câu hỏi:

• nó lưu những dữ liệu gì
• nó có những trạng thái nào
• và khi chuyển trạng thái thì nó kéo theo kết quả ra sao

Trả lời được ba câu đó cho mươi tính năng cốt lõi thì bạn có một bộ khuôn, và mỗi yêu cầu mới chỉ còn là chuyện tìm khuôn nào vừa.

Đồng thời, đây cũng là lý do việc dựng thử trên hệ thống quan trọng tới vậy.

Bạn không nhớ ra được một tính năng mình chưa từng mở ra xem, và bạn cũng không thể chế biến một tính năng mà mình chỉ biết tên.

Review nội bộ trước khi mang ra khỏi cửa

Sau khi có phương án cho từng dòng thì tài liệu chưa được gửi cho khách, mà phải qua một buổi review nội bộ với đủ đội triển khai và đặc biệt là tech lead; ba tiêu chí của buổi này thì tôi đã nói ở bài Fit-Gap.

Điều đáng nói thêm ở đây là phần vận hành. Giá trị lớn nhất của buổi review không phải là bắt lỗi tài liệu mà là bắt những phương án mà chỉ người viết code mới biết là đắt, bởi có những yêu cầu nghe rất nhỏ trong ngôn ngữ nghiệp vụ nhưng lại đụng vào một chỗ mà hệ thống đang tính toán tự động, và người duy nhất phát hiện ra điều đó trước khi báo giá là tech lead.

Vì vậy hãy đưa cho họ đúng thứ họ cần để phản biện, tức là kịch bản nghiệp vụ và đặc tính dữ liệu, chứ không phải một câu mô tả tính năng.

• Câu "khách muốn hệ thống tự tính hoa hồng cho nhân viên bán hàng" thì không phản biện được.
• Câu "hoa hồng tính trên doanh thu đã thu tiền, theo bậc lũy tiến, và phải tính lại khi có hóa đơn điều chỉnh" thì phản biện được ngay.

Và câu thứ hai thường làm đội kỹ thuật đổi hẳn ước lượng.

Chuyển sang giá trước khi gặp khách

Đây là bước hay bị quên nhất trong cả chuỗi, và hậu quả của nó thì luôn xảy ra giữa buổi họp với khách.

Trong số các phương án bạn đề xuất, sẽ có phương án cần custom hoặc vượt ra ngoài phạm vi đã ký. Những phương án đó phải được chuyển cho đội sale trước buổi họp, để họ ra được phương án giá cụ thể cho từng cái.

Nếu bỏ bước này thì kịch bản diễn ra như sau. Khách nghe hai phương án, thấy phương án thứ hai hợp lý hơn, hỏi vậy thêm bao nhiêu tiền, và bạn không trả lời được; buổi họp dừng ở đó, phải chờ báo giá, và tới lúc có giá thì khách đã nguội và bạn phải trình bày lại từ đầu.

Đặc biệt, cần lưu ý rằng con số bạn cần không nhất thiết là một báo giá chính thức. Một khoảng ước lượng đã được sale đồng ý cũng đủ để khách ra quyết định trong buổi, và đó là điều bạn cần.

Dựng hệ thống demo

Tài liệu gửi đi rồi thì tổ chức một buổi demo giải pháp, và giá trị của buổi đó phụ thuộc gần như hoàn toàn vào việc hệ thống demo được dựng tới mức nào.

Đây là checklist tôi vẫn dùng:

• Chuẩn bị một database mới hoàn toàn
• Cài đặt module và addon cần dùng
• Bật tắt tính năng ở từng phân hệ theo đúng phương án đề xuất
• Chuẩn bị dữ liệu chủ mẫu và import lên hệ thống
• Tạo transaction data và các báo cáo
• Cấu hình biểu mẫu và mẫu in theo yêu cầu thực tế
• Cấu hình dashboard
• Tạo sẵn các bộ lọc yêu thích và các mẫu xuất dữ liệu
• Tạo người dùng và phân quyền

Điểm đáng nói nhất trong danh sách là dòng đầu tiên. Database phải mới hoàn toàn, không dùng lại môi trường bạn đang thử nghiệm, bởi môi trường thử nghiệm luôn còn sót cấu hình từ các lần thử trước và luôn còn dữ liệu rác; giữa buổi demo mà hiện ra một sản phẩm tên là "test 3" thì toàn bộ ấn tượng về sự chỉn chu biến mất.

Hai dòng gần cuối cũng đáng chú ý vì chúng hay bị bỏ. Khách xem demo bằng con mắt của người sẽ dùng, nên họ để ý mẫu in đã có logo của họ chưa và màn hình của kế toán có nhìn thấy giá vốn không; những chi tiết đó không liên quan gì tới giải pháp nhưng lại quyết định mức độ tin tưởng trong buổi. Khi việc cần chốt chỉ là một màn hình giao diện chứ chưa tới mức dựng nguyên buổi demo giải pháp, có một kỹ thuật gọn hơn dựa trên cùng nguyên tắc dựng trên hệ thống thật, và nó là chủ đề của một bài riêng.

Chạy thử trước buổi demo

Sau khi dựng xong thì mô phỏng lại buổi demo một lượt trên chính hệ thống vừa dựng.

Việc này phục vụ hai mục đích khác nhau. Mục đích dễ thấy là phát hiện lỗi hệ thống và những tình huống bạn không lường trước, mà loại này thì luôn có; phát hiện trước buổi thì bạn còn sửa được, phát hiện trong buổi thì bạn chỉ còn cách xin phép kiểm tra lại.

Mục đích còn lại ít người nói ra nhưng quan trọng không kém, đó là tập trình bày. Trình tự bạn bấm trên màn hình chính là trình tự khách hiểu về giải pháp, nên nếu bạn nhảy qua nhảy lại giữa các phân hệ thì dù giải pháp có đúng, người xem vẫn thấy nó rối và phức tạp.

Chốt giải pháp ngay trong buổi

Tới phần cuối, và cũng là phần quyết định xem cả chuỗi trên có thành gì hay không.

Trước tiên, mỗi phương án phải nói được đánh đổi bằng đúng một câu, không phải một đoạn phân tích, mà một câu mà người nghe nhắc lại được cho sếp của họ, chẳng hạn phương án đầu thì làm nhanh và không tốn thêm chi phí nhưng hệ thống không chặn được người dùng làm sai, còn phương án kia thì chặt chẽ nhưng thêm thời gian và thêm chi phí; khi cả hai vế nằm trong một câu thì người nghe có thể dễ dàng cân nhắc.

Bên cạnh đó, hãy hỏi thẳng ai là người quyết cho yêu cầu này, bởi rất nhiều buổi họp không chốt được không phải vì khách phân vân mà vì người có thẩm quyền không có mặt, và bạn chỉ phát hiện ra điều đó nếu bạn hỏi.

Và đặc biệt, hãy ghi lại lựa chọn ngay tại chỗ vào chính tài liệu GAP, thêm một cột hoặc một dòng ghi phương án được chọn cùng ngày chọn, rồi sau buổi thì gửi email xác nhận kèm thời hạn phản hồi; nếu tới hạn không ai phản hồi thì lựa chọn ghi trong biên bản được coi là đã chốt, và điều này phải được nói ra trong email chứ không phải tự hiểu.

Với những dòng mà khách vẫn chưa quyết được sau buổi thì đừng để trống. Hãy ghi rõ dòng này đang chờ ai quyết và chờ tới bao giờ.

Bởi một dòng ghi là đang chờ thì có người theo, còn một ô trống thì không.

Chuỗi này nghe dài nhưng phần lớn công sức của nó nằm ở nấc đầu tiên, tức việc tìm cho ra phương án rẻ nhất mà vẫn đáp ứng. Và chuyện đó thì không có cách nào khác ngoài việc hiểu hệ thống đủ sâu, tới mức nhìn một bài toán nghiệp vụ là thấy được nó ánh xạ vào mô hình dữ liệu nào, như bài toán hàng đang trên đường giữa hai kho, thứ trông như phải lập trình mà thực ra giải được bằng cấu hình.