7:12 CH @ Thứ Sáu, 4 tháng 5, 2012
Một cách nhìn về triển khai phần mềm ở Việt Nam
Lâu lâu không viết, không pốt gì, giờ đọc thấy bài này hay hay (dù cóc biết tác giả là ai vì từ cái nguồn mềnh cọp ra họ cũng chỉ có ghi được là theo Internet, hố hố), Vậy nên pốt lại chơi, sau tham khảo cũng được....
Chúng ta đã được nghiên cứu rất cẩn thận về quy trình sản xuất phần mềm, tuy nhiên trong khuôn khổ bài viết này tôi muốn bàn luận về một số kinh nghiệm trong công việc Triển khai Phần mềm tại Việt Nam theo một cách nhìn thực tế.
Để dễ dàng trình bày, tôi mạnh dạng cho rằng một sản phẩm phần mềm được đưa vào ứng dụng có thể so sánh với việc một tác phẩm âm nhạc được đưa ra phổ biến trong dân chúng. Thật vậy, nếu bỏ qua những đặc thù của từng loại thì có thể so sánh quy trình hình thành hai loại sản phẩm này như sơ đồ hình ở trên (http://www.erpsolution.com.vn/showthread.php?t=199)
Một tác phẩm âm nhạc đi đến với công chúng thường có 3 tầng sáng tác: Nhạc sĩ, ca sĩ và người nghe. Nhạc sĩ sáng tác là điều tất nhiên. Ca sĩ cũng sáng tác ra cách để biểu diễn và truyền đạt cảm hứng của nhạc phẩm ứng với từng sân khấu, từng đối tượng nghe. Người nghe mỗi người hiểu và thưởng thức nhạc phẩm theo cách riêng, không gian riêng, tâm trạng riêng của mình.
Có rất nhiều nhạc phẩm sau khi được sáng tác thì chính nhạc sĩ đó biểu diễn luôn ví dụ như các tác phẩm của các nhạc sĩ Thế Hiển, Đức Huy hay Quốc Bảo… nhưng hầu hết các nhạc phẩm được sáng tác bởi một nhạc sĩ và được biểu diễn bởi một số ca sĩ mà không phải là chính nhạc sĩ đã sáng tác ra nó, đôi khi nguyên nhân rất đơn giản là do người nhạc sĩ không có chất giọng tốt. Mức độ thành công của kiểu nói trên thật khó so sánh, nhưng phải chăng nó hình thành ngay trong chúng ta một số khái niệm đó là khả năng và sự phù hợp.
Hiện nay, việc triển khai phần mềm đã được nhìn nhận và đánh giá cao hơn bởi hai nguyên nhân chính, thứ nhất là nó đã mang lại một doanh số khá cao, thứ hai là những phần mềm của nước ngoài như Solomon, ERP, Aptra… thì Việt nam chỉ có triển khai chứ không sản xuất. Tuy nhiên, theo tôi còn một nguyên nhân khá quan trọng nhưng ít được nói đến là “ôm khách hàng”, nhiều doanh nghiệp ngầm xem việc đưa quân mình đi triển khai là con đường ngắn nhất để tạo uy tín và thương hiệu đối với khách hàng.
Cần phải nói thêm rằng càng ngày nhu cầu triển khai phần mềm tại Việt Nam càng được tăng cao, đã qua rồi cái thời các phần mềm theo kiểu “may đo” nhỏ lẻ mà thay vào đó là các yêu cầu tích hợp phần mềm, phần mềm dùng chung…đó là các phần mềm được triển khai toàn quốc, hay toàn tỉnh nên nhu cầu về cán bộ triển khai sẽ được chú trọng trong thời gian tới.
Như vậy, xét ở góc độ kinh doanh thì rõ ràng xứ mệnh của công việc triển khai phần mềm không hề nhỏ chút nào. Điều đáng nói ở đây là hầu hết các nơi đào tạo chuyên viên CNTT chỉ nhấn mạnh đào tạo học viên trong việc sản xuất phần mềm, còn việc triển khai phần mềm coi như là tất nhiên. Ai cũng biết rằng trong “Water fall” đã có “Deployment” nhưng những kỹ năng cần thiết của ca sĩ và nhạc sĩ thì không thể đánh đồng, bao hàm.
Bây giờ chúng ta thử đi vào ghi nhận lại những tồn đọng mà việc triển khai phần mềm đang gặp phải, chúng ta sẽ cố gắng bỏ qua những tồn đọng do nguyên nhân khách quan mà chỉ tập trung vào những nguyên nhân chủ quan.
Quản lý cấu hình
Điều này thường xuyên xảy ra đối với các cán bộ triển khai (CBTK) được lấy ra từ đội sản xuất. Cho dù có quy định thế nào đi nữa thì việc các CBTK ngồi sửa code tại khách hàng là điều khó tránh khỏi, vì theo suy nghĩ của họ thì chỉ cần sửa nhỏ chút xíu mà chương trình đáp ứng yêu cần của người dùng, sau này về cơ quan sửa lại. Tuy nhiên, khi về cơ quan thì vì rất nhiều nguyên nhân khuyến họ không còn nhớ việc đó nữa, nhiều người như vậy để rồi cuối cũng thì mỗi đơn vị khách hàng có một phiên bản khách nhau, đến một thời điểm thì việc quản lý cấu hình không còn khả thi. Điều này đã rất nhiều đơn vị gặp và hậu quả của nó là không thể thu thập đầy đủ các phản hồi của người dùng và cực kỳ khó khăn khi cài đặt phiên bản mới. Việc này có thể ví như anh chàng nhạc sĩ tự biểu diễn bài hát của mình, gặp hôm nào thấy đau cổ họng thì rút viết ra chỉnh lại vài nốt nhạc cho dễ hát.
Đóng gói
Thông thường thì đội sản xuất sẽ không mấy tập trung cho việc đóng gói sản phẩm, bởi khi họ trực tiếp đi triển khai thì việc cài đặt, cấu hình như thế nào sẽ không là vấn đề. Vấn đề sẽ cực kỳ gian nan với những CBTK mà không phải xuất thân từ đội sản xuất đó, họ phải làm quen hàng loạt thông số, dữ liệu, và đôi khi cả cấu trúc của chương trình. Đau khổ hơn là khi trực tiếp triển khai mới phát sinh lỗi mà lỗi này do một thông số nào đó mình chưa được đào tạo lại hoặc mình quên. Điều này giống như ca sĩ phải trình bày một nhạc phẩm sau khi nghe ai đó đã hát mà không được xem bản nhạc gốc, nên việc hát sai nhạc, sai lời là chuyện thường.
Tiếp nhận phản hồi
Khi khách hàng yêu cầu chỉnh sửa hoặc bỗ sung một số chức năng, nếu CBTK là người xuất thân từ đội sản xuất, thay vì anh ta ghi nhận hoặc giải thích thì anh ta lại đứng phân tích ngầm trong đầu: Việc này cần phải sửa database, sửa code, sửa report… nếu thấy sửa nhiều quá thì anh ta tìm mọi cách để áp đặt khách hàng làm theo ý mình, ngược lại, nếu thấy chỉ sửa nhỏ thì anh ta đồng ý. Rất nhiều khách hàng bực bội và cho rằng họ bị áp đặt và có một số trường hợp người dùng sẽ tẩy chay chương trình. Việc tiếp nhận phản hồi của khách hàng là một may mắn của sản phẩm phần mềm nếu so với tác phẩm âm nhạc, không có khán thính giả nào lại yêu cầu ca sĩ “về nói ông nhạc sĩ viết lời lại và chỉnh một số nốt nhạc thì tôi mới nghe”, mà ngược lại nếu nghe không hay thì người ta bỏ luôn. Chúng ta cần tận dụng tối đa may mắn này trong việc sản xuất phần mềm.
Hiểu nghiệp vụ
Hầu hết các doanh nghiệp chỉ chú tâm rằng nhân viên triển khai của mình đã nắm bắt được các tính năng của chương trình hay chưa, chứ không mấy quan tâm đến việc nhân viên của mình đã hiểu nghiệp vụ của người dùng hay chưa. Rắc rối này thường gặp nhất ở các nhân viên trẻ, trong quá trình đào tạo, họ thường chú tâm đến những gì phần mềm mình có mà rất ít khi quan tâm đến thực tế khách hàng làm việc thế nào, đã nhiều lần tôi gặp trường hợp khá buồn cười: sau khi hướng dẫn cho khách hàng đầy đủ các tính năng của chương trình Quản lý Công văn, khách hàng lấy ra một vài công văn yêu cầu CBTK áp dụng thử thì chịu, vì CBTK không biết được đâu là trích yếu, đâu là số ký hiệu gốc…của Công văn ấy. Đó là chưa nói có rất nhiều từ ngữ nghiệp vụ của khách hàng mà chúng ta hầu như chưa tìm hiểu bao giờ, ví dụ: “sao y” khác với “chứng thực” thế nào, “đăng bộ” là gì, “tống đạt” là gì… Tất nhiên, không môi trường đào tạo nào có thể giảng dạy đầy đủ, tuy nhiên việc chỉ tập trung nắm bắt các tính năng của chương trình mà quên đi nghiệp vụ đã để lại không ít hoài nghi trong suy nghĩ của khách hàng. Điều này cũng giống như ca sĩ chỉ cố công gào thét, còn gào thét để làm gì thì không xác định được.
Dẫn dắt vấn đề
Lần này thì giả sử họ hiểu nghiệp vụ rất rõ, nhưng tôi lại muốn nói đến khía cạnh CBTK dẫn dắt người dùng vào chương trình của mình như thế nào. Thường thì có 2 cách dẫn dắt: “1- các anh chị dùng tính năng X của chương trình để làm công việc A” hoặc “2- Khi có nhu cầu làm công việc A thì các anh chị mở tính năng X ra để áp dụng”, về ý nghĩa thì như nhau, nhưng hầu hết các CBTK thường dùng cách 1, trong khi cách 2 thường mang lại hiệu quả hơn, kiểu dẫn dắt ấy giúp người dùng đi từ những việc thông thường của họ và bước dần vào chương trình mới mẻ, cách 2 còn khẳng định với khách hàng rằng “tôi đã hiểu nghiệp vụ của các anh chị”. Các ca sĩ khi về những vùng quê muốn hát nhạc Disco thì trước tiên họ cũng hát vài bản nhạc tình cảm.
Giao tiếp
Có thể nói, khi đi triển khai, đối tượng làm việc của chúng ta là con người chứ không phải là máy tính như khi ta sản xuất chương trình. Chúng ta sẽ được tiếp súc với nhiều đối tượng, nhiều quan chức khác nhau, mỗi người trong họ lại có những độ thông cảm không giống nhau. Rắc rối sẽ bắt đầu xuất hiện khi chúng ta không đủ tự tin khi tiếp xúc với họ mà nguyên nhân phần lớn là do chúng ta chuẩn bị tâm lý không cẩn thận. Đặc biệt có nhiều vị khách hàng thường hỏi những vấn đề mỡ rộng đôi chút thì gần như CBTK bắt đầu lúng túng, đó cũng là thời điểm phát sinh tư tưởng “ngon”, không biết cũng không giám nói là “để em xem lại” hoặc “để em về báo cáo với lãnh đạo bên em”, thay vào đó CBTK lại mông lung nói không đâu ra đâu. Chúng ta thường đánh giá không cao khả năng về CNTT của khách hàng, tưởng rằng có thể “múa rìu qua mắt thợ điện” ai ngờ trước mặt mình là tay “thợ rừng chuyên nghiệp”. Xin phép khẳng định rằng trong khách hàng có không ít vị rất am tường về ứng dụng CNTT, vì thế chúng ta cần hết sức thận trọng, hoặc ít nhất chúng ta cần tôn trọng khách hàng vì họ luôn là người nắm nghiệp vụ hơn chúng ta nhiều.
Hình như trong suốt quá trình triển khai phần mềm, CBTK nào cũng ít nhất cãi nhau với khách hàng một vài lần, không phải cuộc cãi nhau nào cũng có hại nhưng chắc chắn rằng buổi làm việc đó sẽ không có kết quả. Các cuộc cãi nhau thường bắt đầu khi khách hàng chê phần mềm của chúng ta kém, máu “văn ta vợ người” trào lên, và lúc đó chúng ta cố hết lời để chứng minh phần mềm của mình ngon. Các ca sĩ thì họ thường chuẩn bị trước, không phải một bài hát họ rất tâm đắc nào cũng có thể làm hài lòng tất cả người nghe, có nhiều người mê cuồng bài hát đó nhưng cũng không ít người bỉu môi.
Kỹ năng giảng dạy
Điều này có lẽ phụ thuộc rất nhiều vào năng khiếu của mỗi người nhưng không phải là không thể tập luyện, bởi ngoài khả năng ăn nói lưu loát thì trong giảng dạy quan trọng nhất vẫn là nội dung muốn truyền đạt. Hầu hết CBTK đều không xác định trước đối tượng mình sẽ trình bày để chuẩn bị nội dung tương ứng, chúng ta cũng ít khi xác định mục đích và những tiêu chí cần thiết nhất để truyền đạt, nên dễ bị mông lung. Có khi chúng ta chỉ giảng dạy cho một nhóm người nhưng cũng nhiều khi chúng ta phải đứng giảng trước cả hội trường với Micro, máy chiếu. Có thể nói rằng rất ít người trong chúng ta đóng tròn vai thầy giáo này. Run sợ là biểu hiện đầu tiên, kéo theo đó là lắc chuột vô tội vạ trên màn hình, nói thì ít lắc chuột thì nhiều. Có khi dừng lại một hồi lâu không nói gì mà cứ gõ phím rồi lại xoá, gõ rồi lại xoá. Mồ hôi thì chảy dài trên má và đẫm cả áo, nhìn thấy thương. Cá biệt có trường hợp do run quá mà làm rơi Micro. Nhiều trường hợp không hề quan tâm đến việc chọn vị trí đứng giảng cho phù hợp vừa gây khó cho mình lại khó cho người thao dõi.
Rồi xưng hô, đứng giảng dạy nhiều bạn vẫn xưng là con cho ngôi thứ nhất, theo tôi thì cứ phải xưng tôi, chúng tôi hoặc tối thiểu cũng phải là em.
Theo tôi thì việc không chuẩn bị kỷ cho đội quân triển khai là nguyên nhân chính. Hậu quả của nó là cuối buổi dạy, nhìn xuống bên dưới không còn mấy người.
Sức khoẻ
CBTK phải có sức khoẻ dồi dào mới có thể đáp ứng yêu cầu công việc liên tục và cường độ cao. Trước hết, lịch sinh hoạt cá nhân hoàn toàn bị xáo trộn, qua rồi cái ngày ở nhà với mẹ, chăn ấm nệm êm, cơm no áo ấm. Lần này chúng ta phải thường xuyên di chuyển không kể ngày hay đêm, việc ngủ trên xe để sáng hôm sau đến nơi làm việc tiếp là bình thường. Nhiều bạn không quen đi xe nên bị say xe, uống thuốc vẫn say, mà đã say xe thì sự mệt mỏi là người bạn đồng hành bất đắc dĩ, chúng ta cũng không thể làm việc tốt mỗi khi có người bạn này bên mình. Không thể định trước mình sẽ ngủ bao nhiêu tiếng đồng hồ hay thức dậy lúc mấy giờ, cũng không thể định trước mình hoàn thành công việc vào giờ nào, xong việc có về được ngay hay phải trú lại đêm. Thường thì xong việc sẽ được mời nhậu, nếu chúng ta không biết nhậu thì đấy là một nỗi khốn khổ, tôi cũng là người không biết nhậu nên tôi thường từ chối với lý do việc còn nhiều, hoặc tôi sẽ đi cùng với một bạn biết nhậu. Nói chung cuộc sống của CBTK là: Ăn bất kỳ món gì, bất kỳ ở đâu, đâu cũng là nhà, đâu cũng là giường, chuyện giờ giấc xin quên đi và đòi hỏi chúng ta phải có một thể lực dồi dào. Đi triển khai cũng giống như ca sĩ chạy show, chỉ khác nhau là họ được nhiều tiền thù lao còn chúng ta được nhiều rượu bia, say xe và ăn quán ngủ trọ.
Dịch vụ cơ bản
Điều thiếu nhất của các CBTK xuất thân từ dân phần mềm là các dịch vụ cơ bản, nó là Windows, LDAP, DHCP, DNS, IIS, Mail Server, là ADSL, TCP/IP, kiến trúc mạng… Phần lớn chúng ta xem đó là những thứ đã có sẵn, đã hoàn chỉnh, công việc của chúng ta chỉ là Phần mềm. Cũng vì thế mà khi chạy đến khách hàng, thấy máy không kết nối mạng được thì chúng ta lại về, nếu chúng ta có kiến thức hạ tầng thì có thể chúng ta sẽ kiểm tra và kết nối mạng giúp các đơn vị, sau đó mình làm việc của mình, vừa hoàn thành công việc lại vừa được lòng khách hàng. Tất cả các kiến thức nói trên thật ra chỉ cần đào tạo trong một ngày là có thể áp dụng được nhưng hầu hết các doanh nghiệp không hề quan tâm đến nó, bản thân chúng ta cũng không tự nghiên cứu. Tệ hại hơn, nhiều bạn sau khi “mò mẫm” thì làm cho máy của khách hàng rớt mạng luôn, không biết chỉnh sửa thế nào nên đành bỏ về. Chúng ta nghĩ gì khi một ca sĩ đến nơi biểu diễn đầy ắp khán giả ham mộ, đầy đủ mọi thứ nhưng dàn nhạc không đánh được bài Rock mà ca sĩ định biểu diễn, thế là ca sĩ bỏ về trong sự ngơ ngác của khán giả. Rõ ràng nếu có sự chuẩn bị nghiêm túc thì ca sĩ luôn mang kèm theo mình đĩa nhạc đệm đã đánh sẵn.
Tán gẫu với IT
Thường thì đi ăn trưa hay đi nhậu, các IT tranh thủ hỏi chúng ta một số thông tin, khuất mắt, băn khoăn, nhất là các vấn đề về dịch vụ cơ bản như đã nói ở trên. Đôi khi chúng ta chỉ cần nói chuyện “chim trời cá nước” gì đó cũng được nhưng phải nói, phải giao tiếp thì mới vui, mới để lại ấn tượng. Không ít người chẳng biết nói gì nên cứ ngồi đợi người ta nói, mình nghe. Còn nếu IT cũng im re thì bữa ăn trở nên nặng nề vô cùng. Thật ra, thân tình với IT hay không là những lúc này, IT có quý mình hay không là những lúc này. Nếu chúng ta nói được những thông tin quý thoả đáng hoặc nói chuyện vui vẻ thì họ sẽ thấy chúng ta nhiệt tình, dễ mến. Nhiều ca sĩ hát nghe cũng được nhưng trả lời phỏng vấn của báo chí thì không nhận ra đâu là họ nữa.
Tư vấn
Đây là yếu điểm nhất của phần lớn các CBTK, trong các Hợp đồng Kinh tế về triển khai phần mềm thường để trách nhiệm của bên B: “Tư vấn và triển khai”, tuy nhiên gần như các doanh nghiệp chỉ chú tâm tư vấn ở tầm lãnh đạo, còn các CBTK hầu như quên mất nhiệm vụ này. Thật ra làm thế nào để có thể áp dụng phần mềm mình triển khai vào quy trình công việc hiện tại cuả khách hàng một cách phù hợp nhất mới là nhiệm vụ khó khăn của CBTK. Rất tiếc, các doanh nghiệp vừa thiếu người có khả năng tư vấn lại vừa thiếu quan tâm nên công việc triển khai phần mềm lắm khi có sự chênh vênh giữa yêu cầu người dùng và các tính năng của chương trình.
Cho dù còn nhiều khập khiển trong cách so sánh giữa sứ mệnh của Cán bộ triển khai phần mềm và sứ mệnh của Ca sĩ, tuy nhiên việc mang đến cho thính khán những âm hưởng ngọt ngào để rồi trong phút giây chạnh lòng con người ta lại nghĩ về âm hưởng đó, nghĩ về người ca sĩ đã truyền tải. Một ca khúc chỉ hay khi mà ca khúc ấy được biểu diễn bởi một ca sĩ có những tố chất phù hợp, một ca sĩ đầy tâm huyết và có sự chuẩn bị chu đáo.
Xem ra, những yêu cầu cần thiết của một CBTK không hề đơn giản, tuy nhiên cho dù không có được những yêu cầu trên thì những CBTK cũng đã hoàn thành “xuất sắc” công việc của mình. Thông điệp của bài viết cũng chỉ dừng lại ở góc độ tham khảo, nếu nhiều hơn cũng chỉ là một sự chuẩn bị tối thiểu về tư tưởng nếu chúng ta chọn công việc triển khai phần mềm. Riêng với tôi, là một cán bộ triển khai, tôi rất hạnh phúc, đơn giản vì nó phù hợp với sở thích. Khi triển khai phần mềm tôi được đi nhiều nơi, được sống cuộc sống mà có thể tạm gọi là “chu du thiên hạ”. Tôi thích được tiếp xúc với nhiều kiểu người khác nhau, thích được người khác đánh giá về mình và trong những chuyến đi, tôi không quên nhìn trời nhìn đất, nhìn núi nhìn sông, nhìn cảnh sống cơ cực của người dân trên khắp mảnh đất hình chữ S.
Chúng ta đã được nghiên cứu rất cẩn thận về quy trình sản xuất phần mềm, tuy nhiên trong khuôn khổ bài viết này tôi muốn bàn luận về một số kinh nghiệm trong công việc Triển khai Phần mềm tại Việt Nam theo một cách nhìn thực tế.
Để dễ dàng trình bày, tôi mạnh dạng cho rằng một sản phẩm phần mềm được đưa vào ứng dụng có thể so sánh với việc một tác phẩm âm nhạc được đưa ra phổ biến trong dân chúng. Thật vậy, nếu bỏ qua những đặc thù của từng loại thì có thể so sánh quy trình hình thành hai loại sản phẩm này như sơ đồ hình ở trên (http://www.erpsolution.com.vn/showthread.php?t=199)
Một tác phẩm âm nhạc đi đến với công chúng thường có 3 tầng sáng tác: Nhạc sĩ, ca sĩ và người nghe. Nhạc sĩ sáng tác là điều tất nhiên. Ca sĩ cũng sáng tác ra cách để biểu diễn và truyền đạt cảm hứng của nhạc phẩm ứng với từng sân khấu, từng đối tượng nghe. Người nghe mỗi người hiểu và thưởng thức nhạc phẩm theo cách riêng, không gian riêng, tâm trạng riêng của mình.
Có rất nhiều nhạc phẩm sau khi được sáng tác thì chính nhạc sĩ đó biểu diễn luôn ví dụ như các tác phẩm của các nhạc sĩ Thế Hiển, Đức Huy hay Quốc Bảo… nhưng hầu hết các nhạc phẩm được sáng tác bởi một nhạc sĩ và được biểu diễn bởi một số ca sĩ mà không phải là chính nhạc sĩ đã sáng tác ra nó, đôi khi nguyên nhân rất đơn giản là do người nhạc sĩ không có chất giọng tốt. Mức độ thành công của kiểu nói trên thật khó so sánh, nhưng phải chăng nó hình thành ngay trong chúng ta một số khái niệm đó là khả năng và sự phù hợp.
Hiện nay, việc triển khai phần mềm đã được nhìn nhận và đánh giá cao hơn bởi hai nguyên nhân chính, thứ nhất là nó đã mang lại một doanh số khá cao, thứ hai là những phần mềm của nước ngoài như Solomon, ERP, Aptra… thì Việt nam chỉ có triển khai chứ không sản xuất. Tuy nhiên, theo tôi còn một nguyên nhân khá quan trọng nhưng ít được nói đến là “ôm khách hàng”, nhiều doanh nghiệp ngầm xem việc đưa quân mình đi triển khai là con đường ngắn nhất để tạo uy tín và thương hiệu đối với khách hàng.
Cần phải nói thêm rằng càng ngày nhu cầu triển khai phần mềm tại Việt Nam càng được tăng cao, đã qua rồi cái thời các phần mềm theo kiểu “may đo” nhỏ lẻ mà thay vào đó là các yêu cầu tích hợp phần mềm, phần mềm dùng chung…đó là các phần mềm được triển khai toàn quốc, hay toàn tỉnh nên nhu cầu về cán bộ triển khai sẽ được chú trọng trong thời gian tới.
Như vậy, xét ở góc độ kinh doanh thì rõ ràng xứ mệnh của công việc triển khai phần mềm không hề nhỏ chút nào. Điều đáng nói ở đây là hầu hết các nơi đào tạo chuyên viên CNTT chỉ nhấn mạnh đào tạo học viên trong việc sản xuất phần mềm, còn việc triển khai phần mềm coi như là tất nhiên. Ai cũng biết rằng trong “Water fall” đã có “Deployment” nhưng những kỹ năng cần thiết của ca sĩ và nhạc sĩ thì không thể đánh đồng, bao hàm.
Bây giờ chúng ta thử đi vào ghi nhận lại những tồn đọng mà việc triển khai phần mềm đang gặp phải, chúng ta sẽ cố gắng bỏ qua những tồn đọng do nguyên nhân khách quan mà chỉ tập trung vào những nguyên nhân chủ quan.
Quản lý cấu hình
Điều này thường xuyên xảy ra đối với các cán bộ triển khai (CBTK) được lấy ra từ đội sản xuất. Cho dù có quy định thế nào đi nữa thì việc các CBTK ngồi sửa code tại khách hàng là điều khó tránh khỏi, vì theo suy nghĩ của họ thì chỉ cần sửa nhỏ chút xíu mà chương trình đáp ứng yêu cần của người dùng, sau này về cơ quan sửa lại. Tuy nhiên, khi về cơ quan thì vì rất nhiều nguyên nhân khuyến họ không còn nhớ việc đó nữa, nhiều người như vậy để rồi cuối cũng thì mỗi đơn vị khách hàng có một phiên bản khách nhau, đến một thời điểm thì việc quản lý cấu hình không còn khả thi. Điều này đã rất nhiều đơn vị gặp và hậu quả của nó là không thể thu thập đầy đủ các phản hồi của người dùng và cực kỳ khó khăn khi cài đặt phiên bản mới. Việc này có thể ví như anh chàng nhạc sĩ tự biểu diễn bài hát của mình, gặp hôm nào thấy đau cổ họng thì rút viết ra chỉnh lại vài nốt nhạc cho dễ hát.
Đóng gói
Thông thường thì đội sản xuất sẽ không mấy tập trung cho việc đóng gói sản phẩm, bởi khi họ trực tiếp đi triển khai thì việc cài đặt, cấu hình như thế nào sẽ không là vấn đề. Vấn đề sẽ cực kỳ gian nan với những CBTK mà không phải xuất thân từ đội sản xuất đó, họ phải làm quen hàng loạt thông số, dữ liệu, và đôi khi cả cấu trúc của chương trình. Đau khổ hơn là khi trực tiếp triển khai mới phát sinh lỗi mà lỗi này do một thông số nào đó mình chưa được đào tạo lại hoặc mình quên. Điều này giống như ca sĩ phải trình bày một nhạc phẩm sau khi nghe ai đó đã hát mà không được xem bản nhạc gốc, nên việc hát sai nhạc, sai lời là chuyện thường.
Tiếp nhận phản hồi
Khi khách hàng yêu cầu chỉnh sửa hoặc bỗ sung một số chức năng, nếu CBTK là người xuất thân từ đội sản xuất, thay vì anh ta ghi nhận hoặc giải thích thì anh ta lại đứng phân tích ngầm trong đầu: Việc này cần phải sửa database, sửa code, sửa report… nếu thấy sửa nhiều quá thì anh ta tìm mọi cách để áp đặt khách hàng làm theo ý mình, ngược lại, nếu thấy chỉ sửa nhỏ thì anh ta đồng ý. Rất nhiều khách hàng bực bội và cho rằng họ bị áp đặt và có một số trường hợp người dùng sẽ tẩy chay chương trình. Việc tiếp nhận phản hồi của khách hàng là một may mắn của sản phẩm phần mềm nếu so với tác phẩm âm nhạc, không có khán thính giả nào lại yêu cầu ca sĩ “về nói ông nhạc sĩ viết lời lại và chỉnh một số nốt nhạc thì tôi mới nghe”, mà ngược lại nếu nghe không hay thì người ta bỏ luôn. Chúng ta cần tận dụng tối đa may mắn này trong việc sản xuất phần mềm.
Hiểu nghiệp vụ
Hầu hết các doanh nghiệp chỉ chú tâm rằng nhân viên triển khai của mình đã nắm bắt được các tính năng của chương trình hay chưa, chứ không mấy quan tâm đến việc nhân viên của mình đã hiểu nghiệp vụ của người dùng hay chưa. Rắc rối này thường gặp nhất ở các nhân viên trẻ, trong quá trình đào tạo, họ thường chú tâm đến những gì phần mềm mình có mà rất ít khi quan tâm đến thực tế khách hàng làm việc thế nào, đã nhiều lần tôi gặp trường hợp khá buồn cười: sau khi hướng dẫn cho khách hàng đầy đủ các tính năng của chương trình Quản lý Công văn, khách hàng lấy ra một vài công văn yêu cầu CBTK áp dụng thử thì chịu, vì CBTK không biết được đâu là trích yếu, đâu là số ký hiệu gốc…của Công văn ấy. Đó là chưa nói có rất nhiều từ ngữ nghiệp vụ của khách hàng mà chúng ta hầu như chưa tìm hiểu bao giờ, ví dụ: “sao y” khác với “chứng thực” thế nào, “đăng bộ” là gì, “tống đạt” là gì… Tất nhiên, không môi trường đào tạo nào có thể giảng dạy đầy đủ, tuy nhiên việc chỉ tập trung nắm bắt các tính năng của chương trình mà quên đi nghiệp vụ đã để lại không ít hoài nghi trong suy nghĩ của khách hàng. Điều này cũng giống như ca sĩ chỉ cố công gào thét, còn gào thét để làm gì thì không xác định được.
Dẫn dắt vấn đề
Lần này thì giả sử họ hiểu nghiệp vụ rất rõ, nhưng tôi lại muốn nói đến khía cạnh CBTK dẫn dắt người dùng vào chương trình của mình như thế nào. Thường thì có 2 cách dẫn dắt: “1- các anh chị dùng tính năng X của chương trình để làm công việc A” hoặc “2- Khi có nhu cầu làm công việc A thì các anh chị mở tính năng X ra để áp dụng”, về ý nghĩa thì như nhau, nhưng hầu hết các CBTK thường dùng cách 1, trong khi cách 2 thường mang lại hiệu quả hơn, kiểu dẫn dắt ấy giúp người dùng đi từ những việc thông thường của họ và bước dần vào chương trình mới mẻ, cách 2 còn khẳng định với khách hàng rằng “tôi đã hiểu nghiệp vụ của các anh chị”. Các ca sĩ khi về những vùng quê muốn hát nhạc Disco thì trước tiên họ cũng hát vài bản nhạc tình cảm.
Giao tiếp
Có thể nói, khi đi triển khai, đối tượng làm việc của chúng ta là con người chứ không phải là máy tính như khi ta sản xuất chương trình. Chúng ta sẽ được tiếp súc với nhiều đối tượng, nhiều quan chức khác nhau, mỗi người trong họ lại có những độ thông cảm không giống nhau. Rắc rối sẽ bắt đầu xuất hiện khi chúng ta không đủ tự tin khi tiếp xúc với họ mà nguyên nhân phần lớn là do chúng ta chuẩn bị tâm lý không cẩn thận. Đặc biệt có nhiều vị khách hàng thường hỏi những vấn đề mỡ rộng đôi chút thì gần như CBTK bắt đầu lúng túng, đó cũng là thời điểm phát sinh tư tưởng “ngon”, không biết cũng không giám nói là “để em xem lại” hoặc “để em về báo cáo với lãnh đạo bên em”, thay vào đó CBTK lại mông lung nói không đâu ra đâu. Chúng ta thường đánh giá không cao khả năng về CNTT của khách hàng, tưởng rằng có thể “múa rìu qua mắt thợ điện” ai ngờ trước mặt mình là tay “thợ rừng chuyên nghiệp”. Xin phép khẳng định rằng trong khách hàng có không ít vị rất am tường về ứng dụng CNTT, vì thế chúng ta cần hết sức thận trọng, hoặc ít nhất chúng ta cần tôn trọng khách hàng vì họ luôn là người nắm nghiệp vụ hơn chúng ta nhiều.
Hình như trong suốt quá trình triển khai phần mềm, CBTK nào cũng ít nhất cãi nhau với khách hàng một vài lần, không phải cuộc cãi nhau nào cũng có hại nhưng chắc chắn rằng buổi làm việc đó sẽ không có kết quả. Các cuộc cãi nhau thường bắt đầu khi khách hàng chê phần mềm của chúng ta kém, máu “văn ta vợ người” trào lên, và lúc đó chúng ta cố hết lời để chứng minh phần mềm của mình ngon. Các ca sĩ thì họ thường chuẩn bị trước, không phải một bài hát họ rất tâm đắc nào cũng có thể làm hài lòng tất cả người nghe, có nhiều người mê cuồng bài hát đó nhưng cũng không ít người bỉu môi.
Kỹ năng giảng dạy
Điều này có lẽ phụ thuộc rất nhiều vào năng khiếu của mỗi người nhưng không phải là không thể tập luyện, bởi ngoài khả năng ăn nói lưu loát thì trong giảng dạy quan trọng nhất vẫn là nội dung muốn truyền đạt. Hầu hết CBTK đều không xác định trước đối tượng mình sẽ trình bày để chuẩn bị nội dung tương ứng, chúng ta cũng ít khi xác định mục đích và những tiêu chí cần thiết nhất để truyền đạt, nên dễ bị mông lung. Có khi chúng ta chỉ giảng dạy cho một nhóm người nhưng cũng nhiều khi chúng ta phải đứng giảng trước cả hội trường với Micro, máy chiếu. Có thể nói rằng rất ít người trong chúng ta đóng tròn vai thầy giáo này. Run sợ là biểu hiện đầu tiên, kéo theo đó là lắc chuột vô tội vạ trên màn hình, nói thì ít lắc chuột thì nhiều. Có khi dừng lại một hồi lâu không nói gì mà cứ gõ phím rồi lại xoá, gõ rồi lại xoá. Mồ hôi thì chảy dài trên má và đẫm cả áo, nhìn thấy thương. Cá biệt có trường hợp do run quá mà làm rơi Micro. Nhiều trường hợp không hề quan tâm đến việc chọn vị trí đứng giảng cho phù hợp vừa gây khó cho mình lại khó cho người thao dõi.
Rồi xưng hô, đứng giảng dạy nhiều bạn vẫn xưng là con cho ngôi thứ nhất, theo tôi thì cứ phải xưng tôi, chúng tôi hoặc tối thiểu cũng phải là em.
Theo tôi thì việc không chuẩn bị kỷ cho đội quân triển khai là nguyên nhân chính. Hậu quả của nó là cuối buổi dạy, nhìn xuống bên dưới không còn mấy người.
Sức khoẻ
CBTK phải có sức khoẻ dồi dào mới có thể đáp ứng yêu cầu công việc liên tục và cường độ cao. Trước hết, lịch sinh hoạt cá nhân hoàn toàn bị xáo trộn, qua rồi cái ngày ở nhà với mẹ, chăn ấm nệm êm, cơm no áo ấm. Lần này chúng ta phải thường xuyên di chuyển không kể ngày hay đêm, việc ngủ trên xe để sáng hôm sau đến nơi làm việc tiếp là bình thường. Nhiều bạn không quen đi xe nên bị say xe, uống thuốc vẫn say, mà đã say xe thì sự mệt mỏi là người bạn đồng hành bất đắc dĩ, chúng ta cũng không thể làm việc tốt mỗi khi có người bạn này bên mình. Không thể định trước mình sẽ ngủ bao nhiêu tiếng đồng hồ hay thức dậy lúc mấy giờ, cũng không thể định trước mình hoàn thành công việc vào giờ nào, xong việc có về được ngay hay phải trú lại đêm. Thường thì xong việc sẽ được mời nhậu, nếu chúng ta không biết nhậu thì đấy là một nỗi khốn khổ, tôi cũng là người không biết nhậu nên tôi thường từ chối với lý do việc còn nhiều, hoặc tôi sẽ đi cùng với một bạn biết nhậu. Nói chung cuộc sống của CBTK là: Ăn bất kỳ món gì, bất kỳ ở đâu, đâu cũng là nhà, đâu cũng là giường, chuyện giờ giấc xin quên đi và đòi hỏi chúng ta phải có một thể lực dồi dào. Đi triển khai cũng giống như ca sĩ chạy show, chỉ khác nhau là họ được nhiều tiền thù lao còn chúng ta được nhiều rượu bia, say xe và ăn quán ngủ trọ.
Dịch vụ cơ bản
Điều thiếu nhất của các CBTK xuất thân từ dân phần mềm là các dịch vụ cơ bản, nó là Windows, LDAP, DHCP, DNS, IIS, Mail Server, là ADSL, TCP/IP, kiến trúc mạng… Phần lớn chúng ta xem đó là những thứ đã có sẵn, đã hoàn chỉnh, công việc của chúng ta chỉ là Phần mềm. Cũng vì thế mà khi chạy đến khách hàng, thấy máy không kết nối mạng được thì chúng ta lại về, nếu chúng ta có kiến thức hạ tầng thì có thể chúng ta sẽ kiểm tra và kết nối mạng giúp các đơn vị, sau đó mình làm việc của mình, vừa hoàn thành công việc lại vừa được lòng khách hàng. Tất cả các kiến thức nói trên thật ra chỉ cần đào tạo trong một ngày là có thể áp dụng được nhưng hầu hết các doanh nghiệp không hề quan tâm đến nó, bản thân chúng ta cũng không tự nghiên cứu. Tệ hại hơn, nhiều bạn sau khi “mò mẫm” thì làm cho máy của khách hàng rớt mạng luôn, không biết chỉnh sửa thế nào nên đành bỏ về. Chúng ta nghĩ gì khi một ca sĩ đến nơi biểu diễn đầy ắp khán giả ham mộ, đầy đủ mọi thứ nhưng dàn nhạc không đánh được bài Rock mà ca sĩ định biểu diễn, thế là ca sĩ bỏ về trong sự ngơ ngác của khán giả. Rõ ràng nếu có sự chuẩn bị nghiêm túc thì ca sĩ luôn mang kèm theo mình đĩa nhạc đệm đã đánh sẵn.
Tán gẫu với IT
Thường thì đi ăn trưa hay đi nhậu, các IT tranh thủ hỏi chúng ta một số thông tin, khuất mắt, băn khoăn, nhất là các vấn đề về dịch vụ cơ bản như đã nói ở trên. Đôi khi chúng ta chỉ cần nói chuyện “chim trời cá nước” gì đó cũng được nhưng phải nói, phải giao tiếp thì mới vui, mới để lại ấn tượng. Không ít người chẳng biết nói gì nên cứ ngồi đợi người ta nói, mình nghe. Còn nếu IT cũng im re thì bữa ăn trở nên nặng nề vô cùng. Thật ra, thân tình với IT hay không là những lúc này, IT có quý mình hay không là những lúc này. Nếu chúng ta nói được những thông tin quý thoả đáng hoặc nói chuyện vui vẻ thì họ sẽ thấy chúng ta nhiệt tình, dễ mến. Nhiều ca sĩ hát nghe cũng được nhưng trả lời phỏng vấn của báo chí thì không nhận ra đâu là họ nữa.
Tư vấn
Đây là yếu điểm nhất của phần lớn các CBTK, trong các Hợp đồng Kinh tế về triển khai phần mềm thường để trách nhiệm của bên B: “Tư vấn và triển khai”, tuy nhiên gần như các doanh nghiệp chỉ chú tâm tư vấn ở tầm lãnh đạo, còn các CBTK hầu như quên mất nhiệm vụ này. Thật ra làm thế nào để có thể áp dụng phần mềm mình triển khai vào quy trình công việc hiện tại cuả khách hàng một cách phù hợp nhất mới là nhiệm vụ khó khăn của CBTK. Rất tiếc, các doanh nghiệp vừa thiếu người có khả năng tư vấn lại vừa thiếu quan tâm nên công việc triển khai phần mềm lắm khi có sự chênh vênh giữa yêu cầu người dùng và các tính năng của chương trình.
Cho dù còn nhiều khập khiển trong cách so sánh giữa sứ mệnh của Cán bộ triển khai phần mềm và sứ mệnh của Ca sĩ, tuy nhiên việc mang đến cho thính khán những âm hưởng ngọt ngào để rồi trong phút giây chạnh lòng con người ta lại nghĩ về âm hưởng đó, nghĩ về người ca sĩ đã truyền tải. Một ca khúc chỉ hay khi mà ca khúc ấy được biểu diễn bởi một ca sĩ có những tố chất phù hợp, một ca sĩ đầy tâm huyết và có sự chuẩn bị chu đáo.
Xem ra, những yêu cầu cần thiết của một CBTK không hề đơn giản, tuy nhiên cho dù không có được những yêu cầu trên thì những CBTK cũng đã hoàn thành “xuất sắc” công việc của mình. Thông điệp của bài viết cũng chỉ dừng lại ở góc độ tham khảo, nếu nhiều hơn cũng chỉ là một sự chuẩn bị tối thiểu về tư tưởng nếu chúng ta chọn công việc triển khai phần mềm. Riêng với tôi, là một cán bộ triển khai, tôi rất hạnh phúc, đơn giản vì nó phù hợp với sở thích. Khi triển khai phần mềm tôi được đi nhiều nơi, được sống cuộc sống mà có thể tạm gọi là “chu du thiên hạ”. Tôi thích được tiếp xúc với nhiều kiểu người khác nhau, thích được người khác đánh giá về mình và trong những chuyến đi, tôi không quên nhìn trời nhìn đất, nhìn núi nhìn sông, nhìn cảnh sống cơ cực của người dân trên khắp mảnh đất hình chữ S.
Bình luận