Tầm quan trọng của Diagram - trao đổi bằng tin nhắn không đủ để quản lý sự phức tạp của phần mềm.

Bài học thực chiến: Khi trao đổi bằng tin nhắn không đủ để quản lý sự phức tạp của phần mềm

Tôi từng làm việc với PO trong một quy trình mà phần lớn công việc được trao đổi qua Zalo. Các yêu cầu được thảo luận, làm rõ và xác nhận bằng tin nhắn văn bản. Sau đó, đội ngũ phát triển dựa trên những nội dung đã thống nhất để triển khai tính năng.

Ở thời điểm ban đầu, cách làm này có vẻ nhanh chóng và linh hoạt. Mọi người có thể trao đổi trực tiếp, phản hồi nhanh và không mất nhiều thời gian chuẩn bị tài liệu.

Nhưng vấn đề bắt đầu xuất hiện khi dự án đi qua nhiều sprint.

Sau một sprint, một số tính năng được triển khai đã lệch khỏi kỳ vọng ban đầu. Có những yêu cầu mà người thực hiện hiểu theo một cách, trong khi PO hoặc người dùng lại hình dung theo cách khác. Một số quy tắc nghiệp vụ chưa được làm rõ đầy đủ; một số luồng xử lý và trường hợp ngoại lệ chỉ được phát hiện khi tính năng đã hoàn thành.

Hệ quả là đội ngũ phải quay lại sửa thiết kế, thay đổi logic và viết lại một phần code đã triển khai.

Điều đáng nói là những yêu cầu ấy không hoàn toàn chưa từng được trao đổi. Chúng đã được đề cập và xác nhận bằng văn bản. Nhưng việc có lịch sử trao đổi không đồng nghĩa với việc tất cả các bên đã hiểu giống nhau về giải pháp cần xây dựng.

Đó là một bài học khiến tôi suy ngẫm nhiều về cách chúng ta phân tích và quản lý dự án phần mềm.

Trao đổi giúp chúng ta truyền đạt thông tin. Nhưng để đảm bảo các bên thực sự hiểu cùng một giải pháp, đôi khi chúng ta cần một mô hình trực quan thay vì chỉ có những dòng tin nhắn.

Một Activity Diagram có thể làm rõ luồng nghiệp vụ. Một State Diagram có thể xác định những trạng thái hợp lệ và điều kiện chuyển trạng thái. Một Sequence Diagram có thể thể hiện cách các thành phần tương tác. Thậm chí, với một tính năng đơn giản, chỉ cần một sơ đồ luồng ngắn kết hợp với vài tiêu chí nghiệm thu rõ ràng cũng đã có thể hạn chế nhiều cách hiểu khác nhau.

Điều quan trọng không phải là biến mọi cuộc trao đổi thành một bộ tài liệu kỹ thuật. Điều quan trọng là xác định những điểm mơ hồ có khả năng gây ra sai lệch lớn, sau đó lựa chọn cách mô tả phù hợp để loại bỏ chúng.

Từ trải nghiệm đó, tôi nhận ra rằng một phần chi phí phát triển phần mềm không đến từ việc viết code quá khó, mà đến từ việc hiện thực hóa một cách hiểu chưa chính xác về bài toán.

Khi sai lệch được phát hiện sớm trong giai đoạn phân tích, việc điều chỉnh thường đơn giản hơn nhiều so với khi nó đã lan vào cấu trúc dữ liệu, API, giao diện và các luồng xử lý liên quan.

Không phải dự án nào cũng cần áp dụng Diagram ở cùng một mức độ

Tuy nhiên, từ kinh nghiệm trên, tôi không cho rằng mọi dự án đều phải xây dựng đầy đủ Diagram trước khi lập trình.

Đây là điểm cần nhìn nhận dưới góc độ quản lý dự án, thay vì chỉ từ góc độ kỹ thuật.

Với một website giới thiệu doanh nghiệp, một ứng dụng nhỏ hoặc một hệ thống CRUD có phạm vi rõ ràng, việc dành quá nhiều thời gian để xây dựng tài liệu, vẽ nhiều loại sơ đồ và duy trì chúng có thể làm giảm tốc độ phát hành sản phẩm.

