Skills của một người kỹ sư giỏi

Skills của một người kỹ sư giỏi

Xin phép các bạn cho Thuyền được luận bàn về mục này và xin các bạn tham gia ...

Sống ở bên Mỹ này, thị trường jobs lao đao, nhiều sở làm sa thải hàng ngàn kỹ sư trong một tích tắc . Đa số, họ sẽ sa thải các kỹ sư dở, những người giỏi và cần, họ sẽ giữ lại về mang qua department khác, retrain lại hòng tiếp tục đóng góp cho company . Chuyện layoff sa thải thì Thuyền xin bàn ở một thread khác riêng biệt vì nó lớn lắm .

Topics này, Thuyền xin nói, nếu bạn có những skills cần cho sở làm, bạn sẽ được mướn hoài mà thôi .

Ngoài những kiến thức cúa chuyên ngành của bạn (hàng đầu), bạn còn cần phải có những skills khác, mẫu số chung của tất cả các kỹ sư không phân biệt ngành riêng . Sau đây là kinh nghiệm làm việc bao năm nay của Thuyền ...

1. Problem Solving Skills (giải quyết vấn đề)

Nếu bạn theo dõi các thống kê của 10 năm vừa qua trên khắp thế giới, skill đứng hàng đầu trong top 10 skills chính là problem solving skills . Thuyền không nhớ là đọc ở đâu nữa, nhưng chỉ nhớ 4 cái top skills đầu tiên thôi (tại cái thứ 4 có dính đê"n chuyên ngành của mình .

Thật vậy, problem solving skill đứng nhất . Nhì là medical skill. Ba là skill về luật pháp . Thứ 4 là các skills liên quan đê"n computer .

Dù mình có làm trong khâu design, hay khâu test, hay khâu verification của sản phẩm, mình đều có thể đương đầu với các problem cả . Và mình phải biết giải quyết chúng .

Nếu problem đó làm một problem hoàng toàn chỉ là về kỹ thuật chuyên ngành cúa bạn , và là một problem bạn nghĩ rất nghiêm trọng (serious issue), có tầm ảnh hướng đến các khâu khác hay các sản phẩm khác hoặc công việc trách nhiêm của đồng nghiệp (system impact), bạn phải biết giải quyết đúng với bài bản cúa một người kỹ sư chuyên nghiệp (professional engineer).

1.a report to upper management (thông báo cấp trên)

Phương tiện hay nhất là một cái email ngắn gọn hàm tích . Viết đâu ra đó . Mở đầu bằng phần "executive summary" . Tức là viết tóm tắt theo kiểu cho các cấp cao trong nấc thang của sở làm đọc (corporate ladder) . Càng lên cao trong sở làm, boss càng không muốn đọc nhiều, đọc chi tiết, mà chỉ muốn đọc tóm tắt hôi . Chỉ muốn đọc vài chữ mà hiểu tường tận . (đây là một sub-skill giu"p bạn thăng quan tiến chức sau này). Excutive summary cho thấy vấn là gì .

Sau đó, bạn cần viết đúng một câu về impact (nếu không sửa, không giải quyết thì sẽ bị gì)

Cuối cùng, bạn viết chi tiết về các phương pháp giải quyết vấn đề . Boss nếu lười đọc thì sẽ kêu bạn lên đối mặt nói chuyện cho lẹ . Còn nếu boss bạn cũng là dân technical như bạn, ông ta hay bà ta sẽ chăm chú đọc phần này thêm trước khi kêu bạn lên nói chuyện .

Cái phần chi tiết này , bao giờ bạn cũng phải có ít nhất là 3 phương cách để giải quyết vấn đề . Nó chứng tỏ sự thông minh và suy nghĩ tận triệt bề rộng của người kỹ sư . Xin nhớ, ngắn gọn nhưng đầy đủ . Viết bình dân giíup boss bạn hiểu dễ dàng . Boss nhiều chuyện phải lo lă"m, kể cả lo lắng tiền lưong bonus ngày nghỉ cho bạn, nên bạn phải thông cảm trình độ kỹ thuật của boss bạn .

Sau khi list tất cả options để giải quyết vấn đề, bạn cần phải có một cái bảng nhỏ đánh giá các options đó . Đánh giá xấp hạng chúng theo các mặt:
- phức tạp (complexity, có khó làm không)
- Bao lâu thì xong ? Cần bao nhieu nguoi làm ?
- có nguy hiểm không (risk), bao nhiêu cơ hội bạn không chắc mấy là có thể giải quyết được vấn đề
- sẽ làm bao nhiêu phần khác bị thay đổi vậy (degree of impact).
....
Bạn nên đánh giá chung bằng cách chung chung như là "high" , "medium", "low", giúp boss của bạn dễ phán quyết hơn .

Cuối cùng, bạn phải nêu ra cái nào bạn prefer nhất và cái nào bạn không thích nhất . Và vì lý do gi ?

Nếu bạn gửi một cái email như vậy đi cho boss bạn, vài lần như vậy, các cấp trên sẽ thấy ngay, bạn là người có problem solving skill !

Chúc bạn là một người kỹ sư giỏi ...

(sẽ viết tiếp các skill nữa ...)

Anh Thuyền khởi tạo một mục phải nói là rất quan trọng, mà nhiều người có nhu cầu tìm hiểu. Bản thân tớ trước trong quá trình đào tạo cũng thắc mắc không biết mình phải có những kỹ năng gì để ra đời làm việc. Những kỹ năng này tớ chưa thấy có một trường lớp nào dạy, hoặc là có một buổi nói chuyện nào đó của giáo sư nói về vấn đề này. Những bạn học cùng cũng không thấy thắc mắc. Tuy nhiên tớ cũng phải tự đúc kết một số kinh nghiệm ( chưa dám phát triển thành kỹ năng he he he ) bản thân trong quá trình học tập / nghiên cứu. Giờ tớ cứ ngồi bịt miệng đọc bài anh Thuyền đã, nếu tớ thấy tớ có gì mà anh Thuyền chưa đề cập , tớ sẽ bốt lên đây.
Anh Thuyền cứ từ từ bốt lên nha ...

Hi anh bạn của Thuyền,
Thuyền chỉ việc viết lại các phương cách làm việc trong sở Thuyền hiện nay đó . Sở làm của Thuyền, Nortel Network, là nơi đào tạo ra rất nhiều kỹ sư giỏi có lối làm việc rất efficient và professional . Người Việt mình bảo là, "toàn tay chiến, special force trong R&D (Research & Development) không á !".
Thuyền thấy hay hay nên viết lại ...
Tuy nhiên, đó là hãng lớn, cũng là phương pháp làm việc của hãng lớn . Từ từ rồi Thuyền cũng sẽ kể kinh nghiệm làm việc của những hãng nhỏ .
Tất cả kinh nghiệm viết ra, sẽ có cái hay cái dở . Nên Thuyền mong các bạn cứ việc phê bình và mổ xẻ cho box thêm vui ...
Anh RW cũng phải viết thêm kinh nghiệm của anh đó nha ... Thuyền sẽ đòi nợ đến cùng đó ! Admin phải làm gương chứ hihih (kidding, chọc anh đó)

Thuyền xin phép viết tiếp chủ đề này ...
1.b Brainstorming với đồng nghiệp
Nhiều cái đầu cùng hợp lại thì sẽ giúp cho vấn đề được giải quyết một cách đúng đắn và triệt để hơn . Vì vậy, cho dù bạn đã tự nghĩ ra các câu trả lời , đã gửi email report cho cấp trên, bạn cũng nên mở một email thread khác cho các bạn đồng nghiệp của bạn trong sở làm, và mở đầu bằng một cách thân thiện casual như là :
"Hey guys, i would like to bounce off my ideas with you experts all, just to make sure to uncover any of my shortcommings ..."
(tạm dịch: ê tụi bay, tao muốn tụi bay duyệt thử cái này của tao xem tao có sơ suất cái gì không nha)
Bạn nên để boss của bạn vào cái "cc" list của email để chứng minh cho cấp trên biết, bạn có mời các ý kiến khác xét dùm cho bạn .
Thường thì bạn nên để một cái hạn cuối vì trong sở làm, chắc chắn ai cũng bận rộn với project công việc riêng của họ cả ! Thí dụ như là, để cuối email một dòng chữ :
"Nếu tôi không thấy các bạn reply trong 48 tiếng đồng hồ là coi như các bạn ok rồi đó nha"
Giả dụ, các đồng nghiệp của bạn reply email và căn vặn, tranh luận, cuộc tranh luận nếu kéo dài hơn từ 5 hoặc 7 cái reply trở lên, bạn nên tuyên bố :
"At this point, the email forum seems to be inadequate for your discussion . I would like to book a room and we all get together brainstorming to resolve this"
(tạm dịch : Đến lúc này thì diễn đàn email không đủ cho chúng ta thảo luận rồi . Tôi đề nghị, mình cùng gặp nhau mặt đối mặt để vặn óc ra giải quyết . Tôi sẽ kiếm phòng họp )
Bạn phải nhớ, đồng nghiệp có căn vặn bạn hoặc đả phá cái solution của bạn, không phải là họ ghét bạn mà chính là họ thương bạn đó . Bạn cần phải cám ơn họ . Vì có vậy, lỡ về sau có sai hoặc chuyện gì xảy ra, bạn đã làm hết đủ mọi sức trong tầm tay của bạn và các đồng nghiệp của bạn cũng có một phần trách nhiệm trong đó rồi .
Ngược lại, bạn cũng nên tham dự các brainstorming hay reply email giup đỡ cho các đồng nghiệp . Chính boss của đồng nghiệp sẽ thấy bạn là người giỏi và "làm thêm" hơn cả nhiệm vụ sở giao .
Trong các buổi brain-storming của chính bạn, bạn nên xung phong là người sẽ viết meeting minute (tóm tắt quá trình và kết quả của buổi họp) và nên là người moderate cho buổi họp . Tức là, khi có 2 cách mà cả 2 đều bằng nhau, phòng họp chia thành 2 phe, bạn phải đứng ra và chọn một cách , quyết định cho buổI họp . Bạn phải là người drive buổi họp . Drive một cách khéo léo . Bă"t đầu buổ>i họp, bạn sẽ phải nói nhiều để trình bày giải thich background của issue cho mọi nguoi cùng biết . Trong buổI họp thì bạn cũng nên im lặng để các đồng nghiệp có cơ hội tranh cãi với nhau . Bạn nên lắng nghe và nên hỏi họ cặn kẽ để hiểu họ muốn gì . 5 phut trước khi cuộc họp chấm dút, bạn nên khéo léo đứng ra quyết định cho hướng đi .
Đó chính là với peer của mình đó bạn !

Thường thì khi project của bạn còn trong giai đoạn sơ khai , bạn sẽ phải trả lời các câu hỏi : "what", "why" , "how" . Brainstorming là phuong pháp giúp bạn lợi dụng các đồng nghiệp của bạn để trả lời các câu hỏi đó .
Sau đây là các điều luật bạn phải nhớ về phương pháp brainstorming ...
1. Thu lượm càng nhiều ý tưởng càng tốt . Tránh phê bình hoặc xét đóan các ý tưởng khi họ đưa ra . Càng nhiều càng tốt . Dù có nhiều cái idea rất là khùng và dở . Mục đính là kích thích óc sáng tạo . Đây chính là bề rộng của bộ óc .
2. Sau khi brainstorming chấm dút, lúc đó, mình mơ"i đi từ ý tưở"ng một mà bàn luận, mà mổ xẻ . Đây chính là bề sâu của bộ óc
3. Không nên chê trách bất cứ ý tưởng nào . Đừng cười, nhăn mặt hay biểu lộ cảm xúc chê trách . Tất cả ý tưởng đưa ra đều như nhau cả . Bạn cần phải tỏ ra mình có thái độ professional !
4. Cứ việc đưa ra các ý tuởng dựa trên các ý tưởng trước . Không có chi sai trái cả nếu bạn lấy ý tuong trươ"c của người khác, đổi đi vài khía cạnh, và đưa ra, đó là một ý tưởng sáng kiến mới .
5. Nên viết tất cả ý tưởng và đánh số chúng trên bảNg cho mọi người cùng nhìn thấy . Tạo điều kiện dễ dàng cho mọi người phát huy thêm sáng kiến mới để đưa ra
6. Nên ấn định một thời gian nhất định cho brainstorming activity . Thí dụ như 15'' hoăc 30 phút . Thường 30'' là đủ lâu rồi đó bạn .
Để quyết định chọn một option, một là vote, hay là thảo luận phân tích và assign priority cho từng cái option .

1.c Làm sao chắc là solve được problem vậy ?
Đây là khâu quan trọng nhất trong các skills về solving problem của kỹ sư chúng mình .
Thật vậy, có khi ta quá chú trong tìm ra giải pháp, ra solution, mà quên di khía cạnh test nó, verify nó . Một solution mà không có khả năng để mình test cái solution đó, making sure là vấn đề được giải quyết 100% thì quả thực là tai hại .
Viết thì đơn giản vậy đó, nhưng trong các ngành như software engineering, hay chính hardware luôn nữa, có nhiều vấn đề, nhiều problem không xảy ra một cách cố định . Có khi xảy ra có khi không . Vậy thì làm sao bạn chắc là bạn đã fix nó ? Hay là chỉ mot thời gian sau, nó lại xảy ra và bạn lại đổ thừa là ... tại vì nguyen nhân khác . Hoặc vân đề problem bị biến tướng đi , (mutated) , biết thành một dạng khác ?
Vì vậy, bạn cần phải hoạch định ra một vài phương pháp mà bạn có thể chứng minh được là giải pháp bạn chọn sẽ 100% giải quyết được vấn đề . Quan trọng là phải có kết quả cụ thể để thuyết phục được khách hàng, nhất là khách hàng của bạn không phải là dân kỹ sư như bạn .
Thí dụ nhé, cái thang máy có khi chạy có khi không . Cái máy printer lâu lâu bị tắc giấy . Cái mạch điện lâu lâu bị noise, bị ringing hay spike bất tử ... Bạn là người kỹ sư, nếu bạn là dân kỹ sư professional đúng nghĩa, bạn sẽ phải có cách nào đó chứng minh cho người khách hàng (hoặc boss của bạn) biết là vấn đề đã được sửa hoàn toàn .
Có nhiều khi, trong mấy cái solution, bạn có thể chọn cái không mấy hay ho, chỉ vì cái solution đó có thể test được mot cách dễ dàng .

2. Ước lượng, phán xét một cách khoa học
Kỹ sư chúng ta khác với bên các nhà toán học . Chúng ta nhiều khi sẽ bị rơi vào các tình huống cần có một cái óc phán xét ước lượng (estimate) một cách nhạy bén . Cần có common sense mà không cần phải có những công thức phương trình chính xác .
Thí dụ nhé, đứng trưóc một con sông, cần phải biết con sông đó rộng bao xa, một nhà toán học sẽ lập tức viết ra các phương trình, tìm đến một công thức chính xác mà câu trả lời là một khái quát và được chứng minh rõ ràng . Người kỹ sư không cần phải vậy . Họ có thể dựa trên kinh nghiệm và các giác quan common sense của họ tìm đê"n câu trả lời một cách thông minh . Clever và không nhất thiết phải intelligent đó, các bạn biết không . Kỹ sư có thể nhìn suy từ bề rộng của con đại lộ sau lưng của mình dựa trên bóng cây ngả trên ánh nắng, từ đó ước tính tỷ lệ rồi suy qua bề rộng của con sông và có thể đưa ngay ra một câu trả lời đại khái phỏng chừng (thí dụ, khoảng 1000 met)
Trong khi làm việc, đây là một trong những skill rất quan trọng giup ta estimate công việc của ta, hay của người dưới quyền, sẽ tốn bao nhiêu công sức . Và từ đó, dự trù kế hoạch, ấn định thời điểm để deliver sản phẩm đến cho khách hàng . (hoặc thời hạn sẽ xong cong việc cho boss của mình biết).
Trong công việc hàng ngày, có rất nhiều chuyện, hầu như 95% là đều dựa trên khả năng estimate của người kỹ sư cả . Làm càng lâu, càng có nhiều kinh nghiệm trong công việc, người kỹ sư càng phát triển khả năng này thêm nhậy bén và chính xác .
Bạn cần phải ý thức chức năng của mình . Đừng vì mình giỏi toán rồi cặm cụi ngồi xuống xẻ đôi sợi tóc ra mà mất bao thì giờ quý báu . Cũng cần phải ý thức được, đâu la `cần sự chính xác, đâu là sai số bao nhiêu thì có thể tolerable được nhé !
Ngành nào của kỹ sư cũng cần cái chức năng này đó, các bạn ! Chúng ta thường cần phải có một đầu óc bén nhọn, suy nghĩ thật nhanh, và phải biết control sai số !
Được thuyenxaxu sửa chữa / chuyển vào 07:29 ngày 07/02/2005

Tiếp tục đi, hay lắm.

Welcome bạn TinhCaVungTau ... Rất vui khi được bạn tham dự vô box !
Cám ơn bạn đã khích lệ Thuyền . Làm Thuyền có hứng và viết xàm xàm thêm cho đến khi hết còn hứng hén ..

3. Quán triệt và xài 2 chữ "thực tế" !
Đây là một chuyện quan trọng hàng đầu mà các bạn kỹ sư cần phải rèn luyện từ thủa còn mài quần trên ghế giảng đường . Cần phải biến nó thành một phản xạ, thành một "second nature" của chính mình . Tức là, suy nghĩ hành động lúc nào cũng phải hướng dẫn bởi 2 chứ đó, phải "thực tế" đó các bạn .
"Thực tế" là sao đây ?
Là khi mình suy nghĩ, mình làm ra một cái sản phẩm gì, mình cũng phải đặt hàng đầu là sản phẩm của mình có dùng được không ? có giúp ích gì cho cuộc sống chung quanh mình hoặc đà tiến của nhân loại chăng ? Nó khác hoàn toàn với bên Nghệ Thuật & Âm Nhạc, làm ra ra cho vui hay cho đẹp hoặc để cho relaxed tâm hồn ... Hay nó cũng khác với bên Toán Học là đi tìm các hệ quả, mổ xẻ chứng chứng các mệnh đề logics chân lí, rồi để đó, hy vọng một ngày nào đó, một tay kỹ sư hay applied scientist nào đó sẽ dùng đến công trình của mình để tạo ra ích lợi cho xã hội .
Khi bạn làm việc , lấy thí dụ là bên software engineering đi, bạn viết program ra không phải để cho vui . Có mục đích hẳn hòi và người ta có thể xài được . Đừng có để khách hàng đặt mua sản phẩm, ký contract cho đã, nhận program của bạn thì khám phá ra trong 10 chức năng bạn tao ra, chỉ có 3 chức năng là họ xài được còn 7 chức năng kia là ... "trên trời dưới đất" mà thôi .
Sản phẩm của bạn phải "dùng được" và dùng một cách hữu hiệu. Không chỉ effectively mà còn efficiently !
Chúng ta phải chú trọng nhiều đến chức năng của sản phẩm . Còn vẻ đẹp thì để dành cho các tay khác tư vấn góp ý và đóng góp công lao ...
Viết về cái mục này .. Giới kỹ sư trên thế giới thường mang kỹ sư Pháp và kỹ sư Đức ra làm ví dụ . Người Pháp thường méo mó với truyền thống art của họ và khiến kỹ sư của họ thường bị méo mó theo . Ngược lại, kỹ sư Đức rất ư là thực dụng .
Thuyền may mắn có cơ hội làm việc ở cả 2 nước trên và thấy quả là 2 thái cực . Tất nhiên, cuộc bàn luận này chỉ có tính tương đối và khong đúng hoàn toàn . Sẽ có một số trường hợp ngoại lệ . Thí dụ, trong computer graphics hoac trong kỹ nghệ quảng cáo, film ảnh hollywood . Người kỹ sư trong lãnh vực đó thường có thêm mức hiểu biết, thêm tài hoa, và thậm chí cả thêm degree bằng cấp bên art & entertainning á ! (Cái này thì hông tính à nha ... )