Kỹ năng xử lý vấn đề

Trong loạt bài về kỹ năng mềm mình sẽ đi tiếp chủ đề thứ 2 : kỹ năng xử lý vấn đề. Những phần còn lại sẽ viết khi … rảnh (không biết khi nào 😀 )

1. Làm việc nhóm
2. Xử lý vấn đề
3. Giải thích – thuyết trình
4. Đàm phán
5. Tìm kiếm thông tin
6. Giao tiếp
7. Tự học

Nói sơ qua một chút vì sao mình cần phải viết trong khi đã có hàng tá các sách vở báo chí, thậm chí khoá học về các kỹ năng mềm này. Mình đã đọc khá nhiều nhưng tựu chung các bài viết – sách vở kia chỉ mang tính tham khảo, không học hỏi được gì nhiều cho nghề phần mềm cả. Các ví dụ mà họ đưa ra cũng không sát và thiên hướng lý thuyết, tính ứng dụng thực tế khá thấp, nói thẳng ra là toàn nói chuyện đạo lý. Không hẳn là sai nhưng để cho dân kỹ thuật đọc thì không hợp lắm. Sẽ không thể tìm thấy cách xử lý khi lỡ tay delete Database honban (bản chạy thật), cách phân task sao cho các dev không càm ràm, cách giảng hoà khi QA vứt cho Dev đống bug còn Dev ném lại ánh mắt dao cạo kèm một số câu DM (đời mà), hay như cách đàm phán với khách khi gửi Estimate mà có 1 công ty khác chào giá thấp hơn …

Đầu tiên mình sẽ phân loại thành 3 nhóm và luồng xử lý.

• Kỹ thuật
• Nghiệp vụ
• Giao tiếp

Luồng xử lý

Trước khi đi vào từng nhóm cụ thể, mình nói kỹ một chút về luồng xử lý.

• Đầu tiên phải thật bình tĩnh dù có rơi vào tình trạng nào đi chăng nữa, vì cuống cũng chả giải quyết được gì.
• Tiếp theo là chia vấn đề to thành nhiều cái nhỏ và xử lý từng cái. Các bạn cứ tưởng tượng là việc bẻ 1 nắm đũa nó cực khó, nhưng tách ra bẻ từng chiếc thì dễ hơn nhiều.
• Xác định xem thử có tự làm 1 mình hay cần phải gọi hội (trợ giúp).
• Đánh giá kết quả và xem xét có cách nào hay hơn không, với mỗi hướng cần xem thử lợi hại ra sao, cân đo đong đếm cẩn thận rồi quyết đoán chọn 1 cái, không dây dưa, sai thì sửa.
• Lưu nó vào kho kinh nghiệm bản thân để lần sau áp dụng lại.

Kỹ thuật

Trong mỗi giai đoạn sẽ có phát sinh vấn đề đặc thù riêng.

• Giai đoạn tiền triển khai : tức là giai đoạn điều tra trước khi development. Ta thường hay gặp nhất đó là việc lựa chọn giải pháp. Giữa 2 hoặc nhiều ngôn ngữ – framework – công nghệ nên chọn cái nào. Đối với từng loại thì ưu khuyết ra sao, làm sao để đưa suggest mà không bị reject (ăn quả bơ). Xử lý : trước tiên không phải là bắt tay vào làm ngay mà phải lấy được thật nhiều thông tin nhất có thể về hệ thống – về khách hàng – team offshore. Ví dụ : budget (ngân sách) khách có thể chi, mức độ chênh effort giữa các lựa chọn (phải estimate mới biết), thời gian triển khai, nhân sự bên mình mạnh cái nào nhất … Sau đó đưa ra 1 hoặc nhiều bản teian (proposal) để họ lựa chọn. Nếu cứ theo trình tự như vậy cho dù không xử lý được triệt để thì cũng giúp mọi người và cả bản thân đến gần nhất tới lời giải.
• Giai đoạn phát triển (development) : Hay gặp nhất là giải pháp xử lý các vấn đề kỹ thuật (bug là 1 trong số đó). Cách đây 7 năm mình từng gặp 1 bug về security, khách test hệ thống bằng cách áp dụng các mánh khoé của hacker để hack vào web system và họ hack được thông qua XSS (Cross-site scripting), nhiệm vụ đặt ra cần phải release trong ngày. Lúc đấy cuống thật, vì XSS là cái gì mình chả biết thì sao mà fix. Ông onsite lead thì bận xử vụ to hơn cái này nên mình phải gánh vác. Mình đã xử lý như sau :
  • Bình tĩnh lại, đọc đi đọc lại report bug vài lần và chắc chắn không bỏ sót cái gì.
  • Xác định xem có tự fix được không bằng cách search google và stackoverflow xem thử ai đã gặp cái này chưa, sau một hồi thì cũng đành tự nhục : 1 mình không thể làm nổi.
  • Tiếp theo : gọi hội :))) liên lạc phía technical lead ở VN và mô tả lại 1 cách cụ thể nhất, cộng với 1 vài thông tin đã tìm kiếm ra được để giúp tech lead rút ngắn thời gian điều tra. Sau đấy nhờ anh ấy estimate time fix.
  • Báo lại với khách về tình hình cũng như cam kết fix trong bao lâu = điều tra + fix + test
  • Nhận sản phẩm ở nhà và merge vào source staging (server test trước khi deploy thật), dùng jenkins build lại và tự tay test lại lần nữa cho chắc.
  • Report toàn bộ cho khách bao gồm : trình tự phát sinh, nguyên nhân, cách fix, phạm vi ảnh hưởng, phương án chống phát sinh.
  • Deploy lên môi trường honban => DONE
