Khách hàng Nhật mong muốn gì??!!!

Posted 12/1/2010 10:39:06 AM by LeGN ()
Under Nghề nghiệp
Last comment 12/22/2010 9:24:28 PM

ABC là dự án của FSDN phát triển mot so chức năng trong Next XYZ development với một khách hàng Nhật. Đây là một dự án lớn với khối lượng công việc lên đến 114 MM và dự kiến kéo dài trong khoảng thời gian là 7 tháng. Dự án ABC kết thúc với số điểm CSS không cao : 66,29 điểm và bị chậm tiến độ đến hơn 1 tháng. Nhìn lại quá trình làm, ABC đã có những hạn chế sau :

- Đội dự án không clear được spec và design từ ban đầu.

- Duration của giai đoạn CR không complete: schedule không tốt => ngay từ đầu, dự án đã không control được tiến độ chặt chẽ, làm ảnh hưởng đến giai đoạn CR cũng như là toàn bộ duration của dự án.

- Team follow schedule không chặt chẽ.

- Năng lực create report của project team không tốt.

Trong bản đánh giá CSS gửi cho đội dự án, khách hàng đã đưa ra những mong muốn, yêu cầu đối với dự án nói riêng và FSOFT nói chung. Và đây cũng là mong muốn chung của nhiều khách hàng của chúng ta.

Trainning

Chúng tôi mong muốn FPT không những training cho PM và Tobe PM về mặt kỹ thuật mà hãy training về cả tinh thần trách nhiệm, đạo đức nghề nghiệp, hiểu mong muốn của khách hàng là gì. FPT đã có training nhưng khoảng cách giữa tầng lớp Manager và developer còn đang rất lớn. Hãy tăng cường training về Management cho các PM. Về developer, thì các bạn hãy training để làm sao hiểu được process tạo ra sản phẩm. Biện pháp để làm việc này là mở các lớp đào tạo, thống qua hoạt động thi đua giữa các đội dự án nhỏ.

Các bạn hãy collect các nội dung comment, biên tập kết quả đối sách và tóm tắt làm thành Handbook. Vì handbook là quan trọng nên các bạn hãy gửi cho chúng tôi review trước. Draft version thì không cần phải hoàn chỉnh lắm nhưng dựa vào đó chúng tôi và FPT sẽ cùng làm việc để ra được một bản Handbook hoàn thiện. FPT cần tổ chức training nội dung Handbook bên trong nội bộ, đặc biệt là training cho PTL trở lên.

Chúng tôi cho rằng độ chính xác trong việc dịch thuật có vấn đề. Các bạn hãy training để comter không bỏ qua những chỗ còn mơ hồ, mà cần phải confirm chắc chắn với phía doi du an và khách hàng chúng tôi.

            Communication

Communication là yếu tố rất quan trọng. Theo quan sát của chúng tôi thì FPT thường trao đổi với nhau qua Skype, email mà ít trao đổi trực tiếp. Nên làm daily meeting thì sẽ tốt hơn.

            Khi trao đổi với khách hàng, đầu tiên các hãy tránh cách nói lý do lý chấu đi, mà hãy phân tích nguyên nhân một cách chân thật. Hãy chọn câu.từ khi hỏi, khi giải thích với người khác. Nếu cách sử dụng từ ngữ hay thái độ qua TV meeting mà có vấn đề thì chúng tôi sẽ chú ý nhắc nhở các bạn. Có những lúc các bạn đưa ra câu hỏi có nội dung tương tự nhau, các bạn hãy share thông tin với nhau để giảm bớt lượng câu hỏi đi nhé.

Report

PM, TL cần phải biết về quản lý số liệu, số liệu và chất lượng là phải chính xác, đó là đạo đức nghề nghiệp. Ngoài ra, cũng cần phải cho developer biết đuợc cách mà PM, TL quản lý qua các con số. Ở Nhật, khi mà con số trong báo cáo sai lệch thì sẽ bị đánh giá năng lực kém. Sai đi sai lại nhiều lần thì sẽ mất độ tin tưởng. FPT hãy coi trọng về các số liệu trong các báo cáo.

