Apa hubungan yang tepat antara pengembang perangkat lunak dan pelanggan bisnis?

Profesional TI adalah pakar yang dipercaya dengan aset TI bisnis atau organisasi. Sebagai profesional tepercaya, kami memiliki tanggung jawab yang melampaui hal-hal yang diharapkan dipahami atau disadari oleh pelanggan non-TI. Jadi saya pikir hubungan yang tepat antara seorang profesional TI dan pelanggan internal / eksternalnya lebih mirip antara seorang dokter dan pasien daripada seorang pelayan dan master. Apakah saya benar?

Inilah analogi untuk dipikirkan. Seorang pasien bersikeras bahwa kakinya perlu diamputasi. Dokternya tidak setuju tetapi pasien tidak dapat dibujuk. Haruskah dokter mengamputasi kaki hanya untuk memuaskan pasien?

Analogi lain. Seorang pelanggan menginginkan seorang insinyur sipil untuk membangun jembatan ke desain yang tidak aman. Bahkan ketika insinyur menjelaskan bahwa itu tidak aman, pelanggan tidak mempercayainya. Haruskah insinyur membangun jembatan?

Saya pikir jawaban yang tepat di kedua analogi ini adalah TIDAK. Profesional medis dan insinyur profesional seharusnya dalam posisi percaya dan harus melakukan penilaian mereka sendiri, bahkan dalam menghadapi ketidaksetujuan pasien / pelanggan. Bukankah seharusnya hal yang sama berlaku untuk profesional TI ketika profesional TI memenuhi syarat untuk membuat keputusan tetapi pelanggannya tidak?

Ini sedikit lebih rumit daripada di contoh Anda. Itu karena dalam banyak kasus, pengembang perangkat lunak adalah pakar dalam hal-hal yang berhubungan dengan TI (yaitu pemrograman, desain basis data, dll.), Tetapi pelanggan bisnis adalah pakar dalam domain masalah. Dalam kasus seperti itu, hubungan yang tepat adalah hubungan dua pakar di bidang berbeda yang bekerja sama untuk menciptakan solusi yang baik.

Bagaimanapun, seperti pengrajin yang baik, pengembang perangkat lunak diwajibkan untuk memperingatkan pelanggan ketika pelanggan menginginkan hal-hal yang tidak pantas. Jika Anda meminta pelukis dan dekorator Anda untuk merapikan kamar mandi, ia juga wajib memperingatkan Anda bahwa ini tidak akan berhasil. Tetapi ketika klien dengan keras kepala bersikeras pada ide buruknya, tidak apa-apa baginya untuk menandatangani formulir "Anda telah diperingatkan secara eksplisit" dan mengimplementasikan apa yang diinginkannya (selama tidak ada risiko kesehatan, risiko hukum, dll. Dalam melakukan itu).

Baik dalam contoh dokter dan insinyur, profesional adalah konsultan yang menolak untuk melakukan layanan. Di toko IT, Anda tidak.

Kita adalah karyawan, bukan konsultan, jadi kita tunduk pada aturan emas: dia yang memberi kita aturan emas. Programmer yang mengabaikan itu menjadi arogan dan bodoh. Saya telah mendengar banyak sekali keluhan tentang hal itu dari para pebisnis yang muak dengan staf TI yang tidak akan menjelaskan keputusan mereka kepada siapa pun di luar imamat mereka yang picik, dan yang menolak permintaan semua orang di luar organisasi mereka yang dianggap masuk akal. Saya telah melihat manajer TI dipecat karena hal semacam itu.

Sebagai seorang karyawan, padanan Anda dengan konsultan yang menolak untuk melakukan suatu layanan dilindungi oleh kutipan dari Napoleon Bonaparte:

Setiap komandan yang bertanggung jawab untuk melaksanakan rencana yang ia anggap buruk atau malapetaka adalah kriminal. Dia harus menunjukkan kelemahannya, bersikeras bahwa itu harus diubah dan akhirnya mengundurkan diri daripada menjadi alat penghancuran orang-orangnya sendiri.

Anda harus memilih pertempuran Anda. Apakah Anda diminta melakukan tindakan keji dan tidak etis sehingga Anda ingin berhenti? Jika tidak, maka jelaskan masalahnya kepada para pemangku kepentingan dan negosiasikan sesuatu yang masuk akal, atau lakukan saja.

Dan jangan melakukan hal-hal yang belum pernah Anda lakukan. Orang yang melakukan itu disebut "meriam longgar".

Kebetulan, saya telah berhenti dari satu pekerjaan karena mereka membunuh proyek dan saya pikir itu adalah langkah yang sangat bodoh. Beberapa bulan setelah saya pergi, mereka datang untuk setuju dengan saya, dan meminta saya kembali sebagai kontraktor untuk melakukan proyek, tetapi saya sudah berkomitmen di tempat lain.

