Fakta bahwa mereka menarik untuk dipecahkan tidak berarti bahwa seseorang membutuhkannya

"Sekelompok orang melakukan brainstorming pada laptop dan selembar kertas," foto oleh Stefan Stefanchik dari Unspalsh

Ada banyak faktor yang mengarah pada penciptaan perangkat lunak yang buruk: pilihan alat, komunikasi tim, ketidaktertarikan pribadi pengembang dalam kesuksesan, metodologi pengujian. Tampaknya bagi saya bahwa semua ini memiliki akar penyebab utama: ini adalah masalah imajiner.

Perangkat lunak yang terlalu rumit atau tidak berfungsi tidak dianggap seperti itu. Ini hanya dirancang untuk sesuatu yang lain, dan bukan untuk tugas nyata.

Misalkan Anda menerbitkan podcast dan Anda memerlukan situs tempat Anda dapat menjual produk terkait, menghasilkan uang dari iklan, dan yang paling penting, menerbitkan podcast, video, dan blog.

Persyaratan untuk aplikasi web kecil ini mungkin terlihat seperti ini:

• Unduh Cepat untuk Amerika Utara dengan Siaran Langsung Podcast
• Tidak ada kegagalan dalam 15 menit pertama untuk 99,99% pengguna, lebih baik jika tidak ada kegagalan sama sekali
• Integrasi yang baik dengan Google Adwords dan mungkin sistem iklan pihak ketiga lainnya jika Anda punya waktu
• Tautan dinamis ke produk terbaru di toko dan, jika mungkin, rekomendasi kepada pengguna berdasarkan halaman yang dilihat.
• Integrasi dengan pemain Facebook Live. Jika Anda dapat dengan mudah membuat solusi streaming alternatif tanpa Facebook, maka itu lebih baik

Anda memberikan spesifikasi ini kepada tim kontraktor dan berbicara sedikit dengan mereka. Segala sesuatu tampaknya berada pada gelombang yang sama. Tetapi ketika mereka menunjukkan prototipe dalam dua bulan, wajah Anda dipenuhi darah. Anda menghabiskan $ 15 ribu untuk sepotong sampah - dan ingin mendapatkan uang Anda kembali.

Ketika Anda pertama kali membuka aplikasi membeku. Anda bertanya bagaimana memilih jenis spanduk - dan itu menunjukkan Anda UI yang jelek dan tidak bisa dipahami. Setengah dari tautan ke barang-barang di toko rusak atau tidak ada gambar, dan siaran langsung via Facebook tertinggal!

Tetapi tim pengembang tidak memahami kemarahan Anda. Bahkan, dari sudut pandang mereka, mereka berhasil melakukan pekerjaan yang sangat sulit.

Mereka menempatkan jiwa mereka ke dalam penciptaan aplikasi, ia memiliki fitur luar biasa:

• Sistem rekomendasi paling canggih
• Algoritma dekripsi teks waktu-nyata untuk semua aliran audio
• Halaman depan memuat lebih cepat dari 200 ms di seluruh dunia
• Protokol streaming dan klien dibuat hampir dari awal kecuali Anda ingin mengandalkan Facebook Live
• Layanan telah dikembangkan yang memudahkan untuk mengintegrasikan lebih dari 20 pertukaran iklan

Masalahnya adalah Anda meminta produk dasar dengan beberapa fitur tambahan, asalkan cukup sederhana untuk diterapkan. Dan tim pengembang memahami secara berbeda. Mereka mendengar beberapa tugas menarik yang harus dilakukan ... dan banyak fitur-fitur dasar yang membosankan dan tidak banyak perhatian dan pengujian yang ketat.

Lebih buruk lagi, Anda tidak berkomunikasi langsung dengan pengembang - Anda berbicara melalui telepon yang rusak. Anda berbicara dengan seorang tenaga penjualan yang mengadakan pertemuan dengan beberapa manajer tingkat menengah. Mereka menulis beberapa spesifikasi bisnis untuk manajer proyek, yang menulis spesifikasi teknis - dan memberikannya kepada pemimpin tim atau arsitek, dan dia dan timnya mulai mengembangkan produk. Setiap tautan memperkenalkan distorsi sepanjang jalan.


