Như đã đề cập ở Agile (1), Agile (2) viết về cách Py ứng dụng Agile như thế nào trong cuộc sống. Có lẽ đúng như một câu nói từng phổ biến “Cách bạn làm một việc cũng là cách bạn làm mọi việc”, vì dành hơn 40 giờ/tuần để “tiếp xúc” với con người và môi trường Agile nên một cách tự nhiên, thì cũng dễ hiểu vì sao lối tư duy này dần trở thành một phần mặc định trong não.

Tương tự như Agile (1), trong bài viết này, Py cũng sẽ không giải thích thuật ngữ, luận giải quan điểm… – hay nói chung là những gì thiên về lý thuyết, mà chỉ là cách Py đã ứng dụng và ghi lại bài học của chính mình. Nên mong rằng ít nhất bạn đã xem qua Agile Manifesto để đảm bảo chúng ta đang chia sẻ cùng một “ngữ cảnh”.

Individuals and Interactions over Processes and Tools
Con người và tương tác quan trọng hơn quy trình và công cụ

Làm việc trong ngành tech giúp Py nhận ra một điều: điều ý nghĩa nhất (với Py) khi làm việc với con người, là làm được nhiều hơn những gì mình từng nghĩ mình có thể. Dù đã đọc nhiều sách, nghe nhiều podcast, nhưng phải đến khi thật sự “cảm” được điều này qua từng lần phối hợp, từng lần tranh luận, từng lần cùng nhau đi đến kết quả – Py mới dám tự hào nói rằng: Py thích làm việc với con người. Ở thời điểm hiện tại, khi tự động hóa và AI có thể giúp xử lý công việc nhanh chóng và hiệu quả, thì những nghề giải quyết vấn đề – như Product Owner – lại càng có nhiều “đất” để sáng tạo. Vì cách tiếp cận bài toán không còn là tìm đúng công cụ, mà là hiểu rõ bản chất vấn đề và phối hợp cùng những con người khác nhau để đi đến một giải pháp thực tế.

Chính vì vậy, tương tác không chỉ là trao đổi thông tin. Mà là nền móng để hiểu sâu, để đánh giá tốt hơn những điều nằm ngoài dữ liệu. Không giống như lý thuyết vốn mang tính tuyến tính và có phần khô khan, con người có thể mở ra những góc nhìn mới, giúp ta xử lý vấn đề một cách mềm mại và sáng tạo hơn.  Dần dà, Py thấy mình chủ động hỏi han nhiều hơn, lắng nghe nhiều hơn – không chỉ trong team, mà cả ngoài công việc. Những kết nối chân thành thường không hiện lên trong sprint report, nhưng lại là thứ giữ nhịp cho team khi mọi thứ trở nên rối ren.

Và tương tự như vậy, Py học cách nhìn người thân, bạn bè như những stakeholder quan trọng – không chỉ xuất hiện khi cần “support”, mà cần được quan tâm và thấu hiểu mỗi ngày.

Responding to Change over Following a Plan
Phản ứng với thay đổi quan trọng hơn việc bám sát kế hoạch

Py từng nghĩ: kế hoạch chi tiết là dấu hiệu của sự chuyên nghiệp. Chỉ là, sau nhiều năm, Py nhận ra mình không “plan” nhưng vẫn luôn “nghĩ” – và có khi, lại tận hưởng cả những lần chệch khỏi đường ray. Dường như, kế hoạch được sinh ra là để phá vỡ. Và thay vì rập khuôn theo lộ trình định sẵn, việc thay đổi có định hướng thường lại đưa mình đến đích nhanh hơn – hoặc ít ra là đỡ lạc hơn – so với việc mãi chần chừ vì không biết nên đặt bước đầu tiên ở đâu.  

Thật ra, “thay đổi” có khi là thứ duy nhất… không bao giờ thay đổi. Nên với Py, “plan to change” mới là cách tiếp cận hợp lý nhất – trong một thế giới nơi mọi thứ đều chưa rõ ràng: từ sự phát triển không thể đoán định của AI, đến những tầng tiềm thức của chính mình còn chưa được khai phá.

Trong đời sống cá nhân cũng vậy. Có những điều không đi theo lộ trình: công việc thay đổi, dự định bị hoãn, biến cố trong các mối quan hệ… Nhưng thay vì – như đã từng – hoảng loạn, Py học cách tiếp cận mỗi “thay đổi” như một biến số trong backlog: cần được xem xét, đánh giá, rồi điều chỉnh hướng đi cho phù hợp.

Không phải mọi thứ đều phải bám sát “plan”, miễn là mình vẫn giữ được đích đến – thì mỗi bước lệch nhịp cũng có thể là một phần tự nhiên trong hành trình.

