Mulai besok kita mulai hidup dengan cara baru. Kami akan memiliki Scrum dan akan ada kebahagiaan. Demokrasi lengkap: tidak ada bos, tim memutuskan apa yang harus dilakukan, birokrasi dibatalkan, yang utama adalah berbuat baik untuk pelanggan.
Seorang pelatih datang dan mengajari kami dasar-dasar. Dia berbicara tentang kesuksesan yang akan segera terjadi, tentang efisiensi dan fokus pelanggan, tentang fleksibilitas yang belum pernah terjadi sebelumnya dan pentingnya melibatkan klien dalam proses pengembangan, dan tentang pesawat ruang angkasa yang membajak Teater Bolshoi.
Baik, baik. Tunggu dan lihat.
Kami memulai proyek baru. Terima kasih Tuhan!
Dan kemudian saya sudah ditutupi lumut dari duduk di atas kode Legacy. Kekuatan saya tidak lebih, saya tidak bisa mengatasi monster pasta yang hebat ini. Saya entah bagaimana mencoba untuk memindahkan tombol dalam formulir login, jadi saya mendapat kesalahan dari modul surat. Pikirkan di mana koneksi itu ...
Mereka memperkenalkan kami kepada karyawan baru, kami akan memiliki Pemilik Produk atau, dalam bahasa Rusia, perwakilan pelanggan. Nama saya Rita. Wanita yang menawan. Senang berbicara.
Ajukan pertanyaan sederhana kepadanya, jadi dia memulai pidato selama setengah jam. Anda memandangnya dan berpikir: "Eh, Anda tidak mengerti apa-apa!"
Lima menit kemudian, Anda mulai ragu: "Tidak, seperti yang dikatakannya."
Pada akhirnya, Anda menyadari bahwa Anda belum menerima jawaban untuk pertanyaan Anda. Jadi kamu pergi.
Yang utama adalah menyela itu tidak mungkin. Mencoba mengganjal dan mengarahkan aliran verbal ke arah yang benar, tetapi di sana, dia tahu dirinya kebanjiran dan bercerita lagi tentang kapal dan Teater Bolshoi.
Kami sudah takut untuk mengajukan pertanyaan sederhana kepadanya. Anda bisa mendapatkan jawaban, tetapi Anda bisa tenggelam di lautan verbal.
Ya, birokrasi memang menjadi kurang. Karena semua orang mendapat nilai pada dokumentasi secara umum. Sekarang informasi dikirimkan terutama dari mulut ke mulut. Tentu saja, saya mengerti segalanya, kami sangat gesit, tetapi tidak pada tingkat yang sama ...
Diberi tugas: untuk mengembangkan di gateway kemampuan bagi klien untuk menerima data untuk menampilkan grafik. Anda harus pergi ke layanan, mendapatkan data mentah, menceritakannya kembali dan memberikannya kepada klien. Tidak ada spesifikasi apa dan bagaimana cara menghitung - tidak ada yang tahu. Hanya ada nama bagan. Nah, bagaimana saya harus melakukan ini, saya bertanya-tanya?
Oke, saya mencari di suatu tempat di proyek lama kami untuk sesuatu yang serupa, membuat pola. Tidak ada kepastian bahwa inilah yang dibutuhkan, tidak. Aneh, tapi tidak ada yang peduli. Yang utama adalah kami berhasil memperkenalkan fungsionalitas baru di demo.
Saya datang untuk bekerja hari ini, di sana, penguji cewek mengelilingi master Scrum kami Kolya, dan mereka menuntut untuk menjelaskan kepada mereka cara kerja fungsionalitas baru. Kolya melihat dengan mata menatap monitor dan bergumam tentang model dan tentang perubahan persyaratan.
Anda dapat memahami Kolya: Anda mengubah sesuatu sebulan yang lalu, dan sulit untuk mengingat apa sebenarnya, tidak ada dokumentasi. Tapi gadis-gadis itu bukan gula: mereka diperintahkan untuk menguji sesuatu, saya tidak tahu apa.
Saya bertemu mereka di koridor setengah jam kemudian: Kolya berjalan, gadis-gadis itu mengikutinya, dan semua orang tertawa: "Model baru ... model lama ... persyaratan pelanggan ...".
Orang miskin ...
Mendapat permintaan penarikan untuk ulasan. Kesalahan dalam mengekspor grafik: proporsi tinggi dan lebar berbeda dari aslinya. Aneh, karena saya pernah memecahkan masalah ini dan mengurus semua proporsi ... Masalahnya diselesaikan dengan cara yang asli: seorang rekan hanya mengalikan ketinggian dengan 1,25.
Saya bertanya kepadanya:
- Apa artinya koefisien ini?
"Dan ini," katanya, "aku mengambilnya." Sekarang semuanya akan baik-baik saja.
Jam berapa! Dia mengambil ... Dan apa yang akan terjadi dengan ekspor grafik lain? Mereka mulai mengerti, ternyata Anda hanya perlu sedikit mengubah urutan panggilan. Dalam beberapa kasus yang sangat jarang, pengaturan kanvas Anda digunakan, dan Anda perlu menghitung ulang proporsi setelah itu.
Seseorang mendapat kesan bahwa kadang-kadang penting bagi orang untuk melaporkan pekerjaan mereka dengan cara apa pun, dan hasil akhirnya tidak terlalu mengganggu mereka ...
Hari ini, Rita mengatakan bahwa dia memutuskan untuk menggunakan pengguliran tak terbatas ketika menampilkan daftar dokumen. Saya mencoba meyakinkannya bahwa situasi dalam layanan REST terus berubah: beberapa pengguna menambahkan dokumen, yang lain menghapus. Akibatnya, elemen tambahan akan muncul dalam formulir, atau elemen tersebut akan hilang, jadi lebih baik menggunakan usia tua yang baik. Ke mana saya diberitahu bahwa situasi seperti itu jarang terjadi, dan pengguliran tanpa akhir adalah mode dan seksi, pengguna akan senang.
Apakah kamu puas Hmm ... Saya akan kesal jika saya menemukan bahwa daftar tidak sesuai dengan keadaan saat ini ...
Saya tidak mengerti bagaimana mungkin membangun sebuah bangunan dari kotoran dan tongkat, tanpa fondasi, dimulai pada saat yang sama dari empat sudut secara bersamaan. Kadang-kadang saya berpikir bahwa jika pesawat terbang, kapal uap, dan gedung pencakar langit dirancang dengan cara yang sama dengan perangkat lunak modern, maka pesawat segera jatuh, kapal terbalik, dan kota-kota kita akan hancur. Jelas bahwa harga kesalahan kami jauh lebih rendah. Pada akhirnya, kami tidak membuat perangkat lunak medis atau luar angkasa. Tetapi perangkat lunak kami rumit, menggunakan banyak layanan microser. Penting untuk memperhatikan studi pendahuluan detail!
Adalah baik bahwa kita tidak membangun pesawat ...
Dia melihat ke departemen tetangga dan dari ambang merasa ada sesuatu yang salah. Semua orang duduk, mengetuk keyboard dengan marah, dan di udara ada semacam perasaan tidak beruntung pada umumnya.
Tiba-tiba master scrum mereka, Vitya, melompat dan bagaimana menjerit kepada seseorang:
- Apa yang kamu tulis untuk saya semua! Katakan secara lisan!
Dan kemudian mereka menerobos. Sekaligus menjadi pusing. Secara lisan. Kebisingan naik luar biasa.
Aku berdiri sebentar, batuk, semua orang terdiam dan menatapku. Tiba-tiba aku merasa tidak nyaman.
Victor berkata:
- Anda mengubah otorisasi dalam layanan?
"Ya," jawab saya, "berubah." Sekarang pengguna tanpa hak tidak dapat membaca sumber. Perlu untuk menggunakan cara yang berbeda.
- Jadi Anda berubah, - katanya, - dan sekarang aplikasi telah berhenti bekerja untuk kami.
Dia terdiam beberapa saat dan menambahkan:
- Anda melakukan segalanya dengan benar, ini adalah cant kami. Tapi kami, Anda tahu, perlu meluncurkan rilis setelah tiga jam, dan kami tidak bisa memperbaiki kesalahan dengan cepat.
Saya ingin memberi tahu mereka: "Ya ampun, Anda belum pernah menjalankan tes, karena minggu telah berlalu!", Tetapi melihat wajah mereka, berbalik dan pergi untuk melakukan rollback dalam layanan.
Kepala mengumpulkan kami hari ini dan berkata:
- Kita harus memiliki epik. Kami ingin memperkenalkan pembelajaran mesin untuk menyesuaikan hasil pencarian.
Orang-orang, tentu saja, tertarik pada apa yang dimaksud dan apakah ada deskripsi masalahnya.
- Belum ada deskripsi lengkap, saya akan melemparkan Anda tautan ke apa. Pikirkan sekarang, - jawaban. Dan pergi.
Kemudian saya melihat halaman itu melalui tautannya: heading dan dua paragraf. Dan bagaimana menurut Anda Anda harus memesan, jika tidak jelas apa yang harus dipikirkan?
Apa yang terjadi pada mereka, karena ada orang-orang teknis, mereka bangkit dari pengembang sederhana, dan sekarang seolah-olah mereka merosot menjadi pelanggan. Saya mendengar di suatu tempat bahwa kecerdasan buatan itu modis dan keren, dan mari kita mulai epik. Tidak ada tugas untuk mengkonkretkan, atau spesifikasi yang tepat untuk menulis, semuanya adalah masalah besar dan pesawat ruang angkasa dengan teater ...
Saya bertemu Vitya hari ini di koridor dan bertanya:
"Yah, apakah kamu menemukan kesalahan?" Sebulan telah berlalu. Akan diperlukan untuk mengembalikan otorisasi dalam layanan, jika tidak kita hidup dengan lubang.
Vitya memalingkan muka dan berkata:
- Tidak, belum ditemukan. Tidak ada cukup waktu sama sekali ...
Nah, ini dia. Selama sebulan orang tidak dapat menemukan tempat di mana titik akhir yang salah digunakan. Rupanya, mereka sudah meninggalkan ini dan terlibat dalam urusan saat ini. Ini aneh, karena program ini, pada kenyataannya, menggunakan data yang salah ...
Ya, gateway baru kami telah berubah menjadi pasta pasta yang ketat, dan sudah tidak mungkin untuk menemukan ujungnya. Cepat, kami berhasil!
Saya mencoba meyakinkan kolega saya untuk berbicara dengan atasan saya tentang keadaan saat ini. Dari sudut pandang saya, proyek ini dalam keadaan menyedihkan: tim yang berbeda, menyelesaikan tugas mereka, melakukan pengeditan yang meningkatkan kekacauan, entropi tumbuh. Setiap kali, menyelesaikan masalah menjadi semakin rumit.
Orang-orang setuju dengan saya, tetapi inisiatif saya keren. Dan mereka dapat dipahami: setiap orang memiliki tugas saat ini yang harus diselesaikan selama sprint. Tidak sampai berfilsafat, hal-hal harus dilakukan ...
Saya akui: Saya menemukan buku harian ini. Semua karakter adalah fiktif, kebetulan adalah acak. Ini hanya lelucon.
Terkadang manajemen menganggap Agile agak vulgar: cukup untuk menguraikan tugas sedikit, dan tim yang baik akan menangani semua masalah arsitektur dan konseptual sendiri. Seringkali mereka lupa tentang perlunya dokumentasi menyeluruh, meskipun penggunaan Agile sama sekali tidak berarti penolakan terhadap dokumentasi.
Namun, saya tidak ingin berbicara tentang Agile atau teknologi pengembangan. Saya ingin berspekulasi tentang kualitas perangkat lunak yang kami buat dan seberapa buruk keputusan dapat menghancurkan perangkat lunak ini.
Konflik kepentingan
Anda seorang pengembang. Proyek atau bagian dari proyek yang sedang Anda kerjakan adalah anak favorit Anda. Anda menciptakan dan memeliharanya, Anda ingin Anda memiliki ciptaan yang sempurna. Sehingga kolega dan pengguna Anda dapat mengatakan: "Ya, ini adalah hal yang keren!".
Tetapi Anda bekerja untuk bisnis yang mempekerjakan Anda. Bisnis tidak tertarik dengan ambisi Anda. Tujuan utama bisnis adalah untung, dan memang seharusnya begitu. Di sini Anda pada saat yang sama dengan bisnis, karena Anda ingin orang sebanyak mungkin menggunakan proyek Anda?
Tetapi karena satu dan lain alasan, bisnis dapat membuat keputusan yang melanggar harmoni proyek Anda. Katakanlah Anda perlu mengencangkan sesuatu dengan sangat cepat, jika tidak klien akan pergi. Tidak ada waktu untuk menyelesaikan masalah dengan benar.
Apa yang harus dilakukan
Kemungkinan besar, Anda harus mematahkan diri, berharap kruk saat ini dapat dihapus nanti ...
Namun, tidak semuanya begitu sedih. Dalam jangka panjang, bisnis adalah sekutu Anda dalam perjuangan untuk kualitas, kecuali, tentu saja, ia adalah musuh bagi dirinya sendiri.
Meskipun demikian, penting untuk bertemu dengan pendekatan seperti itu sehingga uraian terperinci dan analisis kadang-kadang dapat diabaikan, karena kepuasan pelanggan yang cepat dan murah adalah yang paling penting. Apakah kesuksesan mungkin terjadi dalam kasus ini?
Apakah kesuksesan itu mungkin?
Paradoksnya adalah bahwa produk-produk semacam itu mungkin berhasil secara komersial, setidaknya pada tahap pertama. Klien, tentu saja, terganggu oleh banyak kekurangan dan ketidakkonsistenan dalam sistem, tetapi, secara umum, produk menyelesaikan masalah mereka.
Klien puas dengan tingkat dukungan: mereka memperhatikan kebutuhan mereka dan berusaha untuk dengan cepat memenuhi kebutuhan baru. Benar, beberapa dari mereka dari waktu ke waktu memperhatikan bahwa sistem menjadi semakin tidak konsisten dan tidak dapat diprediksi dalam perilaku, antarmuka menjadi lebih rumit, menjadi semakin sulit untuk memahami apa yang terjadi di dalam, bagaimana menyelesaikan masalah tertentu dengan benar, ada masalah dengan waktu tanggapan, dan sebagainya. Tetapi ini terjadi secara bertahap dan pada awalnya tanpa terasa.
Tidak ada yang curiga bahwa proyek ini hancur. Tak lama lagi, dia pasti akan runtuh karena kerasnya semua ekstensi yang melekat padanya dengan tergesa-gesa.
Seberapa terhubung harmoni internal produk dengan kualitas konsumennya? Sering terjadi bahwa pengembang dalam keadaan horor permanen dari kondisi internal sistem, sementara pelanggan tampaknya puas. Tapi bisakah pesawat yang jelek itu bagus? Dan haruskah harmoni batin suatu produk tidak tercermin dalam kualitas konsumennya?
Bukan rahasia lagi bahwa bagian dalam yang cabul disembunyikan di balik fasad yang indah, dan ini tidak hanya berlaku untuk perusahaan kecil, tetapi juga untuk raksasa industri perangkat lunak. Ini hanya satu
contoh .
Perusahaan monster dapat mempekerjakan ribuan programmer untuk mendukung hidangan spageti raksasa yang telah diubah oleh produk mereka selama bertahun-tahun dan puluhan tahun, tetapi bagi perusahaan kecil ini adalah cara yang mematikan. Dan omong-omong, bahkan untuk monster, kualitas rendah kode tidak lulus tanpa jejak dan berubah menjadi waktu pengembangan dan implementasi yang meningkat secara eksponensial untuk setiap fitur baru, proses yang lebih mahal dan terus-menerus menurunkan kualitas dukungan.
Apa yang lebih penting: kualitas produk atau keterampilan penjualan?
Produk yang berkualitas, sayangnya, bukan jaminan kesuksesan.
Saya memiliki kasus dalam praktiknya ketika satu program yang sangat terspesialisasi yang bekerja dengan baik di Rusia harus dipromosikan ke pasar Eropa. Program menggunakan format data sendiri, dan konversi data pelanggan yang tersedia pada waktu itu tidak terlalu sulit. Jika kami berhasil menyelesaikan kontrak, kami akan menjadi perusahaan monopoli di Eropa untuk sementara waktu. Tampaknya semuanya ada di pihak kita: permintaan di pasar besar, sejauh ini tidak ada yang bisa menawarkan sesuatu yang lengkap dan benar-benar berfungsi, kecuali bagi kita, program ini sudah bekerja di ratusan pekerjaan di Rusia, pelanggan Rusia merespons positif tentang produk.
Jadi, apakah kita berhasil? Sayangnya, tidak. Tender dimenangkan oleh perusahaan Eropa yang telah bekerja dengan klien di daerah lain. Mereka pada saat itu hanya di awal jalan yang telah kami lalui, tetapi berhasil mengalahkan kami. Sayangnya, kami tidak memiliki spesialis yang baik dalam promosi dan penjualan, dan kami tidak dapat meyakinkan orang untuk membuat pilihan yang mendukung perusahaan kami. Kemudian, setelah beberapa waktu, sangat mengecewakan melihat pencapaian kami dalam mengatur antarmuka pengguna dalam produk baru mereka ...
Keputusan buruk
Produk berkualitas tinggi adalah tujuan strategis, dan bisnis yang cerdas akan selalu berada di sisi pengembang, berjuang untuk keunggulan. Tetapi menjaga harmoni internal produk tidak mudah. Dengan pengembangan produk, persyaratan baru datang kepada kami yang dapat menghancurkan harmoni konsep asli. Keputusan yang dibuat dalam kasus ini memainkan peran yang menentukan dalam nasib produk di masa depan.
Tidak ada yang aman dari keputusan buruk. Jika keputusan strategis dibuat pada tahap desain, dan seiring waktu, menjadi jelas bahwa itu salah, ini menyebabkan kematian proyek. Tetapi seringkali keputusan buruk dibuat selama pengembangan ketika fungsionalitas baru ditambahkan. Itu semua tergantung, pertama, pada globalitas keputusan yang dibuat, yaitu, tingkat pengaruhnya terhadap sistem secara keseluruhan, dan kedua, pada jumlah keputusan buruk. Ketika jumlah keputusan buruk dan tingkat pengaruhnya melebihi batas tertentu, penderitaan yang panjang dan menyakitkan dimulai.
Saya ingin berbagi dengan Anda beberapa contoh keputusan buruk dari pengalaman saya sendiri. Tentu saja, contoh-contoh ini sama sekali tidak mengklaim luas akademik dan sistematisasi.
Aturan longgar
Terkadang bagi kita tampaknya untuk kenyamanan pengguna, aturannya harus fleksibel.
Misalnya, sistem Anda berfungsi dengan berbagai jenis hierarki yang dibuat oleh pengguna. Anda memutuskan bahwa untuk salah satu jenis kunci simpul hanya unik di dalam level, dan tidak di seluruh hierarki. Ini sepertinya nyaman karena pengguna memuat hierarki dalam level.
Konsekuensi: sekarang, programmer di mana pun dalam kode harus berhati-hati mempersiapkan kunci komposit, dan ini akan sering menyebabkan kesalahan. Jika pengguna memiliki akses ke situs dengan kunci, ini juga akan menjadi sakit kepala bagi mereka.
Mungkin bermanfaat untuk mempertimbangkan aturan yang lebih ketat dan memerlukan keunikan kunci di seluruh hierarki. Ini akan menguntungkan pengembang dan pengguna.
Pelanggaran aturan
Anda memiliki hierarki kompleks objek yang dibuat pengguna. Setiap objek berisi properti Nama, yang merupakan kunci, dan Judul dengan teks arbitrer. Ada seperangkat aturan formal untuk nama, misalnya, nama tidak boleh berisi spasi atau karakter khusus. Pada titik tertentu, tugas muncul secara otomatis menghasilkan objek dari satu jenis dari yang lain. Nama harus didasarkan pada Judul dan dapat dikenali. Anda memutuskan untuk melanggar aturan dan menggunakan Judul sebagai nama: bagi Anda tampaknya itu akan paling nyaman bagi pengguna.
Bersiaplah untuk masalah di sistem Anda yang akan terjadi di tempat yang tidak terduga.
Pengaturan kompleksitas
Anda memasukkan pengaturan yang hanya valid dalam kondisi tertentu. Ketika beberapa instalasi beroperasi dalam kondisi yang lain termasuk, ini adalah situasi yang cukup umum. Tetapi jika Anda memiliki hierarki sikap yang kompleks, beberapa di antaranya bekerja ketika orang lain dihidupkan, dan mereka, pada gilirannya, bersyarat, ini adalah jalan menuju kekacauan. Pengalaman menunjukkan bahwa dalam kasus ini tidak ada yang siap untuk memprediksi bagaimana perubahan dalam instalasi tertentu akan memengaruhi perilaku: baik pengguna, maupun pengembang. Sistem pengaturan harus jelas, sejelas mungkin dan dipikirkan dengan cermat. Anda harus berusaha mengurangi ketergantungan beberapa pengaturan pada yang lain.
Kurangnya analisis masalah
Sistem Anda memungkinkan pengguna untuk membuat laporan berdasarkan DSL. Pada awalnya diputuskan bahwa DSL berisi semua properti laporan. Setelah beberapa waktu, salah satu klien meminta Anda untuk menambahkan kemampuan untuk menyimpan bagian dari instalasi secara terpisah - ini diperlukan untuk menyelesaikan beberapa masalah internal klien. Memulai tugas di Jira "Tambahkan pengaturan eksternal" tanpa terlebih dahulu menganalisis masalahnya adalah kesalahan.
Pertama-tama, perlu untuk menjawab pertanyaan: mengapa itu diperlukan sama sekali? Mungkin ternyata klien hanya ingin menyembunyikan bagian dari pengaturan untuk beberapa pengguna. Mungkin Anda harus mempertimbangkan pemisahan DSL menjadi bagian-bagian dengan otorisasi bagian-bagian ini? Keputusan tidak begitu cepat, tetapi mungkin secara strategis benar.Keputusan politik
Terkadang keputusan dibuat karena alasan organisasi. Sebagai contoh, sumber daya tertentu disimpan dalam microservice yang dirancang khusus untuk ini. Diperlukan beberapa jenis sumber daya yang serupa. Satu tim terlibat dalam layanan, dan jenis sumber daya baru dibutuhkan oleh yang lain. Untuk berbagi tanggung jawab, keputusan dibuat untuk menambahkan tipe baru bukan ke layanan asli, tetapi ke layanan yang dijalankan oleh tim lain.Masalahnya adalah bahwa layanan tidak hanya menyimpan data, tetapi juga memberikan otorisasi. Sekarang Anda harus berhati-hati menggunakan kembali kode tersebut. Tapi ini bukan yang utama. Yang utama adalah bahwa sekarang tidak jelas layanan mana yang harus digunakan untuk mendapatkan data yang diperlukan. Bukti internal membangun sistem dikorbankan untuk motif organisasi atau politik.Kesimpulan
Sebagai pengembang, saya ingin bangga dengan hasil pekerjaan saya. Bagi saya, keindahan batin, keanggunan dan keharmonisan proyek itu penting. Namun yang tak kalah penting adalah permintaan. Saya tidak ingin bekerja untuk keranjang, saya ingin orang sebanyak mungkin menggunakan produk dan puas. Saya mengerti bahwa kadang-kadang Anda harus pergi ke biaya dan merusak sedikit keharmonisan batin untuk menyenangkan kepentingan klien individu. Tetapi saya yakin bahwa di balik fasad yang indah tidak boleh ada aib, interior yang jelek cepat atau lambat akan naik ke luar, tidak masalah apakah ini merupakan kebingungan eksternal dalam konsep, atau waktu respons yang semakin meningkat terhadap masalah pelanggan.Keindahan dan harmoni produk adalah yang paling penting. Ya, kami kadang-kadang dipaksa untuk berkompromi demi kepentingan bisnis dan siap untuk mengaburkan kejelasan pendekatan demi kepentingan klien tertentu, terutama jika itu adalah klien yang sangat penting, tetapi ini merupakan lereng yang licin.Lebih dari sekali saya harus mengamati kepunahan dan kematian proyek secara bertahap, ketika orang-orang tidak repot-repot mempelajari detail dan tanpa berpikir memperkenalkan fungsi baru, tidak peduli tentang ketidakkonsistenan dalam produk dan tidak memperhatikan munculnya koneksi baru dan yang tidak perlu antara modul. Ini selalu mengarah pada kebingungan, ketika menjadi semakin sulit untuk memperbaiki kesalahan yang paling sederhana, karena tidak ada kepastian bahwa koreksi ini tidak akan memiliki efek yang tak terduga pada komponen dan bagian sistem yang benar-benar asing.Saya ingin berharap umur panjang untuk proyek Anda!