Bagaimana cara menangani jenis permintaan "Bisakah Anda menambahkan beberapa bidang saja" dari pelanggan?


12

Biasanya kami memiliki permintaan fitur untuk bidang yang hanya diinginkan oleh satu pelanggan. Ini, paling-paling, mengacaukan kode aplikasi. Seringkali ketika kita melihat dalam database mereka beberapa bulan setelah menambahkan bidang, kita dapat melihat bahwa mereka sebenarnya tidak menggunakan bidang ekstra. Selain itu, ini adalah aplikasi yang cukup lama sehingga menambahkan satu bidang memerlukan beberapa perubahan kode, mengubah laporan, dan memastikan bahwa itu tidak memengaruhi pelanggan lain yang tidak perlu melihat bidang tersebut.

  • Bagaimana kami dapat memastikan bahwa pelanggan benar-benar membutuhkan permintaan fitur ini?

  • Bagaimana kita dengan sopan mengatakan "kamu tidak benar-benar membutuhkan itu"?

Saat ini kami mulai mengenakan biaya untuk permintaan fitur tertentu. (Sebelumnya, permintaan fitur biasanya gratis) Apakah ada hal lain yang bisa kita lakukan?


Dengan banyak gerutuan dan kutukan di bawah nafasku>. <Bagaimanapun juga, mereka membayar saya ....
Rachel

Jawaban:


16

Apakah mereka membayar untuk fitur tambahan? Jika demikian, maka itu benar-benar bukan bisnis Anda apakah mereka menggunakannya atau tidak. Beri mereka apa yang mereka bayar. Namun, jika bukan itu masalahnya, maka tergantung pada kepemimpinan Anda untuk memutuskan apakah mereka ingin terus menambahkan fitur tanpa penghasilan tambahan.


2
Ya, mereka membayar, tetapi kami benar-benar ingin berfokus pada permintaan fitur yang lebih besar yang pada akhirnya akan mereka gunakan (dan itu mungkin memberi kami lebih banyak pelanggan di masa mendatang) daripada banyak permintaan kecil sepele yang hanya mengacaukan kode
Earlz

8
@ Elarlz - "Kami benar-benar ingin fokus pada ..." - Saya yakin Anda akan seperti itu bukan cara kerja hubungan pelanggan. Permintaan kecil ini (yang dapat menambah nilai signifikan bagi pelanggan) adalah harga yang Anda bayar untuk mengerjakan hal-hal yang lebih besar. Mereka membutuhkan pemasok yang merespons kebutuhan mereka, bukan siapa yang mengambil dan memilih. Cara untuk mengatasinya adalah dengan memberi harga pada mereka secara adil tetapi untuk menunjukkan bahwa menggabungkan mereka ke dalam rilis yang lebih besar adalah hemat biaya (lebih sedikit pengujian regresi dan sebagainya) dan mencoba dan membuatnya lebih menarik untuk menanganinya seperti itu, tetapi Anda tidak bisa pilih dan pilih.
Jon Hopkins

2
Jika Anda dapat memotong biaya hingga 50% dengan kehilangan 5% dari pelanggan, itu bagus, menurut kebijaksanaan konvensional. Apakah bidang khusus ini benar-benar banyak berkeringat untuk imbalan kecil?
9000

5
Ada kecenderungan buruk dalam pengembangan perangkat lunak bagi pengembang untuk tidak ingin melakukan apa yang diinginkan pelanggan, karena itu tidak keren atau menyenangkan. Kami para pengembang cenderung menempatkan kebahagiaan kami sendiri di atas keinginan pelanggan hampir secara universal. Namun, ini bukan tentang kesenangan dan kesenangan kita. Ini tentang pelanggan. Pelanggan adalah orang yang membayar tagihan, Anda sebaiknya membuatnya bahagia. Jika Anda berada dalam bisnis menulis perangkat lunak yang dapat disesuaikan, ini adalah bagian dari pekerjaan.
John Kraft

3
@Wayne M terima kasih telah menunjukkan sikap yang saya maksudkan. Pelanggan mungkin tidak mengerti teknologi, tetapi mereka biasanya bukan idiot. Biasanya pengembang yang tidak mengerti kebutuhan bisnis. Selain itu, jika menambahkan fitur membahayakan integritas aplikasi, itu pertanda desain aplikasi yang buruk.
John Kraft

3

