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