Nếu một tính năng có thể được hiểu rõ bằng vài dòng mô tả, một bản phác thảo giao diện và một số tiêu chí nghiệm thu cụ thể, việc bổ sung nhiều lớp tài liệu không nhất thiết tạo ra giá trị tương xứng.

Trong những trường hợp này, điều cần thiết là mô hình hóa vừa đủ để giảm sự mơ hồ, đồng thời giữ được tốc độ triển khai và khả năng nhận phản hồi từ người dùng.

Ngược lại, khi dự án có nhiều phân hệ, nhiều vai trò, nhiều quy trình nghiệp vụ, nhiều tích hợp và các thành phần phụ thuộc lẫn nhau, mức độ phức tạp tăng lên đáng kể.

Một thay đổi nhỏ ở một phân hệ có thể ảnh hưởng đến dữ liệu, API hoặc luồng xử lý của nhiều phân hệ khác. Khi số lượng tính năng và thành viên tham gia tăng lên, việc chỉ dựa vào trí nhớ, tin nhắn và trao đổi trực tiếp trở nên ngày càng rủi ro.

Ở quy mô này, Diagram không còn đơn thuần là công cụ hỗ trợ một lập trình viên. Nó trở thành phương tiện để tổ chức chia sẻ cách hiểu về hệ thống, kiểm soát những mối quan hệ phức tạp và đánh giá tác động của các thay đổi.

Dự án càng phức tạp, chi phí của việc không mô hình hóa càng có thể lớn hơn chi phí mô hình hóa.

Vì vậy, tôi nhìn nhận việc sử dụng Diagram như một quyết định đầu tư: đầu tư thời gian ở giai đoạn phù hợp để giảm nguy cơ làm lại, giảm chi phí phối hợp và tăng khả năng kiểm soát hệ thống về sau.

Diagram dưới góc nhìn quản lý dự án: Bài toán của ba ràng buộc

Trong quản lý dự án, một mô hình kinh điển thường được nhắc đến là bộ ba ràng buộc: thời gian, chi phí và phạm vi. Chất lượng là mục tiêu phải được bảo đảm trong cách chúng ta cân bằng các ràng buộc này.

Ba yếu tố có mối quan hệ chặt chẽ với nhau. Khi một yếu tố thay đổi, những yếu tố còn lại hoặc chất lượng thực hiện có thể chịu ảnh hưởng.

Chẳng hạn, nếu đội ngũ bổ sung nhiều hoạt động phân tích và thiết kế vào một dự án có thời hạn phát hành cố định, thời gian dành cho những hoạt động đó phải được tính vào kế hoạch. Nếu không thể kéo dài thời hạn, dự án có thể cần điều chỉnh phạm vi, bổ sung nguồn lực phù hợp hoặc chấp nhận những đánh đổi về cách thức triển khai.

Ngược lại, nếu bỏ qua phân tích và thiết kế để phát hành sớm, dự án có thể tiết kiệm thời gian ban đầu nhưng phải trả giá bằng việc sửa lỗi, làm lại tính năng hoặc xử lý các vấn đề kiến trúc về sau.

Điều này không có nghĩa là cứ dành nhiều thời gian cho Diagram thì dự án sẽ tốt hơn. Phân tích quá mức cũng có thể gây lãng phí. Vấn đề thực sự nằm ở việc lựa chọn mức độ đầu tư phù hợp với rủi ro và giá trị mà hoạt động đó mang lại.

Một người quản lý dự án không chỉ hỏi: “Chúng ta có cần vẽ Diagram không?”

Câu hỏi quan trọng hơn là:

• Phần nào của hệ thống có độ phức tạp cao nhất?
• Nếu hiểu sai yêu cầu ở phần này, chi phí làm lại sẽ lớn đến đâu?
• Những quyết định nào cần được thống nhất trước khi phát triển?
• Cần mô hình hóa ở mức nào để giảm rủi ro mà không làm chậm tiến độ một cách không cần thiết?
• Làm thế nào để giữ cho tài liệu có giá trị trong suốt vòng đời dự án?

