Bisnis berusaha membuat keputusan teknis

Kami telah sering menemukan skenario di mana bisnis akan menjanjikan fitur baru kepada klien. Bisnis akan berjanji bahwa fitur tersebut diimplementasikan dengan cara tertentu. Rincian teknis yang dijanjikan oleh bisnis ini biasanya buruk. Sayangnya, klien sekarang diatur dan ingin fitur ini diimplementasikan dengan cara yang dijelaskan oleh bisnis.

Pada akhirnya, bisnis hanya ingin fitur ini selesai tanpa memperhatikan kualitas dan pemeliharaan. Apakah ada cara yang baik untuk mendorong kembali? Bagaimana kita bisa menjelaskan kepada bisnis bahwa memberikan rincian teknis sebelum persyaratan telah dikumpulkan adalah ide yang buruk?

Itu masalah organisasi. Jika atasan tidak mengerti ini, tidak banyak yang bisa Anda lakukan. Cobalah untuk menjelaskan masalah ini kepada bos non-teknis Anda, tetapi jangan kaget ketika Anda tidak sampai ke mana pun.

Ini adalah masalah umum bagi pengembang yang bekerja di perusahaan non-pengembangan yang, dengan alasan apa pun, menjual perangkat lunak.

Ini bukan taktik yang menyenangkan, tetapi Anda bisa memukul mereka dengan bukti. Pada awal proyek, catat persis mengapa itu akan gagal (karena detail teknis buruk) dan kirim email ke orang yang relevan. Terus kirim email kepada mereka, dan ketika proyek akhirnya berakhir dengan pelanggan yang kesal, sebutkan email yang Anda kirim di setiap kesempatan. Ini mungkin menghasilkan beberapa niat buruk, tetapi benar-benar tidak ada cara yang baik untuk mencoba memperbaiki masalah sistemik seperti itu.

Dari perspektif pengembang, ini adalah salah satu dari dua rasa gagal, dalam hal penulisan spec. Hal lain yang bisa terjadi adalah ketika penjualan membuat janji-janji besar, dan kemudian beralih ke IT untuk menentukan proyek dan mengirimkan penulisan yang dapat diubah menjadi kutipan.

Masalahnya adalah, seringkali itulah yang paling banyak dilakukan. Sangat mungkin kode aktual hanya mengimplementasikan rincian pendekatan yang ditetapkan dalam spesifikasi yang dirancang dengan baik.

Pada saat yang sama, penjualan sulit untuk menagih untuk pendahuluan seperti pengembangan spesifikasi. Kami belum cukup di tempat tidur dengan klien, dan aneh untuk memukul mereka untuk uang untuk mencari tahu berapa banyak uang untuk memukul mereka.

Inilah sebabnya mengapa sebagian besar proyek "pertama kali" dengan klien baru akhirnya menjadi pemimpin kerugian. Jika Anda BERUNTUNG, Anda menggunakan proyek pertama itu untuk melatih klien tentang cara menjadi klien, dan Anda dapat mulai mendapatkan kembali pantat Anda pada proyek kedua, atau perjanjian pemeliharaan pada yang pertama.