Dokter mengambil sumpah untuk 'tidak membahayakan' dan secara hukum diperlukan untuk menempatkan kepentingan terbaik pasien pertama . Seorang dokter yang melakukan operasi yang tidak perlu dan berbahaya (bahkan jika pasien menuntutnya) akan membuka diri terhadap gugatan malpraktek dan bisa kehilangan lisensi.

Demikian pula, seorang insinyur sipil, yang bertanggung jawab untuk proyek konstruksi, memiliki kewajiban hukum untuk memastikan bahwa ia memenuhi semua kode bangunan yang berlaku. Seperti halnya dokter, seorang insinyur yang melakukan apa yang disarankan dalam pertanyaan, kemungkinan akan menghadapi tindakan hukum.

Ini sangat berbeda dari situasi pengembang perangkat lunak yang diminta untuk melakukan sesuatu yang mereka tahu tidak praktis. Tidak ada konsekuensi hukum untuk mengambil proyek, bahkan jika Anda tahu itu pada dasarnya membuang-buang uang.

Yang mengatakan, seorang pengembang perangkat lunak harus selalu memberikan saran terbaiknya pada proyek apa pun. Namun, jika orang yang membayar tagihan tidak mau mendengarkan dan bersikeras melakukan tindakan yang tidak bijaksana, pengembang tidak memiliki kewajiban moral atau hukum untuk menolak.

Bukankah seharusnya hal yang sama berlaku untuk profesional TI ketika profesional TI memenuhi syarat untuk membuat keputusan tetapi pelanggannya tidak?

Menurut pendapat saya YA!

Jika Anda akan memiliki hubungan panjang dengan pelanggan Anda.

Saran saya dalam situasi ini adalah untuk memperingatkan pelanggan dalam komunikasi tertulis dan menyimpan salinannya (email, perjanjian apa pun). Jika pelanggan bersikeras lalu lanjutkan dan lakukan (Ini kadang-kadang dikenal sebagai ketidaksepakatan dan komitmen). Pastikan saja bahwa jika ada hal buruk terjadi, Anda harus mampu membela diri.

Perbedaan utama adalah perizinan. Dokter dan insinyur sipil memegang lisensi profesional, dan membutuhkan mereka untuk melakukan pekerjaan mereka dan mencari nafkah, dan mereka juga memiliki tanggung jawab pribadi hukum untuk lebih banyak hal.

Hal ini dapat memberi tekanan lebih besar pada dokter dan insinyur, ketika didorong untuk melakukan sesuatu yang dapat menimbulkan risiko pribadi dan profesional, tetapi memberi mereka lebih banyak tekanan balik, karena mereka dapat berpendapat bahwa mereka tidak dapat melakukan sesuatu karena etika profesional, dan bahwa mereka akan kehilangan lisensi mereka jika mereka melakukannya. Ancaman untuk memecat seorang insinyur sipil karena menolak menandatangani rencana kehilangan kekuatan ketika konsekuensi dari penandatanganan adalah bahwa insinyur tersebut akan kehilangan lisensi, dan tetap tidak dapat bekerja di lapangan.

Ini terhubung dengan persyaratan hukum. Saya tidak dapat meresepkan banyak obat, dan jika saya melakukan hal-hal tertentu kepada seseorang yang secara hukum dapat dilakukan oleh dokter saya akan melakukan kejahatan. Demikian pula, sebagian besar pemerintah di sekitar sini tidak akan mengizinkan perusahaan untuk membangun jembatan tanpa insinyur sipil berlisensi yang menyetujui desain.

Sudah ada proposal untuk pemrogram lisensi, tapi tidak ada yang saya tahu pernah pergi ke mana pun. Mungkin perlu memiliki persyaratan hukum untuk memiliki programmer yang berlisensi untuk mengerjakan proyek terlebih dahulu, dan itu tidak akan terjadi dalam waktu dekat. Ada organisasi profesional dengan kode etik yang sebanding dengan kode medis atau teknik, tetapi tanpa kekuatan hukum, mereka lebih seperti panduan untuk kode etik pribadi.

Saya tidak memikirkan dimensi etis, tetapi hubungan yang tepat dengan basis pelanggan / pengguna bisa sangat bervariasi tergantung pada jenis pasar. Di tempat saya bekerja, kami memiliki produk yang sangat teknis, dan pengguna yang sangat teknis, dan pendapatan rata-rata per pelanggan cukup tinggi. Jadi batas bisnis kami agak kabur: kami memiliki pelanggan dan pengecer nilai tambah yang bertindak sebagai konsultan, yang membantu dalam checkout kode dan bahkan mungkin mengirimkan modul untuk dimasukkan ke dalam perangkat lunak. Jika kami menjual aplikasi pasar massal, model ini tidak masuk akal.