Ada banyak keadaan yang dapat menjadi katalis untuk membuat perangkat lunak yang buruk: alat yang digunakan, kualitas komunikasi dalam tim, kualitas pribadi pengembang, metodologi, dll. Dan ada satu hal di antara mereka yang merupakan akar dari hampir semua orang: masalah imajiner.
Sebagian besar perangkat lunak yang kompleks atau zagabovannoy tidak direncanakan untuk menjadi kompleks dan, terlebih lagi, zagabovannoy. Itu hanya dibuat untuk melaksanakan tugas-tugas yang tidak terletak pada dasar rencana asli.
Cerita Podcast
Bayangkan Anda merekam podcast populer dan pada titik tertentu Anda berpikir untuk membuat situs Anda sendiri - yah, Anda tahu, dengan informasi tentang podcast Anda, catatan masalah sebelumnya, artikel, dan mungkin beberapa iklan. Bahkan, berapa banyak yang bisa Anda bagikan laba dengan beberapa penerbit luar?
Jadi Anda memutuskan untuk mempekerjakan orang yang akan membuat situs ini untuk Anda. Anda menulis persyaratan yang sangat jelas bagi mereka:
- Pemuatan situs cepat di Amerika Utara
- Dukungan untuk mengunduh rilis podcast sebelumnya dan streaming langsung saat ini
- Siaran tidak boleh jatuh atau macet selama 15 menit pertama untuk 99,99% pengguna. Tidak pernah diinginkan, namun demikian.
- Integrasi dengan Google Adwords (dan di masa depan, mungkin dengan analog)
- Integrasi dengan siaran Facebook, karena di sana Anda menghabiskan siaran Anda. Jika Anda dapat membuat solusi alternatif yang memungkinkan Anda melakukan streaming dengan lebih mudah - bahkan lebih baik.
Anda memberikan persyaratan ini kepada pengembang dan, mungkin, berkomunikasi sedikit dengan mereka. 2 bulan berlalu. Mereka menunjukkan Anda demo dan Anda tercakup dalam bintik-bintik merah. Menjadi jelas bahwa Anda baru saja melemparkan $ 15.000 ke dalam jurang. Apa yang mereka tunjukkan kepada Anda benar-benar tidak dapat diterima di sisi mana pun, hanya setumpuk sampah. Anda ingin uang Anda kembali, tetapi kereta sudah pergi.
Marah saat melihat situs yang ditunjukkan sangat sederhana. Pada pembukaan pertama, semuanya membeku. Kemudian sepertinya berhasil dan Anda bertanya bagaimana mengubah jenis iklan yang akan ditampilkan di situs. Mereka menunjukkan Anda antarmuka twist-and-bike untuk ini, yang tidak realistis untuk dikuasai sendiri. Aliran Facebook lambat. Semuanya mengerikan.
Namun tim pengembang tidak mengerti mengapa Anda kesal. Dari sudut pandang mereka, mereka mencapai prestasi, setelah membuat produk yang sedemikian kompleks hanya dalam 2 bulan. Mereka menempatkan semua bakat mereka ke dalam dirinya, seluruh jiwa mereka. Nilailah sendiri fitur luar biasa yang mereka tambahkan ke dalamnya:
- Sistem rekomendasi luar biasa
- Algoritma pengenalan ucapan yang menampilkan terjemahan di bawah siaran Anda DALAM WAKTU NYATA !!!
- Halaman utama situs dimuat dalam 200 ms di mana saja di dunia
- Protokol siaran dan klien ditulis dari awal, dan Facebook telah ditambahkan oleh sebuah plugin. Anda dapat menambahkan plugin untuk platform lain kapan saja!
- Dimungkinkan untuk berintegrasi dengan 20 platform iklan yang berbeda
Anda sudah melihat apa masalahnya, bukan? Anda meminta produk yang sangat spesifik dan sangat terspesialisasi dengan beberapa fitur tambahan yang Anda butuhkan. Tim pengembang mendengarnya secara berbeda. Bagi mereka, semua "diinginkan", "lebih nyaman" dan "di masa depan" berubah menjadi tugas yang menarik untuk mengembangkan produk yang sangat umum, dapat diperluas, dapat diskalakan dan ditambah dengan proporsi yang sangat besar, selama implementasi yang Anda bisa dengan heroik menyelesaikan banyak masalah menarik. Ya, dan, tentu saja, tidak ada yang terganggu oleh hal-hal sepele seperti pemolesan dan membawa ke fungsionalitas dasar produk yang ideal - kami memiliki skala apa, tidak ada waktu untuk menukarnya sekarang!
Masalah lain adalah Anda kemungkinan besar tidak berkomunikasi langsung dengan pengembang langsung sistem. Anda memainkan telepon manja: Anda berbicara dengan beberapa penjual yang menyerahkan tugas kepada seseorang dari manajemen menengah di perusahaannya, menulis spesifikasi bisnis di sana, memberikannya kepada manajer proyek, ia menulis spesifikasi teknis dan memberikannya kepada pemimpin tim, yang membaginya menjadi tugas-tugas dan dibagikan kepada pengembang. Nah, masing-masing pengembang juga memahami dan merealisasikan tugas mereka dalam konteks pemahaman mereka.
Mekanisme penghindaran realitas
Masalah imajiner lebih menarik untuk dipecahkan daripada yang nyata. Orang yang sangat pintar memainkan permainan yang rumit, menyelesaikan masalah matematika, menulis buku tentang topik abstrak - gratis atau hampir gratis. Pada saat yang sama, programmer kelas menengah untuk aplikasi seluler yang cukup standar akan memberi Anda tagihan yang sangat besar. Ini bukan karena programmer rata-rata lebih sulit ditemukan daripada seorang jenius. Ini karena mudah dan menyenangkan untuk melakukan tugas-tugas menarik, tetapi tidak rutin.
Sebagian besar programmer ingin mengerjakan tugas yang menarik, dan mendapatkan uang yang bagus untuk itu. Ini sulit dicapai. Tentu saja, Anda dapat berspekulasi tentang apa "masalah menarik" itu, tetapi bagi sebagian besar pengembang itu adalah sesuatu yang sangat dekat dengan perbatasan bidang masalah yang secara teoritis dapat dipecahkan. Sesuatu yang sulit dicapai, tetapi mungkin.
Berikan orang rasional banyak tugas rutin, non-otomatis, dan cepat atau lambat Anda akan membawanya ke pegangan. Namun, otak manusia, setelah jutaan tahun evolusi, telah mengembangkan beberapa trik berbeda untuk mempertahankan dirinya dalam keadaan yang memadai. Karena para korban kekerasan dapat melarikan diri ke dunia fantasi mereka, maka dengan tak berdosa ditakdirkan untuk bertahun-tahun pengembangan usaha atau lepas web dari waktu ke waktu menemukan keselamatan dalam menyelesaikan masalah imajiner.
Jumlah dan kompleksitas masalah yang ditemukan adalah fungsi dari tingkat imajinasi programmer dan kompleksitas tugasnya yang sebenarnya. Perlu dicatat bahwa pendekatan ini sendiri tidak unik untuk pengembang perangkat lunak. Manajer, tenaga penjualan, SDM, dukungan, pengacara, dan akuntan menemukan cara unik mereka sendiri untuk menciptakan dan secara heroik mengatasi masalah yang tidak ada. Mereka melibatkan diri mereka dalam keputusan yang berada di luar kompetensi mereka, berbicara pada pertemuan di mana kehadiran mereka adalah formalitas murni, dan sebagainya. Mereka juga melebih-lebihkan skala masalah dan peran mereka dalam menyelesaikannya ("Aplikasi Doggy Diary kami yang baru seharusnya kompatibel dengan GDPR sejak hari pertama! Kami tidak sabar menunggu klien untuk mengeluh!"). Mereka mengembang staf untuk menciptakan penampilan pentingnya pekerjaan tim mereka, dan kemudian menangani masalah pertumbuhan, penskalaan dan logistik (dan akan selalu ada masalah seperti itu di tim besar).
Banyak pengembang yang cerdas, tetapi banyak dari tugas mereka sangat bodoh. Kontradiksi ini memaksa orang pintar untuk memikirkan orang lain, meskipun tidak ada dalam kenyataan, tetapi tugas yang menarik.
Arsitektur Telepon Manja
Terkadang masalah imajiner bukanlah hasil fantasi pengembang yang bosan. Terkadang ini adalah hasil dari "telepon rusak."
Kadang-kadang saya bekerja lepas. Ketika saya baru mulai, saya tidak mampu memilah pelanggan. Ini berarti perlunya membawa setiap orang secara berurutan dan mengamati dalam semua warna manifestasi penyimpangan jiwa manusia yang paling beragam. Saya telah melihat rantai ratusan surat tentang masalah rincian prototipe yang sama sekali tidak material. Saya melihat orang-orang berubah total setiap paragraf dari spesifikasi setiap minggu. Saya punya klien yang untuk proyek-proyek dari beberapa situs sepele bertanya tentang kesempatan untuk segera pergi bersama mereka ke ICO atau untuk mengikat kecerdasan buatan kepada mereka.
Ada klien yang cukup masuk akal, namun, tidak memiliki pengetahuan (atau kosa kata?) Untuk mengungkapkan semua persyaratan mereka dalam formulasi yang dapat dimengerti. Ini sendiri bukan masalah. Bagian dari pekerjaan pengembang perangkat lunak adalah tepatnya pengumpulan persyaratan dan penulisan spesifikasi. Inilah yang kita bayar, termasuk uang, dan pekerjaan ini bahkan dapat dilakukan lebih atau kurang secara normal jika Anda memiliki akses normal ke klien dan waktu yang cukup. Masalahnya adalah bahwa kadang-kadang akses ini tidak dan ada beberapa perantara di antara Anda.
Sebagian besar perusahaan suka memiliki "tenaga penjualan" di pos terpisah. Mereka adalah orang-orang istimewa yang mencari pelanggan potensial, mendiskusikan tugas, tenggat waktu, dan harga dengan mereka. Orang-orang inilah yang dapat mencari tahu yang paling berguna dan mengajukan sebagian besar pertanyaan. Tetapi ini bukan orang-orang yang akan menulis proyek ini. Antara tenaga penjualan dan programmer ada 2, 3, 4 atau lebih lapisan manajer tingkat menengah dan bawah, arsitek, analis dan pemimpin tim. Ya, itu bisa menjadi orang yang sangat terampil. Tapi tetap saja - ini adalah lapisan tambahan. Tidak peduli seberapa keras mereka berusaha, informasi yang melewati mereka akan berubah. Seseorang akan membuang sesuatu (menurutnya) yang tidak penting, yang lain akan mengklarifikasi sesuatu yang tidak ditentukan, tetapi (menurutnya) jelas, yang ketiga akan mengganti kata-kata bodoh dengan istilah yang benar (seperti yang dia yakin) - dan sekarang tugas awal tidak lagi dapat dikenali. Seorang tenaga penjualan dapat melemparkan frasa ke pelanggan seperti "tetapi untuk 39.999 kita dapat melakukannya di blockchain juga". Jika klien menggigit, tim pengembang harus memutar otak mereka pada dua level di bawah, tetapi bagaimana hal ini dapat dilakukan pada blockchain. Tapi itu sudah dijual dan dibayar, kami akan melakukannya.
Dengan demikian, masalah awal hilang dalam spekulasi dan pemikiran ulang. Kesenjangan lubang antara masalah-masalah baru yang ditemukan (jika mereka bahkan tidak menganga di sana) dan ada orang yang ingin mengisinya dengan masalah imajiner mereka sendiri dan solusi cemerlang mereka. Karena masih kebebasan, bukan rutin.
Kompleksitas buatan dan seleksi alam
Seringkali ada sisi yang lebih gelap. Menemukan masalah imajiner dan metode untuk menyelesaikannya dapat menjadi pendorong pertumbuhan perusahaan, dan di masa depan, mungkin bisnis utamanya, bagian terpenting dari keberadaannya, yang tidak dapat ditinggalkan.
"Orang-orang yang dipilih untuk memecahkan masalah yang rumit tidak memiliki insentif untuk memecahkan masalah yang sederhana" - Taleb
Pernahkah Anda mendengar tentang tiga insinyur teratas yang tiba-tiba menemukan bahwa perbankan online, pada umumnya, adalah hal yang sangat sederhana? Mereka menciptakan perangkat lunak sederhana dan karenanya bebas masalah, menggunakan teknik dan bahasa pemrograman yang benar, dan kemudian mentransfer semua bank utama ke platform mereka.
Tidak, tidak dengar? Ini karena ini bukan. Tetapi apa yang terjadi, adalah dan akan - tim yang terpisah dari ribuan programmer yang bekerja untuk bank yang berbeda dan untuk beberapa setengah tahun mampu menggunakan seluruh tim untuk mengimplementasikan fitur seperti "transaksi rollback". Begitulah cara perangkat lunak perbankan ditulis, ya.
Dan ini, tentu saja, bukan karena memindahkan angka dari satu kolom ke kolom lainnya sangat sulit, tidak. Itu tidak sulit. Di sini, indeks seluruh Internet, lalu tampilkan hasil pencarian yang relevan dalam sepersekian detik - ini sulit. Namun, beberapa orang di garasi melakukannya. Dan untuk kemunduran transaksi, 1000 orang dan enam bulan diperlukan.
Masalahnya di sini adalah bahwa ekosistem perbankan sangat baik dalam tugas utamanya - mendukung ekosistem perbankan. Roda berputar, kertas-kertas berdesir dan besok semuanya akan sama seperti kemarin. Semuanya memiliki kelembaman. Dan, jika kita telah mengerjakan masalah imajiner selama 5 tahun terakhir, kita akan mengerjakannya besok juga.
“Sulit membuat seseorang memahami sesuatu jika dia mendapat gajinya karena tidak memahaminya.” - Upton Sinclair
Dan semua orang terus mengerjakan tugas-tugas fiktif, karena jika mereka berhenti sejenak dan melihat yang asli, akan menjadi jelas bahwa seluruh sistem mereka rusak. Tiba-tiba, mungkin ternyata Vasya, yang duduk di sudut itu, telah memantau status farm server internal selama 10 tahun terakhir, migrasi dari mana ke AWS berhasil terjadi 5 tahun yang lalu. Tiba-tiba ternyata semua pekerjaan Masha adalah mengirim laporan Dasha kepada seseorang. Kesadaran seperti itu sangat sulit dan orang-orang secara tidak sadar mencoba menghindari situasi di mana mereka dapat dibuat secara tidak sengaja.
Dan kami terus memecahkan masalah imajiner.