Những điều tôi đã làm thử khi được đưa vào chữa cháy cho một project ở cương vị manager

Source

炎上案件に突如ディレクターとして投入されたときにやってみたこと

Background

Ở một dự án tôi đang tham gia dưới vai trò support, bỗng dưng trước ngày release 1 tuần được sếp bảo cần nhảy vào để chữa cháy gấp, thế là tôi đã đưa ra rất nhiều phương án để cố gắng giải quyết.

Chữa cháy đợt một

Đây là những việc đầu tiên tôi đã làm khi được đưa vào để chữa cháy.

1. Cùng mọi người kiểm tra quy luật giao tiếp trong nhóm, và cùng giao hẹn phải đảm bảo tuyệt đối

Ai đang nắm giữ thông tin gì, thêm nữa ai đã chỉ thị ai đó làm việc gì, công việc đó trạng thái hiện giờ ra sao.. Rất nhiều vấn đề trong dự án hiện đang là một mớ bòng bong.

• Mặc dù manager sẽ rất khổ, tuy nhiên tạm thời tôi yêu cầu toàn bộ mọi người phải báo cáo cho tôi, tôi sẽ có trách nhiệm đưa ra chỉ thị công việc với người thích hợp. Việc trao đổi, giao việc trực tiếp giữa các thành viên trong nhóm bị cấm hoàn toàn vào lúc này.
  • (Cũng có lúc tôi sẽ đưa ra chỉ thị yêu cầu anh A và anh B hãy trực tiếp trao đổi với nhau, tuy nhiên kết quả của các cuộc nói chuyện đó cũng phải thông báo cho tôi ngay sau đó).
  • Thêm nữa, những yêu cầu - chỉ thị mà tôi đề ra với các member sẽ được viết trên public chat của nhóm.

Mặc dù thoạt nhìn qua cách làm này có vẻ sẽ rất phiền phức,

• tuy nhiên bằng việc tránh engineer thêm hay giảm specs của dự án mà người manager sẽ đảm nhận, dần dần mọi thứ sẽ đi vào quỹ đạo của nó.
  • Đối với người engineer, người manager có vai trò đảm bảo nhân sự và giảm tại lượng specs của dự án cho hợp lý, chính thì thế luôn muốn họ sử dụng mình thật hiệu quả.
• Về phía khách hàng, họ bao giờ cũng muốn giảm thiểu nguy cơ bị thiếu thông tin muốn truyền tải tới những anh em engineer cho nên thường viện vào lý do "đã nói cho manager rồi".
  • Thêm nữa, nếu nói với engineer theo kiểu "mặc dù không rõ lắm, nhưng cố gắng làm theo hướng này cho tốt tốt là được" thì hầu hết đều dẫn tới kết quả rất xấu, sinh ra những sản phẩm hoàn toàn khác so với yêu cầu. Chính vì vậy, thay vào đó nếu nói trực tiếp tới manager, tỉ lệ đạt được sản phẩm chất lượng tốt hơn chắc chắn sẽ tăng cao, tôi muốn khách hàng có thể trao đổi với mình được tích cực như vậy.

Mặc dù đã đã thông tư tưởng như vậy, tuy nhiên vẫn có những người nói chuyện trực tiếp với engineer mà không qua tôi, chính vì thế tôi đã phải nói chuyện rất thẳng thắn: "chẳng phải tôi đã mong ngài đừng đưa ra những chỉ thị trực tiếp, mà hãy thông qua tôi rồi à? Có thể ngài lo cho tôi bận rộn nên muốn thay tôi đưa ra yêu cầu tới với mọi người, tuy nhiên ngài có biết với vấn đề đó đã có một chỗ khác đang tiến hành sửa rồi không?". Và cứ thế tôi vừa kìm nén tức giận của mình và yêu cầu họ như vậy.

2. Ngoài ra, tôi tập trung tất cả yêu cầu và specs của dự án đóng thành tài liệu và thu thập toàn bộ các task lại để quản lý cho tốt

Do việc phát triển được thực hiện bởi một chi nhánh nước ngoài cho nên các engineer không hiểu và nắm rõ hết được specs. Có một vấn đề nghiêm trọng nữa chính là bên phía đặt hàng có rất nhiều người đưa ra chỉ thị thường xuyên, lại còn không có tính thống nhất và thỉnh thoảng lại đưa ra yêu cầu cho nên những tài liệu specs không được chỉnh lý đều đặn và để có nơi có chỗ.

