So với các dự án công trình xây dựng, ngành phần mềm chịu rủi ro và tổn thất rất lớn nếu có sự biến động về nhân sự. Tuy nhiên phần mềm có lợi thể rất lớn về sự khả năng thích ứng với thay đổi linh hoạt, và do đó thuận lợi cho sức sáng tạo tối đa và khả năng xoay chuyển tình thế.

Trong nhiều năm, ngành công nghiệp phần mềm đã được xem là tương tự như một công trình xây dựng. Kết luận này dựa trên phép suy luận loại suy (analogy). Cách so sánh được áp dụng dựa trên toàn bộ ngôn ngữ thể hiện của phần mềm: kiến ​​trúc, nền tảng, triển khai dự án, cách thức khởi tạo, các dòng mẫ (code) dựng lên phần mềm tương tự như những viên gạch xây nên bức tường. Các thuật ngữ này có sức lan tỏa lớn đến mức nó tác động trực tiếp đến suy nghĩ của chúng ta về quy trình phát triển phần mềm. Nhưng tiếc là phép "ẩn dụ" như vậy về cơ bản không còn đúng và những sai sót đó đã khiến chúng ta đi vào lối mòn khi áp dụng quy trình xây dựng nhà ở vào quy trình xây dựng phần mềm.

Trong xây dựng, người ta chú trọng nhiều đến khả năng dự đoán, đưa ra các yêu cầu chính xác từ trước và giảm chi phí. Đây là những chỉ dấu của một ngành công nghiệp đã đạt mức độ "trưởng thành".  Khi chúng ta cố gắng áp dụng cùng các phương pháp đó trong phần mềm, các vấn đề mới sẽ nảy sinh.

So sánh nguyên vật liệu trong xây dựng với các dòng mã lập trình

Các công trình xây dựng hiện đại có xuất phát từ lịch sử hàng trăm hoặc hàng nghìn năm. Kết quả là, có rất nhiều kỹ thuật chuyên môn được hệ thống hóa theo các quy tắc chung:

• Trong hầu hết các khu vực mặt bằng, chi phí xây dựng trên mỗi mét vuông là một hằng số có thể được biết trước. Ví dụ, bạn thực hiện cải tạo và sửa chữa ngôi nhà đang ở. Nhờ tham khảo bạn bè, bạn biết được chi phí cải tạo rơi vào khoảng 1-1.5 triệu/m2. 
• Độ sâu của tấm sàn bê tông cũng hoàn toàn có thể dự tính được, bằng 1/180 chu vi.

Mặt khác, phần mềm là lĩnh vực chưa quá 70 tuổi tuổi từ khi được khai sinh. Các quy tắc trong lĩnh vực phần mềm không có cùng một lịch sử lâu đời như lĩnh vực xây dựng dân dụng.

Cuối cùng các quy tắc chung được hệ thống hóa và cố định dưới dạng các bộ mã cho lĩnh vực xây dựng, gọi là quy chuẩn xây dựng. Khi xây dựng nhà ở, quy chuẩn xây dựng xác định mọi thứ từ khoảng cách giữa các đinh tán trên tường, đến lượng vật liệu cách nhiệt trong tường và mái nhà. Các quy tắc này có nghĩa là tất cả các ngôi nhà đều đáp ứng một tiêu chuẩn tối thiểu và do đó các bản dự toán về chi phí xây dựng có độ chính xác rất cao.

Sở dĩ có những quy chuẩn xây dựng này vì có giới hạn bộ vật liệu xây dựng (gỗ, thép, v.v.) và công cụ (búa, cưa, v.v.). Các đặc tính của vật liệu và mức độ hỏng hóc, khấu hao của chúng có thể dự đoán được. Hơn nữa máy móc công cụ để xử lý các nguyên vật liệu được chuẩn bị sẵn từ trước và có thể được tái sử dụng nhiều lần. Trong tương lai, vật liệu và công cụ tiếp tục phát triển ở cấp độ cao hơn trong ngành xây dựng, nhưng không thể phát triển quá nhanh như tốc độ phát triển trong phần mềm.

Việc cập nhật danh sách các nguồn "vật liệu" và công cụ mới trong phần mềm khó hơn nhiều. Các nguồn vật liệu như: ngôn ngữ lập trình, thư viện và các công cụ hỗ trợ xuất hiện liên tục và phát triển rất mạnh mẽ mỗi năm. 

