Xây dựng quy trình hỗ trợ CNTT

Qua nhiều thập niên gắn bó và làm việc trong lĩnh vực công nghệ thông tin (CNTT), Robert C. Anderson – Giám đốc phụ trách việc phát triển các quy trình của Computer Aid Inc., một nhà cung cấp các giải pháp CNTT lớn, có trụ sở ở Allentown, bang Pensylvania, Mỹ – đã đúc kết được 25 quy tắc để xây dựng những quy trình hỗ trợ CNTT.

Ông hy vọng những quy tắc này sẽ giúp các nhóm hỗ trợ CNTT cải thiện năng suất làm việc và cung cấp những dịch vụ trợ giúp có hiệu quả và chất lượng cao hơn.

1. Người sử dụng sẽ nhớ những đánh giá cũng như những thời hạn mà họ nghe được. Do vậy, đừng bao giờ nói ra những gì mà bạn không muốn phụ thuộc nhiều vào chúng.

2. Những công việc không xác định được giới hạn là những công việc kéo dài bất tận. Đừng nói rằng bạn sẽ cố gắng làm một việc gì đó mà không cho biết khi nào nó sẽ được thực hiện và tại sao nó không được làm đúng thời hạn.

3. Các nhóm hỗ trợ rất dễ phạm sai lầm khi cung cấp dịch vụ cho một ứng dụng nào đó. Hãy rà soát nhiều lần tất cả những gì được đưa vào quy trình sản xuất để chắc rằng chúng đáp ứng các yêu cầu kỹ thuật.

4. Người sử dụng thường quên những chi tiết hay sự kiện quan trọng. Vì thế, bạn cần có một thỏa thuận rõ ràng với họ trên giấy trắng mực đen.

5. Không có việc gì được hoàn tất hoặc hoạt động tốt trừ phi bạn đầu tư thời gian cho việc kiểm tra chúng. Hãy bắt đầu công việc với một giả định như thế, và bạn sẽ không bao giờ ngạc nhiên trước những kết quả bất ngờ.

6. Sự từ chối không là một câu trả lời tích cực. Đừng bao giờ từ chối khi nhận được một yêu cầu. Thay vào đó, hãy nói: “Để tôi xem lại nó, và sẽ trả lời cho ông vào thứ Ba tuần tới.” Một khi có thời gian suy nghĩ về lời yêu cầu, bạn có thể tìm ra một giải pháp phù hợp.

7. Những gì không thể thẩm định được thì không thể kiểm soát được. Hãy xác định rõ những mục đích ở cấp độ dịch vụ và nắm bắt nguồn gốc những dữ liệu đo lường. Qua đó, bạn có thể so sánh những gì cần phải làm với những gì hiện có.

8. Bạn không thể có được một sự đánh giá chính xác nếu không biết rõ những số liệu và mức độ phức tạp của những chức năng được yêu cầu. Hãy phân tích kỹ những yêu cầu về chức năng, ngay cả những yêu cầu đơn giản.

9. Chủ quan khi đánh giá công việc của chính mình là một điều không tốt. Việc thẩm định chất lượng của một công việc phải do một tổ chức độc lập tiến hành.

10. Môi trường kiểm tra không là môi trường sản xuất. Nhiều ứng dụng có thể chạy tốt khi kiểm tra nhưng chưa hẳn sẽ hoạt động trong môi trường sản xuất thực tế. Do vậy, đừng bao giờ giả định rằng môi trường kiểm tra một sản phẩm hay dịch vụ hoàn toàn giống với môi trường sản xuất trong thực tế.

11. Khi chấp nhận một công việc là bạn có trách nhiệm với công việc đó. Khi được yêu cầu trợ giúp, trách nhiệm của bạn là bảo đảm sao cho yêu cầu đó được hoàn tất một cách thành công.

12. Lời phê bình là sự đóng góp tích cực ; đổ lỗi là hành động tiêu cực. Đừng đổ lỗi cho hoàn cảnh hoặc cho người khác. Hãy thảo luận để tìm ra những phương cách phù hợp nhằm giúp nhóm làm việc có thể hoàn thành công tác tốt hơn.

13. Ghi nhớ định luật của Murphy(*). Ngay cả những hoạt động được chuẩn bị và thực thi một cách kỹ lưỡng nhất cũng khó tránh khỏi gặp rắc rối tại một thời điểm nào đó. Do đó, phải luôn đề cao cảnh giác, linh hoạt và sẵn sàng ứng phó với mọi tình huống có thể xảy ra trong quá trình thực hiện dự án.

14. Sự thông tin liên lạc có hiệu quả sẽ giúp giải quyết hoặc ngăn chặn nhiều vấn đề. Trao đổi ngay với các thành viên trong nhóm và với các cấp quản lý về những vấn đề có khả năng xảy ra hoặc những khó khăn mới phát hiện. Bạn cần phải chủ động thực hiện việc trao đổi này để có thể nhanh chóng khắc phục hậu quả ngay từ đầu.

15. Không ai thích những điều bất ngờ. Hãy thông báo những sự thay đổi đến tất cả những người có liên quan.

16. Trí nhớ của bạn cũng như của người sử dụng không đáng tin cậy. Phải ghi lại những việc cần làm và đừng nên ỷ lại vào trí nhớ của mình.

