Tin Chúa
Phần III cuốn sách "Đek biết gì" là phần quan trọng nhất, giải mã những building blocks trông có vẻ “kỳ dị” đã xây nên cấu trúc tổ chức của Fsoft. Ta sẽ thấy tuy Fsoft được xây dựng theo các phương pháp luận tiên tiến của phương Tây, nhưng lại dựa trên những nền tảng căn bản của Văn hóa Việt Nam. Phần này có 7 chương:
“In god we trust, All others must bring data” là câu nói nổi tiếng của Edward Deming, nói lên tầm quan trọng của việc đo đạc và sử dụng dữ liệu trong những việc ra những quyết định kinh doanh. Đó cũng là câu được in lên áo của các thành viên đội đánh giá CMM lần đầu tiên của Fsoft mặc.
Trên chặng đường đi ra thế giới, chúng ta có thể có nhiều sự lệch pha. Nhưng như các chương 5,6,7 đã đề cập, không phải sự lệch pha nào cũng là khuyết điểm. Ngược lại có khi đó chính là những đặc điểm về văn hóa mà biết tận dụng có thể trở thành điểm mạnh.
Tuy nhiên có một điểm yếu mà chúng ta không thể không khắc phục nếu muốn xây dựng một ngành công nghiệp CNTT có khả năng cạnh tranh trên thị thường toàn cầu. Đó là thói quen ra quyết định dựa trên dữ liệu, làm việc theo quy trình và tuân thủ những chuẩn mực hay nói gọn là tính công nghiệp.
TGB nhận thức được điều này. Cùng lúc với chiến dịch XKPM, Bình đã phân công đệ cứng của mình là Hùng Râu chỉ huy dự án chuẩn hóa hoạt động của toàn bộ FPT.
Trong chuyến đi India tháng 12 năm 1998, đến đâu Bình cũng hỏi xin Process. Bình còn khuyến khích đàn em là Hùng Râu len lén nhặt mấy tập tài liệu trong thùng rác của các công ty mà họ đến tham quan. Chắc do đọc tiểu thuyết trinh thám nhiều quá. Vì mang về hóa ra là rác thật.
Câu chuyện thứ 1: Hùng Râu và ISO ở FPT
Hùng Râu là một nhân vật đặc biệt ở FPT. Không ai biết anh làm gì. Khách nào đến thăm cũng tưởng anh mới là sếp lớn. Còn anh thì luôn tự nhận: Việc của tớ là hoàn thành 50% nhiệm vụ của anh Bình giao, bất kể là việc gì.
Trong những việc được giao đó, có những việc trái khoáy như hợp tác với Vinamilk và bà con nông dân để làm sữa bột Dieclac HV, hoặc ngớ ngẩn như nghiên cứu một cách rất bài bản để phát hiện ra là FPT dốt tiếng Anh. Anh hào hứng kể trong FPT Bí lục
“Anh Bình đưa cho tớ bản copy mấy trang giấy gì đó tớ quên rồi, bảo là phó tổng thống Mỹ Al Gore mới đưa ra phương pháp đánh giá mức độ Knowledge của xã hội Mỹ, em xem mình có dùng được gì không. Để áp dụng vào FPT, tớ đổi thành Sao Công nghệ rồi cùng Trần Quốc Bình (là nhân viên duy nhất của tớ khi đó) nghiên cứu đặt bảng câu hỏi khảo sát đánh giá. Kết quả là mỗi bộ phận và cả công ty đều nhận được một đồ thị dưới dạng “Ngôi Sao” để biết điểm mạnh, điểm yếu của mình kiểu như Benmarking bây giờ. Thực ra toàn những điều mình cũng có thể đoán được, nhưng có tý khoa học thấy đáng tin hơn, sướng hơn hẳn.”
Có một nhiệm vụ tuy Bình không giao, nhưng Hùng biết là Bình thích, đó là lập kế hoạch kinh doanh. Anh đã làm kế hoạch kiểu “đếm cua trong lỗ” cho hai đơn vị mà bây giờ trở thành chủ chốt của FPT là Fsoft và Ftel. Bí kíp của Hùng là xin được một phần mềm đánh giá dự án của Tây trên Lotus 123 từ một người bạn ở UB Hợp tác đầu tư nước ngoài. Rất đầy đủ. Chỉ cần điền các tham số vào là nó ra kế hoạch, các báo cáo cần thiết và kèm theo các chỉ tiêu đánh giá hiệu quả dự án. Hùng chuyển sang dạng Excel, sử dụng GoalSeek để có thể điều chỉnh các thông số kế hoạch dựa vào mục tiêu mong muốn trong tương lai. Thế là cả hai đơn vị mới ra lò chưa biết tương lai thế nào đều có bản KHKD khá chi tiết, anh em thảo luận sôi nổi, mặc dù đều biết đó là bốc phét.
Năm 1995, Bình giao cho Hùng một trong những nhiệm vụ quan trọng, đó là xây dựng quy chế kinh doanh và hệ thống báo cáo tổng hợp. Chu Thanh Hà, khi đó là tổ trưởng bán hàng xa mẹ, trở thành “nạn nhân” phải làm báo cáo đầu tiên, và chắc để khắc phục, chị cưới luôn Hùng Râu.
Hà kể lại: Em không phải làm báo cáo. Nhưng bị “bóc lột”, nhập liệu vào chương trình để anh Hùng làm báo cáo. Lúc đó chương trình Balance in ra các số liệu kế toán, thứ bảy và chủ nhật bọn em phải nhập lại dữ liệu vào MS Money, để thứ hai anh Hùng báo cáo ở giao ban! Kiểu như làm data entry bây giờ. Nhưng háo hức lắm.
Theo Hùng, MS Money là một chương trình tuyệt vời về khả năng tùy biến làm báo cáo. Mặc dù MS thiết kế chỉ đề quản lý dòng tiền cá nhân, nhưng có thể dùng để quản lý doanh thu, hàng tồn, ngoại tệ… rất tiện lợi. Đáng tiếc là sau này Microsoft bỏ đi mất. Có lẽ chính là sự linh hoạt đấy đòi hỏi người dùng phải có một khái niệm rõ ràng về cấu trúc dữ liệu, nên chương trình khó phổ biện. Thực ra ở FPT, tư tưởng của MS Money vẫn sống dưới hình hài một sản phẩm có tên là Boss do Lê Quang Tiến đặt hàng Fsoft làm năm 2002.
Lúc đó, quãng năm 1993, có Đinh Hoa, bạn của Trung Hà - sáng lập viên cùa FPT, là một trong những sinh viên đầu tiên của miền Bắc gửi đi học Harvard, đã dẫn 1 đoàn sinh viên Harvard về FPT thực tập. Hoa mang về 3 cuốn sách: Accounting, Marketing và HR Management. Hùng đã đọc và lấy các mẫu báo cáo từ đó, đổi đi đôi chút như Microsoft thành FSS, FIS,… chủ yếu là các báo cáo về dòng tiền, công nợ, và hàng tồn.
Tất cả được đưa vào Bản quy chế kinh doanh nội bộ số 1 của FPT. Đây là văn bản chính thức đầu tiên của FPT về quản trị kinh doanh. Ban hành đầu năm 1995.
Bản quy chế ra đời, và đương nhiên là bị anh em kinh doanh phản đối quyết liệt. Để hiểu được năng lực quản trị của FPT lúc đó, ta có thể hình dung cảnh NgocBQ (phụ trách tin học nói chung) hỏi lập trình viên kiêm thủ quỹ TamPM: hey Tâm, mình có bao nhiêu tiền? và đợi Tâm từ từ lộn hết các túi ra đếm.
Bị ép làm báo cáo, đương nhiên là anh em báo cáo láo. Hùng đã tìm ra được một quy luật rất hay: làm báo cáo láo còn khó hơn báo cáo thật, miễn là phải có người đọc báo cáo đấy thường xuyên. Nói dối một cách nhất quán liên tục là rất khó. Còn đọc thường xuyên thì Hùng không ngại. Anh nói: Chẳng hạn như hồi đó rất nhiều khi hàng tồn kho thể hiện là số âm. Khả năng lớn là chúng ta đã bán hàng “của người khác” trước khi nhập vào kho mình. Chính những “bất hợp lý” trong số liệu như vậy đã giúp chúng ta điều chỉnh được quy trình kinh doanh, làm việc bài bản hơn.”
Bản QCKD số 1 đấy đáng được tìm lại và lưu trữ trong bảo tàng. Đây chính là 1 nét đặc sắc của “Văn hóa kinh doanh” của FPT: dựa trên số liệu. Có lẽ xuất phát từ suy nghĩ của dân Toán.
Chính tư duy này dẫn đến nhiệm vụ “bất khả thi” mà Bình giao cho Hùng. Đó là chiến dịch ISO/CMM.
Hùng kể:
Tớ nghe thấy thuật ngữ CMM trước ISO. Đó là trong chuyến đi Halifax, Canada vào tháng 10/1998, được dự một seminar người ta bàn về CMM. Tất nhiên là không hiểu gì! Nhưng ISO/CMM liên quan trực tiếp đến chiến lược XKPM của FPT. Lần đó đi Ấn Độ (tháng 12/1998), các công ty Ấn Độ đều khuyên nên làm ISO trước vì dễ hơn. Anh Bình muốn làm CMM, nhưng tớ nói nên làm ISO trước cho FPT vì quân chú (Fsoft) lúc đó hơn chục đứa, có gì mà làm. Thế là chiến dịch ISO bắt đầu.
Phòng Quản lý chất lượng FPT – FQA ra đời, cùng lúc với Fsoft, lúc đó còn gọi là FSU1. Phòng có Hùng và hai nhân viên. Một anh vì không chịu nổi áp lực nên đã chuyển sang làm tiến sĩ Toán. Còn lại mỗi Hùng và một nữ nhân khác, sau này cũng nổi danh giang hồ ở Fsoft, đó là LienBH.
Liên viết trong sử ký:
Tôi chấp nhận thách thức bắt đầu công việc mới ở một môi trường hoàn toàn mới và thách thức, với một hướng đi cực mới nốt, nghe xong chẳng hiểu sẽ phải làm gì để “xây dựng quy trình CMM cho xuất khẩu phần mềm”. Có lẽ ở thế hệ của tôi, sinh ra trong chiến tranh, tranh nhau học hành để được nhà nước cử đi học nước ngoài, khi về chỉ cố gắng để xin được suất biên chế trong thời kì bao cấp khó khăn, cảm giác không được làm gì và không làm gì được. Làm chưa được việc gì, lại khăn gói đi học Cao học bằng học bổng của Nhà nước và khi trở về đã sắp bước vào tuổi tứ tuần mà vẫn loay hoay không biết liệu mình sẽ làm nên trò trống gì không. Lúc đó chỉ muốn được làm một cái gì đó cho có ích và thỏa chí, nhưng mãi chẳng có việc gì “nhớn” để được làm.
Tôi nhận công việc tại phòng FQA, nghiên cứu ISO và CMM với anh Râu. Phòng FQA ra đời chỉ với ba thành viên, sau đó một thành viên luôn luôn bị ảo ảnh về các con số, anh ra khỏi FPT để tiếp tục làm Tiến sĩ ở Viện Toán. Phòng còn lại hai anh em, tôi và anh Râu. Mức lương khởiđiểm hợp đồng ban đầu của tôi là 500 ngàn đồng (thấp so với mức lương 2 triệu của HIPT và với mức lương 150$ khi làm chuyên gia cho dự ánTHCS). Anh Râu giao việc trực tiếp, công việc không kể thời gian miễn là được hoàn thành đúng thời hạn. Có lúc anh Râu giao việc vào 9 giờ tối và hẹn phải báo cáo vào 9 giờ sáng hôm sau. Chắc bây giờ nhiều bạn sẽ rất bức xúc nếu sếp giao việc như vậy, còn lúc đó tôi thấy rất thú vị vì được thách thức. Không thấy khổ gì cả, càng nhiều chuyện “khác người” như vậy càng thấy hay vì chỉ có ở FPT mới như vậy.
Việc đạt được chứng chỉ ISO năm 1999 có thể nói là kỳ tích vì thực sự trong lãnh đạo cũng không ai hiểu hết làm để làm gì. May mà Hùng đã khôn khéo lừa các lãnh đạo ký hết vào một bản cam kết ngay từ khi bắt đầu. Chuyện kể lại, có lần, phải ra quyết định, Hùng họp các lãnh đạo lại và trình bày hai lựa chọn. Đến lúc phải bỏ phiếu, vẫn không ai hiểu gì. Hùng đành phải chấp thuận: các anh chị không cần hiểu, chỉ cần nói là chọn phương án bên phải hay bên trái. Sự kiện này làm tôi nhớ lại chàng thanh niên NAQ ở Đại hội Tour năm 1920, phải lựa chọn giữa Đảng Xã hội và Đảng Cộng sản Pháp. Anh đã hỏi: bên nào ủng hộ thuộc địa? Và đứng về bên đó.
Hùng nói: chắc chắn FPT là một trong những tổ chức đạt được chứng chỉ ISO-9001:2000 đầu tiên trên thế giới! Hệ thống ISO của FPT phức tạp có lẽ là bởi vì lúc đó mọi người muốn thông qua dự án ISO để xây dựng cho FPT một Hệ thống quản trị doanh nghiệp toàn diện kiểu TQM. Thế cho nên một loạt các quy trình không liên quan trực tiếp nhiều đến các yêu cầu của ISO như: Tài Chính, Nhân Sự, Hành Chính, Thông Tin cũng được thiết kế, viết ra và đưa vào áp dụng. Những quy trình này không đánh giá mức độ Compliance với các tiêu chuẩn ISO và với các yêu cầu quản trị doanh nghiệp. Tớ nhớ lúc đó anh Ngọc còn viết Sổ Tay Quá Trình Bóng Đá và bắt các đội bóng FPT tuân thủ!!!
Câu chuyện thứ 2: Sứ mệnh Copy
Năm 2000, Nam và ĐatPP tiến hành một phi vụ “ăn cắp IP” đầu tiên ở Fsoft tại trung tâm đào tạo của TCS, góp phần đẻ ra Fsoft Insight và Dashboard
Hồi mới thành lập FSU1, anh Bình cứ dặn đi dặn lại quan trọng nhất chỉ có vấn đề quy trình và đào tạo đội ngũ. Có lẽ là Fsoft đã rất gặp may khi có những người đã biến được những chỉ đạo đúng đắn nhưng hết sức chung chung ấy thành sự thật.
Phan Phương Đạt là một người như vậy. Thật sự là bây giờ tôi vẫn không hiểu là sao anh lại nhận lời về một đơn vị bé tí của FPT lúc đó làm công tác nhân sự và đào tạo, khi vừa mới tốt nghiệp tiến sĩ toán học từ nước ngoài về.
Đầu năm 2000. Lúc đó chính phủ Ấn độ cho Việt nam vay 5m USD, chẳng biết dùng làm gì. Không hiểu anh Bình dỗ ngon ngọt thế nào chính phủ Việt nam quyết định sử dụng vào việc mua công nghệ đào tạo nhân viên của Ấn độ. Bọn Tata biết vậy nên lobby tích cực FPT. Tôi với Đạt lên đường đến Trivandrum để tìm hiểu về trung tâm đào tạo của TCS.
Trung tâm nằm trên một quả đồi rất đẹp, cây cối, nhà cửa… túm lại là thơ mộng. Chúng tôi sướng mê khi thấy phòng học quy củ, thư viện, bảng tin, sân chơi... lại còn được dự giờ của một vị sếp lớn với nhân viên mới, gọi là “encounter”. Cũng như bây giờ, Đạt lăm lăm máy ảnh, chúng tôi chụp liên tục, cả bàn học, bảng tin để về dò lại nội dung trên đó. Nhưng cũng không nhiều thông tin bổ ích lắm. Hai cái quan trọng nhất là giáo trình đào tạo và nhất là bài giảng về quy trình thì vẫn chẳng biết hỏi ai. Lại có một chú Ấn độ tên là Navnet Kalia được cử take care nên cứ theo sát, cũng mất tự do
Đạt đưa ra sáng kiến, hay mình vào thư viện hỏi mượn giáo trình giảng dạy thế nào cũng có. Y rằng có thật. Chúng tôi mừng húm, mỗi đứa một quyển đọc say sưa, cố gắng ghi nhớ. Được một lúc, đầu óc quay cuồng, khỏi nhớ luôn. Thế là Đạt bảo anh ra cửa trông để em chụp ảnh. Được 4-5 trang thì một chú Ấn độ thình lình xuất hiện. Chúng mày làm gì ở đây? Tao thấy mấy hôm nay đi đâu cũng chụp ảnh, nghĩa là thế nào? Chúng tôi hoảng hồn, luống cuống.
Chúng tao sai rồi. Thế chúng mày muốn xử thế nào?
Bọn mày phải viết ngay một cái mail về nhà, nói rằng trung tâm chúng tao rất xứng đáng đồng tiền bát gạo.
Tưởng gì chứ thế thì quá dễ, tôi viết ngay một cái mail cho anh Bình, kể rằng thế này, thế này,… tóm lại là mình rất nên mua công nghệ này, đưa cho bọn chúng xem, ok rồi gửi đi.
Ra phố, tôi lập tức tìm ngay một kiosk điện thoại để gọi về cho a Bình, tiện thể biết luôn ở nhà đang đàm phán thuận lợi với HarveyNash. Nhẹ cả người
Không cam chịu thất bại, chúng tôi cho rằng nếu không lấy được sách giáo khoa thì phải tìm được thầy. Rồi suy luận tiêp, là ở đây có học sinh, có thư viện, thì chắc phải có thầy giáo. Mà thầy đến đây chắc phải ở chỗ đàng hoàng. Quanh đây chỉ có 1 khách sạn trông 5 sao, bị khoanh vùng. Tối đó, 2 anh em bấm bụng vào ăn nhà hàng trong đó. Y rằng, có một chú đang ngồi ăn. Tiến lại, thì đúng như dự đoán, đó là một lãnh đạo trung tâm ở thành phố khác được phái đến dạy nhân viên mới. Ông này chắc khoái vì tự dưng có mấy thằng ngoại quốc tôn vinh, nên hỏi gì cũng trả lời đầy đủ. Cuối buổi thấy chúng tôi ghi chép không kịp, chú bảo: thôi chúng mày qua Trung tâm của tao, tao bảo bọn đàn em trình bày cho.
Thế là chúng tôi thay đổi lịch trình, bay qua Madras. Đúng hẹn, chú lần lượt kêu đàn em demo cho chúng tôi hệ thống quản lý nhân sự, bảo đảm chất lượng, đào tạo nhân viên, thậm chí cả kế toán. Cuối buổi chú còn copy cho chúng tôi một bản spec chương trình IPMS (Integrated Project Management System), tiền thân đầu tiên của Fsoft Insight.
Chúng tôi lên đường về nước, cảm thấy đường đi nước bước đã rõ hơn nhiều.
Câu chuyên thứ 3: Chiến dịch CMM
Như trên đã nói. Sang Ấn Độ, thấy công ty nào của Ấn cũng khoe là có CMM. Bình rất sốt ruột. Bọn Ấn có, ta phải có. Hùng Râu đã tìm cách hoãn binh, vì biết tiêu chuẩn này có một số đòi hỏi tối thiểu từ tổ chức. Đặc biệt là số lượng dự án.
CMM là một tiêu chuẩn đo độ trưởng thành của các công ty phần mềm do Viện Công nghệ phần mềm SEI thuộc Carnegie Mellon University đặt ra. Theo tiêu chuẩn này thì các công ty phần mềm sẽ được chia thành 5 levels (lớp) từ thấp lên cao. Tiêu chí phụ thuộc vào độ dự đoán được của dự án: về thời gian hoàn thành, nguồn lực cần thiết, và chất lượng sản phẩm. Càng lên cao dự đoán càng chính xác. Ví dụ lập kế hoạch 100 ngày xong, thì bao giờ cũng chỉ loanh quanh 95-105 ngày, chứ không phải lúc 50 lúc 200.
Cuối năm 2001, tình hình thị trường không có nhiều chuyển biến. Dự án vẫn ít. Đợi không biết bao giờ mới có để làm. Anh Bình bảo phải làm. Trước đợi có dự án mới làm CMM. Giờ phải đặt ngược lại, phải có CMM mới có dự án. Biến thành một loại bằng cấp để đi khoe.
Hùng Râu nghiên cứu phát hiện ra trên thế giới chỉ có tầm 200 công ty có mức CMM từ 4 trở lên. Thế là anh đăng đàn tuyên bố: Fsoft sẽ phải thi ít nhất là lấy level 4. Anh em phản đối ầm ầm. Thi thế đ nào được. Đang ở lớp 1, tức là lập trình kiểu ruồi bâu tự phát, chất lượng hên xui, sao mà nhảy hẳn lên lớp 4 được.
Hùng râu cười khẩy: Đây chỉ là một cuộc thi. Ta thì hay khoe giỏi thi. Thi mà còn không được thì các chú làm thế đếch nào được. Anh em thấy cũng có lý. Chắc là trượt thôi, nhưng cứ vống lên thế, nếu có trượt thì bảo là do tao cố quá. Chứ đăng ký lớp 2 mà trượt thì ra cái gì.
Thế là bắt tay vào việc. Hùng Râu đi tìm thầy luyện thi từ tận Ấn độ. Đích thân anh thì bắt tay vào xây dựng PCB: Process Capabiliy Baseline. Một cơ sở dữ liệu dưới dạng excel, chứa một loạt những tham số của quá trình phát triển phần mềm từ timelines, defect rate, leakage, size deviation...... Mức chuẩn đặt là bao nhiêu, mục tiêu là bao nhiêu, trong từng dự án, đơn vị là bao nhiêu? Những số liệu gốc được lấy từ SPD: Software Process Database. Nói chung người ngoài nhìn vào chắc hoa mắt, tin ngay vào độ “trưởng thành” của Fsoft.
Quy chế thi CMM rất khoai. Kiểu “nồi da nấu thịt”. Chúng bắt ta tự chọn ra một đội đánh giá. Bọn chúng huấn luyện rồi bắt đội này đi đánh giá các dự án. Chuyên gia chỉ giám sát quá trình đó. Nên anh em ta vừa phải học quy chế mới, vừa phải nghiêm khắc, vừa phải tìm cách để thuyết phục chuyên gia là Fsoft xứng đáng.
Ngoài việc bắt anh em làm việc như điên, Hùng còn ra sức lấy lòng ông huấn luyện viên, kể cả bắt anh em ăn đồ Ấn, lạ thế. Học giỏi, thầy yêu nên Hùng yên tâm lắm. Ai dè, đến ngày đánh giá, anh em ra sân bay đón hoảng hốt cấp báo: đội bạn đã thay người. Thầy mới là một lão mặt khó đăm đăm, rủ đi ăn không đi. Làm sao bây giờ. Anh em hoảng. Hùng cũng hoảng.
Đến ngày thi, Hùng dặn tất cả anh chị em, bất cứ khi nào bị hỏi bí thì cứ xin đi toalet. Còn ông ấy đích thân chui vào WC mang theo cả một cái máy in để nếu cần thì in và ký lại bằng chứng “fake” luôn. Tất nhiên là thầy hỏi thi cũng đi đái nên bắt được. Mới mách tôi là sponsor của dự án. Tôi ú ớ, tình gian lý ngay, ai cấm mang máy in vào WC chứ:-) Đùa thôi, chứ lúc đó lo gần chết. Máy in cũng bị thu nốt.
Thế mà kỳ lạ thay, Fsoft vẫn đạt chứng chỉ CMM level 4 ngay lần thi đầu tiên ấy, lọt vào top 120 công ty trên thế giới có CMM level 4. Cưa khách dễ thở hơn, có cái để khoe. Anh em làm dự án cũng nghiêm túc hơn, có chuẩn mà theo.
Nhớ lúc đó tôi có hỏi lại cậu chấm thi. Cậu ấy bảo: tao thấy phòng của mày sáng sủa, cửa lúc nào cũng mở, quân của mày chân thành nỗ lực, không giống với bọn định âm mưu lừa đảo khách hàng. Tao tin là chúng mày thực tâm muốn tiến bộ, chứ không phải thi cho xong, vì thế tao hiểu nỗi lo lắng của thằng Hùng Râu!
Năm 2002, chiến dịch CMM4 thành công đã đặt Fsoft vào danh sách top 120 công ty toàn cầu có CMM4 và 5.
Thừa thắng trong ME 2005, Hùng Râu quyết định phải thi chứng chỉ an toàn thông tin là BS7799, lúc đó đang rất cần để đấu thầu cho các dự án ở UK. Do đã rất tự tin, lần này Hùng giao việc cho một anh khác, cũng tên là Hùng, vốn học tiến sĩ về sinh học ở Nhật, chẳng liên quan gì đến phần mềm và quy trình. Kỳ lạ thay, anh này cũng nhận. Và 6 tháng sau hoàn thành nhiệm vụ.
Việc học hỏi và thi đạt các chứng chỉ tiêu chuẩn quốc tế là một bước tiến dài của Fsoft trên con đường tuân thủ chuẩn mực của ngành, đi ra thế giới.
Câu chuyện thứ 4: Lạt mềm buộc chặt
Chưa đánh được người thì mặt đỏ như vang. Đánh được rồi thì mặt vàng như nghệ. Các công ty thường rất háo hức dồn lực để đạt được chứng chỉ. Chụp ảnh, khoe khắp nơi. Nhưng làm thế nào để duy trì được thói quen lập kế hoạch trên số liệu, lại là chuyện rất khó.
Theo quy định của CMM, có 1 số tổ chức như
SEPG (Software Engineering Process Group) chịu trách nhiệm đưa ra các đề xuất cải tiến quy trình
TMG (Technology Management Group), nghiên cứu và phổ cập công nghệ
Và QA (Quality Assurance)
Vấn đề là không ai biết làm QA là làm gì cả. Ngay cả thế nào là chất lượng phần mềm cũng không có định nghĩa rõ ràng. Thời ở FSS, chúng tôi code mà không có ai test. Hay chính xác là ai code người đó tự test. Ah, mà có lúc Tú Huyền (lập trình viên nữ hiếm hoi), thách tôi tìm ra lỗi trong chương trình của em. Mỗi lỗi 5000 đồng.
Tháng 8 năm 2001, khi cùng với Việt Anh sang thăm ProDX ở Portland, việc đầu tiên tôi hỏi là QA là làm gì. Và được giới thiệu một cao thủ lập trình. Anh này có thể review code của các thành viên khác để tìm ra lỗi. Úi giời, chúng tôi mà có hàng ngon thế này, chắc đã cho ra trận từ lâu rồi.
Trưởng phòng QA đầu tiên Hoàng Việt Anh, bị điều ra trận. Phan Văn Hưng thay thế. Chán, xin nghỉ nốt.
Ai sẽ nhận?
Việc khó, mà hóa ra lại không khó.
Thời trước xuất khẩu, năm 1997, anh em cũng đã mổ bò suốt ngày vì không hiểu tại sao không lớn được. (Chưa nhận thức được là vì thị trường quá nhỏ). Một trong những lý do được nhận định là quản lý dự án không hiệu quả. Thậm chí còn ban hành hẳn một nghị quyết để biến tất cả các hoạt động của đơn vị thành dự án và đặt vào trong khung quản lý. Về cơ bản là miêu tả được sản phẩm cuối cùng, các nguồn nhân lực vật lực cần thiết, tiến độ thực hiện,... và quan trọng hơn cả là có thể bảo vệ được trước một hội đồng khách quan.
Khúc Trung Kiên đã đưa ra một sáng kiến là dự án nào cũng phải có một thư ký. Ghi biên bản các cuộc họp và nhắc nhở công việc và tiến độ. Hai thiếu nữ xinh đẹp được tuyển cho nhiệm vụ này là Dương Vân Anh và Nguyễn Thị Thu Hà.
Hà viết lại trong sử ký của mình thế này:
“Là một cô sinh viên vừa tốt nghiệp ra trường, tôi gia nhập FPT vào ngày 3 tháng 9 năm 1998, đúng 10 ngày trước ngày sinh nhật 10 năm FPT với vị trí là thực tập/học việc ở Tổ Thư Ký của Ban TGĐ. được gần 2 tháng thì anh KienKT rủ tôi chuyển về FSS làm thư ký cho Dự án VAT. Nghe nói đó là cái job chưa có tiền lệ. Trong suốt hơn 1 năm từ thời điểm đó, tôi đã được anh KienKT và các anh/chị trong đội dự án dạy bảo bao điều: từ những điều vô cùng nhỏ như format văn bản, sử dụng word, đến tác phong làm việc, quản lý công việc, làm việc nhóm, vân vân và mây mây.
Bỗng nhiên một ngày đẹp trời vào cuối năm 1999, chị Tú Huyền bảo tôi đi họp cùng vụ ISO của công ty, mà nào tôi có biết ISO là gì. Tham gia họp thì tôi hiểu là công ty sẽ xây dựng hệ thống chất lượng theo tiêu chuẩn ISO với slogan rất quyết tâm “ISO hay là chết”, và tất cả các trung tâm/bộ phận đều phải tham gia, mỗi bộ phận phải có 1 người đại diện làm ISOman , ở FSS thì chị Tú Huyền được chỉ định làm ISO man, vì vậy mặc nhiên chị lôi tôi cùng tham gia vào tất cả công việc của ISO man của Phần mềm.”
Khi FSU1 tách ra khỏi FSS, có lẽ Phan Văn Hưng đã rủ em Hà sang phòng quản lý chất lượng, mục tiêu có thể là không trong sáng lắm. Em lúc đó là hoa thơm, các anh làm bướm lượn xung quanh. Rất tiếc là “cự ly” không bằng “cường độ”, em đã xiêu lòng trước một anh bên ngoài ngày nào cũng mang đến một bông hoa hồng. Khi HungPV nghỉ. Cờ đến tay Hà, một sinh viên công nghệ sinh học của Đại học tổng hợp Hà Nội.
Cuối năm 2000, Phan Văn Hòa, lúc đó là giám đốc công ty 24MB, vì lý do cá nhân phải từ bỏ sự nghiệp startup, anh có gọi tôi và bảo, có chị Hoàng A Na, cứng tuổi (Ana bằng tuổi tôi) nhưng rất chỉn chu và nắm được kỹ thuật.
Thế là Thu Hà, A Na trở thành cặp “song sát”, bảo đảm việc thực thi các quy trình của CMM tại Fsoft. Một là SQA = Software Quality Assurance, trực tiếp đo các thông số của dự án, tiến hành final inspection và postmorterm
hai là PQA = Process Quality Assurance, đo sự tuân thủ của các thành viên của dự án, so với quy trình, tính toán các chuẩn (norm), và đề xuất cải tiến.
Do Hai Bà chỉ đạo, nên team QA toàn nữ, dịu dàng, nhưng không hề dễ dãi. Hình như có mỗi một em giai là DucHA, em này bị các chị “ám” nên hình như 40 tuổi mới lấy được vợ.
Về bản chất, công việc của các QA là đặt các PM (project manager) vào trong khuôn khổ, không mù quáng chạy theo ham muốn cá nhân, hoặc đe dọa tiến độ của khách hàng, hoặc sức ép cắt cost đòi tiền của giám đốc. Nên giữa họ hình thành một mối quan hệ rất đặc biệt.
Có thể tham khảo bức thư của QA tường trình cho Ban giám đốc để hiểu rõ mối quan hệ này:
Kính gửi anh Nam,
Có lẽ hôm qua em không nói được nhiều và anh cũng chưa hiểu hết được suy nghĩ của cá nhân em cũng như người đứng vai trò là một QA.
“QA hàng ngày thu thập và đo đạc hàng loạt những con số mà chẳng để làm gì v.v...”
Việc này hoàn toàn chưa đúng đối với em. Nếu đến tận bây giờ em không hiểu việc này thì đúng là em thực rất có vấn đề. Em làm việc hàng ngày để đi kiểm tra các dự án, Thuyết phục có, dở luật ra nếu anh vi phạm thì sẽ bị phạt NC,…
Nhưng trong quá trình thuyết phục là chủ yếu. Nếu em không hiểu các con số các metrics dùng để làm gì nó có ý nghĩa như thế nào đối với dự án, đối với Fsoft. Thì làm sao em tồn tại được đến tận bây giờ. Việc này hoàn toàn có thể kiểm chứng với tất cả cac PM và với tất cả những QA mà em đã từng làm việc cùng.
Vấn đề của em cũng chỉ là vấn đề rất nhỏ trong số vô vàn vấn đề mà anh phải giải quyết em cũng biết điều này nên hầu hết tất cả mọi vấn đề em đều tự tìm hiểu giải quyết tự improve mình trong suốt thời gian làm việc của Fsoft.
...
Em luôn mong anh cũng như Fsoft luôn có những đội ngũ nhân viên tốt toàn tâm toàn ý. Có được thêm nhiều khách hàng lớn. Fsoft luôn là công ty có uy tín hàng đầu và phát triển vững mạnh trong tương lai.
Em rất cám ơn anh về tất cả,
________________________________________
Kính gửi cả nhà,
Trước khi nói đến viêc của QA tôi cung xin trình bày y kiến của tôi về G những năm tháng gần đây. Môi người đều có việc của mình và co những bận rộn riêng và cũng chỉ có ngần ấy effort không thể đòi hỏi them được. Nhưng tôi đã thấy được một số nhóm không được quan tâm. Cai quan tâm mà tôi muốn nhắc đến ở đây cũng chính là sự kiểm soát chặt chẽ (chứ không phải là giao việc là tin và không tracking gì. Tôi đồng ý với Binh về điểm này vì thực tê số người có thể hoàn dealing được hết mọi vấn đề rất it. Nên co sự hỗ trợ lẫn nhau). Đối với tôi một phần của sự quan tâm cũng chính là việc tracking của cấp trên đối với công việc mà mình được giao. Chứ không phải do cấp trên không tin nên mới phải tracking.
Có lẽ vấn đề cốt lõi ở đây là thiếu người. và mô hình làm việc chưa được hợp lý. Vậy ta cần thêm người như thế nào, Hay thay đổi mô hình theo cách nào? Tôi rất hy vọng mọi viẹc được plan phân công rõ ràng và co sự phân công planning và tracking actual chặt chẽ.
Về công việc của QA đã được đánh giá là không hiệu quả trong thời gian 6 tháng đầu năm 2007. Lý do là nhiều PM không muốn làm việc với QA.
Câu hỏi đặt ra là tại sao PM lại không muốn làm việc với QA?
- QA hay yeu cầu PM làm này lam nọ mà họ không muốn làm: Viết SRS, DD, viêt phân tích lỗi, họp, viết meting minute, review/log timeheets/defects chặt chẽ, làm báo cáo, chua kể phải làm thủ tục review/base line…..nhìn thấy mặt QA là thấy nợ việc.
- QA review/test sản phẩm bắt lỗi chặt lại hay báo cáo lên cấp trên: Toàn lỗi nhỏ, Chẳng qua quên một tí, nhầm một tí lỗi này chấp nhận được. Mọi người có thể kiểm chứng việc QA tìm ra lỗi có đúng hay không va nhiều hay it qua DMS. Và liệu khách hang khi xem/test sản phẩm thấy những lỗi như vậy họ sẽ nghĩ gì về mình – CMMI level 5 và liệu các khach hang làm xong dự án này họ có còn nghĩ đén FSOFT nũa không co tiếp tục làm nũa không? Nếu họ tham khảo các khách hàng đã từng làm với mình liệu mình có được reference tôt không?
- Có nhưng PM lại nghĩ rằng lam với QA chỉ là thủ tục để làm đẹp con số không giúp cho dự án gì cả, QA toan làm phiền dự an, không biêt những con số, hồ sơ dự án kia để lam gì? Viết hồ sơ dự án để làm gi` nhớ trong đầu họ là được. Lam mất thời gian mệt người tốn effort ?
- Có những người cũng đơn giản nghĩ ràng viết phân tích yêu cầu làm gì, Deising làm gì, Unit test làm gì, Code review làm gì chỉ cần cuối cùng chương trình chạy được là khách hang OK là được.
- Đúng là chỉ làm để hình thức đẹp và cho đủ thủ tục thì đó là lãng phí. Họ không nhìn thấy được lợi ich lâu dài
- Họ dâu có nghĩ khách hàng lai mong muón khác mà vài trang yêu cầu chưa viết sâu và đủ hoặc buổi nói chuyện với khách hang và thỏa thuân họ nhớ trong đầu là đủ.
- Họ đâu co tưởng tượng được rằng nếu có Design tôt code structure tốt thì làm sao có thể đáp ứng được nhưng CRs thay đổi nho nhỏ mà khách hang yêu cầu sẽ không có nhiều isues đến thế.
- Họ đâu có nghĩ rằng đến khi khách hang mở code ra và rejects nhưng dự án mà mình đang tiếp tục làm với họ.
- QA đã từng cảnh báo dự án về việc này chua? (Nếu bạn cần tôi xin nêu ví dụ cụ thể)
- Tất cả nhũng trường hợp trên G đều dã gặp phải. Vậy con đường phía trước ta se tiếp tục đi như thế nào để tránh được vết xe đổ? Và phát triển mạnh trong tương lai?
- Vậy ai là người trách nhiêm của ai để làm những việc trên? Chính là đường lối của ban giám đốc. Hãy chỉ ra cho PM, Dev, Test va QA biết trách nhiệm và nhiệm vụ của họ là gi`. Những việc tưởng chừng chỉ là thủ tục, nhỏ nhặt ai cũng coi thường không ai chiu làm cả, chúng ta toàn những người làm việc lớn, giống như xây một tòa nhà chỉ cần những viên gạch to và tốt không cần phải có những mạch vữa kết nối tòa nhà đó se là tiết kiệm và bền vững??
Lật đi cũng phải lật lại vấn đề:
- QA đã can thiệp quá sâu vào dự án?
- Làm việc chồng chéo, làm cả phần việc của người khác
- Cách làm việc của QA đã khiến cho PM, Tester thấy mình đang bị soi, bị trì trích??
- QA không biết gì về dự án và công viêc của họ cả (họ đang tối mặt tối mũi với code thì lại phải làm nhưng việc nay)???
- Cũng có thể QA động chạm đến quyền lợi của họ (không co QA họ không phải làm những viec vặt vớ vản đó)
…
QA cũng là con người cũng có sai sót chứ không phải 100% hoàn hảo. Hãy thử xem lại xem QA đã đưựoc hướng dãn làm gì? Và những sai sot tren tổng số kết quả họ đã làm đựoc tỉ lệ là bao nhiêu. (tôi tin là không quá 5%) Còn nếu có sai sót hay phàn nàn chỗ nào thì yêu cầu dẫn chứng cụ thể và hãy xem tường tận, toàn cảnh. QA cung sẽ phải xem xét và tự nâng cao và thay đổi bản thân.
Có lẽ đây cũng chỉ là suy nghĩ phiến diện từ cá nhân tôi. Xin nhường lời nhận xét công lao của QA đã đóng góp hao tổn có lãng phí hay đem lại lợi ich gì không cho tất cả mọi người.
Khi đứng ở một vị trí, một thời điểm, thời gian nào đó thí người nhìn sẽ có cái nhìn và suy nghĩ khac nhau nên rất mong sự giúp đỡ cung như nhân xét thật lòng từ phía mọi người.
Cũng có thể tôi cũng sẽ thay đổi trong tương lai. Nhưng tôi nghĩ tôi sẽ sống theo cách của tôi đã làm gì thì làm hết mình không bao giờ phải hổ thẹn với lương tâm.
Chúc cả nhà luôn vui vẻ,
Câu chuyện thứ 5: Fsoft Insight
Ngoài quy trình và con người, một yếu tố quan trọng sống còn cho việc bảo đảm công ty vận hành là các công cụ giám sát hệ thống.
Ngày 8/4/2008 Vũ Đăng Khoa thông báo, G8 đã chuyển đổi thành công FI sang mô hình SaaS và được Daiwa Bussiness Innovator chính thức cung cấp trên website của mình
“DBI has announced formally about Project DashBoard (base on our FsoftInsight) as their new business solution on home page”
Lời đề nghị của DIR về việc chia sẻ kinh doanh FI nhưSaaS ngay lần đầu gặp mặt, cứ tưởng là đùa nay đã thành sự thật.
Fsoft Insight là một phần mềm lưu trữ và phân tích tất cả các thông số về dự án của Fsoft, giúp cho các lãnh đạo có thể giám sát qua hệ thống dashboard, các PM có thể dùng để lập kế hoạch và theo dõi dự án, SEPG có thể đưa ra các đề xuất thay đổi quy trình.
Có thể nói lịch sử FsoftInsight (FI), ở một chừng mực nào đó chính là lịch sử của Fsoft
Từ khi tôi và DatPP copy được bản spec đầu tiên của một chương trình quản lý dự án của Tata Consulting, có tên gọi là IPMS (Integrated Project Management System)
Sau đó Hoàng Việt Anh, Phan Văn Hưng và Trần Đức Nghĩa kỳ cục tìm cách biến cái spec đó thành hiện thực với tên gọi Spacy (aka Software Process AccuracCY)
Rồi a Hùng Râu về cặm cụi thiết kế PCB trên Excell. Fsoft chính thức làm CMM
TuấnPM lần đầu tiên trình làng Dashboard
Martin Geiger đặt lại tên là Fsoft Insight, thay cho cái tên Spacy chẳng có ý nghĩa gì
Manu, DinhDQ, HaNT và bao nhiêu thế hệ lập trình viên và QA khác đã đổ mồ hôi nước mắt cho FI
Ngày đầu sang Nhật, cùng TungBH và HuongNTL, FI là “vũ khí duy nhất” để đi gặp một chú khách hàng bé tí ở Tokyo. Nghe xong, chú bảo: tao không có việc để thuê mày, nhưng mày có bán cái phần mềm dashboard này không? Chúng tôi không bán vì chỉ có mỗi bản demo
Rồi FI cũng sống được và trở thành công cụ marketing hữu hiệu nhất cho Fsoft. Bất cứ một cuộc tiếp khách nào cũng được bắt đầu bằng màn trình diễn FI và Dashboard
Cũng đến ngày FI trở nên xơ cứng, cần có một làn gió mới, cả hội lại xúm vào bàn làm thế nào, mãi không có đường ra? Năm 2010, sau chuyến đi thăm Infosys và hiểu rõ hơn về cấu trúc chi phí, Fsoft mới dám mạnh dạn đầu tư vào những công cụ quản trị hiện đại như Jira
FI chỉ còn là công cụ có tác dụng nội bộ. Nhưng đã có một chỗ đứng vững chắc trong lịch sử phát triển của Fsoft.
Câu chuyện thứ 6: Thế nào là chất lượng!
Cách đây tầm 3 năm, nhà tôi có tin vui. Hai vợ chồng được lên chức ông bà ngoại. Khỏi nói là bà ngoại mừng thế nào. Bà chỉ đạo ngay: anh quyền cao chức trọng, nhiều mối quan hệ, xin cho em một số điện thoại theo số ngày sinh của cháu. Cả buổi sáng hôm đó tôi đau đầu. Quen từ lâu, mà cũng là quan hệ công việc, thân thiết gì đâu, giờ nhờ thế nào:-) Bí, bèn lên mạng tra. Hóa ra có ngay một website rao bán 2 số điện thoại tôi cần, của Viettel 1.1m, của Vina 400k. Tất nhiên là tôi chọn Vina:-) Có một bạn gọi lại ngay, bảo nhờ anh nhắn hộ tên và số CMTND của chính chủ để em kích hoạt. Nhắn xong, bạn ấy nhắn lại độ 2 tiếng nữa em sẽ giao hàng.
Đúng hẹn, bạn ấy mang đến tận cửa phòng họp, “Em đã kích hoạt rồi, anh dùng cỡ sim nào? em gọi thử ngay cho anh nhé. Ok rồi. Anh lắp cho chị, có gì trục trặc gọi em”. Nhận tiền xong, bạn ấy nán lại một chút. “Có lẽ anh không biết em. Em đã từng làm Fsoft một thời gian. Rất cám ơn anh và Fsoft đã dạy cho em nhiều điều. Trong đó có một điều em vẫn áp dụng trong công việc hiện tại của mình. Chất lượng chính là sự đáp ứng đúng yêu cầu của khách hàng, chứ không phải những lời hoa mỹ, hay mỉm cười, cúi cuđầu.”
Tôi xúc động. Vì đó cũng chính là điều chúng tôi đã học được trong những ngày đầu vất vả của Fsoft. Trước đó chúng tôi, những chuyên gia, tranh cãi loạn xạ về các tiêu chuẩn chất lượng phần mềm do mình tự đặt ra: nào là zero-defect, nào là fancy user experience, richness of functions, high performance, prudent reability…. Cho đến khi chuyên gia Ấn Độ sang xổ toẹt: “Quality is matching customer requirements, both explicit and implicit - Chất lượng là đáp ứng đúng những yêu cầu nói ra và không nói ra của khách hàng!”
Cám ơn em vì những điều em làm cho tôi như một khách hàng, đúng là điều tôi cần, đúng là chất lượng tuyệt hảo.
Bình luận
Bài viết của Phan Phuong Dat
16/3 là FSOFT Process Day. Đúng ngày 16/3/2002, FSOFT nhận chứng chỉ CMM (Mô hình trưởng thành về năng lực thực hiện các dự án phần mềm) đầu tiên, và đến nay đã có rất nhiều chứng chỉ quy trình chất lượng khác nhau. Có dạo ngày này được đổi thành Quality Day, nhưng cá nhân tôi vẫn thích cái tên Process Day hơn, vì một đằng là nói về kết quả, một đằng về cách thức hành động để có kết quả đó (tuy k0 phải là duy nhất). Thường thì người ta đều muốn một thứ, nhưng khác nhau về cách thức có nó. Đó là khác nhau giữa “nói không với tai nạn” và “nói không với hành vi uống rượu khi lái xe”. Chẳng ai “nói có” với tai nạn cả, và nhiều khi những người uống rượu lái xe và không gây tai nạn cảm thấy mình không có lỗi gì, thậm chí còn tự thấy mình giỏi và được bạn bè ngưỡng mộ! Việc có một process và tuân thủ nó giúp ngăn chặn lỗi xảy ra, là kết quả mà chúng ta không dễ thấy (khác với xử lý lỗi, rất dễ thấy và dễ được tôn vinh).
Process là luật chơi, hạn chế sự “tự do”, cho nên dễ bị ghét. Nó cũng dễ bị lợi dụng để đổ lỗi và trở thành tội đồ, khiến nhiều người lầm tưởng rằng không có nó thì tốt hơn. Ai cũng cho rằng trường hợp của mình là đặc biệt, mình phải được đi tắt. Đôi khi, bỏ qua process và thành công, người ta cho rằng mình giỏi và không cần đến nó nữa. Sự thực thì process là một công cụ mạnh và hoàn toàn do con người xây dựng nên và liên tục cải tiến, là tri thức quản lý được mã hóa. Ở FSOFT, tôi đã đứng lớp rất nhiều buổi học môn “Intro to CMM/CMMI” và luôn hỏi học viên rằng, trong định nghĩa về software process (ảnh), cụm từ nào là quan trọng nhất? Rất ít bạn trả lời được đúng, rằng quan trọng nhất là hai từ “people use”.
Chúc mừng các bạn QA FSOFT và tất cả những người làm quy trình nhân ngày này! Chúc các bạn vững tin vào công việc của mình!
Vấn đề thảo luận:
Fsoft đã có CMM như một framework để xây dựng nên đế chế của mình. Liệu có con đường nào khác?
Nguồn tác giả: facebook Nguyễn Thành Nam - Former ceo FPT
Nhận xét