9 điều Developer muốn có hơn cả tiền bạc

Nhiều developer mà tôi viêt đã bước chân vào nghề lập trình từ khi còn “mài quần” ở trường trung học. Cho dù đó là trò chơi được xây dựng từ text-based trên Apple IIe hay là tạo ra một ứng dụng đội hình bóng đá trong Visual Basic thì họ làm vì muốn thử thách, muốn học hỏi.

Sinh viên tốt nghiệp đại học phải đối mặt với một thực tế đáng buồn, đó là khi họ rời khỏi sự bảo bọc của nhà trường và đi tìm công việc đầu tiên cho mình. Trong số bạn bè của tôi thì có người đã tìm được việc làm với mức lương khoảng 25,000$ khi ra trường, và rất ngạc nhiên khi mức lương khởi điểm cho công việc engineering và computer science đã tăng gần gấp đôi.

Nhưng phần lớn các kỹ sư trong lớp học của tôi đã không trở thành kỹ sư vì tiền. Chúng tôi làm bởi vì nó chạm đến một khao khát cháy bỏng, đó là để gây ấn tượng với bạn bè của mình.

Tiền là một yếu tố quan trọng với đại đa số, nhưng giả sử so sánh lương bổng thì điều gì làm cho một số công ty lại thu hút và giữ chân các developer, trong khi những kẻ khác thì xem developer như … giấy vệ sinh?

Một vài định nghĩa:

Vào những năm 1950, một nhà nghiên cứu tên là Frederick Herzberg nghiên cứu 200 kỹ sư và kế toán ở Mỹ. Ông hỏi họ một số câu hỏi đơn giản và đã đưa ra những lý thuyết về sự hài lòng trong công việc, được gọi là Two Factor Theory.

Lý thuyết của ông về sự hài lòng trong công việc được chia làm 2 yếu tố:

• hygiene factors (Yếu tố thiết yếu), gồm điều kiện làm việc, chất lượng giám sát, tiền lương, sự an toàn, và chính sách của công ty
• motivation factors (Yếu tố thúc đẩy), gồm các yếu tố như thành tích, sự công nhận, trách nhiệm, bản chất công việc, sự phát triển cá nhân và sự tiến bộ

Hygiene factors là điều cần thiết để đảm bảo các nhân viên không phải phật lòng, nhưng họ lại không đóng góp để đạt được level cao hơn.

Motivation factors là những gì tạo ra động lực và sự hài lòng trong công việc bằng cách đáp ứng các nhu cầu ý nghĩa và sự phát triển cá nhân.

1. Làm là để thành công

Đó là một thực tế đáng buồn, nhưng hầu hết các software project được thiết lập để thất bại. Mỗi developer đều có những câu chuyện kinh dị cho riêng mình: “anti-patterns” của software project. Tôi đã nhìn thấy một kiến truc sư đưa tài liệu của legacy system mà ông nghiền ngẫm trong 1 lúc trong khi vẫn đang thiết kế một giao diện mới cho sản phẩm. Sau khi hoàn tất thiết kế, ông phát hiện ra rằng các tài liệu đã được 3 năm tuổi đời và không mang lại các thay đổi lớn cho hệ thống.

Tôi đã dành nhiều giờ để chuẩn bị technical estimate thật chi tiết, cho đến khi biết được deadline thực sự đã được dựa vào product development, chỉ với một nửa thời gian mà tôi cần.

Deadline thực chính là phần quyết định sự thành công. Developer muốn xây dựng phần mềm không chỉ để nó làm được việc, mà còn phải duy trì, là một điều để họ có thể tự hào. Điều này không liên quan gì tới các mục tiêu phát triển sản phẩm.

Khi thời gian eo hẹp, điều đầu tiên cần chú trọng chính là chất lượng và khả năng duy trì. Bị buộc phải làm tào lao là một trong những điều tồi tệ nhất. Deliver project đúng hạn nhưng vẫn biết nó chưa hoàn chỉnh sẽ khiến người luôn tự hào về những gì họ làm cảm thấy như một sự thất bại.

