Làm thế nào và tại sao chúng tôi dạy những người không phải kỹ sư sử dụng GitHub tại Thread

Tại Thread, một trong những niềm tin cốt lõi của chúng tôi là công nghệ cho phép thay đổi lớn. Điều này rất quan trọng đối với sản phẩm của chúng tôi, nhưng nó cũng quan trọng đối với cách chúng tôi làm việc nội bộ.

Vì cách làm việc này, chúng tôi cố gắng thể hiện mọi thứ trong dữ liệu sản phẩm, đo lường, kiểu dáng, nhà cung cấp, địa điểm trong kho của chúng tôi, hỗ trợ giải quyết vé và nhiều điều nữa mà bạn không bao giờ nghĩ tới.

Tất cả các mô hình dữ liệu này đi kèm với một chi phí cần một cách cho những người trong công ty sử dụng chúng để duy trì dữ liệu. Điều này có nghĩa là xây dựng các giao diện chỉnh sửa, với xác nhận, thiết kế cơ sở dữ liệu và công việc mặt trước. Thường thì chúng tôi chỉ cần có thời gian để thực hiện điều này, các tính năng mới được ưu tiên cao hơn và bên cạnh đó, một kỹ sư chỉ có thể cập nhật một vài tệp dữ liệu khi cần phải không?

Mặc dù đây là một giải pháp nhanh hơn rất nhiều trong thời gian ngắn, một kỹ sư sẽ phải chuyển ngữ cảnh ra khỏi công việc của họ, xem bản phát hành đi ra ngoài và đảm bảo không có gì sai sót. Có lẽ quan trọng hơn, người cần dữ liệu cập nhật bây giờ không còn quyền sở hữu toàn bộ quá trình và phụ thuộc vào lịch trình của người khác.

Cuối cùng, quá trình này có thể hữu ích để nhanh chóng đưa một tính năng ra khỏi cửa, nhưng gây ra quá nhiều ma sát để hoạt động lâu dài.

Một giải pháp tốt hơn

Tôi nhớ khi GitHub lần đầu tiên ra mắt trình soạn thảo web của họ - Tôi đã rất ấn tượng. Tại sao mọi người sẽ chỉnh sửa mã trong trình duyệt web? Tại sao tôi nên sử dụng trình chỉnh sửa chỉ có thể thay đổi một tệp cho mỗi lần xác nhận? Nhiều năm sau, tôi đã nhận ra rằng tôi không phải là thị trường mục tiêu cho biên tập viên.

Tại Thread, chúng tôi hiện thường xuyên dạy cho những người bên ngoài nhóm kỹ thuật cách đóng góp cho cơ sở mã của chúng tôi thông qua giao diện web GitHub, để họ kiểm soát việc cập nhật dữ liệu mà họ cần để hoạt động hiệu quả.

Bây giờ chúng tôi đã có nhiều người đóng góp cho cơ sở mã hóa chính của chúng tôi, những người có vai trò phi kỹ thuật, hơn tất cả các kỹ sư và nhà thầu đã đóng góp trong nhiều năm qua.

Nó đã làm việc?

Là một kỹ sư trong nhóm sản phẩm, tôi đã có thể tập trung nỗ lực vào việc xây dựng các tính năng sẽ có lợi cho khách hàng của chúng tôi và di chuyển các số liệu, thay vì xây dựng nhiều giao diện CRUD hơn. Tôi cũng có thể gửi các thử nghiệm A / B nhanh hơn vì chúng ta thường có thể bỏ qua công cụ nội bộ cho phiên bản thử nghiệm có lợi cho việc chỉnh sửa dữ liệu thông qua các tệp dữ liệu để bắt đầu. Khi chúng ta đến giai đoạn phân phối của một dự án, chúng ta có thể dành thời gian vào các giao diện chỉnh sửa vì chúng ta không chỉ có ý tưởng về giá trị của tính năng mà còn có ý tưởng tốt hơn về cách người dùng nội bộ của chúng ta muốn giao diện để làm việc.

Nó cũng không giới hạn các tệp dữ liệu; nhiều trang trên thread.com về cơ bản là HTML tĩnh, các trang như Câu hỏi thường gặp về phân phối của chúng tôi, chính sách trả về hoặc các điều khoản và điều kiện. Bằng cách học cách sử dụng GitHub, nhóm điều hành của chúng tôi có thể cập nhật những thông tin này mà không cần yêu cầu trợ giúp. Đội ngũ tài năng của chúng tôi cũng có thể chỉnh sửa trang web việc làm của chúng tôi, phản ứng hàng ngày với các câu hỏi phổ biến xuất hiện khi nói chuyện với các ứng cử viên.

Tất cả điều này có nghĩa là các thành viên trong nhóm của chúng tôi bên ngoài nhóm kỹ sư có thể có quyền sở hữu nhiều hơn đối với công việc của họ và có ít ma sát hơn để thực hiện các thay đổi mà kinh nghiệm của họ nói với họ là cần thiết.

Chúng ta làm điều đó như thế nào?

Điều đầu tiên chúng tôi làm là chạy các hướng dẫn GitHub mỗi khi chúng tôi có một vài người mới bắt đầu để dạy. Chúng tôi trình bày những điều cơ bản về kho lưu trữ là gì, so sánh nó với lịch sử sửa đổi tài liệu trên Google Docs, ý nghĩa của việc cam kết một tệp và chi nhánh là gì. Chúng tôi chỉ nói về những điều này theo những cách cấp cao vì chúng tôi không bao gồm giao diện dòng lệnh ở định dạng hướng dẫn hiện tại.

