Saya bisa mengerti tekanan jadwal. Anda ingin menyenangkan pengguna Anda, karena mereka adalah sumber kehidupan perusahaan. Namun, juga benar bahwa perubahan tertentu akan membuat segalanya lebih mudah. Sayangnya, manajemen dalam organisasi saya memiliki resistensi naluriah terhadap perubahan seperti itu dan resistensi ini begitu kuat sehingga menghalangi perbaikan jangka panjang.

Misalnya, Apple baru-baru ini memperkenalkan Penghitungan Referensi Otomatis untuk program iOS. Ini adalah peningkatan besar atas panggilan retain / release manual yang sebelumnya harus digunakan. Kode lebih mudah ditulis dan lebih mudah dipelihara. Changeover itu sendiri kemungkinan menghasilkan beberapa crash. Tapi begitu itu berhasil, jumlah crash aneh acak cenderung turun.

Baru-baru ini saya memberi tahu bos saya bahwa saya ingin beralih ke penghitungan referensi otomatis. Responsnya adalah bahwa ia ingin berkonsentrasi pada peningkatan yang terlihat. Kemungkinan tanggapan ini pada gilirannya didorong oleh tekanan yang didapatnya dari atas dirinya - dan mungkin benar dari CEO.

Ada banyak contoh serupa. Utas umum adalah bahwa sesuatu harus diperbaiki tetapi biaya jangka pendek perbaikan lebih besar daripada manfaat jangka pendek, di mana "jangka pendek" didefinisikan sebagai "dalam beberapa minggu ke depan."

Bagaimana saya harus menangani situasi ini?

EDIT: Terima kasih atas tanggapannya. Terus mereka datang. Karena ini relevan dengan situasi saya, saya harus menjelaskan bahwa manajer dan CEO saya adalah keduanya programmer - walaupun CEO sekarang mungkin sudah lupa seperti apa ini. Rupanya sisi programmer mereka kewalahan oleh tekanan lain.

Anda benar-benar berbicara tentang utang teknis. Mungkin metafora akan membantu manajer Anda. Saya sering membandingkan efek hutang teknis dalam perangkat lunak dengan memasak di dapur yang kotor. Jika wastafel dan konter serta kompor ditumpuk dengan piring kotor dan ada sampah di lantai, dibutuhkan waktu lebih lama untuk membuat makanan. Namun, cara tercepat untuk menyiapkan makanan berikutnya adalah bekerja di sekitar kekacauan. Membersihkan dapur, dan menjaganya tetap bersih, akan menunda makan berikutnya, tetapi akan meningkatkan pengiriman semua makanan berikutnya. Dan sama seperti orang yang lapar di ruang makan tidak dapat melihat dapur yang berantakan, dan tidak akan mengerti mengapa Anda ingin membersihkan sebelum mulai memasak, manajemen Anda tidak dapat melihat kekacauan dalam kode. Anda harus menunjukkan kepada mereka kekacauan, atau menunjukkan masalah kualitas dan penundaan yang disebabkan oleh kekacauan tersebut.

Mungkin Anda juga bisa berbicara tentang tugas yang mendesak dan tugas penting. Ketika tugas-tugas penting tidak selesai, maka tugas-tugas mendesak memakan waktu lebih lama dan lebih mahal.

Anda telah menemukan sesuatu yang mengganggu programer di mana-mana di beberapa titik dalam karir mereka: kode ini perlu di refactored, ada masalah arsitektur di sana, modul ini menjadi tidak dapat dipertahankan, dll. Karena budaya organisasi Anda saat ini, bagaimanapun, Anda didorong untuk fokus pada pekerjaan yang hanya menghasilkan manfaat yang langsung terlihat .

Ini Rahasia Gunung Es klasik lagi. Rahasianya ada hubungannya dengan fakta bahwa sama seperti gunung es adalah 90% air, sehingga untuk adalah sebagian dari setiap proyek pembangunan: 90% dari pekerjaan akan menjadi benar-benar terlihat oleh pengguna akhir. Kode itu akan berdampak pada pengguna akhir tetapi manajemen mengalami kesulitan membungkus pikiran mereka di sekitar mengapa Anda menghabiskan enam jam refactoring panggilan pemeliharaan / rilis dan referensi otomatis ketika Mereka Tidak Dapat Melihat Perbedaan dan semuanya Bekerja dengan Baik.

