2016/05/30

Lần (từ cũ)


​Lần:

- trong "tôi tự học" của Nguyễn Duy Cần
- chưa có trong Vietlex 2013 anh nhỉ?
- Nghĩa là "dần dần" (theo em thế)

Ít thấy từ "lần" đứng độc lập.

--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

2016/05/16

アジア撤退企業に共通する「日本式マネジメント」の時代錯誤/Những điểm chung về quan điểm quản lý sai lầm của các công ty phải từ bỏ Asia

アジア撤退企業に共通する「日本式マネジメント」の時代錯誤/Những điểm chung về quan điểm quản lý sai lầm của các công ty phải từ bỏ Asia:

1. ちょっと進出してみてダメだったら引き上げる。本気でアジア進出してほしいですね。 Quan điểm "làm thử" nửa vời khi thâm nhập (thị trường) Asia. Hãy làm thật luôn đi. 
2. 海外進出の問題点(1) 日本式を押し通しすぎる / Áp dụng cách làm kiểu Nhật quá cứng nhắc (và thất bại)
3. 海外進出の問題点(2) 現地人材のマネジメントができない / Nhiều công ty Nhật chỉ outsource cái không phải core tech/biz của họ. Họ không cần người tài ở bản địa. Chuyện người Nhật kém quản lý người bản địa giỏi: Thường thấy 
4. 日本企業がアジアで苦戦するのは「アジアNo.1」思考に原因がある / Đừng cố, vì Trung Quốc nó to lắm
5. 「皆が集まる会議」が多すぎる / Cơ chế ra quyết định chậm, nhiều ringi


--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

2016/05/11

Training, mentoring and coaching: Giống, khác nhau thế nào?

Giới thiệu
Bài viết này giới thiệu ngắn gọn sự giống và khác nhau cơ bản giữa training, coaching và mentoring trong phạm vi giáo dục cho người đã đi làm, cụ thể hơn là nhân viên IT qua trải nghiệm của các nhân tôi (Vũ Hưng)

Tạm dịch và giải thích từ ngữ
Training: Là đào tạo theo cách thông thương chúng ta thường thấy. Việc dạy trong trường trường học là training
Coaching: Huấn luyện. "Huấn luyện viên" trong bóng đá được gọi là "coach"
Mentoring: Hướng dẫn

Đây là ba hình thức phát triển (cá nhân) và đều thuộc phạm trù giáo dục.

Các điểm chính 
  1. Training: Dạy học theo một chương trình đã lên kế hoạch sẵn về một kỹ năng, kỹ thuật dùng trong công việc hiện tại hay tương lai. Hiểu đơn giản, "training" là dạy, thường là bị động và một chiều.
  2. Coaching: Hướng dẫn 1-1 (hoặc 1-N) về việc phát triển kiến thức, kỹ năng, khả năng của cá nhân giúp tăng hiệu quả công việc. Điểm nhấn ở đây là huấn luyện viên làm việc/giúp đỡ 1-1 với người được hướng dẫn. 
  3. Mentoring: Người có nhiều kinh nghiêm và hiểu biết hơn hỗ trợ việc phát triển người khác. Mentoring tập trung và quan hệ giữa người truyền kiến thức và người nhận kiến thức.

Đón đọc
  1. Các hình thức coaching
  2. Các tình huống sử dụng coaching
  3. Active learning, một hình thức học mới
  4. Vì sao training không hiệu quả với công ty (mà phải dùng coaching)?
Tài liệu tham khảo


--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.

2016/05/05

Closing a Project: What you need to do as a Project Manager

Tình huống

Bạn là một project manager (PM) (hay Scrummaster (SM)) được điều động vào một dự án phát triển (phần mềm) thay thế PM/SM cũ. Dự án đang ở giai đoạn cuối. Theo báo cáo từ PM/SM cũ, dự án "gần xong, một chút nữa là xong" nhưng một số cái (deliverables, specs, requirements...) không thể "chốt" hay close được với khách hàng. Mục tiêu được giao từ cấp trên là close dự án này, càng sớm càng tốt, giải phóng (bớt) nhân sự, không để dự án dai dẳng, tốt công của và thời gian. Với tư cách là PM/SM, bạn nên/phải làm gì?

