IT Leader - a.Hoang Ngoc Dieu.

IT leader nghiêng hẳn về phía technical và thiếu những kỹ năng quản lý doanh nghiệp thường bị cái bệnh kinh niên là khoái "đồ chơi" mới để vọc, thậm chí để... khoe (còn dạng đốc lô, xúc để mua đồ "xịn" nhằm "cắn" vài phần trăm bỏ túi thì loại này khỏi phải nhắc đến). Dạng IT leader này quên hẳn mục tiêu của doanh nghiệp là tạo ra GIẢI PHÁP hình thành hệ thống và công cụ mạnh mẽ, hiệu suất nhưng ít tốn kém, ít hư hao nhất chớ không phải là chỗ xài tiền để "sắm đồ chơi" .

IT leader nghiêng hẳn về phía quản lý thường xem nhẹ vai trò của công nghệ đối với doanh nghiệp. Họ thường nghĩ rằng những chi phí cho IT là "gánh nặng" chớ không phải là nhu cầu cần thiết. Dạng IT leader nghiêng về quản lý thường bị sức ép tiền bạc và các xếp ở trên "đè xuống" cho nên lắm lúc họ tìm cách làm vui lòng cả làng bằng cách cắt xén làm sao để nhìn cho "đẹp mắt" và vô tình tạo ra những vấn đề khó khăn lâu dài.

Vậy, mẫu người IT leader một cách lý tưởng cần gì? Theo tôi thấy và đã rút tỉa sau nhiều năm làm việc thì mẫu người ấy nên là như sau:

1. Họ cần hiểu rất rõ nhu cầu (requirements). Hiểu càng cụ thể, càng tường tận càng tốt. Họ không nên tưởng tượng, giả định và ngộ nhận về requirements vì đó là điểm trọng yếu dẫn đến thất bại và tốn kém về sau.

2. Họ cần cân bằng và chính xác giữa tài nguyên (nhân lực, tiền bạc, thời gian) và nhu cầu. Cân bằng giữa technology và chuyện tiết kiệm hoặc lợi nhuận của doanh nghiệm không thì sẽ bị đi đến chỗ què cụt trong giải pháp hoặc quá sức lãng phí.

3. Họ cần đặt mình vào vị trí mỗi thành viên mà họ quản lý. Hiểu rõ cá tính, thói quen, điểm yếu, điểm mạnh của thành viên để có thể giao phó những công việc và trách nhiệm khác nhau cho phù hợp bởi vì không phải ai cũng như ai. Nếu IT leader thiếu hụt mảng "con người" trong công việc thì kết quả lúc nào cũng khó mà trọn vẹn và tốt đẹp.

4. Họ cần có tầm nhìn gần và xa. Nắm được chiến lược và chiến thuật làm kinh tế của doanh nghiệp để hình thành những giải pháp hỗ trợ cho doanh nghiệp một cách sâu sát thay vì chỉ nhìn vào nhu cầu trước mắt, dẫn đền tình trạng "giải pháp" bị... chết non.

5. Họ cần hình thành hoặc làm việc với mọi người để hình thành GIẢI PHÁP thay vì dựa vào các SẢN PHẨM. Lắm IT Leader nhầm lẫn "sản phẩm" là "giải pháp". Sản phẩm chỉ là cấu thành của giải pháp và không bao giờ là giải pháp.

6. Họ cần trung thực và nghiêm khắc với chính mình và với mọi người. Bất cứ khi nào họ lâm vào chỗ giả vờ hoặc che đậy những thiếu sót, những sai lầm thì ngay lúc đó họ đã thất bại. Một công trình chỉ có thể thành công nếu những sai sót được xác định đúng lúc và điều chỉnh đúng mức.

7. Họ cần hiểu "leader" không phải là tước hiệu mà là TRÁCH NHIỆM. Họ chính là người cần dẫn dắt, giúp đỡ và cần có trách nhiệm với mọi sự việc và với mọi thành viên chung quanh họ chớ không phải là ai khác.

