Có. Doanh nghiệp không cần chuẩn bị sẵn một bộ tài liệu yêu cầu chi tiết mới có thể bắt đầu làm phần mềm theo yêu cầu. Trong thực tế, nhiều chủ doanh nghiệp chỉ biết công ty mình đang vướng ở đâu: sales khó theo dõi khách hàng, báo giá qua nhiều vòng nhưng không kiểm soát được phiên bản, kỹ thuật và kinh doanh phải nhập lại dữ liệu, quản lý không nhìn được tiến độ hoặc một số công việc phụ thuộc quá nhiều vào một vài người. Những vấn đề như vậy đã đủ để bắt đầu trao đổi. Việc chuyển chúng thành chức năng, quy trình và thiết kế phần mềm là phần việc mà đơn vị phát triển phải cùng doanh nghiệp làm rõ.
Doanh nghiệp cần hiểu vấn đề của mình, không cần biết viết requirement
Chủ doanh nghiệp hiểu cách công ty kiếm tiền, cách nhân viên làm việc và những điểm đang gây mất thời gian hoặc khó kiểm soát. Họ không nhất thiết phải biết hệ thống nên có bao nhiêu module, database phải tổ chức thế nào hay màn hình cần những trường dữ liệu gì. Nếu một đơn vị phát triển yêu cầu khách hàng phải tự nghĩ ra gần như toàn bộ phần mềm rồi mới nhận làm, phần lớn công việc khó nhất đã bị đẩy ngược về phía khách hàng. Với SYP, điểm bắt đầu phù hợp hơn là để doanh nghiệp mô tả cách mình đang vận hành và những vấn đề muốn giải quyết, sau đó hai bên cùng chuyển chúng thành yêu cầu cụ thể.
Ví dụ, chủ doanh nghiệp có thể nói rằng mình không biết một cơ hội bán hàng đang nằm ở đâu, ai đang xử lý và vì sao một báo giá chưa gửi được cho khách. Từ một câu hỏi vận hành như vậy, SYP mới đi sâu hơn: cơ hội bán hàng hiện đi qua những bước nào, mỗi bước do ai phụ trách, khi nào phải chuyển cho kỹ thuật, báo giá cần ai duyệt, mức chiết khấu nào sales được tự quyết và thông tin nào quản lý cần nhìn thấy. Khi những điểm này đã rõ, chức năng phần mềm mới bắt đầu hình thành. Phần mềm vì vậy đi ra từ quy trình thực tế chứ không phải từ một danh sách tính năng được nghĩ ra trước.
Khảo sát quy trình giúp tìm đúng thứ cần đưa vào phần mềm
Không phải tất cả những gì doanh nghiệp đang làm đều nên được đưa nguyên vào hệ thống. Có những bước tồn tại chỉ vì trước đây dữ liệu nằm rời rạc hoặc các bộ phận chưa có cách làm việc tốt hơn. Nếu chỉ hỏi khách hàng đang làm gì rồi số hóa nguyên trạng, phần mềm mới có thể chỉ biến một quy trình chưa tốt thành một quy trình chưa tốt chạy trên máy tính.
Vì vậy, giai đoạn khảo sát quy trình cần làm rõ đâu là bước thực sự cần giữ, đâu là điểm cần kiểm soát chặt hơn và đâu là thao tác có thể bỏ bớt. Đây cũng là lúc SYP trao đổi với chủ doanh nghiệp về cách quy trình nên vận hành sau khi có hệ thống, thay vì chỉ ghi chép lại hiện trạng. Một vấn đề ban đầu tưởng là “cần thêm một màn hình theo dõi” đôi khi lại nằm ở chỗ trách nhiệm giữa hai bộ phận chưa rõ; một yêu cầu tưởng là “cần thêm nhiều báo cáo” có thể thực chất chỉ cần chuẩn hóa dữ liệu ngay từ đầu. Nếu tìm đúng vấn đề trước, hệ thống sẽ gọn hơn và dễ sử dụng hơn.
Không cần nghĩ ra toàn bộ hệ thống ngay từ đầu
Một sai lầm khá phổ biến là cố liệt kê tất cả chức năng doanh nghiệp có thể cần trong vài năm tới rồi đưa chúng vào phiên bản đầu tiên. Cách này khiến scope phình nhanh, chi phí tăng và thời gian triển khai kéo dài trong khi những phần quan trọng nhất vẫn chưa được đưa vào sử dụng. Với một hệ thống theo yêu cầu, điều cần xác định trước là những chức năng lõi nào phải có để giải quyết vấn đề hiện tại.
Một doanh nghiệp bán hàng dự án chẳng hạn có thể muốn sau này quản lý cả CRM, báo giá, kho, mua hàng, công việc kỹ thuật, bảo hành và dashboard. Nhưng phiên bản đầu có thể chỉ cần tập trung vào khách hàng, cơ hội bán hàng, pipeline, BOQ, báo giá và phê duyệt. Khi phần lõi đã chạy ổn, doanh nghiệp mới mở rộng tiếp những phần khác. Làm theo từng giai đoạn không có nghĩa là xây một hệ thống tạm bợ, mà là xác định rõ phần nào tạo ra giá trị trước để doanh nghiệp sớm đưa phần mềm vào vận hành.
Sau khi hiểu nghiệp vụ mới chuyển thành thiết kế phần mềm
Khi quy trình và các chức năng lõi đã đủ rõ, SYP mới chuyển chúng thành bản thiết kế chi tiết hơn. Lúc này mới xác định các nhóm người dùng, quyền hạn, dữ liệu cần quản lý, trạng thái của từng quy trình, các bước phê duyệt và mối liên hệ giữa các phần trong hệ thống. Đây là bước giúp biến những trao đổi về vận hành thành một mô hình mà cả khách hàng và đội phát triển đều có thể kiểm tra.
Bản thiết kế này quan trọng vì cùng một câu nói có thể được mỗi người hiểu theo một cách khác nhau. Chủ doanh nghiệp nói “tôi muốn quản lý báo giá”, sales có thể nghĩ đến việc tạo báo giá nhanh hơn, kỹ thuật lại quan tâm tới BOQ và model thiết bị, còn quản lý cần kiểm soát giá vốn và chiết khấu. Nếu những cách hiểu này không được làm rõ trước, đến khi phần mềm gần hoàn thành mới phát hiện thiếu thì việc sửa lại sẽ tốn nhiều thời gian hơn. Thiết kế trước giúp hai bên thống nhất mình đang xây gì trước khi bước vào phần phát triển chính.
Demo giúp khách hàng nhìn thấy thứ mình sắp làm
Sau bản thiết kế, SYP có thể dựng demo giao diện để khách hàng xem cách hệ thống dự kiến sẽ hoạt động. Đây là bước rất hữu ích với những doanh nghiệp chưa từng tự xây phần mềm vì nhìn một màn hình cụ thể luôn dễ góp ý hơn đọc một tài liệu kỹ thuật. Khi thấy pipeline thực tế, khách hàng có thể nhận ra thiếu một giai đoạn; khi xem màn hình báo giá, họ có thể thấy cần thêm một thông tin; khi nhìn luồng duyệt, chủ doanh nghiệp có thể quyết định bước nào thật sự cần mình tham gia và bước nào có thể giao cho cấp quản lý.
Những thay đổi ở giai đoạn demo thường rẻ và nhanh hơn nhiều so với sửa sau khi hệ thống đã được xây hoàn chỉnh. Vì vậy demo không chỉ dùng để xem giao diện đẹp hay chưa. Nó là cách để kiểm tra xem hai bên có đang hiểu giống nhau về hệ thống hay không. Sau vài vòng góp ý, phạm vi triển khai sẽ rõ hơn và khách hàng cũng biết khá chính xác mình sắp nhận được gì.
Scope nên được khóa sau khi hai bên đã hiểu tương đối rõ hệ thống
Khóa scope không có nghĩa là bắt khách hàng phải nghĩ ra mọi thứ ngay từ buổi đầu rồi cấm thay đổi. Nếu doanh nghiệp chưa từng làm phần mềm riêng, điều đó rất khó xảy ra. Cách hợp lý hơn là dành thời gian khảo sát, phân tích, thiết kế và xem demo trước. Khi các chức năng của phiên bản đầu đã đủ rõ, hai bên mới thống nhất phạm vi triển khai.
Từ thời điểm đó, nếu xuất hiện thêm một nhu cầu mới, hai bên có thể đánh giá nó có thực sự cần cho phiên bản hiện tại hay nên đưa sang giai đoạn tiếp theo. Cách làm này giữ cho dự án không bị kéo dài liên tục nhưng vẫn để phần mềm phát triển theo nhu cầu thực tế. Một hệ thống quản trị doanh nghiệp gần như chắc chắn sẽ thay đổi sau khi đưa vào sử dụng; điều quan trọng là biết thay đổi nào cần làm ngay và thay đổi nào có thể làm sau.
Nếu chưa hình dung được phần mềm, có thể xem case hoặc demo có sẵn
Một số khách hàng thậm chí chưa biết nên bắt đầu mô tả từ đâu. Trong trường hợp đó, SYP có thể dùng những case đã triển khai hoặc một bản demo có logic gần với mô hình của khách hàng để hai bên trao đổi nhanh hơn. Khi nhìn thấy một hệ thống thực tế, chủ doanh nghiệp thường dễ chỉ ra phần nào giống với cách công ty mình làm, phần nào không phù hợp và mình muốn thay đổi điều gì.
Case hoặc demo chỉ là điểm tham chiếu, không phải một bộ phần mềm có sẵn để áp nguyên cho doanh nghiệp khác. Hai công ty cùng ngành vẫn có thể có cách báo giá, phê duyệt, quản lý dự án hay phân quyền rất khác nhau. Giá trị của việc xem hệ thống mẫu nằm ở chỗ khách hàng không phải tưởng tượng mọi thứ từ con số không, còn đội triển khai cũng có thêm dữ liệu để hiểu nhanh hơn cách doanh nghiệp muốn vận hành.
Khách hàng không phải viết phần mềm nhưng vẫn phải tham gia vào dự án
Dù không cần có sẵn tài liệu yêu cầu, doanh nghiệp vẫn phải tham gia vào quá trình làm rõ hệ thống. Đơn vị phát triển không thể tự biết ai có quyền duyệt giá, lúc nào một dự án được coi là thắng, dữ liệu nào kỹ thuật cần nhận từ sales hay chủ doanh nghiệp muốn nhìn thấy thông tin gì để ra quyết định. Những kiến thức đó nằm trong chính doanh nghiệp và cần được người hiểu nghiệp vụ cung cấp.
Vai trò của SYP là đặt đúng câu hỏi, phân tích câu trả lời và chuyển chúng thành một hệ thống có cấu trúc. Vai trò của doanh nghiệp là cung cấp người hiểu quy trình, đưa ra quyết định ở những điểm quan trọng và phản hồi thiết kế trong thời gian hợp lý. Khi hai bên làm đúng phần việc của mình, doanh nghiệp không cần một bộ requirement dày hàng chục trang từ đầu mà vẫn có thể đi tới một hệ thống rõ ràng.
Từ bài toán quản trị đến bài toán phần mềm
Doanh nghiệp chưa có tài liệu yêu cầu vẫn có thể bắt đầu làm phần mềm theo yêu cầu. Điều cần có trước tiên không phải là danh sách chức năng, mà là một bài toán vận hành đủ rõ để hai bên cùng phân tích. Từ đó SYP khảo sát quy trình, xác định chức năng lõi, chuyển thành thiết kế, dựng demo để kiểm tra, điều chỉnh những điểm chưa phù hợp rồi mới khóa phạm vi triển khai.
Hiểu đơn giản, SYP không chỉ nhận một danh sách chức năng rồi viết phần mềm. SYP đi cùng khách hàng từ bài toán quản trị doanh nghiệp đến bài toán phần mềm. Doanh nghiệp hiểu mình đang vận hành như thế nào và muốn cải thiện điều gì; SYP có trách nhiệm biến những thông tin đó thành một hệ thống có thể triển khai và sử dụng thực tế.