Apa yang harus dilakukan sebagai seorang Dev ketika selama bertahun-tahun tim mereka kekurangan inovasi produk, tidak menggunakan metodologi manajemen proyek, dan menjalankan praktik-praktik Dev Software yang buruk? [Tutup]

Saya tertarik mengetahui cara menangani proses pengembangan perangkat lunak saat ini yang belum berubah selama bertahun-tahun dan pada akhirnya akan menyebabkan kegagalan produk dan tim. Ya, mungkin cara yang lebih mudah untuk menyelesaikan ini adalah mengubah pekerjaan, tetapi dengan ekonomi ini lebih mudah dikatakan daripada dilakukan. Namun, jika Anda memiliki contoh spesifik dan telah melihat atau berkali-kali dalam situasi yang sama dan berpikir bahwa solusi terbaik untuk mengatasi masalah ini, adalah meninggalkan perusahaan, maka tolong dukung jawaban Anda. Intinya adalah, pertanyaan ini benar-benar memiliki jawaban terutama jika banyak ahli pada subjek akhirnya menunjukkan bahwa rute terbaik untuk pergi adalah: rute A.

Saya tahu banyak pengembang telah atau dalam situasi yang sama. Ini adalah salah satu alasan utama mengapa perusahaan berubah dari menjadi # 1 di pasar mereka menjadi yang terakhir atau bahkan keluar dari pasar. Semoga jawaban dalam posting ini akan membantu pengembang lain menghadapi hambatan serupa. Dalam tim pengembangan kecil atau besar ini biasanya terjadi:

• Beberapa pengembang tampaknya tidak peduli dan memutuskan untuk mengikuti arus dan lebih memilih untuk meninggalkan kode dengan banyak kode yang berbau seperti itu dan proses pengembangan apa adanya,
• Yang lain bosan tanpa perubahan dan mengundurkan diri dan pindah ke perusahaan lain,
• Yang lain tampaknya takut untuk berbicara dan lebih suka diam,
• Terkadang sangat sedikit pengembang atau hanya satu yang mencoba berbicara untuk peningkatan produk, dan memberi tahu tim betapa pentingnya untuk mengikuti praktik pengkodean terbaik dan manfaat melakukannya bagi klien, pengguna, dan tim. Jenis pengembang ini biasanya memutuskan untuk tetap bersama tim karena alasan seperti perusahaan menawarkan manfaat yang sangat sedikit yang ditawarkan perusahaan perangkat lunak, atau produk memiliki banyak potensi, dll.

Produk dalam tim kami hanyalah sebagian kecil dari tempat perusahaan memperoleh pendapatan karena memiliki payung produk (perusahaan ini bukan perusahaan perangkat lunak / perangkat keras; oleh karena itu, tidak ada litigasi paten yang konstan, setidaknya untuk saat ini, yang menciptakan pekerjaan ketidakstabilan). Apa yang telah saya pelajari sejauh ini selama bertahun-tahun dari pengalaman pengembang lain dan pengalaman saya adalah bahwa untuk benar-benar mengenal tim pengembangan, dibutuhkan waktu, bukan hari, atau minggu, tetapi beberapa bulan. Selama proses wawancara jika tim ingin mempekerjakan Anda, atau membutuhkan Anda; mereka membuat semuanya terdengar hebat, dan mereka mungkin memberi tahu Anda apa yang ingin Anda dengar. Namun, kenyataannya berbeda ketika Anda mulai bekerja di tim itu dan mulai menggali di dalam kode dan bergerak menuju proses SDLC lengkap. Saat inilah sebagai pengembang, Anda mulai melihat kenyataan pekerjaan yang Anda hadapi. Kenyataan ini membuat sulit untuk ingin pindah dari satu perusahaan ke perusahaan lain karena sulit untuk mengetahui apakah perusahaan tempat Anda pindah akan lebih baik atau lebih buruk. Ya, Anda dapat membaca ulasan Glassdoor dll., Tetapi berapa banyak ulasan online yang nyata, dan bukan dari HR?