Ngay cả khi chúng ta chỉ bám vào các ngôn ngữ và thư viện hiện có của mình, có thể mất nhiều năm để khám phá tất cả các chi tiết, các tiện ích, sắc thái kiến trúc và cả những bí mật về kỹ thuật lập trình (bí mật các quả trứng phục sinh - easter egg). Bộ tiêu chuẩn ra đời một phần mềm có thể sẽ phụ thuộc vào mức độ chuyên gia trong phạm vi ngôn ngữ lập trình đó. Thí dụ nhóm dự án lập trình công nghệ .NET của Microsoft sẽ xây dựng cho mình bộ quy chuẩn để định giá sản phẩm phần mềm viết bằng công nghệ .NET chắc chắn sẽ tốt hơn nhóm chỉ biết về lập trình ngôn ngữ PHP.

Tương tự, nguồn nội dung cũng gia tăng. Ngày nay chúng ta không thể chỉ dựa vào nguồn dữ liệu "cây nhà lá vườn", mà chúng ta còn phải kết nối với các mạng xã hội như một nguồn cấp dữ liệu bên ngoài (tương tự như khi ta xây một đường ống nước từ chung cư hay căn hộ đến đường ồng chung của thành phố và từ đó tỏa đi đến các nhà máy nước lân cận). 

Trong lĩnh vực xây dựng, nhà thầu đã được trang bị đầy đủ các công cụ và vật liệu gần như ổn định, được tính toán rõ ràng giúp cho việc xây dựng các bộ quy chuẩn xây dựng có tính khả thi cao. Trong khi sự bất ổn của ngành công nghiệp phần mềm cho chúng ta thấy rằng sẽ không bao giờ có được bộ quy chuẩn xây dựng trong lĩnh vực của mình.

Chính vì không có quy trình tương đương, ngành công nghiệp phần mềm đã tiến hóa theo những cách riêng, từ đó ra đời các quy trình đặc thù như mô hình Waterfall, XP, Agile, Scrum ... chẳng hạn. Các quy trình này không đối lập nhau, không thay thế nhau, mà luôn hỗ trợ cho nhau, nối tiếp nhau, thậm chí là các biến thể (variant) của nhau (thí dụ XP và Scrum).

Các ràng buộc vật lý và yêu cầu ổn định

Các tòa nhà, cầu và các công trình xây dựng khác được điều chỉnh bởi các giới hạn vật lý mà bất cứ công nhân nào cũng có thể biết và nắm vững. Các giới hạn này quy định kích thước, hình dạng và việc sử dụng cấu trúc tùy thuộc vào vật liệu được sử dụng. Ví dụ, các tòa nhà khung gỗ có chiều cao giới hạn từ bốn đến sáu tầng. Các nhịp cầu bị giới hạn về chiều dài bởi vật liệu được sử dụng và các đặc tính của những vật liệu đó liên quan như thế nào đến các cấu trúc vật lý.

Việc xây dựng các tòa nhà và các cây cầu dù đơn giản hay phức tạp, cũng đều được nghiên cứu và thử nghiệm qua nhiều thế hệ. Do đó, các câu hỏi về tất cả các vấn đề liên quan đến công trình xây dựng đều có thể dự đoán được và các câu trả lời nằm trong phạm vi kiểm soát được.

Khi một tòa nhà đã được khởi công và nền móng đã được đổ, bạn không thể dễ dàng thay đổi kích thước hoặc vị trí trên công trình. Khi cấu trúc bên trong của một tòa nhà đã được khởi động, bạn không thể chỉ quyết định thêm một trục thang máy mới hoặc cánh mới vào tòa nhà. Khi chân của một cây cầu được đặt vào vị trí, nó không thể di chuyển được 20m chỉ vì khách hàng phát hiện ra rằng cây cầu đã ở sai vị trí. Thực sự thì bạn có thể làm được, nhưng nó đòi hỏi bạn phải xóa bỏ tất cả kết quả hiện có và bắt đầu lại từ đầu. Chi phí để làm lại trong lĩnh vực xây dựng là không nhỏ. Trong khi chi phí trong lĩnh vực phần mềm chỉ hậu quả nhỏ hơn.

Với phần mềm, có thể thực hiện hầu hết mọi thay đổi mà chúng ta muốn - từ đơn giản đến phức tạp, chẳng hạn như tăng số lượng người dùng được hỗ trợ từ 100 lên 1000; thay đổi hướng đi của sản phẩm, thay đổi ngôn ngữ lập trình... - tất cả với chi phí thấp hơn nhiều so với bắt đầu lại từ đầu.

