Lột trần sự thật về PMO

Trong ngành phần mềm nói chung thì hầu hết mọi người đều quen thuộc với một cái job title là PM ( Project Manager ) tuy nhiên không phải ai cũng nghe đến khái niệm khác có họ hàng dây mơ rễ má đến nó là PMO và hiểu về  nó một cách chính xác lại càng ít hơn vì thường PMO chỉ xuất hiện ở các tổ chức và cty lớn tầm cỡ Enterprise, với một ngành phần mềm chủ yếu gồm các SME doanh nghiệp quy mô vừa và nhỏ như Việt Nam thì muốn gặp voi thì phải ra thủ đô HN hoặc đại đô thị SG vào sở thú mới xem được chứ cứ ở tỉnh lẻ thì tuyệt nhiên là không.

Nhưng với “tinh thần nghé non không sợ hổ”, “thuyền đua thì lái cũng đua, bè ngổ đi trước bè dừa theo sau” tuy là công ty bé thôi nhưng SotaTek cũng không ngán gì mà không đú theo các bậc đàn anh lớn khác trong làng IT lập ra PMO cho nó hoành, nhăm nhe mở sở thú ở tỉnh lẻ để dân tình cũng được ngắm voi.

Tính đến nay PMO đã đi vào hoạt động ở SotaTek được khoảng hơn một tháng nên mình nghĩ cũng nên có một bài viết về PMO để thông ruột cho các anh em chẳng may bị lôi kéo vào cái “tổ chức băng đảng” này không cảm thấy băn khoăn và đồng thời cũng là chia sẻ với mọi người kiến thức về một mô hình quản lý được áp dụng khá phổ biến trong giới IT.

WHAT? PMO là gì

PMO-Văn phòng quản lý dự án, vốn là từ viết tắt của từ Project Management Office , một khái niệm được xuất hiện trong PMBOK®Guide ( Project Management Body of Knowledge ) tức là tài liệu hướng dẫn về các kiến thức cốt lõi trong quản lý dự án. Đây là một đơn vị tập trung (centralizes) nhắm tới mục đích chuẩn hóa (standardizes) việc quản lý dự án của tổ chức. Cụ thể ở đây là chuẩn hóa các quy trình quản lý dự án, tạo điều kiện thuận lợi cho việc chia sẻ các nguồn lực bao gồm cả nguồn lực cứng ( nhân sự ) và nguồn lực mềm ( phương thức, công cụ và kỹ thuật ) cho đội dự án. Trách nhiệm của PMO có thể bao hàm từ việc hỗ trợ dự án cho đến việc đảm nhiệm trực tiếp quản lý một dự án tùy theo cách bố trí của từng công ty khác nhau.

WHY? Vì sao trời đã sinh Du lại còn sinh Lượng

Chắc đến đây thì mọi người cũng sẽ thắc mắc, tại sao đã có PM rồi lại còn đẻ ra PMO. Để trả lời về chuyện sinh đẻ chắc chắn là phải tìm hỏi …thằng bác sĩ  và thằng cha bác sĩ đó là một gã người Mẽo tên là Frederick Taylor được coi là cha đẻ của kỹ thuật quản lý sản xuất hiện đại giới thiệu lần đầu tiên cách đây hơn 1 thế kỷ trước. Mọi dây chuyền sản xuất hiện đại từ nhà máy của gã công nhân thất học Henry Ford vớ được bí kíp Taylor trở  thành vua ô tô đến nhà máy sản xuất nước ngọt Number One của Dr Ruồi học cao hiểu rộng gì rốt ráo cũng đều nhất nhất áp dụng lý thuyết quản lý của cha này hết. Tổ chức PMO được lập ra đầu tiên trên thế giới là một đơn vị mang tên Project Office được lập ra bởi U.S. Air Corps vốn là tổ chức tiền thân của không lực Hoa Kỳ ngày nay, đơn vị này được lập ra để quản lý việc chế tạo máy bay chiến đấu. Đọc đến đây chắc mọi người cũng hình dung được về mức độ quan trọng của đơn vị này, bởi vì ở thời điểm đó thì lĩnh vực công nghệ phức tạp và khó khăn nhất là công nghệ hàng không và công nghệ vũ khí, máy bay chiến đấu lại là sự hội tụ của 2 công nghệ này nên sự phức tạp và khó khăn càng tăng lên gấp bội. Lúc đó thì chẳng có thánh PM nào đủ sức cân nổi loại hàng khủng như thế này nên tất nhiên phải đẻ ra PMO tức là một cơ cấu có khả năng huy động sức mạnh tập thể về năng lực quản lý đáp ứng được các yêu cầu về vận hành các dự án khó nhai.

