Hoc tieng Nhat

スケジュールを引く: Tạo schedule Vì schedule, dạng gant chart, giống đường thẳng nên họ nói giống như 線を引く ただし: (trong đó, tuy nhiên), dùng để bổ sung cho vế trước しかし：Nối 2 vế ngược nhau

Noi luc cong ty

Question: Công ty có nêu đầu tư thời gian, tiền bạc để đào tạo nhân viên hay không?

Tôi nghĩ  những người muốn học tiếng Nhật:

* Có tinh thần có gắng và tiến thủ
* Muốn gắn bó lâu dài với Nhật.

Gạt chuyện giữ người sang một bên (họ không làm cho công ty chúng ta thì cũng làm ở đâu đó)
mình nên khuyến khích những người này bằng cách:

* Đào tạo họ (cả tiếng Nhật và kỹ thuật)
* Hỗ trợ khoảng 30% tiền ăn trưa cho những người học tiếng Nhật.

Về ngắn hạn thì công ty phải bỏ phí, nhưng về lâu dài, công ty sẽ có đội key và BSE mạnh.

Trao doi ve BSE

Xem hình dưới

Theo slide đã tham khảo

Level 1 SE < BSE < Level 2 SE < Level 3 SE < Level 4 SE

Anh nghĩ điều này cần giải thích thêm

1.  Level SE là đủ trình độ để trở thành BSE
2. Tuy nhiên, Level 2, 3, 4 SE làm BSE thì càng tốt.

Anh đồng ý

BSE = SE + communication skills + alpha

Nếu mổ xẻ alpha ra thì có lẽ nó đều là common sense.

Communication skills có thể đào tạo được.

Vậy với BSE ngành IT, nếu có là SE+, thì cần kỹ thuật gì?
Anh nghĩ những kỹ thuật này được liệt kê trong IPA skill sheet ở trên.
BSE cần có nhiều kỹ năng, càng nhiều càng tốt, đặc biệt ở cột
IT architecturre, Project management, IT specialist, Software development
do đặc trưng của IT outsourcing là: Chỉ outsouce 3 công đoạn:
detail design, coding và testing.

Nếu outsouce các công đoạn khác cần nhiều skill hơn
Nếu involve với khách hàng nhiều hơn: cần nhiều skill hơn.

Hy vọng em Hương có thể hạn chế lại những kỹ năng cần thiết hơn.

Chia sẻ kinh nghiệm nhé :) Thanks

> Từ: ThuHuong Nguyen 
> Ngày: 09:29 Ngày 25 tháng 2 năm 2011
> Chủ đề: Re: Nhờ anh Hưng trả lời giúp!
> Đến: Nguyen Vu Hung 
>
> Vâng, thế cho nên em mới phải làm cái nghiên cứu 3-4 năm nay đấy ạ:D
Hóa ra là thế
> Vì nghiên cứu của Tàu thì vẫn là case Tàu, không xuất phát từ thực tiễn và context của VN.
Anh có đề cập qua trong email trước


Thực ra anh cũng  quan tâm đến vấn đề này
để đưa ra phương hướng đào tạo BSE.

Em còn case nào khác của Tàu không? -> gửi nhé.

BSE của VN và TQ khác nhau thế nào?
Theo anh nghĩ đầu tiên và cuối cùng vẫn là vấn đề ngôn ngư

- BSE của TQ làm 100% tiếng Nhật OK (VN BSE thì không thể)
- Phát sinh công (công đoạn dịch)
- Việc dịch chèn vào tất cả các công đoạn
- Mất 2 lần (gấp đôi) công review
- Trao đổi bị hạn chế (email, và đặc biệt là voice chat, meetings)
-  Hiểu nhầm, hiểu thiếu...

>
> Hiện nay em thu thập được rất nhiều data thú vị từ case FSoft. Nhưng tất cả 
đang là 1 đống hỗn độn. Em đang cố gắng matome lại, khi nào xong em sẽ share với anh.

>
> Em thực sự thấy nghề này rất hay và có hứng thú tìm hiểu về nó.
> Với lại em nghĩ, mô hình tương lai, chắc chắn các công ty outsource VN sẽ cần những
người như bọn em, có nghiệp vụ và chuyên tâm hăn vào việc nghiên cứu, để tìm hiểu và 
đưa ra solution. Chứ bản thân các công ty, ví dụ FSoft cũgn ko ai có yoyu để tìm 
hiểu nghiên cứu, khái quát lại các vấn đề.
Tương lai mở công ty tư vấn đây Hương nhỉ?

Các công ty VN làm gì có R&D đâu, họ cứ hùng hục làm zangyou cho xong việc
mà không hề nghĩ đến chuyện làm sao cho smart hơn.

>
> Hiện tại, theo em để tuyền BSE, đối với case VN, anh nên đưa ra những chuẩn thấp 
thấp thôi, ví dụ tốt nghiệp khối kỹ thuật, tiếng Nhật 3kyu, quan trọng nhất là phải có tinh thần học hỏi.

Dân Vn mình kém hơn bọn TQ và bọn Nhật :).

VN mới chỉ có khoảng hơn 10-15 năm làm gia công cho Nhật,
trong đó khoảng 5-7 năm gia công phần mềm.

Kinh nghiệm rất ít so với Trung Quốc (từ năm 79-86), chưa đủ tích lũy
biến chuyển từ know-how thành chất lượng.


> Thế thôi, còn đâu về anh đào tạo còn hơn. Ví dụ anh đưa ra các level, ranking,
> - level 1 tệ nhất là như em vừa nói 3kyu + f (soft skills)
Mức này không dùng làm BSE được, phải phối hợp

