Lập Trình Viên – Bạn Sẽ Bị Đào Thải Ngày Mai?

Posted on Updated on

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)

10 thoughts on “Lập Trình Viên – Bạn Sẽ Bị Đào Thải Ngày Mai?

    mangrovecm@hotmail.com said:
    Tháng Mười 18, 2007 lúc 4:59 chiều

    Tới khi đó thì bạn đã bạc tóc rồi, hoặc cũng không thể ngồi code nỗi nửa đâu.

    Cũng như trước kia, người ta hô hào nào là sử dụng phần mềm không bản quyền thì sẽ bị đi tù, bị phạt hành chính. Hôm nay bạn xem những cửa hàng bán CD software kia, họ đang xây nhà, mua đất đó.

    Lo xa làm chi cho mệt

    web2vietnam responded:
    Tháng Mười 18, 2007 lúc 5:13 chiều

    Cũng hy vọng là thế😀

    TanNg said:
    Tháng Mười 19, 2007 lúc 8:23 sáng

    Ngay làm phần mềm trong nước, chưa nói làm web thì theo mô hình Waterfall vẫn sẽ tỏi. Người Việt phù hợp với Agile methods hơn.

    Release sớm và thường xuyên không chỉ liên quan tới lập trình mà nó giúp mình cảm nhận và đo lường phản hồi của người sử dụng tốt hơn.

    javacola said:
    Tháng Mười 20, 2007 lúc 7:48 sáng

    Thực thế thì mô hình Waterfall đã không còn phù hợp với việc phát triển phần mềm từ rất lâu rồi, nó tồn tại chỉ còn mang tính chất tham khảo và hàn lâm để dạy cho sinh viên😀

    Em không đồng ý với quan điểm của anh Quang về việc: Tương lai phát triển phần mềm: Chỉ cần một vài “nghệ nhân”.

    Hãy xét đến các dịch vụ Web 2 đang làm mưa làm gió như Digg, delicious,… ở thời kỳ sơ khai có thể do một hoặc vài cá nhân phát triển – đó chỉ là bước khởi đầu để hiện thực hóa ý tưởng. Tuy nhiên theo đà phát triển Dev team của họ cũng phải phình ra.

    Anyway, great post🙂

    TanNg said:
    Tháng Mười 20, 2007 lúc 12:29 chiều

    Chuyện một vài nghệ nhân cũng có thể lắm. Vì mấy lý do sau

    * Nguồn gốc để thắng lợi trên Internet là innovation và change. Đông cũng không giúp vượt qua rào cản lớn, đông nhiều khi làm cho thay đổi khó khăn hơn.

    * Vòng đời sản phẩm ngắn. Một sản phẩm chưa kịp phình đã lạc mốt. Nghệ nhân thì có thể làm ngay sản phẩm khác, còn đám đông lập trình viên thì không.

    * Công cụ, năng suất và nền tảng ngày càng rẻ và chất lượng càng cao. Kéo theo lợi thế của số đông bị đánh mất. Một vài người giỏi có điều kiện để đứng trên vai người khổng lồ.

    * Xu hướng open source, open content, open standard phát triển mạnh, tạo ra cơ chế đứng trên vai người khổng lồ vì có thể tái sử dụng code, framework, cũng như các sản phẩm trí tuệ của người khác.

    * Driving force của Internet là người dùng, họ cần càng ít càng tốt. Vấn đề đặt ra là giải quyết bài toán một cách đơn giản, chứ không phải dồn nhiều người để giải quyết bài toán khó. Và đây cũng là sở trường của nghệ nhân, sở đoản của người quản lý chuyên nghiệp.

    evodanh@yahoo.com said:
    Tháng Mười Một 3, 2007 lúc 1:08 sáng

    Digg, del.icio.us chẳng qua được như ngày hôm nay là do đứng trên vai những người khổng lồ thôi.
    Mà những người khổng lồ thì cần rất nhiều developer.
    Ko biết Digg dùng database system gì nhỉ? Mà 1 database system do bao nhiêu người viết???

    Hồng Quang responded:
    Tháng Mười Một 5, 2007 lúc 12:07 chiều

    Theo tôi biết Digg hiện vẫn là một dịch vụ độc lập, còn del.icio.us được Yahoo mua lại nhưng trước đó đã phát triển rất tốt. Mặt khác Yahoo kg góp sức gì nhiều cho del.icio.us ngoài sự bảo đảm đó là của Yahoo.

    MinhTĐ said:
    Tháng Mười Một 26, 2007 lúc 1:37 sáng

    Bác có biết trong công nghệ làm máy bay, người ta sử dụng phương pháp nào không? Water Fall hay Agile?

    truonglvx said:
    Tháng Mười Hai 7, 2007 lúc 9:44 chiều

    trong công nghệ sản xuất máy bay thì water fall là mô hình thường được sử dụng nhưng việc sản xuất máy bay là hoàn toàn khác với sx phần mềm

    MinhTĐ said:
    Tháng Mười Hai 12, 2007 lúc 12:06 sáng

    Tất nhiên, nhưng chỉ là nói lên một điều, phương pháp nào cũng có chỗ ứng dụng của nó! Nếu cứ chỉ nói một chiều thì cũng không ổn!

Bình luận đã được đóng.