Trao đổi về qui trình, mô hình phát triển và chất lương sản phẩm

Hoàng Xuân Thịnh, 07/10/2005

1. Tiếp cận vấn đề bằng phương pháp 6W

Tôi bắt đầu bài viết của mình từ một nhận xét mà bằng cảm nhận cá nhân, mọi người đều có thể thấy được, đó là: người ta chỉ có thể làm tốt một cái gì đó nếu người ta có thể suy nghĩ về nó và suy nghĩ về nó từ nhiều góc độ. Con người có kiểu làm việc riêng của mình là những gì họ làm chẳng qua chỉ là sự hiện thực hoá của những gì họ nghĩ, cái hiện thực họ tạo ra chính là biểu hiện vật chất của các giá trị tinh thần của họ. Các giá trị tinh thần là kết quả của những quá trình tư duy, suy ngẫm. Người ta đã nghiên cứu cách điều khiển các quá trình tư duy và đúc kết lại thành phương pháp luận. Hiện có nhiều phương pháp tư duy, nếu bạn nào quan tâm đến vấn đề này thì có thể truy nhập các trang Web về Phương pháp luận sáng tạo. Ở đây tôi muốn giới thiệu một phương pháp tư duy mà tôi học được khi đọc một cuốn sách kinh tế của người Nhật. Tôi không nhớ đó là cuốn sách nào vì tôi đã đọc nó cách đây chừng 9, 10 năm gì đó, chỉ nhớ láng máng hình như đó là một cuốn sách do ông chủ hãng Honda viết. Phương pháp đó gọi là phương pháp vét cạn thông tin 6W (chắc nhiều bạn đã biết), đây là một phương pháp đặt câu hỏi về việc ta cần giải quyết, nó khá dễ dàng và rất dễ nhớ, dễ vận dụng (chính vì vậy mà tôi giới thiệu nó).

Phương pháp đặt câu hỏi này giúp ta khi đứng trước nhiệm vụ phải giải quyết một công việc gì đó có thể nhìn công việc dưới nhiều góc nhìn khác nhau nhằm bao quát toàn bộ thông tin về công việc. Giả sử ta phải giải quyết công việc A, vậy ta phải đặt các câu hỏi sau.

Phương pháp 6W

1. Để giải quyết công việc ta phải làm những gì? (What)
Câu hỏi này giúp ta phân nhỏ A thành nhiều công việc nhỏ rõ ràng, rành mạch, cụ thể. Ví dụ: để giải quyết công việc A ta chia A thành A1, A2, A3. Nếu trả lời tiếp câu hỏi “Các A1, A2, A3 có liên quan đến nhau như thế nào?” thì ta sẽ hình thành được luồng công việc (Workflow) - một khái niệm đặc biệt quan trọng khi nghiên cứu về nghiệp vụ của một tổ chức.

2. Thực hiện các việc như thế nào? (How)
Ta thiết kế các bước thực hiện các A1, A2, A3. Để thực hiện A1 thì:

B1. Làm việc 1.
B2. Làm việc 2.
…
Bn. Làm việc n và kết quả là ta thu được A1.

Cứ thế lần lượt các A2, A3.
Ngoài ra ta cũng có thể đặt các câu hỏi về chi phí cho công việc này (How much) ra sao. Dựa vào đây ta thu được cái nhìn bao quát về chi phí cho công việc.
Liên quan đến câu hỏi này là các vấn đề về:

• Công cụ thực hiện công viêc.
• Thông tin, chỉ dẫn để thực hiện công việc.

3. Thực hiện các việc vào lúc nào? (When)
Chỉ ra thời điểm thực hiện từng A1, A2, A3. Chỉ ra thời hạn thực hiện mỗi công việc. Dựa vào đây ta lập được kế hoạch (về thời gian) công việc.

4. Ai thực hiện các việc? (Who)
Đây là câu hỏi quan trọng vì nó liên quan đến mọi khía cạnh nhân sự của công việc, trong câu hỏi này ta phải chỉ ra ai thực hiện công việc, ai là người chịu trách nhiệm chính, ai là người thực thi, ai là người quản lý. Tất cả những người trên đòi hỏi phải có kỹ năng gì, kiến thức gì, thông tin gì để hoàn thành công việc. Phần này giúp ta tách bạch giữa công việc và con người thực hiện công việc.

5. Thực hiện công việc ở đâu? (Where)
Phải chỉ ra địa điểm thực hiện công việc, tất cả các thông tin liên quan đến địa điểm đều phải được làm rõ.