Berikut adalah beberapa fakta yang dapat Anda bawa tentang masalah ini.

• Manajemen, kecuali mereka adalah programmer itu sendiri , tidak akan memahami Rahasia Gunung Es.
• Ini adalah masalah ketidaktahuan, bukan kedengkian. CEO menginginkan produk yang bagus - dia tidak mengerti semua yang masuk ke produk yang bagus.
• CEO (dan atasan langsung Anda) tidak bodoh - pelajarilah dan siapkan beberapa fakta dan beberapa data konkret mengapa Anda harus meluangkan waktu untuk hal ini, dan masalah-masalah Gunung Es lainnya.

Jangan lupa - Anda pria perusahaan (atau wanita). Bukan manusia kode. Anda sedang mengembangkan produk ini untuk perusahaan yang memiliki kepentingan dalam keberhasilan atau kegagalannya - proyek dan proposal proyek Anda harus mencerminkan hal ini. Tunjukkan hasrat Anda terhadap perusahaan dan produk, tunjukkan pengetahuan Anda, dan buktikan kepada bos dan CEO Anda bahwa mereka harus memercayai Anda ketika Anda datang kepada mereka dan mengatakan bahwa Sesuatu Membutuhkan Pekerjaan. Tunjukkan pada mereka bagaimana hal itu akan berkontribusi pada garis bawah - apakah dengan menambahkan nilai pada produk (lebih banyak orang membeli salinan) atau dengan menghemat waktu (lebih sedikit pelanggan yang marah ketika produk Anda gagal).

Kamu tidak.

Saya melihat pertanyaan ini dan semua pertanyaan menyukainya sebagai jalan buntu. Anda tidak dapat "meyakinkan" orang tentang apa pun. Jika mereka belum mengetahui hal-hal seperti ini atau menyelidikinya, kemungkinan mereka tidak akan menyerah. Dan tidak ada jumlah data yang akan meyakinkan mereka sebaliknya. Perubahan harus datang dari dalam. Anda bisa menuntun kuda ke air tetapi Anda tidak bisa membuatnya minum.

Saya katakan memanggang perubahan yang Anda inginkan ke perkiraan teknis Anda berikutnya. Seperti, hei, kita "harus" meningkatkan kerangka kerja baru yang diperkenalkan Apple. Jangan biarkan tidak menggunakan ARC di peta jalan Anda. Tidak ada opsi; bermigrasi ke ARC adalah satu-satunya cara.

Saya telah menjawab pertanyaan serupa di sini sebelumnya sehingga ini dapat dianggap duplikat. Pada dasarnya, Anda tidak akan mendapatkan signoff untuk melakukan "upaya refactoring". Cara Anda membuat kode lebih bersih adalah dengan mengikuti aturan pramuka: selalu biarkan kode lebih bersih saat Anda meninggalkannya daripada saat Anda tiba.

Sama seperti membayar utang riil bisa tampak seperti tugas yang tidak dapat diatasi (atau membersihkan rumah yang berantakan). Caranya adalah membuatnya lebih baik sepotong demi sepotong sampai Anda mulai melihat "pulau kebersihan". Setelah Anda memiliki momentum yang signifikan, pengembang lain di tim akan mulai memperhatikan dan pada akhirnya berkontribusi pada tugas.

Saya sarankan membaca Clean Coder oleh "Paman" Bob Martin. Menulis kode yang baik adalah bagian dari pekerjaan Anda. Anda tidak meminta izin untuk melakukan pekerjaan Anda, Anda hanya melakukannya.

Seperti pertanyaan lain yang bersifat ini, Anda perlu memberikan angka yang akan dipahami manajemen. Angka yang menunjukkan berapa banyak waktu yang akan dihemat dengan menerapkan peningkatan ini, berapa banyak "crash aneh acak" akan terjadi, dll. Meyakinkan mereka bahwa crash terlihat oleh pengguna akhir dan bahwa segala sesuatu yang dilakukan untuk mencegahnya baik untuk bisnis.

Anda juga dapat mencoba mengimplementasikan peningkatan ini pada waktu Anda sendiri (yaitu di luar jam kerja) dan kemudian menunjukkan manfaatnya kepada manajemen sesudahnya. Saya hanya akan melakukan ini ketika jelas bahwa manajemen tidak memahami apa yang Anda coba sampaikan dan / atau bahwa mereka tidak ingin mengalokasikan waktu bagi Anda untuk mencobanya.