Tuy nhiên thì nhiều năm sau đó mô hình PMO cũng không được phổ biến rộng rãi ở Mỹ và mà chỉ đến khi sang đến xứ Phù Tang nó mới trở thành một mô hình hấp dẫn và có sức ảnh hưởng. Cũng như mô hình sản xuất tinh gọn Lean Manufactoring ra đời ở Mỹ nhưng lại trở nên nổi tiếng nhờ các công ty Nhật và tiên phong là Toyota thì PMO cũng trở nên nổi tiếng và phổ biến bởi các doanh nghiệp IT Nhật Bản. Mô hình PMO bắt đầu được chú ý khi người ta nhận ra tỉ lệ thành công của các dự án IT ở Nhật là rất thấp. Theo điều tra của ITPro tại thời điểm 2008 thì tỉ lệ thành công của các dự án ở Nhật chỉ khoảng 31.1%  và trong một báo cáo trước đó vào năm 2005 tỉ lệ còn thấp hơn là 26.7%. Tuy rằng có sự biến động không đáng kể nhưng người ta nhận thấy có sự tiến bộ ở một số công ty trong việc đưa các kế hoạch quản lý mang tính định lượng (定量管理) vào trong các dự án. So sánh giữa 2 nhóm công ty, một nhóm không áp dụng các phương pháp quản lý định lượng thì tỉ lệ thành công của các dự án chỉ là 24.3% trong khi đó thì tỉ lệ này ở các công ty quản lý bằng phương pháp định lượng lại là 45.6% tức là cao gần gấp đôi so với các công ty kia.

Và mấu chốt để có thể thực hiện việc áp dụng quản lý định lượng lại nằm ở các tổ chức PMO vì đây chính là cơ quan thi hành cũng như cân đo đong đếm số liệu tương quan của các dự án trong một công ty. Đây cũng là lý do mà PMO còn có 1 tên gọi khác nữa là Portfolio Management Office.

Hiểu một cách nôm na là thế này. Trước đây các dự án được quản lý một cách đơn lẻ được vận hành với Project Team và PM không có liên hệ gì với nhau cả thì bây giờ sẽ có một tổ chức là PMO bao gồm các Project Management Officer đóng vai trò hỗ trợ cho các dự án thông qua việc thống kê, đo đạc phân tích số liệu các dự án cũng như cùng nhau chia sẻ về các know-how, best practice của các dự án với nhau. Các ông Officer thì có thể là gồm các các PM của các dự án được lôi vào đây ngồi chung cùng với các ông executive của công ty để align về các mục tiêu, định hướng và nguồn lực phát triển của doanh nghiệp hoặc cũng có thể là các PMOers chuyên nghiệp chỉ đóng vai trò trung gian giữa 2 nhóm kia. Trong các tổ chức lớn thì số lượng các PMOers chuyên nghiệp này càng nhiều, thường ban đầu họ sẽ là PM quản lý trực tiếp dự án rồi sau đó có nhiều kinh nghiệm đẩy lên một level nữa để làm PMO với vai trò bao quát hơn, cùng một lúc hỗ trợ cho các PM và các project cụ thể.

Vì nhận thấy những lợi ích này của PMO nên mô hình này được các bạn Nhật Bản phát huy tối đa và nó trở nên phổ biến và mạnh mẽ hơn, các bạn Nhật có một cái năng lực vô đối đấy là copy nhưng không chỉ paste, cái gì các bạn ấy copy xong như bonsai, võ thuật, gấp giấy, pha trà đến PMO thì các bạn ấy đều nâng tầng nó lên một level cao hơn và sau một vòng quay thì thế giới lại đi copy của các bạn ấy cái sản phẩm đã nhét thêm giá trị gia tăng đó.  Ảnh hưởng từ các doanh nghiệp lại tác động ngược trở lại thế giới và có nhiều tổ chức và cty trên thế giới áp dụng mô hình PMO hơn.