Masalah imajiner seringkali lebih menarik untuk dipecahkan daripada yang nyata. Orang-orang dengan kecerdasan berlebihan memainkan permainan kompetitif, menemukan dan memecahkan masalah matematika, dan menulis buku untuk menjawab pertanyaan abstrak tentang sifat manusia - dan semua ini gratis, hanya untuk bersenang-senang. Tetapi seorang programmer yang biasa-biasa saja mungkin akan membebani Anda biaya yang lumayan untuk membuat aplikasi Android sederhana. Ini bukan karena programmer biasa-biasa saja lebih sulit ditemukan daripada genius, tetapi karena kegiatan pertama menarik, dan yang terakhir cukup membosankan.

Sebagian besar programmer ingin mendapat bayaran dan bersenang-senang pada saat yang bersamaan. Tentu saja, definisi "menarik" berbeda untuk semua orang, tetapi bagi banyak insinyur, itu berakhir dengan memecahkan masalah yang menarik dan kompleks yang ada di bidang solvabilitas.

Berikan orang cerdas terlalu banyak tugas membosankan yang tidak dapat diotomatisasi, dan Anda akan membuatnya gila. Namun, otak manusia, setelah miliaran tahun evolusi, telah menjadi sangat inventif dalam mempertahankan akal. Sama seperti korban perampasan atau pelecehan anak menemukan keselamatan dalam buku-buku fiksi ilmiah, para korban program perusahaan dan pekerja lepas mencari keselamatan dalam memecahkan masalah imajiner.



Jumlah masalah imajiner yang dapat dibuat oleh seorang insinyur perangkat lunak untuk dirinya sendiri tergantung pada imajinasinya dan kompleksitas masalah nyata yang perlu dipecahkan.

Perlu dicatat bahwa masalah ini tidak unik untuk pengembang. Manajemen, penjualan, SDM, dukungan, hukum dan bahkan departemen akuntansi - semua memiliki cara unik mereka sendiri untuk menciptakan masalah imajiner. Beberapa orang mencoba masuk ke dalam proses pengambilan keputusan ketika kehadiran mereka di pertemuan itu hanya formalitas atau tidak diperlukan sama sekali. Yang lain terlalu melebih-lebihkan masalah kecil yang terkait dengan peran mereka, atau mempekerjakan jauh lebih banyak karyawan daripada yang diperlukan untuk menunjukkan pentingnya mereka.

Ketika masalah terlalu bodoh, orang pintar akan menemukan cara untuk memperbaiki situasi.


Tetapi masalah imajiner datang tidak hanya dari pengembang yang bosan. Mereka juga hasil dari rantai komunikasi yang panjang.

Ketika saya baru saja mulai mencari klien sebagai pekerja lepas, saya tidak mampu membangun komunikasi berdasarkan kebijaksanaan saya. Jadi saya harus berurusan dengan utas surat panjang dengan ratusan surat, di mana detail kecil MVP internal dibahas. Orang-orang selama seminggu mengubah setiap persyaratan dalam proyek. Saya punya klien yang mengajukan pertanyaan seperti itu: "Apakah akan kompatibel dengan ICO?" atau "Bisakah saya menambahkan AI di sini?"

Tentu saja, sebagian besar klien memiliki pengalaman yang cukup, tetapi bahkan mereka sering tidak memiliki pengetahuan untuk merumuskan atau membangun beberapa persyaratan. Ini normal, karena bagian dari pekerjaan saya sebagai "teknisi komputer" adalah untuk membantu orang memahami apa yang mereka lakukan dan apa yang tidak mereka butuhkan, berdasarkan situasi spesifik mereka. Tetapi jauh lebih sulit untuk menentukan kapan ada beberapa gasket antara Anda dan klien.

Persyaratan berubah karena seseorang salah memahami niat, atau mencoba mengatasi kebosanan yang disebutkan di atas