6. Tại sao? (Why)
Đây là câu hỏi quan trọng và có thể đặt ra cho cả 5 câu hỏi trên. Ví dụ:

Tại sao lại chia A thành A1, A2, A3? Có thể chia khác được không? Phương pháp chia như thế nào là hợp lý? Khi nào ta trả lời thuyết phục nhất cho câu hỏi tại sao này thì cách chia có thể được coi là hợp lý nhất.

• Tại sao lại thực hiện công việc theo các bước trên? Có thể khác được không?...
• Tại sao chi phí lại như thế? Khác được không?
• Tại sao lại đòi hỏi những người thực hiện công việc có các kỹ năng này? Khác được không?

Có thể đặt vô số câu hỏi tại sao, càng trả lời rõ ràng rành mạch chừng nào, càng tốt chừng ấy.

Câu trả lời cho các câu hỏi trên giúp ta bao quát thông tin về công việc cần giải quyết và giúp ta đưa ra giải pháp cho nó. Bây giờ ta sử dụng phương pháp trên để trả lời câu hỏi quy trình là gì.

2. Quy trình là gì?

Một quy trình, trước hết là một dãy các công đoạn nhằm mục đích cuối cùng là sản xuất ra một sản phẩm hoặc thực hiện một dịch vụ (sau đây gọi chung là sản xuất một sản phẩm), dãy công đoạn đó phải thoả mãn các tiêu chuẩn sau:

(1) Các công đoạn cần thực hiện là gì? (Know – What)

Công đoạn 1, công đoạn 2, công đoạn 3, … Các công đoạn này được đặt tuyến tính theo thời gian, kết quả của công đoạn trước là đầu vào cho công đoạn sau. Việc phân chia ra các công đoạn này phải do những chuyên gia về công việc đó đảm nhiệm. Nói ví dụ, chúng ta là dân IT thì không thể viết bảng phân chia công việc nhằm thực hiện rút tiền từ một tài khoản của một ngân hàng, việc này phải do chuyên gia về ngân hàng viết. Dân IT có thể viết bảng phân chia công việc cho một quy trình sản xuất một phần mềm và phải là dân IT có trình độ (các bạn cũng tự biết điều này mà!) mới viết được. Khi phân chia thì phải có một số tiêu chí nào đó giúp ta nhận biết sự phân chia đó có tối ưu hay không, nhưng tựu trung lại, sự phân chia nào thì cũng bao gồm các công đoạn sau:

Công đoạn 1: Thu thập yêu cầu

Thực hiện công việc điều tra, nghiên cứu để hình thành bản mô tả yêu cầu của khách hàng về sản phẩm tương lai. Đối tượng điều nghiên là khách hàng của sản phẩm (Đương nhiên rồi!) và nhà sản xuất ra sản phẩm (Xin chú ý chi tiết này!). Phiên bản mô tả yêu cầu đầu tiên thu được là một mớ thông tin chưa được phân loại, còn rối rắm và trùng lặp, còn thiếu và thừa nhiều thông tin.

Công đoạn 2: Phân tích yêu cầu

Phân tích bản mô tả yêu cầu để hình thành lên “hình ảnh” của sản phẩm tương lai. Khái niệm phân tích ở đây giống như khái niệm phân tích được dùng trong hoá học vậy. Bạn để ý, khi nhà hoá học nói tôi phân tích nước nghĩa là ông ta đã thu được ít nhất 2 thành phần cơ bản cấu tạo lên nước là oxy và hydro. Cũng vậy, phân tích yêu cầu là phải tìm ra các thành phần cơ bản cấu tạo lên sản phẩm tương lai, sau đó “gộp” các thành phần cơ bản này để tạo thành sản phẩm, khi “gộp” lại như vậy bạn sẽ thấy nhiều thông tin thừa cần bị loại bỏ và nhiều thông tin thiếu cần phải bổ sung để các thành phần cơ bản có thể phối hợp cùng nhau (“lắp ráp” lại được với nhau) nhằm tạo lên sản phẩm. Ví dụ, phân tích bản mô tả yêu cầu về một phần mềm thì phải thu được các nhóm nghiệp vụ mà phần mềm ấy phải cung cấp cho tổ chức đặt hàng. “Gộp” các nhóm yêu cầu lại thì thu được phần mềm cần thiết dưới hình thức các nghiệp vụ.

Công đoạn 3: Thiết kế

