Bài này định viết từ lâu, giờ post lên để hưởng ứng lời kêu gọi của bác Ogawa: làm thế nào để duy trì một sản phẩm tốt

Từ bé, tôi chưa bao giờ được đánh giá và cũng tự biết là mình ko thuộc loại người có “chất” để làm ra những sản phẩm tốt nhất (tư duy hoàn hảo). Tôi thích làm cái mới, nhưng không đủ kiên trì và dũng cảm để đưa những đề xuất mới đó đến sự hoàn thiện. Gần chục năm nghiên cứu toán học huyền bí, không đóng góp gì vào việc phát triển phẩm chất đó. Một mình một bài báo, mà hầu như chẳng có ai hiểu ngoài tác giả, càng làm tăng cảm giác bất lực vì biết mình không thể tự ép mình để tạo ra “một sản phẩm toán học tốt”

Về nước, tham gia FPT đã cho tôi nhiều cơ hội để hoàn thiện cách nhìn của mình với chất lượng

Đầu tiên là so sánh trực diện với các bậc đàn anh. Giữa chương trình mà tôi viết ra và chương trình a Bảo viết ra quả là khác nhau một trời một vực. Lúc đó tôi mới hiểu đẳng cấp

Thứ đến là sự háo hức được nhìn thấy sản phẩm của mình được ứng dụng và xấu hổ khi nó không giúp được người dùng. Đó là chương trình giữ chỗ cho hàng không Việt nam. Sau thời gian đầu được tung hô, chương trình bắt đầu giở quẻ và crash bất kỳ xuất ý. Phải mất gần một tuần Tết ngồi lỳ tại phòng vé, chúng tôi mới mò ra được lỗi trong việc đặt cấu hình phần cứng của máy tính đã dẫn đến lỗi treo máy

Thứ ba là sỹ diện với các testers. Hồi đó bộ phận phần mềm còn nhỏ, không có tester chuyên nghiệp, chúng tôi tự test cho nhau và công khai. Chẳng ai muốn bị vạch mặt chỉ tên là chương trình của mình lắm lỗi cả, nhất là những lỗi do bọn “fresher” tìm ra. Không hiểu sao khi làm CMM, tôi lại được khuyên là không nên công khai danh tính của những dev gây ra nhiều lỗi.

Nỗi sợ hãi, chắc chắn cũng góp phần không nhỏ vào việc nâng cao chất lượng. Từ năm 1992 chúng tôi bắt đầu làm chương trình cho các ngân hàng. Cứ đến những ngày cuối tháng, cuối năm khi ngân hàng chạy batch, là người toát mồ hôi, tim đập thon thót . Mười hai giờ đêm bị gọi cũng là chuyện thường. Hết tháng này, tháng khác… phải đến hàng năm trời chúng tôi mới khắc phục được những lỗi sơ đẳng về xử lý concurency

Chất lượng không chỉ thể hiện ở code, mà còn ở mô hình kinh doanh/tổ chức. Ở đây không thể cải tiến chất lượng nếu không có sức ép của sếp. Anh Bình là người cổ vũ, nhưng cũng là người luôn không hài lòng với bọn chúng tôi. Năm 1997, anh bảo là phần mềm chẳng có tương lai gì nếu cứ làm với phong cách amateur như bọn tôi hồi đó. Anh thúc ép bọn tôi phải thay đổi, đích thân dắt chúng tôi sang Ấn độ để xem cách “người ta làm phần mềm”.

Bắt đầu Fsoft, được cọ xát với những khách hàng thuộc loại đòi hỏi bậc nhất tại Nhật, Mỹ, châu Âu, quả thật là một cơ hội không thể nào tốt hơn để tôi trực tiếp có những trải nghiệm về “chất lượng quốc tế”. Từ bố trí văn phòng, tổ chức cuộc họp, phỏng vấn ứng viên, teleconf, post morterm, xin lỗi, kiểm điểm đến những buổi review thâu đêm, những tập test cases dày cộp. Từ những nỗi ê chề khi bị khách hàng nhìn với con mắt thương hại, đến niềm hân hoan thấy có công góp của mình trong những sản phẩm công nghệ tiên tiến nhất của những hãng công nghệ hàng đầu thế giới. Một trường học vĩ đại mà tôi thấy tiếc nuối là đã “tốt nghiệp” hơi sớm.

Rõ ràng là muốn làm ra một sản phẩm tốt, cần phải có 1 nền văn hóa vì sự “hoàn hảo”. Là một sự phối hợp đồng bộ giữa con người, quy trình, khách hàng, công cụ, tổ chức. Là một môi trường năng động khuyến khích tối đa sự cởi mở và hợp tác. Và trên hết là phải quăng mình vào cuộc cạnh tranh bình đẳng và khốc liệt theo những tiêu chuẩn quốc tế nghiêm ngặt nhất

Tư duy hoàn hảo không có nghĩa là chúng ta đã đạt được sự hoàn hảo. Tư duy hoàn hảo là khi chúng ta nhìn thấy và tin tưởng vào khả năng tiến bộ của mình, mạnh dạn bước vào mọi thách thức.