Ước gì có mình nghe sớm hơn! Đúng, tôi ước gì là có người nói tôi nghe về những điều này sớm hơn, nhưng trải nghiệm mới là thứ khiến tôi thấm thía trọn vẹn cảm giác. Tôi nghĩ các bạn cũng vậy, thực sự đi qua một thứ gì đó mới có thể khiến bạn suy ngẫm thật nhiều về nó, nhưng tôi vẫn sẽ viết xuống đây những điều mà tôi mong là các bạn nên biết và sau này khi trải qua nó ở chốn công sở thì các bạn thay vì “ước gì có người nói mình nghe sớm hơn” thì các bạn sẽ đón nhận nó một cách ung dung hơn.
Trước khi vào nội dung chính, tôi xin tự giới thiệu một chút. Tôi là full-stack developer đang làm việc tại một công ty đa quốc gia có chi nhánh ở TP.HCM. Trước khi vào công ty này làm, tôi đã làm ở một công ty startup của Việt Nam với vị trí front-end developer.
Xin chào, đây là tôi!
Lúc làm ở công ty cũ, những dự án tôi tham gia là những dự án khá nhỏ, với tốc độ xây dựng sản phẩm rất nhanh. Vì đó là những dự án nhỏ và chúng tôi đã có một BA (business analysis) chuyên phân tích yêu cầu từ phía khách hàng nên những gì những developer như tôi quan tâm ở đây là công nghệ, là kỹ thuật.
Tuy nhiên, khi tôi di chuyển qua công ty hiện tại, tôi nhận ra thế giới phát triển phần mềm rộng lớn hơn là những vấn đề về kỹ thuật. Tôi không thể phủ nhận, kỹ thuật là yếu tố rất quan trọng, nhưng không phải bất kỳ thứ gì chúng ta đang cố giải quyết bằng code, bằng design pattern đều đến từ những yêu cầu thực tế sao? Và việc phân tích những gì khách hàng cần để tạo ra một sản phẩm ý nghĩa không phải nên là ưu tiên hàng đầu hay sao?
Team nhỏ của tôi có 20 người đến từ 5 quốc gia khác nhau. Khác với những team làm chủ yếu về sản phẩm cho dự án, team chúng làm integration (tôi không biết dịch như thế nào, nhưng có thể hiểu là việc chúng tôi xử lý dữ liệu trao đổi qua lại giữa các hệ thống khác nhau). Chúng tôi giải quyết việc trao đổi thông tin giữa công ty với công ty, giữa công ty với ngân hàng và giữa công ty với nhà nước. Chúng tôi là team gần như làm về kỹ thuật nhiều nhất so với các team còn lại trong dự án nhưng khi PO (product owner) - người chịu trách nhiệm phân tích yêu cầu từ các bên liên quan và người chịu trách nhiệm giải đáp những thắc mắc trong team chúng tôi đi nghỉ 2 tuần, team chúng tôi gần như bị block hết gần hai phần ba công việc. Nếu PO nghỉ thêm 2 tuần, rất nhiều khả năng chúng tôi không biết mình phải làm gì tiếp theo. Cũng trong thời gian đó, Một số người trong số chúng tôi giả định những gì họ nghĩ là đúng và tiếp tục công việc.
Team tôi, dù không đủ người trong hình (đến từ các nước Việt Nam, Đan Mạch, Trung Quốc, Ba Lan, Anh) và cô gái mặc áo sọc quần đen là tôi!
Trong buổi họp tiếp theo, chúng tôi đã bàn về điều này và đây là những gì chúng tôi đã phải sửa chữa trong team của mình.
Không nên phụ thuộc quá nhiều vào một thành viên. Phải luôn đảm bảo một chủ đề có ít nhất hai người biết về nó để khi một người nghỉ, công việc sẽ không bị đình trệ vì thiếu một mảnh ghép cần thiết. Điều này ứng dụng cho cả việc hiểu yêu cầu phần mềm (dành cho các vị trí BA, PO,...) và lập trình hay các vấn đề khác nhau về kỹ thuật (dành cho các vị trí như developer, software architect,...)
Yêu cầu phần mềm là thứ phải luôn được ưu tiên. Phải đảm bảo bạn hiểu những gì mình phải làm trước khi bắt đầu viết code. Nếu bạn chưa hiểu gì đó hoặc chợt nhận ra một trường hợp nào đó mà PO hay BA chưa nghĩ đến, hãy dừng lại để hỏi thay vì mặc định nó sẽ diễn ra như vậy và dành công sức cho nó.
Chưa dừng lại, đó mới là phần đầu câu chuyện. Khi mọi thứ có vẻ ổn định hơn ở lúc ban đầu thì sẽ có tiếp những sóng gió tiếp theo. Khi làm trong một dự án nhỏ, như tôi đã nói lúc đầu, gần như những gì tôi quan tâm là kỹ thuật, tôi được làm việc với những công nghệ mới nhất, code ít nên được review kỹ càng, thiết kế dự án có thể linh hoạt thay đổi do nó không quá lớn. Nhưng đây sẽ là câu chuyện hoàn toàn khác khi bạn làm việc trong một dự lớn. Và sự thật là bạn sẽ nghe rất nhiều điều phàn nàn, có khi những điều đó lại phát ra từ chính các bạn! Tôi không muốn đưa ra những lời biện hộ, tôi chỉ cố gắng đưa ra một góc nhìn khác, để từ đó chúng ta trở thành những người cẩn trọng với lời nói của chính mình khi xem xét sự việc trước khi buông lời phàn nàn mà thôi!
Khi một ai đó nói rằng dự án dùng công nghệ quá cũ!
Nếu đó là một dự án lớn cần nhiều năm để hoàn thành thì trừ khi bạn tham gia vào đầu dự án, nếu không thì cơ hội để bạn được làm việc với công nghệ mới là rất hiếm. Mọi công nghệ được dùng hiện tại trong dự án có thể là cũ với bạn nhưng đó là công nghệ mới nhất vào vài năm trước. Có thể bạn muốn làm việc với công nghệ mới nhất và bạn muốn nâng cấp mọi thứ lên phiên bản mới nhất để phù hợp với xu hướng công nghệ hiện tại. Nhưng nếu một lần bạn buộc mình phải đứng vào vị trí của người quản lý dự án, bạn có bao giờ cân nhắc đến chi phí và công sức phải bỏ ra so với lợi ích đạt được từ việc đó? Hãy cân nhắc đến nhiều yếu tố hơn là coding để bạn có thể hiểu được tại sao mọi thứ lại diễn ra như cách nó đang diễn ra.
Khi một ai đó phàn nàn rằng code quá là xộn xộn!
Yêu cầu dự án thay đổi liên tục, kéo theo đó là hàng đống thay đổi diễn ra trong code mỗi ngày. Đống lộn xộn đó được tạo ra bởi rất nhiều nguyên nhân: thiếu thông tin tại thời điểm cài đặt, thiếu thời gian do chạy deadline cho kịp release, thêm những trường hợp đặc biệt không dự đoán trước được,…
Khi code quá lộn xộn, chúng ta có nhiều giải pháp: refactor code, hướng dẫn mọi người cách viết code tốt hơn, trao đổi về kỹ thuật trong team nhiều hơn để mọi người nhận thức được vấn đề và tránh làm như vậy trong lần tới,…
Có nhiều cách để bạn có thể cải thiện tình hình thay vì ngồi phàn nàn. Đó là những việc làm có ý nghĩa hơn, nó giúp chúng ta phát triển hơn và đóng góp nhiều hơn để giúp cho đội nhóm của mình làm việc hiệu quả hơn mỗi ngày!
Khi có một ai đó kêu ca rằng thiết kế (design) của hệ thống quá tệ!
Có thể thiết kế tệ mà bạn đang nói tới lại là thiết kế khả thi nhất có thể tại thời điểm mà nó ra đời. Ngoài trình độ và kinh nghiệm của nhà thiết kế hệ thống (architect) thì một trong những yếu tố quan trọng gây ảnh hưởng đến một giải pháp kỹ thuật là thông tin và thời gian.
Nếu họ có nhiều thông tin như hiện tại và có thời gian để suy nghĩ về giải pháp hơn bạn đang có vào 2 năm trước, tôi khá chắc là hệ thống đã không được thiết kế như hiện tại. Ví dụ, nếu biết được hệ thống sẽ có nhiều người dùng và tăng chóng mặt như vậy, thì 2 năm trước, khi thiết kế hệ thống, người ta đã chú ý nhiều hơn đến tính mở rộng (scalability). Hoặc nếu người ta hiểu hết những trường hợp phức tạp về yêu cầu phần mềm như bây giờ thì có lẽ database đã được thiết kế khác đi rất nhiều.
Nhưng đó là nếu như… Khi có nhiều kiến thức hơn, nhiều thông tin hơn, bạn muốn thay đổi nhiều thứ, nhưng đó cũng là lúc có nhiều thứ trở nên phụ thuộc lẫn nhau. Và để thay đổi nó có khi cần một khoảng thời gian dài hơn chúng ta nghĩ. Ở những tình huống tệ hơn, bạn chấp nhận thỏa hiệp với những gì đang diễn ra và chấp nhận là bạn chỉ có thể mang những những kinh nghiệm và mong muốn đó ứng dụng ở một dự án khác nếu bạn có cơ hội mà thôi.
Hy vọng qua những gì tôi viết, các bạn sẽ không còn quá bỡ ngỡ trước những gì rồi sẽ xảy mà sẽ trở nên cảm thông và tìm hiểu nhiều hơn khi nhìn nhận những gì đang diễn ra trong chính công việc của chính mình. Nếu không thể chịu đựng và chấp nhận được một điều gì đó sau khi đã suy nghĩ kỹ thì đâu có quá nhiều lựa chọn để bạn đưa ra quyết định? Hãy thay đổi bản thân và rời bỏ nó!