8. Họ cần tin tưởng và tôn trọng vào khả năng của mọi người. Đừng đối xử các thành viên như những con số hoặc những cỗ máy bởi vì IT không phải là thế giới vô cảm mà nó cần sáng tạo, cần sức sống rất nhiều.

==============================

Vậy, từ 8 điểm trên, mình có thể rút tỉa ra tính chất (hoặc phẩm chất) của một IT leader lý tưởng gồm có:

- hiểu.
- cân bằng.
- chính xác.
- tự đặt mình.
- tầm nhìn.
- hình thành.
- trung thực.
- nghiêm khắc.
- tin tưởng.
- tôn trọng.

Trong đó, hầu hết những phẩm chất đều nghiên về nền tảng đạo đức, về khả năng tự chủ, công bằng và nhân hậu. Chỉ có 3 kỹ năng chuyên môn cần đào luyện:

1. Hiểu: cái này đòi hỏi khả năng đọc, tư duy, phân tích. Từ đó mới đưa ra và phát huy kỹ năng tiếp theo.

3. Chính xác: cái này đòi hỏi tinh thần khoa học, tính tỉ mỉ và kiên nhẫn. Kỹ năng này cần đào luyện rất nhiều qua công việc và những va chạm thực tế. Kỹ năng này cần phẩm chất trung thực và nghiêm khắc hỗ trợ. Không thì khó chính xác.

2. Tầm nhìn: cái này là kỹ năng mang tính "strategic", có nghĩa là đào luyện cho mình khả năng hình thành giải pháp có độ dày và độ dài. Kỹ năng này cần "hiểu" và "chính xác" hỗ trợ rất nhiều. Nếu không thì "tầm nhìn" bị rơi vào chỗ cảm tính.


=====================================

CIO chỉ ra rằng, 8 kỹ năng mà một CIO - chính là IT leader - cần đều không phải là kỹ thuật.

1. Know Your Leadership Style
2. Focus on Strategic Communication
3. Learn How to Develop Talented High-Performance Teams
4. Develop a Strong Technology Strategy
5. Understand Complex Business Problems
6. Know How to Lead in a Crisis
7. Be Able to Market IT to the Business
8. Know the Corporate Culture and Be Willing to Change It 

=================================

"1. Sự khác nhau, ranh giới giữa skills: technical, management, business và leadership."

Một cách thuần tuý định nghĩa thì:

- technical: thuần tuý kỹ thuật.
- management: thuần tuý quản trị.
- business: thuần tuý thương nghiệp.
- leadership: thuần tuý cấp lãnh đạo.

Một IT leader có thể bao gồm cả bốn cái ở trên và tuỳ vị trí, cái này có thể nhiều hơn cái kia.

Một CIO (chief information officer) chiếm đa số business + leadership + management và một phần nhỏ technical. Ở vị trí này, technical skill của họ thường rất broad và high level ("high level" có nghĩa là tổng thể, đối nghịch với "low level" có nghĩa là đào sâu).

Dưới CIO có thể có nhiều leaders và mỗi leaders có thể có tính năng và trách nhiệm chuyên biệt. Có những leader có đa số là technical và thiểu số là business + leadership focus. Dạng này là dạng technologist. Có những leaders nghiêng hẳn về strategic và business và ít focus đến technical. Dạng này là dạng strategist.

Thông thường những doanh nghiệp nhỏ thì IT leader kiêm nhiệm cả bốn. Những doanh nghiệp lớn thì tách rời và có focus cụ thể 1 hoặc 2 cái ở trên.

2. Thước đo về "performance" và "capability" của một leader khá phức tạp và thường dựa vào kết quả của các công trình + phản hồi của những cá nhân làm việc với leader ấy. Thông thường, mỗi leader và mỗi member có một cái KPI (key performance indicator) cụ thể từng phần một. Cái này do xếp của leader hoặc một uỷ ban nhân sự của doanh nghiệp đưa ra. Ví dụ dựa trên từng criteria cụ thể:

1. Profit & Financials (bao nhiêu %)

2. Technical performance and benefits (bao nhiêu %)

3. Risks and prevention (bao nhiêu %).

4. Business compliance (bao nhiêu %)

5. Leadership performance (bao nhiêu %).

6. Communication and strategy (bao nhiêu %).

7. Projects and deliverables (bao nhiêu %).

Trong mỗi category có những phần cụ thể đánh giá performance và quality. Những cái này chỉ có cái khung chung chung và mỗi doanh nghiệp cần đặt ra tiêu chí và mục tiêu để hình thành KPI một cách cụ thể.

Process đánh giá thì có thể thực hiện theo quý, theo nửa năm và trọn năm. Đánh giá thì có thể từ nhiều tầng khác nhau (từ xếp xuống đồng sự, xuống nhân viên).  

========================================================

"kỹ năng phân tích không phụ thuộc vào vai trò của IT thế nào nhưng IT Leader sẽ là người ảnh hưởng trực tiếp doanh nghiệp có năng lực đó hay không. Em nhấn mạnh "năng lực của doanh nghiệp", ý muốn nói kỹ năng đó hiện diện khắp nơi trong doanh nghiệp tùy mức độ khác nhau.

Đây một ý cụ thể cho phần câu hỏi của em là "8 kỹ năng đó ảnh hưởng lên các bộ phận đó thế nào?""

----------------

Có lẽ các điểm 1, 2, 4 và 6 hàm chứa những đụng chạm đến analytics.

Để một IT Leader có sự chính xác và tầm nhìn thì anh ta cần phải dựa vào những thông tin và phân tích khoa học và thông tin + phân tích khoa học thì phải đi từ analytics. Chính bản thân anh ta đã có kỹ năng nhận định tình hình một cách tổng quát và có sự nhạy bén trước tình hình rồi. Analytics xuyên qua công cụ hay bất cứ phương tiện nào giúp confirm nhận định tổng thể bằng những con số cụ thể.

Riêng với câu hỏi "8 kỹ năng đó ảnh hưởng lên các bộ phận đó thế nào?" thì phải nói là sự ảnh hưởng trực tiếp và mạnh mẽ nhất là chất lượng công việc và thời hạn hoàn tất công việc được mang lại do 8 đặc tính (không phải 8 kỹ năng, vì trong 8 đặc tính đó có nhiều kỹ năng).

Ví dụ cụ thể hơn, 1 IT manager chịu trách nhiệm một software development division và có requirement là phải release ít nhất là 3 release mỗi quý (chẳng hạn) và giữa mỗi release phải đáp ứng những bug fixes nghiêm trọng, có ưu tiên cao. 8 tính chất kia giúp cho anh ta

- hiểu rõ độ phức tạp và khó khăn của nhu cầu.

- hình thành được chiến lược dàn trải tài lực, nhân lực làm sao cho khoa học và thích hợp. Sắp xếp làm sao để đáp ứng release định kỳ và bug fixes bất định kỳ mà không bị trễ nãi, không đòi hỏi thêm nhiều nhân lực

- không đòi hỏi thêm nhiều máy móc (ngoại trừ trường hợp anh ta justify được lý do một cách cụ thể).

- bảo đảm được chất lượng release xuyên qua cơ chế kiểm soát chất lượng.

- thông cảm và chia sẻ với sức ép công việc để bảo đảm sự đóng góp thật sự của thành viên (ngoài chuyện lương phạn).

- đi sát với thực tế và tiên đoán mức phát triển gia tăng theo tính năng của software gia tăng, nhu cầu thị trường gia tăng.

..v.v...

Tất cả những thứ ấy nhằm mang lại 2 thứ:

1. Chất lượng sản phẩm.
2. Giá thành ổn định.

=================================================

 

KĨ NĂNG LẤY YÊU CẦU CỦA NGƯỜI DÙNG/KHÁCH HÀNG (copy)