1. Lập trình viên + comter
2. Kỹ sư (cấp 1) + comter
3. Kỹ sư (cấp 2,3,...) + comter

Hầu hết các công ty sử dụng loại 3; trong trường hợp này, họ cần kỹ sư rất khá

Các kỹ sư này, nếu em để ý, họ đều xuất thân từ các trường chuyên cấp III, học đại học
có ranking vào bậc nhất ở Việt Nam.


> - level 2, 2kyu + g (f+1)
> - level 3 : 1 kyu+j....
>
> để có chuẩn tuyển và để BSE trong cty phấn đấu lên bậc.
> (Các case của em cho thấy dân xã hội mà tuyển làm BSE sẽ rất rất hạn chế trong cv sau này)
trong khi đó, dân xã hội (là các trường đại học có ranking thấp hơn, đầu vào kém) nên
họ không khá nhanh được.

Dân xã hội có hạn chế nữa là tư duy kỹ thuật, điều này thực tế cho thấy khó có thể đào tạo
lại ở độ tuổi 22+.

Em có biết Fujitsu case tuyển dân ngoại ngữ (đã tốt nghiệp ở VN) đào tạo ở Việt Nam và Nhật không nhỉ?
Case này theo anh biết thất bại gần như 100% (nhưng phải kể tới nguyên nhân suy thoái kinh tế)

Đại học FPT đang lấp chỗ trống bằng cách đào tạo cả tiếng Nhật + kỹ thuật + kỹ năng mềm từ trong trường

Đại học Hà Nội cũng có lớp kỹ sư tiếng Nhật.

Trao đổi thêm nhé! Anh rất muốn được nghe ý kiến từ chuyên gia như Hương!

Redmine Bulk Time Entry plugin to record work time

https://github.com/edavis10/redmine-bulk_time_entry_plugin
Cho phép nhập nhiều timelog cùng một lúc trong một trang.
Có thể import timelog từ csv file.

Dịch 場合

チェックエラーとなった場合、メッセージ出力する。 Có thể dịch là Trường hợp có lỗi, (thì) hiển thị thông báo. Nếu có lỗi, (thì) hiển thị thông báo.

Redmine Tips - Do your Issue Statuses help or hurt your workflow?

The statuses depend on the development processes that we are working on.
And I imitate the following statuses (specified for the  cases of bug tracking)
cf. https://bugs.freedesktop.org/page.cgi?id=fields.html#status

Statuses for other development processes are as simple as you wrote;
The default statuses on Redmine/ProjectChilly are fine to me.

IMO, I think we should mention statuses + trackers + roles as a combination
when speaking to development processes.

By the way, please recommend me a good book on Redmine.


(2011/02/17 0:30), Eric Davis wrote:
Do your Issue Statuses help or hurt your workflow?
 
Issue Statuses are used in Redmine to create a workflow for issues. In an optimized
setup, the issues will move through the different statuses as they are worked on. 
The Issue Statuses I use for Little Stream Software have been optimized to be as 
simple as possible for single person business but also communicate where the issue 
is at to my clients.
 

    * Proposed - Someone has an idea for some work but isn't sure about it yet.
    * New/Approved - Both my client and I like the idea and agree on the budgets.
    * In Progress - I'm actively working on the issue.
    * Resolved - I've finished the issue and am waiting for client to sign off 
      on it. (i.e. ready to be tested).
    * Closed - My client agrees the work is complete.

 
I also use two issue statuses for when exceptions occur:
 

    * Declined - one of us decides the issue isn't needed but we want to document 
       the conversation (instead of deleting the issue).
    * Feedback - someone has a question about the issue that prevents us from 
       working on it

 
This same workflow works for my Open Source plugins but in that case I act as the 
client and project manager.
 
What issue statuses do you use? What have you found helpful?

The changing quality assurance paradigm

The changing quality assurance paradigm All of the factors discussed in the previous section point to the need to end status quo quality assurance approaches and break down the barriers between all of the internal organizations that are instrumental to creating quality products. Leaving testing and quality assurance as an afterthought today is a ticking financial bomb.

Cach dung 各位

関係各位: OK
各位： Không nên dùng độc lập mà viết ○○各位, 
   ví dụ xxxチーム各位、SSS株式会社各位、 従業員各位 
   nên dùng trong trường hợp ngang hàng
関係者各位: Người Nhật dùng phổ biến, tuy nhiên, 
   về mặt ngôn ngữ là không hợp lý vì có cả 者 và 位　
   (đồng nghĩa: đều có nghĩa là người)
各位 = 皆さん (nhẹ nhàng, informal hơn)
関係者各位様： tuy nhiên, về mặt ngôn ngữ là không hợp lý 
   vì có cả 者 = 位 = 様 cùng nghĩa
各位殿,関係者各位殿: Tương tự trên, có 違和感


Google:
関係各位: 4 triệu hit -> có vẻ phổ biến hơn
関係者各位: 1 triệu hit
関係者各位様: 382K hit, trong đó rất nhiều hit không match hoàn toàn.

Học tiếng Nhật: Sai cái sai giống y chang người Nhật (có lẽ nên như thế)

Is Ctr+P a good shortcut?

Thời kỳ chưa có chuột, nếu bố trí shortcut kiểu Ctrl+P (thông thường: In)
thì phối hợp ngón út cả hai tay. Khá tiện.

Đến thời kỳ có chuột, thông thường một tay phải dùng chuột
nên em nghĩ nếu muốn ấn Ctrl-P thì

1. Bỏ tay phải (nếu thuận tay phải) khỏi chuột, move tay phải đến phím P
   tay trái nhấn Ctrl

