#8 Khi knowledge nằm trong đầu một người là lúc team bắt đầu có vấn đề

Không biết mọi người thế nào, chứ mình là một người rất thích chia sẻ kiến thức và cũng muốn được nghe người khác chia sẻ. Mình dành nhiều thời gian để đọc blog kỹ thuật, những chia sẻ kiến thức, tư duy và mình cảm thấy biết ơn những người đã chia sẻ. Có những thứ hoàn toàn miễn phí, có trả phí nhưng những giá trị nó mang lại đã giúp đỡ mình rất nhiều.

Những thứ mình đã trải qua

Mình cũng đã làm trên nhiều dự án, làm việc với nhiều đồng nghiệp, ít kinh nghiệm có, nhiều kinh nghiệm có, siêu sao cũng có. Có những dự án, những logic business chỉ nằm trong đầu của một số người, cứ có vấn đề gì lại phải nhắn tin hỏi làm như này có đúng không, làm như kia có đúng không. Rồi nhiều khi code xong rồi lại không đù so với yêu cầu nghiệp vụ, phải làm lại từ đầu. Thời gian trôi đi, team cũng thay máu liên tục nhưng nút thắt vẫn nằm ở đó, không có ai thay thế.

Chưa cần đi sâu vào khía cạnh logic business, trong hệ thống IT của bất kỳ một tổ chức nào cũng vậy, cũng sẽ có những tip chỉ một vài người biết. Đơn giản như log trong pipeline, hay hệ thống architect cloud, hoặc debug trong hệ thống monitoring, một khi có vấn đề xảy ra, team lại phải đi hỏi người đang quản lý cái hệ thống đó đê debug.

Hỏi lần đầu lần thứ hai thì không sao, nhưng cùng một vấn đề mà hỏi nhiều lần thì rõ ràng team đang có vấn đề, phải xem xét lại.

Hệ quả dễ thấy

Cái đầu tiên là mất thời gian kinh khủng. Bạn cứ tưởng tượng rằng, khi bạn hỏi một ai đó, thì cũng phải gửi tin nhắn hoặc nói chuyện, rồi nhắn tin qua lại giải thích vấn đề, rồi đợi người kia giải quyết vấn đề rồi báo lại. Nhưng đó là trường hợp lý tưởng nhé, mình đã từng tạo một ticket để debug một lỗi, nhưng lại rơi vào im lặng, có thể người chịu trách nhiệm đang đi du lịch (sorry, time for holiday).

Cái thứ hai là Team phụ thuộc vào một người hoặc một vài người chuyên biệt nào đó. Nếu người đó vẫn còn ở đấy, đi làm thì không sao, nhưng lỡ người đó đi du lịch hoặc tệ hơn là nghỉ việc, thì công ti phải cuống cuồng đi tìm người thay thế để chuyển giao, mà chuyển giao công việc thì sao có thể nói hết được những gì người đó nắm trong đầu từ nhiều năm. Người được chuyển giao nhiều khi cũng là người mới, hệ thống còn chưa nắm hết nói gì đến những thứ quan trọng trong đầu của một người làm lâu năm.

Cái tiếp theo là mọi người trong team không thể cùng tiến bộ và không cảm thấy có thành tựu.Mới hôm qua mình nói chuyện với một người bạn thân, bạn có nói một câu rất hay:

Chỉ khi bản thân cảm thấy có thành tựu, thì người ta mới cố gắng, còn khi cảm thấy đã mất giá trị, thì người ta sẽ làm hời hợt

Mình thấy câu này rất đúng, cùng tiến bộ, cũng là một cách chia sẻ công việc, trách nhiệm, thay vì ôm hết việc về một người, nên chia sẻ cho nhiều người cùng biết và cùng làm với mình.

Tư duy mình nhận ra

Nên chia sẻ kiến thức và kinh nghiệm cho người khác

Bản thân mình cũng từng là một junior nhận được sự chia sẻ đúc kết từ nhiều người, vậy tại sao khi mình có kiến thức rồi thì mình lại không chia sẻ cho người ít kinh nghiệm hơn ? Việc chia sẻ này không làm mình kém đi hay giảm khả năng cạnh tranh mà ngược lại. Giúp người khác có thêm kiến thức, kỹ năng, và cũng giúp mình một lần nữa củng cố lại kiến thức. Nhiều khi trong quá trình chia sẻ, chính mình lại nhận ra là mình vẫn còn thiếu sót, và có thể tìm hiểu sâu hơn nữa. Dù bạn là người nhiều kinh nghiệm, hoặc ít kinh nghiệm, thử chia sẻ cho người khác, bạn sẽ thấy điều kỳ diệu.