• Giai đoạn maintain : chủ yếu là fixbug và thêm bớt chức năng. Thường thì tất cả các vấn đề lớn về kỹ thuật đã được xử lý ở giai đoạn trước nên lúc này đa số là các task nhẹ. Nhưng có một điều đặc biệt phải cực kỳ cẩn thận : tránh bug degrade (fix 1 bug lòi 1 đống bug). Việc xử lý vấn đề nằm trọng tâm ở 2 chỗ : điều tra độ ảnh hưởng, thống nhất cách fix. Thêm một chú ý cuối là phải test lại cho cẩn thận, thường sự cố hay phát sinh ở bug nhỏ chứ không phải bug to, vì lúc đấy hay chủ quan.

Nghiệp vụ

Thực ra nghiệp vụ nó có 2 loại, loại liên quan đến kỹ thuật và loại không.

• Loại 1 : VD trên màn hình SEARCH, ở phần kết quả tìm kiếm khách muốn các item có thể di chuyển giá trị cell này qua cell khác bằng cách drag – drop. Cái đấy là liên quan kỹ thuật vì nó cần phải tính tới yếu tố ngôn ngữ – framework đó có hỗ trợ Drag – Drop Function ở Listview/Grid/Table hay không.
• Loại 2 : mặc dù cũng phải thêm sửa code nhưng ta không nên tính nó vào loại 1 vì liên quan chủ yếu về xử lý, không ảnh hưởng cấu trúc Library – cấu trúc project. VD thêm 1 vài item trong điều kiện search, ta chỉ cẩn thêm label – textbox ở front-end, thêm item cho DTO object, truyền thêm param vào SQL là đủ. Tức là bổ sung vào những cái đang có theo cách copy-paste.

Trong 2 loại trên thì loại 2 chỉ là task không nên xếp vào “vấn đề”. Còn loại 1 khá đau đầu vì cần phải qua trình tự nhiều bước giải quyết.

• Tìm hiểu
• Đánh giá và đưa ra phương án
• Họp bàn xem thử có nên làm hay không
• Estimate
• Re-Plan
• Triển khai
• Nghiệm thu

Giao tiếp

Để xử lý vấn đề giao tiếp, cách tốt nhất là không để các vấn đề xảy ra. Vậy bằng cách nào ?

Trong dự án, bất kể là product hay out-source, giao tiếp là yếu tố quan trọng nhất, là mạch huyết lưu thông giúp mọi thứ được vận hành trôi chảy. Nếu so sánh project với một thành phố thì giao tiếp chính là các trục đường, tắc đường chính là vấn đề và để giải quyết thì có nhiều cách nhưng muốn triệt để chỉ có cách qui hoạch thật tốt ngay từ đầu hoặc đập đi xây lại. Cái khó của thành phố là việc làm này cực khó, lịch sử tồn tại lâu đời với công trình – cầu cống – di tích là rào cản, nó giống như một dự án lâu đời vậy, trở ngại chính là những con người với thói quen vận hành cũ kỹ – thiếu hiệu quả nhưng ngại thay đổi, ngại đụng chạm.

