Ngành công nghiệp phần mềm đã biến đổi mạnh mẽ trong thập kỷ qua, và không nhất thiết là theo hướng tốt hơn. Những gì từng là một nghề thủ công hợp tác nơi các developer tích cực định hình sản phẩm giờ đã trở thành một dây chuyền lắp ráp hoàn thành ticket. Sự thay đổi này không chỉ đơn thuần là thay đổi quy trình làm việc—nó đang thay đổi căn bản cách phần mềm được xây dựng và ai được quyết định về nó.
Cái Chết Của Quyền Tự Chủ Developer
Phát triển phần mềm hiện đại đã phát triển thành một hệ thống phân cấp cứng nhắc nơi các kỹ sư ngày càng bị ngắt kết nối khỏi các quyết định sản phẩm. Cuộc thảo luận cộng đồng tiết lộ một mô hình đáng chú ý: các developer từng tham gia vào quy trình thiết kế, đặt câu hỏi về yêu cầu, và chịu trách nhiệm cho toàn bộ tính năng giờ thấy mình bị giáng xuống thành thực hiện các nhiệm vụ được định nghĩa trước mà không có bối cảnh hay đóng góp ý kiến.
Sự biến đổi này không xảy ra qua đêm. Khi các công ty phát triển lớn hơn và tìm cách giảm rủi ro trong quy trình phát triển của họ, họ đã giới thiệu các lớp product manager, designer, và business analyst giữa developer và các vấn đề kinh doanh thực tế. Kết quả là một hệ thống nơi các kỹ sư được mong đợi thực thi thay vì suy nghĩ, dẫn đến những gì nhiều người mô tả là một môi trường giống nhà máy tập trung vào sản lượng hơn là đổi mới.
Product Manager: Một vai trò kết hợp các chức năng business analyst truyền thống với trách nhiệm sở hữu sản phẩm, thường không có kiến thức kỹ thuật sâu.
Dòng thời gian thay đổi vai trò trong phát triển phần mềm:
- Trước 2013: Các lập trình viên tham gia vào quá trình thiết kế, trưởng nhóm kỹ thuật đảm nhận việc lập kế hoạch dự án
- Từ 2013 trở đi: Ra đời các vị trí thiết kế toàn thời gian và quản lý sản phẩm chuyên biệt
- Hiện tại: Hệ thống phân cấp cứng nhắc với lập trình viên chỉ là người thực thi thay vì người ra quyết định
Sự Trỗi Dậy Của Những Người Ra Quyết Định Phi Kỹ Thuật
Có lẽ thay đổi quan trọng nhất là việc chuyển quyền ra quyết định kỹ thuật khỏi các kỹ sư. Nơi các engineering lead từng lập kế hoạch cho toàn bộ dự án và hợp tác trực tiếp với các bên liên quan, các product manager chuyên biệt giờ sở hữu các tính năng và chỉ định cách tiếp cận triển khai cho các developer thực sự hiểu các ràng buộc kỹ thuật.
Sự tách biệt này đã tạo ra ma sát và kém hiệu quả. Các kỹ sư báo cáo phải đàm phán với product owner về các cải tiến kỹ thuật cơ bản, trong khi được yêu cầu đóng khung các nỗ lực refactoring theo thuật ngữ kinh doanh để được phê duyệt. Sự mỉa mai là rõ ràng: các công ty thuê các developer thông minh nhưng sau đó thưởng cho những người chỉ đơn giản làm theo hướng dẫn mà không đặt câu hỏi về bức tranh lớn.
Cộng đồng chỉ ra một vấn đề cơ bản với cách tiếp cận này. Khi những người gặp khó khăn với các thao tác máy tính cơ bản được trao quyền hạn đối với quy trình phát triển phần mềm, kết quả có thể dự đoán là có vấn đề. Nợ kỹ thuật tích lũy, các quyết định kiến trúc không được đặt câu hỏi, và chất lượng tổng thể của phần mềm bị ảnh hưởng.
Sự Phát Triển Vai Trò trong Các Nhóm Phần Mềm:
- Truyền thống: Chuyên gia chuyên môn + Phân tích viên kinh doanh + Thiết kế do Developer dẫn dắt
- Hiện đại: Product Manager (kết hợp nhiều vai trò) + Nhà thiết kế UX/UI + Developer (chỉ thực hiện)
- Tác động: Gấp 10 lần về nhân sự và ngân sách để có 75% khả năng đạt kết quả tầm thường
 |