Quan trọng nhất vẫn là làm việc đúng cách chứ không chỉ là làm thật nhanh. Tôi từng trò chuyện với một developer, anh cho rằng “Chất lượng quan trọng giống như số tính năng và ngân sách”.

Sắp xếp kế hoạch tuy không phải là điều duy nhất dễ khiến một dự án thất bại, nhưng nó lại được xem là lý do phổ biến nhất. Những nguyên do khác sẽ bao gồm: bị buộc phải sử dụng các công cụ rẻ tiền (có thể là phần mềm hoặc phần cứng), làm việc với một đối tác không deliver như đã hẹn, quản lý dự án kém, thay đổi scope và những mong đợi chất chứa nhưng không chịu nói ra.

2. Quản lý xuất sắc

Quản lý xuất sắc là yếu tố bắt buộc phải có để tạo động lực cho cả dự án và nhân lực. Điều này có nghĩa là không nên quản lý nhỏ lẻ, mà phải khuyến khích tư duy độc lập, hiểu được cần làm sao để xây dựng phần mềm chất lượng, quyết định nhanh, và sẵn sàng tinh thần chiến đấu cho cả team khi product development cần rút ngắn lịch trình.

Đây là những đặc điểm của một software manager tuyệt vời. Nhiều khi người này sẽ sẵn sàng đắm mình trong dầu sôi lửa bỏng để bảo vệ và hy sinh làm việc cả đêm để chứng minh quyền của mình. Khi một người quản lý “cầm súng lên nòng”, các developer giỏi sẽ có xu hướng quay sang hỗ trợ và sau đó kéo thêm vài người nữa.

Nó tạo ra lòng trung thành gần như là sùng bái, và kết quả là không chỉ thúc đẩy động lựa cho các developer nhà ta, mà còn mang đến sản phẩm phần mềm tốt đến mức kinh ngạc.

3. Học hỏi thêm nhiều điều mới

Một nghiên cứu hành vi đã chỉ ra rằng, chúng ta hạnh phúc nhất khi chúng ta đang học những kỹ năng mới hoặc đang thử thách những cái cũ. Một bài báo gần đây đã trích dẫn một nghiên cứu của 2 nhà nghiên cứu từ trường Đại học Columbia, cho thấy rằng người lao động sẽ tăng mức độ hạnh phúc lên 20% ​​nếu công việc cần nhiều kỹ năng hơn. Nghiên cứu này chỉ ra rằng chúng ta sẵn sàng được trả lương ít hơn cho công việc thú vị, hào hứng và dạy cho chúng ta những kỹ năng mới.

Đây là lý do tại sao các công ty sử dụng ngôn ngữ Ruby có thể tìm thấy các lập trình viên giàu kinh nghiệm sẵn sàng để làm việc với mức lương thấp hơn so với mức mà họ đáng ra phải nhận được.

Các developer mà tôi biết lại rất thích chơi với các công nghệ mới hào nhoáng. Đó là Perl và HTML vào giữa thập niên 90, ASP, PHP và Java vào cuối những năm 90, ASP.NET và XML một vài năm trước đây, và ngày nay là AJAX và Ruby (và ASP.NET 2.0). Hãy cho họ một cơ hội để sử dụng những món hàng này, họ sẽ không chỉ có thể gây ấn tượng với bạn bè mà còn giúp họ lắp đầy khao khát muốn được học hỏi.

Hãy để một developer tiếp tục học hỏi vì họ sẽ sẵn lòng làm việc trong điều kiện thiếu thốn. Và họ sẽ không bao giờ yêu cầu tăng lương.

4. Làm việc sáng tạo và giải quyết đúng vấn đề

Developer rất thích thử thách. Nếu không có chúng, ta sẽ cảm thấy buồn chán, tâm trí thì như lưu lạc phương nào. Buồn làm sao nếu ta hàng ngày phải cân bằng sổ tiết kiệm, kiểm tra email, nhấn Digg và Slashdot, đọc một vài blog, uống nước, thấy bạn bè online thì “nhảy vào” bàn luận những chuyện nhảm nhí, …

