Apakah proses tim saya di luar kendali?

Saya seorang pemimpin tim pengembang perangkat lunak (saya baru-baru ini mengendalikan tim baru), dan pada akhirnya bertanggung jawab untuk mempertahankan produktivitas tinggi, kualitas yang baik, dan prioritas yang terorganisir.

Saya memiliki 6 pengembang senior di tim saya, tetapi semuanya terasa berantakan di sini. Situasinya adalah saya harus berurusan dengan permintaan JIRA dari sekitar 10 titik kontak di perusahaan kami, dan semuanya mewakili unit bisnis, atau klien yang berbeda.

Masalah yang saya miliki adalah bahwa pekerjaan saya terutama terdiri dari memadamkan api sepanjang hari dan memastikan bahwa semua masalah sedang dikerjakan. Sayangnya, budaya di perusahaan kami memiliki produktivitas tinggi (rilis cepat) tetapi berkualitas rendah (bug produksi), dan klien kami tidak akan menerima penundaan hasil yang tiba-tiba.

Apa beberapa cara yang baik untuk menangani ini? Saya punya banyak teori, tapi saya mencari jawaban dari seseorang yang benar-benar memiliki pengalaman bekerja dalam situasi seperti saya.

Berikut adalah daftar kecil cara kerja:

• Setiap pengembang bertanggung jawab atas aplikasi dan layanan spesifik yang berinteraksi dengannya;
• Rilis biasanya diuji oleh klien di server produksi yang disimulasikan, dan kemudian digunakan untuk server langsung;
• Setiap aplikasi digunakan oleh rata-rata 50-80 orang, dengan total 8 aplikasi.

Terima kasih

klien kami tidak akan menerima penundaan hasil yang tiba-tiba

Maka, mereka harus menerima kualitas buruk yang mereka dapatkan.

Apa yang harus Anda lakukan untuk mengubah ini adalah membuat klien Anda menerima kenyataan pengembangan perangkat lunak (atau produksi lainnya!): Bahwa hal-hal yang terburu-buru mempengaruhi kualitas.

Buat daftar besar hal-hal yang salah - hal-hal yang rusak, waktu yang mereka punya alasan untuk mengeluh. Jelaskan kepada mereka alasan untuk masalah ini dan beri tahu mereka apa yang ingin Anda lakukan untuk mengubahnya. Pastikan Anda menjelaskan kepada mereka persentase waktu yang dihabiskan tim Anda untuk mendukung dan memperbaiki aplikasi langsung. Jika Anda tidak mengumpulkan data tentang itu, sekarang saatnya untuk memulai (dan kumpulkan selama sebulan sebelum Anda menyajikan informasi kepada klien).

Dapatkan pemangku kepentingan utama di sebuah ruangan dan katakan: "apakah Anda ingin X diperbaiki, atau Anda ingin Y dikirimkan? Kami hanya punya waktu untuk salah satu dari keduanya." Buat mereka bertanggung jawab untuk menetapkan prioritas, dan jelaskan bahwa Anda memiliki kapasitas terbatas. Jika mereka meminta sesuatu yang baru, tanyakan pada mereka apa yang mau mereka korbankan dari peta jalan saat ini untuk mencapainya.

Tanyakan kepada tim Anda waktu dan sumber daya apa yang mereka butuhkan untuk "memperbaiki keadaan" (baik dalam hal memperbaiki bug dasar, dan dalam hal memperbaiki masalah yang lebih besar dalam kualitas kode / arsitektur / dll.). Masukkan barang-barang itu dalam daftar hal-hal yang harus diprioritaskan oleh pemangku kepentingan Anda.

Hal terbaik yang pernah saya lakukan dalam pekerjaan saya saat ini adalah mendapatkan 8 pemegang saham teratas dalam satu ruangan secara bersamaan, dan menyusun tumpukan 16 kartu indeks yang mewakili fitur-fitur baru yang telah diminta. Saya melangkah mundur dari meja dan berkata, "kita bisa mengirimkan salah satu dari ini sekaligus. Anda ingin memesan apa?" Biarkan mereka memperdebatkan eachother selama prioritas bisnis bukan Anda terjebak di tengah.

Berhenti, jatuhkan dan putar. Api membutuhkan bahan bakar dan sering kali datang dalam bentuk panik. Sisihkan waktu untuk mengatur diri sendiri dan tim. Evaluasi pengembang Anda dan lihat apakah Anda memiliki yang tidak cukup terampil dan / atau tidak bekerja cukup keras untuk menghasilkan hasil yang Anda inginkan. Putuskan siapa yang tetap (dan berusaha untuk mempertahankannya), siapa yang butuh sedikit dorongan, sisanya harus pergi. Evaluasilah dukungan dan alat yang diperoleh programmer Anda untuk memastikan mereka dapat melakukan pekerjaan mereka. Pastikan pengujian suara, ulasan, kontrol sumber dan dokumentasi diikuti. Orang-orang baik dengan alat yang baik perlu bertanggung jawab untuk melakukan pekerjaan dengan baik.

Harus ada sistem untuk mengetahui apa yang perlu dilakukan oleh tim Anda, saat ini sedang dikerjakan dan kapan mereka diharapkan akan selesai. Banyak metodologi, teori, perangkat lunak, papan penghapus kering dan catatan tempel, dokumen, dan email untuk menyelesaikannya. Buat sesuatu bekerja dengan membuat semua orang menempel padanya. Jika setiap orang memiliki beberapa masukan ke dalam sistem, ada lebih banyak insentif untuk mengikutinya.