Dự án đang ở đâu?

Trả lời câu hỏi này để biết được hiện trạng của dự án. Một số câu hỏi cần đặt ra
  1. Dự án cần làm những gì? 
    1. Schedule/WBS (Work Breakdown Structure) ở đâu, đã làm được gì?
    2. Product backlog/sprint backlogs ở đâu, đã làm được gì?
  2. Những gì (chức năng/user story) đã hoàn thành, những gì chưa hoàn thành, những gì đang "treo" (đang được confirm). Nên trả lời riêng câu hỏi này.
  3. Dự án đang trong phase nào? (yêu cầu, thiết kế, lập trình, kiểm thử đơn vị, kiểm thử tích hợp, deploy, tạo tài liệu). Một số chức năng có thể ở phase này, hoặc ở phase khác. Cần liệt kê cụ thể.
  4. Đầu vào của dự án gồm những gì? (tài liệu yêu cầu, user stories, thiết kế, nếu có)
  5. Đầu ra của dự án gồm những gì? Đã làm được gì? Trạng thái (being confirmed, being reviewed, done...)
  6. Kế hoạch và trạng thái (schedule, burndown chart)

Vấn đề của dự án là gì?

Cần họp toàn team, lắng nghe thông tin từ tất cả những người liên quan.

Risk và issue log là hai tài liệu quan trọng nhất cần có. Với những dự án quản lý kém, hai tài liệu này thường không tồn tại hoặc quản lý kém. Đặc biệt, với dự án không chạy tốt theo khung Scrum, thường hai tài liệu này không tồn tại và cần được tạo lại.

Lưu ý rằng trong danh sách issue log không chỉ chứa các vấn đề kỹ thuật mà cần bao gồm cả danh sách các vấn đề về nhân sự, communication, yêu cầu, thiết kế, kỹ thuật, năng lực của cả nhóm.

Cận biên tích hợp của dự án

Xác định những hệ thống, chức năng có tích hợp, liên kết với dự án chúng ta tiếp quản. 

Một pattern hay thấy ở các  dự án phần mềm là, từng module đơn lẻ đã hoàn thành nhưng phần tích hợp các module đó trong phạm vi nội bộ do nhóm phát triển đảm nhận không được ý thức tới, chưa làm, hoặc làm nửa vời, không có issue log.

Một pattern khác hay thấy hơn là phân tích hợp hệ thống/phần mềm chúng ta tiếp quản với hệ thống bên ngoài làm chưa tốt. Với phần này, cần xác định các hệ thống liên quan, những người chịu trách nhiệm (đầu mối) của các dự án đó, họp và xác định trạng thái, công việc tồn đọng, issue list.

Tiếp theo phải là gì?

Sau khi đã tiến hành ba bước trên, cần refine lại danh sách công việc còn lại cần làm, tạo schedule/WBS hay masterplan cho các sprint tiếp theo. Trả lời câu hỏi: Cần khoảng bao nhiêu thời gian (và tiền) (ở mức high level) để hoàn thành nốt công việc tồn đọng. Nếu tốt hơn, nên tạo plan cho từng sprint ở mức high level.

Tiếp theo phải là gì?

Tiến hành dự án theo cách thông thường mà bạn, với tư cách là PM/SM nghĩ là hợp lý để hoàn thành dự án với mức độ tự tin và quyết liệt cao nhất. Luôn chú ý tới communication và risk (là hai yếu tố khá "cao cấp" với PM/SM non tay)

Kết luận

Theo kinh nghiệm cá nhân, việc xác định issue log và các hệ thống cận biên cần tích hợp tới là các điểm nóng cần làm để có thể close được dự án.


--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン ヒュン ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.