Bagaimana menangani situasi yang sayangnya tidak hipotetis ini dengan pengguna akhir?


22

Saya bekerja di perusahaan berukuran sedang tetapi dengan kekuatan IT yang sangat kecil.

Tahun lalu (2011), saya menulis sebuah aplikasi yang sangat populer dengan sekelompok besar pengguna akhir. Kami mencapai tenggat waktu pada akhir tahun lalu dan beberapa fungsi (saya akan memanggil funcA mulai sekarang) tidak ditambahkan ke dalam aplikasi yang diinginkan pada akhir. Jadi, aplikasi ini sudah berjalan di live / produksi sejak akhir 2011, saya dapat menambahkan tanpa masalah.

Kemarin, seluruh kelompok pengguna akhir mulai mengeluh bahwa fungsi yang tidak pernah ada dalam aplikasi tidak lagi berfungsi. Prioritas kami di perusahaan ini adalah bahwa jika aplikasi rusak, itu harus diperbaiki terlebih dahulu sebelum proyek diprioritaskan.

Saya telah membandingkan kode dan kueri dan tidak ada perbedaan sejak 2011, yang merupakan proofA. Saya kemudian bisa mendapatkan salah satu pengguna akhir untuk mengakui bahwa itu tidak pernah bekerja proofB, tetapi sejak itu pengguna akhir telah kembali dan mengatakan bahwa itu bekerja sebelumnya ... Saya percaya gerombolan pengguna akhir telah berasimilasi nya. Saya juga telah meninjau catatan saya untuk proyek ini yang memiliki persyaratan dan pembaruan harian mengenai proyek yang secara khusus menyatakan, "fungsi tidak tercapai karena keterbatasan waktu", proofC.

Saya telah berbicara dengan banyak dari mereka dan saya dapat melihat di mana mereka bisa bingung karena mereka sangat jauh dari latar belakang pemrograman, tetapi saya juga tahu mereka cukup pintar untuk bertindak dalam suatu kelompok untuk mem-bypass pesanan prioritas proyek untuk mendapatkan fungsi yang mereka inginkan untuk membuat pekerjaan mereka lebih mudah.

Bagian terburuknya adalah bahwa sekarang grup think sudah siap dan bos saya serta kepala TI mulai mempercayai mereka, meskipun tidak ada perubahan kode atau kueri. Sejauh meninjau keadaan logika itu sangat dipotong dan kering ke titik jika 1 = 1, funcA tidak akan berfungsi.

Jadi, ini adalah akhir dari uraian skenario saya, tetapi saya mencoba untuk tidak mendapatkan sedikit metrik kinerja saya karena ini yang pada dasarnya akan membuat saya pindah untuk memperbaiki masalah produksi yang tidak ada yang mungkin akan mengambil alih 1 bulan.


1
Kami bukan forum dalam arti kata tradisional, kami adalah situs tanya jawab yang mencari pertanyaan yang dapat dijawab. Kata-kata kasar, jajak pendapat, dan diskusi pada umumnya tidak sesuai dengan format kami.
maple_shaft

12
@maple_shaft: Saya tidak setuju. Ini adalah pertanyaan serius yang mencari cara untuk berurusan dengan masalah nyata yang terjadi ketika berhadapan dengan, haruskah kita katakan, pengguna akhir kurang tahu. Kita semua pernah melihatnya dan merasa frustrasi karenanya, bukan? Jadi ide tentang bagaimana menangani skenario seperti itu sangat cocok untuk format situs ini.
Mason Wheeler

1
Apakah tidak mungkin ada jawaban untuk pertanyaan ini? Siapa yang akan menonton para pengamat?
Pengguna Smith

2
Agar bermanfaat bagi orang lain yang membaca ini, kasus ini merupakan pelajaran lain bagi kita yang percaya bahwa dokumentasi adalah hal yang sekunder dan bahwa persyaratan bernyanyi tidak penting.
NoChance

1
"tidak ada yang berubah" kata-kata terakhir yang terkenal.
JeffO

Jawaban:


18

Perselisihan tentang fakta yang mudah diamati sebenarnya cukup mudah diselesaikan: cukup amati fakta. Jika saya mengatakan "ada pohon dengan kayu ungu di luar rumah saya," siapa pun yang bisa datang ke rumah saya dapat memverifikasi kebenaran atau kepalsuan pernyataan saya untuk diri mereka sendiri.

