Thế giới là một cuộc chọn lọc và đào thải không ngừng, nhưng thế giới IT còn khắc nghiệt hơn. Bạn sẽ là người bị đào thải kế tiếp?

1. Cái chết của mô hình Waterfall

Năm 1970, mô hình nổi tiếng và được áp dụng trong qui trình phát triển phần mềm tại phần lớn các công ty hiện nay ra đời: mô hình thác nuớc (waterfall model). Mô hình này là kết quả của sự kết hợp các mô hình sản xuất từ các ngành kỹ thuật khác áp dụng cho công nghệ phần mềm. Nó định nghĩa ra chuỗi qui trình phát triển theo thứ tự từ trên xuống bao gồm: lấy yêu cầu khách hàng, làm thiết kế, phát triển, kiểm định và cuối cùng sẽ bàn giao cho người dùng. Bạn sẽ thấy mô hình này giống hệt với qui trình xây một căn nhà: kiến trúc sư tìm hiểu yêu cầu của chủ nhà, thiết kế căn nhà, đưa cho đội ngũ thi công thực hiện, kiểm tra chất lượng và cuối cùng trao chìa khóa cho người sở hữu.
Năm năm sau, Frederick Brooks phát hiện ra lỗ hổng lớn đầu tiên của mô hình này trong cuốn sách kinh điển về quản trị dự án: The Mythical Man-Month (Bí mật về tháng nhân công). Chắc các bạn làm phần mềm đều biết khái niệm man-month (hay man-day) là thước đo căn bản để tính giá cho việc phát triển phần mềm: đó là công lao động trong một tháng (hay một ngày) của một lập trình viên. Phát hiện nổi tiếng nhất của Brooks là “trong phát triển phần mềm không phải cứ thêm nhân công thì dự án sẽ nhanh hơn theo cùng cấp số“. Vấn đề là do sự mất cân đối trong giao tiếp khi số lượng người tham gia tăng lên.

Nhiều năm qua đi, người ta ngày cảng học hỏi được nhiều hơn về cách tốt nhất để làm một phần mềm và cũng bắt đầu nhận thức được rằng mô hình thác nước là quá cứng nhắc và thiếu thực tế. Không giống như việc bạn xây một căn nhà, ngay khi thiết kế, người ta đã dự kiến được 99% hình thù và chi tiết căn nhà sẽ như thế nào. Một dự án phần mềm hiếm khi được hình dung một cách chi tiết và đúng theo yêu cầu công việc. Chỉ khi đưa vào thử nghiệm trong môi trường thực các vấn đề mới bắt đầu phát sinh và việc thay đổi yêu cầu diễn ra thường xuyên.

Những người “ngoại đạo” thường nghĩ rằng vì phần mềm là “mềm” nên có thể dễ dàng thay đổi chỉnh sửa tùy hứng. Nhưng thực ra phầm mềm cũng giống như bất kỳ một cơ cấu kỹ thuật nào khác (như máy móc cơ khí chẳng hạn), nó cũng có thiết kế và cấu trúc (mà thường lại còn phức tạp hơn các máy móc cơ khí rất nhiều).

Khi yêu cầu công việc thay đổi, việc thay đổi trong phần mềm là tất yếu và trong thế kỷ 21 này các thay đổi lại càng diễn ra thường xuyên và nhanh chóng. Với mô hình thác, việc theo kịp các thay đổi là không thể thực hiện vì vòng qui trình của nó quá dài. Nó giống như việc cứ mỗi lần có bất kỳ thay đổi nào là bạn phải gần như phải phá căn nhà đi và xây lại từ đầu. Bạn có thể hình dung ra được sự tốn kém và bất tiện sẽ lớn như thế nào.

Tóm lại, hai vấn đề lớn nhất của mô hình thác nước là:

1. Mô hình này quá tự tin với giả định rằng chúng ta luôn có thể làm được một hệ thống hoàn hảo ngày lần đầu.

2. Phầm mềm ngày càng khác với các cơ cấu kỹ thuật cứng nhắc mà giống như các cơ thể sống - nó phải tiến hóa để thích hợp với môi trường. Đây chính là tiền đề cho một phương thức phát triển mới chiếm lĩnh ưu thế trong những năm gần đây: phương thức phát triển linh hoạt (Agile Development Methods).

2. Phát triển linh hoạt - Phần mềm tiến hoá

Phương thức phát triển phần mềm linh hoạt bắt đầu xuất hiện vào đầu những năm 90 với mục tiêu là phần mềm phải có khả năng biến đổi, phát triển và tiến hóa theo thời gian mà không cần phải làm lại từ đầu. Phương thức này tập chung vào tính đơn giản: tạo ra một phần mềm thật đơn giản đáp ứng đúng yêu cầu của khách hàng hôm nay và sẵn sàng cho những thay đổi vào ngày mai.

Phương thức phát triển này dựa trên hai kỹ thuật đáng lưu ý nhất:

