tìm hiểu rồi đề xuất

Ta lại cùng đến với một tình huống khác anh A. trải qua

I. Tình huống

📍. Do yêu cầu về nâng cao tính bảo mật (security) cho dự án, A. đã trao đổi và thống nhất với R. cần làm tác vụ (task):

a. Cập nhật OS/middleware cho N. server.

Task này sẽ do Infra team thực hiện.

Việc truyền đạt task từ A. đến Infra (team) diễn ra xuôn xẻ, Infra cũng đã tạo task nội bộ để đối ứng theo yêu cầu: INFRA-72nn Upgrade OS for N Instance

📍. Hai ngày trước ngày thực hiện task trên, A. nhận được liên lạc từ Infra:

b. Hiện tại, N. instance đang sử dụng type t2.micro, đây là dòng Instance type cũ. Infra đề xuất dựng N. intance mới sẽ sử dụng Instance type t3a.micro sẽ có hiệu năng tốt hơn và chi phí cũng rẻ hơn ạ. Nhờ anh báo khách và xin ý kiến của khách về vấn đề này giúp với ạ

. A đọc lại nội dung trên vài lần và suy nghĩ: Ý Infra “xin ý kiến của khách” tức là sao?

Uhm, tức là Infra muốn xin khách hàng (KH) cho phép “dựng N server mới sử dụng type khác với hiện tại” (A. và R. gọi là N. server nhưng Infra thì gọi là N. instance)

Có vẻ Infra muốn xin KH một việc và nội dung của việc đó đã được mô tả.

Vậy cứ thế mà đi xin phép thôi nhỉ?

II. Mọi thứ đều cần căn cứ

Bình thường thì A. đưa task cho Infra làm dựa trên Yêu cầu của khách hàng, Infra sau đó chốt kế hoạch, thực hiện và A. sẽ liên lạc với R. trong quá trình đó. A. hình dung task này cũng như vậy, nhưng có vẻ sự việc đang diễn tiến khác với kỳ vọng của A.

🧭  Theo thói quen BrSE, phản ứng của A. là hỏi “Tại sao?” khi mọi việc diễn ra không theo hình dung hay kỳ vọng.

Vì thế, đầu tiên đơn giản là A. tự hỏi:

c. Tại sao Infra lại muốn làm điều này?

Một nguyên tắc mà A. học được là: trong công việc, mọi thứ đều phải có “căn cứ” của nó. Giống như các hợp đồng đều có vài dòng: Căn cứ vào ….. Nghe nói ví dụ đâu đó có trường hợp nhân viên gây sự cố thiệt hại cho công ty mà không phải bồi thường vì …. công ty chưa có quy định cụ thể, tức là thiếu căn cứ để yêu cầu bồi thường …

Nói đơn giản: (trong công việc) Mọi thứ đều cần có căn cứ (=lý do hợp lý).

Vậy Infra căn cứ vào đâu mà đề xuất việc này ?

III. Căn cứ về mặt nội dung công việc

📍 A. xem lại bối cảnh thì rõ ràng Infra đang tiếp tục câu chuyện liên quan đến task ban đầu:

a. Cập nhật OS/middleware cho N. server

Có điều Infra lại muốn làm:

b. dựng N. server mới sử dụng type khác với hiện tại

📍 “dựng server mới” thì có liên quan gì tới việc “cập nhật OS/ middleware” cơ chứ? A. tự hỏi. Logic của Infra không phải thứ mà một kẻ bình thường như A. có thể hiểu được!

“Tại sao Infra lại muốn dựng server mới?”,

“Tại sao việc này lại giải quyết được yêu cầu Cập nhật OS/ Middleware?”

📍 Với 2 suy nghĩ trên trong đầu, A. viết câu hỏi cho Infra:

d. nếu chuyển sang dùng type mới (t3a.micro) thì OS/ middleware có được lên version mới nhất không?

Infra trả lời:

 Dạ có anh ạ.

Việc update OS/ middleware sẽ cần taọ server mới ạ. Và việc tạo mới này thay vì dùng Instance type t2.micro như server hiện tại thì nên dùng type t3a.micro ạ.

Ra thế, giờ mới rõ logic của Infra vì sao b. lại thoả mãn được a.

OK, tới đây là xác nhận được việc làm b. là phù hợp với mục đích task a. đặt ra. Có cơ sở để đề xuất đến R!

Vậy cứ thế mà đi đề xuất thôi nhỉ?

IV. Căn cứ về mặt thẩm quyền trong công việc

Tạm rời xa tình huống một chút để quay lại một bối cảnh rộng hơn liên quan đến vai trò của BrSE trong dự án.

Công ty của A. có một Job Description (mô tả công việc: JD) cụ thể cho vị trí BrSE, trong đó mô tả BrSE có trách nhiệm:

(Chiều từ KH đến team: )