• Chính vì tài liệu specs và những tài liệu liên quan khác ở đâu không ai hay cho nên tôi đã phải tự mình quyết định, lần theo dấu vết để cố gắng tập trung được mọi thứ ở mức tối đa.
• Tất cả tài liệu được tập trung lại cũng đều chỉ là sự tự ý tổng hợp của người manager.
• Tại trang liên lạc chung với mọi người, tôi đã gửi link của nơi tổng hợp dữ liệu và ghi một vài dòng sơ lược về loại tài liệu là gì, ngoài ra để xem chi tiết thì cần tự tìm hiểu trong đó.
  • Tôi chỉ ghi lại những thứ mà mọi người sẽ muốn xem và access, những thứ không cần thiết đều bỏ đi.
• Mặc dù chỉ còn 1 tuần nữa là đến ngày release, tuy nhiên tôi cũng đã tạo ra một bảng quản lý các vấn đề tồn đọng. Tại đó tôi ghi lại hết các câu hỏi hay vấn đề cần xác nhận, thậm chí cả những yêu cầu. Về phần truyền tải những yêu cầu và đưa ra chỉ thị tới từng developer cụ thể tôi đã giao hoàn toàn trọng trách cho system engineer.

3. Xây dựng đội hình tương trợ

Một mình người manager sẽ không thể làm gì cả. Mặc dù trong mắt mọi người manager có thể là một kẻ đáng ghét, nhưng cũng đồng thời có suy nghĩ "tóm lại cứ giao hết cho manager là được", coi manager là một kim chỉ nam xuất sắc. Manager chính là người sẽ đảm nhận lo toan cho những công việc phiền phức, vụn vặt mà những người làm nhiệm vụ chuyên sâu sẽ không màng tới. Tôi nghĩ rằng cũng như cách này, điều quan trọng nhất là hình thành được mối quan hệ 2 bên đều vui giữa engineer và manager cũng như với bên đặt hàng.

• Mặc dù đã quyết định quy luật liên lạc, nhưng cuối cùng thì việc tôi phải tới nói chuyện với từng thành viên quan trọng trong dự án sẽ mang lại kết quả hiệu quả nhất: "thực tình chỉ mình tôi thì cũng không có kỹ năng gì đặc biệt, không thể tự mình làm điều gì. Ở lĩnh vực này thì tôi chỉ có trông cậy vào anh được mà thôi. Anh có thể giúp tôi được không?"
• Chỉ cần đối phương nghĩ được một chút rằng: "Đành vậy, thôi giúp được gì thì sẽ giúp", điều đó chứng tỏ rằng member trong dự án đang từ tư thế bị động đã sẵn sàng chủ động giúp sức. Bằng cách này, dự án sẽ được đưa vào một vòng lặp nâng caao chất lượng hằng ngày.

4. Giảm số lượng thành viên thường trực

Chín người mười ý

• Tôi cố gắng sắp xếp và điều chỉnh lại làm sao để đưa dự án trở lại về trạng thái cơ bản 3 người chính là: engineer - manager - bên đặt hàng (người quyết định specs). Tóm lại, trong rất nhiều người đang thường trực tham gia ở dự án, tôi sàng lọc ra các thành viên cốt lõi sao cho người engineer đảm bảo chất lượng phát triển, người bên phía đặt hàng phải có nhiệm vụ tóm tắt lại hết yêu cầu muốn thực hiện.
• Dù engineer có nhiều người đi chăng nữa, manager cũng sẽ chỉ nói chuyện với một người chịu trách nhiệm mà thôi. Người engineer này sẽ chịu trách nhiệm và điều chỉnh công việc cho các thành viên khác. Người bên phía đặt hàng phải chịu trách nhiệm tổng hợp và chỉnh lý lai toàn bộ specs và yêu cầu để truyền tải.
  • Nếu có một người khác người đã được chỉ định có ý kiến trực tiếp với manager, tôi yêu cầu "hãy nói chuyện và truyền tải tới người chịu trách nhiệm".
• Tuyệt đối đảm bảo không được có chuyện giữa engineer và người đặt hàng được bàn thảo trực tiếp không qua manager.

Chữa cháy đợt hai

Chữa cháy đợt một thực chất chỉ là sách lược giúp công việc được xoay vòng chỉn chu trong một dự án đang bị hỗn loạn nghiêm trọng. Chính vì thế, sau khi đã đảm bảo được quy luật về liên lạc trong nhóm, giảm thiểu số thành viên cốt lõi xuống 3 đến 4 người, tóm tắt lại toàn bộ tài liệu và quản lý các vấn đề còn tồn đọng, cuối cùng đã đến bwocs làm sao để ngày release được hạ cánh an toàn..

1. Tạo tài liệu specs (test specs)