Jika mereka mengeluh bahwa FuncA dulu ada di produk dan digunakan untuk bekerja di versi sebelumnya dan sekarang tidak berfungsi, dan Anda tidak berpikir itu pernah ada dalam produk, minta mereka untuk membuktikannya. (Atau, dengan kata-kata yang lebih lembut, ucapkan sesuatu seperti "kita kesulitan mereproduksi masalah. Bisakah Anda membantu kami di sini?")

Beri mereka salinan versi sebelumnya jika mereka belum memilikinya, dan dapatkan mereka di LiveMeeting, dan minta mereka menunjukkan kepada Anda bagaimana mereka dulu menggunakan FuncA. Jika mereka tidak dapat melakukannya, maka (semoga) mereka menyadari bahwa itu tidak ada di sana setelah semua dan keluar dari kasus Anda tentang hal itu, atau setidaknya mencoba taktik yang berbeda untuk menerapkannya. (Dan pastikan untuk mendapatkan seseorang dari manajemen atau PM di LiveMeeting.)


Mereka telah menunjukkan tangkapan layar bukti yang dapat saya jelaskan tetapi hanya sebagian sehingga rincian skenario adalah apa yang mereka katakan, mereka tidak benar-benar didefinisikan melalui tangkapan layar. Pada dasarnya, apa yang terjadi adalah bahwa MGMT tidak terlalu menyadari logika dan pada titik ini adalah kata seluruh dept terhadap satu programmer yang rendah. (Juga versi sebelumnya sama dengan peluncuran awal yang terjadi pada 2011)
Pengguna Smith

3
@ PenggunaSmith: Itu sebabnya saya mengatakan untuk menggunakan LiveMeeting. Lebih sulit untuk keliru tentang apa yang terjadi ketika Anda benar-benar harus melakukannya dengan orang-orang yang menonton.
Mason Wheeler

1
Jawaban ini memberikan definisi bukti yang jauh lebih baik daripada "kata pengguna akhir" atau "Saya membaca kode." Berhentilah dan ingat 10 kali terakhir bahwa sebagai seorang programmer Anda benar-benar terperangah Anda bisa sangat salah meskipun menatap 1 = 1 dalam kode (padahal seharusnya 1 == 1, misal). Jika Anda menganggap pembuktian dalam hal "membaca kode" sebagai manusia yang rawan kesalahan maka terus terang metrik kinerja Anda akan menerima pukulan. @MasonWheeler telah mengusulkan Anda epistemologi yang lebih akurat dan lebih menarik, sebaiknya Anda mengikutinya.
djechlin

Dalam negosiasi ada ungkapan "Jika Anda harus membela diri, Anda sudah kalah". Fakta-fakta pembuktian adalah bentuk utama dari pertahanan - sebagai suatu peraturan, yang terbaik untuk tidak kecuali diminta, meskipun demikian, simpan jika singkat - kurang lebih.
mattnz

1
Ditandai sebagai jawaban mungkin jawaban yang paling konkret. Meskipun saya sudah melakukan pertemuan langsung sebelum memposting pertanyaan ini. Ditambah satu pasangan lagi yang merupakan jawaban yang sebagian bagus. Jujur pada titik ini saya tidak peduli dengan metrik saya, itu lebih pada kenyataan bahwa struktur mendasar dari organisasi TI kami berada dalam keadaan berantakan sehingga ini bahkan terjadi yang membuat saya khawatir.
Pengguna Smith

13

Ini bukan masalah yang bisa diatasi dengan fakta - jika Anda mencoba, Anda akan kehilangan kredibilitas.

Pertama, terima bahwa perangkat lunaknya "rusak" - karena tidak melakukan apa yang diinginkan pengguna. Sekarang, terimalah bahwa pengguna memiliki hak untuk membuat perangkat lunak melakukan apa yang mereka inginkan - itulah sebabnya perangkat lunak itu. Jadi yang kita miliki adalah perangkat lunak yang rusak dan seorang insinyur menolak untuk memperbaikinya .....

Akibatnya jika sistem yang Anda jalankan untuk menetapkan prioritas, pengguna ini tidak dapat memperbaiki perangkat lunak mereka dengan melalui saluran normal, sehingga mereka menggunakan saluran samping dan meningkatkan setengah kebenaran di rantai makanan untuk mencoba keluar dari manuver sistem, di waktu yang bersamaan, membuat KPI Anda terlihat buruk (perhatian utama Anda haruslah pelanggan, bukan KPI Anda) - KPI Anda dianggap "kerusakan jaminan" jika mereka menyukai Anda, atau efek samping yang menguntungkan jika mereka tidak. Namun, mereka memiliki kontrol atas berapa banyak yang terjadi - paling mereka suka Anda.