2. Move tay trái sang phía phải (dãy jkl;), dùng hai ngón tay trên bài tay trái nhấn Ctrl và P
   # Tay phải giữ nguyên chuột.

Cách nào cũng dở nhỉ?
Hay là nên thay phím P bằng một phím nào đó phía bên trái (asdf) để dễ bấm bằng
một bàn tay (trái) hơn?

Gartner Top Predictions for 2011: IT’s Growing

Đây là các dự đóan của Gartmer về IT năm 2011

1. Đến năm 2011, hạ tầng cơ sở của một nước G20 sẽ bị phá loại bởi các thế lực online
2. Đến năm 2011, thu nhập hàng năm từ IT được xác định bằng thu nhập hàng năm của các CIO mới nhất trên toàn thế giới năm 2000
3. Tới năm 2015, các doanh nghiệp thông minh về thông tin sẽ tăng chi tiêu về IT trên đầu người tới 60%
4. Tới nắm 2015, các công cụ và sự tự động hóa sẽ làm mất đi 25% lực lượng lao động về IT


7. Tới năm 2015, 20% số các công ty phi IT trong top 500 sẽ là các nhà cung cấp dịch vụ đám mây
8. Tới năm 2014, 90% số tổ chức sẽ hỗ trợ thiết bị tập hợp chương trình trên các thiết bị cá nhân
9. Tới năm 2013, 80% business sẽ có lực lượng lao động sử dụng tablet
10. TỚi năm 2015, 10% số "người dùng" online sẽ không phải là con người

Tham khảo: december_15_top_predictions_for_2011_dplummer.pdf

Vi sao nhan vien nghi viec

Theo một điều tra của một công ty cỡ lớn ở Nhật,
dưới đây là lý do vì sao nhân viên nghỉ việc

Nói chung không phải vì việc khó, mà chính vì cấp trên.
Nguyên nhân chính là

1. Cấp trên không chịu nghe ý kiến tư vấn của cấp dưới
2. Bị ép làm thêm "miễn phí"
3. Cách lãnh đạo không thuyết phục
4. Ép một cách chủ quan, không đủ thuyết phục.
5. Không hề quan tâm đến một số nhân viên


ホットライン窓口では「会社は好きだけど辞めたい。」という訴えに接することがあります。
仕事が厳しいから辞めたいのではありません。それどころか、仕事自体は楽しいというのです。
ではなぜ？それは、職場の環境です。上司への不満に堪えきれなくなっているのです。
 
具体的には、
上司が「部下の意見を聞く耳を持たない。」
「サービス残業を強要する。」
「納得できない指導をする。」
「根性論だけを押しつける。」
「一部の部下をことさら無視する。」などです。
このような不満で有為な人物を失うのは、組織としてみればとても大きな損失です。
 
人は、仕事が厳しくてもやりがいがあれば、満足感を感じるものです。
自分の成長を感じるときは、人はストレスを感じないといいます。
これまでの上司で、一番の人を思い出してください。
きっと「厳しくはあっても親身な指導で自分を成長させてくれた人」を思い起こすのではないでしょうか。
 
あなたは上司として、部下が気持ちよく働 くことができ、
また、成長できる環境を作るよう意識して いますよね。
疲労感や閉塞感を与えるのではなく、達成 感を与えるマネージャーであってください。

hien tai quoc gia chi nguyen khi

賢才国家之元気 (Hiền tài quốc gia chi nguyên khí), 
là câu của của tiến sĩ Thân Nhân Trung, người Việt Yên, Bắc Giang, lưu trong
大宝三年壬戊科進士題名碑記 năm 1484
(Đại Bảo tam niên Nhâm Tuất khoa tiến sĩ đề danh bi kí),
được coi là 一言興邦 (Nhất ngôn hưng bang), ảnh hưởng nhiều tới Lê Hiến Tông.

A letter to a CEO

Con người là yếu tố quan trọng nhất của một công ty. 
Đây là câu được viết trong Quốc Tử Giám: Hiền tài quốc gia chi nguyên khí
(賢才国家之元気)

Thâm niêm cũng quan trọng, nhưng năng lực là yếu tố quan trọng hơn.

適材適所. Dùng đúng người đúng chỗ.

Sự đổi mới và sáng tạo bị giết chết trong một môi trường thiếu dân chủ.

Quản lý nhân sự có trình độ đại học khác với quản lý công nhân xuất thân từ nông dân. 
Lập trình viên có tinh thần tự chủ. Những người không có khả năng này cần ra đi.

Mô hình tập đoàn/công ty con thích hợp nếu nhân sự tăng tới 80-100 người.
Tổ chức công ty theo mô hình này sẽ dễ dàng quản lý và mở rộng hơn.
Tin tưởng và giao quyền quyết định cho cấp dưới.

Chất lượng là vấn đề sống còn để cạnh tranh với các đối thủ outsourcing khác 
ở Việt Nam và Trung Quốc.

Công khai, minh mạch, tuyên bố rõ định hướng chủ trương của công ty (chính là chủ trương của CEO) để tạo sự hiểu nhất quán trong toàn tổ chức.

Chia sẻ. Thiếu tài chính: đi vay.

Xác định và tập trung vào core business.

Vượt qua chính mình, nỗ lực tự tiến bộ, chứ không phải vượt qua đối thủ cạnh tranh.

Xac dinh do uu tien cua cong viec

Xác định độ ưu tiên công việc

Xác định độ ưu tiên công việc, liệt kê theo thứ tự giảm dần của độ ưu tiên

