Người hùng PM! anh ở đâu

612

Bái báo này là dành cho bạn, người khách hàng gan dạ với ý tưởng hừng hực cháy và một ít tền trong tài khoản ngân hàng. Mấy cái biểu đồ bạn vẽ lên giấy ăn sẽ làm thế giới điên đảo, và tiền của bạn chắc đang được chất thành xe tải đang được chở đến nhà. Để đảm bảo mấy cái xe này đến nơi đúng lúc, dưới đây là một vài lời khuyên giúp bạn quản lý công việc trơn tru hơn.

Ta cần PM để làm gì?

Douglas Crockford từng tuyên bố rằng “Chương trình máy tính là một trong những thứ phức tạp nhất mà con người tạo ra”. Bạn có thể chưa nghe đến tên anh này, nhưng anh ấy khá nổi tiếng trong giới lập trình đấy. Anh hiện là kỹ sư phần mềm cao cấp tại Paypal. Anh ấy đã từng đi tiên phong với một kiểu công nghệ thú vị mà bài báo này chẳng thể kể hết. Anh ấy cũng là một người có rất nhiều kinh nghiệm làm việc trong các dự án lớn.

Còn về phần tôi, chỉ mới lập trình được 13 năm thôi, và thậm chí đến giờ, mỗi project với tôi lại là một trải nghiệm mới. Có quá nhiều công nghệ mới đến mức tôi tưởng như không bao giờ có thể am tường hết được. Với mỗi dự án, vẫn có một số không đổi bên cạnh những thách thức riêng:

  • Project luôn có áp lực thời gian.
  • Ngân sách ít hơn mong muốn.
  • Tôi có giá trị hơn khách hàng nghĩ.
  • Tôi không tuân theo đúng như những gì khách hàng muốn.
  • Khách hàng không giải thích rõ mong muốn của họ như tôi mong đợi.
Bạn là Project Manager với kinh nghiệm chinh chiến dày dặn? Bạn đã kinh qua không ít dự án e-Commerce lớn nhỏ với khả năng lãnh đạo team cực “Chất”.

VietLink đang rất cần bạn đấy. Tại VietLink, chúng tôi sẵn sàng offer bạn:

  • Offer $2000 với 3 năm kinh nghiệm PM
  • Môi trường năng động thân thiện
  • Lương tháng 13, thưởng MVP hàng tháng
  • Sẵn sàng thỏa thuận thêm phỏng vấn
  • Ứng tuyển ngay cơ hội này tại đây: http://topdevvn.com/s/sgKxgf67 

Rõ ràng, ta cần một “bảo mẫu”. Một người hùng đề ra các nguyên tắc cơ bản; đảm bảo tính chân thật và đảm bảo mọi người không quên các công việc quan trọng. Một người hùng thiết lập sự liên lạc giữa tất cả các bên.
Và người hùng này không ai khác, chính là PM.

Tại sao product manager lại ở trong hộp? Anh ta là mèo, và mèo khoái hộp.

Lý do programmer không thể trở thành một PM giỏi

Bên cạnh chứng nhận của Project Management Institute, thứ giá trị nhất mà một PM có thể đóng góp chính là kinh nghiệm. Cũng vì lý do này, nhiều programmer có thể đảm nhiệm vị trí PM khá tốt; chúng ta có nhiều khinh nghiệm với các techical project hơn; và là những chuyên gia phân tích, phân loại thông tin và đặt ra mục tiêu cụ thể.

Tôi biết, các anh đã trả chúng tôi đủ tiền rồi, vậy nên các anh sẽ hi vọng chúng tôi có thể tự quản lí tiến độ chứ không cần phải tốn thêm tiền cho một người nữa làm công việc này đúng không?

A hèm, thứ nhất, các anh chỉ trả tiền để chúng tôi code thôi.

Và khi chúng tôi buộc phải tranh luận phải ưu tiên cái gì, hoặc trong tuần này chúng tôi sẽ làm đến đâu, chúng tôi sẽ chẳng viết được dòng code nào đâu. Và rồi lại mất ít nhất 10 phút nữa thì chúng tôi mới có thể tiếp tục quay lại “đam mê”. Càng mất thời gian hơn nữa nếu chúng tôi bị stress bởi cũng cuộc tranh luận ấy (trong đa số trường hợp là về tính năng ưu tiên).

Quan trọng hơn nữa, chúng tôi không thể nhìn toàn cảnh được. Làm ơn hiểu rằng: khi tôi nhìn chằm chằm vào sửa bug, não tôi chả có chỗ cho vấn đề khác nữa.

