Beyond Tasks: How I "build impact" in Fintech

Trong môi trường Financial Technology, mình nhận ra rằng “hoàn thành task” chỉ là điểm bắt đầu. Điều tạo nên giá trị thực sự không nằm ở việc làm xong bao nhiêu đầu việc, mà là mình đã góp phần giúp sản phẩm tốt hơn, người dùng hài lòng hơn và đội ngũ vận hành hiệu quả hơn như thế nào.Khi mới tham gia dự án Fintech, mình chủ yếu tập trung vào việc xử lý task được giao: viết test case, kiểm thử chức năng, log bug và theo dõi tiến độ fix lỗi. Ban đầu mình nghĩ chỉ cần hoàn thành đúng deadline là đủ.  Nhưng sau một thời gian làm việc, mình nhận ra nếu chỉ “đợi được giao gì làm nấy” thì rất khó phát triển và cũng khó tạo ra giá trị thật cho sản phẩm. Càng làm, mình càng nhận ra đặc thù của Fintech khác với nhiều lĩnh vực khác: chỉ một lỗi nhỏ liên quan đến giao dịch, số dư hay bảo mật cũng có thể ảnh hưởng lớn đến trải nghiệm và niềm tin của người dùng.  Từ đó, mình bắt đầu thay đổi cách làm việc. Thay vì chỉ test theo yêu cầu có sẵn, mình chủ động tìm hiểu nghiệp vụ tài chính, luồng thanh toán, logic xử lý giao dịch và hành vi thực tế của người dùng. Mình học cách đặt câu hỏi: Nếu hệ thống mất kết nối giữa lúc thanh toán thì sao?  Nếu người dùng bấm thanh toán nhiều lần liên tiếp thì sao?  Nếu dữ liệu trả về chậm hoặc sai định dạng thì điều gì sẽ xảy ra? Chính tư duy đó giúp mình phát hiện thêm nhiều edge case và bug tiềm ẩn trước khi sản phẩm được release. Có những lỗi không nằm trong checklist ban đầu nhưng lại ảnh hưởng trực tiếp đến trải nghiệm người dùng hoặc độ an toàn của hệ thống.Có giai đoạn team chạy deadline khá gấp, tài liệu không đầy đủ, requirement thay đổi liên tục. Lúc đó mình không chỉ test theo checklist nữa mà bắt đầu tự tìm hiểu flow nghiệp vụ để hiểu hệ thống đang hoạt động như thế nào. Ví dụ với một chức năng thanh toán, mình không chỉ test case happy case mà còn thử những tình huống người dùng thật có thể gặp: Mạng chập chờn giữa lúc thanh toán,  Bấm thanh toán nhiều lần,  Chuyển màn hình giữa chừng,  Dữ liệu trả về chậm hoặc sai format. Nhiều bug mình tìm ra không nằm trong tài liệu nhưng nếu lên production thì ảnh hưởng khá lớn đến trải nghiệm người dùng. Có lần mình phát hiện trường hợp giao dịch bị tạo trùng khi người dùng bấm liên tục vì hệ thống xử lý chậm. Dev ban đầu nghĩ khó xảy ra, nhưng sau khi test lại bằng API và log dữ liệu thì đúng là có thể phát sinh thật. Sau đó team phải bổ sung xử lý duplicate transaction trước khi release.Ngoài công việc testing, mình cũng cố gắng học thêm những thứ giúp công việc hiệu quả hơn, đóng góp nhiều hơn cho team:Chủ động review flow nghiệp vụ cùng BA và Dev để hiểu vấn đề từ đầu thay vì chỉ đợi đến lúc có bug mới xử lý Đề xuất cải thiện quy trình test để giảm lỗi lặp lại  Học SQL để tự kiểm tra dữ liệu thay vì phụ thuộc hoàn toàn vào Dev  Học test API để verify logic backend   Tìm hiểu automation để tăng hiệu quả regression test Mình nhận ra rằng giá trị của một người làm IT không chỉ nằm ở kỹ năng kỹ thuật, mà còn ở tinh thần chủ động học hỏi và khả năng nhìn vấn đề từ góc độ sản phẩm và người dùng.Hành trình “tạo dấu ấn” của mình trong Fintech không phải là làm điều gì quá lớn lao, mà là từng bước làm tốt hơn mỗi ngày: suy nghĩ nhiều hơn một chút, kiểm tra kỹ hơn một chút và luôn cố gắng tạo ra sản phẩm ổn định, an toàn hơn cho người dùng. Đó cũng là điều khiến mình thấy công việc IT không chỉ là hoàn thành task, mà là đang góp phần xây dựng niềm tin trong môi trường tài chính số.Có thể những việc đó không quá nổi bật, nhưng mình nghĩ chính sự chủ động và tinh thần làm nhiều hơn một bước đã giúp mình trưởng thành hơn trong công việc IT nói chung và Fintech nói riêng. 