Tiếp theo chúng ta sẽ tìm hiểu cách chỉnh sửa tệp trên giao diện web GitHub, cách viết thông báo cam kết, yêu cầu kéo là gì và báo cáo trạng thái xây dựng từ Jenkins nghĩa là gì.

Cuối cùng, chúng tôi yêu cầu những người đóng góp phi kỹ thuật chọn một kỹ sư có sẵn trên Slack để nhấn nút hợp nhất khi bản dựng có màu xanh.

Các vấn đề chúng tôi đã gặp phải

Về sự cân bằng, chúng tôi cảm thấy đây là một chiến thắng lớn cho toàn đội và chúng tôi có kế hoạch tiếp tục đào tạo và khuyến khích nhiều người đóng góp hơn khi chúng tôi phát triển, nhưng chúng tôi đã thay đổi quá trình của mình một chút khi điều này đã phát triển.

Đầu tiên, chúng tôi đã sử dụng các vai trò GitHub và các nhánh bị khóa để ngăn chặn các cam kết vô tình thành chủ. Đối với một người nào đó quen thuộc với kiểm soát phiên bản và các nhánh cụ thể, giao diện web GitHub đặc biệt rõ ràng về việc khi một cam kết đang diễn ra ở nhánh chính hoặc một nhánh mới. Tại Thread, chi nhánh chính của chúng tôi được triển khai liên tục mà không cần can thiệp thủ công, điều này dẫn đến một số cam kết đi ra ngoài đã phá vỡ trang web và gây ra thời gian chết.

Đối với tất cả các vấn đề thời gian chết, chúng tôi đã chạy 5 Whys đáng trách và nhận ra rằng trong khi nhận thức muộn, chúng tôi có thể đã bắt gặp các vấn đề này với các bài kiểm tra đơn vị chạy trước khi triển khai, chúng tôi có thể sẽ không nắm bắt được mọi thứ và vì vậy việc giới thiệu các chi nhánh được bảo vệ để khuyến khích đánh giá mã là nhẹ cách giải quyết vấn đề.

Thứ hai, phần nào để đáp ứng với vấn đề này, chúng tôi đã bắt đầu viết một số bài kiểm tra đơn vị chỉ kiểm tra cấu trúc dữ liệu trong các tệp dữ liệu hoặc để kiểm tra xem tất cả các tệp mẫu Django phân tích thành công như các mẫu hợp lệ. Đặc biệt trong trường hợp của các tệp dữ liệu, chúng thường không phải là thứ mà chúng tôi mong muốn kiểm tra, nhưng vì bây giờ chúng tôi muốn các tệp có thể chỉnh sửa được bởi những người không có kiến ​​thức về mã, chúng có thể hữu ích trong việc nắm bắt các lỗi đơn giản .

Cuối cùng, vì chúng tôi thường sử dụng Python cho các tệp dữ liệu của mình, chúng tôi đã phát hiện ra rằng cú pháp isn đặc biệt trực quan và có thể làm quen với một số. Để giải quyết vấn đề này, chúng tôi đã viết tài liệu bằng văn bản với một ít chi tiết hơn so với việc nó được viết cho một kỹ sư. Tài liệu này cũng nằm trong repo và có thể chỉnh sửa bởi mọi người, vì vậy chúng tôi khuyến khích những người không phải kỹ sư cập nhật và làm rõ các hướng dẫn khi họ tìm hiểu và dạy cho nhau cách chỉnh sửa một số phần của trang web.

Tiến về phía trước

Chúng tôi coi thử nghiệm này là một thành công và sẽ tiếp tục nó trong tương lai gần. Khi chúng tôi thiết kế các tệp dữ liệu để có thể chỉnh sửa, chúng tôi sẽ thử bao gồm các hướng dẫn chi tiết trong chính các tệp, có thể bao gồm các ví dụ sao chép / dán.

Chúng tôi đã cố gắng để làm cho các thử nghiệm thất bại của mình có thông báo lỗi thông tin với các chi tiết về cách khắc phục nơi chúng tôi có thể, nhưng do sự phức tạp của việc diễn giải thử nghiệm, chúng tôi hiện không đưa Jenkins đến các thành viên nhóm phi kỹ thuật, mặc dù về mặt kỹ thuật, chúng có thể đăng nhập bằng đăng nhập một lần. Đây có lẽ là cơ hội tiếp theo mà chúng tôi phải cải thiện trải nghiệm đóng góp và một cái gì đó chúng tôi có thể dùng thử trong đợt khởi đầu mới tiếp theo thông qua hướng dẫn.

Để kết thúc, tôi đã khuyến khích tất cả các nhà phát triển xem liệu có cơ hội nào trong các công ty của bạn để có được các thành viên nhóm phi kỹ thuật đóng góp cho cơ sở mã của bạn không. Có lợi ích cho năng suất từ ​​cả hai phía, sự đồng cảm nhiều hơn giữa các nhóm và cảm giác mạnh mẽ hơn về quyền sở hữu đối với công việc đối với những người không còn phụ thuộc vào các nhà phát triển để thay đổi cho họ. Ma sát giảm cũng có nghĩa là chu kỳ phản hồi ngắn hơn, có thể biến đổi cho những gì người khác có thể hoàn thành trong công việc của họ, tất cả mà không tốn thời gian phát triển cao trên các giao diện chỉnh sửa.