Như một bài mình đã từng viết về handover dự án, nhảy ngang vào thì việc đầu tiên chính là giao tiếp, phải nắm thông tin và tạo dựng mối liên hệ (liên hệ chứ không phải quan hệ theo nghĩa xấu). Như việc bước chân vào thành phố mới lạ, giữ chắc tấm bản đồ là quan trọng nhất, sau đấy mới là tìm đường. Còn khi được xây dựng project ngay từ đầu, đấy là cơ hội tuyệt vời mà mỗi BrSE phải biết quí trọng và nắm lấy. Qui hoạch các trục giao tiếp lớn, các nhánh giao tiếp nhỏ, phân tầng phân lớp bài bản để 1 thông tin từ điểm A tới điểm N phải đi theo một cách nhanh và chuẩn xác nhất.

Trên là lý thuyết, còn tiếp theo đây là thực tế. Trong một dự án out-source có 3 trục giao tiếp chính theo kiểu tam giác : Khách hàng – Onsite, Onsite – Offshore, Khách hàng – Offshore. Trong đó sẽ có các nhánh nhỏ : nội bộ khách hàng, nội bộ team onsite, nội bộ offshore. Hoặc có khi còn phân lớp theo chức năng : FrontEnd (Khách-Onsite-Offshore), BackEnd (Khách-Onsite-Offshore), Infra(Khách-Onsite-Offshore).

• Về xử lý vấn đề “chuyện đã rồi”. Khi gặp một sự cố phát sinh, ví dụ : khách nghiệm thu chức năng A, nhưng kết quả release lại là A’, lý do là việc truyền tải yêu cầu bị sai ngay từ đầu, có thể do khách mô tải aimai (dễ nhầm), dẫn đến BrSE (onsite) hiểu sai, offshore làm theo và kết quả khác với mong muốn. Cách xử lý đó là điều tra, phân vùng trục giao tiếp, giống kiểu xem thử vụ đụng xe xảy ra đường nào trong thành phố, vì đèn báo giao thông sai hay do người tham gia phóng nhanh vượt ẩu. Thấy sai ở đâu sửa ở đó, cách chống phát sinh thì nhiều nhưng thứ mà mình hay áp dụng đó là evidence cho những yêu cầu lớn. Đó có thể là tài liệu, mail, chat hoặc bất kỳ thứ gì mà 3 bên đều kiểm chứng được.
• Về xử lý vấn đề “nóng” theo kiểu tức thời. Trong buổi họp, khách yêu cầu làm thêm 1 vài chức năng “nhỏ” (khách nghĩ), nhưng ở nhà lại nhất quyết không chịu làm vì thấy nó “không nhỏ” cộng thêm mấy tuần rồi anh em OT triền miên, không muốn ôm thêm. Cả 2 bên căng thẳng, không ai chịu nhường ai. Nếu đứng giữa bạn phải làm gì ? đây là câu hỏi mở, nếu hiểu kỹ những điều mình viết ở trên bạn sẽ tự trả lời được.

Kết

Bài dài quá aaaaaaaa… viết mấy ngày mới xong. Mà cũng chả xong được cái gì. Vấn đề là muôn màu muôn vẻ, các cụ có câu khá hợp : muôn hình vạn trạng. Vậy nên cách xử lý nó cũng … không cái nào hoàn toàn giống nhau. Nhưng trên tất cả đó là luồng xử lý, thứ duy nhất phải tuân thủ dù trong hoàn cảnh nào. Nếu ta dựa theo cách làm việc đó, mọi thứ đều có thể được giải quyết (có thể êm đẹp hoặc không). Và điều quan trọng là phải chấp nhận đối mặt với kết quả (có thể là hậu quả). Vì chỉ thế mới nhanh trưởng thành lên được.

Các bạn có thắc mắc vì sao người ta thường hay tuyển yêu cầu người có kinh nghiệm ? cái kinh nghiệm mang lại cho họ những gì mà người ta cần đến vậy. Đó chính là sự khác nhau giữa người biết và người chưa biết. Đối với 1 sự việc, người cứng sẽ cho đó là 1 task bình thường, trong đầu đã có luồng đối ứng, còn amater thì thấy 1 đống bùi nhùi, không biết phải làm gì. Cái kinh nghiệm này không hẳn là số năm làm việc, 10 năm làm là 10 năm kinh nghiệm hay 1 năm kinh nghiệm lặp lại 10 lần ? câu này các bạn tự trả lời.