Nếu mà các bạn đảm bảo được Chất lượng sản phẩm và Schedule thì không có vấn đề gì cả. Tuy nhiên  tại các dự án của FPT từ trước tới giờ thì thực tế là chưa đạt được. Trong quá khứ rất nhiều lần khi chúng tôi hỏi về nội dung mà được cho là Issue và đối sách của nó thì đều không có được câu trả lời rõ ràng. Như vậy là chúng tôi phán đoán do các bạn không có sự report vấn đề  từ phía bên dưới. Mặt khác thì nội dung trong phần Đối sách cũng không cụ thể rõ ràng. Vì vậy mà các bạn hãy báo cáo tất cả Issue và phương án giải quyết cho chúng tôi. Tại thời điểm chúng tôi phán đoán là có khả năng giải quyết vấn đề thì chúng tôi sẽ đưa ra tiêu chuẩn phán định. Đối với chúng tôi thì mặc dù có thể điều chỉnh được level chi tiết của report nhưng không chấp nhận việc Management bỏ bê 1 loạt.

Công việc làm report định lượng là một công việc khá vất vả. Các con số trong report là các thông số để FPT báo cáo cho chúng tôi. Con số trong report rất cần thiết và không thể thiếu được. Đặc biệt là dự án ABC là dự án rất quan trọng, bên chúng tôi phải báo cáo lên cho BGD cho nên số liệu lại càng phải quan trọng. Chính vì vậy khi report mà xảy ra sai số trong report, mâu thuẫn số liệu thì đó là lỗi cực kì nặng của quán lý. Dựa vào các con số để phân tích đưa ra đối sách. Dựa vào kết quả phân tích và đối sách thì có thể phải huy động thêm cả trăm người. Khi đưa ra số sai-> phân tích sai-> ảnh hưởng rất lớn đến dự án. Do vậy, yêu cầu cơ bản nhất cho report là số liệu phải chính xác.

Senior manger lại càng phải ý thức được việc quan trọng của con số trong các báo cáo. Mức độ chi tiết và độ chính xác của báo cáo cũng thể hiện trinh do, dang cap của FPT.

Trong dự án sau thì trong ke hoach, FPT phải define rõ ra cách lấy các số liệu như thế nào, cái gì làm được, cái gì không làm được. Nếu các bạn nâng cao được năng lực xác lập process collect data và khả năng phân tích thì có thể tạo report nhanh chóng.

Tài liệu Quality opinion (Report kết quả test) là cần thiết. Đây là sự khác nhau về văn hóa chất lượng. Hãy cho chúng tôi biết thông tin số bug sau khi delivery của các bạn.

            Quality

            QA chúng tôi là người đảm bảo chất lượng sản phẩm và họ rất tự hào về việc đó, do vậy họ không nhân nhượng. Ở Nhật thì QA và SE như kẻ địch. SE ở Nhật cũng không muốn QA phải sờ vào sản phẩm nên cố gắng làm ra sản phẩm tốt. Do vậy bên SE và QA đã thường xuyên xảy ra cãi vã. Vì QA và SE  rất cạnh tranh nhau về chất lượng do vậy mà sản phẩm làm ra cũng rất chất lượng. Rất mong QA FPT cũng làm được như vậy.

Về việc check chất lượng thì chúng tôi đang check dựa trên Checklist tiêu chuẩn của QA. Dù nó có là chi tiết nhưng đã là bug thì nó vẫn là bug, các bạn hãy học điều đó. Các bạn hãy nhận thức rằng người phụ trách sản xuất không chỉ là FPT mà còn là khách hàng chúng tôi nữa.

Các bạn hãy nhận thức là Document chính là Kinh thánh của Program nhé. Vì để đến khi biết được Document có sai sót, rồi cho tới khi program hoạt động bình thường thì sẽ tốn nhiều thời gian và việc sửa lại sẽ trở nên khó khăn.