Semoga berhasil!

Sajikan Kasus Bisnis

Ada banyak alasan mengapa rekomendasi insinyur sering diabaikan. Cara terbaik untuk menangani hampir semua alasan adalah dengan menghadirkan alasan bisnis mengapa harus dilakukan. Analisis biaya / manfaat klasik. Ini tidak hanya membuat argumen yang meyakinkan, tetapi juga memberi atasan Anda sesuatu untuk dibawa ke atasan mereka.

• Berapa biaya dimuka?
• Berapa biaya yang berkelanjutan?
• Apa penghematan uang / waktu yang diproyeksikan dan dari mana mereka berasal?
• Berapa lama sebelum kita melihat ROI?

Saat melakukan kasus bisnis, Anda harus selalu mendukung argumen Anda dengan data.

• Berapa banyak waktu yang dihabiskan pembangunan untuk mengatasi masalah yang akan dihilangkan atau dikurangi ini?
• Berapa banyak keluhan pengguna yang Anda dapatkan terkait dengan masalah yang akan dihapus atau dikurangi ini?
• Apa manfaat lain yang dimilikinya?

Sejajarkan angka-angka dan buat persamaannya kasar, tetapi sederhana. Akan dikenakan biaya X untuk melakukan dan itu akan menguntungkan perusahaan Y.

Catatan: Jangan kaget jika menerapkan gagasan akademis itu mahal.

Perubahan semacam ini termasuk dalam kategori refactoring. Pendekatan Agile adalah bahwa Anda harus memasukkan waktu refactoring AMPLE ke dalam setiap cerita yang Anda perkirakan dan inilah alasannya. Selain insinyur, tidak ada yang akan mengerti mengapa Anda ingin melakukan ini dan tidak apa-apa, itu bukan pekerjaan MEREKA untuk menentukan cara kode dengan benar, itu milik Anda.

Jadi lain kali Anda memiliki banyak pekerjaan yang harus dilakukan, pastikan bahwa perubahan ini adalah bagian dari itu. Jika Anda memberikan perkiraan, pastikan untuk menambahkan 30% ke perkiraan Anda untuk refactoring, jika Anda tidak memberikan perkiraan maka lakukan saja refactoring sebagai bagian dari pekerjaan Anda.

Ini mungkin membuat Anda lebih lambat - tidak, itu bukan cara untuk melihatnya, cara untuk melihatnya adalah bahwa kecepatan Anda saat ini adalah ilusi, pada dasarnya kebohongan bahwa Anda melewatkan rantai, Anda sebenarnya harus menjadi sedikit lebih lambat karena pekerjaan ini yang Anda tahu perlu dilakukan.

Anda mungkin bisa membangun rumah lebih cepat jika Anda tidak menggunakan beton sebagai fondasi - dan mereka akan terlihat baik bagi pelanggan tetapi - yah - Bahkan jika pelanggan tidak melihat perlunya fondasi, pembangun perlu. (Ini sebenarnya paralel yang menarik karena ternyata pembangun tidak selalu melakukan apa yang mereka tahu harus mereka lakukan sehingga kita perlu mengesahkan undang-undang untuk memaksa mereka - tidak ada undang-undang yang mengatur pengembangan perangkat lunak meskipun kita menghadapi hal yang sama keputusan dan sering membuat yang salah ...)

Anda menyebutkan bahwa Anda cukup beruntung sehingga manajer dan CEO Anda sama-sama programmer. Sehingga mereka mungkin tidak mengerti apa utang teknis.

Anda harus menangani situasi dengan mencoba menyelesaikan situasi berdasarkan fakta, yang berarti ada kemungkinan nyata bahwa Anda tidak akan berakhir membuat perbaikan teknis yang Anda inginkan (fakta dapat mengganggu seperti itu).

Tugas Anda adalah memastikan mereka memahami biaya dan manfaat melunasi hutang teknis tertentu yang Anda tanggung. Pekerjaan mereka adalah memutuskan apakah penggunaan sumber daya yang terbaik adalah dalam melunasinya atau melakukan sesuatu yang lain.

Seperti halnya sulit bagi orang-orang yang tidak terlibat dengan kode untuk melihat manfaat dari meningkatkan hal-hal "tersembunyi", mungkin sulit bagi programmer untuk melihat manfaat dari perubahan kode yang terlihat ketika manfaat bertambah ke bidang bisnis sedikit " disembunyikan "dari pengembang.

