Anda harus memilih perangkat lunak mana yang Anda butuhkan: ditulis tepat waktu atau berkualitas tinggi

Saya harap saya bisa menarik perhatian Anda dengan tajuk yang provokatif (dan, memang, berlebihan). Bagus Sekarang izinkan saya memformulasikannya kembali dengan cara yang sedikit lebih elegan dan tidak terlalu menggoda :

Pada prinsipnya, perangkat lunak dapat ditulis tepat waktu atau dengan baik, tetapi tidak keduanya sekaligus *

* kecuali dalam beberapa kasus di tim berkinerja tinggi yang ada

Selama beberapa bulan sekarang saya telah memikirkan mengapa pembuatan perangkat lunak berkualitas tinggi tidak sesuai dengan perkiraan tanggal dan perencanaan secara umum. Selama karir saya, saya melihat proyek dibangun pada berbagai model (kaskade, benar-benar fleksibel, kaskade fleksibel), dan mereka semua memiliki satu kesamaan: tidak peduli proyek apa yang sedang kami kerjakan jika dilakukan “ berdasarkan sains” ( yaitu, kami tidak membiarkan diri kami trik kotor, karena itu nanti kami akan mengalami mimpi buruk), maka kami selalu melanggar tenggat waktu.

Di sisi lain, setiap kali proyek dikirim "tepat waktu", ini berarti bahwa sepanjang jalan itu pasti harus mengurangi volumenya, atau memotong begitu banyak sudut sehingga selama pelaksanaan gunung akumulasi utang teknis, hampir menjamin bahwa proyek harus ditulis ulang tak lama setelah meluncurkan. Oleh karena itu, saya mulai bertanya-tanya: dapatkah kita benar-benar berasumsi bahwa proyek itu dikirim “tepat waktu” jika sebagai hasilnya kita memiliki dukungan yang jelek, tidak nyaman, diisi dengan bug dan, terus terang, versi kode yang lebih jelek dibandingkan dengan apa yang kita awalnya coba lakukan?

Diterjemahkan ke Alconost

Saya memiliki kesempatan untuk mengerjakan proyek tanpa tenggat waktu yang sulit. Ya, secara resmi "tenggat waktu" ada di sana, tetapi jauh dari beton bertulang. Semua orang mengerti bahwa tenggat waktu kami fleksibel, dan kualitas lebih penting daripada pengiriman produk tepat waktu. Pada proyek-proyek inilah kami mendapatkan perangkat lunak terbaik, ada pengembang yang paling puas, dan, secara umum, proyek-proyek ini adalah yang paling sukses di antara semua yang harus saya kerjakan. Tetapi kita semua tahu bahwa proyek seperti itu sangat langka, kalau tidak saya tidak akan menulis semua ini.

Jadi, mengapa begitu sulit untuk merencanakan pekerjaan dan memberikan perangkat lunak yang bagus, memiliki tenggat waktu yang sulit? Saya pikir ini sebagian besar disebabkan oleh kreativitas , keterampilan , dan ketidakpastian .

Sisi kreatif pemrograman

Saya berpendapat bahwa pengembangan perangkat lunak, menurut definisi, adalah kegiatan kreatif . Tentu saja, ada pengembang yang melakukan tugas sepele yang sama, tetapi mereka hanya memiliki pekerjaan sampai seseorang telah menemukan cara untuk mengotomatisasi pekerjaan mereka. Anda tidak akan iri pada mereka, dan topik artikel ini sama sekali berbeda.

Bagi saya, ada sesuatu yang istimewa dalam tindakan menciptakan sesuatu yang baru dan dalam mencari solusi asli dalam menanggapi tantangan; itu sebabnya saya merasa terpanggil untuk pengembangan perangkat lunak, dan saya tidak berpikir bahwa saya adalah satu-satunya. Bahkan, saya pikir kreativitas adalah alasan utama mengapa pengembang menikmati pekerjaan mereka. Pengalaman saya menunjukkan bahwa setiap kali saya bekerja dalam kondisi di mana "serangkaian praktik" yang ketat dan tidak berubah (apakah itu tumpukan teknologi, proses, regulasi, dll.) Diamati, maka ada lebih sedikit ruang untuk kreativitas Saya - semakin saya tidak tertarik dengan pekerjaan seperti itu. "Pada akhirnya, jika mereka sudah memutuskan segalanya untuk diri mereka sendiri, lalu mengapa mereka membutuhkanku?" - Saya pikir. Di sisi lain, saya jauh lebih dipenuhi, terinspirasi oleh pekerjaan seperti itu (di mana saya juga yang paling produktif), di mana ada arahan yang relatif sedikit dari atas, ada ruang untuk kreativitas, dan saya dipercaya untuk membuat keputusan teknis sendiri.

