Mengapa begitu sulit untuk membuat karyawan memperbarui pelacak masalah?

31

Saya selalu mengalami kesulitan untuk membuat orang memperbarui masalah mereka, baik di perusahaan saya maupun di tempat kerja. Saya punya beberapa kasus ketika orang benar-benar melakukannya dari kebaikan hati mereka, tetapi ~ 70% dari waktu saya harus mengejar orang.

Menjadi orang yang pada umumnya melakukan beberapa atau bentuk manajemen lainnya (saya adalah yang pertama menjadi pengembang), alasan utama yang saya coba berikan adalah bahwa saya tidak ingin memburu orang dan mengganggu permintaan tentang kemajuan, tetapi saya tidak Saya pikir pada akhirnya orang tidak akan banyak bertanya. Dalam beberapa kasus yang jarang dan ekstrim saya akhirnya memperbarui tiket mereka (ketika saya harus membuat laporan).

Jadi, apakah Anda mengalami masalah ini ?, bagaimana Anda mendorong pengembang untuk memperbarui pelacak masalah sesering mungkin ?, tingkat kesuksesan apa yang Anda miliki?

project-management issue-tracking

— dukeofgaming
sumber

21

Dari pengalaman pribadi, masalahnya terletak pada mentalitas bahwa memperbarui pelacak masalah dan menjaga dokumentasi yang tepat secara umum tidak sepenting pengkodean. Dan sementara ini adalah mentalitas yang agak alami untuk seorang pengembang, itu seharusnya tidak untuk manajemen dan perusahaan pada umumnya. Apakah perusahaan Anda memperlakukan bagian pekerjaan itu sama pentingnya dengan pengkodean? Jika tidak, Anda harus mulai dari sana, pengembang cerdas dan adaptif, jika mereka merasa bahwa perusahaan benar-benar menganggap ini masalah besar (dengan pujian ketika dilakukan dengan benar dan konsekuensi ketika tidak), mereka akan segera mulai melakukannya dengan benar.

— yannis

@YannisRizos Komentar ini cukup baik untuk menjadi jawaban

— dukeofgaming

14

Ah! Saya bahkan tidak bisa membuat bos saya menggunakan pelacak masalah. Dia berjalan, berbicara dengan cepat tentang "barang" dan pergi. Saya menyebutnya "laporan bug drive-by". Saya benar-benar diejek karena menggunakan pelacak masalah ... Saya merasakan frustrasi di Angkatan.

— MetalMikester

3

imo, sebagian besar 'pelacak isu' yang saya lihat sangat buruk - akhirnya ui terlalu rumit (sehingga mereka dapat menangani kasus khusus). Jadi jika Anda bertanya kepada saya mengapa saya tidak menggunakannya, itu sebabnya.

— GrandmasterB

1

Secara efektif, pastikan Anda memiliki aplikasi yang berfungsi dengan baik, mudah digunakan, cepat dan tidak memerlukan terlalu banyak informasi untuk dimasukkan. Cacat juga perlu diklasifikasikan seperti apa yang harus dilakukan dalam rilis berikutnya dan informasi yang dimasukkan harus digunakan. Sebagai contoh, jika seorang pengembang menjelaskan semuanya dengan benar tetapi Anda terlalu malas untuk membacanya dan malah bertanya kepadanya, maka jelas seseorang akan kehilangan motivasi untuk menggunakan sistem karena sangat frustasi untuk menjelaskan hal yang sama dua kali.

— Phil1970

30

Alasannya adalah mereka tidak mengerti mengapa mereka harus memperbarui pelacak masalah, terlepas dari kenyataan bahwa Anda mengatakannya.

Mengapa demikian? Dugaan saya adalah bahwa memperbarui pelacak tidak memengaruhi pekerjaan mereka dengan cara apa pun yang berarti, jadi solusinya mungkin menerapkan sistem pelacakan yang sebenarnya membantu mereka melakukan pekerjaan mereka dengan lebih baik.

— Martin Wickman
sumber

"Terapkan sistem pelacakan yang sebenarnya membantu mereka melakukan pekerjaan mereka dengan lebih baik." Bisakah Anda memberi contoh? Dari sesuatu yang membantu mereka, bukan sistem pelacakan khusus.