Những việc cần làm ngay, có deadline tính bằng vài giờ hoặc dưới 24 tiếng (1 ngày)

Những việc liên quan tới nhóm khác, người khác ngoài dự án mình đang tham gia

Những việc liên quan tới người khác trong nhóm của mình

Những việc của bản thân có deadline nhỏ hơn tính bằng đơn vị ngày (2+ ngày)

Công việc nội bộ không ảnh hưởng nhiều tới tiến độ dự án: training, phổ biến quy định, 
nghiệp vụ, review kết quả

Tieng Nhat business

Sửa Tiếng Nhật

Sửa thành thể viết tắt:

○○○の成果物を１月１４日に送付した。
○○○様からのレビュー結果を待っている。

○○○の成果物を１月１４日に送付済み。
○○○様からのレビュー結果待ち。

レビュー結果に従い、バッチのＵＴ結果を修正している
レビュー結果に従い、バッチのＵＴ結果を修正中


早速にファイルを送付して頂き、ありがとうございました。
⇒早速、ファイルの送付をありがとうございます。　(Không nên dùng ました trong trường hợp này)

何か不明点があれば、また連絡いたします。
⇒もしご不明な点がありましたら、お知らせください # Hay dùng, lịch sự hơn ご連絡下さい
⇒もしご不明な点がありましたら、ご一報下さい # Điệu hơn
⇒もしご不明な点がありましたら、ご連絡下さい # Trung lập, hay dùng nhất

ありましたら chứ không phải là あれば。

Google:
不明点があれば
不明点がありましたら

Haipad M1001

http://www.haipad.net/ProductShow.asp?ID=5 http://www.hiapk.com/index.php

Tao search thử rồi, cái HaiPad mà tao mua là cái này

http://www.haipad.net/ProductShow.asp?ID=5
http://www.tudou.com/programs/view/w59txS1H3gc/

Không rõ trang này
http://www.shanzhaiben.com/
có liên quan gì đến haipad?

đồ của bọn này dùng tạm được, nhưng bọn nó làm ẩu quá:
kể cả phần cứng lẫn phần mềm. Nếu muốn cải tiến thì phải
order chúng nó customize thêm phần cứng và cả phần mềm
(phần mềm thì tự mình làm được chút ít)

Hỗ trợ tiếng Anh, tiếng Nhật, Việt thiếu.
Tài liệu cũng hơi lởm khởm (search toàn ra tiếng Trung không đọc được)

À, nếu sang Thẩm Quyến từ VN thì đi thế nào tiện nhất?
Có cần VISA không? Nếu An có việc sang đấy thì rủ tôi đi cùng nhá.

On Fri, Dec 17, 2010 at 9:33 AM, Darren Cook <@dcook.org> wrote:
>
> >>  They aren't too tech-savvy so I though something
> >> wireless that connects to an online web album and can be controlled
> >> from a browser would be good.
> >
> > I would recommend a Google Android tablet combined with Flickr Droid.
>
> Is that a practical suggestion? Can you suggest a specific model, that
> is available to buy now? An android tablet is so much more than a photo
> frame, so if the price is competitive that would explain why no-one is
> bothering to make photo frames (at least, with wireless) any more!

This is what I am playing with:

# This is not a knockoff.
# This toy is for geeks but I think its slide show function will work
pretty well once properly configurated.

http://shop.apadjp.com/products/detail.php?product_id=12

The latest Android version is 2.3 but I think 2.1 works fine.
Because the OP only needs a slide show that can be connected to Internet,
most apad works well with Flickr Droid as I recommended in the previous post.

The price is 2 man - 2.5 man depends on the model, but I am sure you can get
a bargain if you go to あきばお(？) at weekend.

So far, Wi-Fi works well for me, 256 MB of RAM seems to be enough for me
for surfing web, viewing PDF files with Acrobat Reader (for Android)
and slide show.
However, for the PNG and JPG file with resolution 1000x800 needs 1-2 seconds to
be rendered and shown on the screen (too slow compared to iPad?, yes,
compare their CPU and RAM)

One thing I am not happy with is, battery. It seems to be optimized
for decoding mp3 and working offline.
However if you go online (communication needed), the battery will run
out in less than 2 hours).

HTH.

タッチ！うごく うたえほん

子育て中のママ＆パパ必見！！　ママたちがこどものために作ったアプリ
「うごく絵本」＋「うた」＋「手遊び」＋「カラオケ」＝それが！ 
「タッチ！うごく うたえほん」。人気の童謡を中心に10曲収録で盛りだくさん！
お子様を飽きさせない仕掛けや音がいっぱいです！




http://itunes.apple.com/jp/app/id408859672?mt=8#
http://app.joysound.com/sumahomama/

Khả năng

1. Chiều lòng khách hàng
2. Hỗ trợ tới mức kỹ thuật tới nhân viên cấp duới khi cần thiết
3. Khả năng ngôn ngữ Anh/Việt/Nhật (duy nhất), khả năng trình bày
4. Quản lý nguồn thông tin bằng các công cụ cần thiết
5. Gây ảnh hưởng gián tiếp
6. Chat có nội dung và không có nội dung
7. Chịu dựng áp lực công việc (kể cả mắng chửi :D)
8. Thay thế 4 người (2 quản lý trung gian và 2 phiên dịch viên) :)

flv to mp4 (iPhone) conversion

Under cygwin or a typical bash shell

ffmpeg version SVN-r20888

for file in *flv; do ffmpeg -i "$file" -s 320x180 "$file.mp4"; done

Lập trình không lỗi