Từ trước tới nay, chúng tôi  đã có nhiều lần phát hiện ra là đội dự án cố tình không thực hiện test. Chính vì vậy mà chúng tôi phải request lấy Evidence. chúng tôi nghĩ không cần những Deliverable thừa. Từ nay trở đi chúng tôi muốn trao đổi với các bạn về vấn đề này. Tuy nhiên, khi phát hiện ra bug ở giai đoạn UT ở công đoạn sau thì sẽ có câu hỏi là các bạn đã thực hiện Confirm như thế nào.

Về chất lượng thì không có chuyện lờ mờ, sai sót ở đây. Việc Management cần phải được định lương có độ chính xác cao. Nếu các bạn không làm được như vậy thì hãy nhận thức là sẽ bị mất lòng tin. Lý do người Nhật comment format là vì những cái đó thuộc về qui chuẩn rồi. Đã có qui chuẩn rồi mà còn phạm lỗi thì độ tin tưởng về chất lượng nói chung không đáng tin cậy.

Guest at 12/6/2010 11:20:47 PM    Quote    Report

Ông này vứt đi rồi. Cương vị là một QA già đời nếu thấy lãnh đạo làm sai hướng gây ảnh hưởng nghiêm trọng đến chất lượng thì phải đấu tranh. Đăng này biết rồi và mặc xác mọi thứ thì đó là làm không hêt trách nhiệm QA. Đấu tranh đến cùng cho chất lượng sản phẩm theo yêu cầu của khách hàng ông hiều không? Không cần quan tâm đến sếp mình được bao tiền

HongHS (QA) at 12/6/2010 2:29:34 PM
Với vai trò là QA, tôi chỉ có một chút thinking thế này:

- Khách hàng Nhật thực ra rất tử tế và họ thường suy nghĩ kiểu Win-win. Họ chỉ ra cái sai cho mình và mong muốn mình cải thiện. Chứ ko như những thằng Châu Âu-Mỹ, mình sai nó stop luôn, thế là ko còn có cả cơ hội để cải thiện.

- Thường những khách hàng Nhật mới làm việc với chúng ta sẽ luôn có những comment như ở trên, vì sao? Vì hệ thống chúng ta chưa tốt, chưa có phương pháp triển khai ngang những bài học như ở trên, ở mức tổ chức, những bài học như ở trên cần tuyên truyền và đưa ra đối sách ngay lập tức. Tuy nhiên, thường những ông nhận được dự án mới thì cười toe toét, đếch còn thời gian mà ngồi phân tích đưa đối sách đến lúc issue đến đít rồi thì ngồi khóc hoặc đầu hàng.

- Với những khách hàng Nhật lâu năm, họ bắt đầu thất vọng vì chúng ta (Fsoft) không phát triển được, vì sao? Họ muốn mình cải thiện,tuy nhiên bên mình có thực sự mong muốn cải thiện hay ko đầu tiên phải chỉ ra được mình cải thiện thế nào. Thế nhưng hầu như các dự án đầu tư thời gian cho việc phân tích và đưa ra đối sách rất ít. Thế nên đối sách đưa ra rất hời hợt và đối phó, ko chủ tâm tự mình thấy cần improve thực sự.

Còn việc cải thiện mức hệ thống thế nào thì có nhiều anh/chị/bạn ở trên đã nói một số rồi, ko biết là các top của mình có thực hiện hay ko thôi.

Guest at 12/7/2010 12:44:20 AM    Quote    Report