Kami memiliki situasi yang serupa. Cara kami menangani membangun hubungan berbasis kepercayaan yang memberi kami kebebasan untuk mengatakan "Anda tidak membutuhkan ini". Butuh waktu, kesabaran dan Anda harus siap untuk berbicara banyak dan makan siang dan tugas-tugas membosankan lainnya. Rapat yang membosankan ini akan membayar untuk diri mereka sendiri dalam jangka panjang di mana Anda dapat fokus pada pembuatan fitur yang sangat penting.

Berbicara juga akan membuat Anda melihat apakah yang mereka minta benar-benar penting.


3

Saya tidak berpikir Anda bisa masuk ke "apakah Anda benar-benar membutuhkannya?" perselisihan dengan pelanggan. Secara pribadi, saya ingin bertanya, "Bagaimana ini akan membuat perusahaan Anda lebih banyak uang?" tetapi faktanya adalah, beberapa manajer, untuk beberapa alasan ingin melacaknya dan mereka terbiasa untuk mendapatkan apa yang diinginkan. Jika Anda tidak ingin melakukannya, katakan tidak atau minta sejumlah besar uang untuk mencegah permintaan.

Mulailah mempertimbangkan cara untuk mempermudah aplikasi Anda menangani lebih banyak bidang pelanggan.

  1. Izinkan label dalam laporan dan formulir ditetapkan oleh pelanggan untuk memanfaatkan bidang yang ada.
  2. Tambahkan bidang generik (String12) ke tabel bidang kustom yang ada atau tambahan.
  3. Memiliki sistem lapangan yang ditentukan pengguna di mana ini semua ditangani oleh entri data dan tidak harus membuat kolom baru dalam tabel (Saya tidak ingat apa ini disebut-bantuan.).

Anda mungkin menemukan bahwa pelanggan yang sudah ada mengembangkan sistem Anda. Industri mungkin bergeser sehingga persyaratan baru bermunculan.

Maaf, tetapi jika Anda tidak dapat menawarkan pelanggan Anda apa yang mereka inginkan semata-mata karena alasan teknis dan bukan laba, Anda perlu mengambil langkah. Tidak akan sulit bagi pendatang baru untuk memasuki pasar Anda dengan lebih banyak bidang, jadi jangan biarkan itu terjadi.


3

Melihat dari sisi lain jendela sejenak, di pekerjaan terakhir saya, saya terkena sistem ERP yang memungkinkan kolom "kustom" ditambahkan oleh pengguna akhir ke entitas / tabel. Dari interaksi singkat saya dengannya, sepertinya mereka secara dinamis menambahkan kolom ke tabel kedua dengan pemetaan satu-ke-satu. Contohnya:

Tabel WIDGET dengan kolom statis:

  • WIDGET_ID
  • WIDGET_NAME
  • WIDGET_COST
  • dll.

Tabel WIDGETCUSTOM dengan kolom yang dapat ditentukan pengguna:

  • WIDGET_ID
  • WIDGET_WEIGHT
  • DID_BOB_WORK_ON_WIDGET
  • dll.

Kolom WIDGET_ID dapat mengikat keduanya. Secara otomatis menampilkan bidang tambahan Anda saat mengedit widget, dan Anda dapat memasukkannya dalam laporan dinamis, atau bahkan mencari berdasarkan itu. Itu cukup efisien karena database masih bisa melacak dan mengindeks kolom-kolom itu jika perlu, dll.

Dari sudut pandang pemrograman, saya melihat bagaimana itu akan tetap waras. Setiap pelanggan dapat memiliki kolom khusus mereka sendiri, tetapi kolom khusus tersebut tidak mengganggu logika inti Anda.


Aplikasi ini terlalu rumit untuk menambahkan fungsi seperti itu tanpa perombakan besar. Jadi solusi ini keluar (tetapi direncanakan dalam pembaruan versi utama yang akan datang semoga setahun)
Earlz

1
Jika Anda bisa menangani ini dalam setahun, apa masalahnya?
JeffO

@ Jeff satu tahun dengan asumsi kita tidak terjebak oleh permintaan fitur ini dalam waktu yang bersamaan .. Setahun pada waktu pengembangan tanpa gangguan pada dasarnya
Earlz

1

Fitur "permintaan" hanya itu, permintaan. Jika mereka membuat tuntutan maka Anda perlu memutuskan berapa nilainya bagi perusahaan untuk "mengacaukan" basis kode dengan itu. Jika itu menjadi masalah endemik maka Anda dapat menekannya, tetapi jika mereka bersedia membayar apa yang Anda minta atau sesuatu yang dekat dengannya dan itu hanya beberapa fitur di sana-sini, saya katakan gunakan uang itu.