Và sở dĩ người Việt chúng ta có cơ duyên chém gió với nhau về PMO cũng là vì Việt Nam bây giờ được coi là sân sau về outsourcing hàng đầu trong ngành IT của Nhật và một trong  những công ty đi tiên phong mở cửa làn sóng outsource của Việt Nam sang Nhật chính là trym đầu đàn FPT đã nhanh tay copy paste về triển khai ở Việt Nam, và tất nhiên SotaTek thì cũng đang copy của FPT nhưng cố gắng học theo tinh thần Nhật Bổn là không chỉ paste mà có chém gió thêm để mọi người hiểu về PMO ở một tầng mức cao hơn, lĩnh hội được cả về trảm phong thần chưởng nữa chứ không chỉ là quản lý dự án đơn thuần.

HOW-PMO vận hành như thế nào? Rốt cuộc là chúng mày làm cái giề?

Cụ thể thì băng nhóm PMO sẽ làm nhiệm vụ bảo kê cho các dự án bằng một số “hành vi” như sau

Supportive: PMO cung cấp templates quản lý dự án, policies, methodologies, Lessons Learned độ dự lý dự án. Trong thực tiễn ở SotaTek thì có thể list ra vài case study như là:

Đồng chí Robert(dung.nguyen) estimate cho dự án khách hàng đang thả thính hơi cao. Xong rồi khi đồng chí Teddy(thanh.nguyen) gửi cho khách hàng dù đã có bóp lại số liệu cho khiêm tốn hơn thì vẫn bị chê đắt khách say goodbye luôn, đồng chí Teddy về hậm hực cấu véo đồng chí Robert nguyên nhân gây ra hụt ăn, thì đồng chí Robert bảo đấy là em estimate cả phần test vào thì đồng chí Teddy bảo thôi chú để anh gửi cho cái template anh tạo sẵn rồi, chỉ cần estimate cho effort development thôi còn theo tỉ lệ % của template nó sẽ tự nhân hệ số mà ra effort cho cả test nữa.

Hoặc team MG bị khách hàng đặt chỉ tiêu định lượng về tính số point cho các task trong tuần, mỗi tuần phải đạt 10 point chẳng hạn, trong report của dự án trước khi họp đồng chí Maxwell(manh.nguyen) chỉ report số point trung bình cho cả team nhưng không report cho từng người thì sẽ bị nhắc phải report cho từng người vì khách hàng đặt chỉ tiêu cho cá nhân chứ không phải cho đội để đảm bảo sau 3 tháng thống kê con số trung bình phải đạt được 10 point/tuần.

Controlling: PMO dạng thức này tác động cao hơn mức trên là ngoài support ra, PMO còn phải thực hiện hướng dẫn cách quản lý dự án, cách sử dụng các phần mềm quản lý dự án, thậm chí hỗ trợ vận hành các công cụ quản lý dự án đặc thù phục vụ yêu cầu dự án. Ví dụ cụ thể là dự án Banana Show do thiếu người nắm vững cách code vue.js nên code chưa thật ngon thì đồng chí Herry(hung.pham) đề nghị bổ sung thêm người vào hỗ trợ, đồng chí Maxwell sẽ involve trực tiếp vào việc review code cho team member để Henry có thể giảm được workload và control được chất lượng dự án.

Directive: PMO kiểu này có tác động đến việc quản lý dự án ở mức độ cao nhất, PMO phân bổ mỗi dự án một Project Manager riêng biệt và chịu trách nhiệm kết quả dự án đó, dự án đây có thể có quy mô lớn hay nhỏ đều dưới sự quản lý của PMO. Ví dụ là ở SotaTek hiện đang có dự án hot và vô cùng quan trọng là dự án Vãi Cả Cơm (VCC) siêu to thì hiện tại cả 4 founder  là các đồng chí Tyler(tuyen.luu), Wiliam(phuc.nguyen) và Andy(an.nguyen) cũng như Richard(thanh.tran) phải trực tiếp nhảy vào lead các đối ứng khách hàng, phần web, mobi, blockchain trong dự án luôn và bốn hiệp khách này phải phối hợp với nhau.

Nói chung thì PMO là một stakeholder dính máu ăn phần trong các dự án và tùy mức độ béo bở của dự án mà PMO muốn chui vào sâu hay muốn ra sớm và khi nào thì rút ra kịp và rút không kịp để đến mức dự án cháy đen như bánh mỳ và member thì chết ngả rạ như hồng quân Liên Xô để lại hậu quả là một bầu tâm sự không biết đến bao giờ mới nguôi ngoai.