Sangat menyenangkan jika manajemen Anda dapat menjelaskan kepada Anda mengapa fitur yang terlihat lebih sepadan dengan waktu Anda daripada membayar utang teknis, tetapi sebenarnya, bukan tugas Anda untuk menentukannya. Jadi, menjelaskannya kepada Anda tidak banyak membantu bisnis kecuali membuat Anda bahagia. Dan dalam satu hal, bersikeras mereka melakukannya adalah tidak memercayai mereka untuk melakukan pekerjaan mereka. Jika Anda tidak suka ketika mereka mengelola Anda maka Anda harus mengerti.

Jadi, selama Anda membuat mereka sadar akan status semua hutang teknis dan biaya serta manfaat dari mengabaikannya dibandingkan melunasinya, Anda telah melakukan pekerjaan Anda. Kecuali jika Anda benar - benar tidak mempercayai manajemen untuk melakukannya, dalam hal ini Anda memiliki masalah yang jauh lebih besar yang akan menjadi pertanyaan lain untuk diatasi.

Mungkin ini bukan jawaban, tetapi tanggapan berdasarkan kesalahan yang saya buat. Juga ketidaksepakatan dengan beberapa filosofi yang saya baca di sini.

• Jangan bertabrakan dengan keyakinan bahwa programmer paling tahu.
• Jujur. Re-faktor ketika Anda pergi tetapi jangan berbohong dan pad estimasi untuk tujuan Anda sendiri.
• Anda tidak memiliki kodenya. Jangan melakukan pekerjaan yang tidak disetujui oleh pimpinan.
• Anda bisa benar tentang sesuatu; Anda bisa saja salah ... tetapi Anda harus melakukan apa yang harus Anda lakukan.

Tetapi tentu saja mengikuti saran luar biasa yang diberikan untuk memperbaiki keadaan.

Anda jelas bekerja untuk bos berambut runcing (PHB). Dia tidak memprogram lagi, jika pernah, dan jika dia melakukannya, dia mungkin tidak benar-benar baik (meskipun dia suka menjatuhkan frasa seperti "kebenaran konst" dan "kesalahan segmentasi" sehingga orang-orang tahu dia mendapatkan garis-garisnya) ) - itulah cara dia dipilih untuk manajemen.

CEO (yang praktis memiliki Mohawk) menyukai PHB karena PHB menghadirkan fitur . Setiap sprint ia dengan bangga menunjukkan kotak centang baru (sedikit tidak selaras, dengan label yang ambigu), ikon gemerlapan (belum bekerja di lingkungan apa pun kecuali warna 8-bit di atas Citrix) dan formulir (yang memiliki tabrakan acak karena kondisi balapan) dalam varian xml berdasarkan pesanan dipesan lebih dahulu mengimplementasikan database lokal yang tidak seorang pun di tim dev berani menyentuh karena ditulis oleh salah satu legenda dev penjaga lama 10 tahun yang lalu dan melakukan SEMUA dengan makro dengan 5 nama huruf, apakah mereka membutuhkan 5 huruf atau tidak).

Programmer yang benar-benar melakukan "bit kerja" (Anda tahu bit itu terjadi, tidak nyaman setelah semua pekerjaan nyata seperti menggambar lingkaran di papan tulis, berteriak, dan makan miniatur Battenburg sudah selesai) tahu bahwa dalam sistem waras pekerjaan yang baru saja diambil 10 orang 10 hari untuk susah payah keluar dari hutan yang tidak terawat, mungkin berjumlah satu atau dua hari, termasuk pengujian. Tetapi untuk mendapatkan sistem dari mana itu menjadi waras mungkin butuh 6 bulan kerja yang benar-benar keras, dengan sedikit di jalan imbalan eksternal yang jelas.

PHB tahu bahwa dalam 6 bulan, dengan cara apa pun, ia bisa mendapatkan tiga puluh atau empat puluh fitur baru ke dalam aplikasi yang dapat digunakan oleh para tenaga penjualan (yang harus menjadi penyihir dengan apa yang sebenarnya mereka jual) dapat digunakan untuk menggoda pembelian dan peningkatan baru. .