Không ngừng học hỏi

Dù bạn là người mới ra trường, hay là senior, cũng đều nên giữ tinh thần học hỏi, cầu tiến. Với bản thân mình, mình luôn nghĩ trong đầu một quan điểm: Mình chẳng là gì cả. Cái này cũng không phải hạ thấp bản thân, bi quan, mà thực sự đó là sự thật. Có những thứ mình nghĩ là mình đã nắm rồi nhưng càng đào sâu thì càng mờ mịt (như tìm hiểu về Kubernetes vậy =))). Mình giòi còn có người khác giỏi hơn. Lĩnh vực này mình giỏi nhưng nhiều lĩnh vực khác thì mình cũng chỉ là con số 0 mà thôi.

Cố gắng giải quyết vấn đề trước khi hỏi người khác

Cái này giúp mình khá nhiều. Khi có một vấn đề (bug chẳng hạn) xảy ra, thay vì đọc log qua loa rồi hỏi người quản lý hệ thống hoặc người có kinh nghiệm hơn, thì mình thường tìm hiểu đến cùng nguyên nhân, khai thác triệt để những gì mà mình hiện có và đang kiểm soát được, tìm cách giải quyết vấn đề. Chỉ hỏi trong trường hợp mình không có đủ thông tin cần thiết hoặc mất quá nhiều thời gian để debug trong khi lỗi khẩn cấp, cần tìm ra lỗi nhanh. Một khi nhận được câu trả lời thì mình ghi nhớ lại, tránh hỏi lại lần thứ hai, mất thời gian của cả hai.

Tò mò

Khi mình được công ty cấp quyền truy cập vào cái gì đó, mình luôn tò mò xem nó có gì trong đó, để khi có lỗi xảy ra, rất nhanh mình có thể tìm đến đúng chỗ cần tìm. Ví dụ đơn giản mình join vào dự án, source code là thứ mình sẽ được tiếp xúc nhiều nhất, nhiều khi bây giờ hỏi cái method này ở class nào, mình cũng còn nhớ, tác dụng của nó là gì. Không cần phải quá chi tiết, chỉ cần biết nó ở đó và nhiệm vụ của nó. Việc debug sau này sẽ dễ dàng hơn rất nhiều lần.

Hay khi mình có quyền truy cập vào hệ thống AWS dev của công ti (với quyền readonly thôi) nhưng mình cũng xem các services đang chạy nó là gì, rồi mỗi tháng công ti phải trả bao nhiêu trên từng services.

Những sự tò mò đó sẽ được tích luỹ dần dần, và không sớm thì muộn, mọi thứ như đang nằm trong lòng bàn tay của mình vậy, khi có lỗi xảy ra, bạn có thể xác định nguyên nhân nằm ở đâu thay vì phải phán đoán rồi debug tốn kém thời gian.

Nên làm gì

Mọi người thường nói, nên viết documentation cho dự án. Điều đó đúng nhưng nếu viết một cách hời hợt thì sẽ thành thảm hoạ. Vừa mất thời gian, vừa có thể dễ gây nhầm lẫn. Hi vọng khi AI phát triển, việc viết documentation cho dự án sẽ dễ dàng hơn nhiều. Trong quá trình làm việc cùng nhau, nên chia sẻ dần dần những logic business, mọi người cùng biết, làm việc sẽ hiệu quả hơn nhiều so với mọi thứ chỉ nằm trong đầu một người.

Tổ chức thường xuyên các buổi chia sẻ: cả về logic business cũng như Tech, hoặc tất cả mọi thứ. Người có kinh nghiệm chia sẻ cho những người mới hoặc người không biết. Có như thế, mọi người mới có thể san sẻ công việc, chia sẻ trách nhiệm dần dần. Một cái đầu làm sao bằng nhiều cái đầu được, nhiều khi còn sửa lỗi sai giúp vì không phải lúc nào một cái đầu cũng minh mẫn.

Mọi người nên chủ động suy nghĩ đến cùng cho công việc của mình. Như vậy vừa có kỹ năng, lại rèn được tư duy. Thường xuyên cập nhật các kiến thức bên ngoài (blog, hỏi AI).

Kết

Việc giữ những kinh nghiệm cho riêng mình không khiến bạn giàu hơn, nhưng chắc chắn việc chia sẻ kiến thức cho người khác sẽ khiến mình nhàn hơn, haha (that’s right!!)

Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.