copyright from: cmu.duytan.edu.vn
Một người bạn của tôi, là chủ một công ty phần mềm tuần trước có nói với tôi về tình hình anh hiện đang phải đối mặt. Công ty anh ta cần tuyển 50 nhân viên phát triển phần mềm và thế là anh đã quảng cáo những vị trí tuyển dụng đó trên báo chí, websites, và ở các trường đại học. Sau nhiều tuần, công ty của anh nhận được hơn 300 hồ sơ. Anh đã cẩn thận đánh giá tất cả các hồ sơ xin việc và chọn ra 100 người để phỏng vấn. Anh đã yêu cầu họ viết một chương trình “đơn giản” để kiểm tra khả năng của họ, hy vọng sẽ tuyển được 50 trong số 100 ứng viên đó cho công ty của mình. Mặc dù yêu cầu của chương trình đó khá là đơn giản, 75 ứng viên đã không thể làm xong trong khoảng thời cho phép. Anh cũng đã nhận thấy những khác biệt lớn giữa những lập trình viên đã viết xong được chương trình đó. Anh ta nói: “Điều gì sẽ xảy ra khi nhân viên phát triển không thể làm xong việc trong thời gian yêu cầu? Hoặc là (tôi) phải cho họ thêm thời gian hoặc (tôi) phải làm thay cho họ.” Từ góc độ quản lý, điều này là không thể chấp nhận được. Tuy nhiên, vấn đề không phải với những người không làm được việc vì dù gì thì tôi cũng sẽ chẳng thuê họ. Vấn đề là với 25 người làm được việc, dù đúng trong thời gian cho phép nhưng họ lại mắc quá nhiều lỗi.
Anh nói: “Đây là vấn đề năng suất và chất lượng.” Là ông chủ một công ty (phần mềm), anh đã từng gặp nhiều người làm phần mềm là “sản phẩm” của “những chương trình huấn luyện và đào tạo tồi.” Anh bảo tôi: “Họ được dạy cách lập trình nhưng không theo chuẩn lập trình nào cả. Họ học được nhiều ‘mánh và thủ thuật’ để làm bài được trong quá trình học nhưng lại không được dạy làm thế nào để chữa lỗi trong mã của họ trước khi tích hợp mã với người khác. Vì thế, sản phẩm cuối cùng của họ thường có nhiều lỗi và hạn chế, đòi hỏi nhiều thời gian hơn nữa để sửa chữa. Họ không biết cách tính toán công việc của mình vì họ không biết khi nào họ sẽ làm xong việc tại chẳng ai dạy họ cách lượng hóa hay lập kế hoạch.” Là một nhà quản lý, anh ta luôn tự hỏi sẽ phải làm gì với những nhân viên làm phần mềm được huấn luyện quá tồi này vì nếu anh ta không có hành động kịp thời, các thành viên phát triển khác trong nhóm sẽ đặt ra chính câu hỏi đó. Do công việc phát triển phần mềm liên quan đến làm việc nhóm và mọi người phải dựa vào kết quả công việc của nhau (trong phát triển phần mềm), nên các thành viên trong nhóm sẽ không vui nếu người giám đốc dự án không sẵn lòng giải quyết vấn đề một cách hiệu quả và trực tiếp với các nhân viên phát triển tồi đó. Anh giải thích: “Tôi đã gởi họ đi học để cải thiện kỹ năng nhưng nhiều người đã cố che cái dở của mình hơn là tiếp nhận cơ hội phát triển kỹ năng. Thái độ tiêu cực này xuất phát từ quan niệm là họ cũng có bằng cấp (như ai) và không cần phải đi học lại nữa. Họ cũng không thích người khác giúp họ xem xét lại kết quả công việc của họ. Họ phàn nàn về làm việc nhóm, các quyết định của nhóm, và luôn có cớ ngụy biện cho việc làm của họ. Một số bảo với tôi rằng họ quá bận không có thời gian chữa lỗi, nhưng sẽ cố chữa sau, và rồi (chủ yếu) bỏ thời gian thử mã có chạy được không hơn là thật sự chữa chúng. Họ còn tìm kiếm thêm các ‘mánh’ mới từ các ‘chat-room,’ và thay vì hỏi các thành viên khác trong nhóm, họ nhờ ai đó trên mạng giúp đỡ họ vì chẳng ai sẽ biết được họ là ai cả.” Là một ông chủ và là một doanh nhân, anh bạn của tôi chẳng có mấy lựa chọn hơn là sa thải những nhân viên như vậy vì họ đã có những thái độ và thói quen xấu, khó mà thay đổi được gì.
Anh bạn tôi nói: “Sau nhiều năm trong nghề, tôi đã học được cách làm thế nào để nhanh chóng phát hiện ra những người có ‘các thái độ xấu’ như vậy. Hàng tuần, tôi ra yêu cầu đánh giá lại thiết kế và mã lập trình trong từng dự án ở công ty. Rồi tôi cố tìm ra những đối tượng không muốn cho người khác xem việc mình làm, không tiếp thu đề nghị của người khác, không bỏ thời gian đánh giá phần việc của người khác, và thiếu hợp tác hay không sẵn lòng làm việc chung trong nhóm. Khi xem xét những gì các đối tượng này làm, tôi thường chẳng hiểu được thiết kế hay mã của họ vì chúng rất không logic, lộn xộn, và đầy những “mánh và thủ thuật” (chắp vá với nhau) hơn là dễ nhìn hay có chút logic gì. Nếu tôi làm lơ trước những thái độ như vậy, vô hình chung sẽ khuyến khích hơn nữa những thái độ xấu đó và rồi sẽ làm hại đến năng suất của các thành viên khác trong nhóm. Tôi không hiểu vì sao nhà trường lại không dạy gì về làm việc nhóm cho sinh viên vì đó là một thành tố cực kỳ quan trọng trong phát triển phần mềm, và tôi cũng chẳng hiệu tại sao trường học lại đào tạo ra những loại người như vậy?”
Tôi bảo với anh ta rằng: “Lý do chính vì sao nhiều người làm phần mềm mắc phải những thói quen xấu như vậy không phải vì làm phần mềm là khó mà là vì việc thiếu giảng dạy những nguyên tắc cơ bản về Công nghệ Phần mềm (cho họ).” Thậm chí đến ngày nay, có rất ít chương trình đào tạo tập trung vào thiết kế, kiến trúc, phương pháp lập trình, đảm bảo chất lượng, làm việc nhóm, và quản lý dự án. Hầu hết các trường đều vẫn chỉ dạy chủ yếu là lập trình, vì thế sinh viên chỉ có thể lập trình cho những dự án nhỏ và không làm được gì nhiều hơn thế. Nhiều sinh viên khác học đủ các “mánh và thủ thuật” trong quá trình học để có thể làm cho xong bài tập. Điều họ lại không học được trong quá trình đó là tính kỹ luật trong kiến thức, vốn cực kỳ quan trọng cho nghề nghiệp tương lai của họ, dù ngay trước mặt nó có thể chẳng mang lại lợi ích trực tiếp gì cả. Ngày nay, hầu hết các chương trình đào tạo (phần mềm) đều là từ ba đến bốn năm học lập trình (chay), và suốt thời gian đó sinh viên chỉ học cách viết các chương trình nhỏ để thỏa mãn các yêu cầu học tập của nhà trường. Đối với những người mới bắt đầu học máy tính, lập trình dường như là khó nhưng trong ngành phần mềm, lập trình (thực ra) chỉ là một phần nhỏ của cả dự án. Những sinh viên mới chỉ viết được vài ba chương trình nhỏ ở trường lại nghĩ rằng chuyển sang viết những chương trình lớn hay phức tạp hơn cũng tương tự như vậy, chỉ là viết nhiều hơn và tốn nhiều thời gian hơn. Thật sự thì KHÔNG PHẢI như vậy. Xây một túp lều (như tôi đã từng nói) khác xa việc xây dựng một tòa nhà 10 tầng. Việc xây dựng một tòa nhà lớn đòi hỏi đủ thứ kiến thức và kỹ năng khác nhau, mà thường là với yêu cầu chuyên môn cao hơn nhiều. Bạn chẳng thể nào xây dựng xong một tòa nhà lớn mà không cần có kiến trúc sư. Bạn không thể xây được một tòa nhà lớn nếu không có thiết kế. Đơn thuần chỉ bỏ gạch và xi măng lại với nhau không thể tạo ra được một tòa nhà lớn vì nó sẽ bị sập. Sự khác biệt về tính phức tạp giữa những gì sinh viên học (ở trường) và những gì ngành phần mềm thực sự làm cũng tương tự như vậy, và những ai chỉ biết học các “mánh và thủ thuật” thì sẽ không thể nào hiểu được khác biệt này. Vì thế, nhiều người đến trường học các thứ như email, Excel, PowerPoint, và web để “Google” tìm kiếm thông tin hay download nhạc, những người này có thể làm được các bài trình bày hay các bảng tính đơn giản, nhưng như vậy thì chỉ cần học trong vài tuần chứ cần gì cả năm học. Họ cũng có thể học cách lập trình C++ hay Java chỉ cần trong một hai năm chứ cần gì đến cả bốn năm. Thế nên, cái sinh viên thật sự cần học (trong bốn năm đó) là một kiến thức vững chắc về việc làm thế nào để viết được các chương trình tốt, làm thế nào để giải quyết các bài toán kinh doanh, làm thế nào để tạo ra các sản phẩm có chất lượng, và làm thế nào để làm việc được trong nhóm. Những kỹ năng này vượt ra khỏi phạm vi của việc lập trình; và thật sự đó mới là cái mà ngành phần mềm gọi là “phát triển phần mềm” hay “Công nghệ Phần mềm.” Và đó cũng là những gì mà ngành phần mềm ngày nay đang cần đến.
Một người bạn của tôi, là chủ một công ty phần mềm tuần trước có nói với tôi về tình hình anh hiện đang phải đối mặt. Công ty anh ta cần tuyển 50 nhân viên phát triển phần mềm và thế là anh đã quảng cáo những vị trí tuyển dụng đó trên báo chí, websites, và ở các trường đại học. Sau nhiều tuần, công ty của anh nhận được hơn 300 hồ sơ. Anh đã cẩn thận đánh giá tất cả các hồ sơ xin việc và chọn ra 100 người để phỏng vấn. Anh đã yêu cầu họ viết một chương trình “đơn giản” để kiểm tra khả năng của họ, hy vọng sẽ tuyển được 50 trong số 100 ứng viên đó cho công ty của mình. Mặc dù yêu cầu của chương trình đó khá là đơn giản, 75 ứng viên đã không thể làm xong trong khoảng thời cho phép. Anh cũng đã nhận thấy những khác biệt lớn giữa những lập trình viên đã viết xong được chương trình đó. Anh ta nói: “Điều gì sẽ xảy ra khi nhân viên phát triển không thể làm xong việc trong thời gian yêu cầu? Hoặc là (tôi) phải cho họ thêm thời gian hoặc (tôi) phải làm thay cho họ.” Từ góc độ quản lý, điều này là không thể chấp nhận được. Tuy nhiên, vấn đề không phải với những người không làm được việc vì dù gì thì tôi cũng sẽ chẳng thuê họ. Vấn đề là với 25 người làm được việc, dù đúng trong thời gian cho phép nhưng họ lại mắc quá nhiều lỗi.
Anh nói: “Đây là vấn đề năng suất và chất lượng.” Là ông chủ một công ty (phần mềm), anh đã từng gặp nhiều người làm phần mềm là “sản phẩm” của “những chương trình huấn luyện và đào tạo tồi.” Anh bảo tôi: “Họ được dạy cách lập trình nhưng không theo chuẩn lập trình nào cả. Họ học được nhiều ‘mánh và thủ thuật’ để làm bài được trong quá trình học nhưng lại không được dạy làm thế nào để chữa lỗi trong mã của họ trước khi tích hợp mã với người khác. Vì thế, sản phẩm cuối cùng của họ thường có nhiều lỗi và hạn chế, đòi hỏi nhiều thời gian hơn nữa để sửa chữa. Họ không biết cách tính toán công việc của mình vì họ không biết khi nào họ sẽ làm xong việc tại chẳng ai dạy họ cách lượng hóa hay lập kế hoạch.” Là một nhà quản lý, anh ta luôn tự hỏi sẽ phải làm gì với những nhân viên làm phần mềm được huấn luyện quá tồi này vì nếu anh ta không có hành động kịp thời, các thành viên phát triển khác trong nhóm sẽ đặt ra chính câu hỏi đó. Do công việc phát triển phần mềm liên quan đến làm việc nhóm và mọi người phải dựa vào kết quả công việc của nhau (trong phát triển phần mềm), nên các thành viên trong nhóm sẽ không vui nếu người giám đốc dự án không sẵn lòng giải quyết vấn đề một cách hiệu quả và trực tiếp với các nhân viên phát triển tồi đó. Anh giải thích: “Tôi đã gởi họ đi học để cải thiện kỹ năng nhưng nhiều người đã cố che cái dở của mình hơn là tiếp nhận cơ hội phát triển kỹ năng. Thái độ tiêu cực này xuất phát từ quan niệm là họ cũng có bằng cấp (như ai) và không cần phải đi học lại nữa. Họ cũng không thích người khác giúp họ xem xét lại kết quả công việc của họ. Họ phàn nàn về làm việc nhóm, các quyết định của nhóm, và luôn có cớ ngụy biện cho việc làm của họ. Một số bảo với tôi rằng họ quá bận không có thời gian chữa lỗi, nhưng sẽ cố chữa sau, và rồi (chủ yếu) bỏ thời gian thử mã có chạy được không hơn là thật sự chữa chúng. Họ còn tìm kiếm thêm các ‘mánh’ mới từ các ‘chat-room,’ và thay vì hỏi các thành viên khác trong nhóm, họ nhờ ai đó trên mạng giúp đỡ họ vì chẳng ai sẽ biết được họ là ai cả.” Là một ông chủ và là một doanh nhân, anh bạn của tôi chẳng có mấy lựa chọn hơn là sa thải những nhân viên như vậy vì họ đã có những thái độ và thói quen xấu, khó mà thay đổi được gì.
 |