Namun untuk memberi PHB tugasnya: tanpa kotak centang dan bentuk penjualan itu mungkin mandek atau menurun, pesaing mungkin mendapatkan pangsa pasar, dan itu mungkin lebih buruk daripada alternatifnya.

Kesimpulan yang saya dapatkan adalah bahwa satu-satunya jalan keluar dari rawa adalah bekerja di sebuah perusahaan baru, dengan beberapa orang yang berbagi visi Anda tentang bagaimana perangkat lunak harus dilakukan dan kemudian dengan teguh berpegang pada filosofi itu (saya Saya masih berusaha untuk sampai ke sana!)

Ada biaya tersembunyi lain yang tidak disebutkan dalam jawaban lain. Yaitu bahwa insinyur yang baik cenderung meninggalkan jenis lingkungan yang dijelaskan. Akhirnya siapa pun yang memiliki ambisi atau kemampuan untuk memperbaiki telah meninggalkan perusahaan, dan kemudian segalanya akan menjadi sangat buruk, mungkin tidak dapat diperbaiki. Sayangnya Anda tidak dapat memberi tahu manajer Anda hal ini tanpa dianggap sombong ("Saya salah satu programmer terbaik Anda"), dan seorang brengsek yang memaksa ("Saya akan pergi jika Anda tidak melakukan apa yang saya inginkan"). Namun, ingatlah untuk menyebutkannya dalam wawancara keluar Anda, untuk memastikan Anda tidak memakai status perekrutan ulang.

Anda berdua benar dan keduanya salah, itu sebabnya masalah-masalah itu bertahan lama dan membuat perasaan sulit.

Alasan mengapa secara jelas dinyatakan di atas: manajemen berpikir dalam uang; atau lebih khusus lagi: pendapatan. Bagi mereka sesuatu yang memiliki biaya tetapi tidak ada visibilitas langsung ke pelanggan tidak menambah pendapatan jadi itu rencana yang buruk.

Visi Anda juga benar: itu akan baik untuk pelanggan tetapi dalam jangka panjang. Tindakan Anda mungkin menghasilkan pendapatan yang lebih besar di masa depan dibandingkan dengan rencana jangka pendek.

Anda bukan manajer, Anda bukan orang yang langsung bertanggung jawab atas pendapatan (saya berasumsi tentu saja). Jadi Anda mencampuradukkan (itulah yang terasa bagi manajemen) dengan masalah mereka dan Anda tidak fokus pada pekerjaan Anda: memperluas perangkat lunak lebih lanjut.

Semua kata-kata yang keras dan jelas tetapi itulah sebabnya sebagian besar masalah muncul, karena kesalahan komunikasi. Anda berdua menginginkan hal yang sama tetapi keputusan jangka pendek Anda dibuat secara berbeda. Semua itu karena pengembang memiliki pandangan yang berbeda dibandingkan dengan manajer.

Bagaimana Anda mengatasi masalah ini? Anda berkomunikasi dan memahami satu sama lain dengan baik pada sejumlah masalah. Itu akan menjadi fokus pada keterlibatan dan kepuasan pelanggan.

Untuk mengatasi masalah ini dalam metode bukti yang stabil dan di masa mendatang, sepakati beberapa hal: ukur biaya perbaikan bug dalam kode lama. Ukur waktu yang dibutuhkan tambahan untuk bekerja dengan perangkat lunak lama dan bagaimana jadinya dengan basis kode baru.

Untuk membuktikan ini, Anda bisa melakukan contohnya hal yang cukup sederhana ini: percabangkan perangkat lunak dalam versi Anda. Pertama lakukan apa yang diinginkan manajemen, jadi buat fitur itu. Anda melakukan ini tetapi perjanjiannya adalah Anda mendapatkan waktu untuk menunjukkan cara yang berbeda. Kemudian lakukan hal yang sama di branche baru tetapi pertama-tama perbaiki masalah yang ingin Anda singkirkan. Kemudian juga kembangkan solusinya.

Sekarang Anda memiliki solusi yang sama tetapi benar-benar dikembangkan secara berbeda. Buat kasus dari itu, letakkan solusi di samping satu sama lain termasuk beberapa info manajemen seperti stabilitas, jumlah kode yang diperlukan dan kode itu sendiri.

