Series chuyện đi làm – “Training” ải khó khăn và thử thách

Ở bài viết trước của “series chuyện đi làm”, mình đã kể về quá trình mình gia nhập công ty vào ngày đầu tiên như thế nào. Nhận được phản hồi khá tốt từ nhiều bạn, hôm nay tiếp tục kể về quá trình training ha.

Thời kì training khó khăn và thử thách

Toàn bộ các phần của Series:

Công ty mình hiện tại đang đi theo quy trình Agile, do đó thời kỳ training cho lính mới vô sẽ bao gồm luôn cả quá trình training về quy trình làm việc chứ không chỉ về kỹ thuật. Quy trình Agile là gì thì mình đã trình bày ở 2 bài viết trước rồi, mọi người có thể đọc lại.

Ải 1 – “Training” về quy trình và cách làm việc

Theo như mình được biết thì hiện nay tại Việt Nam, hầu như 100% sinh viên mới ra trường đều cần phải đào tạo lại về cách làm việc. Có nhiều lý do cho việc này mà nhiều công ty bắt buộc phải đào tạo lại các lập trình viên.

Thứ nhất, và cũng chiếm số lượng nhiều nhất – lập trình viên được học qua về cách làm việc nhưng sơ sài. Tại trường đại học nếu có thì cũng chỉ là vài buổi thảo luận, nói chuyện của một vài thầy cô nào đó. Nhưng chủ yếu sinh viên lên là để ngủ, chém gió với nhau, nếu có nghe thì một vài bữa cũng quên do không được áp dụng ngay vào thực tiễn.

Thứ hai, chiếm ít hơn – là do không có định nghĩa về cách làm việc. “Cách làm việc là cái beep gì? Bố đây éo cần, đưa project name với vài mô tả thì mở IDE lên quất thôi, không cần nói nhiều.”

Thật ra cách làm việc không phải là cách code thế nào khi được giao project name hay mô tả. Đó là cách thu nhận yêu cầu, cách trao đổi với nhau (với cấp trên, với bạn cùng team…), xác nhận thông tin với người ảnh hưởng đến dự án. Mình ví dụ:

Sếp: Ê H, mày làm cho tau cái task MH370 này nhé!

H: Dạ sếp, cứ chuyển nó qua cho em đi.

Sếp: Ngày mai là phải xong đấy, làm xong thì báo anh kiểm tra.

Xong cuộc trò chuyện, ông sếp quên cmn mất. Éo giao task cho H, vậy H phải làm gì? Đơn giản là nhắc ổng thôi phải không?

Rồi cái H bay vô làm lấy làm để mà éo kịp đọc cái mô tả. Thời gian trôi qua gần tới deadline rồi mà task chưa hoàn thành. May quá sếp bận họp và việc quá nhiều, ổng quên mất việc đã giao cho H. Phần hí hửng vì ổng quên, phần cũng do task chưa hoàn thành nên H không thèm báo ổng và vẫn cắm đầu code đến khi xong thì báo.

Vậy việc H làm là đúng, sai chỗ nào? Đúng và sai là cái các bạn sẽ được học ở thời gian training này, mình sẽ không phân tích ở đây. Công ty mình là công ty của Nhật, nên mình được học phong cách làm việc của người Nhật khá nhiều, công nhận tụi Nhật nó có nhiều cái khá hay. Học thì dễ nhưng hành thì khá khó và phải tập làm quen từ từ, một phần do mình quen tính nóng vội thời còn ngồi trên ghế nhà trường. Những lỗi thường gặp nhất trong công việc mà sẽ được training là: cách gửi mail, cách báo cáo, cách phản ánh vấn đề gặp phải, thời điểm và người thích hợp để báo cáo,….

Ải 2 – “Training” về kỹ thuật lập trình

Xong phần kỹ năng làm việc, tiếp theo là đến phần training về kỹ thuật lập trình. Thật ra vấn đề kỹ thuật thì ai vô công ty đều có biết ít nhiều, không phải ai cũng giỏi nhưng mình nghĩ tất cả đều biết.

Phần này các bạn sẽ được hỏi là “Em đã biết cái này chưa? Nếu chưa thì tự học đi, méo ai chỉ đâu. :)” Đùa đó, bạn sẽ được quẳng vào 1 team chuyên làm 1 thứ gì đó đại loại như Mobile, Framework PHP, CMS, Ecommerce,… Còn việc sao lại được vào team này thì tùy, có thể do bạn biết về thứ đó, cũng có thể do team đó cần người, và cũng có thể do bạn là con ghẻ thích cho vô đâu thì vô.

Nếu chưa biết về vấn đề mà team đang làm, bạn sẽ được training. Và tất nhiên mang tiếng training chứ gần như 99% là tự học, học trên công ty không biết thì hỏi, nếu muốn nhanh lên trình thì tối về nhà học thêm. Có 3 vấn đề mà mình đã học được ở phần training này và muốn chia sẻ một chút cho những ai chưa biết:

– Không nên hỏi quá nhiều: Có nghĩa là nếu bí một vấn đề nào đó, hãy tự tìm hiểu cho đến cùng. Kỹ năng tự học là một thứ quan trọng giúp mình nhanh lên skills hơn bất cứ thứ gì. Có thể tra tự học qua Google, stackoverflow, tips và tutorials share đầy rẫy trên mạng,… Hỏi người biết hơn mình có lợi là sẽ rất nhanh biết nhưng nó chỉ nên là phương án cuối cùng, sau khi thử hết cách rồi mà vẫn chưa ra.

– Hỏi người có khả năng: người có khả năng là người có thể giúp mình giải quyết được. Thứ nhất người đó phải trình cao hơn và giải thích dễ hiểu, nhiều người kỹ thuật rất tốt nhưng khả năng sư phạm hơi thấp nên nói đi nói lại vẫn như vịt nghe sấm. Thứ hai người đó phải đang rãnh task hoặc task chưa sát deadline. Đang bận mà đứa nào nhào vô hỏi bị ăn đập đừng trách mình nhoé, nguy hiểm quá.

– Hỏi thì nên hỏi rõ, giải quyết xong rồi thì nên nhớ để lần sau không mắc phải lần 2: Đây là một điều khá cơ bản mà đôi khi mình cũng mắc phải. Tức là nếu mình bị vướng chỗ nào đó, mình hỏi người khác và giải quyết được thì mình nên nhớ hoặc ghi chép ở đâu đó để lần sau không cần phải hỏi lại.

Thường mỗi khi học một ngôn ngữ hay nền tảng nào đó, mình hay làm mấy cái project nho nhỏ. Thích tùy biến, code kiếc kiểu gì đó miễn sao mình hiểu và vận hành trơn tru cái đã học. Cái hay của project này là sau này lỡ quên thì có thể nhìn lại, và cũng là cái để sau này nhìn lại và thấy code mình chuối thế nào trong những ngày đầu tự học đó.

P/s: mình có 1 cái project về Laravel, bạn nào hứng thú mình share cho. Vừa học vừa code, hết training thì vứt tới giờ chưa có thời gian xem lại. Code thì không có gì nổi bật, chuối là đằng khác nên đừng ném đá nhé.

Advertisements

2 thoughts on “Series chuyện đi làm – “Training” ải khó khăn và thử thách

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s