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/3/2010 11:20:50 AM    Quote    Report

Guest at 12/3/2010 10:16:31 AM
PM của Fsoft, đại đa phần không bằng DEV của nhật thì làm sao tránh khỏi ... (xin lỗi nếu nói quá!)
Bên Nhật, làm DEV khoảng 7 đến 10 năm mới lên SE và Manager.
Fsoft chắc chỉ cần 1 năm là lên PTL, 2 năm đã lên PM ...

Bạn cứ nói quá lên thế chạm tự ái của hơn 200 PM FS đấy. Các bạn PM trẻ của mình chỉ ngang với kiểu PTL bên Nhựt thôi. Tuy nhiên cũng cần phải tự hào mà nói rằng rất rất nhiều dự án các bạn PM trẻ làm việc một cách sòng phẳng với các bác PM hàng chục năm kinh nghiêm của Nhật

Guest at 12/3/2010 1:36:13 PM    Quote    Report

Dân Nhật chuyên nghiệp nó thế, nhưng trong lòng họ luôn nghĩ mấy thằng nhóc này dốt thấy mẹ, âu cũng là do đất nước nó kém phát triển, mình ráng giúp cho nó khá lên.

(Chỉ tội mấy thằng nhóc PM FS, mở mồm khoe khoan kiến thức để ráng bằng các chú các bác mà không biết họ đã hạ mình xuống thấp chỉ chực chạm mặt đất cho bằng mình).

Guest at 12/3/2010 1:38:46 PM

Xóa vì không liên quan đến chủ đề

Guest at 12/3/2010 3:49:46 PM    Quote    Report

Guest at 12/3/2010 1:36:13 PM
Dân Nhật chuyên nghiệp nó thế, nhưng trong lòng họ luôn nghĩ mấy thằng nhóc này dốt thấy mẹ, âu cũng là do đất nước nó kém phát triển, mình ráng giúp cho nó khá lên.

(Chỉ tội mấy thằng nhóc PM FS, mở mồm khoe khoan kiến thức để ráng bằng các chú các bác mà không biết họ đã hạ mình xuống thấp chỉ chực chạm mặt đất cho bằng mình).

Bác này có vẻ như không có tẹo nào lòng tự hào dân tộc, tự hào về kiến thức của mình thì phải. Đành rằng chúng ta kém, chúng ta chậm phát triển hơn các nước bạn nhưng nếu mãi tư tưởng kiểu như bác thì muôn đời không khá được.

MinhHA at 12/3/2010 4:38:39 PM    Quote    Report

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.

Nói chung, cần trao đổi để khách hàng hiểu rằng đôi khi delay là cần thiết, daily report cần phải dẹp bỏ nếu không thích delay nhiều hơn, dự án có nguy cơ fail không phải là điều gì quá nghiêm trọng; không phải cái gì khách hàng yêu cầu cũng phải làm, cần phải biết cách nói không khi nói có là một điều ngớ ngẩn.
Có như vậy các bạn mới có thể có sức khỏe và niềm vui để hoàn thành tốt công việc được

Sơn nhọ at 12/3/2010 4:41:42 PM    Quote    Report

Đúng đúng đúng, đại nhân Minh nói rất đúng.

Guest at 12/4/2010 10:00:34 AM    Quote    Report

Bạn Minh nói không sai, PM phải biết cân nhắc cái gì cần, ko cần cho dự án.
Người Nhật rất hay vặn vẹo, nhưng nếu có lý lẽ chính đáng, họ sẽ vui vẻ đồng ý.

Chỉ có điều các PM hãy 1 lần đứng trên quan điểm Khách Hàng, suy ngẫm tại sao họ cần báo cáo hàng ngày?
Bỏ ra một đống tiền, cái họ cần là 1 sản phẩm chất lượng và đúng thời hạn. Họ có kế hoạch riêng, nếu mình chậm sẽ ảnh hưởng đến kế hoạch của họ.

Người Nhật làm gì cũng có cái lý của nó. Rất ít, có lẽ là ko, người làm bừa. Khi họ yêu cầu báo cáo chi tiết hàng ngày, có nghĩa là họ đã cảm thấy dự án có vấn đề, và họ muốn nó phải giải quyết thỏa đáng.

