Có nhiều điều để dự án bị chậm hơn kế hoạch mặc dù kế hoạch sinh ra có nhiều biến số chỉ là cảm tính. Tuy vậy với vai trò là một thành viên của team, bạn làm điều tốt nhất có thể để hài lòng sếp và hài lòng khách hàng. Dự án có thể trở nên nhanh hơn nếu như một vài chuyện sau không xảy ra:
Tôi bắt đầu tự án bằng việc học Hasura và sau 2 tháng xây features nháp, CTO từ phía khách hàng có báo rằng mức giá Hasura đề nghị là quá cao và chúng ta sẽ xây bằng các cộng cụ thông thường (ở đây là MongoDB thay cho Hasura). Vì thế mà các api cũ cùng dữ liệu trở nên vô dụng nếu không migrate và bản thân migration lại là thêm 1 việc.
Thực tế mà tôi trải qua không phải là thêm người mà thực ra là có những thành viên rời đi và những thành viên khác được thay vào vị trí trống. Những người đi có thể vì tác phong làm việc không đạt yêu cầu hay yêu cầu từ phía khách hàng mập mờ khiến họ không hài lòng với trải nghiệm làm việc. Những người mới đến mặc dù họ đều có năng lực khá thì việc phải cài đặt, giải thích cấu trúc code, làm quen với conventions… khiến họ chậm lại và không thể xây features như kỳ vọng.
Rào cản ngôn ngữ. Khách hàng là người Ấn Độ, có đôi khi chúng tôi không thực sự nghe được họ phát âm Tiếng Anh. Một thời gian sau chúng tôi nhận ra rằng Microsoft Team có tính năng live transcript khá hiệu quả.
Rào cản trong tác phong làm việc. Có thể có nhiều lý do để đồng nghiệp của tôi trở nên kém hiệu quả. Thực ra chỉ có 2 điều khiến tôi rất khó chịu. Thứ nhất là anh ấy trả lời tin nhắn rất chậm, nếu nhanh là 1-2h sau khi tôi nhắn còn thường có thể là tôi nhắn từ sáng và đến gần chiều anh ấy trả lời. Điều thứ hai là anh ấy làm nhầm solutions mà chúng tôi đã nhất trí. Điều này khiến tôi buộc phải hoặc là yêu cầu anh ấy làm lại hoặc là tự tay làm lại features này. Nếu không tôi sẽ không thể tiếp tục với công việc của mình.
Ở một thái cực ngược lại, tôi có cho mình một đồng nghiệp cầu toàn. Anh bạn này sẽ nghĩ đến những trường hợp giới hạn (edge cases) mà người dùng thực hiện. Anh ấy sẽ đặt câu hỏi và lật đi lật lại vấn đề cho đến khi chúng tôi có 1 giải pháp hoàn thiện hoặc mọi mâu thuẫn được xử lý. Tôi thích điều này vì bản thân tôi đôi khi không nhận ra những giới hạn vê thiết kế sẽ là rào cản cho chúng tôi về lâu về dài. Từ góc nhìn của anh bạn mà tôi nhận ra rằng có những điều chỉnh là cần thiết. Đây cũng là sự đánh đổi tự nhiên về tốc độ nếu chúng tôi muốn sự an toàn và ổn định của hệ thống.
Nhóm của tôi có 1 cấu trúc phẳng. Ở đây không ai là lãnh đạo về công nghệ nên mọi quyết định về các thư viện hay các cài đặt đều mang tính dân chủ. Ý kiến được đưa ra và tranh luận. Khi mọi mâu thuân và khúc mắc được xử lý, chúng tôi sẽ bắt đầu dựng tính năng. Cái hay của cấu trúc này mà tôi thích nhận là không có sự gò bó mà một lãnh đạo tài năng áp đặt lên bạn. Trong suốt 4 tháng qua tôi gần như luôn chọn công việc mà tôi cảm thấy thú vị. Cái dở là có những lúc chúng tôi mất công tranh cãi, thảo luận những phương án mà không đưa ra quyết định trong khi 1 lãnh đạo tài năng sẽ nhanh chóng chỉ cho chúng tôi con đường.
hgn's note