"Lập trình không lỗi" là việc gần như không thể làm.
Ngay cả những công ty lớn và những lập trình viên siêu việt cũng gặp lỗi
vì họ không thể vượt qua quy luật:

"Mọi chương trình đều có ít nhất một lỗi".

Hệ quả: Nếu fix được "lỗi cuối cùng", sẽ xuất hiện "lỗi cuối cùng" tiếp theo.

Tips để lập trình ít lỗi hơn:

1. Architect it beautifully
-> Thiết kết dễ hiểu, đơn giản.
Nếu làm việc trên một hệ thống có sẵn, cần hiểu kỹ cấu trúc của hệ thống này.

2. Look at every single line of code and ask yourself "how could this go wrong?"
-> Kiểm lại lại từng dòng code.
Nói cách khác: Tự review code của chính mình.
# Trên thực tế, không phải mọi team đều có thời gian để review chéo code.

3. Keep careful track of your screwups in 2 and build systems to avoid them
Quản lý môi trường: Một version cũ, ngay trước đó, và version hiện tại.
Kết hợp sử dụng software configuration management software (như subversion)
để quản lý mã nguồn: Hôm qua code chạy được, nhưng không nay thì không? Vậy nguyên nhân ở đâu?

cf. http://inamidst.com/topic/bugfree

Luật Parkinson

Đây là luật Parkinson, đơn giản như một nghịch lý nhưng rất đúng.
Cần áp dụng triệt để khi giao việc:

Work expands so as to fill the time available for its completion.
-> Người giao việc có thể cắt ngắn deadline tới mức không thể ngắn hơn.

Data expands to fill the space available for storage.
-> Ổ cứng chứa toàn dữ liệu thừa có thể xóa được.

The demand upon a resource tends to expand to match the supply of the resource.
-> Tiền bao nhiêu cũng đủ, dù là "ít" hay "nhiều".

Tuyển người qua hành vi

Đây là một vài tip khi phỏng vấn, các bạn tham khảo: Trong tuyển dụng nhân sự, phương pháp phỏng vấn dựa trên khoa học về hành vi đã chứng tỏ được tính ưu việt hơn hẳn so với phỏng vấn truyền thống.

Văn Hóa

Phương pháp này có tên đầy đủ theo tiếng Anh là Behavioral Event Interview (BEI), là tiến trình phỏng vấn theo một cấu trúc nhằm giúp dự đoán chính xác hơn tiềm năng của ứng viên cho sự thành công trong công việc sau này. BEI có nguồn gốc từ nghiên cứu của Hải quân và Không quân Mỹ vào thập niên 1940. Theo đó, khi khảo sát về tính hiệu quả trong chiến đấu của lực lượng trong ngành, các chuyên gia đã đưa ra kết luận rằng chính hành vi, chứ không phải kiến thức về kỹ thuật, đã tạo nên sự khác biệt của từng cá nhân.

Tại hội thảo “Phát huy sức mạnh nguồn nhân lực để hội nhập WTO”, do Trung tâm Huấn luyện Thành công và Hạnh phúc, TPHCM tổ chức, bà Kee May Lee với hơn 15 năm kinh nghiệm trong lĩnh vực phát triển con người đã chia sẻ phương pháp phỏng vấn dựa trên khoa học về hành vi. Theo bà Lee, BEI là một quá trình phỏng vấn theo hệ thống, nhằm giúp nhà tuyển dụng có được những thông tin thiết thực và khách quan về ứng viên. Nói cách khác, BEI sẽ “dò tìm” sự tương thích cao nhất giữa ứng viên và công việc tuyển dụng. Vì thế, khi áp dụng phỏng vấn BEI doanh nghiệp sẽ giảm bớt thời gian đào tạo nhân sự, đồng thời hạn chế tối đa mức độ bỏ việc đột xuất của nhân viên.

BEI có gì khác so với phỏng vấn truyền thống? Bà Lee giải thích, phỏng vấn truyền thống thường đưa ra những câu hỏi dựa trên “cảm nhận” hoặc “giả định” đối với ứng viên. Chẳng hạn: “Bạn có cho rằng mình có lợi thế về kỹ năng phục vụ khách hàng?”; “Bạn sẽ làm gì nếu gặp phải một khách hàng khó tính?”… Trong khi đó, BEI sẽ hướng đến những câu hỏi cụ thể hơn: “Hãy kể cho tôi nghe một trường hợp khi bạn gặp phải một khách hàng khó tính”; “Lúc đó bạn đã xử lý tình huống như thế nào?”; “Kết quả ra sao?”… Do vậy, phỏng vấn BEI đòi hỏi nhà tuyển dụng phải chuẩn bị kỹ trước, trong và sau khi phỏng vấn. Trước cuộc phỏng vấn, nhà tuyển dụng sẽ chuẩn bị bảng mô tả công việc (trách nhiệm phải thực hiện và tiêu chuẩn để đánh giá công việc); đọc bản lý lịch tóm tắt (resume) của ứng viên; lập bảng câu hỏi phỏng vấn và bảng đánh giá phỏng vấn. Khi tiến hành phỏng vấn, nhà tuyển dụng phải chia sẻ với ứng viên về các bước tiến hành phỏng vấn; đặt những câu hỏi về hành vi trong quá trình làm việc trước đây của ứng viên; sử dụng quy tắc “10 giây” (nhằm tránh buộc ứng viên phải trả lời ngay câu hỏi, hoặc để ứng viên suy nghĩ quá lâu); ghi chú những thông tin thiết thực từ ứng viên.

