Viết về việc đổi team và những khó khăn mới

Bạn đã bao giờ trải qua cảm giác từ một chiếc cano linh hoạt với team 10 người bước thẳng lên một con lớn với 50 thành viên chưa? Mình vừa trải qua cảm giác đó được hơn một tháng.

Ở team 10 người, mình có được sự linh hoạt cần thiết và mỗi sự thay đổi nhỏ đều tác động lên cả team một cách dễ dàng. Nhưng ở team 50 người, mọi thứ là một mê cung của quy trình, tầng lớp và những "luật bất thành văn".

Để không bị sóng đánh văng khỏi tàu, một lộ trình "hòa nhập và hòa tan" mà không đánh mất bản sắc của một PM ra đời.

Dưới đây là những gì mình đã đúc kết được sau những tháng đầu tiên "vật lộn" nhưng đầy cảm hứng.

1. Tìm hiểu quy trình cũ: Đừng là "vị vua mới" hiếu thắng

Có một sai lầm kinh điển mà nhiều PM (bao gồm cả mình trong quá khứ) dễ mắc phải: Vừa vào team đã muốn "đập đi xây lại". Chúng ta thường mang theo cái tôi quá lớn và những quy trình "chuẩn chỉnh" từ công ty cũ để áp đặt vào môi trường mới.

"Culture eats strategy for breakfast." – Peter Drucker

Trước khi muốn thay đổi bất cứ điều gì, dù là nhỏ nhất, mình đã dành thời gian để hiểu Tại sao quy trình đó tồn tại. Tại sao team lại dùng Jira theo cách cồng kềnh này? Tại sao buổi Daily Standup lại kéo dài tận 30 phút thay vì 15 phút?

Và mình bắt đầu với những sự thay đổi nhỏ như thay đổi template viết User Story. Với team mình, mình thấy nó quá sơ sài, hoặc quá dài dòng và mình đã tìm hiểu tại sao nó tồn tại, ưu điểm của nó là gì, nhược điểm của nó là gì và khi thay đổi, không chỉ mỗi bạn nắm được việc đó mà các bên liên quan cũng cần hình dung được (quả này nhiều lúc rảnh có thời gian thì viết dài, bị dí task thì viết vội nên nó không được đồng nhất chứ không có gì).

Mình nắm được hiện tại user story hơi dài và viết sẽ mất nhiều thời gian, chưa có chuẩn chung giữa các team. Mình đang ưu tiên cần sự nhanh gọn và linh hoạt nên mình đã rút ngắn phiên bản chuẩn lại một chút, chỉ cần đọc vào là biết cần làm gì, cần test gì, tạo sao lại như vậy và mọi người trong team sẽ nắm được việc đó nên sẽ ít thắc mắc hơn. Và từ đó, những thay đổi “lớn” hơn dần hình thành.

Hãy là một "nhà khảo cổ học" trước khi làm "kiến trúc sư". Hiểu rõ những vết nứt của quy trình cũ sẽ giúp bản vẽ mới của bạn thực tế hơn.

2. Cố gắng đặt mục tiêu cho sự thay đổi

Trong một team 50 người, mỗi thay đổi của mình sẽ tạo ra hiệu ứng lên nhiều người khác (Dev, QC, Design,...). Vì vậy, trước khi đưa ra bất kỳ thông báo thay đổi nào, mình luôn tự hỏi: "Thước đo thành công của việc này là gì?" và "Effort của team có đáng không?".

Với idea thay đổi nhỏ nhỏ ở trên, mình muốn thay đổi cách viết docs, mình phải chứng minh được là nó giảm được bao nhiêu % số lần dev confirm với mình hay mọi người (im im mà đếm thui chứ k ai track cái này được đâu mà hình như nó đang hiệu quả)

Nếu bạn không đo lường được, thì tìm cách mà đo để làm (ego cao mà :v)

3. Tìm cách gia nhập vào các cuộc trò chuyện

Vì là một team 50 người nên lượng thông tin luân chuyển khá lớn. Mình phải cố gắng nhanh chóng bắt kịp "tần số" của mọi người để tránh trở thành một PM chỉ biết ngồi đợi task.

Trong 2 tuần đầu, mình chỉ ngồi nghiên cứu sản phẩm và tham gia vào các cuộc họp (không tham gia vào bất kì hoạt động nào khác luôn - trừ đi ăn bánh chuối với đi pha cà phê)