Sebagian besar perusahaan suka memulai seorang tenaga penjualan yang mengganggu pelanggan potensial, berdagang, dan umumnya menggambarkan produk. Ada juga spesialis dengan keterampilan komunikasi canggih untuk berdiskusi dengan klien dengan spesifikasi dan persyaratan yang lebih terperinci: ini biasanya adalah tenaga penjualan yang sama, hanya sedikit dengan jabatan yang berbeda. Dan ada sistem perusahaan internal, berbagai tingkat manajemen dan, mungkin, beberapa hierarki dalam tim teknis.

Ketika daftar persyaratan klien melewati begitu banyak orang, bahkan jika orang-orang ini memiliki niat terbaik, sesuatu pasti hilang dalam proses tersebut. Terkadang ini terjadi karena persyaratan asli tidak masuk akal atau perlu diubah. Mungkin penjual berkata kepada klien: "Hanya 39.999, kita akan melakukannya di blockchain dari atas." Dia setuju, tetapi semua orang harus menebak apa artinya melakukan di blockchain.

Paling sering, persyaratan berubah baik karena seseorang salah memahami niat, atau mencoba untuk mengatasi kebosanan yang disebutkan di atas, mencoba membuat pekerjaan mereka atau pekerjaan tim mereka lebih menarik dan mengesankan.

Di balik semua ini, persyaratan awal hilang - masalah nyata yang perlu diselesaikan. Mereka digantikan oleh masalah imajiner dan kekosongan, dan Anda memiliki banyak orang yang siap dan bersedia mengisi kekosongan ini dengan masalah imajiner mereka, karena masalah nyata yang perlu mereka selesaikan membosankan, dan mengisi kekosongan memberi mereka kepuasan.

Kompleksitas yang berlebihan dan seleksi alam

Seringkali ada alasan yang lebih gelap untuk munculnya masalah imajiner: masalah seperti itu membantu tim atau perusahaan untuk tumbuh, mereka bahkan dapat menjadi bagian integral dari pekerjaannya.

"Orang-orang yang dibawa keluar, dipilih, dan didorong untuk mencari solusi yang kompleks tidak memiliki insentif untuk memperkenalkan yang disederhanakan."
- Nassim Nicholas Taleb

Pernahkah Anda mendengar tentang ketiga pemrogram yang telah menemukan solusi yang benar-benar sederhana untuk web banking yang aman? Mereka mengembangkan perangkat lunak perbankan tanpa cacat dari awal menggunakan metodologi desain fungsional dan bahasa yang aman, dan kemudian mulai mentransfer bank-bank besar ke infrastruktur luar biasa mereka.

Anda mungkin belum pernah mendengarnya, karena mereka tidak ada. Tetapi ada banyak tim dari ribuan pengembang yang tidak dapat mempelajari konsep sederhana, seperti "kembalikan ke versi lama" , dan mereka terus-menerus sibuk membuat perangkat lunak perbankan.

Menyimpan dan mengirimkan nomor bukan masalah yang sulit. Mengindeks seluruh isi Internet dan menampilkan hasil yang sesuai untuk kueri dalam bahasa alami dalam sepersekian detik adalah masalah lain. Tetapi hanya beberapa orang pintar yang berhasil menyelesaikan masalah ini.

Masalah kronis dari perbankan online adalah bahwa ekosistem perbankan telah benar-benar unggul dalam hierarki apropriasi uangnya sendiri. Para pemimpinnya adalah lintah korup yang menempel pada tubuh masyarakat, tetapi pemimpin organisasi hanya mencerminkan keadaan seluruh sistem.

Saya tidak mengatakan bahwa sebagian besar karyawan bank biasa adalah tokoh yang jahat dan berbahaya. Tidak semuanya. Biasanya, mereka adalah orang-orang ramah yang menghasilkan uang untuk makanan, perumahan, dan pendidikan untuk keluarga mereka. Tetapi insentif utama mereka bukan untuk memperbaiki perangkat lunak perbankan, tetapi untuk menyelamatkan pekerjaan. Kehilangan pekerjaan di ekonomi modern adalah masalah serius bagi sebagian orang, dan di industri perbankan kata ceroboh atau inisiatif berlebihan adalah cara mudah untuk tampil di hadapan komite disiplin.