Jadi yang terjadi adalah sistemnya rusak, dan semua orang berusaha memanipulasi sesuatu untuk mendapatkan apa yang mereka inginkan. Mereka menginginkan fitur, dan Anda ingin menjaga KPI bersih Anda.

Kecuali Anda dapat memperbaiki sistem atau belajar bermain politik kantor dengan sangat cepat, permainan berakhir: Anda kalah.

Catatan: Tidak ada satu pun dari diskusi ini yang melibatkan Dead line, bug vs feature feature, siapa yang membayar, dll. Ini Fakta - dan fakta tidak penting (well, mereka memang melakukan, tetapi mereka dapat dimanipulasi dengan banyak cara .... ) dalam politik kantor.


1
Bagaimana Anda bisa kehilangan kredibilitas jika Anda bisa MEMBUKTIKANnya ?
Thomas Eding

3
@ThomasEding Kredibilitas dalam dunia bisnis lebih tentang bagaimana orang lain memandang Anda daripada tentang fakta. Jika Anda menjadi target maka tidak ada jumlah fakta yang akan melindungi Anda. Berapa banyak pengembang bintang rock yang Anda temui yang merupakan penipu lengkap? Saya telah bertemu lebih dari yang ingin saya akui.
maple_shaft

2
Saya setuju dengan bagian yang baik dari ini, ini jelas merupakan bentuk politik kantor. Ketika bertemu dengan situasi apa pun saya akan berpikir tindakan pertama adalah menangani fakta-fakta, jadi Anda agak kehilangan saya di sana, tetapi saya akan setuju dengan pelanggan datang dulu kpis kedua ke titik sampai Anda tentu saja dipecat. +1 untuk pandangan berbeda tentang situasinya. +1
Pengguna Smith

2
Tidak pernah mengeluh tidak pernah menjelaskan. Berdebat membuat Anda terlihat lemah. Mendengarkan permintaan yang sopan itu baik. Mengatakan Anda akan mendiskusikan permintaan mereka dengan atasan Anda untuk prioritas adalah baik. Jika Anda berdebat, maka lakukan apa yang mereka teriakkan, itu memperkuat perilaku tidak menyenangkan mereka. Jika mereka meningkat, kekuatan posisi bos Anda menegakkan kesopanan. Atasan Anda secara diplomatis dapat menjelaskan pilihannya untuk waktu Anda. Itu juga menunjukkan bahwa mereka bukan bos Anda. Ketika Anda mengatasi masalah dengan bos Anda dengan tenang, Anda mungkin mendengar kata-kata seperti "jangan khawatir, saya mendukung Anda." Tetap fokus, buat produk, kata-kata kasar akan berhenti.
PengembangDon

@ Thomas Tanyakan pada setiap terdakwa yang tidak bersalah apakah kejahatan bermoral yang khusus ....
mattnz

9

Secara organisasi, saya merasakan masalah.

Ada hierarki yang mencakup kepala TI dan bos Anda. Jika organisasi Anda tradisional (tidak terdengar seperti Agile), Anda adalah sumber daya dan mereka adalah manajer sumber daya. Anda memiliki pekerjaan penuh waktu yang disebut pengembangan perangkat lunak. Jika pengguna akhir secara langsung meminta fitur, menetapkan prioritas Anda, dan mencoba mengatur waktu Anda, manajer Anda berlebihan. Mereka mungkin bertanggung jawab kepada pengguna akhir, tetapi jika mereka melakukan pekerjaan mereka, Anda bertanggung jawab kepada mereka dan mereka perlu melindungi Anda dari keluar dari mode pengembang fokus ke mode pengembang defensif .

Beberapa poin untuk mengatur konteks jawaban saya:

  • Pengembang perangkat lunak bukan penjelajah waktu, jadi hasilnya perlu dinilai berdasarkan siapa mereka, bukan seperti apa mereka sebelumnya.
  • Jika fitur dalam spesifikasi persyaratan, jadwal, dan diprioritaskan di atas pekerjaan yang selesai, mungkin ada keluhan yang sah. Jika tidak, apa justifikasi untuk meminta Anda bertanggung jawab?
  • Hukuman Anda, jika pantas, perlu datang dari rantai komando Anda. Sama seperti pemasaran dan penjualan tidak akan suka jika pengembangan produk memarahi pelanggan, sebagian besar organisasi memiliki manajer produk untuk menerima kemarahan pelanggan (dan pujian) dan menyampaikannya melalui saluran.
  • Manajer produk dapat menciptakan hubungan yang sangat sulit jika mereka menikmati kehangatan dari bagian-bagian proyek yang sukses, tetapi hanya akan memecahkan cambuk ketika mereka menghadapi pengembang.
  • Jika Anda mengirimkan produk fungsional dengan nilai kerja setahun, dan butuh satu (atau dua) bulan untuk menambahkan fitur yang diinginkan, dari apa yang saya lihat di industri kami, estimasi Anda di atas rata-rata.
  • Memecahkan masalah secara adil dan produktif mengharuskan orang menaruh kembali jari mereka ke dalam saku mereka dan membuat rencana ke depan.