Cụ thể, nhà tuyển dụng nên thông báo cho ứng viên về thời lượng cuộc phỏng vấn; cho họ biết những câu hỏi cụ thể sẽ được nêu và khuyên họ đừng vội trả lời vì thông tin của họ sẽ được ghi lại; cuối buổi phỏng vấn họ có thể đặt câu hỏi với nhà tuyển dụng… Nhà tuyển dụng cần làm cho ứng viên thấy thoải mái và thư giãn bằng cách đặt câu hỏi với thái độ tôn trọng và chờ họ trả lời; kiên nhẫn lặp lại câu hỏi hoặc diễn đạt cho rõ nghĩa hơn; lắng nghe chăm chú và ghi chép những gì ứng viên nói. Sau khi phỏng vấn xong, nhà tuyển dụng cần xem lại những ghi chép của mình đã được hệ thống chưa, và phải hoàn tất ngay bảng đánh giá phỏng vấn. Bà Lee cho biết nhiều nhà tuyển dụng đã không làm điều này, vì thế thông tin về các ứng viên có thể bị lẫn lộn nếu tiến hành phỏng vấn nhiều người.

Làm sao đặt câu hỏi về hành vi trong quá khứ của một người? Theo bà Lee, nhà tuyển dụng nên phối hợp giữa các dạng câu hỏi mở, thăm dò và câu hỏi đóng. Câu hỏi mở nhằm lấy thông tin về tình huống xảy ra, việc xử lý và kết quả đạt được nên thường nhẹ nhàng như gợi mở những tâm sự: “Kể cho tôi nghe về sự kiện đó…”, “Bạn có thể chia sẻ với tôi về tình huống…”. Câu hỏi thăm dò nhằm đột phá vào các câu trả lời chung chung của ứng viên nên thường dưới dạng 4W+1H (Cái gì? Ở đâu? Khi nào? Ai? Như thế nào?). Tuy nhiên, nhà tuyển dụng nên tránh câu hỏi “Tại sao?” - vì dễ khiến ứng viên nảy sinh cảm giác đề phòng, đối phó, từ đó thông tin cung cấp sẽ không trung thực. Câu hỏi đóng nhằm xác nhận, làm rõ vấn đề nên thường ngắn gọn: “Thật vậy chứ?”.

Trên thực tế, bước vào cuộc phỏng vấn hầu như ứng viên nào cũng cảm thấy bối rối, lo lắng hoặc thậm chí căng thẳng. Lý do là vì họ muốn tạo ấn tượng tốt với nhà tuyển dụng để được thâu nhận. Nhưng chính những bất ổn tâm lý này đã khiến họ không thể suy nghĩ thấu đáo mọi vấn đề, từ đó câu trả lời ít nhiều bị sai lệch.

Trong phỏng vấn BEI, vấn đề khuyến khích ứng viên đưa ra các thông tin vừa chính xác vừa có tính sự kiện rất được quan tâm. Và các nhà tuyển dụng đã được khuyên hãy tạo không khí thoải mái cho ứng viên; hãy tỏ ra tôn trọng, hỗ trợ và động viên tinh thần của họ. Nhưng nhà tuyển dụng nên làm thế nào để tỏ thái độ tôn trọng và hỗ trợ ứng viên? Bà Lee cho biết trong vòng luân chuyển các dạng câu hỏi mở, thăm dò và đóng của phỏng vấn BEI, nhà tuyển dụng nên xen kẽ bằng những câu hỏi dạng trấn an, diễn đạt cho rõ nghĩa hoặc lặp lại ý vừa nêu. Chẳng hạn như trong câu trấn an nhằm khuyến khích ứng viên cố nhớ lại một sự kiện trong quá trình làm việc trước đây, nhà tuyển dụng có thể nói: “Tôi biết rất khó nhớ lại những chuyện đã qua, nhưng bạn đừng quá căng thẳng, chúng ta còn thời gian…”.

Bên lề cuộc hội thảo trên, một số doanh nghiệp nước ngoài đã chia sẻ những kinh nghiệm thực tế trong việc áp dụng phương pháp phỏng vấn BEI. Theo họ, tuy BEI đã có những câu hỏi sát sườn với công việc thực tế của ứng viên nhưng vẫn có những người giỏi “bịa chuyện”, có thể nêu ra những tình huống rất thật được cóp nhặt từ đâu đó. Vì thế, phỏng vấn BEI nên được kết hợp với việc thực hành tình huống thật, chẳng hạn tuyển tiếp tân thì đề nghị ứng viên thực hành tình huống nghe điện thoại; tuyển bán hàng thì không gì “thật” hơn buộc ứng viên vào vai nhân viên công ty trong một tình huống được sắp đặt sẵn… Ngoài ra, câu hỏi thăm dò trong phỏng vấn BEI chỉ nên có từ hai đến ba câu cho từng ứng viên và nhà tuyển dụng phải ghi chép thật chính xác lời ứng viên nói. Dấu hiệu cho thấy buổi phỏng vấn thành công là ứng viên… nói nhiều hơn nhà tuyển dụng, theo một tỷ lệ là 80% (cho ứng viên) và 20% (đối với nhà tuyển dụng).

Theo KINH TẾ SÀI GÒN

Software Outsourcing Hidden Cost

Xét cho cùng, outsourcing sang Việt Nam không hiệu quả nếu không biết cách làm. http://spreadsheets.google.com/pub?key=0AgOqPQzRjQPOdDA4R0NNUTgxSnNzV1Zmd0JRYUt1c2c&hl=ja&single=true&gid=0&output=html

Điểm quan trọng khi phân tích yêu cầu dự án (mức business)

Điểm quan trọng khi phân tích yêu cầu dự án (mức business)