KĨ NĂNG LẤY YÊU CẦU CỦA NGƯỜI DÙNG/KHÁCH HÀNG (tham khảo)

 nhân có vài bạn đặt vấn đề kĩ năng mềm của môt IT manager, CIO,... mình muốn bàn về việc lấy user requirements, mà theo mình nó vận dụng được nhiều kĩ năng mềm của một người hành nghề CNTT.

<< entry này sẽ dài, bạn nào ngán đọc dài xin bỏ qua cho. >>

dù là một kĩ sư phần mềm, một người thiết kế PM, một người cung ứng giải pháp PM, một IT manager, hay chí đến một CIO/CTO thì yêu cầu của người dùng (hay khách hàng) đều là đầu mối để chúng ta làm việc, để đáp ứng lại bằng một (hệ) giải pháp. người dùng có thể rât khác nhau đối với các chức năng tạm kể ra bên trên, nhưng làm sao để nắm bắt được các yêu cầu của những đối tương ấy vẫn là trách nhiệm quan trọng của người hành nghề CNTT.

trong nhiều hoàn cảnh, một số người làm CNTT ở VN hiện nay (có thể ở nhiều chức vụ khác nhau) nhận các đặc tả yêu cầu người dùng (user requirements spec.) hay thâm chí đặc tả các thiết kế giải pháp từ người khác. khâu thu thập và lập văn bản các yêu cầu người dùng vì thế được/bị bỏ qua. đó là một thuận lợi ngắn hạn nhưng lại là một thiệt thòi trong dài hạn đối với người hành nghề CNTT. vì lẽ, việc thu thập yêu cầu người dùng là một công đoạn khó khăn và đòi hỏi nhiều bản lĩnh trong toàn bộ chu trình phát triển giải pháp CNTT (và có thể nói, tương tự cho nhiều ngành nghề khác, nhưng ở đây xin thu hẹp trong khung CNTT).

**

một trong những phản ứng “tê tái” nhất mà người nộp kết quả giải pháp phải đón nhận là câu phán: “đây không phải là giải pháp tôi đang mong đợi, tôi đâu có cần cái này? bạn đã làm sai ý tôi rồi!”. úi. và trong kinh nghiệm của ngành nghề này, câu phán đó không phải là điều hiếm khi được nghe.

và hầu như đa phần các trường hợp dẫn đến kêt quả ấy là do khâu lấy yêu cầu người dùng đã không được làm tốt. trong kinh nghiệm bản thân hành nghê và kinh nghiệm làm huấn luyện đào tạo mình có nhận xét: người làm kĩ thuật càng có nhiều "kinh nghiệm kĩ thuật" lại càng dễ có nguy cơ gặp khó khăn khi lấy yêu cầu người dùng, nếu bản thân người ấy không nắm vững các phương pháp để lấy yêu cầu, mà trong đó việc tự "trấn áp" cách nghe, cách hiểu, cách nói, cách tiếp thu vấn đề "rất i tờ" của mình. vấn đề và các trở ngại thì nhiều, do đó, sau nhiều năm chiêm nghiệm, người ta đã đưa ra cả một chuyên ngành về “yêu cầu người dùng”. các bạn quan tâm có thể thử nhờ bạn Google truy tầm qua chủ đề “user requirements”, hoặc chính xác hơn, “requirements engineering” để có thể có được những thông tin, tài liệu liên quan đến chủ đề phức tạp này. nó cũng cho chúng ta thấy mức độ quan trọng và số vốn trí tuệ và kinh nghiệm hiện được thu thập và hệ thống hóa chung quanh chủ đề này ra sao.