Và não của tôi sẽ tự động tận hưởng ngay sau khi tôi sửa được những bug này, tôi sẽ cho rằng tôi đã hoàn thành một sứ mệnh vĩ đại và bỏ đi chơi game. Khi có người nhắc tôi rằng home page vẫn chưa chạy được, tôi sẽ rất bất ngờ bởi vì tôi đã dành rất nhiều thời gian chú tâm đến từng chi tiết nhỏ của project mà quên bén đi tổng thể. Não tôi hoạt động như vậy đó, và tôi tin chắc những programmer khác cũng có tâm lý tương tự.

Khi chúng tôi ngưng công việc để thảo luận các quyết định của project, sẽ không có một dòng code mới nào được viết ra cả.

Lý do khách hàng không thể trở thành một PM giỏi

Vậy thì, nếu programmer không quản lý được project thì nhiệm vụ này chắc phải do các bạn khách hàng đảm nhiệm rồi. Tiền là của bạn, tầm nhìn cũng là của bạn mà. Mà dù hay hay dở, bạn cũng là người đứng mũi chịu sào cho cả dự án này mà.

Nhiều khách hàng cũng như bao người khác thôi, họ cũng bị phân tâm hay đãng trí như thường. Dù dòng mô tả này có lẽ sẽ không đúng với các bạn, nhưng hãy cứ tưởng tượng có một chuyên viên nhắc nhở đi kè kè theo bạn nhắc nhở những công việc quan trọng và giữ tiến độ của project.

Nếu bạn đã từng giám sát, hoặc làm việc trong một dự án với quy mô tương tự, bạn có thể trở thành một quản lý khác phù hợp cho dự án của mình đấy. Nếu bạn chưa từng, làm ơn đừng đánh giá thấp giá trị của “nhà tiên tri” dự đoán trước những trục trặc phát sinh. Ước tính thời gian cũng chỉ là ước tính mà thôi, và bug luôn xuất hiện ở thời đểm khó lường nhất. Và người sẽ nhắc nhở những quá trình nào cần quan tâm nhất cũng đóng vai trò rất quan trọng.

Ví dụ như với Đảm Bảo Chất Lượng (QA). QA rất quan trọng nếu bạn muốn kết quả tốt từ bất cứ project nào, nhưng lại có ít người để tâm đến. Một PM giỏi sẽ tận dụng hết mức nguồn QA ít ỏi, đồng thời giúp bạn đảm bảo chất lượng của programmer. Đôi khi, mọi chuyện không trong tầm hiểu biết của bạn, và có lúc bạn cũng sẽ phạm lỗi. Bạn cần một người cố vấn hiểu biết về mặt kỹ thuật đễ xác định xem liệu programmer của bạn chỉ đang sao nhãng, hay thật sự không về phù hợp với dự án của bạn. Xử lý sớm vấn đề nhân lực chính là yếu tố sống còn của project.

Cuối cùng, ngay cả các bạn, những khách hàng thượng đế ạ. Đôi lúc các bạn cũng phải “xuống” một chút. Tôi đã từng làm việc trong nhiều dự án với những khách hàng đòi nằng nặc mọi thức phải thật hoàn hảo, cái nào cũng phải ưu tiên và tất tần tật mọi thức phải làm xong cho bằng hết. Tôi không bất đồng với họ về điểm này, và họ, rất tiếc, cũng chả biến được một ngày thêm vài tiếng. Và rồi, họ không có được kết quả mà họ muốn. Theo tôi, nếu họ chỉ cần tin tưởng trao quyền tiếp cận và quản lý cho một PM, thì kết quả “đau buồn” này đã không xảy ra. Khi tiền bạc và ý tưởng của bạn đang trên đống lửa, bạn sẽ rất khó đưa ra bất cứ quyết định cứng rắn nào. Và khi có chuyện xảy ra, cứ việc than khóc thoải mái, máy tính không biết thương bạn đâu (tôi biết, tại tôi thử nhiểu rồi).

Các kỹ thuật quản lý technical project không hoàn chỉnh

Dù bạn có quyết định cứ làm ngơ phần bài trên và tự nhảy vào tự quản lý, hay thuê người thực sự biết về quá trình; nếu bạn muốn tìm hiểu thêm, danh sách này sẽ giúp bạn. Tôi chưa từng (chính thức) làm PM, nên tôi không chắc một PM thực thụ sẽ dùng cái nào, nhưng tôi đã từng thành công phần nào với những phương pháp này:

Cột mốc

