Nhắc đến hướng dẫn cài đặt, sử dụng công cụ công nghệ, nhiều người nghĩ ngay tới việc tải phần mềm về rồi bấm next liên tục. Nhưng khi đứng ở vai trò Tech Lead, chúng tôi thấy câu chuyện rộng hơn rất nhiều. Đã có không ít đội ngũ kiệt sức vì chạy theo deadline mà quên mất người trực tiếp viết code cần gì để làm việc tốt. Cách quản lý lấy lập trình viên làm trung tâm ra đời chính từ nỗi trăn trở ấy.
Đây không phải một trào lưu quản trị cầu kỳ. Nó đơn giản là cách sắp xếp công việc sao cho kỹ sư có đủ không gian để làm tốt phần việc của mình. Muốn vậy, bạn cần một bộ công cụ được cài đặt đúng cách, dùng đúng mục đích và được cả đội thống nhất. Thiếu một trong ba yếu tố này, mọi nỗ lực đều dễ tan thành lộn xộn.
Bài viết này tổng hợp từ kinh nghiệm thực tế khi chúng tôi dẫn dắt nhiều dự án phần mềm cho khách hàng vừa và nhỏ. Có giai đoạn deadline dồn dập khiến cả nhóm gần như cạn sức. Cũng có lúc chúng tôi tìm được cách vận hành nhẹ nhàng hơn hẳn. Những trải nghiệm đó là điều chúng tôi muốn chia sẻ với bạn.
Áp lực thật sự của một Tech Lead nằm ở đâu
Khách hàng và bộ phận kinh doanh thường chỉ nhìn vào ngày ra mắt sản phẩm. Họ hiếm khi hình dung một lập trình viên cần bao lâu để xử lý một bài toán logic phức tạp. Khi yêu cầu đổ về dồn dập, người quản lý rất dễ rơi vào bẫy ép tiến độ. Đó là phản xạ tự nhiên, nhưng cái giá của nó thường lớn hơn người ta tưởng.
Hậu quả quen thuộc là đội kỹ sư quá tải. Code được viết vội và lỗi nổ ra ngay sau mỗi lần release. Chúng tôi từng chứng kiến cảnh cả nhóm phải làm thêm cuối tuần chỉ để vá những lỗi lẽ ra đã tránh được từ đầu.
Chúng tôi hiểu bộ phận kinh doanh cũng đang chịu áp lực từ khách hàng, và không phải lúc nào deadline cũng thương lượng được. Vai trò của Tech Lead là đứng giữa hai bên để tìm phương án khả thi nhất. Thay vì chuyển nguyên áp lực xuống đội dev, chúng tôi thường thương lượng lại phạm vi tính năng. Có khi giải pháp chỉ đơn giản là bổ sung nhân sự tạm thời cho giai đoạn nước rút.
Chúng tôi từng nhận một dự án web application cho khách hàng ngành bán lẻ, thời hạn bị rút ngắn gần một nửa so với kế hoạch ban đầu. Nếu ép cả team code ngày đêm, sản phẩm có thể kịp hạn nhưng sẽ đầy lỗi tiềm ẩn. Thay vào đó, chúng tôi ngồi lại cùng đội dev để phân loại tính năng nào bắt buộc, tính năng nào có thể lùi lại. Kết quả là sản phẩm vẫn ra mắt đúng phần quan trọng nhất, còn lập trình viên không phải sống trong trạng thái căng thẳng kéo dài.
Giảm họp, tăng thời gian tư duy sâu cho lập trình viên
Một trong những điều đầu tiên chúng tôi thay đổi là số lượng cuộc họp. Lập trình viên cần những khoảng thời gian liên tục để xử lý logic. Mỗi lần bị ngắt bởi lịch họp, họ có thể mất thêm mười lăm đến hai mươi phút để lấy lại mạch tư duy. Đó là thời gian không ai nhìn thấy trên lịch, nhưng lại ảnh hưởng trực tiếp đến chất lượng code.
Với người làm kinh doanh, một cuộc họp ba mươi phút chỉ là ba mươi phút. Với dev, cái giá phải trả lớn hơn nhiều. Vì vậy, chúng tôi bắt đầu tự hỏi mỗi cuộc họp có thật sự cần thiết hay không. Câu hỏi đơn giản ấy đã loại bỏ khá nhiều buổi họp vốn chỉ để “cho mọi người biết tình hình”.
Chúng tôi chuyển phần lớn buổi cập nhật trạng thái hằng ngày sang báo cáo bằng văn bản trên kênh chat chung. Mỗi thành viên viết vài dòng về việc đang làm, điểm nghẽn nếu có, và việc dự kiến tiếp theo. Nhờ vậy cả nhóm vẫn nắm được tình hình mà không cần ngồi họp mỗi sáng. Những vấn đề thật sự khẩn cấp vẫn được xử lý ngay qua tin nhắn, phần còn lại dev tự sắp xếp thời gian của mình.
Chúng tôi cũng rà soát lại công cụ giao tiếp nội bộ, với mục tiêu tránh việc một thông tin bị lặp ở ba bốn kênh khác nhau. Mọi quyết định quan trọng được ghi lại thành văn bản ở một nơi duy nhất. Nhờ đó, lập trình viên có thể tra cứu quyết định cũ bất cứ lúc nào mà không phải hỏi lại đồng nghiệp.
Hướng dẫn cài đặt, sử dụng công cụ công nghệ để chuẩn hoá quy trình
Muốn quản lý lấy lập trình viên làm trung tâm, hạ tầng kỹ thuật cũng phải hỗ trợ đúng triết lý đó. Chúng tôi kết hợp webhook với CI/CD để tự động cập nhật trạng thái công việc lên bảng quản trị dự án. Khi kỹ sư đẩy code lên hệ thống, công cụ tự kiểm tra lỗi, build và cập nhật trạng thái task trên Jira hoặc Trello. Việc thiết lập ban đầu mất vài ngày, nhưng về lâu dài nó gỡ bỏ rất nhiều thao tác lặp.
Dev không còn phải dừng lại để viết báo cáo thủ công vào cuối ngày. Điều này nghe có vẻ nhỏ, nhưng cộng dồn qua một tháng thì thời gian tiết kiệm được rất đáng kể. Quan trọng hơn, dữ liệu trên bảng luôn phản ánh đúng thực tế, không phụ thuộc vào trí nhớ của ai.
Việc chuẩn hoá tài liệu kỹ thuật cũng quan trọng không kém. Chúng tôi từng tiếp nhận một lập trình viên mới vào dự án đang chạy nước rút, và bạn ấy mất gần cả tuần chỉ để dựng xong môi trường phát triển vì tài liệu cũ đã lỗi thời. Sau lần đó, chúng tôi xây bộ tài liệu nội bộ mô tả từng bước cài đặt, từ hệ điều hành, thư viện cho tới cấu hình máy chủ local.
Giờ người mới chỉ cần một buổi sáng là có thể bắt tay vào code. Cách làm này khá gần với hướng đi chúng tôi từng chia sẻ trong bài lộ trình kỹ thuật giúp doanh nghiệp cắt giảm chi phí vận hành, nơi hạ tầng được chuẩn hoá đúng cách sẽ tiết kiệm rất nhiều thời gian về sau.
Chúng tôi cũng đồng bộ môi trường làm việc bằng một bộ quy trình thao tác chuẩn. Thay vì để mỗi người tự cài phần mềm theo thói quen riêng, cả team thống nhất dùng chung một số thứ cố định. Cùng phiên bản thư viện và framework cho toàn dự án, tránh xung đột khi build chung. Editor và linter được cấu hình giống nhau, để code từ nhiều người vẫn giữ phong cách nhất quán. Quy tắc đặt tên nhánh và công cụ quản lý mã nguồn cũng được thống nhất, giúp việc review không bị rối.
Nhờ đó, lỗi phát sinh do lệch phiên bản giữa các máy gần như biến mất. Chúng tôi không cần ai phải nhớ quá nhiều thứ, vì hệ thống đã làm phần đó giúp mọi người.
Đo hiệu suất bằng giá trị thực, không phải giờ ngồi máy
Đánh giá năng lực lập trình viên luôn là chuyện nhạy cảm. Chúng tôi không đếm số giờ ngồi trước máy hay số dòng code viết ra mỗi ngày. Một kỹ sư giỏi đôi khi chỉ sửa năm dòng code nhưng lại ngăn được một lỗ hổng ảnh hưởng cả hệ thống. Nếu chỉ nhìn vào số liệu bề mặt, chúng ta rất dễ bỏ sót đúng người đang làm việc giá trị nhất.
Vì vậy, chúng tôi nhìn vào giá trị thực. Tính năng có chạy ổn định không, người dùng cuối phản hồi thế nào, và sau khi release hệ thống có ít lỗi phát sinh hơn không. Cách đo này khó hơn việc đếm giờ, nhưng nó phản ánh đúng đóng góp của từng người.
Chúng tôi cũng thiết lập khung giờ giới hạn thông báo, thường là hai buổi mỗi ngày, để lập trình viên có thời gian tập trung sâu. Trong khung giờ đó, kênh chat nội bộ chuyển sang chế độ im lặng, trừ khi hạ tầng gặp sự cố nghiêm trọng.
Ban đầu có thành viên bên kinh doanh hơi khó chịu vì phải chờ lâu hơn mới được phản hồi. Nhưng sau vài tuần, cả hai bên đều thấy chất lượng phần mềm cải thiện rõ rệt, số lỗi phải sửa gấp sau release cũng giảm hẳn. Sự phiền toái ban đầu đã được đền bù bằng một sản phẩm ổn định hơn nhiều.
Lắng nghe phản biện để quy trình tốt lên từng ngày
Chúng tôi không nghĩ Tech Lead là người nắm hết mọi câu trả lời. Người trực tiếp code mỗi ngày mới là người phát hiện sớm nhất những điểm nghẽn, có thể đến từ kiến trúc cũ chưa tối ưu hoặc quy trình review còn rườm rà. Vì thế, chúng tôi duy trì buổi retrospective hai tuần một lần, nơi mọi thành viên được quyền nói thẳng về những bất cập trong cách làm việc.
Có lần một bạn dev junior nêu ý kiến rằng quy trình review code đang ngốn quá nhiều thời gian, vì mọi thay đổi phải qua ba người duyệt liên tiếp. Quy trình này ban đầu được đặt ra để đảm bảo chất lượng, nhưng thực tế lại làm chậm cả tiến độ chung. Ý kiến ấy khiến chúng tôi phải nhìn lại chính quy trình mà mình đã tự tay thiết kế.
Chúng tôi lắng nghe và thử giảm xuống còn hai người duyệt cho các thay đổi nhỏ, còn thay đổi chạm tới hệ thống lõi vẫn giữ ba người. Thời gian review giảm gần một nửa mà chất lượng vẫn được giữ vững. Từ chuyện nhỏ này, chúng tôi học được rằng quy trình tốt nhất là quy trình được điều chỉnh liên tục theo phản hồi thật.
Một case thực tế đội ngũ chúng tôi từng triển khai
Cách đây không lâu, chúng tôi hỗ trợ một khách hàng vận hành chuỗi cửa hàng nhỏ xây lại hệ thống quản lý nội bộ. Ban đầu đội dev làm việc trong tình trạng họp liên tục, báo cáo thủ công mỗi cuối ngày và gần như không có thời gian tập trung sâu. Tốc độ phát triển chậm, và ai cũng mệt.
Sau khi áp dụng mô hình lấy lập trình viên làm trung tâm, chúng tôi giảm số buổi họp từ năm buổi xuống còn hai buổi mỗi tuần, đồng thời chuyển báo cáo sang tự động qua webhook. Tốc độ hoàn thành task tăng rõ rệt, nhưng điều khiến chúng tôi bất ngờ hơn là tinh thần cả nhóm cũng tốt lên.
Hai lập trình viên senior từng có ý định nghỉ vì áp lực đã quyết định ở lại tiếp tục gắn bó với dự án. Khi hệ thống nội bộ được tự động hoá và phản hồi nhanh hơn cho cả đội lẫn khách hàng cuối, trải nghiệm làm việc thay đổi rõ rệt. Đây cũng là hướng đi tương tự những gì chúng tôi từng nhắc trong bài tích hợp AI vào phần mềm để nâng cấp trải nghiệm người dùng: khi công nghệ được đặt đúng chỗ, cả người dùng lẫn người vận hành đều nhẹ nhàng hơn.
Kết luận
Quản lý dự án lấy lập trình viên làm trung tâm không có nghĩa là bỏ qua deadline hay chiều theo mọi yêu cầu của dev. Đó là cách tổ chức công việc để tiến độ kinh doanh và sức khoẻ tinh thần của kỹ sư cùng được tôn trọng. Khi đội ngũ thấy chuyên môn của mình được bảo vệ trước áp lực hành chính, họ sẽ gắn bó lâu dài và cống hiến cho chất lượng sản phẩm.
Theo chúng tôi, bất kỳ Tech Lead nào cũng có thể bắt đầu từ những thay đổi nhỏ, như bớt vài cuộc họp không cần thiết hay chuẩn hoá lại tài liệu cài đặt môi trường. Nếu bạn đang tìm hướng dẫn cài đặt, sử dụng công cụ công nghệ phù hợp cho đội kỹ thuật, hãy kiên trì áp dụng trong vài tuần. Bạn sẽ thấy rõ khác biệt về tốc độ và chất lượng công việc.
