Họ có được những người phát triển phần mềm có kinh nghiệm đón chào không? Họ phải mất bao lâu để làm việc như một tổ? Phải mất bao lâu để người mới được tuyển học điều họ cần để có năng suất? Đó là những câu hỏi tôi muốn biết cho nên tôi đã dành vài tháng tới thăm các công ti phần mềm ở Mĩ và châu Âu và phỏng vấn người ở đó.
Điều tôi tìm thấy thật thú vị nên tôi muốn chia sẻ với các bạn để cho các bạn có thể có khả năng tránh những sai lầm người khác đã phạm phải. Tôi cũng tin rằng vấn đề này sẽ được nghiên cứu thêm nữa để làm giảm thất vọng từ cảnh quan của nhân viên mới và cũng từ người quản lí dự án đi thuê người mới cho dự án.
Nhiều người bảo tôi rằng là nhân viên mới thường được phân công cho “nhiệm vụ làm quen,” tại đó họ được trao cho các tài liệu để đọc và cập nhật. Bởi vì họ không biết mấy về các dự án, họ bị lẫn lộn và một số người đã phạm sai lầm cần phải được sửa chữa về sau bởi những người có kinh nghiệm hơn. Sau vài tuần đọc tài liệu, họ được trao cho mã để kiểm điểm và thực hiện thay đổi nhỏ để cho họ có thể học được từ những việc “làm việc về mã” đó. Sau vài tháng sửa mã họ được trao cho các chương trình nhỏ để viết khi họ đã cải tiến tri thức của mình, nhưng cũng vẫn phải mất thời gian dài để hiểu làm sao công ti vận hành và phần mềm tất cả là để làm gì.
Khi người mới tham gia vào công ti, tất cả họ đều có những kĩ năng khác nhau tuỳ theo điều họ đã học ở trường và trường mà họ xuất thân ra. Một số người thích viết mã trước rồi hỏi câu hỏi sau. Một số muốn thảo luận chi tiết trước khi làm bất kì cái gì. Bởi vì hầu hết người quản lí đều rất bận rộn, họ không chú ý đủ tới công nhân mới. Nhiều người không biết phải làm gì bên cạnh việc được phân công cho họ cho nên một số dùng máy tính của công ti để tìm kiếm trên web về “các website thú vị”.
Một số thậm chí còn chơi trò chơi video bởi vì có kết nối internet tốt, khi họ bị bắt họ bị kỉ luật và thậm chí bị đuổi. Bởi vì các kĩ năng khác nhau, những người mới được thuê nhìn các vấn đề theo những cách khác nhau và có những ý tưởng khác nhau về cách chúng nên được giải quyết. Bao giờ cũng là khó trong vài tháng đầu đối với mọi người mới được tuyển bởi vì nhiều ý tưởng mới đã được thực hiện theo cách thiếu kinh nghiệm và vụng về.
Những người mới không biết cách làm việc trong tổ cho nên họ thích tranh cãi với người khác để “khoe khoang” kĩ năng của họ. Một số thảo luận là tầm thường nhưng số khác lại nghiêm chỉnh hơn. Ý kiến khác có thể dễ dàng chấm dứt trong “Ai biết nhiều hơn” hay “Công cụ nào tốt hơn.” Một số người có xu hướng “theo sự kiện” nghĩa là họ KHÔNG đồng ý với bất kì cái gì chừng nào họ chưa có đủ dữ liệu. Họ thích biết đích xác thông tin nào có đó trước khi họ đồng ý với bất kì giải pháp nào. Nhiều người thuộc kiểu “Nhanh và sống” và muốn làm mọi thứ bây giờ rồi sửa chúng về sau, họ có nhiều năng lượng và muốn chứng minh cho người quản lí rằng họ là “người giỏi nhất” và biết cách làm mọi thứ “theo cách đúng.”
Vấn đề thông thường nhất trong nhiều công ti là thiếu đào tạo người mới và làm cho họ cảm thấy được đón chào. Phần lớn công ti phần mềm đều nhỏ và bận rộn cho nên họ không muốn đầu tư vào đào tạo người mới hay hướng dẫn tương ứng. Nhiều người quản lí bận rộn thế và họ muốn những người mới được thuê làm việc ngay khi những người này có thể làm thay vì dành thời gian để đào tạo những người này trở thành “nhà chuyên môn” hay thảo luận về cuộc sống bên ngoài công việc. Nhiều công ti có các cuộc họp hàng tuần nơi mọi người nói về các vấn đề nhưng lại tập trung vào các vấn đề kĩ thuật, các thứ họ không thể giải quyết được, hay các quyết định chính mà người quản lí phải ra thay vì cách đưa người lập trình mới được tuyển vào dự án.
Khi tôi phỏng vấn người quản lí phần mềm, nhiều người phàn nàn rằng người mới được tuyển không có kĩ năng mà công nghiệp cần. Ví dụ được trích dẫn nhiều nhất là hiểu quản lí cấu hình vì nhiều người mới được tuyển KHÔNG biết về kiểm soát phiên bản cho nên họ thay đổi mã tuỳ ý thích mà không có qui trình kiểm soát chính thức nào. Sai lầm thứ hai những người mới thường phạm phải là KHÔNG tuân theo qui trình chuẩn. Một người quản lí hỏi tôi: “Trường có dạy về “qui trình phần mềm” hiện nay không? Sinh viên có hiểu rằng họ phải tuân theo các chuẩn của công ti không?” Đây là vấn đề nhạy cảm, đặc biệt đối với các sinh viên khoa học máy tính và sinh viên được đào tạo trong các trường hướng nghiệp, không có giáo dục chính thức về kĩ nghệ phần mềm.
Mọi công ti bao giờ cũng có mức độ chính thức nào đó về công việc của họ hay “Qui trình chuẩn.” Một số qui trình được làm tài liệu tốt nhưng số khác có thể không được làm tài liệu chút nào nhưng những người ở đó biết bởi vì đó là cách tổ vận hành. Chẳng hạn, kiểm thử có thể rất chính thức và phải được thiết kế sớm hay có thể viết kiểm thử sau khi viết mã như một cách giải quyết sau. Tuỳ theo loại dự án và độ phức tạp của công ti, điều đó có thể yêu cầu những người mới được tuyển phải làm quen với qui trình nào mà dự án dùng.
Điều rất quan trọng cho người mới được tuyển là đi tới đồng ý với tổ của mình về cái gì là qui trình chính thức chấp nhận được tối thiểu bởi vì từng người mới làm thay đổi năng suất của tổ. Người mới được tuyển phải học để có năng suất nhiều nhất có thể được vì cả tổ sẽ bị ảnh hưởng bởi việc có người mới nữa. Một phần của vấn đề này là những người khác nhau có ý tưởng khác nhau về “năng suất” nghĩa là gì. Vấn đề là tổ thường làm những điều này theo cách đặc thù và thuận tiện cho họ. Sẽ khó cho người mới được tuyển học nhanh chóng vì đôi khi những điều họ đã học trong trường sẽ không có tác dụng trong công nghiệp.
Vấn đề chính với người mới được tuyển là phải kiên nhẫn và học tập. Một khi họ tự tin thì họ có thể được chấp nhận như một phần của tổ. Công việc tổ thường có vấn đề chính với người mới được tuyển vì họ KHÔNG được dạy cách làm việc trong tổ. Họ KHÔNG biết cách hỏi sự giúp đỡ vì họ sợ bằng việc hỏi quá nhiều câu hỏi, họ có thể bị đánh giá là “Không đủ năng lực.” Phải mất thời gian để học cách toàn thể công ti vận hành và cảm thấy cách các cấu phần khớp với nhau. Trong khi điều quan trọng là bắt đầu trong một dự án nhưng điều dễ cho người mới được tuyển là bắt vào mảnh nhỏ và không bao giờ thấy mảnh của họ làm gì cho toàn thể công ti.
Những người có kinh nghiệm có thể giúp đỡ bằng cách giải thích nghiệp vụ của công ti cho người mới được tuyển sau một hay hai tháng ổn định công việc, để cho qui trình nghiệp vụ không bị mất hút trong quá tải thông tin của tháng đầu tiên. Người mới được tuyển cần biết rằng trong khi họ bắt đầu từ việc nhỏ, để thực sự có ích họ ít nhất cũng phải biết cách bộ phận dự án của họ khớp với “bức tranh lớn” và phải học nhiều hơn và việc hỏi được cần tới để tìm ra về điều đó.
Những phàn nàn khác mà nhiều người quản lí nói với tôi là nhiều người mới được tuyển viết “quá nhiều” mã mà không kiểm xem thư viện “dùng lại” có không. Trong phần lớn các công ti, có chỗ cất giữ “tài liệu dùng lại” nhưng người mới được tuyển hiếm khi nhìn vào trong nó. Người mới được tuyển về căn bản sẽ cố “viết lại mã” cho toàn thể hệ thống trong vài tuần đầu của họ theo việc làm. Họ được đào tạo viết mã nhưng không nhiều về các khía cạnh khác của phát triển phần mềm, họ đã KHÔNG để thời gian học cách bố trí mã, lí do cho điều đó, và ai đang dùng nó. Họ nhảy vào trong “viết mã” theo cách lớn lao và phạm nhiều sai lầm.
Tôi tin tưởng mạnh mẽ đào tạo và kèm cặp là cách tốt nhất để đem người mới được tuyển vào trong công ti. Nếu bạn chấp nhận ai đó mới trong tổ của mình, hãy chắc dành thời gian nói với họ về cách mọi sự được thực hiện và hỗ trợ họ để cho họ cảm thấy được đón chào vào dự án. Đây là đầu tư tốt nhất mà tổ có thể làm để cải tiến năng suất và xây dựng công việc tổ.
What happened when newly graduated students join a software company? Are they welcomed by the experienced software developers? How long will it take for them to work as a team? How long will it take for new people learn what they need to be productive? Those were questions that I wanted to know so I spent several months visiting software companies in the U.S and Europe and interviewed people there. What I found were interesting so I like to share with you so you may be able to avoid mistakes others had made. I also believe that this issue must be investigated further to reduce frustrations from the perspective of a new employee and also from project manager hiring new people into project.
Many people told me that as new employees they were assigned “familiarization tasks” where they were given documents to read and update. Because they did not know much about the projects, they are confused and some had made mistakes that had to be corrected later by more experienced people. After several weeks of reading documents, they were given code for review and made small changes so they can learn from these “working codes”. After several months of fixing code they were given small programs to write as they were improving their knowledge, but it had taken a long time to understand how the company operated and what all of the software was for.
As new people join company, they all have different skills depending on what they have learned in schools and what schools that they came from. Some like to code first then ask questions later. Some want to discuss in detail before doing anything. Because most managers are very busy, they do not give enough attention to new workers. Many do not know what to do beside works assigned to them so some use company computers to search the web for “interesting websites”. Some even play videogames because of good internet connection, when they got caught they are disciplined and even fired. Because of different skills, new hires see problems in different ways and have different ideas of how they should be solved. It is always difficult in the first few months for every new hires because many good ideas were implemented in a clumsy and inexperienced way.
New people do not know how to work in team so they like to argue with each others to “show-off” their skills. Some discussions are trivial but others are more serious. A different opinion could easily end up in “Who know more” or “Which tool is better”. Some people are “Fact driven” which mean they do NOT agree with anything unless they have enough data. They like to know exactly what information there is before they agree to any solution. Many are “Fast and furious” and want to do everything now then fix them later, they have a lot of energy and want to prove to manager that they are “The bests” and know how to do things the “right way”.
The most common problem in many companies is the lack of training for new people and makes them feel welcome. Most software companies are small and busy so they do not want to invest in training new people or guide them accordingly. Many managers are so busy and they want their new hires to work as soon as they can rather than spending time to train them to become “Professional” or discuss life beyond work. Many companies have weekly meetings where people talk about issues but most are focusing on technical problems, things that they can not solve, or major decisions managers must make rather than how to bring newly hired programmer into the project.
As I interviewed software managers, many complained that new hires do not have skills needed by industry. The most cited example is the understand configuration management as many new hires do NOT know about revision control so they change code as they like without any formal control process. The second mistake new people frequently made are NOT following standard process. One manager asked me: “Does school teach “software process” today? Do students understand that they must follow company’s standard?” This is a sensitive issue, especially to computer science students and students who are trained in vocational schools that do not have formal education in software engineering. Every company always has certain level of formality for their works or “Standard process”. Some are well documented but other may not be documented at all but people who work there know because it is the way the team operates. For example, testing could be very formal and must be designed early or it is possible just write test after coding as an afterthought. Depending on the kind of project and sophisticated of the company, it may require new hires to get familiar with what process that the project uses. It is very important for new hires to come to agreement with their team about what is the minimum acceptable formal process because each new person changes the productivity of the team. The new hires must learn to be as productive as possible as the whole team will be affected by having new people too. Part of the problem is different people have a different idea of what “productivity” means. The issue is the team used to doing things in particular ways and comfortable with them. There will be difficult for new hires to learn quickly sometimes the things that they learned in school will not work in the industry.
The main thing for new hires is to be patient and learn. Once they are confident then they can be accepted as part of the team. Teamwork is often a major issue for new hires as they are NOT taught how to work in team. They do NOT know how to ask for help, or how to ask questions as they are afraid that by asking too many questions, they may be judged as “Incompetent”. It takes a while to learn how the whole company operates and feel for how all components fit together. While it is important to start in one project but it is easy for a new hires to get caught up in that small piece and never see what their piece is doing for the whole company. Experienced people can help by explain the business of the company to new hires after a month or two of settling in, so that the business process do not get lost in the information overload of the first month. New hires need to know that while they are starting small, to be really useful they should at least know how their part of the project fits the “big picture” and should do more learning and questioning needed to find out about that.
Another complains that several managers told me is many new hires write “too much” code without checking the “Re-use” library. In most companies, there are places to store “Re-use materials” but new people rarely look into it. New hires will typically try to “re-code” an entire system in their first few weeks on the job. They are trained to code but not much in other aspect of software development, they have NOT take time to learn the code layout, the reasons for it, and who is using it. They just jump into “Coding” in a big way and make a lot of mistakes.
I strongly believe training and mentoring are better ways to bringing new hires into the company. If you are accepting someone new into your team, make sure you spend time talk to them about how things are done and support them so they feel welcomed in the project. This is the best investment a team could do to improve productivity and build teamwork.