Khi đặt những câu hỏi này, Diagram trở thành một phần của chiến lược quản lý rủi ro và nguồn lực, chứ không còn là một công việc tài liệu hóa đơn thuần.

Với hệ thống lớn, tư duy mô hình hóa phải trở thành năng lực của cả tổ chức

Ở một dự án nhỏ, một lập trình viên có thể nắm được gần như toàn bộ hệ thống. Việc trao đổi trực tiếp và ghi nhớ các quyết định đôi khi vẫn đủ để duy trì tốc độ phát triển.

Nhưng khi hệ thống mở rộng, số lượng tính năng tăng lên và nhiều người cùng tham gia, cách làm đó khó duy trì một cách ổn định.

Không một cá nhân nào có thể dựa mãi vào trí nhớ để quản lý tất cả quy tắc nghiệp vụ, quan hệ dữ liệu, phụ thuộc giữa các phân hệ và quyết định kiến trúc của một hệ thống lớn.

Lúc này, Diagram đóng vai trò như một phần của tri thức tổ chức.

Nó giúp thành viên mới hiểu cấu trúc hệ thống nhanh hơn, giúp các nhóm phối hợp trên cùng một mô hình và giúp người phụ trách kỹ thuật đánh giá ảnh hưởng của thay đổi trước khi triển khai.

Quan trọng hơn, các mô hình được thống nhất tạo ra một cơ sở tham chiếu chung. Khi có bất đồng, đội ngũ có thể quay lại kiểm tra quy trình, trạng thái, mối quan hệ dữ liệu hoặc quyết định thiết kế đã được xác nhận, thay vì phụ thuộc hoàn toàn vào những cuộc trao đổi rời rạc.

Tất nhiên, không phải mọi quyết định đều cần một Diagram riêng. Tài liệu chỉ có giá trị khi phản ánh đúng những quyết định quan trọng và được cập nhật khi hệ thống thay đổi.

Đối với hệ thống lớn, tôi cho rằng việc mô hình hóa cần được xem là một năng lực thiết yếu của đội ngũ phát triển. Không nhất thiết mọi thành viên đều phải vẽ những sơ đồ phức tạp, nhưng họ cần hiểu các mô hình liên quan đến phần việc của mình và biết cách sử dụng chúng để giao tiếp, triển khai và kiểm soát thay đổi.

Kết luận: Mô hình hóa vừa đủ, nhưng phải có tư duy hệ thống

Sau những trải nghiệm thực tế, tôi không nhìn Diagram đơn thuần như một kỹ năng kỹ thuật cần bổ sung vào bộ công cụ của lập trình viên.

Tôi nhìn nó như một cách để giảm khoảng cách giữa điều chúng ta nghĩ mình đang xây dựng và điều hệ thống thực sự cần phải làm.

Với dự án nhỏ, hãy ưu tiên tốc độ và chỉ mô hình hóa những phần cần thiết. Với dự án có nghiệp vụ phức tạp hoặc nhiều thành phần phụ thuộc lẫn nhau, hãy đầu tư nghiêm túc hơn vào phân tích, thiết kế và duy trì những mô hình quan trọng.

Với người làm Tech Lead hoặc quản lý dự án, thách thức không nằm ở việc yêu cầu đội ngũ vẽ thật nhiều Diagram. Thách thức nằm ở việc nhận diện đúng rủi ro, lựa chọn mức độ tài liệu hóa phù hợp và giúp mọi người cùng hiểu đúng hệ thống trước khi những hiểu lầm trở thành chi phí phát triển.

Làm phần mềm hiệu quả không phải là viết code càng nhanh càng tốt, cũng không phải tài liệu hóa càng nhiều càng tốt. Đó là khả năng đưa ra những quyết định đúng vào đúng thời điểm, với mức đầu tư phù hợp với độ phức tạp của bài toán.

Và với tôi, Diagram là một trong những công cụ quan trọng giúp biến tư duy đó thành thực tế.