Để có cái năng lực cao chạy xa bay đúng lúc nơi kịp thời sơ tán như vậy hẳn nhiên PMOers khinh công phải giỏi, đào tường khoét vách cũng phải có nghề. Theo chuẩn nghề mà bọn thuật sĩ giang hồ vẽ ra cho PMOers thì đại khái có mấy công phu sau

  • Kiến thức vê lĩnh vực IT nói chung phải rộng còn kiến thức đặc thù về quản lý dự án hải hiểu sâu còn về domain dự án cũng phải nắm được tương đối vững để có thể nói chuyện được với các bên liên quan khác nhau, tích hợp các quan điểm đó lại với nhau để đưa ra phương pháp đúng về quản lý dự án
  • Excel/Word/PowerPoint phải Pro. Ngày xưa đám sĩ tử đi thi coi văn phòng tứ bảo là bảo bối thì bây giờ mấy thứ này chính là văn phòng tứ bảo của PMO, ông làm template, quản lý định lượng phân tích số liệu để quản lý định lượng và đem đi present chém gió show hàng cho mọi người hiểu về methodology về know how với best practice của dự án mà không thạo mấy cái này thì vứt.
  • Năng lực communicate ngon. Đại khái phải biết chém gió cấp 12 vì trong quá trình quản lý dự án phức tạp đòi hỏi có sự trao đổi thường xuyên liền mạch để nắm vững các thông tin không nhất quán từ nhiều view khác nhau, vừa phải biết giải thích cho PM và team dự án hiểu về những pháp pháp hiệu quả mới có thể áp dụng tăng năng suất công việc.
  • Kinh nghiệm thực chiến trong phát triển dự án. Thường thì của công việc PMOers  cũng không còn đòi hỏi cần code nhiều tuy nhiên trước đó cũng cần phải là cao thủ code dù ngu dốt vẫn xưng bá võ lâm như Quách Tĩnh tự cảm khái “Thiên thu bá nghiệp, bách chiến thành công.    Biên thanh tứ khởi xướng đại phong . Nhất mã bôn đằng, xạ điêu dẫn cung” . Vì chỉ có hiểu code, có hiểu dự án mới biết đội đang tắc chỗ nào ngày xưa mình gặp những lần tắc bể phốt như thế thì thông cống ra làm sao để mà chỉ dẫn cho anh em đi qua chỗ tụ nước.

Thôi chém gió đến đây cũng đã dài, chẳng biết viết đoạn chốt thế nào mà cũng đến giờ đi ngủ rồi. Hẹn mọi người lúc khác chém tiếp chủ đề khác.

P/S: Có mấy cái hình Infographic về PMO là chôm trên mạng, không phải mình tự chế

 

Compiling Assets Laravel Elixir

Laravel Elixir cung cấp một API gọn gàng và liền mạch cho việc tạo các Gulp cho các ứng dụng Laravel. Laravel Elixir cung cấp một số pre-processor phổ biến cho CSS và Javascript Sass và Webpack. Laravel Elixir cung cấp một vài tính năng giúp bạn làm việc với các file JavaScript, như biên dịch ECMAScript 2015, module bundling, nén, hay đơn giản chỉ là nối các files plain JavaScript.

Read more …

Nodejs là gì?

Trong bài viết giới thiệu về asynchronous, event-driven và non-blocking I/O, mình có treo tên Nodejs lên trên tiêu đề nhưng thật ra bài viết ấy lại không đả động đến Nodejs được bao nhiêu. Nó chỉ giới thiệu ý nghĩa của các khái niệm trên trong ngữ cảnh mà Nodejs sử dụng. Lần này là một bài viết chân thật về Nodejs. Hãy cùng nhau trả lời một câu hỏi mang tính bản thể luận về Nodejs: Bản chất của Nodejs là gì?

Read more …

Cloud Computing & Openstack Fundamental

Điện toán đám mây (tiếng Anh: cloud computing), còn gọi là điện toán máy chủ ảo, là mô hình điện toán sử dụng các công nghệ máy tính và phát triển dựa vào mạng Internet. Thuật ngữ “đám mây” ở đây là lối nói ẩn dụ chỉ mạng Internet (dựa vào cách được bố trí của nó trong sơ đồ mạng máy tính) và như một liên tưởng về độ phức tạp của các cơ sở hạ tầng chứa trong nó. Ở mô hình điện toán này, mọi khả năng liên quan đến công nghệ thông tin đều được cung cấp dưới dạng các “dịch vụ”, cho phép người sử dụng truy cập các dịch vụ công nghệ từ một nhà cung cấp nào đó “trong đám mây” mà không cần phải có các kiến thức, kinh nghiệm về công nghệ đó, cũng như không cần quan tâm đến các cơ sở hạ tầng phục vụ công nghệ đó.

