Một đội ngũ hiệu quả sẽ viết ít phần mềm hơn, và việc viết ít phần mềm sẽ giúp đội ngũ mình hiệu quả hơn. Việc này nghe có vẻ phản cảm lúc mới nghe: Chẳng phải chúng ta bản thân là các kỹ sư chuyên để viết phần mềm sao? Không phải thước đo hiệu quả của chúng ta được tính bằng các dòng code sao? Để vén màn mơ hồ về việc này, chúng ta đôi lúc nên ngưng việc xáo trộn giữa việc chúng ta Làm gì (What) với Lý do (Why) vì sao ta làm.

Là kỹ sư phần mềm, chúng ta thiết kế và xây dựng giải pháp cho những vấn đề mà doanh nghiệp mắc phải. Việc tự thân viết code sẽ là 1 phần của câu trả lời. Nhưng chúng ta cũng không nên khăng khăng rằng mọi cây cầu (Bridge) đều được xây dựng chung một form mẫu, và không nên mọi thành phần đều do ta chế tác nên. Thay vào đó, chúng ta nên tập trung vào năng lượng hữu hạn của đội ngũ nhóm của mình để họ có thể mang đến giá trị độc nhất. Nếu chúng ta tưởng thưởng cho nhóm và cá nhân cho việc phát mình ra bánh xe thay vì sử dụng một cách thông minh các thành phần hiện có, thì có thể chúng ta đang hướng đến những nỗ lực tốn kém, thủ công hơn là tính hiệu quả của platform đang sẵn có.

Xây dựng thứ mà bạn bắt buộc phải xây, mua thứ mà bạn có thể và hãy viết (write) chúng xuống

Khi chúng ta xây dựng thứ gì đó mới, công việc của chúng ta sẽ bắt đầu với việc lên kế hoạch tổng thể, tìm hiểu hiện trạng và nhu cầu của tổ chức, và viết những phần (pieces) mà chúng ta phải tự tạo ra. Khi lên tiến độ dự án, chúng ta xác định các nhà cung cấp từng thành phần (pieces) mà chúng ta nghĩ là hiệu quả hơn việc chúng ta bắt đầu xây dựng lại từ đầu. Công việc kết thúc khi ta bắt đầu tích hợp tất cả các thành phần này vào giải pháp chung cho khách hàng. Và việc tích hợp nên là liên tục hơn là tích hợp 1 lần, nên chúng ta phải ghi những quyết định của chúng ta để tiện việc bảo trì cho tương lai, và chia sẻ những gì chúng ta học được cho tổ chức và cộng đồng lớn.

Bản đồ Wardley của Simon Wardley (diễn giải bên dưới) mô tả tầm quan trọng của việc nhận định tính thương mại hóa của từng thành phần chúng ta cần, và nơi nào thành phần đó sẽ phù hợp với chuỗi giá trị giữa thành phần trung gian và người dùng cuối. Nếu chúng ta có một số thứ chung chung như file giao diện, chuỗi ký tự lớn thì nó có thể được đấu thầu cho một số nhà cung cấp trên cơ sở hợp lý về giá và thuận tiện. Nếu thành phần đã được chuẩn hóa đủ để lắp ráp từ sản phẩm hiện có, thì có thể chúng ta nên điều chỉnh chúng và làm một vài chỉnh sửa nhỏ hoặc thêm gắn kết (add our own glue) giữa chúng. Chỉ nếu thành phần nào không tồn tại trên thị trường, hoặc nếu tự tạo ra nó sẽ mang đến một lợi thế cạnh tranh độc đáo, thì chúng ta mới sử dụng đến việc tùy chỉnh (custom work)

