Tại sao rất khó để bắt nhân viên cập nhật trình theo dõi vấn đề?

Tôi đã luôn phải vật lộn để có được những người cập nhật các vấn đề của họ, cả ở công ty và tại nơi làm việc. Tôi đã có một vài trường hợp khi mọi người thực sự làm điều đó từ lòng tốt của họ, nhưng ~ 70% thời gian tôi phải đuổi theo mọi người.

Là người thường quản lý một số hoặc một hình thức quản lý khác (tôi là nhà phát triển đầu tiên), lý do chính tôi cố gắng đưa ra là tôi không muốn đuổi mọi người xuống và làm gián đoạn truy vấn về tiến trình, nhưng tôi không ' Cuối cùng mọi người nghĩ rằng sẽ được hỏi nhiều. Trong một số trường hợp hiếm hoi và cực đoan, tôi cuối cùng đã cập nhật vé của họ (khi tôi cần tạo báo cáo).

Vì vậy, bạn đã gặp phải vấn đề này chưa?, Bạn đã khuyến khích các nhà phát triển cập nhật trình theo dõi vấn đề thường xuyên như thế nào? Bạn đã đạt được mức độ thành công nào?

Lý do là họ không tìm hiểu lý do tại sao họ nên cập nhật trình theo dõi vấn đề, ngoài thực tế là bạn nói như vậy.

Tại sao vậy? Tôi đoán là việc cập nhật trình theo dõi không ảnh hưởng đến công việc của họ theo bất kỳ cách có ý nghĩa nào, vì vậy giải pháp có lẽ là triển khai một hệ thống theo dõi thực sự giúp họ thực hiện công việc tốt hơn.

Thật khó, bởi vì nhân viên cảm thấy rõ ràng rằng việc cập nhật trình theo dõi vấn đề không quan trọng. Bạn phải thay đổi điều đó, nhưng có một nhược điểm. Giao tiếp thật khó khăn. Giao tiếp hiệu quả thực sự khó khăn - khó hơn nhiều so với bạn nghĩ. Vì vậy, khó khăn, giao tiếp đó thường thất bại, ngoại trừ do tai nạn .

Hiển thị, đừng nói. Ví dụ. đừng nói rằng bạn (hoặc sếp của bạn) cần dữ liệu cho báo cáo. Hiển thị từ quan điểm của nhân viên về cách theo dõi vấn đề cập nhật ảnh hưởng và giúp đỡ họ.

Dẫn bằng ví dụ.

Tôi là một nhà phát triển và đấu tranh để sử dụng trình theo dõi vấn đề chúng ta có trong công việc. Điều này thật đáng tiếc bởi vì tôi là tất cả để họ giữ mọi thứ ngăn nắp. Giải pháp của tôi lúc này là sử dụng một công cụ theo dõi cá nhân và tham khảo nó để nói về sự tiến bộ tại các scrum hàng ngày của chúng tôi.

Đây là những gì sẽ khiến tôi sử dụng trình theo dõi mọi lúc:

• Tích hợp liền mạch với IDE và kiểm soát nguồn. Chúng tôi sử dụng một số ứng dụng web vụng về vì giấy phép đã được mua cho nó. Phải mất mãi mãi để tạo / cập nhật các tác vụ và có một số tính năng UI khó hiểu. Thật không may, việc sử dụng này nằm ngoài tầm kiểm soát của nhóm chúng tôi.

• Sự đơn giản. Bằng cách này, tôi có nghĩa là không lấy 10 trường được điền thủ công chỉ để thêm một tác vụ. Ước tính hàng giờ so với thời gian hoàn thành, nhập thủ công dự án / thành phần / vv. trong một số lĩnh vực, vv chỉ cần tăng thời gian.

• Chỉ một. Không chắc mức độ phổ biến của nó, nhưng quản lý dự án sử dụng một công cụ, hỗ trợ sử dụng công cụ khác và phát triển sử dụng công cụ thứ ba. Nếu một cái không được cập nhật, chắc chắn ba cái không và đồng bộ hóa giữa chúng không có khả năng được tự động hóa.

Trước hết: bạn có ý nghĩa gì với "mọi người cập nhật tiến trình của họ"?

Bạn có nghĩa là "nhà phát triển cập nhật ước tính hiện tại" hay "nhà phát triển không đặt vấn đề để giải quyết", hay đúng hơn là "khách hàng / người kiểm tra không kết thúc vấn đề đã giải quyết" hoặc tất cả cùng nhau?

Từ quan điểm của một nhà phát triển, nó là sự pha trộn giữa tư duy và văn hóa.