Nhật chủ yếu là CMMI level 3, nhưng PM của họ phân tích số liệu rất tốt. Vậy nên khi có vấn đề, cái họ đòi đầu tiên bao giờ cũng là báo cáo và số liệu. Số liệu sai -> phân tích sai -> phán đoán sai, vậy nên tội rất nặng.

Thiết nghĩ, Fsoft nên có chế độ, đào tạo dành cho SE. cty phần mềm càng nhiều SE, chất lượng sẽ tốt lên rất nhiều.

nirvana2212 at 12/4/2010 10:34:34 AM    Quote    Report

Và giờ thì đã out để thử với ý tưởng mới.
Nhưng công bằng mà nói, làm business ko chỉ có mỗi vấn đề PM và những điểm khác thì mình thấy fsoft làm rất giỏi, "honto ni".


Gakki at 12/3/2010 9:24:09 AM
Thế còn hỏi, không chui vào làm sao mà biết.
<FONT size=2><I>
Guest at 12/2/2010 3:26:52 PM
Bố đời, thế còn chui vào fsoft làm gì?

&lt;font size="2"&gt;&lt;i&gt;

nirvana2212 at 12/1/2010 7:06:10 PM

Mình làm PM 5 năm ở cty Nhật, đến khi vào FSoft thì thấy cách quản lý ở đây cứ như là chả có quản lý gì cả. Tự compare với cty cũ thì thấy về kỹ thuật thì ko nhiều khác biệt nhưng nhận thức ở đây thì thua khoảng 3 năm so với cty mình cũ. Tuy nhiên khi người ta chưa trải nghiệm thì rất khó mà tự nhận thức đc, các DL, GL thì còn tệ hơn. Vậy nên mình cũng đành kệ. Hơn nữa với phương châm quân số lớn của Fsoft và tư tưởng ko hướng đến đào tạo nhân viên thì mãi mãi vẫn sẽ như vậy.



&lt;/i&gt;

</I></FONT>

Guest at 12/4/2010 11:03:32 AM    Quote    Report

Cái lối suy nghĩ của Guest at 12/4/2010 10:00:34 AM quẩn quanh, cái này không sai, nhưng cái kia cũng đúng, muốn có cái này, nhưng cũng cần cái kia. Nghe qua thì hợp lý, muốn bác lại cũng khó, nhưng nghe mãi phát ngấy, thấy nó hãm tài.
Ý kiến của MinhHA đúng sai đừng phân tích làm gì, nhưng điểm quan trọng nó nói lên là: hoặc là chọn 1, hoặc là chọn 2, chỉ cần dứt khoát, đừng chọn mỗi thứ một tí. Tôi thấy tin tưởng những người suy nghĩ như vậy. Tôi bất tín nhiệm những người loay hoay với đủ các thứ lý luận, cầu toàn, nói lý thì giỏi mà thực ra bất tài, làm một việc mong đạt 10 mục tiêu, nhìn thấy 10 khó khăn, gieo rắc cho đồng đội 10 nỗi sợ hãi.

BQT at 12/5/2010 12:36:56 PM    Quote    Report

BQT đã remove các comment lạc đề để topic thảo luận đúng hướng!
BQT kính báo!

Guest at 12/6/2010 12:30:58 AM    Quote    Report

Cái suy nghĩ của Guest at 12/4/2010 11:03:32 AM theo mình, nếu ông này mà được lên làm PM (mà không có đầu óc phân tích tình hình, risks của dự án) thì chắc là sẽ để cho ace OT điên cuồng, chất lượng dự án tồi tệ (nếu ace không nhiệt tình làm việc)
Với ý nghĩ tiêu cực: "Nghe qua thì hợp lý, muốn bác lại cũng khó" -> hợp lý thì muốn bác làm chi? hay chỉ để chứng tỏ mình luôn luôn đúng, ý kiến người khác không là cái chi cả?
"nhưng nghe mãi phát ngấy" -> không biết lắng nghe ý kiến để học hỏi thì nghỉ việc cho rồi nói chi lên PM :)