Sekarang ambil kopi bersama dan mulailah melihatnya, tidak berdebat siapa yang benar tetapi apa yang akan menjadi pengaruh kedua arah bagi perusahaan. Itu akan membuat pertemuan yang benar-benar bermanfaat dan bukan diskusi yang lebih baik-buruk karena itu tidak akan menghasilkan suasana yang Anda berdua butuhkan. Itu tidak akan membuat produk Anda lebih baik.

Jika Anda memiliki tinjauan kode, buat tiket teknis yang menyatakan bahwa kode harus ditingkatkan dengan menggunakan ARC dan tetapkan ke manajer.

Yakinkan dia. Jelaskan kepadanya beberapa contoh kecil peningkatan teknis serupa yang Anda lakukan dan manfaatnya bagi proyek.

Anda harus menjual perubahan itu dengan satu-satunya cara yang bersedia dibeli oleh manajemen:

Temukan fitur yang dihadapi pengguna sehingga menarik bahwa manajemen hanya perlu memilikinya, tetapi tidak mungkin dilakukan tanpa perbaikan tingkat rendah dalam kode.

Adalah tugas atasan Anda untuk memastikan perusahaan memfokuskan pengembangan pada penyampaian apa yang dirasakan klien sebagai nilai tambah. Ada dua faktor yang dapat mengubah persepsi ini:

1. Berapa lama untuk memenuhi permintaan klien?
2. Apakah Anda memberikan ketika Anda mengatakan akan melakukannya?

Sebagian besar lebih suka Anda mengatakan akan memakan waktu 6 minggu dan mengirimkan dalam 5 daripada mengatakan Anda akan mengirimkan dalam 3 tetapi mengambil 4.

Memiliki basis kode saat ini yang lebih mudah untuk dikelola dan ditingkatkan memungkinkan Anda untuk memberikan hasil yang lebih cepat dan dapat diprediksi. Jika Anda menghabiskan terlalu banyak waktu untuk perbaikan bug, Anda memiliki lebih sedikit sumber daya yang tersedia untuk menambahkan fitur baru. Mengevaluasi jumlah sumber daya yang dihabiskan untuk memperbaiki kode dan seberapa akurat Anda pada janji fitur. Ini satu cara untuk menentukan apakah kode Anda saat ini (berdasarkan filosofi atasan Anda) terlalu mahal.

Biarkan saya memberi tahu Anda tentang peluang $ 2 miliar yang hampir lolos dari tangan kami karena kelambanan manajemen.

Beberapa dari kita memiliki titik mendengarkan suara pelanggan, yang berarti memahami apa yang diinginkannya. Tidak selalu apa yang dia minta, tetapi jika Anda berada dalam posisi untuk melakukan percakapan dengan pelanggan Anda, pada akhirnya Anda akan saling memahami apa yang dia inginkan. (Kemudian dia bisa secara eksplisit mulai memintanya.)

Karena itu, penting untuk memahami siapa yang harus melakukan percakapan dengan pelanggan. Anda biasanya memiliki orang-orang pengembangan bisnis Anda bersama dengan beberapa desainer utama melakukan ini. Jika Anda memiliki persaingan, Anda dapat berharap bahwa pelanggan juga memiliki percakapan ini.

Pada saat yang sama, penting bagi pengembang untuk terus mengikuti perkembangan di bidangnya, karena akan ada kompetisi yang akan mengalahkan Anda jika Anda tidak.

Dalam situasi kami, kami memiliki pelanggan yang sudah ada, dan produk yang agak efektif berdasarkan teknologi lama, dan pelanggan membutuhkan peningkatan cepat. Apa yang benar-benar mereka butuhkan adalah produk pengganti yang lengkap, tetapi pola pikir di perusahaan kami adalah bahwa ini akan segera memaksa kami ke posisi kompetitif, sedangkan memodifikasi produk yang ada memungkinkan pelanggan kami untuk terus bersama kami tanpa secara hukum diminta untuk membuatnya kompetitif. Manajemen kami mengira mereka memiliki pasar ini. Masalahnya adalah mereka tidak bisa mengikuti permintaan upgrade, karena struktur produk yang ada tidak cukup fleksibel untuk ditingkatkan.

Pelanggan menjadi tidak sabar dan mulai berbicara dengan sumber yang bersaing. Kami kehilangan "kepemilikan" kami atas pasar itu dan pendapatan beberapa miliar dolar. Namun, begitu pasar memaksa kami ke posisi kompetitif, manajemen tidak punya pilihan selain keluar dari bisnis atau bersaing. (Sebagian besar yang menjadi penghalang jalan akhirnya dipecat.) Kami berkompetisi, dan mampu merebut kembali bisnis dengan benang yang paling tipis.