1. Refactoring: Giống như vệc bạn trang trí lại căn nhà mà không cần phải cơi nới, xây thêm hay xây lại, “refactoring” (xin lỗi, tôi chưa tìm được từ tiếng Việt nào thích hợp để dịch) cho phép chúng ta chuyển đổi mã lệnh để làm cho ứng dụng tốt hơn, đẹp hơn mà không phá hỏng nó (các bạn có thể tìm hiểu thêm về kỹ thuật này trong cuốn Refactoring: Improving the Design of Existing Code).
2. Developer Testing: Phần mềm do chính các lập trình viên được kiểm định thay vì do các nhóm tester độc lập làm. Công cụ là “unit test”, cho phép từng phần nhỏ của phần mềm được kiểm định ngay trong quá trình phát triển trước khi lắp ghép vào ứng dụng. (xin xem thêm cuốn Test Driven Development: By Example)

Một trong những yếu tố khác khiến cho phương thức phát triển linh hoạt có thể cất cánh là sự lớn mạnh của các ngôn ngữ kịch bản (scripting language) như PHP, Python và gần đây là “viên hồng ngọc” Ruby. Tính linh hoạt của các ngôn ngữ này khiến cho việc thay đổi phần mềm dễ dàng hơn nhiều so với các ngôn ngữ tiền bối. Thêm vào đó là việc cộng đồng mã nguồn mở đang cung cấp vô số các thư viện dựng sẵn, đáp ứng cho việc phát triển nhanh, triển khai nhanh, thường xuyên đưa ra các cập nhật mới (release soon, release often) theo đúng tinh thần của phương thức phát triển linh hoạt. Phần mềm ngày nay không phải được nâng cấp hàng năm mà là hàng tuần, thậm chí hàng ngày.

3. Tương lai phát triển phần mềm: Chỉ cần một vài “nghệ nhân”

Digg, del.icio.us… các “phần mềm” trị giá hàng chục triệu, hàng trăm triệu USD chỉ do một hai người thực hiện. Facebook, mạng xã hội trị giá nhiều tỷ USD, cũng chỉ do một nhóm nhỏ làm ra.

Bí quyết phát triển các phần mềm có giá trị nhất ngày nay là chỉ cần một vài người có kỹ năng, nhiều nhiệt huyết. Với vài cá nhân xuất sắc trang bị các ngôn ngữ lập trình hiện đại và phương thức làm việc mới, một nhóm nhỏ có thể làm ra những sản phẩm tốt hơn cả một “đạo quân” lập trình viên trước kia.

Tổng kết lại, có thể thấy những thay đổi sẽ diễn ra trong các năm tới đây:

• Những kỹ sư phần mềm có trình độ cao, có nhiệt huyết và tham vọng sẽ là những cỗ máy làm ra tiền.
• Những lập trình viên không có kỹ năng đặc biệt có lẽ nên tìm việc làm ở lĩnh vực khác.
• Những thay đổi mà chúng ta đang thấy ở thị trường phần mềm đại chúng sẽ diễn ra ở các công ty lớn.
• Đưa phần mềm cho nước ngoài gia công (outsourcing) sẽ ngày càng ít tính kinh tế hơn.
• Khoa học máy tính vẫn là lĩnh vực cạnh tranh và đòi hỏi cao.

4. Tương lai của các LTV Việt Nam

Nhìn các xu hướng đang diễn ra trên thế giới, có thể thấy rằng các dự án cần hàng trăm người sẽ ngày càng ít đi. Theo tính toán của Mỹ, chi phí outsourcing đang gia tăng (từ 1/10 lên 1/3 so với giá thành sản xuất trong nước) làm cho việc đưa phần mềm ra nước ngoài gia công ngày càng kém hấp dẫn. Ngoài ra, do khó khăn về giao tiếp và chệnh lệch về trình độ, chất lượng các dự án này cũng không được như mong muốn và rất khó bắt kịp các thay đổi của khác hàng.

Các LTV luôn có xu hướng muốn gia nhập các công ty lớn, tham gia vào các dự án lớn. Nhưng có thể đấy sẽ cách tiếp cận sai lầm vì:

• Tương lai của các công ty làm xuất khẩu phần mềm dạng này đang ngày càng bấp bênh.
• Bản thân các LTV thường không cải thiện được trình độ vì các công việc được giao ít cần kỹ năng cao hay tính sáng tạo.

Tất nhiên, nhìn thẳng vào thực tế, sự thay đổi sẽ không diễn ra ngay trong nay mai — mô hình thác nước và các biến thể của nó vẫn sẽ được dùng, người ta sẽ vẫn outsourcing. Nhưng mọi thứ sẽ ngày càng khó khăn hơn, đòi hỏi cao hơn và chỉ khi bạn thực sự chuẩn bị tốt cho sự thay đổi thì mới tránh được việc bị đào thải.