• mindset: khi bạn đặt vấn đề thành giải quyết, điều đó có nghĩa là bạn đã hoàn thành và chịu trách nhiệm nếu nó có lỗi
• văn hóa: nếu toàn bộ công ty không thích sử dụng các công cụ như vậy, nhưng thích các chiến lược tổ chức khác

Kinh nghiệm của tôi là: bạn cần văn hóa để chỉ đúng hướng, ít nhất. Điều giúp tiếp theo là xác định DoD (định nghĩa 'hoàn thành') - nếu nhà phát triển (cũng làm việc cho các vai trò khác) có thể nói rằng anh ta đã hoàn thành toàn bộ danh sách, họ sẽ giải quyết vấn đề được giải quyết và tiếp tục mà không cần Nhìn phía sau.

Ngừng hỏi về tiến trình mã hóa (thường là một tỷ lệ phần trăm tùy ý thoát ra khỏi không khí mỏng) cho đến khi vé được đóng không có tín dụng. Nếu điều chính bạn đo được là số lượng vé đã đóng thì sẽ cải thiện.

Tuy nhiên, xin lưu ý rằng tất cả các số liệu có thể được chơi và các số liệu có xu hướng hoạt động tốt hơn khi được hợp tác với các số liệu bổ sung, ví dụ bạn có thể muốn xem xét các vấn đề được mở lại vì điều này ngụ ý rằng chúng đang bị đóng cửa sớm

Như được chỉ ra bởi một số câu trả lời khác, câu hỏi đúng ở đây có lẽ là: tại sao bạn có một trình theo dõi vấn đề. Một câu trả lời tốt cho câu hỏi này (không chỉ từ góc độ quản lý mà còn từ góc độ nhà phát triển) là bắt buộc nếu bạn muốn một hệ thống theo dõi vấn đề thực sự hoạt động và được cập nhật thường xuyên.

Ở nhiều công ty, hệ thống theo dõi vấn đề chủ yếu được sử dụng như một công cụ báo cáo quản lý. Bắt các lập trình viên cập nhật các vấn đề chỉ để quản lý có thể chạy báo cáo không hoạt động tốt. Và việc buộc các lập trình viên cập nhật các vấn đề cũng không hoạt động - bạn có thể đã cập nhật các vấn đề nhưng bạn nên đặt câu hỏi về dữ liệu.

Theo kinh nghiệm của tôi, cách duy nhất để thực sự có các nhà phát triển (và người kiểm thử, quản lý, v.v.) sử dụng hiệu quả một hệ thống theo dõi vấn đề là tích hợp nó vào quá trình phát triển. Điều này có nghĩa là đầu ra của một phần của quy trình trở thành đầu vào cho phần tiếp theo của quy trình.

Để cung cấp cho cơ quan hệ thống theo dõi lỗi tôi sẽ đề nghị như sau:

• Các nhà phát triển chỉ làm việc trên các lỗi / tính năng được đăng nhập trong trình theo dõi vấn đề và không có công việc nào được thực hiện ngoài nó. Tất cả các ý tưởng, dự án tái cấu trúc, các tính năng mới, các công cụ tùy chỉnh sẽ được phát triển, v.v. cũng nên được ghi lại.
• Các vấn đề được làm việc theo thứ tự ưu tiên. Ưu tiên một phần nên được xác định bởi quản lý, nhưng các nhà phát triển chắc chắn cũng có tiếng nói trong việc xác định các ưu tiên. Điều này đặc biệt đúng khi nói đến vấn đề bảo trì và tái cấu trúc.

Để xử lý, bạn có thể sử dụng một cái gì đó như sau:

• trạng thái 'mới' chỉ ra rằng một vấn đề chưa được nhà phát triển chọn và vẫn đang trong hàng đợi các vấn đề ưu tiên
• trạng thái 'được gán' chỉ ra rằng nó đã được gán cho nhà phát triển. Điều này có thể được thực hiện bởi nhà phát triển hoặc người khác như trưởng nhóm. Tôi thấy nó hoạt động tốt khi có một vài vấn đề được chỉ định cho mỗi nhà phát triển và thường là sự pha trộn giữa 'nâng vật nặng' như các tính năng mới và lựa chọn dễ dàng như các lỗi đơn giản hoặc một số công việc bảo trì đơn giản. Điều này cho phép các nhà phát triển lựa chọn công việc tùy thuộc vào tâm trạng của họ.
• trạng thái 'trong tiến trình' có nghĩa là nhà phát triển đang giải quyết vấn đề. Chỉ một hoặc hai vấn đề cho mỗi nhà phát triển nên được 'tiến hành' tại bất kỳ thời điểm nào.
• khi một vấn đề đã được giải quyết, nhà phát triển có thể thay đổi trạng thái của vấn đề thành 'cần kiểm tra' và thay đổi chủ sở hữu thành người kiểm tra. Đây là một bước quan trọng, vì đây cũng là hàng đợi làm việc của những người thử nghiệm.
• người kiểm tra có thể thay đổi trạng thái thành 'thử nghiệm thất bại' và thay đổi quyền sở hữu trở lại nhà phát triển, điều đó có nghĩa là nó sẽ đứng đầu hàng đợi cho nhà phát triển hoặc họ có thể thay đổi trạng thái thành 'sẵn sàng để triển khai'.
• các vấn đề với trạng thái 'sẵn sàng triển khai' sau đó có thể được hợp nhất và phát hành theo chu kỳ phát hành bởi bất kỳ ai chịu trách nhiệm cho các bản phát hành.