Dengan demikian, sistem perbankan tetap sama - bukan karena mereka efektif, tetapi karena inersia. Kelambanan ini dimanifestasikan dalam bentuk penyelesaian masalah imajiner untuk menghindari penyelesaian masalah nyata - solusinya, seperti yang telah dicatat, mengancam pekerjaan orang lain. Menyelesaikan masalah-masalah nyata ini dapat mengakibatkan pemecatan atau, dalam kasus beberapa "institusi" yang tidak menyenangkan seperti Goldman Sachs, ke beberapa surat yang menghancurkan kehidupan mantan karyawan dan berakhir dengan bunuh diri yang aneh .

"Sulit untuk membuat seseorang memahami sesuatu jika gajinya tergantung pada apa yang tidak dia mengerti!"
- Upton Sinclair

Perusahaan biasa mengabaikan fakta bahwa manajemen puncak menghabiskan 90% waktunya untuk "bertemu dengan klien," termasuk perjalanan ke pulau-pulau tropis dan jutaan anggaran untuk "overhead". Pada gilirannya, manajemen puncak menutup mata terhadap korupsi di jajaran.

Ketika manajer tingkat menengah mendorong fantasi Wall Street gaya serigala mereka, manajemen senior menutup mata terhadap perilaku manajer yang membeli kantor eksentrik, mempekerjakan tiga sekretaris dan selusin magang.

Karena manajer biasa tidak mengeluh tentang fantasi diktatorial mereka dan kehausan akan kekuasaan, manajer tingkat menengah menutup mata terhadap fakta bahwa alih-alih memotong biaya, mereka menghabiskan waktu pada presentasi PowerPoint "Meningkatkan metodologi Agile agile agile kami."

Karena pemimpin tim tidak memperhatikan bahwa atasan mereka bahkan tidak tahu cara menggunakan Excel dan pergi ke kantor beberapa kali seminggu, manajer biasa menutup mata ketika pemimpin tim dan arsitek berbicara tentang "generasi berikutnya interaksi antara sistem kami melalui JRPC dan layanan mikro menggunakan Hibernate dan Spring ”ketika query MySQL sialan ini dieksekusi selama lebih dari satu hari.

Karena pengembang tampaknya tidak memperhatikan bahwa pimpinan tim mereka tidak menulis kode apa pun selain diagram, pemimpin tim tidak mengeluh tentang pengembang mereka, yang, bukannya MENJELAJAHI rem dari permintaan di atas, membuat ulang UI untuk kesepuluh kalinya dalam setahun menggunakan kerangka kerja JavaScript baru.

Ini adalah lingkaran setan untuk menyelesaikan masalah imajiner: dari CEO yang tidak mengerti bahwa mencuri 30 juta lagi tidak akan memberinya cinta orangtua, kepada peserta pelatihan yang tidak mengerti bahwa tombol "Kirim" yang baru pada Angular-Material-Bootstrap 19.13.5 tidak akan berubah kata sandi disimpan dalam teks biasa (dan digunakan untuk memeriksa cookie).

Tetapi setiap orang harus terus menyelesaikan masalah imajiner, karena jika mereka berhenti melakukan ini, mereka akan mulai fokus pada masalah nyata - dan mereka akan mengerti bahwa seluruh sistem rusak. Mereka dapat memahami bahwa di sudut kantor, Debra telah melihat grafik uptime cluster server selama sepuluh tahun, meskipun lima tahun yang lalu perusahaan pindah ke AWS. Mereka dapat memahami bahwa 99% tugas mereka hanya diperlukan untuk menyelamatkan pekerjaan orang lain. Dan kesadaran ini sulit diterima, saya berani katakan, bahkan tidak mungkin bagi mayoritas. Oleh karena itu, sebagian besar menemukan cara untuk beradaptasi.