Đáng lo ngại nhất là các LTV Việt Nam còn xa mới theo kịp các đồng nghiệp ở các nước như Ấn Độ hay Ireland cả về mặt tổ chức lẫn kỹ năng. Chúng ta quá chú trọng tới các công nghệ độc quyền của Microsoft, Oracle hay IBM và hiểu biết về mã nguồn mở là một lỗ hổng lớn. Không may, có thể ngày mai công ty sẽ nói lời chia tay với bạn chỉ vì bạn không có kinh nghiệm gì về Python hay cơ sở dữ liệu MySQL. Như tựa một bộ phim “Đó là một tương lai không quá xa” (Not too far future), xin hãy suy nghĩ lại con đường của mình.

(theo ReadWriteWeb)

“How Microsoft Lost the API War” (2004) là một trong những bài viết sâu sắc nhất nhất tôi đã từng đọc dự báo sự ra đời của web 2.0 ngày nay. Nhưng web không dừng lại ở API mà đã phát triển thành một nền tảng (platform). Chúng ta hãy điểm qua những gì đang diễn ra trên cuộc chiến nóng bỏng này.

Nhiều người tin rằng ngày Facebook tuyên bố mở cửa nền tảng cùa mình cho các nhà phát triển xây dựng các ứng dụng trên đó là một ngày lịch sử. Vì sao? Có hai lý do chính:

1. Facebook là một trong những mạng xã hội thành công nhất cả về mặt số lượng lẫn chất lượng. Đưa ứng dụng lên Facebook nghĩa là bạn có tiềm năng tiếp cận trực tiếp với hơn 20 triệu người dùng. Với đa số ứng dụng web thì chỉ cần có 1/20 số người dùng đó cũng đã là thành công lớn.

2. Khác với các công ty như Google hay Yahoo, Facebook không chỉ đưa ra các API (application programming interface) mà họ mở gần như toàn bộ nền tảng của mình cho các nhà phát triển.

Một ứng dụng được phát triển trên nền tảng của Facebook sẽ có tất cả những tính năng tuyệt vời của mạng xã hội này, nổi bật nhất là tính tự lan truyền: khi một người trong mạng dùng ứng dụng thì đồng thời (trong đa số trường hợp) anh ta cũng tự động giới thiệu nó cho bạn bè của mình cùng sử dụng. Kết quả là số người dùng sẽ tăng lên theo cấp số nhân nếu đó thực sự là ứng dụng hữu ích. Người dùng còn có thể chia sẻ, cùng bình luận hay cùng làm việc trên ứng dụng này thông qua các giao thức của Facebook. Ứng dụng cũng được thừa hưởng luôn giao diện đơn giản và thân thiện của Facebook, giống như một ứng dụng trên Windows thì mặc nhiên sẽ có cửa sổ với các nút phóng to, thu nhỏ và đóng ứng dụng. Chính vì thế nhiều người coi đây là một “hệ điều hành” trên web.

Chỉ trong vòng 4 tháng tính đến tháng 8 năm 2007 đã có hơn 2300 ứng dụng(!) được xây dựng trên nền của Facebook và một số thu được thành công nhanh chóng (bạn có thể tìm hiểu 30 ứng dụng hàng đầu trong bài viết này của Mashable). Ứng dụng “for Facebook” đang trở thành một “cơn sốt vàng” (gold rush) mà rất nhiều công ty muốn tham gia trước khi quá trễ. Điều này gợi cho tôi nhớ lại thời Windows 3.x ra đời vào đầu những năm 90 của thế kỷ trước và sự bùng nổ của một loạt ứng dụng “for Windows” như FoxPro for Windows, WordPerfect for Windows… nhưng ở mức độ nhanh và cao hơn rất nhiều.

Trước thành công của Facebook, sau đó MySpace tuyên bố sẽ đưa ra API phát triển ứng dụng cho mạng xã hội lớn nhất này. Tiếp theo, Google cũng có kế hoạch sẽ mở cửa mạng xã hội Orkut của mình và mạnh miệng hơn họ còn tuyên bố nền tảng của mình sẽ mở 100% thay vì chỉ 95% như Facebook (thú thực, mạng Orkut này không gây ấn tượng gì với tôi lắm, đến nay nó mới có khoảng 1,8 triệu đăng ký, đa số là tại Châu Âu). Và gần đây, Microsoft nói sẽ mở một số API chủ chốt cho các nhà phát triển ứng dụng trên Windows Live của họ (tất nhiên, chiến lược của MySpace, Microsoft, Google khác với Facebook, bạn có thể xem thêm ở bài phân tích này trên ZNet).

Không chỉ các công ty lớn mà hầu hết các công ty web 2.0 khác cũng bắt đầu phải suy nghĩ tới việc tự định nghĩa lại mình. Facebook đã cho thấy rằng các “dịch vụ web” đang đi đến cuối con đường của mình và sẽ phải nhường chỗ cho các nền tảng web.

Nếu hôm nay bạn hỏi tôi Web 3.0 là gì thì tôi có một dự đoán: Đó sẽ là sự liên thông giữa các nền tảng web 2.0 để tạo nên một nền tảng web mới.

(nếu dự đoán trên đúng thì xin các bạn mua giùm cái áo thung này nhé )