| "Mánh và thủ thuật" không bao giờ là giải pháp căn bản trong phát triển phần mềm. |
Anh bạn tôi nói: “Sau nhiều năm trong nghề, tôi đã học được cách làm thế nào để nhanh chóng phát hiện ra những người có ‘các thái độ xấu’ như vậy. Hàng tuần, tôi ra yêu cầu đánh giá lại thiết kế và mã lập trình trong từng dự án ở công ty. Rồi tôi cố tìm ra những đối tượng không muốn cho người khác xem việc mình làm, không tiếp thu đề nghị của người khác, không bỏ thời gian đánh giá phần việc của người khác, và thiếu hợp tác hay không sẵn lòng làm việc chung trong nhóm. Khi xem xét những gì các đối tượng này làm, tôi thường chẳng hiểu được thiết kế hay mã của họ vì chúng rất không logic, lộn xộn, và đầy những “mánh và thủ thuật” (chắp vá với nhau) hơn là dễ nhìn hay có chút logic gì. Nếu tôi làm lơ trước những thái độ như vậy, vô hình chung sẽ khuyến khích hơn nữa những thái độ xấu đó và rồi sẽ làm hại đến năng suất của các thành viên khác trong nhóm. Tôi không hiểu vì sao nhà trường lại không dạy gì về làm việc nhóm cho sinh viên vì đó là một thành tố cực kỳ quan trọng trong phát triển phần mềm, và tôi cũng chẳng hiệu tại sao trường học lại đào tạo ra những loại người như vậy?”
Tôi bảo với anh ta rằng: “Lý do chính vì sao nhiều người làm phần mềm mắc phải những thói quen xấu như vậy không phải vì làm phần mềm là khó mà là vì việc thiếu giảng dạy những nguyên tắc cơ bản về Công nghệ Phần mềm (cho họ).” Thậm chí đến ngày nay, có rất ít chương trình đào tạo tập trung vào thiết kế, kiến trúc, phương pháp lập trình, đảm bảo chất lượng, làm việc nhóm, và quản lý dự án. Hầu hết các trường đều vẫn chỉ dạy chủ yếu là lập trình, vì thế sinh viên chỉ có thể lập trình cho những dự án nhỏ và không làm được gì nhiều hơn thế. Nhiều sinh viên khác học đủ các “mánh và thủ thuật” trong quá trình học để có thể làm cho xong bài tập. Điều họ lại không học được trong quá trình đó là tính kỹ luật trong kiến thức, vốn cực kỳ quan trọng cho nghề nghiệp tương lai của họ, dù ngay trước mặt nó có thể chẳng mang lại lợi ích trực tiếp gì cả. Ngày nay, hầu hết các chương trình đào tạo (phần mềm) đều là từ ba đến bốn năm học lập trình (chay), và suốt thời gian đó sinh viên chỉ học cách viết các chương trình nhỏ để thỏa mãn các yêu cầu học tập của nhà trường. Đối với những người mới bắt đầu học máy tính, lập trình dường như là khó nhưng trong ngành phần mềm, lập trình (thực ra) chỉ là một phần nhỏ của cả dự án. Những sinh viên mới chỉ viết được vài ba chương trình nhỏ ở trường lại nghĩ rằng chuyển sang viết những chương trình lớn hay phức tạp hơn cũng tương tự như vậy, chỉ là viết nhiều hơn và tốn nhiều thời gian hơn. Thật sự thì KHÔNG PHẢI như vậy. Xây một túp lều (như tôi đã từng nói) khác xa việc xây dựng một tòa nhà 10 tầng. Việc xây dựng một tòa nhà lớn đòi hỏi đủ thứ kiến thức và kỹ năng khác nhau, mà thường là với yêu cầu chuyên môn cao hơn nhiều. Bạn chẳng thể nào xây dựng xong một tòa nhà lớn mà không cần có kiến trúc sư. Bạn không thể xây được một tòa nhà lớn nếu không có thiết kế. Đơn thuần chỉ bỏ gạch và xi măng lại với nhau không thể tạo ra được một tòa nhà lớn vì nó sẽ bị sập. Sự khác biệt về tính phức tạp giữa những gì sinh viên học (ở trường) và những gì ngành phần mềm thực sự làm cũng tương tự như vậy, và những ai chỉ biết học các “mánh và thủ thuật” thì sẽ không thể nào hiểu được khác biệt này. Vì thế, nhiều người đến trường học các thứ như email, Excel, PowerPoint, và web để “Google” tìm kiếm thông tin hay download nhạc, những người này có thể làm được các bài trình bày hay các bảng tính đơn giản, nhưng như vậy thì chỉ cần học trong vài tuần chứ cần gì cả năm học. Họ cũng có thể học cách lập trình C++ hay Java chỉ cần trong một hai năm chứ cần gì đến cả bốn năm. Thế nên, cái sinh viên thật sự cần học (trong bốn năm đó) là một kiến thức vững chắc về việc làm thế nào để viết được các chương trình tốt, làm thế nào để giải quyết các bài toán kinh doanh, làm thế nào để tạo ra các sản phẩm có chất lượng, và làm thế nào để làm việc được trong nhóm. Những kỹ năng này vượt ra khỏi phạm vi của việc lập trình; và thật sự đó mới là cái mà ngành phần mềm gọi là “phát triển phần mềm” hay “Công nghệ Phần mềm.” Và đó cũng là những gì mà ngành phần mềm ngày nay đang cần đến.