Để hiểu được thành phần nào chúng ta cần và cách lắp chúng, bước đầu tiên là thu thập các yêu cầu về vấn đề gặp lại hiện tại và giải pháp mở rộng sau này của chúng. Điều này cho phép chúng ta xác định phần nào là độc nhất (unique) thay vì đi mua hàng và phần nào cần phải được sớm hoàn thành để bắt đầu đi phân phối giá trị của sản phẩm (Delivering value). Đối với các dự án về platform và hạ tầng cụ thể, việc tiếp cận với nhóm người sử dụng là điều cần thiết. Việc mất kết nối giữa nhóm thiết kế và nhóm sử dụng sẽ lãng phí mất sự sáng tạo đổi mới. Các platform nội bộ và công cụ nội bộ thì đặc biệt cần nhóm quản lý sản phẩm (Product Managers) và nhóm phát triển (Developers) ủng hộ để đảm bảo rằng sản phẩm đáp ứng yêu cầu của người dùng và sẽ được áp dụng nhiệt tình thay vì bi bỏ rơi ven đường ( =)))) Việc tối ưu hóa sớm, loại bỏ các yêu cầu sai (wrong of set requirements) sẽ giúp bao quanh (boxed) chúng ta trong những ràng buộc của các lựa chọn quan trọng. Tất nhiên đôi lúc bạn sẽ kết luận rằng: Bạn cần phần mềm của riêng mình nếu khăng khăng sản phẩm bạn sẽ phục vụ phát trực tuyến hàng tỷ giao dịch blockchain, với độ trễ 10 ms, từ không gian vũ trụ. Việc áp dụng đủ các ràng buộc thiết kế là để giải quyết vấn đề trước mắt của bạn, cũng như để chuẩn bị đầy đủ cho dự định của bạn trong 1 năm tới. Song song đó, hãy viết xuống những lựa chọn thay thế mà bạn đã xem xét và lý do vì sao bạn không chọn chúng. Bạn có thể tiết kiệm thời gian cho ai đó hoặc cả bản thân khi mà tương lai những thành phần thiết kế nào đó cần xem xét lại.

Hãy tập trung vào tác động mang lại (Impact), chứ không phải khối lượng (Volume)

Đề cập đến vấn đề ưu ái trong công việc, các nhà lãnh đạo thường tập trung khen thưởng nhóm của bạn cho mức độ tác động mà nhóm đạt được về nguồn lực (cho hiện tại lẫn tương lai) hơn là chia vui cùng các kỹ sư cho việc thiết kế nên thành phần mới toanh, hoặc viết những dòng code nhất định. Hãy nhìn rộng hơn, tập trung vào tác động mang lại của nhân viên trong nhóm bạn.

Vậy còn những câu chuyện anh hùng trong đội ngũ của bạn thì sao ? “Trước khi tôi đến, khách hàng X đã phải bỏ ra 30 phút một ngày để nhập thủ công các đơn hàng của họ từ file bảng tính excel vào hệ thống đơn hàng, nhưng sau khi tập hợp các yêu cầu của họ, chúng tôi nhận thấy các bảng tính excel có thể được phân tích tự động và tự kiểm tra các ngoại lệ dữ liệu. Từ giờ khách hàng X chỉ cần tập trung vào những ca quan trọng, và chúng tôi chỉ cần viết giúp họ những quy tắc kiểm tra dữ liệu trên bảng tính excel, thay vì chúng tôi phải viết một phần code lập trình phân tích bảng tính excel (CSV-Parsing) và sau đó phải vận hành phần code này. Xây dựng đội ngũ của bạn để hoàn thành các mục tiêu nghiệp vụ xác định và cân nhắc nguồn lực cho phép bạn dễ tưởng thưởng các thành viên trong nhóm về chiến lược công nghệ (strategic engineering) hơn là chiến thuật hack nhỏ lẻ (tactical hacks) Nền tảng tin nhắn Intercom đã tạo ra nhiều điều thần kỳ từ việc “Run less software”, cho phép những kỹ sư trong nội bộ tập trung vào nơi có thể tạo thêm giá trị, thay vì tập sức nặng vào phát triển nội bộ. Lãnh đạo họ nhìn nhận rằng những dòng code được viết trong nhà đều cần được chăm sóc, thay đổi và hỗ trợ liên tục. Càng nhiều thứ có thể thuê ngoài cho các nhà cung cấp, thì các nhóm nội bộ càng ít tự làm.

