Một phần mềm theo yêu cầu mất bao lâu để hoàn thành? Nếu chưa biết doanh nghiệp muốn xây gì, gần như không thể đưa ra một con số có ý nghĩa.
Có những hệ thống sau hai hoặc ba tháng đã có thể đưa vào vận hành. Cũng có những dự án kéo dài sáu tháng, một năm hoặc lâu hơn. Khoảng cách này không đơn thuần đến từ tốc độ lập trình. Một dự án ngắn thường có phạm vi tương đối rõ, tập trung vào một số quy trình chính và các quyết định được đưa ra nhanh. Dự án dài hơn có thể bao phủ nhiều phòng ban, xử lý nhiều logic nghiệp vụ, phải chuyển đổi dữ liệu cũ hoặc liên tục thay đổi trong quá trình triển khai.
Vì vậy, thay vì chỉ hỏi một công ty phần mềm “bao lâu thì xong?”, doanh nghiệp nên hiểu những yếu tố nào thực sự tạo nên khoảng thời gian đó.
Cùng là phần mềm quản lý nhưng khối lượng công việc có thể khác nhau rất xa
Tên gọi của phần mềm thường không nói lên được nhiều về thời gian phát triển. Hai doanh nghiệp cùng muốn xây một hệ thống quản lý bán hàng chẳng hạn, nhưng một bên chỉ cần quản lý khách hàng, đơn hàng và doanh số; bên còn lại có thêm bảng giá riêng cho từng nhóm khách hàng, nhiều cấp phê duyệt, chính sách chiết khấu, quản lý công nợ, kho và kết nối với hệ thống kế toán. Bề ngoài cùng là một loại phần mềm, nhưng lượng công việc phía sau hoàn toàn khác nhau.
Độ phức tạp cũng không thể đo bằng số màn hình. Một chức năng nhìn rất đơn giản có thể chứa nhiều quy tắc xử lý bên dưới. Một yêu cầu phê duyệt chỉ xuất hiện trên giao diện dưới dạng vài nút bấm, nhưng hệ thống có thể phải xác định người gửi là ai, giá trị bao nhiêu, thuộc bộ phận nào, cần qua mấy cấp, trường hợp nào được bỏ qua một cấp và sau khi duyệt thì dữ liệu nào được phép thay đổi. Khi những quy tắc này tăng lên, thời gian phân tích, xây dựng và kiểm tra cũng tăng theo.
Các phần việc ít nhìn thấy như phân quyền, lịch sử thay đổi, nhập dữ liệu cũ, xử lý trường hợp ngoại lệ hay kết nối với hệ thống khác thường chiếm một lượng thời gian đáng kể. Vì thế một dự án có mười màn hình chưa chắc nhỏ hơn dự án có hai mươi màn hình.
Muốn ước tính tiến độ tương đối chính xác, trước tiên phải biết doanh nghiệp đang cần giải quyết những quy trình nào và mức độ xử lý sâu đến đâu. Nếu yêu cầu mới chỉ dừng ở câu “tôi muốn một phần mềm quản lý công ty”, bất kỳ thời hạn cụ thể nào được đưa ra lúc đó cũng chỉ mang tính phỏng đoán.
Phần mềm càng được làm rõ trước khi xây, càng ít phải quay lại sửa
Thời gian của một dự án không chỉ nằm ở phần việc phải làm, mà còn nằm ở số lần phải làm lại.
Nếu quy trình chưa rõ nhưng đội phát triển đã bắt đầu xây dựng, những thay đổi về sau rất dễ đụng vào phần đã hoàn thành. Ban đầu doanh nghiệp xác định đơn hàng chỉ cần trưởng bộ phận duyệt. Sau khi làm xong mới phát hiện một số trường hợp phải qua giám đốc, một số trường hợp kế toán cần kiểm tra trước, còn đơn hàng dưới một hạn mức nhất định thì không cần duyệt. Đây không còn là việc thêm một nút bấm mà có thể phải chỉnh lại cả luồng xử lý, quyền hạn và cấu trúc dữ liệu liên quan.
Bởi vậy, giai đoạn thiết kế có giá trị ở chỗ loại bỏ càng nhiều sự mơ hồ càng tốt trước khi khối lượng lập trình trở nên lớn. Quy trình chính cần được nhìn rõ, dữ liệu cần lưu phải được xác định, quyền của từng nhóm người dùng phải tương đối thống nhất và doanh nghiệp phải biết phiên bản đầu tiên sẽ dừng ở đâu.
Điều này không có nghĩa phải ngồi viết tài liệu trong nhiều tháng rồi mới bắt đầu. Với nhiều dự án, một bản mô phỏng giao diện và luồng xử lý cụ thể giúp doanh nghiệp nhìn ra vấn đề nhanh hơn rất nhiều so với việc chỉ mô tả bằng lời. Những điểm chưa hợp lý được sửa ở giai đoạn này thường rẻ và nhanh hơn nhiều so với sửa sau khi toàn bộ chức năng đã được xây dựng.
Một vấn đề khác là phạm vi công việc dễ phình ra trong quá trình triển khai. Những yêu cầu như “thêm giúp một trường này”, “tiện làm luôn phần kia” hay “bộ phận này muốn thêm một bước nữa” riêng lẻ đều có vẻ nhỏ. Nhưng nếu chúng xuất hiện liên tục trong vài tháng, dự án cuối cùng có thể khác rất xa so với thứ hai bên đã ước tính ban đầu.
Doanh nghiệp vẫn có thể thay đổi yêu cầu. Phần mềm theo yêu cầu vốn được xây để phù hợp với hoạt động thực tế. Nhưng cần tách rõ đâu là phần phải hoàn thành trong giai đoạn hiện tại và đâu là yêu cầu mới có thể triển khai ở giai đoạn tiếp theo. Nếu mọi ý tưởng mới đều được đưa ngay vào một phiên bản đang làm, rất khó giữ được bất kỳ mốc thời gian nào.
Bản chạy thử thường làm lộ ra những vấn đề mà tài liệu không thể hiện được
Ngay cả khi yêu cầu ban đầu đã khá rõ, lần đầu người dùng thực sự thao tác trên phần mềm vẫn thường xuất hiện những điều cần điều chỉnh.
Trên bản thiết kế, một quy trình có thể hoàn toàn hợp lý. Nhưng khi nhân viên phải thực hiện nó hàng chục lần mỗi ngày, một bước nhập liệu thừa bắt đầu trở nên khó chịu. Có trường thông tin tưởng là bắt buộc nhưng thực tế nhiều trường hợp không có dữ liệu để nhập. Một nút chức năng đặt đúng về mặt thiết kế nhưng lại nằm sai vị trí so với thói quen làm việc. Cũng có những tình huống nghiệp vụ chỉ khi đưa dữ liệu thật vào mới phát hiện trước đó chưa ai nghĩ tới.
Đó là lý do một sản phẩm dùng thật trong doanh nghiệp gần như luôn cần một giai đoạn chạy thử và tinh chỉnh. Việc có phản hồi không phải vấn đề. Phần đáng quan tâm là mất bao lâu để một phản hồi trở thành một phiên bản đã được chỉnh sửa.
Giả sử người dùng phát hiện năm điểm cần thay đổi vào thứ Hai. Nếu người phụ trách xác nhận ngay, đội phát triển xử lý trong vài ngày và người dùng được kiểm tra lại trong tuần đó, dự án vẫn tiến lên rất nhanh. Nhưng cùng năm yêu cầu đó nếu phải chờ tổng hợp, chờ họp, chuyển qua nhiều cấp rồi mới được đưa vào lịch xử lý thì một vòng chỉnh sửa có thể kéo dài hai hoặc ba tuần.
Sau vài vòng như vậy, một dự án vốn chỉ có vài tuần công việc thực tế có thể kéo dài thêm vài tháng.
Đây cũng là lý do tốc độ phản hồi ngày càng quan trọng trong triển khai phần mềm. Công cụ phát triển có thể nhanh hơn, nhiều công việc kỹ thuật có thể được tự động hóa hơn, nhưng nếu khoảng thời gian giữa lúc người dùng phát hiện vấn đề và lúc hệ thống được cập nhật vẫn quá dài thì toàn bộ dự án vẫn chậm.
Không nhất thiết phải hoàn thành toàn bộ hệ thống rồi mới đưa vào sử dụng
Một phần mềm quản lý toàn doanh nghiệp có thể mất nhiều tháng để hoàn thiện. Nhưng điều đó không đồng nghĩa doanh nghiệp phải chờ đến tháng cuối cùng mới có thứ để dùng.
Nếu phạm vi lớn, có thể tách hệ thống thành những phần có giá trị vận hành độc lập. Quy trình đang gây nhiều vấn đề nhất được xử lý trước. Những chức năng cần thiết để quy trình đó hoạt động được xây hoàn chỉnh, đưa cho người dùng thực tế, sau đó mới tiếp tục mở rộng sang phần tiếp theo.
Giả sử một hệ thống đầy đủ cần sáu tháng. Cách triển khai thứ nhất là làm tất cả trong sáu tháng rồi bàn giao một lần. Cách thứ hai là sau hai tháng đã có một phần cốt lõi được đưa vào sử dụng, tháng thứ ba và thứ tư mở rộng thêm các quy trình liên quan, những phần còn lại tiếp tục hoàn thiện sau đó. Tổng khối lượng có thể không khác nhiều, nhưng thời điểm doanh nghiệp bắt đầu nhận được giá trị từ dự án khác nhau rất lớn.
Việc đưa từng phần vào sử dụng sớm còn tạo ra một lợi ích khác: những quyết định sau đó được dựa trên trải nghiệm thực tế thay vì hoàn toàn dựa trên giả định. Sau một thời gian sử dụng, doanh nghiệp sẽ biết chức năng nào thực sự cần mở rộng, điều gì ban đầu tưởng quan trọng nhưng thực tế ít dùng, và phần nào cần thiết kế khác đi.
Một dự án hai hoặc ba tháng vì vậy không nhất thiết có nghĩa toàn bộ hệ thống của doanh nghiệp đã được số hóa trong hai hoặc ba tháng. Trong nhiều trường hợp, đó là khoảng thời gian để xây một phiên bản đủ hoàn chỉnh cho những quy trình quan trọng nhất và bắt đầu vận hành thật. Hệ thống sau đó tiếp tục được mở rộng theo nhu cầu.
Có những khoảng thời gian đội phát triển gần như không thể tự rút ngắn
Phần mềm theo yêu cầu không được xây trong môi trường tách biệt. Nó phụ thuộc trực tiếp vào cách doanh nghiệp đang vận hành, nên nhiều quyết định chỉ phía doanh nghiệp mới có thể đưa ra.
Nếu phòng kinh doanh và kế toán chưa thống nhất cách tính một khoản chiết khấu, đội phần mềm không thể tự chọn một công thức. Nếu hai bộ phận đang hiểu một trạng thái đơn hàng theo hai cách khác nhau, vấn đề đó phải được giải quyết trước khi đưa vào hệ thống. Nếu cần chuyển dữ liệu cũ nhưng dữ liệu chưa được chuẩn hóa, việc phát triển phần mềm xong sớm cũng không giúp hệ thống sẵn sàng để sử dụng.
Thời gian chờ những quyết định như vậy có thể lớn hơn nhiều so với thời gian lập trình. Một bản thiết kế cần ba ngày để điều chỉnh nhưng chờ hai tuần mới có người xác nhận. Một kết nối với hệ thống cũ chỉ cần vài ngày phát triển nhưng mất một tháng để được cấp thông tin kỹ thuật. Một phiên bản đã sẵn sàng để chạy thử nhưng nhóm người dùng chính quá bận nên ba tuần sau mới bắt đầu kiểm tra.
Khi lập kế hoạch, các khoảng chờ này thường bị đánh giá thấp vì chúng không xuất hiện trong danh sách chức năng của phần mềm. Nhưng khi dự án bắt đầu, chúng lại tác động trực tiếp đến ngày hoàn thành.
Bởi vậy, một dự án chạy nhanh thường không chỉ có đội kỹ thuật làm nhanh. Phía doanh nghiệp cũng có một người đủ hiểu nghiệp vụ, đủ quyền quyết định và đủ thời gian để xử lý những vấn đề cần xác nhận trong quá trình triển khai.
Vậy xây phần mềm theo yêu cầu trong 2–3 tháng có thực tế không?
Có, nếu nói đúng phạm vi.
Hai đến ba tháng là khoảng thời gian hoàn toàn khả thi để xây và đưa vào vận hành một hệ thống có phạm vi vừa phải, tập trung vào những quy trình chính, không có quá nhiều kết nối phức tạp và được hai bên phối hợp chặt trong quá trình thiết kế, chạy thử và điều chỉnh.
Một hệ thống lớn hơn có thể cần sáu tháng hoặc lâu hơn. Nếu phải xử lý nhiều phòng ban, nhiều loại dữ liệu, chuyển đổi một hệ thống cũ hoặc tích hợp với nhiều nền tảng đang sử dụng, việc cần thêm thời gian là hợp lý. Thời hạn dài tự nó không phải dấu hiệu của một dự án kém.
Điều cần cảnh giác là một dự án kéo dài nhưng không ai còn biết chính xác đang chờ điều gì, phạm vi thay đổi liên tục hoặc nhiều tháng trôi qua mà doanh nghiệp vẫn chưa có phần nào đủ hoàn chỉnh để sử dụng.
Thời gian triển khai phần mềm vì thế nên được nhìn cùng với phạm vi và cách tổ chức dự án. Làm nhanh không phải mục tiêu duy nhất. Một dự án được kiểm soát tốt phải giúp doanh nghiệp nhìn thấy rõ mình đang xây gì, phần nào đã hoàn thành, phần nào đang được kiểm chứng và khi nào một phiên bản có thể bắt đầu tạo ra giá trị trong vận hành.