Các bác lý luận thế nào chăng nữa, cũng mong các bác thực tế một chút.
@ Guest at 12/6/2010 11:20:47 PM: bác đòi hỏi một QA Fsoft một điều không khác gì đòi "một người trung thực thì không bao giờ nói dối", nói như bọn Tây là "unreasonable". Nếu bác mà làm QA thì nói tên ra xem là ai mà nói người khác "vứt đi" như vậy. Nếu không, bác là dev hay từng là dev chẳng hạn, và ae ở đây yêu cầu bác luôn luôn unit test cẩn thận đúng như trách nhiệm của một dev đối với chất lượng chẳng hạn, bác sẽ nói gì, em xin nghe?
@HongHS: cái này không dám khẳng định, nhưng với một khách hàng Mỹ mình làm, nó cũng cho hết cơ hội này đến cơ hội khác. Ngược lại có phải không từng có những khách hàng Nhật cancel ngay từ phase đầu tiên? Khẳng định "Âu Mỹ stop ngay" không rõ từ đâu ra, giá mà có một cái vote đúng/sai cho ae Fsoft vote, kết quả chưa biết thế nào nhỉ?
Em cũng hiểu đó không phải là những điểm quan trọng trong ý kiến của các bác, nhưng góp thêm tí gió để các bác tranh luận thêm hăng say, để em được hiểu các bác hơn ^^

Guest at 12/7/2010 1:54:21 AM    Quote    Report

Topic hay quá. Nhân đây xin hỏi các anh chị QA lâu năm ở Fsoft: có phải Fsoft (hay một vài anh chị) từng có ý tưởng tổ chức QA độc lập hoàn toàn (tức là tất tần tật về power, assessment, activity, ...) với các development unit không?

Như em thấy mong muốn của khách hàng này về QA và Quality đúng quá, nhưng chỉ thực hiện được khi mà chúng ta "cởi trói" cho QA để QA thực sự được quyền reject các deliverables kém chất lượng, bất kể điều đó ảnh hưởng thế nào đến business plan ngắn hạn của cả công ty (không phải chỉ project plan không thôi).

Nói cách khác QA có thể kill một dự án trong khi có khả năng là khách hàng vẫn "cho cơ hội" ấy.

Nếu có ý tưởng như thế thì phản biện là gì? Hay là chúng ta về lý thuyết là đang như thế rồi?

Guest at 12/7/2010 5:38:00 AM    Quote    Report

QA hiện tại á? Ngồi trong cuộc họp, hỏi vài câu, góp vài ý, chém vài nhát. Xong vui vẻ cả làng, "cố lên các bạn nhá".

Guest at 12/7/2010 9:39:38 AM    Quote    Report

Mình chưa thấy có QA nào mà ko cho gửi sản phẩm đi khi sản phẩm còn đầy lỗi. Vì QA cũng muốn gửi cho khách hàng đúng hạn mà.

Ts at 12/7/2010 10:40:20 AM    Quote    Report

Bài Post này hay quá, rất là có ích đấy.

lẹt bẹt at 12/7/2010 3:11:23 PM    Quote    Report

Tất cả những issue trong bài này đều đã có và sẽ có. Làm sao được khi chính sách tuyển người mới ồ ạt, người có năng lực đi thì nhiều mà người có năng lực lên thì ít. Lại còn trợ cấp PM, liệu có mấy PM xứng đáng được nhận trợ cấp???

HongHS (QA) at 12/7/2010 3:45:06 PM    Quote    Report

Guest at 12/7/2010 5:38:00 AM Quote Report

QA hiện tại á? Ngồi trong cuộc họp, hỏi vài câu, góp vài ý, chém vài nhát. Xong vui vẻ cả làng, "cố lên các bạn nhá".

-> Bạn QA nào mà chỉ làm được việc này thì chưa đủ năng lực làm QA thực sự.

HongHS (QA) at 12/7/2010 3:55:24 PM    Quote    Report

Guest at 12/7/2010 1:54:21 AM Quote Report

Topic hay quá. Nhân đây xin hỏi các anh chị QA lâu năm ở Fsoft: có phải Fsoft (hay một vài anh chị) từng có ý tưởng tổ chức QA độc lập hoàn toàn (tức là tất tần tật về power, assessment, activity, ...) với các development unit không?

Như em thấy mong muốn của khách hàng này về QA và Quality đúng quá, nhưng chỉ thực hiện được khi mà chúng ta "cởi trói" cho QA để QA thực sự được quyền reject các deliverables kém chất lượng, bất kể điều đó ảnh hưởng thế nào đến business plan ngắn hạn của cả công ty (không phải chỉ project plan không thôi).