Về mặt specs vốn dĩ đã không ai nắm rõ, chính vì thế tôi chỉ có cách tự tìm hiểu và động não suy nghĩ liên hệ tới những tài liệu mình đã từng đọc để ghi lại flow của service, tạo ra file document chứa những specs đã bị thay đổi hay thêm vào sau các đợt nói chuyện, từ đó đưa ra được tiêu chuẩn "Chạy được như thế này là OK (ngoài ra là kiểm soát được lỗi)". Cuối cùng thì bản mà tôi làm ra cũng chính thành tài liệu specs của dự án.

2. Liên lạc với các bên liên quan (đặc biệt là những người có quyền quyết đinh) để bàn thảo về việc nới kì hạn nộp và bỏ một vài tính năng và yêu cầu cần thiết đi

Mặc dù là điều thường làm tuy nhiên đây cũng chính là thứ hiệu quả và mang lại tín hiệu tích cực nhanh nhất mà người manager nên làm. Có thể bàn bạc "sau khi nộp hàng chúng tôi sẽ làm tiếp phần này" để cắt giảm bớt chức năng và yêu cầu cần thiết để kịp nộp hàng (giảm lượng công việc phải làm ngay lập tức) và bàn về kế hoạch sắp tới. Nếu chỉ cần bàn riêng về kế hoạch thôi thì có thể bao hàm luôn trong chữa cháy đợt một. Thực sự thì nếu được cần làm ngay ở chữa cháy đợt một, tuy nhiên trong trạng thái người manager được đưa vào chưa hiểu rõ ràng về specs mà lại đi bàn bạc "có thể bỏ chức năng này đi được không" là điều không thế, ngoài ra bên khách hàng cũng không thể quyết định ngay "ừ thế thì chức năng đó cũng không cần" như thế được, cho nên buộc lòng phải để ở chữa cháy đợt hai.

3. Làm rõ người quyết định cuối cùng, cũng chính là người sử dụng (hay đại diện cho người này) lúc launch, điều chỉnh lần cuối

Làm rõ "cuối cùng ai là người điều hành (ai quản lý hay vận hành), ai là người sẽ sử dụng (end user) hay đại diện cho việc đó", từ đó quyết định những điều chi tiết cuối.

• Với những người ngoài sẽ có rất nhiều lời ra tiếng vào về tính cần thiết hay không cho một chức năng, hay bảo là end user sẽ cần này nọ.. tuy nhiên cần dẹp bỏ bằng quyền hạn của manager.
  • Do manager sẽ phải đưa ra chỉ thị, bàn bạc và quyết định cả specs nữa nên sẽ có những lúc đầu óc xoay không kịp và rất khó khăn cho nên nếu được nên tránh để end user và người có quyền quyết định bên đội vận hành cũng là manager, từ đó điều chỉnh giữa người đó và manager rồi tới manager và đội phát triển.
• Tại thời điểm này nếu có vấn đề gì thì khó có thể cứu chữa được, cho nên cần giao trách nhiệm quyết định cho một người thực tế, có khả năng phán đoán giải quyết vấn đề tốt.

4. Nếu có thể cần tăng số ngày làm việc của đội phát triển và thêm người cấp dưới cho manager

Mặc dù tôi cũng theo chủ nghĩa khuyên các thành viên dự án đi làm vào ngày nghỉ do trong tuần đã mệt mỏi nhiều, tuy nhiên nếu có thể cần tăng thời gian làm việc lúc này. Bên phía manager vào lúc này do lượng công việc cần làm đã rất nhiều cho nên nếu có thêm các thành viên có năng lực tốt, đáng tin cậy để trợ giúp việc test chi tiết sẽ rất quý báu.

5. Kiểm tra các vấn đề quan trọng

Lần này do dự án quá chây ì nên đã gặp vấn đề nghiêm trọng, tuy nhiên cần kiểm tra xem có số lượng ngày nhất định nào buộc phải chờ đợi hay không, ví dụ như đến thời điểm kiểm tra được app cần 10 ngày nữa.. Tại thời điểm này nếu không vượt qua được kiểm duyệt một số chức năng quan trọng thì coi như đã kết thúc.

• Tôi nghĩ rằng cần thiết cho kiểm tra kể cả những thứ vẫn còn nữa vời đi chăng nữa đối với những hình thức "thẩm tra", "thừa nhận" hay "cần bao nhiêu ngày để xác nhận".
• Ngoài ra khi có những kiểu xác nhận như trên, thường sẽ có những người nói thời gian cần thiết mà không đưa buffer vào, chính vì thế cần nhìn ra được vấn đề và tự bản thân mình kiểm tra kỹ lưỡng. Tự mình phải hiểu và nhớ rằng buffer sẽ mất khoảng 1 hay 2 ngày, trường hợp xấu có khi cần tới 3 ngày buffer nữa.
• Có một thứ mọi người cũng hay bỏ qua chính là việc deploy không được trót lọt như mong đợi. Bạn nhất định phải sàng lọc ra hết những thứ cần thiết để môi trường production có thể chạy được tốt.