— Burhan Ali

2

@ BurhanAli Tidak. Saya tidak dalam posisi untuk memberi tahu mereka apa yang berhasil bagi mereka. Mereka perlu mencari tahu sendiri. Namun sarannya: mulailah dengan sesuatu yang sederhana dan gunakan umpan balik mingguan untuk memperbaikinya.

— Martin Wickman

Tim Anda mungkin berbeda, tetapi sebagai contoh, saya mulai menjadi jauh lebih baik tentang memperbarui pelacak masalah ketika saya mulai menggunakannya sebagai pusat komunikasi sehingga saya tidak akan terganggu sesering mungkin ketika berada jauh di dalam kode.

— Morgen

13

Sulit, karena karyawan jelas merasa bahwa memperbarui pelacak masalah tidak penting. Anda harus mengubahnya, tetapi ada tangkapan. Komunikasi itu sulit. Komunikasi yang efektif sangat sulit - jauh lebih sulit daripada yang Anda kira. Sangat sulit, sehingga komunikasi biasanya gagal, kecuali karena kecelakaan .

Tunjukkan, jangan katakan. Misalnya. jangan katakan bahwa Anda (atau bos Anda) membutuhkan data untuk laporan. Tunjukkan dari sudut pandang karyawan bagaimana pelacak isu terbaru mempengaruhi dan membantu mereka.

Menurut contoh.

— Maglob
sumber

10

Saya seorang pengembang dan berjuang untuk menggunakan pelacak masalah yang kami miliki di tempat kerja. Ini sangat disayangkan karena saya semua bagi mereka untuk menjaga semuanya tetap teratur. Solusi saya untuk saat ini adalah menggunakan alat pelacakan pribadi dan merujuknya untuk membicarakan kemajuan di scrum harian kami.

Inilah yang akan membuat saya menggunakan pelacak sepanjang waktu:

Integrasi sempurna dengan IDE dan kontrol sumber. Kami menggunakan beberapa webapp kikuk karena lisensi sudah dibeli untuk itu. Dibutuhkan selamanya untuk membuat / memperbarui tugas, dan memiliki beberapa fitur UI yang membingungkan. Sayangnya menggunakan ini di luar kendali tim kami.
Kesederhanaan. Maksud saya, tidak mengambil 10 bidang yang diisi secara manual hanya untuk menambah tugas. Perkiraan jam vs. waktu penyelesaian, secara manual memasukkan proyek / komponen / dll. di beberapa bidang, dll. hanya menambah jumlah waktu.
Hanya satu. Tidak yakin seberapa umum hal ini, tetapi manajemen proyek menggunakan satu alat, dukungan menggunakan yang lain, dan pengembangan menggunakan yang ketiga. Jika seseorang tidak mendapatkan pembaruan, tiga tentu tidak dan sinkronisasi di antara mereka tidak akan otomatis.

— Kriptik
sumber

8

Pertama-tama: apa yang Anda maksud dengan "orang yang memperbarui kemajuan mereka"?

Apakah maksud Anda "pengembang memperbarui estimasi saat ini", atau "pengembang tidak menetapkan masalah untuk diselesaikan", atau lebih tepatnya "pelanggan / penguji tidak menutup masalah yang diselesaikan", atau semuanya?

Dari perspektif pengembang, ini adalah campuran dari pola pikir dan budaya.

pola pikir: ketika Anda mengatur masalah untuk diselesaikan itu berarti Anda selesai, dan bertanggung jawab jika bermasalah
budaya: jika seluruh perusahaan tidak terlalu tertarik untuk menggunakan alat tersebut, tetapi lebih suka strategi organisasi lainnya

Pengalaman saya adalah: Anda membutuhkan budaya untuk menunjuk ke arah yang benar, setidaknya. Apa yang membantu selanjutnya adalah mendefinisikan DoD (definisi 'selesai') - jika pengembang (bekerja untuk peran lain juga) dapat mengatakan (s) ia memenuhi seluruh daftar itu lega untuk menandai masalah terselesaikan dan melanjutkan tanpa perlu untuk melihat ke belakang.

— Andy
sumber

5