Khi nhóm nào quyết định tự viết code của riêng mình, họ cần biết điều cần thiết thực hiện kế hoạch bảo trì dài hạn cho code của mình và chiến lược bảo trì dài hạn cho nó. Google’s Richard Bondi and Max Luebbe, trong bài nói chuyện của họ tại SREcon Americas đã nhấn mạnh rằng nếu không có mục đích và chiến lược rõ ràng, việc phân tán người dùng thực hiện code (user contributions to a codebase) sẽ rất dễ dính phải “Nợ kỹ thuật – Technical Debt”. Chúng thường xuất hiện trong những bộ tính năng ngổn ngang, tính sở hữu không rõ ràng, hoặc có cả những bug ma quái (spooky bugs), đi xa hơn những gì những kỹ sư phần mềm đang chỉnh sửa.

Chia sẻ những gì bạn làm và cách bạn thực hiện chúng

Nếu bạn đã xác định yêu cầu với thị trường hoặc thành phần bạn đang thiếu khiến bạn vẫn phải viết code cho riêng mình thì hãy thử tạo giá trị khi cung cấp Nguồn mở (Open Source) cho công việc của bạn. Khi bạn chia sẻ các thiết kế và động lực của mình để người khác có thể thấu hiểu xem: nó có phù hợp với trường hợp sử dụng của họ không, từ đó họ có thể dễ dàng đóng góp hay hỗ trợ bạn. Trừ phi phần mềm của bạn viết mang tính cạnh tranh quan trọng, việc chia sẻ phần mềm cho phép người khác vừa có lợi và giúp nó dễ được tham gia bảo trì.

Và việc chia sẻ code sẽ vượt xa hơn mong đợi trong các trường hợp công ty lớn, các nỗ lực của các nhóm lẻ có thể được nhân lên (duplicate) tại nơi khác trong doanh nghiệp, lúc đó việc quản lý nguồn mã bên trong và tập trung các nỗ lực kỹ thuật (engineering efforts) sẽ trở nên rất quan trọng. Việc sử dụng công nghệ của người khác có được ghi nhận? Nếu công ty bạn không có các buổi tech-talks hay tài liệu chung hay nguồn quản lý code thì nên đề xuất chúng. Điều đó giúp cho việc quan sát xem nhân viên của bạn có tìm hiểu về sự đổi mới (innovation) ở những mảng nghiệp vụ khác. Và thuê thêm những Kỹ thuật viên viết tài liệu (Technical Writer) để làm vai trò như thủ thư cho bạn. Dù là nội bộ hay bên ngoài, chia sẻ cũng là một trách nhiệm.

“Don’t reward unnecessary complexity” không chỉ áp dụng cho các công ty mà còn cho cộng đồng (Không vì bài gì đó phổ biến trên trang Hacker News, thì nó sẽ phù hợp với nhóm hay công ty của bạn). Đừng áp dụng ngu ngốc, và đừng thử những cộng đồng có tính độc hại, nơi có đầy những mã code lỏm và xung đột lẫn nhau. Việc tự phát triển phần mềm nên là cuối cùng chứ không nên đầu tiên để tiến hành. Chúng ta phải thành lập nhóm và công ty để tưởng thưởng những tác động từ việc tái sử dụng code nhiều hơn là phát triển lại toàn bộ. Write less code, do more engineering.

Dịch từ “Increment.com Issues 11: Team – Tác giả: LIZ FONG-JONES – Nov 2019”

Link: https://increment.com/teams/code-less-engineer-more/

(*) Bản đồ Wardley là công cục, là nơi mà các mục tiêu của doanh nghiệp sẽ được phân tách thành các thành phần cụ thể để có thể mang giá trị đến cho khách hàng. Mỗi thành phần sẽ là 1 phần của chuỗi (chain) các giá trị lớn hơn, liên kết giữa các thành phần được thể hiện qua mối quan hệ phụ thuộc. Chuỗi giá trị được đặt trên bản đồ theo mức độ phát triển của từng thị trường, từng nguồn gốc đến hàng hóa. Từ đó các học viên có thể nhóm các thành phần theo từng khu vực chung trách nhiệm, chức năng trong khi sử dụng chiến lược phù hợp để mua sắm từng thành phần