Tôi đã từng chứng kiến các developer sẵn sàng ở lại cho đến khi mặt trời mọc chỉ để giải quyết một vấn đề kỹ thuật mà không cần ai yêu cầu và cũng chẳng đòi hỏi lương bonus. Developer giỏi là những kẻ nghiện giải quyết vấn đề.

Đối mặt với thách thức đúng tầm, nhiều developer sẽ không nghỉ tay cho đến khi vấn đề được giải quyết ổn thỏa, đặc biệt là nếu nó đòi hỏi một giải pháp đặc biệt sáng tạo. Còn nếu là thách thức tào lao, thì họ sẽ quay lại chat chit với bạn bè và tiếp tục bàn luận những chuyện nhảm nhí.

Loại thử thách đúng là thử thách về kỹ thuật vì nó sẽ dạy cho họ một kỹ năng mới, tốt nhất là loại kỹ năng mà mọi người hay nói tới. Ví dụ: “Dùng 5 RSS feed này, tổng hợp dữ liệu, hiển thị các headline trên trang web … và tìm ra cách để sử dụng AJAX để làm cho nó đẹp mắt”.

Còn những thách thức tào lao sẽ là những thứ như: “Fix code của thằng kia đi. Mày biết đó, chúng ta không tranh cãi vì sợ thằng đó gây ra hiểm họa. Nó code hệ thống ghê lắm và bây giờ chúng ta cần phải sửa lại sao cho đạt chất lượng và có khả năng duy trì. À, deadline là ngày mai nhé!”.

Nếu công ty của bạn không mang đến công việc đầy thách thức cho dân developer, hãy ngẫm nghĩ lại làm thế nào mà bạn lập ra công ty được vậy? Nếu tự thấy sẽ không có cơ hội nào để bạn mang đến các công việc đầy thử thách, thì hãy đi tìm các hygiene factor developer, bởi vì motivation factor developer sẽ không ở lại lâu với công ty của bạn đâu.

5. Có tiếng nói

Developer sống trong “khu kháng chiến” và họ là những người đầu tiên biết khi hệ thống hoặc quy trình đang không hoạt động. Một developer đã nói nói với tôi rằng: “[Tôi muốn] một người nào đó có thể lắng nghe vấn đề của tôi và thực sự nhìn nhận nó một cách nghiêm túc. Tôi đã từng làm việc tại một vài công ty, nơi mà nhiều RAM, nhiều dung lượng đĩa cứng, hoặc CPU nhanh hơn không phải là ưu tiên hàng đầu, và điều này lại làm cản trở công việc của tôi kinh khủng. Có nơi tôi từng làm việc, mỗi lần muốn compile phần mềm, tôi đã phải xóa tất cả các file tạm thời chỉ vì không đủ disk space. Làm việc mà bị buộc phải sử dụng công nghệ lạc hậu thì thật sự rất bực bội.”

Khi một developer nói, chúng ta nên lắng nghe. Khi các developer cùng lúc phát biểu những điều tương tự thì ai đó nên lắng nghe và lập tức xử lý.

6. Được công nhận sự chăm chỉ

Là một engineer, chúng ta thích tạo ra những ấn tượng với bản thân và bạn bè của mình. Ít nhất là những người nhận ra khó khăn thế nào để viết Perl compiler. Từ đầu. Trong FORTRAN. Trên một Vic 20.

Tạo ra điều gì đó với kết quả tuyệt vời chính là một niềm vui, nhưng sẽ vui hơn nhiều khi có ai đó khen mình, mở tiệc mừng, khen bạn hết lời, hoặc mua cho bạn một phần bít tết. Hầu hết các developer đều thích nghe những lời khen và nhận được sự công nhận cho sự chăm chỉ. Ngay cả những người không cần khen thì đâu đó vẫn phảng phất sự tủi thân nếu không được nhận lời khen nó (hoặc tệ hơn nữa là người khác lại được sự công nhận trong khi công việc đó là của bạn).

Công nhận — Recognition là một trong những yếu tố cốt lõi giúp thúc đẩy động lực của Herzberg và nó áp dụng cho các software developer nhiều như các engineer ban đầu được phỏng vấn.

7. Tạo ra những điều có ích