Anda akan dapat melakukan pekerjaan yang jauh lebih berkualitas dengan motivasi yang lebih baik jika Anda dihargai alih-alih menjadi kambing dalam proses yang harus dimiliki oleh kepala IT. Ini adalah cara yang adil dan cara yang produktif. Saya harap Anda akan dikelola dengan cara itu, dan suatu saat nanti, saya harap Anda akan mengelola orang lain dengan cara itu.


DevDon, berharap ini dengan jawaban # 1 karena saya pikir ini adalah bagian besar dari masalah kami .... struktur IT kami untuk skenario ini sangat serampangan. +1
Pengguna Smith

1

Dalam kasus kegagalan realitas seperti ini, hal terbaik adalah bergerak maju. Alih-alih berdebat tentang masa lalu, bicaralah tentang membuatnya bekerja dan betapa mudah atau sulitnya itu. Tidak masalah apakah masalah itu memperbaikinya atau mengimplementasikan untuk pertama kalinya. Jika manajemen menginginkan A dilakukan sebelum B membuatnya demikian.


Tentu saja ini benar, tetapi ketika pengguna akhir mengetahui bahwa mereka dapat memanipulasi sistem dengan cara ini, perusahaan saya akan berada dalam kemiringan yang serius jika ini terus berlanjut karena sumber daya akan digunakan dengan cara ini dibandingkan digunakan untuk strategi perusahaan secara keseluruhan arahan yang benar-benar akan mendorong garis bawah perusahaan.
Pengguna Smith

0

Apakah Anda satu-satunya pengembang yang mengerjakan proyek ini? Sepertinya Anda menjawab seseorang saat membuat proyek. Di mana orang itu dalam semua ini? Di mana dokumentasi untuk proyek mengatakan apa yang disampaikan?

Harus ada jejak kertas dokumen. Dokumen pelatihan yang menunjukkan cara menggunakan aplikasi. Spesifikasi fungsional yang menguraikan apa yang dikembangkan. Jika fitur tidak dimasukkan, harus ada dokumentasi tentang itu juga. Seseorang harus menandatangani dan mengatakan mereka menerima itu.

Seharusnya kata-kata Anda tidak bertentangan dengan kata-kata mereka, itu semua harus ada dalam dokumentasi.

Jika Anda tidak memiliki dokumentasi ini ... maka saya khawatir Anda harus menggigit yang ini. Anggap itu pelajaran hidup. Pada akhirnya, pengguna Anda adalah pelanggan Anda, dan seperti kata pepatah: pelanggan selalu benar. Buatlah cara untuk menambahkan fitur ini dan berapa lama. Adakan pertemuan dan katakan sesuatu di sepanjang baris 'Catatan kami menunjukkan bahwa fitur ini tidak pernah diterapkan, tetapi kami bisa membuatnya hidup dalam x minggu. Haruskah kita pergi kepala? "

Dan untuk cinta semua yang suci .... dapatkan dokumentasi yang Anda butuhkan untuk menunjukkan itu disetujui.


Ya, saya adalah satu-satunya yang mengerjakan proyek ini. Ada dokumentasi dengan pembaruan harian yang saya sebut proofC dalam pertanyaan saya.
Pengguna Smith

@ PenggunaSmith ~ Saya menganggap itu lebih berarti pembaruan status harian. Itu sebenarnya bukan dokumentasi yang saya bicarakan. Apakah seseorang menandatangani produk akhir? Apakah ada pelatihan atau dokumentasi aplikasi yang Anda berikan kepada pengguna akhir atau pemegang pasak?
Tyanna

Sayangnya tidak ada. Ada pelatihan tetapi periode pelatihannya sangat singkat. Ada dokumentasi aplikasi tetapi tidak mencakup kurangnya fungsi yang ada. Pembaruan harian pada dasarnya adalah alat jurnal yang kami gunakan untuk menjelaskan deskripsi awal, harian, dan akhir tentang apa yang terjadi dengan suatu proyek.
Pengguna Smith
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.