Gửi các đơn vị phần mềm nhỏ hơn và giới hạn kích thước của các nhánh máy chủ cục bộ của bạn

Trong thập kỷ lãnh đạo HackerNoon vừa qua, tôi đã làm việc với rất nhiều nhà phát triển phần mềm tài năng và ngay từ đầu trong nhiệm kỳ của họ, tôi thường nói điều tương tự: vận chuyển các đơn vị phần mềm nhỏ hơn và giới hạn quy mô của các chi nhánh máy chủ tại địa phương của bạn. Tại sao? Đây là hai lý do chính và một lý do lớn nhưng:

1. Người dùng thu được nhiều lợi ích hơn từ - và đưa ra phản hồi cho - công việc của bạn trong khi bạn tiếp tục nỗ lực hoàn thành dự án.

Nếu bạn có một dự án có giá trị làm việc trong 6 tháng và không đi vào hoạt động trong 6 tháng, thì đó là 5 tháng 30 ngày người dùng không thu được lợi ích gì từ công việc của bạn. Chỉ khi nó hoạt động thì phần còn lại của Internet mới có cơ hội hưởng lợi từ những gì bạn vận chuyển. Và thậm chí sau đó, đó cũng chính là lúc cuộc chiến khó khăn lớn để được nhận con nuôi bắt đầu. Thay vào đó, nếu bạn vận chuyển một phần dự án mỗi tuần, người dùng sẽ bắt đầu nhận được giá trị trong suốt vòng đời của dự án.

Dane Lyons , đồng nghiệp cũ của tôi, đã từng nói với tôi rằng “chúng ta nên tiếp tục bổ sung thêm các đơn vị giá trị nguyên tử và thực hiện càng nhiều bản phát hành càng tốt. Chúng tôi có thể dễ dàng có 10 bản phát hành trên [chức năng] trước khi hài lòng với nó và sẵn sàng tiếp tục.”

Với tư cách là Giám đốc điều hành, tôi thường đánh giá những người mới tuyển dụng về việc họ phải mất bao lâu để trở thành những người đóng góp có lợi nhuận. Trong việc bán hàng, điều này càng chặt chẽ và khô khan hơn, liệu doanh số bán hàng của họ có vượt quá mức thù lao của họ không? Tất nhiên, có những điều khác cần xem xét, chẳng hạn như chi phí biên cho tiếp thị, cơ sở hạ tầng, v.v., nhưng dù bạn chia nhỏ nó ra sao, việc đo lường mức độ tác động của nhà phát triển phần mềm đến lợi nhuận cuối cùng sẽ khó hơn so với nhân viên bán hàng. Nếu bạn đang bắt đầu đảm nhận vai trò mới là nhà phát triển phần mềm, tôi khuyên bạn nên thử kết hợp thành công các đĩa đơn trước khi bắt đầu chạy tại nhà.

Trong trò chơi phát triển phần mềm, không có quy tắc chung nào cho điểm số. Chắc chắn một số người chỉ định hệ thống điểm và những người khác xác định KPI, nhưng cuối cùng, chính những người sử dụng sản phẩm của bạn sẽ xác định xem bạn có tạo ra giá trị hay không và bằng cách nào. Bằng cách vận chuyển sớm hơn, bạn sẽ nhận được phản hồi sớm hơn. Những người sử dụng phần mềm của bạn sẽ giải thích rõ hơn cách xây dựng và không xây dựng đơn vị nguyên tử tiếp theo của dự án.

2. Chi nhánh của bạn càng đi xa khỏi thực tế sản xuất thì các đồng đội càng khó đóng góp cho dự án của bạn và thúc đẩy các dự án lân cận phát triển.

Lúc đầu, các tác động bên ngoài từ việc không cung cấp phiên bản cập nhật nhất có thể khó nhận thấy hơn. Tất cả mọi thứ đã được kết nối. Ví dụ: trong một sản phẩm như HackerNoon, trang hồ sơ và trang câu chuyện không tồn tại trong chân không; chúng tồn tại dưới dạng các trang được kết nối trong một sản phẩm. Nếu những thay đổi xảy ra với cách hoạt động của một trang, nó sẽ ảnh hưởng đến cách hoạt động của tất cả các trang được kết nối với trang đó.

Nếu chi nhánh địa phương của bạn rất lớn, những thay đổi khác xảy ra trên các trang hoặc chức năng được kết nối với nó thường sẽ không hoạt động khi chi nhánh béo bở của bạn cuối cùng đã được đưa vào sản xuất. Điều này phá vỡ mọi thứ. Điều này tạo ra lỗi. Điều này buộc phải làm lại công việc. Điều này tạo ra mong muốn từ đồng đội của bạn là không muốn làm việc cùng bạn. Điều này thậm chí có thể tạo ra trải nghiệm sản phẩm tồi tệ hơn trải nghiệm bạn đã có trước khi bạn thực hiện tất cả công việc cho chi nhánh địa phương của mình.

Bằng cách thực hiện những thay đổi nhỏ thường xuyên hơn, bạn đang trao quyền cho người khác đóng góp. Họ cảm thấy những gì họ vận chuyển cũng sẽ hiệu quả vì cả hai bạn đều đã thống nhất về cơ sở sản xuất là gì. Tăng dần là bff của bạn. Nó kết nối bạn với thực tế. Nếu những thay đổi gia tăng đang ảnh hưởng tiêu cực đến sản phẩm, điều gì khiến bạn nghĩ rằng những thay đổi lớn hơn theo cùng một hướng sẽ ảnh hưởng tích cực đến trải nghiệm sản phẩm?

Và điều quan trọng là: đừng sợ những dự án táo bạo có thể trở thành những nhánh quá lớn bởi vì bạn là một tên mofo tồi có khả năng tạo ra sự khác biệt về cách thức hoạt động của thứ chết tiệt này đối với mọi người.

Một số dự án đơn giản phải là những nhánh lớn. Ví dụ: những thứ có sự phụ thuộc lớn như cơ sở dữ liệu mới có thể ăn sâu vào cách sử dụng hiện tại đến mức tốt nhất bạn nên quay ngược thời gian và tiếp cận dự án giống như bản phát hành tiền đề 2.0 hàng năm. Và các công nghệ đột phá khác, như ChatGPT, mất quá nhiều thời gian để xây dựng nên việc phát hành một phiên bản UX tồi tệ, chưa được đào tạo, chưa hoàn thiện của công nghệ mới sẽ không có ý nghĩa gì. Thực hiện những cú đánh lớn. Khi bạn có đường băng. Khi bạn có đội ngũ trên tàu. Nhưng đừng tự phóng đại bản thân. Hầu hết việc phát triển phần mềm không phải là phát minh lại cái bánh xe. Nó chỉ đơn giản là vận chuyển đơn vị nguyên tử tiếp theo.