|---|
| "Các ticket đang di chuyển nhưng công việc thì không" Điều này truyền tải sự ngắt kết nối giữa việc hoàn thành ticket và phát triển có ý nghĩa |
Sự Xói Mòn Của Tay Nghề Thủ Công
Những gì đang bị mất trong quá trình chuyển đổi này vượt ra ngoài hiệu quả—đó là bản chất cơ bản của phát triển phần mềm như một kỷ luật sáng tạo, giải quyết vấn đề. Các developer mô tả cảm giác bị ngắt kết nối khỏi công việc của họ, coi code như thứ thuộc về người khác thay vì tự hào về nghề của mình.
Tôi đã thích sự nghiệp của mình ít đi trong khoảng 10 năm qua vì tôi đã thấy mọi công ty đều đi theo hướng này.
Các triệu chứng rất rõ ràng: pull request được phê duyệt mà không có thảo luận có ý nghĩa, các nhiệm vụ nợ kỹ thuật vẫn không được chạm đến cho đến khi tình huống khẩn cấp phát sinh, và mọi cải tiến đều yêu cầu ticket riêng biệt, ước tính, và phê duyệt. Các kỹ sư được huấn luyện để ở trong làn đường của họ, không được khuyến khích hỏi tại sao các tính năng quan trọng hoặc đề xuất cải tiến bên ngoài phạm vi hẹp của họ.
Môi trường này đặc biệt ảnh hưởng đến các developer mới, những người đang được đào tạo từ đầu để tập trung vào các ticket được viết tốt thay vì hiểu toàn bộ hệ thống hoặc quan tâm đến các mục tiêu dự án rộng lớn hơn. Kết quả là một thế hệ lập trình viên có kỹ năng chính là điều hướng các công cụ quản lý dự án thay vì giải quyết các vấn đề kỹ thuật phức tạp.
Dấu hiệu của Phát triển theo Hướng Ticket:
- Không hiểu mục đích của tính năng ngoài việc đáp ứng deadline giao hàng
- Pull request được phê duyệt mà không có thảo luận
- Nợ kỹ thuật bị bỏ qua cho đến khi xảy ra tình huống khẩn cấp
- Mọi cải tiến đều yêu cầu ticket riêng biệt và phê duyệt
- Các kỹ sư coi code như thuộc về người khác
Lời Hứa Sai Lầm Về Velocity
Cách tiếp cận dựa trên ticket hứa hẹn năng suất có thể đo lường thông qua các chỉ số velocity và story point. Các đội có thể burn down 30 point mỗi tuần và cảm thấy hiệu quả, nhưng sự chuyển động này thường che giấu việc thiếu tiến bộ thực sự. Các bản sửa nhanh trở thành mìn kỹ thuật, các quyết định thiết kế không bao giờ được đánh giá lại, và codebase trở thành một cuộc khai quật khảo cổ của các giải pháp ngắn hạn.
Vấn đề cơ bản là velocity đo lường hoạt động, không phải hiệu quả. Các công ty cuối cùng chi tiêu nhiều tiền hơn đáng kể để thuê nhiều chuyên gia cho các vai trò trước đây được xử lý bởi ít thành viên nhóm đa năng hơn. Việc giảm rủi ro được cho là đến với cái giá của đổi mới, hiệu quả, và sự hài lòng trong công việc.
Tìm Kiếm Con Đường Phía Trước
Bất chấp những vấn đề hệ thống này, một số developer và đội đang tìm cách duy trì chất lượng và mục đích trong môi trường bị ràng buộc. Chìa khóa dường như là lấy lại những tự do nhỏ: cải thiện chất lượng code trong công việc thường xuyên, đặt câu hỏi ngay cả khi câu trả lời đã biết, và coi ticket như ranh giới thay vì băng che mắt.
Đối với các developer cá nhân, giải pháp có thể liên quan đến việc tìm kiếm các công ty nhỏ hơn hoặc các hốc chuyên biệt nơi sự xuất sắc kỹ thuật và hiểu biết sâu vẫn được đánh giá cao hơn việc tuân thủ quy trình. Cộng đồng gợi ý rằng các startup và công ty tập trung vào các ứng dụng quan trọng về hiệu suất cung cấp môi trường tốt hơn cho các developer muốn suy nghĩ vượt ra ngoài ticket tiếp theo.
Ngành công nghiệp rộng lớn hơn có thể cần nhận ra rằng quỹ đạo hiện tại—trong khi có vẻ giảm rủi ro—thực sự tăng chi phí và giảm đổi mới. Phần mềm thành công nhất trong lịch sử đã đến từ các đội nơi developer hiểu cả bối cảnh kỹ thuật và kinh doanh của công việc họ, không phải từ dây chuyền lắp ráp của các vai trò chuyên biệt làm việc riêng lẻ.
Tham khảo: Ticket-Driven Development: The Fastest Way to Go Nowhere