Yes, you are making it happen!  Đặt câu hỏi nhé: Sáng nay bạn trả tiền ăn sáng bằng gì ? Nếu câu trả lời là Apple Pay, Google Pay, Wallet hay QR Code... Thì bạn đang góp phần thúc đẩy fintech tại Việt Nam và Đông Nam Á này đâý nhé. Thực tế là "Ví số" đã thay Ví da! Ít năm trước, trả tiền bằng thẻ tín dụng rất là "Tây", người Việt mình thì cứ móc tiền mặt cho nhanh... Nay thì app đặt xe, momo, thanh toán QR  — mọi thứ được thực hiện trên điện thoại đã thành quen rồi. Và Việt Nam không chỉ bắt kịp, mà đang dẫn đầu khu vực trong tỷ lệ tiếp nhận thanh toán số ở ĐNA này. Disruptive technology tìm thấy thị phần lớn ở đây không phải vì người Việt dễ dãi, mà vì chúng ta nhanh nhạy với mọi giải pháp thực sự mang lại giá trị so với các nước khác trong khu vực. Trạm kế tiếp chính là: Thanh Toán Bằng QRNapas VietQR, AliPay, và nhiều player khác đang tăng tốc trong việc tạo ra các giải pháp ở Vietnam. Khi các tổ chức Chuyển Mạch Switching, Payment Rails và Regional Payment Network mở cửa cho người dùng Việt, QR Pay là điểm đến tất yếu. Có lẽ sau Trung Quốc, Vietnam ta đang dẫn đầu rồi. Tất nhiên, dân làm sản phẩm, đặc biệt là Technical product sẽ luôn ở tuyến đầu, kiến tạo, xây dựng nên trải nghiệm. Nhưng product giỏi đến mấy cũng vô nghĩa nếu thị trường không phản hồi. Và thị trường Việt Nam, người dân Việt Nam đã là nhân tố lớn nhất  đóng góp cho sự chuyển dịch trong Fintech này. Ngay lúc chạm màn hình thanh toán bữa sáng nay, chúng ta đã thay đổi cách mà bankings và financial system vận hành rồi. 