. tiếp nhận, phân tích, sắp xếp và quản lý các Yêu cầu,

(Chiều ngược lại từ team đến KH:)

. phối hợp với Dev. team để cung cấp các tính năng được Yêu cầu

Hiện tại A. đã tương đối thành thạo loại trách nhiệm đầu tiên, tuy nhiên gần đây, trong bối cảnh toàn bộ công ty phải nâng cao tính bảo mật an toàn thông tin, A. thấy phần công việc liên quan đến loại trách nhiệm thứ hai (từ team đến KH) đang tăng lên tương đối. Ở chiều này, JD chỉ mô tả chung chung “phối hợp với Dev. team”, còn cụ thể thì A. thấy mình phải chủ động giải thích, đề xuất, thương lượng các task từ bản thân Dev. team đưa sang KH.

Khi suy ngẫm 2 loại trách nhiệm nói trên, A thấy ngoài căn cứ về nội dung công việc, còn một loại căn cứ nữa ở đằng sau là về thẩm quyền công việc. Để ý kỹ thì nó thế này:

Chiều từ KH đến team:

さ. KH là người có thẩm quyền đưa ra yêu cầu, BrSE được trao quyền và vì thế đại diện cho KH để triển khai yêu cầu đến team

Chiều ngược lại từ team đến KH:

り. BrSE đại diện cho team để đề xuất/ đàm phán, thương lượng các vấn đề từ team với KH

Nếu như さ là khá hiển nhiên, rõ ràng và tự động (do trong team có mỗi BrSE biết tiếng Nhật) thì り mơ hồ hơn và không tự động (automatic) như vậy.

Không automatic bởi vì có lúc A. chỉ đơn giản xác nhận lại Yêu cầu từ KH, không liên quan đến り. Hơn thế nữa, “đại diện cho KH” nhiều khi đơn giản hơn “đại diện cho team”.

Để có thể làm tốt việc “đại diện cho team”, A. phải hiểu khá kỹ và trả lời được câu hỏi “team là ai?“. Nếu team là “bất kỳ ai trong team”, thì ai trong team cũng có thể đưa ra đề xuất/ kiến nghị …. nhưng khi cần chịu trách nhiệm về incident thì lúc đó không có ai nhận “tôi là team” cả 🙂

Vì thế, trong context “đại diện cho team”, nhất là với những liên lạc quan trọng như đề xuất, phương án nhân sự, báo giá (estimate) … đến KH, câu trả lời cho câu hỏi “team là ai?” sẽ là: “Người có thẩm quyền chịu trách nhiệm về team”. Ở công ty của A. người này là ông Manager (Mgr.) của dự án và là một người cụ thể.

Giờ thì quay trở lại với tình huống nào.

📍 A. nhận thấy task mà Infra đề xuất (dựng N. server mới …) đang ở tình trạng như sau:

. Căn cứ về mặt nội dung công việc đã được xác nhận tại câu trả lời cho d., nhưng

. Căn cứ từ góc độ thẩm quyền thì sao?

📍 Về câu hỏi trên, hiện tại A. thấy task mới được đưa lên từ Infra, trong khi Người có thẩm quyền đề xuất cho KH là Manager của dự án (Mgr.). Từ góc độ thẩm quyền thì như vậy là chưa đủ.

Suy nghĩ thế, A. quyết định đưa vụ việc lên hỏi trực tiếp Mgr.:

e.  nhờ anh C. cho ý kiến về việc này với ạ

(có liên lạc đề xuất trên với KH ko?)

Sau đó Mgr. trả lời A. là đồng ý đề xuất task mà Infra muốn làm sang KH.

V. Đứng từ phía KH để bổ sung thông tin

Đến đây, A. đã có được đầy đủ cả căn cứ về nội dung và thẩm quyền, sẵn sàng “đại diện cho team” đề xuất sang KH.

Vậy đề xuất thôi nhỉ?

Vẫn chưa phải!

Trước đây A. đã từng chuyển nguyên vẹn nội dung từ team đến R. và lần nào cũng nhận được các câu hỏi bổ sung, sau đó cứ hỏi đáp qua lại nhiều lần mới chốt được câu chuyện.

Từ kinh nghiệm những lần đó, A. biết khi xem xét một vấn đề, để quyết định có làm hay không, KH thường cần dựa vào thông tin liên quan đến chi phí (Cost), rủi ro (Risk), lợi ích thu được (Merit) …. Và nội dung được team đưa ra ban đầu thì thường chưa đủ …

📍 Suy nghĩ như vậy, A. hỏi thêm người đề xuất (Infra):

f.  Infra cho hỏi thêm:

. Nếu tiếp tục dùng t2.micro như hiện tại, ngoài vấn đề hiệu năng kém hơn và cost đắt hơn (t3a.micro) thì còn có vấn đề gì khác hay rủi ro gì khác trong tương lai không?