Khi bắt đầu một project mới, đa số mọi người sẽ tự động biết chia project ra nhiều phần nhỏ dễ quản lý, mỗi phần sẽ tương đương khoảng vài tuần hoặc vài tháng làm việc. Lúc bắt đầu project, nên có một cuộc họp xác lập các cột mốc này. Bạn không cần xác định rõ con đường đến các cột mốc này đâu. Bạn chỉ cần nhớ kiểm tra sau mỗi cột mốc để tận dụng hiểu biết gia tăng của project, và để đảm bảo độ khó các cột mốc đúng như đặt ra ban đầu.

Ước tính thời gian

Progammer chúng tôi rất ngại cái gì “ước tính”, vì tôi biết chúng kiểu nào cũng sai và không ai khác ngoài chúng tôi phải trả giá. “Ước tính” sai thì cũng bình thường, bời vì là “ước tính” mà. Và chúng tôi trả giá cũng là đúng, bởi dù gì đây cũng chính là động lực, làm không kịp thì phải chịu “roi quất” cho nhanh lên thôi.
Vì vậy, mỗi khi chạm cột mốt mới, các bạn cứ thoải mái hỏi thời gian ước tính. Thông thường, tôi sẽ đưa một khoảng ước tính thật lạc quan, và rồi nhân đôi nó lên. Đa số trường hợp chậm tiến độ này thường do các lỗi ẩn.

User Stories

User Stories là giới thiệu ngắn về một phần chức năng của ứng dụng. User Stories (thường đi chung với một hình vẽ nhỏ, và chỉ nên ở bite-sized, để khớp với thẻ index) được dùng để ghi lại các feature quan trọng. Hơn nữa, chúng còn là cầu nối giữa yêu cầu của khách hàng và ngôn ngữ của programmer. Đối với khách hàng các bạn, thì chỉ đơn giản trong vài phút thôi, nhưng về phần programmer chúng tôi, thì tốn thời gian công sức hơn nhều.

Để biết thêm về user stories, các bạn có thể đọc thêm Mountain Goat Software and Roman Pichler. Còn về thuyết “Agile Project Management”, bạn có thể đọc bài blog The Ultimate Introduction To Agile Project Management của Paul Barnes.

Compositions (mock-up)

Đây không phải là bài viết về lý do bạn cần designer bởi vì tôi thấy nhiều khách hàng đã biết rõ điều này rồi, nhưng cái gì quan trọng phải nhắc lại nhiều lần. Nếu có một design đã hoàn chỉnh trước khi lập trình, các bạn sẽ nhận thấy năng suất gia tăng đáng kể. Hơn nữa, chúng tôi sẽ mất “hứng” mỗi khi chúng tôi phải thảo luận về một quyết định design nào đó, hoặc mỗi khi phải thay đổi điểm nào đó (do chưa có sẵn bản thảo để làm theo), bạn tính thử đi, mất bao nhiêu thời gian… Tôi không cằn nhằn đâu, design cũng rất vui đấy, nhưng theo kinh nghiệm của tôi, nếu bạn muốn giảm bớt thời gian phí phạm, đây là cách hiệu quả nhất và cần quan tâm trước nhất.

Đa số designer có cung cấp composition (còn được gọi là comps) trong Adobe Photoshop, Adobe Illustrator, hay Sketch. Nếu bạn muốn tự làm, bạn có thể sử dụng rất nhiều công cụ trên mạng như Balsamiq hay InVision. Bản comp không cần phải cùng màu và styles như sản phẩm cuối cùng (vì mấy cái này dễ thay đổi được), nhưng hãy đảm bảo rằng mọi phần tử trong UI đều được biểu diễn và nhận biết.

Hợp đứng

Các cuộc hợp dài hơi là không thể tránh khỏi, nhưng bạn không nên “nhồi” programmer quá tải hay mất thời gian quá mức cần thiết. Tôi đã gặp nhiều khách hàng muốn tôi nhớ hết mọi thứ được đưa ra trong một cuộc hợp (kéo dài đến hai tiếng rưỡi đồng hồ), và hiển nhiên tôi đã khiến họ thất vọng. Một cuộc hợp đứng thường kéo dài 15 phút, và đúng như tên, mọt người thường đứng trong khoản thời gian của cuộc hợp. Bắt mọi người đứng đáng ra là để đảm bảo mọi người sẽ để ý tham gia (đồng thời để cuộc hợp ngắn hơn).

Trong những cuộc họp này, mọi người đi vòng vòng và báo cáo vắn tắt tiến độ của mình cho mọi người. bạn có thể tìm hiểu thêm tại ExtremeProgramming.Org. Nếu các thành viên làm việc từ xa và không muốn mọi người phải lên Skype mỗi ngày, bạn có thể thử một công cụ khá vui (15Five) để thay thế. 15Five cho phép các thành viên tải báo cáo bất cứ khi nào tiện, và nhắc nhở họ bằng các câu hỏi khảo sát.