Tôi vào nghề với một niềm tin giản dị: code tốt là đủ. Viết clean code, close ticket đúng deadline, không để bug lên production — vậy là một dev giỏi. Hơn năm năm đi làm, tôi dần trở thành người được giao task khó nhất team. Rồi đến lúc tôi nhảy vào một dự án Fintech.Tuần đầu tiên tưởng bình thường. CRUD vẫn là CRUD. API vẫn là API. Nhưng rồi có một buổi chiều, PM hỏi: "Nếu hệ thống xử lý sai số tiền của người dùng, chuyện gì xảy ra?"Tôi định trả lời theo kiểu dev: "Thì mình log lỗi rồi rollback." Nhưng nhìn khuôn mặt mọi người trong phòng — tôi hiểu câu hỏi đó không phải về technical.Trong Fintech, bug không phải là lỗi phần mềm. Bug là ai đó mất tiền thật.Từ "viết code chạy được" đến "viết code đáng tin"Dev 5 năm dạy tôi nhiều thứ: clean architecture, performance, CI/CD pipeline. Nhưng có một thứ tôi chưa từng nghĩ tới — chi phí của sự sai lầm.Trong các project trước, nếu UI hiển thị sai giá sản phẩm, user reload lại là xong. Còn khi số dư tài khoản hiển thị sai vì một race condition không ai kiểm tra — không có chuyện "reload lại là xong".Tôi bắt đầu đọc lại codebase không phải để hiểu logic làm gì, mà để hỏi: cái này sai được không? Nếu sai, sai đến đâu?Ba câu hỏi tôi học được cách đặt ra mỗi ngày:Nếu request này chạy 2 lần cùng lúc thì sao? — Idempotency không còn là khái niệm học thuật, đó là thứ phải code mỗi ngày.Khi nào transaction thực sự "xong"? — Eventual consistency đẹp trên giấy. Trong Fintech, bạn phải biết chính xác moment nào tiền "an toàn".Ai có thể xem dữ liệu này? — Authorization không chỉ là middleware. Đó là kiến trúc, là audit log, là compliance.Cái tôi tưởng là thừa, hoá ra là thiếu5 năm làm full-stack, tôi quen move fast. Nhưng Fintech dạy tôi một bài học kỳ lạ: đôi khi đi chậm mới là tạo ra value thật.Có lần tôi propose một feature tưởng là "quick win" — cho phép user xem lịch sử giao dịch real-time. Tôi tự tin lắm: websocket, 2 ngày là xong.Nhưng senior trong team hỏi: Audit log ở đâu? Nếu user dispute giao dịch, mình chứng minh bằng gì? Hệ thống fraud detection có nhận được event này không?Tôi ngồi im. Hai ngày của tôi hóa thành hai tuần — và feature đó tốt hơn rất nhiều."Làm nhiều hơn task" không phải là code thêm tính năng. Đó là hiểu tại sao task đó tồn tại — rồi làm cho mục đích đó được phục vụ thật sự.Khi dev học nói chuyện với người không biết codeMột trong những thay đổi lớn nhất không liên quan đến keyboard. Đó là học cách giải thích.Trong Fintech, quyết định kỹ thuật ảnh hưởng đến compliance, đến risk, đến tiền thật. Bạn không thể chỉ nói "tôi dùng optimistic locking để handle concurrent write" rồi kết thúc. Bạn phải nói được: "Nếu không có cơ chế này, hai người có thể rút cùng một số tiền lúc 3 giờ sáng và cả hai đều thành công."Kỹ năng dịch technical sang business impact — không ai dạy trong trường. Tôi học được từ những buổi họp awkward, từ những lần bị hỏi ngược mà không trả lời được.Công thức tôi đang tập dùng: [Quyết định kỹ thuật] giúp/ngăn chặn [điều gì xảy ra với người dùng], điều mà nếu không có sẽ gây ra [hậu quả cụ thể].Dấu ấn không nằm ở số dòng codeLần đầu tiên tôi cảm thấy mình thật sự tạo ra giá trị — không phải khi ship một feature phức tạp. Mà là lúc tôi ngồi cùng đội fraud analyst, lắng nghe họ mô tả workflow thủ công làm mỗi buổi sáng, rồi nói: "Mình có thể tự động hoá bước này."Feature đó chỉ tốn 3 ngày code. Nhưng để biết cần làm gì, tôi mất 2 tuần ngồi hiểu bài toán. Đó là thứ 5 năm trước tôi sẽ không làm — vì "đó không phải task của tôi".Fintech không cần thêm người viết code. Fintech cần người hiểu rằng code là phương tiện, không phải đích đến.Hành trình từ "dev hoàn thành task" đến "người tạo ra dấu ấn" bắt đầu bằng một câu hỏi rất đơn giản: Tại sao cái này quan trọng?Khi bạn có câu trả lời cho câu hỏi đó — mọi dòng code bạn viết ra đều có trọng lượng hơn.