Penting untuk dicatat bahwa kebebasan kreatif tambahan mengarah pada fakta bahwa dalam perjalanan untuk mencapai solusi pasti akan ada lebih banyak trial and error - dan ini normal. Tampaknya beberapa orang dapat dengan mudah mengetahui solusi sempurna apriori (sebelumnya) tanpa menulis satu baris kode pun. Sebaliknya, saya bersikeras bahwa dalam proses kreatif, jalan untuk menemukan solusi untuk suatu tugas (ini tidak hanya berlaku untuk perangkat lunak) memerlukan bermain-main dengan : tidak mungkin untuk mengetahui semuanya terlebih dahulu dengan pasti; sebaliknya, Anda belajar dalam praktik, secara bertahap memilah-milah pilihan baru dan berpegang teguh pada yang bekerja, mengasah keputusan Anda (dan, mungkin, secara bertahap menyerahkannya kepada pelanggan jika Anda bekerja sesuai dengan metodologi "fleksibel") sampai Anda puas dengan itu.



Coba pikirkan berapa kali yang dibutuhkan untuk mendesain komponen di atas kertas dengan susah payah - hanya pada saat itu, untuk benar-benar mengulangi desain, itu hanya layak untuk memulai implementasi. Akan selalu ada yang tidak diketahui yang tidak dikenal dalam bisnis ini , dan Anda dapat mengidentifikasi mereka dan mengatasinya hanya dengan posteriori (pada kenyataannya), memprogram solusi Anda, dan tidak menghabiskan banyak waktu untuk berteori dan tidak berpura-pura bahwa kita dapat memiliki informasi yang sempurna sebelumnya. Improvisasi seperti itu tidak cocok dengan perkiraan tanggal.

Selain itu, seperti halnya dengan kegiatan kreatif lainnya, akan berguna untuk mempraktikkan penundaan strategis saat pemrograman - istilah ini pertama kali diusulkan oleh Adam Grant, yang mengklaim bahwa ia sering gagal menciptakan sesuai permintaan, tetapi, sebaliknya, kreativitas muncul sebagai "pemberitahuan push " dari sebuah proses yang berjalan di latar belakang di kepala Anda:

“Karyawan yang suka menunda-nunda biasanya menghabiskan lebih banyak waktu untuk pemikiran yang berbeda, dan kurator lebih sering menilai mereka lebih kreatif daripada rekan kerja. Penundaan tidak selalu memicu kreativitas: jika seorang karyawan tidak memiliki motivasi percaya diri untuk menyelesaikan masalah besar, maka karena tergelincir itu hanya tertinggal. Namun, jika seseorang cukup bergairah tentang bisnis dan memberikan ide-ide baru, kemudian menunda tugas, ia datang ke solusi yang lebih kreatif . "
- Grant, Adam. "Asli: Bagaimana Non-Konformis Memindahkan Dunia"

Sekali lagi, ini tidak akan menyenangkan para advokat perencanaan pusat yang ingin meramalkan dan mengukur setiap menit dalam proyek pengembangan perangkat lunak.


Bimasakti , Mars, dan meteor

Keterampilan Pemrograman

Pengembang terbaik yang saya tahu adalah pengrajin yang terampil. Penguasaan adalah fitur khas dari perangkat lunak yang baik: Anda membuat sesuatu yang berfungsi, dan Anda membuatnya dengan cara terbaik - relatif mudah untuk membuat sesuatu berfungsi, tetapi sangat sulit untuk melakukan sesuatu yang tidak hanya akan berfungsi, tetapi juga tahan uji waktu.