Berhentilah bertanya tentang kemajuan koding (biasanya persentase sewenang-wenang dicabut dari udara) sampai tiket ditutup tanpa kredit. Jika hal utama yang Anda ukur adalah jumlah tiket yang ditutup akan meningkat.

Namun perlu dicatat bahwa semua metrik dapat dimainkan dan metrik cenderung bekerja lebih baik ketika bergabung dengan metrik pelengkap misalnya Anda mungkin juga ingin melihat masalah yang dibuka kembali karena ini menyiratkan bahwa mereka sedang ditutup sebelum waktunya

— jk.
sumber

5

Seperti yang ditunjukkan oleh beberapa jawaban lain, pertanyaan yang tepat di sini mungkin adalah: mengapa Anda memiliki pelacak masalah. Jawaban yang bagus untuk pertanyaan ini (tidak hanya dari perspektif manajemen tetapi juga dari perspektif pengembang) sangat penting jika Anda ingin sistem pelacakan masalah benar-benar berfungsi dan diperbarui secara berkala.

Di banyak perusahaan, sistem pelacakan masalah terutama digunakan sebagai alat pelaporan manajemen. Membuat pemrogram memperbarui masalah hanya agar manajemen dapat menjalankan laporan tidak berfungsi dengan baik. Dan memaksa pemrogram untuk memperbarui masalah juga tidak berfungsi - Anda mungkin telah memperbarui masalah tetapi Anda harus mempertanyakan data.

Dalam pengalaman saya, satu-satunya cara untuk benar-benar memiliki pengembang (dan penguji, manajemen, dll.) Secara efektif menggunakan sistem pelacakan masalah adalah dengan mengintegrasikannya ke dalam proses pengembangan. Ini berarti bahwa output dari satu bagian dari proses menjadi input ke bagian selanjutnya dari proses.

Untuk memberikan otoritas sistem pelacakan bug, saya akan menyarankan yang berikut ini:

Pengembang hanya bekerja pada bug / fitur yang masuk dalam pelacak masalah dan tidak ada pekerjaan yang dilakukan di luar itu. Semua ide, proyek refactoring, fitur baru, alat kustom untuk dikembangkan, dll. Harus dicatat juga.
Masalah dikerjakan sesuai urutan prioritas. Prioritas sebagian harus ditentukan oleh manajemen, tetapi pengembang harus memiliki suara dalam menentukan prioritas juga. Ini terutama benar ketika datang ke masalah pemeliharaan dan refactoring.

Untuk memproses, Anda dapat menggunakan sesuatu seperti berikut:

status 'baru' menunjukkan bahwa masalah belum diambil oleh pengembang dan masih dalam antrian masalah yang diprioritaskan
status 'ditugaskan' menunjukkan bahwa itu telah ditetapkan ke pengembang. Ini bisa dilakukan oleh pengembang atau orang lain seperti pemimpin tim. Saya menemukan ini bekerja dengan baik untuk memiliki beberapa masalah yang ditugaskan untuk masing-masing pengembang, dan biasanya campuran 'angkat berat' seperti fitur baru dan hasil yang mudah seperti bug sederhana atau beberapa pekerjaan pemeliharaan sederhana. Ini memungkinkan pengembang untuk memilih pekerjaan tergantung pada suasana hati mereka.
status 'sedang berlangsung' berarti pengembang sedang mengerjakan suatu masalah. Hanya satu atau dua masalah per pengembang yang harus 'dalam proses' kapan saja.
setelah masalah diselesaikan, pengembang dapat mengubah status masalah menjadi 'perlu pengujian' dan mengubah pemilik menjadi tester. Ini merupakan langkah penting, karena ini juga merupakan antrian kerja para penguji.
penguji dapat mengubah status menjadi 'pengujian gagal' dan mengubah kepemilikan kembali ke pengembang yang berarti masuk ke antrian teratas untuk pengembang, atau mereka dapat mengubah status menjadi 'siap untuk digunakan'.
masalah dengan status 'siap untuk digunakan' kemudian dapat digabungkan dan dirilis sesuai dengan siklus rilis oleh siapa pun yang bertanggung jawab atas rilis.

Singkatnya: jadikan sistem pelacakan masalah sebagai bagian penting dari proses pengembangan dan Anda tidak perlu khawatir tentang masalah yang tidak diperbarui.