ở đây, mình chỉ mong khơi gợi vấn đề, và kêu gọi được sự quan tâm của các bạn đồng nghiệp mới vào nghề, hoặc chưa có cơ hội đối mặt và quan tâm đủ với các thử thách của công việc thu thập yêu cầu người dùng. mình cũng chưa nói đến việc hiểu, phân tích và sau đó là đáp ứng lại với các yêu cầu ấy. hiện nay, ngành software engineering đã đủ trưởng thành đề hệ thống hóa các qui trình, và ngay cả các loại tài liệu, artifacts cần được tạo ra trong suốt các qui trình ấy. ngay cả với các phương pháp agile, một cách này hay cách khác người ta cũng sẽ phải đề cập đến “user requirements” và phương pháp thích hợp để ứng phó với v/đ này. << minh không nhằm đi vào chi tiết của các phương pháp ấy ở đây. các tài liệu, sách vở giáo khoa liên quan sẽ đầy đủ, khúc chiết và có hệ thông hơn những gì mình có thể ghi nhanh ở đây.>>

**

một điều mình cũng thường được nghe (và phần nào trải nghiêm): “lắm khi người khách hàng cũng không biết họ cần/muốn gì.” ở các xã hội mà việc sử dụng CNTT càng giới hạn thì câu này càng được nghe nhều hơn. chắc phải có phần nào sự thật trong ấy.

tuy nhiên, cho phép mình nhận xét vấn đề này ở một góc khác. thường, câu nhận xét trên "đúng" là do chúng ta muốn nghe người khách hàng cho ta biết về cái “giải pháp” mà họ nghĩ là họ cần; và như thế thì họ sẽ bí. đàng khác, người dùng thường phải có một thứ nhu cầu. một thứ vấn đề, nên họ mới cần nói chuyện với chúng ta. cho nên, nếu ta cố tìm cách để nghe cái nhu cầu, những trở ngại, khó khăn ấy (qua tầm nhìn và ngôn ngữ nghiệp vụ của họ) thì cơ hội được nghe họ nói sẽ nhiều hơn. còn “giải pháp” là thứ rồi đây, qua làm việc (có khi gian khổ, nhọc nhằn) với họ, và dựa trên tri thức chuyên môn của người làm CNTT chúng ta hi vọng hình dung ra, thiết kế ra và thực hiện được giúp họ. bỡi thế, hỏi họ “cần gì” trong ý nghĩa “giải pháp” có thể họ sẽ không nói (rõ ràng) được, nhờ họ mô tả tình huống khiến họ ới đên CNTT thì có cơ khá hơn.

<< về phương pháp và công cụ, sách vở sẽ cho chúng ta nhiều cách hiệu quả để đáp ứng với cái nạn "người dùng ko biết họ muốn gì". >>

cũng cần nói thêm, sẽ có những người khách hàng (hoặc người thay mặt cho khách hàng -- thí dụ: bà con marketing, sales, hay product planning :)) sẵn sàng, hồ hỡi đưa ra yêu cầu của họ ở dạng giải pháp. đây thường là một điều đau đầu khác. vì một người dùng / khách hàng có thể sẽ đưa ra một thứ giải pháp sai, hoặc phiến diện, hoặc không thích hợp với những nhu cầu thật sự mà họ đang gặp phải (chưa nói các yếu tố công nghệ, hệ thống, v,v,). nếu người nhận yêu cầu không khéo léo và tinh tế kéo người khách hàng quay về được chính các "yêu cầu thật" của họ thì mối nguy đôi bên sẽ dắt tay nhay đi xuống một lộ trình không mấy sáng sủa. giải pháp ở đầu ra có nguy cơ giải quyết một loại yêu cầu... khác.

các giáo trình, tài liệu về requirements engineering sẽ chi li hơn, đầy đủ hơn về các tình huống và các phương áng (cũng như công cụ, phương tiện) để ứng xử các tình huống ấy, mình xin không bàn thêm. chỉ xin tạm kết: kĩ năng thu thập yêu cầu của người dùng là một kĩ năng rất quan trọng, nó vận dụng nhiều loại kĩ năng mềm của người làm CNTT. tìm hiểu, học tập và rèn luyện các kĩ năng ấy để hoàn thành tốt công đoạn lấy yếu cầu này là một trong những bước cần quan tâm của một người hành nghề CNTT muốn đi xa.

mình sẵn sàng trao đổi thêm với các bạn quan tâm hay có kinh nghiệm khác hơn.