Apa cara terbaik untuk mengatasi masalah yang diuraikan di bawah ini dengan mempertimbangkan bahwa manajer sejak awal selalu menolak untuk berubah, dan pengembang sebelumnya telah melakukan hal yang sama selama bertahun-tahun?

• Kurangnya inovasi produk selama bertahun-tahun: Produk memiliki banyak potensi dan membawa pendapatan yang baik bagi perusahaan, tetapi produk sepertinya dibuat 20 tahun lalu. Beberapa pengguna mengeluh bahwa produk tersebut tidak ramah pengguna atau intuitif, dan yang lain menyebutkan bahwa digunakan untuk aplikasi seperti Gmail dan merasa frustrasi ketika menggunakan produk karena tidak memiliki fitur yang sama. Masalah utama di sini adalah ketika Anda mencoba sebagai pengembang untuk membuat perubahan pada produk dan mulai memindahkan elemen utama produk sekitar hanya beberapa piksel jauhnya (agar lebih ramah pengguna, atau intuitif), manajer panik, dan memberi tahu Anda untuk meletakkannya kembali di tempat itu. Jika Anda mencoba menambahkan fitur yang akan menguntungkan produktivitas bagi pengguna, manajer meminta Anda untuk menghapusnya karena "pengguna terbiasa melakukan prosesnya seperti itu dll." Saya pikir Anda memiliki titik penolakan terhadap perubahan, peningkatan, dan inovasi (manajer tidak terbuka untuk berubah, bahkan ketika Anda sebagai pengembang memberikan argumen kuat tentang manfaat). Perusahaan memiliki beberapa pesaing di lapangan (produk beberapa dari mereka jauh lebih kompetitif), tetapi entah bagaimana perusahaan telah mempertahankan klien saat ini selama bertahun-tahun.

• Kurangnya koordinasi manajemen proyek: Akibatnya, beberapa proyek terlambat dikirim, dengan bug dan beberapa klien mengeluh (klien melaporkan bug juga), atau anggaran digunakan terlalu cepat sebelum mengirimkan proyek dll. Saya sudah menyediakannya beberapa tip koordinasi proyek dan ide-ide sekarang digunakan secara teratur untuk melacak kemajuan proyek dan tugas yang harus dilakukan.

• Praktek Pengembangan Perangkat Lunak yang buruk: Bau kode terlihat pada sebagian besar, jika tidak semua file, tidak ada dokumentasi, redundansi kode, front end tier dan back end dicampur pada file yang sama, alat pengembangan yang sudah ketinggalan zaman, tidak ada lingkungan pengujian nyata atau alat uji (cukup salin dan tempel file dari lingkungan dev ke produksi, dan kemudian uji secara manual bahwa semuanya terlihat baik dan dirilis). Sebagian besar alat pengembangan yang saya gunakan untuk pengembangan dan pengujian di mana tidak diketahui oleh tim, karena tim hanya menggunakan 2 IDE untuk pengembangan kode dan kontrol sumber hanya tersedia untuk lingkungan pengembangan. Pengembang lain telah mencoba menggunakan kerangka kerja terbaru untuk memperbaiki masalah saat ini, tetapi manajer tidak menyukainya karena "bagaimana jika Anda pergi, lalu siapa yang akan mempertahankan kode itu ?, biarkan saja seperti itu" Beberapa pengembang sudah kiri dan pindah ke perusahaan lain.