hoặc là chọn 1, hoặc là chọn 2, chỉ cần dứt khoát, đừng chọn mỗi thứ một tí. -> ngu, không biết phân tích, nguời ta phân tích chọn mỗi thứ 1 tí vì có lý do, mỗi thứ có điểm lợi điểm hại khác nhau, biết đâu kết hợp cái hay của 1 & 2 thì sẽ tốt hơn. tên Guest này mà lên làm PM thì hỏng .

Tôi bất tín nhiệm những người loay hoay với đủ các thứ lý luận, cầu toàn, nói lý thì giỏi mà thực ra bất tài, làm một việc mong đạt 10 mục tiêu, nhìn thấy 10 khó khăn, gieo rắc cho đồng đội 10 nỗi sợ hãi.
-> chắc là sếp to? không biết leo lên bằng cách nào? nịnh bợ? hay là leo đường sau nào?
Trong khi mình thấy bạn Guest at 12/4/2010 10:00:34 AM có đóng góp tích cực, ý kiến hay. Phân tích tình hình ở đây không phải reo rắc nỗi sợ hãi (ngu quá nên suy diễn linh tinh?) mà là để biết mình nên làm gì trong tình huống đó, giúp nv giải quyết vấn đề 1 cách triệt để, không để lại 1 đống shit về sau phải hốt :)

Any way, mỗi nguời có một cách làm việc riêng, nhưng theo mình nghĩ
Guest at 12/4/2010 11:03:32 AM mà làm PM thì chỉ có làm cho nv của mình cày mục mặt ra vì không biết phân tích vấn đề rõ ràng, triệt để, không biết lắng nghe ý kiến góp ý của người khác, nguời ta cầu toàn vì sao? vì muốn làm tốt công việc của mình, môt nguời sếp mà không thấy đuợc điểm này thì về cày ruộng đi, không thì sẽ làm khổ anh em ;)

Guest at 12/6/2010 10:49:57 AM    Quote    Report

Cảm ơn bạn Guest at 12/6/2010 12:30:58 AM, có đồng quan điểm với bạn.

Mỗi cty có một chiến lược, chính sách, cách quản lý riêng, cái này ai cũng rõ. Nhưng bạn thấy có điểm chung là "hầu hết đều rất coi trọng DEV/TEST, SE".

Riêng Fsoft có vẻ khác, nhiều khi chân ướt chân ráo cũng lên PM, ngay cả biết tiếng Nhật, không biết kỹ thuật cũng lên PM... (Tất nhiên, có rất nhiều PM có kinh nghiệm, tâm huyết, cái này ai cũng biết)

Những PM kiểu như vậy, thử hỏi có phán đoán, giải quyết được vấn đề của dự án hay không? Hay chỉ là đảm nhiệm như kiểu cầu nối, phiên dịch viên? Có vấn đề gì thì đổi lỗi cho PTL và các thành viên khác?
(Xin lỗi bạn nói thẳng, Fsoft ko thiếu PM như vậy)

Bạn là nhân viên Fsoft gần 4 năm, làm việc với KH Nhật trong suốt thời gian đó và nghỉ Fsoft đã gần 3 năm.
Giờ vẫn làm cho KH Nhật, thỉnh thoảng vào chợ dưa hóng hớt tí cho đỡ nhớ Fsoft :)
Có gì anh em đừng chém gió :))

Guest at 12/6/2010 1:58:23 PM    Quote    Report

Các bác bàn lắm quá làm gì?

Nguyên nhân chính là do đồng tiền. Thử hỏi xem PM, PTL (chưa nói đến Dev) lương được bao nhiêu. Muốn chất lượng liệu có được không?

Nguyên nhân sâu hơn là ở các sếp. Lợi nhuận, doanh thu nhiều, nhưng tái đầu tư vào con người được bao nhiêu?

Đừng có bắt dân đen phải làm gì nếu bản thân các sếp không làm gì!

HongHS (QA) at 12/6/2010 2:29:34 PM    Quote    Report

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/6/2010 3:59:18 PM    Quote    Report

Deleted by author

Guest at 12/6/2010 4:05:19 PM    Quote    Report

Chuẩn.

Guest at 12/6/2010 1:58:23 PM
Các bác bàn lắm quá làm gì?



Nguyên nhân chính là do đồng tiền. Thử hỏi xem PM, PTL (chưa nói đến Dev) lương được bao nhiêu. Muốn chất lượng liệu có được không?