Ta hiểu thiết kế chính là dùng các ngôn ngữ hình thức (các biểu tượng, các ký hiệu, …) để biểu đạt một ý nào đó. Dùng ngôn ngữ hình thức là vì nó khiến người ta không thể hiểu nhầm, không thể ý thế này mà hiểu thế kia, nghĩa là nó không đa nghĩa, hơn nữa nó còn giúp người ta biểu đạt đến tận những tiểu tiết mà ngôn ngữ tự nhiên không biểu đạt được. Bạn đã xem bản vẽ kỹ thuật (cơ khí) chưa? Làm cách nào để bạn có thể dùng ngôn ngữ tự nhiên mà mô tả cái bánh răng và đưa bản mô tả này cho người thợ tiện để anh ta tiện đúng cái bánh răng cho bạn. Vì vậy, quá trình thiết kế chẳng qua chỉ là việc biến cái nội dung được biểu đạt dưới dạng ngôn ngữ tự nhiên thành cái nội dung được biểu đạt dưới dạng ngôn ngữ hình thức.

Công đoạn 4: Sản xuất

Sản xuất thì ai cũng hiểu rồi, cứ theo bản thiết kế (và bản kế hoạch công việc để biết cái gì làm trước, cái gì làm sau) mà làm ra sản phẩm thôi. Trong phần mềm thì sản xuất là lập trình.

Công đoạn 5: Kiểm tra, thử nghiệm sản phẩm

Thực hiện việc kiểm soát chất lượng sản phẩm. Nếu sản phẩm qua được công đoạn này thì chuyển công đoạn tiếp, không thì quay ngược lại.

Công đoạn 6: Bán hàng

Công đoạn 7: Các dịch vụ hậu bán hàng

Lấy ý kiến khách hàng về sản phẩm, chăm sóc khách hàng…

(2) Mỗi công đoạn được thực hiện như thế nào? (Know – How)

Trong phần này, ta thiết kế các bước thực hiện mỗi công đoạn (có thể coi là thuật toán xử lý mỗi công đoạn). Ở đây ta sẽ phải thiết kế các thủ tục, hướng dẫn công việc, biểu mẫu để hướng dẫn và ghi nhận lại tiến trình xử lý… Các công cụ sử dụng phải được chỉ rõ và thống nhất.

3. Ai thực hiện các công đoạn ấy? (Know – Who)

Đây là nơi đối chiếu công đoạn 1 và 2 với nhân sự hiện tại để tìm những người thích hợp thực hiện công việc. Mỗi công đoạn có thể nhiều người thực hiện. Nhưng thế nào là người thích hợp?

• Phải có người chịu trách nhiệm chính cho mỗi công đoạn. Trong công đoạn 1, lý tưởng nhất là người có chuyên môn về lĩnh vực ấy đảm nhiệm chính (Phần mềm kế toán thì tốt nhất là để các kế toán viên có kinh nghiệm đảm nhiệm việc này). Những người này ngoài nghiệp vụ thì phải có kỹ năng điều nghiên thị trường. Thực tế không phải công ty phần mềm nào cũng có nhân sự thích hợp cho công đoạn này, vì vậy hãy chọn người có kinh nghiệm về giao tiếp thực hiện việc này.
  
• Kỹ năng làm việc (gồm tri thức và kinh nghiệm), trách nhiệm, kết quả công việc, nhật ký công việc của mỗi người phải được chỉ rõ.
  

Các quy định trên giúp ta phân tách người thực hiện công việc với công việc những biến động về nhân sự không ảnh hưởng lớn đến công việc, để doanh nghiệp bớt sự bị động về nhân sự, để chuyên nghiệp hoá hoạt động của doanh nghiệp.

(4) Khi nào thì thực hiện mỗi công việc? (Know – When)

Căn cứ bảng cấu trúc phân việc (WBS=Work Breakdown Structure) ta có được lịch của dãy công việc.

(5) Thực hiện mỗi công việc ở đâu? (Know – Where) Địa điểm thực hiện công việc.

Sau khi đã trả lời các câu hỏi trên, ta hãy kiểm duyệt lại một vài lần quy trình ta soạn thảo bằng các câu hỏi tại sao. Làm như vậy cho đến khi ta cảm thẩy mọi câu hỏi tại sao đều có thể được giải đáp hợp tình, hợp lý thì dừng lại.

3. Chất lượng là gì? Hệ thống quản lý chất lượng là gì?

(1) Chất lượng là gì?