Working Software over Comprehensive Documentation
Giá trị sử dụng thực tế quan trọng hơn tài liệu chi tiết

Những ngày đầu đi làm, Py từng khá tự ti vì không học đúng chuyên ngành. Py không biết nên bắt đầu từ đâu, càng không chắc đâu là “cách tiếp cận chuẩn” – theo kiểu phải có nền tảng lý thuyết cụ thể, có sẵn quy trình và bước đi rõ ràng. May mắn là ở thời điểm đó, Py gặp được một người anh mentor – một PM cực kỳ kỹ tính về “mindset” lẫn “toolset”. Anh là người kiên nhẫn hướng dẫn Py trong những tháng đầu tiên chập chững vào nghề – và đến tận bây giờ, vẫn luôn là người Py tìm đến mỗi khi thấy mình cần một cú hích về tư duy.

Trở lại với “tài liệu” theo nghĩa đen, cách Py viết docs cũng thay đổi theo thời gian – không còn rập khuôn mà linh hoạt hơn, phù hợp với cách vận hành của từng scrum team cụ thể. Nhưng có một nguyên tắc Py luôn giữ: tài liệu được tạo ra là để đảm bảo sự đồng thuận – giữa các bên, về những gì sẽ được xây dựng. Có nghĩa là, form có thể thay đổi, miễn là sứ mệnh của nó vẫn được đảm bảo.

Trong đời sống cá nhân cũng vậy. Có những thứ “hình thức” mình từng nghĩ là quan trọng – như viết journal phải đúng template, dùng đúng app, hoặc phải đều đặn mỗi ngày mới gọi là journaling. Nhưng thật ra, journal chỉ là công cụ. Còn mục tiêu thực sự – là dành thời gian để lắng nghe chính mình, để giữ lại những điều trân quý thêm một chút nữa, và nếu may mắn – có thể nhìn thấy được một thông điệp nào đó trong chuỗi những dòng chữ tưởng chừng rời rạc ấy.

Nên bạn không cần một cuốn sổ thật đẹp, một bộ plan tài chính bài bản, hay một tracker chỉn chu. Chỉ cần bắt đầu từ bất cứ đâu, bất cứ định dạng nào phù hợp với bạn ở hiện tại. Quan trọng nhất vẫn là đích đến – và cách bạn chọn đi đến đó.

Customer Collaboration over Contract Negotiation
Hợp tác với khách hàng quan trọng hơn đàm phán hợp đồng

Trong “mối quan hệ” với người khác – từ gia đình, bạn bè đến đồng nghiệp – Py tập cho mình thói quen chậm lại, để hiểu sâu và đúng hơn mong muốn thực sự của đối phương. Bỏ qua những lớp vỏ bên ngoài – như kỳ vọng của mẹ, lời khuyên của bạn bè, hay những request rập khuôn từ stakeholders – cuối cùng vẫn là một “want” nào đó đang đợi được lắng nghe và đáp ứng. Việc tranh luận đúng – sai, câu chữ – ngữ nghĩa, đôi khi chỉ khiến mọi thứ trở nên nặng nề hơn.

Hình như đây là mindset của những người làm service, và trong hình dung của Py thì PO là một nghề như vậy. Không chỉ dừng lại với người khác, Py dần học cách nhìn chính mình như một “khách hàng” quan trọng – người cũng cần được hỏi han, chăm sóc và thấu hiểu. Có những lúc Py mệt, nhưng vẫn ép mình “phải cố thêm một chút”. Rồi Py học cách dừng lại, và tự hỏi: Hôm nay mình thật sự cần gì? – nghỉ ngơi, một bữa ăn đàng hoàng, hay chỉ đơn giản là một lời công nhận nhỏ. Học cách cộng tác với chính mình, Py thấy nhẹ lòng hơn. Không cần mặc cả với cảm xúc, cũng không cần cố gắng trở nên hoàn hảo. Chỉ cần đồng hành – như một PO hiểu rõ nhất “người dùng” của cuộc đời mình.

Dĩ nhiên, không phải lúc nào Agile cũng là lựa chọn tốt nhất. Và Py cũng không có ý thần thánh hoá nó. Chỉ là, khi chọn thông điệp để chia sẻ, Py muốn tập trung vào những điều tích cực – những điều đã và đang góp phần làm cho công việc, và cả cuộc sống, trở nên “thở” được hơn.

Thật ra, Py từng đùa với team: “Em xin lỗi, nhưng PO của mọi người trong sprint này gia trưởng nha.” – để minh họa cho việc: linh hoạt quá đà đôi khi cũng không phải là điều hay. Có lẽ là trong bài viết nào đó sắp tới đây Py sẽ kể về những đoạn “gia trưởng” này.

---

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này. 

Chúc bạn nhiều may mắn và bình an.

Anpy