Read more …

NodeJS – Hiểu Asynchronous Event-Driven Nonblocking I/O

Ta thường được nghe nói NodeJS là một JavaScript runtime built trên Chrome’s V8 JavaScript engine. Node.js sử dụng mô hình event-driven, non-blocking I/O. Ra đời từ 2009 đến nay, với sự thông dụng của nó, chắc hẳn nhiều người đã quen thuộc với NodeJS và các khái niệm event-driven, non-bloking I/O, asynchronous mà NodeJS góp phần phổ biến. Bài viết này đảo qua các khái niệm này một lần nữa một cách dài dòng, dẫn dắt hơn những câu trả lời gạch đầu dòng trên Stackoverflow một chút.

Read more …

Encoding: Base64 và Ascii85

Trong bài viết này, mình sẽ giới thiệu với mọi người về khái niệm Encoding, phân biệt nó với Encryption (Thứ mà nếu có điều kiện mình sẽ cùng chia sẻ trong những bài viết sau), sau đó đi qua 2 ví dụ với Base64 và Ascii85.

Ý định cơ bản của mình khi viết bài này là giới thiệu về phương pháp mã hoá Base64, hay nói đúng theo trên Wikipedia là về một nhóm encoding schemes na ná nhau gọi chung là Base64. Trong quá trình lựa chọn nội dung trình bày, mình quyết định đưa bài viết đi xa hơn mục đích ban đầu của nó một chút, xuất phát từ việc nhận ra Base64, vốn dĩ là một phương pháp Encoding lại thường xuyên bị nhầm thành Encryption.

Read more …

Giới thiệu về Server Sent Events

Như các bạn đã biết về vấn đề push notification, hay tự động cập nhập dữ liệu, hoặc thông tin … trên website khá là phổ biến. Hôm nay tôi sẽ giới thiệu cho các bạn biết về một trong những kỹ thuật để thưc hiện tự động cập nhập dữ liệu web client đó là Server Sent Event
Read more …

Browser push notification

Chào các bạn, như đã hứa trong group Laravel Việt Nam thì hôm nay mình tranh thủ viết một bài tutorial giới thiệu cách implement Push notification trên browser. Ở đây mình sẽ chỉ giới thiệu cách implement trên trình duyệt Chrome/Cốc Cốc. Firefox hoặc safari thì cũng tương tự các bạn có thể tự tìm hiểu thêm hoặc nếu có nhiều bạn có nhu cầu thì mình xin trình bày ở 1 blog khác. Mình viết hơi dài một chút để các bạn có thể hiểu sâu vấn đề chứ không chỉ là step by step tutorial mà code nó chạy mình không hiểu tại sao.
Read more …

Domain Driven Design là cái gì?

bài trước sau khi Start with why thì chúng ta đã có lý do cho việc tìm hiểu về Domain Driven Design rồi nên sang tới bài này chúng ta sẽ tiếp tục với câu hỏi Domain Driven Design là cái gì?  Câu trả lời thì cũng không quá đơn giản và dễ dàng nhưng cũng không đến mức quá cao siêu và phức tạp như cách mà những chuyên gia trình bày trong các quyển sách viết về Domain Driven Design.

Read more …

Domain Driven Design- Tại sao?

Vốn dĩ chưa có ý định viết về Domain Driven Design nhưng hôm nay vớ phải cái dự án làm outsource cho khách hàng có dùng cái này nên viết cái bài này để dọn đường cho anh em trước khi triển khai dự án.

Mặc dù outsource là việc làm bất đắc dĩ trong thời điểm khó khăn hiện nay, nhưng tinh thần tiến công của startup là không thay đổi. Mà đã làm startup thì  đối diện với bất cứ điều gì suy nghĩ đầu tiên bật ra trong đầu cũng là “Start with why?”.  Vậy thì Domain Driven Design là cái quái gì và tại sao lại cần phải dùng đến nó?  Nó  có phải là thứ bổ béo gì không mà phải mất công lằng nhằng tìm hiểu?

Read more …