Saya katakan di awal bahwa kesempatan ini hampir saja lolos dari tangan kami. Kami mendapatkan bisnis kembali, untuk pendapatan yang saya sebutkan. Jika kami lebih siap untuk beradaptasi dengan masalah pelanggan pada awalnya, tidak akan ada persaingan nyata.

Yang saya tawarkan adalah: Selalu mencoba untuk tetap terdepan dalam kemampuan pribadi Anda. Selalu kembangkan produk yang fleksibel dan dapat diadaptasi dengan cepat sesuai dengan kebutuhan pelanggan Anda. Jika Anda bekerja terlalu lama untuk perusahaan yang tidak berpikir seperti ini, Anda akan layu, dan motivasi pribadi Anda akan berkurang. Saya telah melihatnya terjadi.

Ketika Anda memiliki ide untuk meningkatkan produk Anda untuk alasan apa pun, tanyakan pada diri sendiri pertanyaan-pertanyaan ini: - Apakah ini yang menurut saya diinginkan pelanggan? Bisakah saya memvalidasi pemikiran saya tentang pengembangan produk terhadap suara pelanggan? Apakah perusahaan saya dalam posisi untuk memenuhi kebutuhan pelanggan? Jika ya, bagaimana caranya? - Anda kemudian harus berada dalam posisi untuk membuat kasus persuasif mengenai proposal pengembangan produk Anda.

Bahasa umum bisnis di semua bidang dan industri adalah uang. Masalah yang Anda gambarkan bukan masalah pemrograman: ini adalah masalah bisnis. Jika Anda ingin mendapatkan respons yang sesuai dengan proposisi bisnis, Anda perlu membingkainya dalam bahasa bisnis. Ini berarti bahwa Anda harus dapat mempresentasikan rencana proyek alternatif termasuk semua biaya dan manfaat.

Anda perlu belajar tentang hal-hal seperti biaya peluang, ROI (laba atas investasi), dan NPV (nilai sekarang bersih). Anda tidak memerlukan gelar MBA untuk melakukan ini, tetapi Anda membutuhkan akses ke data yang mungkin tidak tersedia untuk Anda, seperti biaya tenaga kerja, biaya overhead, dan potensi pendapatan. Jika Anda dapat membuat argumen yang jelas bahwa satu jalur akan memberikan nilai lebih dari yang lain menggunakan angka keras, Anda akan mendapatkan perhatian penuh dari manajemen.

Ketika saya adalah pengembang baru di tim yang sangat kecil, saya melakukan banyak perbaikan semacam ini di waktu luang saya. Saya menikmatinya; Saya akan masuk dan mencoba teknik baru yang menarik sambil duduk di ruang tamu bersama istri saya di malam hari. Ketika saya menjadi pengembang yang lebih senior dan kemudian manajer tim yang lebih besar, waktu luang saya hilang. Kami bekerja lembur hanya untuk menyelesaikan fitur dan perbaikan kritis. Menjadi sangat sulit untuk membenarkan menghabiskan waktu siapa pun untuk pekerjaan rumah tangga biasa itu, meskipun kita semua tahu betapa pentingnya hal itu.

Atasan Anda tidak perlu penjelasan tentang betapa pentingnya, untuk menekan biaya perawatan, mengurangi biaya pertumbuhan di masa depan, melibatkan tim pengembangan yang berbakat, dll. Jika ya, Anda memiliki masalah besar. Namun, yang mereka butuhkan adalah rencana. Karena saat ini saya menduga bahwa mereka memiliki segala macam rencana, jadwal, peta jalan, janji, dan tekanan pada sisi "tambah fungsionalitas", yang bersaing melawan angan-angan belaka dan permintaan terbuka dari tim pengembang.

Satu hal yang bisa Anda coba adalah membuat rencana yang terdokumentasi. Lihat apakah Anda dapat mengikatnya untuk rilis, atau untuk keluar kriteria untuk fungsionalitas baru. Permintaan untuk "menghabiskan waktu mengulang penghitungan referensi" mungkin sulit untuk disetujui bos Anda, tetapi menjadwalkan blok waktu 5 hari 4 minggu dari sekarang mungkin lebih mudah. Pada dasarnya, bagaimanapun Anda melihat bahwa fitur-fitur baru direncanakan dan dijadwalkan, cobalah untuk menirunya, atau menyuntikkan bagian "di bawah tenda" ke dalamnya.