Phần mềm có tính linh hoạt cao hơn, chúng ta có thể chấp nhận các yêu cầu thay đổi trong suốt quá trình phát triển, với ngưỡng thay đổi trung bình từ 5% - 15%. Các yêu cầu được phát hiện sớm trong quá trình phát triển có thể tiếp tục thay đổi cho đến khi dự án kết thúc.

Trong thế giới xây dựng, kiến ​​trúc sư có thể giao cho người xây dựng một bộ bản thiết kế với sự tin tưởng rằng người xây dựng sẽ hiểu ý tưởng thiết kế một cách chính xác. Mặc dù vẫn sẽ có tranh luận qua lại và nhu cầu thay đổi, nhưng mức độ thay đổi không giống với thế giới của phần mềm. Trong phần mềm, chúng ta không thể giao bản thiết kế (ngay cả khi đã có bản vẽ chi tiết UML) cho các nhà phát triển rồi để họ tự code cho đến khi ra thành phẩm. Bản thiết kế là điều kiện cần nhưng chưa đủ. Chúng ta vẫn cần đến một loạt các cuộc trao đổi liên tục giữa khách hàng và các lập trình viên cho đến khi dự án chính thức nghiệm thu.

Chủ nghĩa siêu thực (surrealism) trong các dự án xây dựng và phần mềm

Thiết kế xây dựng phải phù hợp với những hạn chế của địa điểm và chức năng. Bạn sẽ thấy thú vị khi tưởng tượng một tòa nhà văn phòng được thiết kế có thể đổi hướng từ Tây sang Bắc đề tránh nóng mùa hè, như quay xung quanh một điểm giống như một con quay hồi chuyển. Về mặt kỹ thuật là rất phức tạp, và không có tác dụng rõ rệt về mặt chức năng và sự tiện lợi cho những người sử dụng các tòa nhà đó. Trong phát triển phần mềm, bạn có thể thoải mái sáng tạo với vô vàn các hiệu ứng (animation). Trong lĩnh vực xây dựng, sự sáng tạo để có được chủ nghĩa siêu thực (Surrealism) sẽ phải đánh đổi bằng kinh phí lớn, sức sáng tạo lớn và thậm chí đánh đổi bằng cả tính mạng. Có thể nhiều người trong chúng ta không biết một số liệu thực tế rằng, cho đến năm 2022, Trung Quốc đã xây dựng gần 3000 cây cầu kính trên khắp cả nước, trong khi Việt Nam chúng ta mới chỉ có 3 cây cầu kính.

Tương tự như vậy, khi xây dựng cầu hoặc đường, có những tiêu chuẩn rõ ràng và có tính pháp lý dựa trên loại và kích thước của phương tiện sẽ đi qua. Ở những nước phát triển, cây cầu được thiết kế thông minh hơn, như cầu quay cho tàu thủy đi qua. Đối với lĩnh vực phát triển phẩn mềm, sức sáng tạo cũng rất lớn. Nếu chỉ đơn thuần đáp ứng nhu cầu cơ bản, phù hợp với nhóm đối tượng người dùng mục tiêu với mồn nền tảng xã hội ở mức độ nào đó, các tính năng thông mình có thể khiến dự án vượt quá ngân sách, dẫn đến hệ lụy nghiệm thu kéo dài và thậm chỉ là dự án "đắp chiếu" (thất bại).

Phần mềm không phải tuân theo những ràng buộc tương tự này. Nếu khách hàng thực sự muốn hiệu ứng quay ấn tượng giống như một chiếc cấu quay hay một chiếc cầu tự nâng, các kỹ sư phần mềm cũng có thể thiết kế. Trong sản phẩm phần mềm, đối tượng người dùng đa dạng hơn, mục đích sử dụng cũng rất phong phú hơn so với lĩnh vực xây dựng. 

Thí dụ: Một khách hàng yêu cầu chúng tôi thiết kế một trang Landing Page cho những người yêu thể thao vua "bóng đá". Trên đó có thiết kế một loại quảng cáo tự xoay (rotate ads) cho phép hiển thị một danh sách các banner ngẫu nhiên hoặc theo quy luật được cấu hình ở hệ thống quản trị. Tiếp theo, với ngân sách dồi dào, vị khách hàng nọ có 1 ý tượng khá táo bạo, nhưng rất thực tế, đó là: chỉ hiển thị các loại quảng cáo phù hợp với người dùng của quốc gia đó, còn gọi là quảng cáo theo ngữ cảnh. Đó chính là "quảng cáo ảo". Thí dụ người dùng ở Việt Nam sẽ nhìn thấy quảng cáo về giày Bitis thay vì giày đến từ Nhật Bản.

So sánh tổn thất khi có biến động nhân sự