17. Công việc không hoàn tất cho đến khi bạn có được sự xác nhận của người sử dụng. Đừng bao giờ cho rằng công việc đã hoàn tất khi chưa nhận được sự chấp thuận của khách hàng.

18. Nếu không xác định mục đích một cách rõ ràng, bạn sẽ chẳng bao giờ nhận được những gì mình cần. Phải nói rõ bạn muốn có và muốn thực hiện cái gì và khi nào.

19. Người sử dụng là khách hàng. Hãy đối xử với người sử dụng như là những khách hàng (tư vấn, hướng dẫn... họ sử dụng sản phẩm một cách có hiệu quả), chứ không chỉ đơn thuần là giải quyết những sự cố theo yêu cầu của họ.

20. Tri giác là thực tế. Luôn sẵn sàng tiếp nhận ý kiến phản hồi về những gì bạn đã truyền đạt. Đừng bao giờ giả định rằng người khác cũng có những nhận thức về các vấn đề giống như bạn.

21. Phân công nhiệm vụ mà không trao quyền sẽ dẫn đến thất bại. Nếu giao trọng trách cho một người nào đó thì bạn phải cho họ những quyền cần thiết để họ có thể hoàn thành tốt nhiệm vụ được giao.

22. Những khó khăn trở ngại thì dễ thấy, nhưng giải pháp thì khó tìm ra. Trước khi tiếp xúc với người nào đó để tìm cách giải quyết một vấn đề, bạn phải có sẵn ít nhất một giải pháp cho vấn đề đó.

23. Cảm nhận của bạn không phải là cảm nhận của người khác. Có những vấn đề đối với bạn là rõ ràng nhưng với người khác thì không. Do vậy, đừng nghĩ rằng mọi người đều có sự phán đoán giống như bạn.

24. Công nghệ không luôn phát huy tác dụng như chúng ta nghĩ. Hãy phát triển những chiến lược thử nghiệm dựa trên những công nghệ mà doanh nghiệp sử dụng.

25. Những dữ liệu bị mất và không thể phục hồi được thường nằm trong những tập tin không được sao lưu dự phòng. Vì vậy, hãy nhớ sao lưu định kỳ những hệ thống và dữ liệu của bạn.

(Đăng Nga dịch)

(*) Định luật của Murphy: “If there's more than one way to do a job, and one of those ways will result in disaster, then somebody will do it that way” (tạm dịch là “Nếu có nhiều hơn một cách để thực hiện một công việc, và một trong những cách này sẽ dẫn đến một sự thất bại hoàn toàn thì người ta sẽ làm công việc này theo cách đó.”). Định luật này được Edward A. Murphy (1918-1990), một kỹ sư không gian người Mỹ, đưa ra trong năm 1949 khi ông tham gia những cuộc thử nghiệm về hệ thống tên lửa tốc độ cao của lực lượng không quân Mỹ.

Khuôn khổ một quy trình hỗ trợ

Để một quy trình hỗ trợ CNTT mang lại hiệu quả cao nhất, bạn cần vạch ra phương hướng phát triển rõ ràng và phù hợp với những tiêu chuẩn của ngành như CMM (Capability Maturity Model – Mô hình đánh giá năng lực sản xuất phần mềm) và ITIL (Information Technology Infrastructure Library – Thư viện cơ sở hạ tầng CNTT). Việc thiết kế và thực hiện các chuẩn này là khó khăn. Tuy nhiên, nếu quyết tâm thực hiện, bạn có thể giảm chi phí điều hành, cải tiến chất lượng và thỏa mãn các yêu cầu của khách hàng. Theo kinh nghiệm của tác giả, nếu có được những quy trình tuân thủ các yêu cầu nói trên, bạn sẽ tiết kiệm 30-50 % các khoản chi phí có liên quan đến hỗ trợ CNTT. Để đạt được điều này, bạn cần phải trả lời một số câu hỏi dưới đây:

- Công việc đang được thực hiện thuộc loại nào?

- Làm thế nào để thực hiện những công việc cùng loại với tần suất lặp lại cao?

- Ai sẽ đảm nhiệm công việc này ? Vai trò cụ thể của họ là gì ? Ai là người chịu trách nhiệm?

- Những tài liệu hỗ trợ và văn kiện khác cần có cho mỗi nhiệm vụ là gì?

- Làm thế nào chúng ta biết được những sản phẩm đã cung cấp là phù hợp với yêu cầu?

- Làm thế nào chúng ta xác định được chất lượng của những sản phẩm đã cung cấp?

- Làm thế nào chúng ta thu thập được dữ liệu của tất cả các công việc đã thực hiện và của người phụ trách công việc đó?

- Làm thế nào chúng ta đo lường được thành quả đạt được, năng suất làm việc, chất lượng và sự hài lòng của khách hàng đối với tất cả các quy trình làm việc, sản phẩm và các dịch vụ khác?

Trả lời được những câu hỏi này kết hợp với 25 quy tắc nêu trên sẽ giúp bạn tránh được những sai lầm khi xây dựng những quy trình hỗ trợ các hoạt động CNTT.
Thứ Bảy, 18/08/2007 14:17
31 👨 474
0 Bình luận
Sắp xếp theo