Mulailah dari yang kecil dengan meminta 5% waktu yang dialokasikan untuk jenis barang itu, dan kemudian secara bertahap membangun prioritas roadmap teknologi Anda sendiri, dan terus berusaha keras untuk membenarkan kasus bisnis, ROI, tingkat risiko, dll. Pada masing-masingnya. Dalam waktu dekat, Anda bahkan akan merasakan tantangan bos Anda, karena Anda akan dengan cepat menemukan lebih banyak ide hebat daripada waktu yang dapat Anda lakukan.

Semoga berhasil!

Inilah mengapa permintaan Anda untuk penghitungan referensi otomatis ditolak:

1. Itu bukan perbaikan . Setelah Anda memiliki sesuatu yang lebih besar dari hello world, perubahan apa pun akan mengarah ke arah yang salah. Tidak ada jumlah refactoring yang akan mengubah fakta bahwa jika Anda perlu melakukan perubahan, itu akan selalu salah arah. Kuncinya adalah mengetahui kapan perubahan Anda cukup signifikan sehingga masih layak risiko menyebabkan masalah baru. Manajemen Anda telah dengan jelas mengatakan bahwa jika pengguna akhir tidak dapat melihatnya, itu tidak sebanding dengan risikonya.
2. Penghitungan referensi adalah fitur yang benar-benar gila. Anda melihat beberapa perusahaan besar terkenal yang menerapkan beberapa fitur, dan segera berpikir bahwa Anda memerlukan fitur yang sama. Yah, sangat mungkin basis kode Anda benar-benar berbeda dari yang digunakan apel. Mungkin penghitungan referensi tidak akan berhasil, atau itu hanya buang-buang waktu. Anda harus menemukan cara lain yang tidak memerlukan penyebaran primitif penghitungan referensi di mana pun dalam kode Anda. Mungkin rencana penghitungan ulang Anda membutuhkan ribuan modifikasi dalam basis kode, sebagian besar perubahan itu tidak diperlukan. Buang-buang waktu dan uang saja.
3. Anda sedang memecahkan masalah yang salah. Manajemen biasanya tahu masalah apa yang ada dalam sistem. Beberapa masalah kebocoran memori yang tidak relevan yang diselesaikan oleh solusi penghitungan ulang bukanlah salah satunya. Fokus pada masalah nyata dan bukan masalah imajiner dengan cara komputer menangani memori.
4. Diperlukan waktu terlalu lama untuk mengimplementasikannya. Apple adalah perusahaan yang sedikit lebih besar daripada tim tidak penting Anda dengan beberapa programmer dan beberapa manajer. Mereka dapat melakukan perubahan besar hanya dengan membayar harganya. Jika dibutuhkan beberapa juta untuk mengimplementasikan sesuatu, itu adalah kacang. Jika perusahaan kecil mencoba melakukan hal yang sama, mereka akan kehabisan uang dengan cepat. Pengembangan perangkat lunak sudah sangat mahal; menambahkan biaya yang tidak perlu tidak akan membantu sedikit pun. Salah satu fitur yang tidak relevan seperti manajemen memori akan membuka pintu banjir: setelah mereka menyetujuinya, setengah programmer Anda ingin "perbaikan" mereka sendiri diimplementasikan. Ini adalah kisah yang tidak pernah berakhir dan perusahaan dapat melakukan sesuatu yang bermanfaat sebagai gantinya.

Berikut beberapa langkah yang dapat Anda gunakan untuk menangani masalah:

1. Jatuhkan fitur
2. Cari tahu apa masalah sebenarnya
3. Mulailah melakukan sesuatu yang bermanfaat
4. Rencanakan dengan cermat bagaimana Anda menggunakan waktu Anda
5. Cari tahu bagaimana perbaikan Anda menghasilkan uang
6. Pilih hanya fitur yang menghasilkan uang paling banyak
7. Sadarilah bahwa aspek pemrograman dari pengembangan perangkat lunak hanya sebagian kecil dari keseluruhan sistem - perbaikan tidak akan sepadan dengan waktu