Mặc dù chúng ta không phải nhân viên y tế ở Bosnia hoặc người vận chuyển thực phẩm ở Sudan, thì hầu hết mọi người luôn muốn làm một điều gì đó để thế giới trở nên tốt đẹp hơn, cả về công nghệ và xã hội. Một số người có thể nghĩ rằng mình làm điều đó chỉ vì lợi ích của công nghệ, nhưng trái lại, chúng ta tự thấy mình là một phần của vấn đề lớn đó.

Ví dụ, một người bạn của tôi làm việc cho một công ty tài chính. Mỗi khi họ tung ra một sản phẩm giúp cộng đồng tài chính “đỡ vất vả” hơn, họ sẽ rất vui mừng và trân trọng sản phẩm đó.

Albertsons — Một nhà phát triển phần mềm hàng tồn kho rất thích làm việc mỗi ngày bởi vì công việc của ông chính là dùng các thuật toán phức tạp để đảm bảo các loại ngũ cốc cho trẻ em luôn có mặt trên kệ.

Một kỹ sư phần mềm L.A. Times đã ngây ngất vì đã tạo ra phần mềm phục vụ cho việc giao báo. Những chiếc xe tải đang tiết kiệm hơn 30% quãng đường đi và chi phí nhiên liệu do chọn đúng con đường ngắn nhất để giao báo.

Mặt khác, thật nực cười khi viết một giao diện cho một API lỗi, được sử dụng tổng cộng 15 lần trong năm tiếp theo. Copy & paste toàn bộ ứng dụng và thay đổi một loạt các label có vẻ như chẳng thú vị như cách mà ta diễn tả.

8. Xây dựng phần mềm không cần sự phê chuẩn của “Hội đồng thẩm định”

Năm 2001, tôi từng là một nhà thầu trong 3 năm, và trong thời gian đó tôi đã xây dựng rất nhiều web application. Do bị off-site nên tôi đã trở nên quen với việc viết phần mềm cực nhanh một khi đã biết cần phải xây dựng điều gì. Tôi và một developer khác đã tạo ra một số lượng phần mềm khổng lồ trong cả 2 năm.

Công việc full-time tiếp theo của tôi đã khiến tôi có cảm giác như mình sụt hẳn 20kg. Đối với mỗi trang mà tôi muốn xây dựng, thì tôi phải meeting call với 6 người. Nếu có bất kỳ sự thay đổi về database, thì cần 3 approval. Thật kinh khủng, application này đã mất thời gian gấp 5 lần. Bực bội!

Thẩm quyền quyết định dự án mà không cần meeting call là rất lớn.

9. Ít luật lệ ràng buộc

Chẳng ai thích giao diện lỗi, code tào lao và data model được thiết kế kém. Quá nhiều luật lệ ràng buộc sẽ giết chết sáng tạo, đòi hỏi sự giải quyết của lãnh đạo, và thường lấy đi niềm vui trong xây dựng phần mềm.

Nếu bạn đang nắm giữ luật lệ, hãy cố gắng tìm ra cách để giảm thiểu tác động của nó đối với sự phát triển trong tương lai. Nếu bạn không làm được thì hãy tìm đến những developer đặt nhân tố thiết yếu (hygiene factors) lên hàng đầu, bởi vì các developer coi trọng các yếu tố thúc đẩy (motivation factor) sẽ không thể duy trì lâu các ứng dụng có chất lượng kém.

Kết

Nếu bạn là một nhà quản lý, lần cuối cùng bạn hỏi team developer những vấn đề này là khi nào?

Nếu bạn là một developer, lần cuối cùng bạn lên tiếng nghiêm túc một trong các vấn đề này là lúc nào? Hãy cho ví dụ và một giải pháp cụ thể.

Nếu câu trả lời là “lâu rồi”, thì bạn sẽ phải làm một việc. Đó là gửi bài viết này cho một vài đồng nghiệp của bạn và bắt đầu bàn bạc làm thế nào để tạo ra sự thay đổi.

Source: https://potato.fsoft.com.vn/2016/08/12/9-dieu-developer-muon-co-hon-ca-tien-bac/