Những năm 1990 được gọi, họ muốn quy trình báo cáo lỗi của họ quay lại

Quá trình phát triển phần mềm đã được cải thiện gấp 100 lần kể từ khi Internet được phát minh, nhưng cách mọi người báo cáo lỗi đã không thay đổi kể từ những năm 1990. Bạn đã bao giờ có kinh nghiệm này? Một kỹ sư chọn một phiếu yêu cầu và sau một số cuộc điều tra, họ xác định rằng nó hoạt động tốt ở phía họ và họ không có đủ thông tin để tái tạo lỗi. Họ thêm nhận xét vào yêu cầu, chuyển sang một nhiệm vụ khác và đợi người báo cáo lỗi cung cấp thêm thông tin cho họ. Chu kỳ này lặp lại nhiều lần và mỗi khi có thông tin mới trong vé, kỹ sư phải nhớ nơi họ đã dừng lại và cố gắng tiếp tục chuỗi. Các chuyển đổi ngữ cảnh như thế này gây khó khăn cho các kỹ sư và quy trình báo cáo lỗi điển hình dường như là con đẻ của loại rắc rối này. Cuộc sống thực của một con bọ Hãy tưởng tượng một đồng nghiệp báo cáo sự cố đăng nhập trong kênh Slack kỹ thuật và một vài kỹ sư bỏ mọi thứ để điều tra. Bất chấp những nỗ lực tốt nhất của họ, họ không thể lặp lại vấn đề. Họ yêu cầu thêm thông tin như loại trình duyệt và thiết bị. Sau đó, họ hướng dẫn nhân viên thử các bước khắc phục sự cố khác nhau như xóa bộ nhớ cache và làm mới trang. Các cuộc trò chuyện qua lại không đồng bộ thường tiêu tốn một giờ hoặc hơn. Cuối cùng, nhóm kỹ thuật phải lên lịch một cuộc gọi gỡ lỗi với nhân viên để cố gắng xác định sự cố trên máy tính của họ. Trong cuộc gọi, nhân viên chia sẻ màn hình của họ và các kỹ sư hướng dẫn họ cách mở bảng điều khiển và các tab mạng trong công cụ dành cho nhà phát triển để nhận biết điều gì đang xảy ra. Cuối cùng, các kỹ sư thấy rằng có lỗi 401 trong tab mạng có nội dung là "mật khẩu không chính xác". Về bản chất, vấn đề không phải là đăng nhập bị hỏng, mà là giao diện người dùng không thể hiển thị thông báo lỗi "mật khẩu không chính xác" và hiển thị nó cho người dùng. Một lỗi giao diện người dùng đơn giản lẽ ra phải mất năm phút để xác định và giải quyết khiến một số kỹ sư mất cả buổi chiều. Thời gian cho sự thay đổi Quy trình báo cáo lỗi ngày nay vẫn còn lỗi thời. Kể từ những năm 1990, thế giới đã phát minh ra tính năng nhắn tin tức thời như Slack, gọi điện video như Zoom và áp dụng công việc từ xa trên toàn cầu. Giao tiếp lỗi đã trở thành kỹ thuật số. Theo dõi lỗi đã chuyển từ tệp bằng văn bản sang vé Jira. Chưa hết, báo cáo lỗi vẫn chứa đầy những thao tác qua lại phiền phức gây lãng phí thời gian kỹ thuật. Tất cả chúng ta đều đã trải qua sự thất vọng khi xử lý các báo cáo lỗi không rõ ràng, thiếu ngữ cảnh cần thiết để giải quyết vấn đề. Đó là lý do tại sao một năm trước, một vài người trong chúng tôi bắt đầu tưởng tượng ra một cách tốt hơn. Điều gì sẽ xảy ra nếu chúng ta có thể xây dựng một công cụ mới giúp hiện đại hóa báo cáo lỗi và có thể giải quyết vấn đề báo cáo lỗi không rõ ràng, giảm nhu cầu liên lạc qua lại và tiết kiệm thời gian cũng như năng lượng của các kỹ sư? Và vì vậy, ý tưởng cho được sinh ra. Một công cụ được thiết kế để làm cho quá trình báo cáo lỗi trở nên năng suất và hiệu quả hơn. Chúng tôi muốn tạo ra một giải pháp giúp các kỹ sư giải quyết các lỗi kỹ thuật chứ không phải các vấn đề về giao tiếp. Mứt Vì vậy, chúng tôi bắt đầu xây dựng một công cụ cho phép bất kỳ ai, bất kể nền tảng kỹ thuật của họ, nắm bắt dữ liệu kỹ thuật theo ngữ cảnh phong phú về các lỗi để các kỹ sư có thể nhanh chóng xác định và giải quyết các vấn đề. Chúng tôi muốn tạo ra một công cụ giúp cuộc sống của các kỹ sư trở nên dễ dàng hơn, đồng thời cũng giúp những người báo cáo sự cố cho họ làm việc hiệu quả hơn. Khi chúng tôi phát triển và thử nghiệm Jam vào đầu năm ngoái, chúng tôi đã thấy tiềm năng mà nó có để tăng tốc cách thức làm việc của nhóm chúng tôi. Ví dụ: lấy Jam này về một lỗi trong mã của chúng tôi. Thay vì phải thực hiện cuộc gọi để gỡ lỗi trực tiếp, các kỹ sư của chúng tôi có thể xem vấn đề là gì, ngay từ chính báo cáo lỗi. Chúng tôi bắt đầu chia sẻ Jam với các nhóm kỹ thuật khác và chúng tôi thực sự hào hứng với phản hồi. Ramp, T-Mobile và Dell là một trong số những người đầu tiên sử dụng Jam và cung cấp phản hồi vô giá giúp chúng tôi định hình sản phẩm. Dựa trên thông tin đầu vào của họ, giờ đây chúng tôi tự hào nói rằng Jam có hơn 14.000 người dùng và con số này vẫn tiếp tục tăng. Nhưng công việc của chúng tôi còn lâu mới xong. Chúng tôi biết rằng quy trình báo cáo lỗi có thể là nguyên nhân chính khiến các kỹ sư thất vọng và chúng tôi cam kết thay đổi điều đó. Nếu bạn đã chán ngấy với các báo cáo lỗi không rõ ràng, chúng tôi mời bạn thử dùng Jam và cho chúng tôi biết suy nghĩ của bạn. Chúng tôi đang thực hiện sứ mệnh xây dựng một tương lai tốt đẹp hơn cho ngành kỹ thuật và chúng tôi cần phản hồi của bạn để biến điều đó thành hiện thực. Bạn có thể liên hệ với tôi theo địa chỉ dani@jam.dev và tham gia cùng chúng tôi trên hành trình này.