Về vấn đề deploy, nếu có đủ thời gian để luyện tập thì sẽ không có vấn đề gì cả.

• Một người engineer cho biết chỉ cần chia nhỏ chức năng ra rồi sau đó đưa lên liên tục thì việc sợ deploy sẽ dần được giải quyết.
  • Tôi muốn mọi người tạo môi trường phát triển càng nhanh càng tốt.
  • Sau khi chuẩn bị được môi trường, sẽ tạo cơ chế để deploy.
  • Khi test và review định kỳ sẽ deploy nhiều lần, kinh nghiệm deploy từ đó sẽ được nâng cao.

6. Chỉnh lý điều kiện nộp hàng

Các vấn đề rất hay xảy ra trước khi giao hàng chính là

1. mặc dù đã phát triển xong, tuy nhiên không thể deploy hay chưa quyết dịnh nơi deploy, ngoài ra là có vấn đề với bên infra.
2. Hỗn loạn khi không thể chuẩn bị được nơi release cần thiết
3. Mặc dù đã phát triển xong, tuy nhiên vẫn còn việc phải cài đặt hàng nghìn mục lúc khởi tạo dẫn tới việc vận hành không tốt

Mặc dù bị trùng với việc kiểm tra xem có pass được các mục quan trọng hay không, phải nhớ kiểm tra xem hoạt động sau khi phát triển có ổn hay không (việc deploy có thành công ngay không..) Từ đó, cũng giống với 3, có những trường hợp nếu không có đủ dữ liệu cần thiết thì môi trường production sẽ không hoạt động, chính vì vậy cần chỉnh lý và kiểm tra kỹ tất cả chức năng và điều kiện giao hàng cần thiết trước khi nói lời "giao hàng".

7. Ngoài ra nếu được cần điều chỉnh kế hoạch cho thư thả hơn

Cố gắng kết thúc trước 1-2 ngày, sau đó thực hiện test lại nhiều lần. Cần ghi nhớ kỹ điều này

[Lời khuyên cá nhân] Nếu đã release thành công, thực hiện buổi closing meeting

Cuối cùng, cũng đúng với cái tên "dự án đang cháy" cho nên không tránh khỏi có những kết thúc thiêu rụi từng người và cháy thành tro.. Cũng giống với việc có buổi kickoff meeting, cần thiết thực hiện closing meeting Kickoff có ý nghĩa truyền tải với mọi thành viên sắp tới chúng ta sẽ thực hiện một dự án như thế này, còn closing là tóm tắt những điều đã làm và những điều dù muốn nhưng chưa thể làm. Hình tượng thì giống như màn hình thông báo kết quả sau một trò chơi.

• Xem xét lại (hình thức KPT..)
• Chỉnh lý lại tài liệu, quyết định cách vận hành hướng tới phase vận hành từ nay về sau
• Kiểm tra dự án còn lại

Xem những điều gì đã làm được và chưa làm được, bằng việc dọn dẹp lại giúp kết nối tới những dự án sau, những thành viên dù đã "cháy rụi" vẫn được tận hưởng cảm giác "cuối cùng dự án cũng đã kết thúc rồi". Ngoài ra, thực hiện closing meeting sau khi kết thúc dự án như vậy sẽ giúp các thành viên được làm mới lại cảm xúc.

Cuối cùng

Sức mạnh của một manager, mặc dù kể cả là người có giỏi đến đâu đi chăng nữa cũng không thể so sánh với sức mạnh của 1 team. Tôi đã chứng kiến rất nhiều dự án đang bị cháy, và nếu tình hình chỉ đơn thuần là đang bị hỗn loạn mà thôi thì người manager chỉ cần bàn thảo và đưa ra phương hướng đúng đắn thì tình hình sẽ được cải thiện rất nhanh. Người manager chính là đầu tàu của cả team, cần sử dụng con người một cách hợp lý và hoạt động như một chất xúc tác. Những điều cơ bản của một người manager:

• Quản lý yêu cầu
• Quản lý kế hoạch
• Quản lý con người (quản lý cost) Nếu làm được những điều trên, ít nhất bạn sẽ đưa 1 dự án đang bị cháy quay lại đúng hướng của nó.