Với nghiên cứu Line sản phẩm thì mình không đi sâu vào logic của từng module của các sản phẩm, nhưng mình nắm rõ: Team này làm về A, team kia làm về B, team nọ làm về C. Mục tiêu là khi ai đó nhắc đến "vấn đề A1, mình biết ngay nó thuộc phạm vi của ai và ảnh hưởng thế nào đến bức tranh chung.

Và tham gia mọi cuộc họp (dù chỉ để nghe) từ Planning, Review, Daily cho đến những buổi họp Technical. Không phải để thể hiện, mà mình quan sát cách họ tranh luận, cách họ ra quyết định và cả những "joke" nội bộ của họ. Việc này giúp mình định hình tính cách của mỗi người và chọn ra cách làm việc phù hợp nhất đối với họ.

Việc này giúp mình không bị "hớ" khi phát biểu và dần dần xây dựng được sự tin tưởng từ team.

4. Đào bới quá khứ để bảo vệ tương lai

Đây là phần quan trọng nhất - Đừng tin hoàn toàn vào những gì bạn đọc được trên Backlog. Tài liệu có thể cũ, nhưng con người thì không (hoặc ít nhất là ký ức của họ).

Mình đã dành nhiều thời gian để gặp với những người quản lý backlog cũ hoặc các Lead lâu năm. Câu hỏi chủ yếu của mình là: "Tại sao chúng ta LÀM cái này và tại sao chúng ta KHÔNG LÀM cái kia?".

Tips cho việc tiếp nhận sản phẩm:

Đối với những nhân sự sắp nghỉ hoặc đã chuyển team, mình luôn chuẩn bị một file Framework để "vắt kiệt" kiến thức của họ:

• Phần 1 - Pitfalls: Những tính năng nào nhìn thì dễ nhưng đụng vào khó trong hệ thống?
• Phần 2 - Những dự định dở dang: Bạn định làm gì tiếp theo? Tại sao lúc đó chưa làm? (Do thiếu resource hay do sếp không duyệt…?)
• Phần 3 - Stakeholders "khó": Ai là người có tiếng nói nhất trong những quyết định về tính năng này?

Việc này mình nghĩ nó chiếm đến 50% thành công của mình trong tháng đầu tiên. Nó giúp mình tránh được việc không đáng xảy ra.

5. Những việc khác mình đã làm và mình nghĩ bạn cũng nên thử

Ngoài 4 điểm chính trên, đây là vài "mẹo nhỏ" giúp mình sống sót trong môi trường 50 người:

A. Coffee Chats không bàn công việc

Đừng chỉ gặp mọi người khi có Issue. Hãy mời một bạn Dev hay một bạn Designer đi uống cafe/trà đá chỉ để hỏi về sở thích của họ. Trong một team lớn, sự kết nối cá nhân (Personal Connection) là chất bôi trơn giúp quy trình vận hành trơn tru hơn.

B. Xây dựng "Bản đồ quyền lực" (Stakeholder Mapping)

Trong team 50 người, không phải ai cũng có quyền quyết định như nhau. Hãy xác định xem ai là "Informer" (người cần biết tin), ai là "Approver" (người chốt deal), và ai là "Influencer" (người có tiếng nói thầm lặng).

C. Ghi chép mọi thứ

Với quá nhiều thông tin, trí nhớ của bạn sẽ phản bội bạn. Mình dùng một cuốn sổ (hoặc Notion) để ghi lại tất cả những từ lóng, tên dự án viết tắt và cả tên... con mèo của đồng nghiệp.

"The shortest pencil is longer than the longest memory."

Kết luận

Chuyển từ team 10 lên 50 người không chỉ là tăng về số lượng, mà là sự thay đổi về tư duy. Bạn không còn là một người "tay hay làm" (doer) thuần túy nữa, mà dần trở thành một "người điều phối" (orchestrator).

Đừng vội vàng "hòa tan" đến mức mất đi bản sắc của mình, nhưng cũng đừng quá "hòa nhập" mà quên mất rằng mình vào đây để mang lại giá trị mới. Hãy cứ giữ tinh thần của một người đi khám phá: tò mò, khiêm tốn và luôn sẵn sàng điều chỉnh cánh buồm.

Những tháng đầu tiên của mình đã trôi qua như thế đấy. Còn bạn, bạn có kỷ niệm nào đáng nhớ khi lần đầu gia nhập một team lớn không?