Nguyên nhân sâu hơn là ở các sếp. Lợi nhuận, doanh thu nhiều, nhưng tái đầu tư vào con người được bao nhiêu?



Đừng có bắt dân đen phải làm gì nếu bản thân các sếp không làm gì!

Guest đã bị xóa bài at 12/6/2010 5:27:50 PM    Quote    Report

Comment thế này có vi phạm gì đâu mà admin xóa nhỉ. Không nhìn vào nguyên nhân thực tế thì làm sao mà thay đổi được hiện trạng? Hay là chỉ muốn những lời "hay" ý "đẹp".

Một dự án thì có mấy người thâm niên tầm 2 năm trở lên? có mấy người đã gắn bó được với khách hàng tầm 1 năm trở lên? Hay cứ 1 dự án là một loạt member mới. Như thế lấy đâu kinh nghiệm, lấy đâu bài học mà dự án chẳng fail, khách hàng chẳng comment, phàn nàn...


Guest at 12/6/2010 4:05:19 PM
Chuẩn.

<font size="2"><i>

Guest at 12/6/2010 1:58:23 PM

Các bác bàn lắm quá làm gì?







Nguyên nhân chính là do đồng tiền. Thử hỏi xem PM, PTL (chưa nói đến Dev) lương được bao nhiêu. Muốn chất lượng liệu có được không?







Nguyên nhân sâu hơn là ở các sếp. Lợi nhuận, doanh thu nhiều, nhưng tái đầu tư vào con người được bao nhiêu?







Đừng có bắt dân đen phải làm gì nếu bản thân các sếp không làm gì!



</i>

Guest at 12/6/2010 10:00:03 PM    Quote    Report

@ bạn Guest at 12/6/2010 12:30:58 AM: mình là người được bạn ưu ái mạt sát thậm tệ trong cái comment dài ngoằng của bạn đây, như bạn thấy đấy mình không đi phán đúng phán sai ý kiến nào trong topic này cả, mình đơn giản là nghi ngờ và không thích tranh luận với những người thích biện bác như bạn thôi.
Với ý kiến của bạn chẳng hạn, ai bị gọi là ngu mà chẳng muốn trả lại đôi câu, nhưng mình đã tự nhủ bản thân như vầy: "Shut up! Thằng này suy nghĩ nó quá khác mình, nói nhiều vô ích".
Vậy nhé, hi vọng không làm bạn mất hứng :) Dù sao mình cũng không hề ác cảm với bạn, vì những gì bạn nghĩ, cũng có thể mình đã từng nghĩ. Rồi ai dù thông minh đến mấy cũng sẽ có lúc phải trải qua cái đoạn "không nói lý lẽ, chỉ nói niềm tin", "không dựa vào lý luận, chỉ dựa vào kinh nghiệm" thôi.

Guest at 12/6/2010 10:21:31 PM    Quote    Report

nói thêm về ý kiến của MinhHA - như mình đã nói là mình không phân tích đúng sai gì cả: nếu đó là bro Hoang Anh Minh và nếu bro H.A.Minh đúng như mình cảm nhận (tiếc là cũng không quen biết gì nhiều) thì đó là ý kiến của một người tự tin, quả quyết, tỉnh táo không sa vào suy nghĩ rắc rối, vậy nên mình thấy tin tưởng, thế thôi.

Guest at 12/6/2010 11:16:25 PM    Quote    Report

Fsoft rõ ràng đang lừng chừng ở hai yếu tố:
1. Đủ sức để cột chân tất cả những thằng vào công ty buộc phải làm và làm cho cực tốt công việc với mọi khả năng. Làm theo phương pháp này thì không hi vong ăn ngay chỉ hi vọng đến một thời nào đó giống như 13 ông thành lập FPT. Tôi nói là "đủ sức" thì mới làm được
2. Kỳ cọt theo mô hình quản lý công nhân của tư bản nước ngoài: mày làm thì làm không làm tao thuê thằng khác. Làm thế này thì bên phòng tuyển dụng phải là số 1 và hiện tại đang là số 1. Nhưng phương pháp này thì không chắc áp dụng được cho đơn vị thuần về chất xám mặc dù lợi nhuận tốt.