Chất lượng được định nghĩa như sau: chất lượng là sự phù hợp của các đặc tính của sản phẩm với các yêu cầu. Vậy các yêu cầu đó là gì?

• Nhóm yêu cầu thứ nhất, là các yêu cầu của khách hàng đối với sản phẩm, các yêu cầu này khiến cho họ khi sử dụng sản phẩm cảm thấy thoả mãn.
• Nhóm yêu cầu thứ hai, là các yêu cầu của nhà sản xuất đối với sản phẩm, ví dụ là các yêu cầu sao cho chu kỳ sản xuất sản phẩm phải ngắn, dễ dàng cho việc bảo trì sau này, chi phí sản xuất và bảo trì phải thấp. Xét một công ty phần mềm, khi công ty bán phần mềm cho khách hàng ở rất xa công ty thì việc bảo trì có thể thường xuyên phải thông qua điện thoại, qua email… nên việc định vị lỗi, định vị cửa sổ, định vị báo biểu xảy ra lỗi là rất quan trọng, vì vậy việc đánh mã các cửa sổ (form), đánh mã các báo biểu là cần thiết để nhận dạng ngay ra lỗi…

Tập hợp tất cả các yêu cầu trên tạo ra yêu cầu của sản phẩm và sản phẩm có các đặc tính đáp ứng tập hợp yêu cầu này thì gọi là sản phẩm có chất lượng.

(2) Các loại chất lượng

Có 2 loại chất lượng cần đạt được của sản phẩm:

• Chất lượng thiết kế: căn cứ bản phân tích do công đoạn 1 thực hiện, các kỹ sư thiết kế biến thành bản thiết kế hệ thống. Tương ứng có chất lượng thiết kế. Căn cứ trên các yêu cầu (của khách hàng và của nhà sản xuất) để kiểm tra bản thiết kế có đáp ứng các yêu cầu ấy hay không, nếu đáp ứng thì gọi là đạt chất lượng thiết kế.
  
• Chất lượng quá trình: đó là sự phù hợp của hệ thống thực tế (sản phẩm) với bản thiết kế, sự phù hợp đó gọi là chất lượng quá trình. Căn cứ bản kế hoạch kiểm thử được các kỹ sư thiết kế kiểm thử thực hiện, tiến hành kiểm tra hệ thống có phù hợp bản thiết kế hay không, nếu phù hợp gọi là đạt chất lượng quá trình.

(3) Hệ thống quản lý chất lượng là gì?

Để dễ nói về hệ thống quản lý chất lượng (HTQLCL) tôi xin lấy ISO làm ví dụ. Cái “thần” của ISO tập trung ở ý này: hãy viết ra những gì bạn định làm và sau đó hãy tiến hành công việc theo những gì bạn đã viết. Việc viết ra những gì bạn định làm bao gồm viết ra mục tiêu bạn muốn đạt được là gì, và cách thức tiến hành công việc để đạt đến mục tiêu đó là thế nào (What và How). Như vậy bạn phải thiết kế một hệ thống văn bản và thủ tục hướng dẫn người ta làm việc, sau đó tái cấu trúc tổ chức của bạn cho phù hợp với hệ thống văn bản này. Vậy,
một cách đơn giản, HTQLCL là hệ thống văn bản hướng dẫn và kiểm soát tổ chức đạt được điều mình muốn.
Mục đích của HTQLCL là kiểm soát được quá trình làm ra sản phẩm, bán sản phẩm, bảo trì sản phẩm. Kiểm soát nghĩa là làm minh bạch hoá toàn bộ quá trình trên, sản phẩm đã qua công đoạn nào, ai tham gia công đoạn đó, công đoạn đó diễn ra vào lúc nào, diễn ra ở đâu. Khi có sai lỗi rất dễ quay ngược lại để tìm nguyên nhân. HTQLCL được thiết kế dựa trên 3 nguyên lý:

• HTQLCL quyết định chất lượng sản phẩm, hay nói cách khác, quá trình làm ra sản phẩm quyết định chất lượng sản phẩm. Để hình dung được nguyên lý này, bạn hãy tưởng tượng bạn phải trồng một cây bưởi từ khi nó còn là một mầm cây. Bạn tưới cây, bón phân cho cây, bảo vệ nó khỏi sự tán phá của thời tiết, của sâu bọ… cây lớn lên và ra quả, đến kỳ bạn hái quá và thưởng thức bưởi. Chính quá trình bạn chăm sóc cây quyết định độ ngon của quả bưởi, phải không bạn?
• HTQLCL chú ý phòng ngừa lỗi hơn là khắc phục lỗi. Do người thiết kế HTQLCL thường là người có kinh nghiệm nên nhiều lỗi thông thường của sản phẩm đã được biết trước và nguyên nhân của nó cũng đã rõ, vì vậy HTQLCL đã loại bỏ sai lỗi ngay từ đầu bằng cách không để xảy ra nguyên nhân gây ra sai lỗi đó.
• HTQLCL chú ý nhấn mạnh vào việc làm đúng ngay từ đầu, nghĩa là nhấn mạnh vào việc làm đúng theo các văn bản hướng dẫn ngay từ đầu. Mục đích cũng là để dễ dàng kiểm soát sai lỗi nếu có mà thôi.

Trong mục này tôi muốn nhắc đến hai khái niệm quan trọng nữa:

• Đảm bảo chất lượng (Quality assurance): là làm theo đúng hướng dẫn của HTQLCL, tức là chú ý vào quá trình.
• Kiểm soát chất lượng (Quality control): là công việc kiểm thử (testing) sản phẩm, tức là chú ý vào sản phẩm.

4. Mô hình phát triển phần mềm có ý nghĩa gì?

Trước hết ta bắt đầu từ mô hình thác nước kinh điển (xin đọc lại bài anh Trần Thanh Ngoan đã post), mô hình này có nhược điểm lớn mà ai cũng biết là các sai lỗi sau khi đã phát hiện ra rất khó sửa đổi, sửa lỗi ở khâu phân tích thì có nghĩa là phải sửa toàn bộ tài liệu và chương trình. Việc này là không khả thi trên thực tế đối với các doanh nghiệp phần mềm, vì phải chi phí quá nhiều nhân lực, thời gian và tiền bạc, và trong trường hợp doanh nghiệp chấp nhận các chi phí
đó thì cũng chưa chắc đã giải quyết được lỗi, khách hàng nào đợi được cơ chứ! Vậy vấn đề đặt ra là phải tìm những cách phát triển phần mềm khác khắc phục được lỗi cơ bản này của mô hình thác nước. Bạn hãy xem lại trong mục Chất lượng là gì, bạn sẽ thấy các mô hình ra đời sau chính là để đáp ứng nhóm yêu cầu thứ hai – nhóm yêu cầu của nhà sản xuất đối với sản phẩm. Còn nếu bạn là khách hàng thì liệu bạn có để ý đến việc nhà sản xuất dùng mô hình nào để phát triển sản phẩm không? Chắc là không! Tôi nói mô hình thác nước là kinh điển vì tất cả các mô hình sau đó chỉ là biến thể của mô hình này mà thôi, các mô hình sau này vẫn phải giải quyết từng ấy công việc của mô hình thác nước nhưng bằng cách này hay cách khác, chúng không làm phá vỡ cấu trúc của hệ thống, giúp doanh nghiệp dễ dàng bảo trì và tiếp túc phát triển chương trình, giúp doanh nghiệp kế thừa công sức của những người đi trước đã làm.

Cuối cùng tôi muốn nói vài lời về mối quan hệ giữa quy trình, mô hình, ISO và CMM. Các bạn thấy đấy mô hình là hình ảnh cụ thể của quy trình phát triển phần mềm theo một quan điểm nhất định. Còn ISO giúp quy trình thể hiện dưới dạng văn bản theo một số nguyên lý nhất định. Nhược điểm của ISO là có thể không tính đến trình độ của nguồn nhân lực của tổ chức nên có thể quy trình rất “tốt” nhưng do trình độ nhân lực của doanh nghiệp không đáp ứng yêu cầu nên sản phẩm sản xuất ra vẫn kém chất lượng. CMM giải quyết nhược điểm ấy bằng cách làm “khớp” dần giữa trình độ nhân lực và quy trình theo nguyên tắc dùng quy trình để tạo ra kỹ năng làm việc, khi kỹ năng làm việc đã nâng lên rồi thì quy trình cũ đã lạc hậu, vậy nâng cấp quy trình để tạo kỹ năng làm việc mới… cứ thế cái nọ nâng cái kia lên. Vì vậy CMM được gọi là chứng chỉ đánh giá mức độ trưởng thành của doanh nghiệp là vì thế.
__________________
Hoàng Xuân Thịnh
Trung tâm CNTT Điện lực Việt Nam (EVNIT), 16 Lê Đại Hành, Hà Nội.