Untuk melangkah lebih jauh, jika ini adalah masalah konstan dengan produk Anda dan banyak pelanggan mencari jenis penyesuaian ini, mungkin inilah saatnya untuk memikirkan kembali bagian-bagian aplikasi Anda ini dan menjadikannya fleksibel dengan cara yang diberdayakan oleh pelanggan untuk melakukan hal ini sendiri, baik itu pelaporan ad-hoc, pengumpulan data yang fleksibel, dll. Cobalah untuk mengubah gangguan ini menjadi nilai jual. "Model data stok kami tidak cukup baik untukmu? Lihat opsi penyesuaian kami! Kamu bisa melakukannya sendiri!"


2
Ingat, di balik setiap masalah adalah peluang untuk membuat solusi, dan kemudian menjualnya kepada seseorang;)
MattC

0

Anda harus menentukan dengan tepat apa yang akan Anda lakukan di fitur tersebut dan menerapkan perkiraan waktu untuk membuatnya. Jika pelanggan menginginkan bidang tambahan yang baik, tagihan mereka untuk itu. Saya memberi tahu pelanggan saya bahwa jika Anda ingin menambahkan fitur setelah saya membangun fitur, itu baik-baik saja, tetapi akan sedikit lebih mahal untuk membuatnya, dalam beberapa kasus.

Saya mengalami kesulitan memahami mengapa Anda peduli apakah mereka menggunakannya atau tidak. Sederhana, Anda membangun apa yang mereka inginkan dan Anda dibayar untuk itu.

Kekacauan basis kode? Jika Anda perlu memperbaiki kode Anda saat bekerja di fitur baru, biayanya untuk itu.


0

Buat daftar beberapa fitur yang Anda pertimbangkan untuk ditambahkan, termasuk menambahkan "hanya beberapa bidang tambahan". Perlihatkan daftar itu kepada pelanggan Anda dan minta mereka untuk umpan balik tentang yang mana yang mereka sukai terlebih dahulu. Jelaskan bahwa sumber daya Anda terbatas dan Anda tidak dapat melakukannya sekaligus. Gunakan umpan balik untuk memutuskan arah mana yang ingin Anda tuju dengan aplikasi Anda.

Jika pelanggan menegaskan bahwa beberapa bidang tambahan benar-benar yang penting dan Anda masih memutuskan tidak menambahkan mereka, mudah-mudahan pelanggan masih bisa melihat manfaat dari fitur Anda menerapkan gantinya.


0

Sepertinya Anda mungkin mendapat manfaat dari semacam sistem tarik. Biarkan pengguna memilih fitur apa yang akan diterapkan selanjutnya, tetapi batasi jumlah yang dapat dikembangkan pada waktu tertentu. Papan Kanban sangat bagus untuk ini. Ini dapat memberikan kepemilikan pengguna pada proses priortiztion (alias kurang tanggung jawab dan stres untuk Anda). Percayalah, jika pengguna dipaksa untuk memutuskan fitur mana yang akan dikembangkan, mengetahui bahwa permintaan lain akan dikesampingkan, mereka akan berinvestasi lebih banyak dalam benar-benar memutuskan apa yang harus mereka miliki.


Metode Kanban hanya berfungsi ketika Anda bisa pergi ke Gemba: tempat di mana masalah terjadi. Berada di ruang fisik, berbicara kepada orang-orang yang melakukan pekerjaan, perhatikan mereka menunjukkan kepada Anda bagaimana mereka melakukannya. Lihat dengan mata Anda, sentuh dengan jari-jari Anda. Kemudian, dan hanya kemudian, cobalah mencari cara untuk memperbaikinya. Dan tanyakan kepada mereka bagaimana memperbaikinya.
Christopher Mahan

@ Christopher - titik diambil, tetapi pasti sistem dapat dimodifikasi sampai batas tertentu. Mungkin melupakan Kanban, tetapi cobalah untuk melestarikan ide sistem tarik. Tidak peduli bagaimana cara kerjanya secara khusus, pengguna harus memiliki beberapa cara untuk memprioritaskan tugas dan memilih mana yang akan dilakukan selanjutnya dalam lingkungan di mana pengembangan terus menerus. Pengembang tidak memiliki cara untuk benar-benar mengetahui fitur apa yang perlu dilakukan selanjutnya sendiri.
Morgan Herlocker