* Mô tả yêu cầu câu việc thật ngắn gọn.
* Phát biểu các mục tiêu quan trọng của dự án.
* Mô tả môi trường mà hệ thống sẽ chạy.
* Các thông tin "hậu trường" và các tài liệu liên quan quan trọng.
* Thông tin về các ràng buộc thiết kế chính.

Ngoài ra,

1. Đừng nghĩ mình hiểu đúng khách hàng muốn gì. Phải hỏi.
2. Đưa người dùng tham gia dự án từ đầu.
3. Bản ghi nhớ, đồng ý giữa các bên về phạm vi dự án.
4. Đảm bảo rằng các yêu cầu dự án cụ thể, thực tế (thực thi được) và đo đếm được.
5. Rõ ràng, không có điểm nghi vấn.
6. Tạo tài liệu yêu cầu dự án rõ rằng, ngắn ngọn và chia sẻ với khách hàng.
7. Xác nhận sự hiểu của mình về dự án với khách hàng.
8. Tránh đề cập tới công nghệ hay giải pháp cho tới khi yêu cầu được làm rõ.
9. Bản ghi nhớ: Được sự đồng ý của các bên liên quan ngay từ khi dự án bắt đầu.
10. Tạo bản prototype để khách hàng có thể hiểu rõ hơn yêu cầu

Pitfalls quản lý dự án

Pitfall #1: Not creating a common project vision at the onset of a project

A shared vision (or goals) and expected project outcomes across key stakeholders is key to managing project efforts and avoiding scope creep.

• Involve leaders and managers in the development of the project vision and ensure that all anticipated benefits are clearly understood and agreed upon.
• Identify success criteria and be specific. For example, total project costs will not exceed a certain dollar amount and the project will be rolled out within a specifically stated timeframe.
• Define the boundaries of the project by knowing what is out of scope (as well as in scope).

Words of Wisdom: Facilitate your stakeholders to the creation of a common vision and ensure that they own the vision and the ultimate solution.

Pitfall #2: Not getting organised, staying organised and organising those around you

Strong planning and organisational skills are essential traits of a successful Project Manager.

• Develop your project plan at the task level and communicate it to your project team and stakeholders. It's well worth the time in order to keep you and everyone else organised.
• Create a robust communication plan and make sure it's a "living document."
• Understand who you need to communicate with, how they want to be communicated with and the frequency. Then determine how your messaging should differ by stakeholder.
• Conduct an interactive kick-off meeting to ensure everyone involved with the project is fully engaged.
• Ask for continuous feedback and be prepared to adjust your plan to address changing stakeholder needs.
• Develop risk and issue logs. Risks and issues are a part of every project. Get ahead of the game and brainstorm with people on potential risks and ways to avoid them before they become issues that impact your project's scope, timeframe, quality and/or budget.

Words of Wisdom: The devil is in the detail. Review your plans at least twice daily. It's the best 15-20 minutes you'll ever spend.

Pitfall #3: Not involving the right people on the project