Nói cách khác QA có thể kill một dự án trong khi có khả năng là khách hàng vẫn "cho cơ hội" ấy.

Nếu có ý tưởng như thế thì phản biện là gì? Hay là chúng ta về lý thuyết là đang như thế rồi?

-> Hiện nay QA hoàn toàn có quyền reject một sản phẩm nếu nó không đủ quality. Vấn đề là làm thế nào QA có thể reject được mà đội dự án tâm phục khẩu phục và chấp nhận delay delivery:
- Thứ nhất: Tiêu chí nghiệm thu sản phẩm phải rõ ràng và QA dựa trên tiêu chí của khách hàng để nghiệm thu sản phẩm đó, như vậy thì nếu không đạt tiêu chí QA có quyền reject.
- Thứ hai: Phải có căn cứ rõ ràng, bằng chứng xác đáng. Ví dụ: để release sản phẩm, đội dự án phải thực hiện hoạt động verification (review or test) đối với sản phẩm đó, nhưng QA ko tìm thấy bằng chứng hoặc bằng chứng ko đầy đủ thì có quyền yêu cầu đội dự án phải thực hiện lại hoạt động verification, nếu không thực hiện lại thì có thể reject vì những sản phẩm chưa được verification thì ko thể kết luận quality của sản phẩm đó là good được.
- Thứ ba: QA là người trực tiếp nghiệm thu sản phẩm, chứ không chỉ nhìn thấy bề nổi là thiếu record, thiếu bằng chứng mà có thể reject ngay thì sẽ rất thiếu thuyết phục mà thông qua bằng chứng trực tiếp sẽ khiên đội dự án tâm phục khẩu phục.

HongHS (QA) at 12/7/2010 3:57:24 PM    Quote    Report

Guest at 12/7/2010 1:54:21 AM Quote Report

Topic hay quá. Nhân đây xin hỏi các anh chị QA lâu năm ở Fsoft: có phải Fsoft (hay một vài anh chị) từng có ý tưởng tổ chức QA độc lập hoàn toàn (tức là tất tần tật về power, assessment, activity, ...) với các development unit không?

Như em thấy mong muốn của khách hàng này về QA và Quality đúng quá, nhưng chỉ thực hiện được khi mà chúng ta "cởi trói" cho QA để QA thực sự được quyền reject các deliverables kém chất lượng, bất kể điều đó ảnh hưởng thế nào đến business plan ngắn hạn của cả công ty (không phải chỉ project plan không thôi).

Nói cách khác QA có thể kill một dự án trong khi có khả năng là khách hàng vẫn "cho cơ hội" ấy.

Nếu có ý tưởng như thế thì phản biện là gì? Hay là chúng ta về lý thuyết là đang như thế rồi?

-> Hiện nay QA hoàn toàn có quyền reject một sản phẩm nếu nó không đủ quality. Vấn đề là làm thế nào QA có thể reject được mà đội dự án tâm phục khẩu phục và chấp nhận delay delivery:
- Thứ nhất: Tiêu chí nghiệm thu sản phẩm phải rõ ràng và QA dựa trên tiêu chí của khách hàng để nghiệm thu sản phẩm đó, như vậy thì nếu không đạt tiêu chí QA có quyền reject.
- Thứ hai: Phải có căn cứ rõ ràng, bằng chứng xác đáng. Ví dụ: để release sản phẩm, đội dự án phải thực hiện hoạt động verification (review or test) đối với sản phẩm đó, nhưng QA ko tìm thấy bằng chứng hoặc bằng chứng ko đầy đủ thì có quyền yêu cầu đội dự án phải thực hiện lại hoạt động verification, nếu không thực hiện lại thì có thể reject vì những sản phẩm chưa được verification thì ko thể kết luận quality của sản phẩm đó là good được.
- Thứ ba: QA là người trực tiếp nghiệm thu sản phẩm, chứ không chỉ nhìn thấy bề nổi là thiếu record, thiếu bằng chứng mà có thể reject ngay thì sẽ rất thiếu thuyết phục mà thông qua bằng chứng trực tiếp sẽ khiên đội dự án tâm phục khẩu phục.