1
Ironcode, kamu benar. Saya bekerja di Bank of America dan tim kami memungkinkan unit bisnis memprioritaskan permintaan fitur melalui bug bug prioritas. Mereka mengajukan bug, lalu memprioritaskan bug. Mereka dapat mengubah prioritas kapan saja, dan kami menyesuaikan. Ya, kadang-kadang menimbulkan biaya switching, tetapi kami menemukan itu lebih efektif untuk bisnis. Perhatikan bahwa ini mungkin tidak akan berfungsi untuk poster asli, karena manajemen mungkin memiliki tujuan untuk pelanggan mereka. (sebagai miring ke samping, pendekatan manajemen ini tampaknya salah arah)
Christopher Mahan

0

Saya pikir Anda harus meminta pelanggan Anda untuk menempatkan satu atau lebih dari Anda melalui "hari di kantor" untuk melihat bagaimana mereka benar-benar menggunakan perangkat lunak ... Tunggu ... Pekerjakan saya untuk $ 250 / jam dan saya akan mencari tahu. Juga, tolong, tolong jangan lempeng emas. Buat itu berfungsi. Sebagian besar bisnis tidak peduli itu terlihat jelek ketika bekerja dengan baik.


Kami sudah melakukan ini. Inilah sebabnya kami tahu kapan permintaan fitur mungkin tidak akan digunakan.
Earlz

Ah, well, lalu ada perkelahian politik di perusahaan klien. Anda kacau. Atau Anda bisa Steaks dan Penari Telanjang mereka.
Christopher Mahan

0

Lacak permintaan. Saat Anda merancang / mengembangkan fitur - fitur besar , pilih beberapa permintaan yang diprioritaskan untuk disertakan dalam rilis itu.


0

Bangun sistem negosiasi standar untuk permintaan. Mungkin sesuatu berdasarkan dari pelaporan bug atau sistem permintaan fitur, seperti fogbugz. Izinkan pelanggan Anda untuk mengajukan permintaan, dan prioritaskan berdasarkan:

  • kelayakan teknis / biaya fitur
  • Apakah permintaan fitur itu "berbayar"? Jika ada dalam kontrak, dan / atau mereka sudah membayar untuk itu, maka masukkan
  • apakah fitur "masuk akal"? Ini sedikit seni, tetapi, secara umum, jika cukup banyak pelanggan yang meminta fitur, maka implementasikan secara gratis. Ini merupakan peluang untuk membuat produk Anda lebih baik, dan membuat penjualan ke pelanggan berikutnya menjadi lebih mudah
  • apakah Anda memiliki siklus berbayar yang belum digunakan? Jika Anda memasukkan satu set jam bulanan untuk pemeliharaan / dukungan sebagai bagian dari kontrak Anda (saya sangat menyarankan Anda melakukannya, meskipun jumlahnya sangat rendah), dan mereka tidak terbiasa, mulailah melemparkannya untuk melakukan perubahan semacam ini.

0

Jika pelanggan memiliki total kepemilikan aplikasi, maka lakukan apa yang mereka minta. Biarkan mereka meniup uang mereka; itu milik mereka.

Namun, jika Anda tidak maka Anda ingin pergi ke solusi untuk bidang bantu ini yang melibatkan menyimpannya di luar datamodel inti. Anda kemudian dapat menggunakan sesuatu seperti tampilan basis data untuk menggabungkan bidang tambahan kembali untuk pelanggan khusus ini. (Ada beberapa cara untuk melakukan penyimpanan tambahan, tergantung pada sifat dari data yang disimpan; yang paling sederhana hanyalah sebuah tabel yang memiliki kunci utama yang sama dengan beberapa PK di tabel utama Anda, tetapi itu tidak efisien ketika digunakan bidang sangat jarang. Hanya benar-benar masalah ketika mereka menginginkan fitur bidang yang memerlukan hal-hal seperti pengindeksan.)

Anda juga dapat menunda permintaan pelanggan dengan mengatakan bahwa Anda tidak punya sumber daya yang cukup untuk mengimplementasikannya pada tahap ini. Akan sangat membantu jika pada saat itu Anda menunjuk pada peta jalan Anda yang mengatakan (perkiraan terbaik Anda saat) ketika akan mungkin untuk mengimplementasikan apa yang mereka inginkan dengan harga murah. Dan Anda harus memprioritaskan menjadikan aplikasi dalam keadaan di mana dimungkinkan untuk mendukung fitur dengan murah, karena fitur-meta itu menjadi fitur penjualan inti dari aplikasi utama Anda.

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.