Dapatkan pemahaman yang lebih baik tentang apa yang diharapkan klien. Ini mungkin bukan bagian dari pekerjaan Anda. Mungkin ada orang lain yang berpura-pura rambutnya terbakar, klien mereka tidak bahagia dan langit jatuh. Itu yang mereka lakukan dan beberapa sangat bagus dalam hal itu. Jika semuanya darurat, maka tidak ada yang darurat karena semuanya tidak akan selesai. Tawarkan untuk duduk berdiskusi dengan klien sesekali. Anda akan menemukan bahwa banyak 'baik untuk dimiliki' berubah menjadi 'pemecah kesepakatan' saat mereka sampai di tim dev. Jadilah penghubung teknis atau alasan lain untuk membantu. Membuat janji yang tidak bisa Anda pertahankan lebih buruk daripada memberi tahu mereka apa yang tidak ingin mereka dengar sejak awal. Kami ingin melakukan pekerjaan dengan baik sehingga kami membutuhkan 8 minggu dan bukan 5. Mereka akan lebih bahagia dalam jangka panjang.

Pada akhirnya Anda perlu mendidik klien Anda tentang pengembangan perangkat lunak dan melibatkan mereka dalam proses sebanyak mungkin. Apa yang mereka lihat sekarang adalah pengiriman cepat fitur-fitur baru tetapi juga bug dalam perangkat lunak. Sementara mereka akan senang dengan yang pertama mereka tidak akan (atau tidak seharusnya) senang dengan yang terakhir.

Anda perlu menjelaskan kepada mereka bahwa dengan proses yang lebih baik sementara pengiriman perangkat lunak baru akan ditunda dalam jumlah yang singkat, akan ada lebih sedikit bug (tidak akan pernah ada nol). Jika Anda bisa mendapatkan persetujuan bahwa ini adalah jalan ke depan Anda akan dapat mulai memperkenalkan proses yang Anda butuhkan untuk mendapatkan kembali kendali atas pengembangan Anda.

Menggunakan proses Agile dapat membantu di sini seperti yang mereka sarankan (dan dalam beberapa mandat implementasi) bahwa pelanggan dimasukkan sebagai bagian dari tim. Jika Anda melibatkan klien dengan sangat erat, mereka akan melihat apa yang berfungsi dan apa yang dapat Anda hasilkan secara langsung.

Pendapat saya (pengalaman terbatas): Saya pikir ada dua masalah yang harus dipecahkan. Pertama, proses kualitas. Apakah Anda menggunakan scrum / air terjun / sesuatu di antaranya? Dalam scrum, Anda dapat menambahkan tugas tambahan untuk setiap cerita: 1 untuk membuat skrip / rencana pengujian, yang lain untuk menjalankannya, yang lain untuk ulasan kode, dll. Dalam air terjun, dapatkah Anda cukup menambahkan langkah-langkah ini?

Masalah lainnya adalah masalah utama besar yang ada di mana-mana dalam perangkat lunak. Mengelola harapan. Yaitu meningkatkan waktu dari seseorang yang berteriak bahwa mereka memerlukan tombol untuk melakukan X agar dikirimkan.

Jika Anda dapat menambahkan langkah-langkah tambahan pada proses dan membuat pengumuman besar tentang hal itu [kami sekarang menerapkan proses kualitas ini: yang berarti lebih sedikit waktu untuk memperbaiki bug! dan hasil kualitas yang lebih baik! email besar / rapat dll untuk memberi tahu mereka], dan memberikan hasil secara teratur (ala scrum), idenya adalah mereka yang Anda kirimi akan belajar tentang dan melihat nilai dalam langkah-langkah proses tambahan, dan mereka akan membelinya. Lebih sedikit waktu memperbaiki bug = lebih banyak waktu menerapkan dan menguji fitur.

Klien tidak akan menerima penundaan hasil yang tiba-tiba? Mereka harus melakukannya. Jelas tidak bisa dilanjutkan apa adanya. Mungkin Anda bisa menambahkan langkah-langkah QA tambahan dan kemudian jika perlu menambahkan lebih banyak anggota tim? Tetapi langkah-langkah kualitas mutlak diperlukan.

Sekali lagi jika Anda menggunakan scrum atau sejenisnya, Anda bisa membidik sprint satu minggu sehingga ada hasil pengiriman reguler. Itu akan menenangkan orang seperti halnya perputaran cepat.

Berharap itu membantu sampai taraf tertentu .. harap saya tidak melewatkan intinya.

Apa yang Anda gambarkan terdengar sangat normal dan tidak terlalu mengkhawatirkan sama sekali.

• Pelanggan biasanya memiliki pola pikir yang berbeda tentang apa yang penting daripada insinyur. Kami menyukai hal-hal yang benar, tetapi pelanggan dihadapkan dengan kenyataan yang menghargai ketepatan waktu atas kemurnian. Mereka harus menyelesaikan masalah mereka dengan cepat agar dapat bersaing, dan itulah tepatnya yang mereka bayar untuk Anda.
• Menetapkan prioritas terlalu besar dan berbulu untuk dikelola satu orang saja, memiliki tumpukan masalah penting (jadi Anda menggunakan JIRA), dengan para letnan yang mengelola setiap bidang yang diminati adalah pilihan terbaik yang kami miliki untuk menjaga pekerjaan impotant di depan Jadwal.

Tidak ada yang perlu dikhawatirkan. Yang mengatakan, Anda dapat menyelamatkan diri dari banyak rasa sakit dengan mengalihkan sebanyak mungkin tugas manajemen ke pelanggan yang membayar, dengan melibatkan mereka dalam proses pengembangan penetapan prioritas, dan turun ke teknologi, mengotomatisasi sebanyak rutinitas seperti bisa jadi.