Singkatnya, saya yakin situasi serupa terjadi pada banyak pengembang di perusahaan lain tetapi karena keadaan yang berbeda, pengembang mungkin lebih suka tetap di tim daripada pergi ke perusahaan lain karena alasan seperti (kenyamanan pekerjaan, fleksibilitas kerja, manfaat perusahaan, atau hanya karena kesempatan yang lebih baik belum tiba). Tidak ada perusahaan yang sempurna yang saya tahu, tetapi bagaimana Anda sebagai pengembang berperilaku dan mendekati semua masalah ini untuk menjaga hal-hal positif dan pada akhirnya mempromosikan perubahan untuk peningkatan produk dan perbaikan proses pengembangan perangkat lunak (apakah Anda memiliki banyak tahun pengalaman pembangunan atau hanya beberapa)? Saya tahu posting ini panjang, tetapi saya lebih suka memberikan detail ekstra untuk meningkatkan peluang mendapatkan umpan balik yang lebih bermanfaat.

Terima kasih banyak atas semua tanggapan dan waktu Anda

Kutipan Martin Fowler relevan: "Anda dapat mengubah organisasi Anda atau mengubah organisasi Anda." Mengingat Anda telah memutuskan untuk mengubah organisasi (menjadikannya lebih baik) alih-alih mengubah organisasi (bekerja untuk organisasi lain), berikut adalah beberapa saran.

Pertama, banyak tindakan Anda tergantung pada perincian tentang struktur kekuasaan dan politik di tempat kerja. Apakah ada satu manajer pengembangan perangkat lunak, atau beberapa? Jika beberapa, apakah ada dari mereka yang tidak menolak perubahan? Ada berapa banyak pengembang perangkat lunak? Apakah pengembang tertarik untuk berubah? Jika demikian, ada beberapa perubahan yang harus Anda lakukan walaupun tanpa persetujuan manajemen. (Seperti yang disarankan Fowler dalam Refactoring , Anda mungkin bahkan tidak perlu memberi tahu manajemen. Anda mungkin disewa untuk mengembangkan perangkat lunak sebaik mungkin, jadi jika ada cara yang lebih baik untuk melakukannya, maka lakukan saja.)

Kedua, perlu diingat bahwa manajemen mungkin memiliki alasan bagus untuk apa yang mereka lakukan. Anda seorang pengembang perangkat lunak; tugas Anda adalah mengembangkan perangkat lunak yang baik dan mengetahui teknik yang baik untuk melakukannya. Tugas manajemen adalah memahami masalah gambaran yang lebih besar dan pertimbangan bisnis yang mungkin berada di luar jangkauan Anda. Bahkan jika Anda benar dan mereka salah tentang pertimbangan bisnis (kekhawatiran Anda tentang kurangnya inovasi, keterlambatan pengiriman, keluhan pelanggan, dll.), Memahami dari mana manajemen berasal akan membantu Anda berkomunikasi dengan persyaratan mereka, meringankan keprihatinan mereka, dan sebagainya.

Ketiga (dan terkait), pastikan Anda dapat berbicara dalam bahasa bisnis. Suatu bisnis (benar) tidak secara langsung peduli dengan praktik pengembangan perangkat lunak yang baik; bisnis berkaitan dengan melayani kebutuhan pelanggan dan menghasilkan keuntungan. (Dan banyak bisnis jelas akan melakukan kebutuhan minimum yang memungkinkan untuk menghasilkan keuntungan.) Anda akan lebih efektif dalam mempromosikan perubahan jika Anda dapat menjelaskan bagaimana praktik pengembangan perangkat lunak yang buruk dan kurangnya inovasi akan merusak laba perusahaan atau jangka panjang kesehatan.

Keempat, mengubah budaya perusahaan dari posisi pekerja pangkat sangat sulit. James Shore (seorang konsultan dan penulis yang gesit) menulis Change Diary yang menggambarkan usahanya sendiri dalam melakukan hal itu. Saya sangat merekomendasikan membaca semuanya. Beberapa poin yang relevan:

• Jangan mencoba mengubah semuanya sekaligus. Temukan titik sakit terbesar dan mulailah dari sana. Dapatkan semua orang di papan dengan membantu mereka untuk melihat bagaimana perubahan Anda mengatasi titik sakit tersebut.
• Memahami perspektif orang lain. Shore berbicara tentang bagaimana perubahan yang dia dorong dari perspektif pengembangan perangkat lunak ditentang oleh manajer proyek karena dia (Shore) gagal mempertimbangkan bagaimana perubahan itu akan mempengaruhi manajer proyek.
• Pada akhirnya, Anda akan memerlukan beberapa dukungan dari tingkat yang lebih tinggi, bahkan jika Anda sendiri yang meminta sebagian besar perubahan. Shore berbicara tentang jagoannya ("seseorang yang bekerja dengan saya yang memiliki pengaruh lebih daripada saya dan berpikir secara umum seperti saya").

Jawaban singkat yang jelas adalah meninggalkan perusahaan. Yang lain sudah pergi, dan manajer Anda adalah penghalang aktif untuk maju. Jika Anda tetap pada posisi itu, Anda akan perlahan membusuk (baik dalam moral maupun keterampilan). Mencari pekerjaan baru tidak selalu mudah, tetapi dalam hal ini perlu.

Kalau-kalau Anda memilih untuk tidak meninggalkan perusahaan (baris pertama dari jenis pertanyaan Anda memberikan itu):

Apakah manajer Anda punya bos? Jika demikian, bagaimana bos itu melihat produk? Bisakah Anda (berani saya mengatakannya?) Melewati kepala manajer Anda dan mendekati bosnya? Jangan mengomelinya dengan detail teknis, cukup ungkapkan minat dan antusiasme untuk tumbuh dalam perusahaan. Sajikan ide nyata untuk perbaikan yang secara terukur akan mempengaruhi garis bawah. Anda mungkin dipromosikan keluar dari bawah rintangan.

Berhati-hatilah - sementara beberapa roda berderit diminyaki, yang lain diganti. Anda AKAN menyebabkan manajer Anda sangat tidak menyukai Anda. Dia akan mendengar tentang ini, dan dia akan mengatakan hal-hal buruk tentang Anda kepada bosnya. Tapak hati-hati, tapi ingat - tidak ada risiko, tidak ada hadiah.

Yang terburuk yang mungkin terjadi adalah Anda akan mencari pekerjaan baru, yang seharusnya Anda lakukan.

Sepertinya sudah waktunya bagi Anda untuk belajar tentang sapi perah. Buka di sini dan di sini . Dan lihatlah Growth Share Matrix . GSM memberikan beberapa informasi tambahan tentang mengapa uang tunai dalam keadaan baik.

Investopedia (tautan kedua) mungkin memiliki penawaran terbaik dalam hal ini.

1. Sapi perah membutuhkan sedikit modal investasi dan secara terus-menerus memberikan arus kas positif, yang dapat dialokasikan ke divisi lain dalam korporasi. Generator uang tunai ini juga dapat menggunakan uang mereka untuk membeli kembali saham di pasar atau membayar dividen kepada pemegang saham.

Seperti yang Anda catat, ada beberapa sisi negatif dari proyek cash-cow.

• Itu stabil
• Tingkat perkembangan baru yang sederhana dijamin
• Selalu ada perbaikan untuk mengatasi bug.

Dan seperti yang Anda catat, ada beberapa kerugian dari proyek-proyek itu.

• Itu stabil dan basis kode tidak banyak berubah
• Teknologi baru umumnya diabaikan (terlalu mahal untuk dikunci)
• Dan segalanya menjadi ... basi.

Saya pernah mengerjakan sebuah proyek di mana saya memiliki banyak keluhan serupa dengan apa yang Anda ajukan. Saya ingat dengan jelas berbagi keprihatinan saya tentang basis kode dengan bos saya saat itu. Wawasannya tidak terlalu mencerahkan sehingga saya tidak akan membagikannya. Tapi saya menghentikan proyek dan jujur, itu adalah salah satu proyek yang lebih baik yang pernah saya lihat. Tidak, itu tidak mencolok. Ya, kami melewatkan tenggat waktu. Ya, saya memulai beberapa mars kematian dari sana. Tidak, teknologi kode tidak terlalu inovatif tetapi kami menghasilkan beberapa solusi luar biasa.