Karena Anda adalah seorang master, kualitas pekerjaan Anda berbicara tentang Anda . Bagi Anda, kualitas lebih penting daripada kuantitas, karena Anda tidak ingin diakui sebagai penulis govnokod, bahkan jika Anda dapat memuaskan manajer produk dengan memberikan program Anda kilau eksternal, dan mengisinya dengan banyak kejutan yang keji - Saya menyebut pendekatan ini Kindersurprise Development . Anda tahu bahwa mencurahkan cukup waktu untuk sebuah kasus dan menulis program yang baik adalah benar, jadi tahan tekanan "lakukan lebih cepat", karena Anda tahu bahwa semakin banyak tongkat yang Anda atur sekarang, semakin pendek kodenya, dan semakin banyak masalah yang akan menyertainya bisnis.


Mata berdarah

Pengerjaan berkaitan dengan perawatan : kami peduli melakukan pekerjaan yang sangat baik, tentang mereka yang harus menjaga kode kami setelah kami, tentang pelanggan kami yang seharusnya mudah digunakan dengan program kami, tentang rekan tim, dll. Anda melakukan ini karena Anda bukan orang brengsek dan karena Anda tahu bahwa inilah yang harus Anda lakukan jika Anda peduli dengan keberhasilan proyek.

Singkatnya, seorang insinyur yang baik memiliki tugas yang sulit: menjaga kualitas - yang akan dirasakan dalam jangka panjang - di dunia di mana semuanya diputuskan untuk dilakukan dengan cepat.

Dalam praktiknya, ini diungkapkan dalam hal serupa:

• Temukan kombinasi yang tepat antara enkapsulasi, ekstensibilitas, skalabilitas, dll. - lagi, diperlukan pendekatan berulang dengan coba-coba, karena tidak ada yang berhasil membangun solusi terbaik pada percobaan pertama.
  
• Luangkan waktu untuk refactoring jika Anda menemukan kode yang sangat buruk.
  
• Tulis tes yang bagus dan lengkap - bahkan mungkin melakukan TDD
  
• Program berbarengan dengan seorang kolega
  

Tidak perlu dikatakan, tidak mungkin untuk merencanakan semua ini sebelumnya, jadi pendekatan yang sama masih tidak akan membantu Anda memenuhi tenggat waktu.

Prediksi Anda salah

"Bahkan jika ada persyaratan yang jelas - dan tampaknya itu tidak pernah terjadi, hampir tidak mungkin untuk menghitung berapa lama untuk pekerjaan tertentu, karena kami tidak pernah menyelesaikan masalah ini sebelumnya. Jika Anda memutuskan, maka berikan saja hasilnya. "
- Ron Jeffries, Gerakan NoEstimates

Proyek perangkat lunak adalah Sistem yang Kompleks : dibuat oleh orang-orang, dan karena itu mengandung jejak hubungan interpersonal, motivasi, masalah komunikasi dan psikologi manusia secara umum - semua ini sangat sulit untuk dimodelkan dan dikuantifikasi dalam tabel jika Anda tertarik dengan pendapat saya. Jadi, proyek perangkat lunak sangat sulit untuk dimodelkan (dan, karena itu, prediksi). Ini paling baik dijelaskan oleh Nassim Taleb dalam bukunya " Anti-Fragility" :

“Sistem kompleks sangat saling tergantung (yang sulit dikenali) dan reaksi non-linear. “Non-linear” berarti bahwa ketika Anda menggandakan, misalnya, dosis obat atau jumlah pekerja di pabrik, pengembaliannya tidak akan dua kali lipat, tetapi lebih atau kurang. Ini bukan untuk mengatakan bahwa dua akhir pekan di Philadelphia dua kali lebih menyenangkan daripada satu - saya dapat mengatakan ini dari pengalaman saya sendiri ... "
- Nassim Nicholas Taleb, Anti-Kerapuhan

Lebih buruk lagi, mengingat waktu tidak bisa menjadi nilai negatif, "kejutan" yang tidak direncanakan cenderung menunda penyelesaian proyek, daripada membawanya lebih dekat, karena ada asimetri hasil:

“Waktu bukanlah nilai negatif, yang berarti bahwa proyek tiga bulan tidak dapat diimplementasikan dalam periode waktu nol atau negatif. Oleh karena itu, pada sumbu waktu, yang bergerak dari kiri ke kanan, kesalahan terakumulasi di kanan, dan bukan di kiri. Jika ketidakpastiannya linier, kita akan melihat bahwa beberapa proyek diselesaikan secara signifikan lebih cepat dari jadwal (karena kadang-kadang kita tiba di tempat yang jauh lebih awal, dan kadang-kadang jauh kemudian). Namun dalam kenyataannya, tidak demikian. "
- Nassim Nicholas Taleb, Anti-Kerapuhan

Ini adalah berita buruk, karena ketidakpastian dijamin , dan bahkan kesalahan kecil dalam mengevaluasi tugas individu akan menumpuk secara eksponensial dalam skala proyek. Selain itu, di sini kami mempertimbangkan kasus terbaik ketika tenggat waktu ditetapkan oleh pengembang sendiri setelah penilaian waktu yang cermat. Namun, kenyataannya jauh lebih absurd: dalam banyak kasus, "bisnis" menetapkan tenggat waktu yang diinginkannya, dan hanya insinyur yang merencanakan bagaimana memenuhi semua persyaratan untuk periode yang ditentukan secara sewenang-wenang ini menyelesaikan masalah; kasing ini sama mengerikannya dengan memulai sebuah rumah dari atap, bukan dari fondasi, atau meletakkan kereta di depan seekor kuda.


Pertanyaan yang bagus

Berikut adalah beberapa contoh yang menunjukkan non-linearitas pengembangan perangkat lunak dan loop umpan balik yang dihasilkan:

• Anda pernah menyarankan bahwa API Anda ingin mengikat untuk menerima accountId , tetapi sebenarnya hanya menerima memberId . Tambahkan ke perkiraan periode 4 hari Anda perlu refactor kode API - setelah itu, pada gilirannya, Anda akan memerlukan peninjauan terpisah, yang akan kami tambahkan 2 hari lagi.
  
• Tugas yang kami harap akan selesaikan dalam 2 hari berlangsung selama seminggu, karena dalam proses peninjauan salah satu rekan memaksa Anda (dan melakukannya dengan benar) untuk memperbaiki dan mengoptimalkan potongan kode menjijikkan yang telah lama menunggu di sayap.
  
• Ingat tugas satu kali ketika Anda perlu menerapkan hanya satu peluang baru. Tetapi ternyata untuk ini Anda perlu memperbarui dependensi, yang memakan waktu 4 hari, dan operasi ini memicu reaksi berantai dengan pembaruan dependensi lain dan sejumlah besar dependensi selama perakitan.
  

Apakah kita mengacau?

Kami hanya dengan inersia terus memainkan permainan ini dengan evaluasi dan perencanaan, hanya untuk meyakinkan diri kita sendiri: kita seharusnya mengendalikan situasi. Namun dalam kenyataannya, kita tidak mengendalikan apa pun; pengalaman menunjukkan bahwa proyek perangkat lunak tidak dapat diprediksi. Jadi saya pikir lebih baik fokus pada bisnis daripada perencanaan - #NoEstimates , siapa yang bersama saya? Namun, tentu saja, ini tidak akan berhasil di banyak organisasi: "Anda tidak bisa mengambilnya dan membiarkan para insinyur menjalankan bola sehingga tidak ada yang mengendalikan mereka. Harus ada akuntabilitas! " Saya mengerti.


Tidakkah kamu mengatakan itu?

Lalu apa yang harus dilakukan? Saya pikir ini bermuara pada mempersempit kesenjangan antara dunia tabel dan dunia IDE sehingga dapat memberikan para insinyur kreativitas, fleksibilitas, dan kebebasan maksimum untuk menunjukkan penguasaan, namun, pada saat yang sama, secara bertanggung jawab mematuhi janji dan memenuhi harapan para pemangku kepentingan proyek. Manajer Teknis (Manajer Teknik) - spesialis terbaik dalam membangun jembatan semacam itu, yang juga dapat menyerap kesenjangan antara dua dunia. Pekerjaan ini tidak mudah, tetapi perlu. Inilah seberapa baik Aaron Longwell berbicara tentang dia dalam artikelnya:

“Karena manajer teknis hidup di perbatasan antara bisnis dan teknisi, merekalah yang harus menyelesaikan kontradiksi antara harapan dan kenyataan. Mereka seperti suspensi tuas, yang ditarik ke arah yang berbeda: itu dapat patah di kedua sisi. Jika bisnisnya menang, maka pengembangnya akan mati. Jika pertimbangan teknik lebih besar daripada pertimbangan bisnis, maka selamat tinggal pada anggaran dan tenggat waktu. Bagaimanapun, sebuah kegagalan. Manajer proyek perangkat lunak yang berhasil menemukan cara untuk bertindak secara fleksibel; untuk menghasilkan, tidak melanggar, dan secara bertahap menyelesaikan gesekan. Kepemimpinan sebagai pendekatan layanan dapat membantu Anda menjadi lebih fleksibel. "
- Aaron Longwell, Mengapa Pengembangan Perangkat Lunak Membutuhkan Servant Leaders

Juga sangat penting untuk membangun hubungan saling percaya yang kuat antara Produksi dan Insinyur. Jika ada kepercayaan, maka Anda dapat dengan jujur ​​dan hati-hati menegosiasikan tenggat waktu. Jika Anda telah membuktikan bahwa tim Anda membuat perangkat lunak yang baik, maka Anda harus memiliki reputasi yang cukup baik, dan para pemangku kepentingan harus memercayai Anda, memahami bahwa jika Anda keluar dari jadwal, maka untuk alasan yang baik dan untuk kebaikan bersama.

"Trik" lain yang saya pribadi gunakan sebagai manajer adalah tidak menyebutkan tanggal tertentu, karena mereka pasti berubah menjadi tenggat waktu yang sulit. Lebih baik memberikan kurma fuzzy, misalnya, "tiga hingga lima minggu." Dalam hal ini, ketika mendekati tenggat waktu yang goyah, Anda menambahkan: "pada bulan April atau Mei", yang dengan mudah ditafsirkan sebagai "Antara 15 April dan 3 Mei" pada awal April, sekitar 10 April dapat berubah menjadi "Pada 20 April ", dll. Dalam hal ini, Anda tidak menyembunyikan, berkomunikasi dengan kolega, dan tim memberikan fleksibilitas persyaratan yang akan diperlukan untuk menyelesaikan masalah tak terduga yang tak terelakkan yang muncul.

Akhirnya, ingatlah bahwa pengembanglah yang harus bertanggung jawab atas kualitas teknis dari produk yang diterbitkan, dan bukan pihak terkait lainnya. Sangat wajar bahwa akan ada gesekan antara organisasi, yang, pada pandangan pertama, dipandu oleh insentif yang berbeda. Dalam hal ini, paling penting untuk dicatat bahwa Anda semua (mungkin) disatukan oleh tujuan bersama: untuk memberikan perangkat lunak berkualitas tinggi kepada pelanggan dalam waktu sesingkat mungkin. Tampaknya, hanya pengembang yang baik yang dapat berpikir dalam semangat ini dan memahami bahwa penting untuk menghindari pendekatan “satu, dua - dan selesai!” Yang menipu, yang dalam jangka panjang adalah yang paling lambat.

Sebagai kesimpulan, saya akan mengatakan bahwa ini adalah masalah yang dapat dipecahkan, meskipun kompleks (dan umum). Saya akan mengatakan bahwa jika, menurut pendapat Anda, manajer Anda atau organisasi Anda tidak cenderung untuk menulis perangkat lunak yang baik, maka Anda perlu membicarakannya dan mencoba mengubahnya; jika ini gagal, cari pekerjaan lain.

Tentang penerjemah

Artikel ini diterjemahkan oleh Alconost.

Alconost melokalkan game , aplikasi , dan situs dalam 70 bahasa. Penerjemah asli bahasa, pengujian linguistik, platform cloud dengan API, pelokalan berkelanjutan, manajer proyek 24/7, segala format sumber daya string.

Kami juga membuat video iklan dan pelatihan - untuk situs yang menjual, gambar, iklan, pelatihan, permainan asah, penjelajah, trailer untuk Google Play dan App Store.

Lebih detail