Ticketing system

Tuy bất cứ ai cũng có thể duy trì một hệ thống giấy note và Google Docs (với công việc của mọi người được highlight đủ màu sắc), nhưng việc này không cần thiết đâu. Đã có người tìm ra cách giúp bạn giải quyết vấn đề này rồi. Basecamp và Trello rất nổi tiếng vì chúng khá dễ dùng, trong khi đó Pioval lại cố bao hết triết lý “agile” (nhanh) vào một bao bì bóng bẩy. Dù bạn có chọn gì đi nữa, thì ít nhất, một ticketing system tốt sẽ cho phép bạn:

  • Tạo nhiệm vụ
  • Gắn độ ưu tiên và ngày hết hạn
  • Kết nối các nhiệm vụ và công việc
  • Gắn giải thích như “đã hoàn thành” hay “test thất bại”
  • Hiện các nhiệm vụ được phân cho một người dùng nhất định

Khi PM quăng trước mặt bạn một lượt 40 tấm note đỏ ưu tiên và cùng hết hạn một ngày, bạn sẽ hiểu rõ giá trị của cách nhìn “mắt chim”.

Bạn không cần phải dùng sticky note để theo dõi bug.

Source control

Bạn có thể chưa từng xem qua code trong project version control system của mình. Tuy vậy source control (hay versioning) là một trong những công cụ backup mạnh mẽ nhất hiện nay.

Đa số project hiện nay đang dùng Git, hoặc Subversion (SVN) với các project cũ hơn. Github cho phép các bạn host miễn phí số lượng public repository không giới hạn (hơn nữa, Github chứa hầu hết các project nguồn mở trên thế giới). Trong khi đó, Bitbucket lại được ưu ái hơn trong các project thương mại vì cho phép host ptivate repository không giới hạn.

Các version control system này có một điểm chung: nó lưu trữ code từ xa để đề phòng chuyện không may xảy ra, và theo dõi các lần “ủy thác” code cho hệ thống kèm theo một message (bắt buộc) mô tả công việc (nhằm tránh developer viết chồng lên code của nhau). Đồng thời, nó cho ta thấy các thay đổi theo thời gian, và tạo code branch mới cho một số chức năng chưa được tung ra. Bạn cũng có thể dùng lệnh “blame” để thấy ai chịu trách nhiệm cho dòng code nào và khi nào.

Source control là công cụ tuyệt vời nhất.

Test-driven development

Bước này ít khi được đưa vào các project có ngân sách thấp do vấn đề chi phí. Vậy nếu bạn chỉ mới start up thì cũng không nên quá lo về vấn đề này. Nhưng tôi phải đưa bước này ra đây vì nó có thể bảo vệ mạnh mẽ ứng dụng trước bug. Nói cách khác, programmer sẽ dành thêm thời gian quý báu để viết test (code block nhỏ) nhằm đảm bảo một số phần của ứng dụng vận hành theo một số hướng cụ thể, lặp lại được và dễ dự đoán. Ví dụ như, Tôi có thể viết một test giúp đảm bảo mỗi khi click vào nút “login”, một popup có trường username sẽ mở ra.

Cái hay nữa là một khi đã viết ra rồi, tôi có thể chạy test đồng loạt chỉ với một dòng lệnh duy nhất. Và nếu tôi viết 200 test, tôi có thể chạy chúng sau khi tung ra phiên bản ứng dụng mới để đảm bảo rằng sẽ không có bug nào dính vào 200 tính năng mới này. Test tuy chưa hoàn hảo, nhưng nếu bạn muốn một công cụ đảm bảo ứng dụng bug-free (hoặc ít nhất là buglite) thì test sẽ là lựa chọn của bạn.

Lời kết

Trên đây là toàn bộ những kinh nghiệm quản lí mà tôi đã lụm nhặt được qua hơn chục năm làm việc trong các web project. Tất nhiên, tôi vấn khuyên các bạn nên thuê dân chuyên nghiệp và tận dụng tối đa kinh nghiệm của họ. Còn nếu bạn không đủ tài lực, tôi hy vọng những chia sẻ này sẽ giúp được bạn phần nào. Là khách hàng, bạn có quyền hạn cao nhất trong một project. Vì vậy, càng hiểu biết về tính chất của công việc, bạn sẽ càng dễ đi đến thành công hơn.

Techtalk via Toptal

 

CHIA SẺ