Masalahnya adalah saya. Saya tidak memiliki perspektif yang cukup untuk memahami apa yang sebenarnya dibutuhkan oleh basis kode untuk bertahan hidup. Saya tidak memiliki pengalaman untuk melihat di mana inovasi itu benar-benar terjadi. Saya tidak mengerti dasar-dasar pasar yang menentukan tingkat pendanaan yang sesuai untuk proyek cash-cow itu.

Saya akan mendorong Anda untuk melihat ini sebagai kesempatan belajar untuk lebih memahami bagaimana bisnis berjalan dan bagaimana Anda dapat meningkatkan keterampilan Anda dalam mengadaptasi produk dengan kebutuhan bisnis. Meskipun pekerjaannya mungkin tidak mencolok, potensi belajarnya tinggi dan keterampilan itu akan membantu Anda di masa depan dalam karier Anda. Mayoritas pengembangan tingkat perusahaan berkisar pada semua kendala yang baru saja Anda sebutkan. Kode itu bau; hal-hal ditampar di tempat untuk mengandung tenggat waktu yang sudah lolos; banyak pengembang yang menolak untuk berubah.

Pada titik tertentu, Anda masih akan pindah dari proyek. Pelajaran yang dapat Anda ambil dengan Anda bisa menjadi pelajaran membuat karier nyata.

Manajer Anda mungkin menolak untuk berubah karena dia melihat tidak ada nilai (bisnis) yang mengubah praktik. Bisnis tidak melihat masalah nyata karena apa pun yang diminta dari tim pengembangan akhirnya diselesaikan dan keluhan klien tidak sampai ke orang yang peduli dan / atau dapat melakukan sesuatu untuk memastikan hasil yang lebih baik. Entah itu atau bisnis telah datang untuk menerima keadaan saat ini sebagai tidak dapat dihindari.

Jika Anda akan mengubah praktik pembangunan, Anda harus menunjukkan kepada mereka bahwa keadaan saat ini tidak dapat dihindari. Dan satu-satunya cara Anda akan didengar adalah dengan membangun kasus bisnis yang menunjukkan bagaimana keadaan saat ini menghabiskan biaya produk dan menahan potensi pendapatan mengingat keadaan lain.

Untuk membangun kasing bisnis itu, Anda perlu berbicara dengan manajer produk perangkat lunak ini. Manajer produk menjadi orang yang memutuskan prioritas barang yang akan dikembangkan berdasarkan nilai bisnis yang diwakilinya. Manajer produk adalah (harus) yang dapat melihat manfaat dan nilai bisnis untuk dapat membangun perangkat lunak yang lebih baik dengan lebih cepat. (Dan saya berharap itu tidak sama dengan yang bertanggung jawab atas tim pengembangan.)

Kasus bisnis perlu membahas apa pengaruhnya terhadap pendapatan bisnis dari:

• Fitur yang belum (belum) diterapkan akan menghasilkan lebih banyak pelanggan atau mempertahankan lebih banyak pelanggan seandainya mereka diimplementasikan.
• Fitur yang tidak diimplementasikan secara memadai yang menghasilkan ketidakpuasan pelanggan dan menyebabkan gesekan pada pelanggan.

Kasus bisnis juga perlu menunjukkan bagaimana praktik pengembangan saat ini memengaruhi kecepatan dan biaya pengembangan fitur yang sangat dibutuhkan:

• Berapa lama yang dibutuhkan untuk membuat perubahan yang paling sederhana sekalipun.
• Berapa banyak bug yang diperkenalkan sebagai hasil pengembangan fitur baru, baik pada fitur baru maupun kerusakan jaminan pada fitur lainnya.
• Berapa banyak waktu yang dihabiskan untuk memperbaiki bug ini yang tidak dapat dihabiskan untuk mengimplementasikan fitur baru.
• Berapa banyak panggilan dukungan yang dihasilkan karena bug ini dan berapa banyak staf dukungan yang perlu dihabiskan untuk panggilan ini.

Dan tentu saja perlu menunjukkan bagaimana mengadopsi praktik pembangunan yang lebih baik akan mempengaruhi angka-angka ini.

Anda mungkin menghadapi kebutuhan untuk menulis ulang bagian-bagian perangkat lunak (utama). Sekalipun Anda tidak, maka Cara Bertahan dari Menulis Ulang Tanpa Kehilangan Kearifan Anda harus dibaca dalam cara mendekati proyek-proyek semacam ini.

Catatan akhir: jika manajer produk tidak tertarik dengan semua ini, Anda hilang: lompat kapal.

Saya pikir ini adalah masalah yang sangat sulit tanpa solusi langsung. Berikut adalah beberapa ide tentang apa yang mungkin Anda coba lakukan:

Ketakutan akan Perubahan Mengenai masalah mengubah sesuatu menjadi lebih baik saya mengerti mengapa ketakutan manajemen berubah. Orang-orang terbiasa dengan hal-hal dengan cara tertentu dan jika Anda mengubahnya, pengguna akan memberontak (mungkin). Perubahan adalah hal yang menakutkan dan biasanya membutuhkan banyak pemikiran dan studi sebelum dilakukan. Yang Anda butuhkan adalah data untuk menunjukkan bahwa ini lebih baik dan yang diinginkan pengguna. Berbicara tentang gmail, Anda mungkin ingin melakukan sesuatu seperti "Google Labs" tempat Anda dapat mengaktifkan / menonaktifkan fitur baru sehingga pengguna dapat mencobanya. Kemudian hubungkan beberapa pengumpulan data di sekitar ini untuk membantu mencadangkan perubahan Anda.

Mengubah Proses Pengembangan Perangkat Lunak Sekali lagi perubahan itu sulit, orang tidak hanya berubah karena Anda mengatakan ada cara yang lebih baik. Saya pikir dalam skenario ini, rekomendasi terbaik saya adalah memimpin dengan memberi contoh. Lakukan hal-hal dengan cara yang Anda inginkan agar dilakukan dan tunjukkan pada orang-orang betapa lebih baik itu. Juga, dan ini kuncinya, Anda perlu menemukan orang lain yang berbagi pemikiran Anda. Jika Anda bisa mendapatkan beberapa orang, itu akan sangat membantu perjuangan Anda. Setelah Anda dapat menunjukkan beberapa hasil maka Anda dapat mendekati manajemen tentang membuat perubahan ini lebih luas. Saya menemukan bahwa upaya dari atas ke bawah dan akar rumput benar-benar membantu dalam membuat perubahan.

Juga di sisi alat perusahaan takut meningkatkan / mengubah ini karena biayanya mahal dan hasil dari alat baru tidak selalu dapat diukur. Rekomendasi saya di sini adalah membuat alat sendiri. Jika Anda membuatnya sendiri, Anda akan menghemat waktu dan melakukan pekerjaan dengan lebih baik. Semoga orang-orang mulai memperhatikan dan kemudian ingin menggunakannya juga.

Mengubah manajemen Ini sulit dan saya tidak yakin bagaimana melakukannya selain menjadi seseorang yang menghasilkan hasil dan pendapat mereka dihargai. Begitu pendapat Anda dihargai, orang-orang mungkin mulai mendengarkan atau tidak.

Terakhir, ingat perubahan itu sulit dan butuh waktu. Bertahanlah dan mulailah dari yang kecil dan bangun.