. Việc chuyển sang t3a.micro có phát sinh rủi ro gì ko? t3a.micro đã có thực tế được sử dụng ở dự án khác chưa? Infra team đã điều tra cẩn thận trước khi đề xuất chưa?

Infra trả lời:

. >Nếu tiếp tục dùng t2.micro như hiện tại, ngoài vấn đề hiệu năng kém hơn và cost đắt hơn (t3a.micro) thì còn có vấn đề gì khác hay rủi ro gì khác trong tương lai không?

Vì là t2.micro là loại instance cũ nên có thể sẽ không còn được AWS support trong thời gian tới ạ.

. >Việc chuyển sang t3a.micro có phát sinh rủi ro gì ko? t3a.micro đã có thực tế được sử dụng ở dự án khác chưa? Infra team đã điều tra cẩn thận trước khi đề xuất chưa?

Việc chuyển sang type t3a.micro không có rủi ro gì, các server khác hầu hết đã được sử dụng sang dòng t3a.* ạ

OK. Với các thông tin trên, A. thấy sự việc cũng khá đơn giản, ít rủi ro (risk), lợi ích (merit) thì rõ ràng, đủ để đề xuất sang KH. Let’s go.

Tuy nhiên, một lần nữa, để đảm bảo đúng quy trình cũng như thẩm quyền thì A. nghĩ phải xác nhận nội dung hoàn chỉnh của đề xuất trước khi gửi. Và ai sẽ làm việc đó? Lý tưởng thì người đưa ra đề xuất (Infra) sẽ làm, nhưng thực tế thì A. thường chính là người phải tập hợp thông tin từ các trao đổi dài trên Slack ra một nội dung hoàn chỉnh.

📍 Vì thế, A. đã tự mình tóm tắt lại và nhờ Mgr. xác nhận trước khi gửi cho R.

g.  Xin tổng hợp đề xuất nhanh như dưới:

—–

Liên quan đến task : Update OS/middle cho N. server

Đề xuất: chuyển sang instance mới với type t3a.micro và cài OS/ middleware mới

. Hiện tại, NAT-instance đang sử dụng type t2.micro, đây là dòng Instance type cũ.

. t2.micro có thể sẽ không còn được AWS support trong thời gian tới

. Đề xuất tạo mới server với type t3a.micro

. t3a.micro sẽ có hiệu năng tốt hơn và chi phí cũng rẻ hơn (xem ảnh đính kèm)

. Việc chuyển sang type t3a.micro được đánh giá không có rủi ro gì,

. Các server thuộc cùng account hầu hết đã được sử dụng sang dòng t3a.*

Mong các bạn xem xét và approve đề xuất

——-

Mgr. react OK thì mình sẽ gửi R. nội dung trên nhé

VI. Tóm tắt

Cùng nhìn lại điểm bắt đầu và kết thúc của tình huống:

Các bước đi từ b. đến g. như sau:

1. 📌 BrSE xác nhận căn cứ về nội dung công việc (mục đích của task) đề xuất
2. 📌 BrSE lấy xác nhận của Mgr. về đề xuất để có căn cứ thẩm quyền
3. 📌 BrSE làm rõ thêm về CRM (cost, risk, merit) … của đề xuất
4. 📌 BrSE tổng hợp nội dung hoàn chỉnh và lấy xác nhận của Mgr. lần nữa

Đó là 4 bước mà một BrSE sẽ được kỳ vọng tiến hành đầy đủ. Trong trường hợp một Comtor. thì ít nhất bạn cần được hướng dẫn và tiến hành bước 2.

Bước 2 là một điểm cần được hướng dẫn và follow vì đặc trưng của một Comtor./ BrSE, như đã nói là có 2 mặt đại diện: cho KH và cho team. Một BrSE/ Comtor. cần ý thức rõ và cần có sự nhạy cảm để chuyển qua chuyển lại giữa 2 vai trò này tuỳ theo các tình huống giao tiếp khác nhau.

Bước 3. và bước 4. thì đòi hỏi kinh nghiệm làm việc thực tế. Một Comtor. cũng cần được khuyến khích tự tiến hành bước 3 và 4 trong khả năng của bạn ấy. Như trường hợp của A. thì với bước 3. bạn được trang bị tài liệu với kha khá các ví dụ (sample) đề xuất với nhiều hơn nữa các khía cạnh cần được nêu lên trong đề xuất, vd. như cost về mặt effort thực hiện release/ downtime hệ thống, cost vận hành phát sinh về sau, lịch trình dự kiến… Bước 4. thì đòi hỏi kỹ năng tóm tắt chứ không chỉ đơn thuần là chất đống tất cả những thông tin thu được vào một chỗ.

Cảm ơn đã đọc bài và hẹn gặp lại các bạn ở bài tiếp theo 🎭