— Mauritz Hansen
sumber

3

Mungkin mereka menganggap terlalu banyak pekerjaan untuk membuka browser, masuk, menemukan tiket dan mengisinya. Mungkin Anda bisa mencoba mendorong mereka dengan kaitan . Saat ini adalah fitur umum bahwa dalam pesan git / hg [Saya berasumsi Anda menggunakan salah satu dari ini] Anda dapat mengetik sesuatu seperti suka TETAP # 123, dan tiket akan secara otomatis berubah setelah Anda mendorong komit Anda. Dengan begitu hampir tidak ada pekerjaan untuk pengembang [jika dia bekerja pada setiap masalah di cabang terpisah - dia sudah memiliki tiket id] dan kemungkinan besar dia akan menambahkan beberapa karakter dalam pesan komit. Jika solusi ini tidak cukup, mungkin itu berarti ruang lingkup tiket terlalu besar, dan harus dibagi menjadi banyak tiket yang lebih kecil?

— mkk
sumber

3

Ini kedengarannya seperti masalah budaya perusahaan lebih dari apa pun. Siapa yang melembagakan kebutuhan untuk menggunakan pelacak? Jika ini adalah sesuatu yang dilemparkan satu orang atau kelompok ke sana, dan mengharapkan orang lain untuk hanya menerima dan menggunakan, semoga sukses. Kecuali orang mengerti apa itu, tahu bagaimana menggunakannya, dan menerima bahwa itu benar-benar membuat hidup mereka lebih mudah (hidup mereka, BUKAN milikmu), mereka tidak akan menggunakannya kecuali dipaksa oleh manajemen. Karena itu, jika menggunakan pelacak adalah keputusan perusahaan, maka manajemen harus menerapkannya. Kecuali peran Anda mencakup tanggung jawab dan wewenang untuk membuat / menggunakan orang pelacak (terdengar seperti tidak, seperti yang Anda tunjukkan sebagai pengembang), Anda tidak akan melangkah terlalu jauh, apa pun yang Anda lakukan (secara realistis, IMHO ).

— pemburu
sumber

2

Ini mungkin mirip dengan mengapa sangat sulit untuk membuat orang memasukkan waktu mereka secara teratur. Ini pekerjaan yang membosankan ...

Banyak pelacak isu terintegrasi dengan IDE. Misalnya, Pelacak Item Pekerjaan TFS memungkinkan Anda menandai tugas yang telah diselesaikan saat Anda melakukan check-in. Bahkan ada opsi untuk mengharuskan check-in dikaitkan dengan tugas. Membuat pembaruan item item kerja bagian dari proses checkin menyederhanakan banyak hal. Alternatifnya adalah membuka pelacak masalah dalam antarmuka terpisah untuk melakukan perubahan.

Pilihan lain adalah mengadakan pertemuan status (atau selama standup harian) di mana seseorang membuka pelacak dan memperbarui tugas saat orang memberikan status.

— Michael Brown
sumber

0

Satu hal yang harus dipertimbangkan adalah GUI itu sendiri menjadi penghalang. Misalnya, beberapa kendala mungkin termasuk:

Terlalu banyak klik
Server Aplikasi Pelacak Masalah yang tidak dioptimalkan atau kurang bertenaga
Kegunaan atau aksesibilitas buruk

Mengekspos API akan memungkinkan pelacak masalah diperbarui melalui skrip yang sama dengan artefak teknis (cakupan kode, laporan pengujian unit, status bangunan, dll).

Referensi

— Paul Sweatte
sumber

Di salah satu tempat kerja saya, kami menggunakan Jira dan setengah tahun pertama adalah alasan saya belajar membencinya - lambat, membengkak, prosesnya buruk, saya harus menandai menghabiskan waktu di Jira, di rumah saya sendiri perangkat lunak pelacakan waktu pribadi dan perangkat lunak berpemilik yang tidak membantu. Jika bugtrack membutuhkan lebih dari satu detik untuk memperbarui antar klik, itu terlalu lama. Pada akhirnya saya belajar untuk menyukai Jira ketika perangkat keras yang lebih baik dilemparkan ke dalamnya dan prosesnya selesai.

— Maurycy