HongHS (QA) at 12/7/2010 4:01:46 PM    Quote    Report

Guest at 12/7/2010 12:44:20 AM Quote Report
@HongHS: cái này không dám khẳng định, nhưng với một khách hàng Mỹ mình làm, nó cũng cho hết cơ hội này đến cơ hội khác. Ngược lại có phải không từng có những khách hàng Nhật cancel ngay từ phase đầu tiên? Khẳng định "Âu Mỹ stop ngay" không rõ từ đâu ra, giá mà có một cái vote đúng/sai cho ae Fsoft vote, kết quả chưa biết thế nào nhỉ?
-> Cái này thì đứng ở view sau: Những công ty coi chúng ta là chuyên nghiệp (ko biết có phải do sale hót hay quá hay ko) giao việc cho chúng ta, nhưng sau một thời gian dự án thấy chúng ta ko làm được -> stop luôn.
Những công ty Nhật họ thừa biết trình độ của chúng ta, do vậy họ vừa giao việc, vừa training, họ chỉ thất vọng nếu sau một vài năm mà skill của chúng ta ko tăng lên mà thôi. (Có thể do turnover rate quá lớn chăng?)

HongHS (QA) at 12/7/2010 4:04:37 PM    Quote    Report

Guest at 12/7/2010 9:39:38 AM Quote Report

Mình chưa thấy có QA nào mà ko cho gửi sản phẩm đi khi sản phẩm còn đầy lỗi. Vì QA cũng muốn gửi cho khách hàng đúng hạn mà.

-> Nếu QA của dự án của bạn mà cho phép điều này, thì bạn hoàn toàn có quyền complain. Đối với QA thì nguyên tắc chất lượng luôn luôn được ưu tiên hàng đầu. Sản phẩm mà còn đầy lỗi thì khách hàng sẽ complain nặng nề hơn nhiều việc delay một vài ngày nhưng sau đó package lại ko có lỗi. :D

Nguyễn Trường Giang at 12/11/2010 11:01:45 AM    Quote    Report

Câu này của A.MinhHA rất đúng: "Các bạn nên triệt để tuân theo những lời dạy trên của khách hàng nếu các bạn cảm thấy không đủ tự tin để hướng khách hàng làm theo phong cách của mình. Nhưng làm vậy hiển nhiên là bạn và các đồng nghiệp sẽ bị stress, không sớm thì muộn"

Vấn đề là "phong cách của mình" lại không được tốt cho lắm: năng lực kém, ý thức kém, năng suất kém, chất lượng kém, teamwork kém.

Mà nếu "phong cách của mình" tốt thì khách hàng chẳng cần daily report, thậm chí có khi ko cần cả unit test evident của mình :D (em nghĩ họ chỉ cần những thứ đó khi ko tin tưởng mình thôi)

Giá mà FSOFT ai cũng Pro như anh thì chắc KH lúc nào cũng cho 100CSS ấy chứ :D

MinhHA at 12/13/2010 2:21:13 PM    Quote    Report

@Trường Giang: quả thật chất lượng của mình trong đa số dự án là kém thật nên cái vòng stress giữa hai bên nó mới luẩn quẩn :)

Guest at 12/17/2010 1:23:03 AM    Quote    Report

HongHS (QA) at 12/7/2010 3:45:06 PM
Guest at 12/7/2010 5:38:00 AM Quote Report



QA hiện tại á? Ngồi trong cuộc họp, hỏi vài câu, góp vài ý, chém vài nhát. Xong vui vẻ cả làng, "cố lên các bạn nhá".



-> Bạn QA nào mà chỉ làm được việc này thì chưa đủ năng lực làm QA thực sự.


Hơi bị nhiều ở HCM.

Guest at 12/22/2010 9:24:28 PM    Quote    Report

Khách hàng Người Nhật mà có làm PM một dự án ở FSO tôi nghĩ cũng fail như thường.