Tóm lại: làm cho hệ thống theo dõi vấn đề trở thành một phần thiết yếu của quá trình phát triển và bạn sẽ không phải lo lắng về các vấn đề không được cập nhật.

Có thể họ coi đó là quá nhiều công việc để mở trình duyệt, đăng nhập, tìm vé và điền vào. Có lẽ bạn có thể cố gắng khuyến khích họ bằng móc . Ngày nay, một tính năng phổ biến là trong tin nhắn git / hg [Tôi giả sử bạn sử dụng một trong số này] bạn có thể nhập một cái gì đó giống như FIXED # 123, và vé sẽ tự động thay đổi khi bạn đẩy cam kết của mình. Theo cách đó, gần như không có công việc nào dành cho nhà phát triển [nếu anh ta làm việc trên từng vấn đề trong một chi nhánh riêng biệt - anh ta đã có id vé] và rất có thể anh ta sẽ thêm vài ký tự đó vào thông điệp cam kết. Nếu giải pháp này là không đủ, có lẽ điều đó có nghĩa là phạm vi của vé quá lớn và nên được chia thành nhiều vé nhỏ hơn?

Điều này có vẻ như một vấn đề văn hóa công ty nhiều hơn bất cứ điều gì khác. Ai thiết lập nhu cầu sử dụng trình theo dõi? Nếu đây là thứ mà một người hoặc một nhóm ném ra ngoài đó, và mong mọi người khác chỉ chấp nhận và sử dụng, chúc may mắn. Trừ khi mọi người hiểu nó là gì, biết cách sử dụng nó và chấp nhận rằng nó thực sự làm cho cuộc sống của họ dễ dàng hơn (cuộc sống của họ, KHÔNG phải của bạn), họ sẽ không sử dụng nó trừ khi bị quản lý ép buộc. Điều đó đang được nói, nếu sử dụng trình theo dõi là một quyết định của công ty, thì nó nên được quản lý để thực thi nó. Trừ khi vai trò của bạn bao gồm trách nhiệm và quyền hạn để có được / khiến mọi người sử dụng trình theo dõi (nghe có vẻ như không, như bạn đã chỉ ra bạn là nhà phát triển), bạn sẽ không đi quá xa, bất kể bạn làm gì (thực tế, IMHO ).

Điều này có lẽ tương tự như lý do tại sao thật khó để khiến mọi người nhập vào thời gian của họ thường xuyên. Đó là một công việc tẻ nhạt ...

Nhiều trình theo dõi vấn đề tích hợp với IDE. Ví dụ: Trình theo dõi mục công việc TFS cho phép bạn đánh dấu một tác vụ là đã giải quyết khi bạn thực hiện đăng ký. Thậm chí còn có một tùy chọn để yêu cầu đăng ký được liên kết với một nhiệm vụ. Làm cho việc cập nhật một phần mục công việc của quy trình đăng ký đơn giản hóa mọi thứ. Thay thế là mở trình theo dõi vấn đề trong một giao diện riêng để thực hiện thay đổi.

Một tùy chọn khác là có một cuộc họp trạng thái (hoặc trong thời gian chờ hàng ngày) nơi ai đó mở trình theo dõi và cập nhật các tác vụ khi mọi người cung cấp trạng thái.

Một điều cần tính đến là GUI tự nó là một trở ngại. Ví dụ: một số trở ngại có thể bao gồm:

• Quá nhiều lần nhấp
• Máy chủ ứng dụng theo dõi sự cố không được tối ưu hóa hoặc không đủ năng lực
• Khả năng sử dụng hoặc khả năng tiếp cận kém

Việc hiển thị API sẽ cho phép trình theo dõi vấn đề được cập nhật thông qua tập lệnh giống như các tạo phẩm kỹ thuật (phạm vi bảo hiểm mã, báo cáo thử nghiệm đơn vị, trạng thái bản dựng, v.v.).

Tài liệu tham khảo

• Scrumwise - API

• Tham chiếu API đám mây JIRA

• API dịch vụ nội dung Alfresco