• Engage the right people at all levels of your organisation (and not necessarily those who simply want to chime in because it's a high profile project) to solidify the project vision, avoid scope creep and implement.
• Ensure that all stakeholders understand what needs to happen, how it needs to happen and when.
• Identify a project sponsor, someone with authority and influence, and have them actively involved throughout the project.
• Communicate the project vision, project team roles and responsibilities and clearly set expectations.
• Ensure your key project decision makers understand the principles of good project management and that they need to operate within that framework.
• Include frontline personnel who can be key contributors to a project. They often provide insight into the "goings-on" of an organisation and have the ability to rally the troops when the rubber meets the road and things need to get done.
• Identify the nay-sayers and keep them very involved in the project (keep your friends close and your enemies closer).

Words of Wisdom: Don't assume that senior leaders are the only ones that should be in your sights. Keep a laser focus on decision makers and those who directly impact your project.

Pitfall #4: Not asking for help and learning from others

"Mum's the word" is not a mantra any project manager should embrace. Project managers who are new to project management or are managing a different type of project than they've managed before can have a steep learning curve.

• Identify people internally who have managed a similar project and talk about lessons learned from previous projects.
• Identify external sources who can impart their own words of wisdom on how to effectively manage a project.
• The Internet is a beautiful thing, use it to research project management best practices and tools and understand new technologies.

Words of Wisdom: Asking for help is not a sign of weakness. It's better to ask for help then to place a project at risk. Let's face it, every project has its ups and downs but it's what you, as the Project Manager, do to handle the good and the bad that leads to project success and avoids project chaos.

Hoàn thiện kỹ năng làm việc

1. Sinh viên: Nhận bài tập với yêu cầu rõ ràng, mức độ dễ từ giáo viên

2. Sinh viên mới ra trường, dưới 1 năm kinh nghiệm: Làm việc dưới sự
chỉ đạo của Team Lead, Project Manager (phân tích hộ).

3. Sau 1 năm kinh nghiệm: Chủ động phân tích, giải quyết vấn đề.

4. Sau 1.5-2 năm kinh nghiệm: Biết cách đề xuất giải quyết những bài toán tích hợp lớn hơn,
những vấn đề kỹ thuật lớn hơn.

5. Sau 2 năm:  Có khả năng quản lý team, từ 3-4 người trở lên.

Để "level up", Đại cần chủ động hơn, hoàn thành công việc cho dù
yêu cầu không rõ ràng (thiếu thông tin).

Tây có câu này rất hay: Practice makes perfect.

Waterfall vs. Spiral

Mô hình phát triển phần mềm ở công ty nhà nước làm nói chung là Waterfall.

Họ cung cấp cho đối tác *rất* ít thông tin.
Sau khi phân tích, thiết kế, phát triển, test toàn bộ
mới đưa cho họ kiểm chứng.

Rủi ro là nếu phát sinh vấn đề ở một trong các bước trên sẽ khó quay lại.

Đặc trưng khác của công ty nhà nước Việt Nam là:

1. Ít giao tiếp, trao đổi -> thiếu thông tin dẫn tới làm sai, thiếu.
2. Chậm.

Spiral model theo hướng phát triển prorotype, lặp lại quy trình phát triển
nhiều lần ép khác hàng giải quyết *trực tiếp* vấn đề 1. ở trên.

cf.
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Spiral_model

Mười phẩm chất của một kỹ sư

1. Năng khiếu phân tích: Luôn luôn phân tích, để tâm tới vấn đề và cải tiến nó. 
Nghĩa là, người kỹ sư phải có tính "tò mò", luôn tìm hiểu và học hỏi

2. Chú ý tới chi tiết (tiểu tiết): Phải luôn chú ý tới những chi tiết nhỏ nhất, 
những sự cố hay quan sát dù nhỏ nhất. Đôi khi, những chi tiết nhỏ này là 
"ánh sáng cuối đường hầm" dẫn tới giải pháp giải quyết vấn đề.

3. Khả năng giao tiếp: Có thể giao tiếp với các kỹ sư hay người làm kỹ thuật
 bằng ngôn ngữ kỹ thuật chính xác. Đồng thời phải có khả năng diễn đạt cùng 
nội dung kỹ thuật bằng ngôn ngữ "phi kỹ thuật" để ai cũng có thể hiểu vấn đề. 
Kỹ năng này đòi hỏi cả khả năng nói và khả năng viết.

4. Luôn luôn học hỏi công nghệ mới để tránh tụt hậu. Đặc biết với ngày IT,
 các công nghệ mới ra đời hàng tuần đòi hỏi người kỹ sư phải tìm hiểu nhanh 
các công nghệ này.

5. Sáng tạo: Có khả năng nghĩ ra những giải pháp và đề xuất sáng tạo để 
làm cho hệ thống đã có hoạt động tốt hơn.

6. Suy nghĩ logic: Đây là khả năng cần nhất trong các khả năng người kỹ sư 
cần có. Nó là khả năng hiểu một hệ thống phức tạo và phân tích vì sao 
sự cố xảy ra.

7. Giỏi toán: Khả năng này là thiên bẩm đối với một số người. Tuy nhiên có 
thể đào tạo được. Không có cơ sở vững chắc về toán, người kỹ sư không 
thể hiểu các tính toán hay thuật toán phức tạp.

8. Khả năng giải quyết vấn đề: Phân tích, bóc tách vấn đề để chỉ ra nguyên nhân 
vấn đề nằm bộ phận nào của hệ thống. Workaround là cách giải quyết biểu hiện 
của vấn đề trong khi "fix" là sự giải quyết triệt để tận gốc nguyên nhân vấn đề.
Người kỹ sư cần hiểu sự khác nhau của hai phương pháp này, sử dụng đúng lúc, 
đúng chỗ và đánh giá được hậu quả tiềm năng sau khi vấn đề được giải quyết.

9. Teamwork tốt: Người kỹ sư tốt hiểu rằng họ là một mắt xích trong một cỗ máy.
 Cố máy này hoạt động tốt hay không phụ thuộc vào tất cả các mắt xích. Các mắt 
xích cần hỗ trợ nhịp nhàng với nhau nhưng bản thân từng mắt xích cũng cần 
hoàn thiện để tránh gây ảnh hướng xấu tới các mắt xích khác.

10. Kiến thức cơ bản: Hiểu biết rộng với nhiều ngôn ngữ lập trình, cơ sở dữ liệu, 
hệ thống hay được sử dụng.

Tham khảo: http://www.engineeringschools.com/engineering-top-10.html

Mẹo vặt nâng cao năng suất

1. Dành thời gian tỉnh táo nhất trong ngày để check email (8h - 9h).
Xử lý ngay những email, công việc gấp hoặc có thể giải quyết ngay.
Queue những công việc "dài hơi" và note trong sticky memo.
-> http://www.forest.impress.co.jp/lib/dktp/calclock/tag/husentyou.html

2. Liệt kê những công việc cần làm trong stiky memo để dễ dàng theo dõi.
Đặt độ ưu tiên cho các task này và xử lý theo thứ tự ưu tiên.

3. (Cố gắng) giải quyết trọn vẹn 100% công việc đã liệt kê trong ngày,
trước khi ra về.

4. Sắp xếp giao việc cho người khác ("đá bóng") hợp lý nhất.
Tuy nhiên, không để mất quyền chủ động. Luôn nắm được tiến độ và hỗ trợ.

5. Phân chia email theo thư mục, tags các email theo màu đỏ (urgent, phải làm ngay),
Màu xanh (TODO, phải làm trong ngày).

6. Kết hợp ThunderBird và Lightning quản lý các cuộc hẹn, công việc
trong một ngày cũng như trong tuần.

7. Memo, email confirm lại nếu khách hàng trao đổi bằng điện thoại hoặc
trao đổi miệng trực tiếp.

Clear (Flush) Windows and Linux DNS cache

Set DNS to 8.8.8.8
My Network -> Property -> TCPIP -> Property -> DNS -> OK
Access the website
Change DNS back to the value it should be

Linux

Set DNS to 8.8.8.8


[vuhung@redmine-0.8.7]$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
nameserver 8.8.8.8
#nameserver 192.168.51.1

Access the website
Change DNS back to the value it should be