Trong xây dựng, những người thợ thường được coi là có thể hoán đổi và thay thế cho nhau. Giả sử rằng nếu bạn thay đổi những người thợ mộc trong khi đóng khung một ngôi nhà, thì kết quả công việc của họ nhìn chung sẽ giống nhau.

Trong quy trình phát triển phần mềm, việc thay thế nhân sự không hề đơn giản. Do sự phức tạp và khác biệt trong cả công cụ (ngôn ngữ lập trình và thư viện), các chuyên viên phát triển, các chuyên gia phân tích (BA), kiểm thử viên và kỹ sư thiết kế UX không thể chỉ được chuyển từ khu vực này sang khu vực khác. 

Chúng ta thường nhìn thấy giữa lĩnh vực phần mềm và lĩnh vực xây dựngdường  có điểm chung nào đó, như nhân sự có thể thay thế và hoán đổi cho nhau. Thực tế là không đúng. Tất cả các phần quan trọng của phần mềm được xây dựng bởi một nhóm các kỹ sư trình độ cao, vì vậy nếu bạn trao đổi hoặc thay thế một thành viên trong nhóm này bằng một thành viên khác, thì chi phí tốn kém theo ba cách chính:

• Họ mất kiến ​​thức tiềm ẩn mà thành viên cũ trong nhóm của họ có.
• Họ phải đào tạo thành viên mới trong nhóm về những gì họ đang xây dựng và những gì họ đã hoàn thiện cho đến nay.
• Họ phải dành thời gian thiết lập mối quan hệ làm việc hiệu quả với người mới.

Thêm người vào dự án phần mềm ở giai đoạn muộn sẽ làm dự án càng bị trễ hơn

Việc thay thế hoặc thêm một người mới sẽ khiến cả nhóm chậm lại ít nhất 3-4 tháng. Về mặt cá nhân, thành viên mới trong nhóm thường mất nhiều thời gian hơn thế để trở nên hiệu quả hoàn toàn. Trong khi việc xây dựng cũng bị chậm lại khi mọi người bị thay đổi, nhưng nó sẽ không giống với một dự án phần mềm.

Kết Luận

Các nguyên tắc trong xây dựng không thể được sử dụng để mô tả phần mềm. Rất nhiều doanh nghiệp phần mềm cố gắng bắt chước công thức trong lĩnh vực xây dựng công trình, chẳng hạn như:

1. Cố gắng thu thập ĐẦY ĐỦ các yêu cầu từ sớm, thay vì suy nghĩ rằng các thay đổi yêu cầu là không thể tránh khỏi. Rõ ràng "Cơ hội nếu rõ ràng thì đã không đến với bạn. Thông tin có rõ ràng thì đã có người làm trước bạn". Các nhà thầu phát triển dự án phần mềm hiểu rất rõ điều này. Họ sẵn sàng chấp nhận rủi ro là không thể có bức tranh hoàn hảo ngay từ đầu.
2. Đánh giá quá cao tầm quan trọng của kiến ​​trúc hệ thống và vai trò của kiến ​​trúc sư thay vì chấp nhận rằng phần mềm có thể thích ứng linh hoạt và có thể được thay đổi bởi bất kỳ ai trong nhóm
3. Luôn tìm kiếm phương án dự đoán về phạm vi (scope), chi phí (cost)... thay vì chấp nhận thực tế rằng các nghiệp vụ chưa thể chuẩn hóa để có thể mô hình hóa và chuyển đổi thành các tính năng trong phần mềm.

Rõ ràng xây dựng một dự án phần mềm không liên quan nhiều đến quy trình trong các dự án xây dựng. Phần mềm không thể chỉ xây dựng, mà phải được khám phá và tiến hóa theo thời gian.

Với kinh nghiệm của TIGO Team, chúng tôi xem các vấn đề (pain points) của khách hàng đang gặp phải là trọng tâm để khám phá. Chúng tôi biết cần "gõ" ở chỗ nào và xây "long mạch" ở chỗ nào để khơi thông dòng chảy dữ liệu của khách hàng. Chúng tôi đang tạo ra những ý tưởng mới có thể được diễn đạt bằng dòng "code". Vì vậy, chúng tôi thành công và kiên trì thực hiện sứ mệnh "Chuyển đổi tinh tế, thích ứng linh hoạt". 

Cảm ơn các bạn đã theo dõi. Mọi phản hồi, xin liên hệ với chúng tôi để được tư vấn. 
Email: info@tigosolutions.com

Phạm Đình Trường CEO, Software Architect TIGO Solutions