Bagaimana cara Anda "menjual" dukungan sebagai opsi karier [ditutup]

Kami merasa relatif mudah untuk mempekerjakan pengembang untuk mengerjakan berbagai proyek.

Masalah muncul ketika proyek selesai tetapi masih perlu didukung.

Kami benar-benar berjuang untuk membuat orang bergabung dengan tim pendukung. Itu dilihat sebagai jalan buntu, membatasi karir, membosankan, kelas dua dll.

Saat ini, kami menyelesaikan ini dengan meminta tim proyek untuk menugaskan beberapa tim mereka ke tim pendukung untuk sementara waktu. Bagian dari tugas adalah untuk melakukan "brain dump" dari proyek sehingga tim pendukung memahaminya. Ini berfungsi selama penugasan hanya untuk periode tertentu.

Mencoba mempekerjakan orang untuk bekerja dalam dukungan penuh waktu adalah masalah. Ada beberapa aplikasi dan kaliber tidak terlalu tinggi.

(Kenyataan finansialnya adalah bahwa dukungan bisa sangat menguntungkan bagi perusahaan dan begitu Anda mendapatkan reputasi, Anda didekati oleh perusahaan lain untuk melakukan dukungan mereka walaupun Anda tidak terlibat dalam pengembangan asli.)

Jangan

Bagi saya pilihan terbaik di sini adalah tidak memisahkan pengembang menjadi dukungan dan non-dukungan. IMHO ada tiga alasan utama:

• orang yang menulis hal-hal yang sulit untuk didukung tidak belajar sampai mereka harus mendukung hal-hal ini.
• orang-orang yang hanya melakukan dukungan biasanya akan mengambil jalan yang paling tidak resistan dalam mengoreksi kesalahan bahkan jika itu menghambat pekerjaan di masa depan.
• penghematan waktu teoretis agar tetap sesuai jadwal dalam pengembangan baru dengan memiliki pengembang dukungan terpisah selalu lebih dari dikonsumsi dengan harus memberikan instruksi atau pekerjaan yang berulang.

Dalam tim pengembang, Anda dapat memiliki orang-orang yang memiliki tugas pemeliharaan atau mengambil pendekatan untuk membiarkan tugas pemeliharaan menjadi dasar pelatihan bagi anggota tim yang lebih baru, tetapi jika Anda mencoba menjualnya sebagai tujuan jangka panjang dari posisi tersebut, Anda hanya akan menarik orang-orang yang akan memberi Anda mulas atau orang-orang yang akan segera keluar.

Selalu perlu ada jalan yang jelas untuk keluar dari peran pendukung dukungan 100%, dan / atau persentase tertentu dari pekerjaan pengembangan baru untuk membuat orang-orang baik tertarik.

Anda tidak ingin menarik orang-orang yang senang dalam peran itu tanpa batas waktu dan Anda tidak akan pernah meyakinkan para pengembang yang baik untuk mengambil peran itu dan mempertahankannya dalam jangka panjang kecuali Anda menawarkan jenis pembayaran yang tidak akan pernah mereka pertimbangkan. sebuah langkah karier.

Jadikan pekerjaan dukungan menyenangkan dan berharga bagi pengembang Anda.

Saya suka melakukan dukungan karena alasan berikut:

• Saya berbicara dengan orang-orang di seluruh dunia. Saya mendapat banyak teman seperti itu. Beberapa tahun yang lalu, salah satu pelanggan saya mengundang saya ke pernikahannya! Saya dulu punya peta dunia di kantor saya dengan pin yang menemukannya.
• Dukungan hampir merupakan yang terbaik, dapatkan kepuasan untuk pekerjaan Anda. Saat Anda membuat pengguna bahagia, itu benar-benar membuat Anda lebih bahagia juga.
• Keluhan adalah cara yang bermanfaat untuk meningkatkan diri Anda. Saya menanggapi keluhan dengan serius, dan dalam banyak kasus, saya dapat mengubah seseorang yang marah menjadi pelanggan / pengguna yang senang yang pada akhirnya akan menyebarkan berita tersebut.
• Ini membantu saya memahami apa yang dibutuhkan pelanggan / pengguna. Maka saya dapat membangun perangkat lunak yang lebih baik.

Itu hanya beberapa alasan.

Mengenai dukungan itu sendiri, saya sarankan untuk menerapkan proses yang mudah dikelola.

Ketika kami mendapatkan kasus dukungan, kami melakukan hal berikut:

• Jika itu bug yang dapat direproduksi, kami menambahkannya ke dalam tumpukan dan memberikan ID-nya kepada pelanggan / pengguna. Kami juga mengambil ID pelanggan / pengguna untuk memberi tahu dia tentang resolusi dan melepaskan personaaly. Ini mudah jika Anda mengumpulkan emailnya secara langsung.
• Jika masalah menggunakan perangkat lunak, kami menganggap ini sebagai kesempatan untuk meningkatkan dokumentasi. Setiap jawaban ditulis seperti artikel pangkalan pengetahuan yang kami tambahkan di database kami sesudahnya. Butuh tiga kali lipat waktu untuk menulis, tetapi kami tidak mengulangi diri kami nanti (sebagian besar pengguna lebih suka browsing di KB).
• Jika ini permintaan fitur, kami menghubungkan pengguna dengan pemilik produk secara langsung. Ini sangat berharga. Tentu saja kami menggunakan sistem seperti uservoice.com, tetapi berbicara dengan pengguna secara langsung jauh lebih baik.
• Jika ini keluhan, kami mencoba mengelolanya di luar proses. Orang yang suka mengeluh dianggap penting (meskipun keluhannya sepele).

Mengapa tidak hanya membayar dukungan devs 5 atau 10k lebih dari build dan melupakan devs?

Dengan melampirkan premi ekstra untuk mendukung peran; sebagai pengakuan atas tantangan tambahan "liasion pelanggan" dan "pemeliharaan kode produksi"; Anda tidak hanya akan memberikan motivasi ekstra, tetapi yang lebih penting perannya akan dipandang memiliki lebih banyak gengsi. Bagaimanapun, gaji yang lebih tinggi harus berarti peran yang lebih penting dan bahkan jika bukan itu masalahnya, akan diterima seperti itu.

Jika Anda berpikir bahwa dukungan adalah pekerjaan kelas dua, Anda mungkin akan kesulitan mempekerjakan orang untuk itu. Jika Anda memperlakukannya sebagai pekerjaan yang membatasi karir dan jalan buntu, Anda tidak akan mendapatkan pelamar yang baik.

Dukungan umumnya tidak dilihat sama menyenangkannya dengan pengembangan baru, dan jika Anda memiliki tim pengembangan dan dukungan terpisah, tim pendukung harus mengambil apa yang diberikan pengembangan kepada mereka, yang seringkali tidak menyenangkan. (Saya pernah bekerja di suatu tempat di mana R&D akan memberikan kami beberapa perangkat lunak yang melakukan sesuatu yang keren, tetapi yang biasanya membutuhkan desain ulang untuk menjadi kualitas produksi, dan kami tidak mendapatkan cukup waktu untuk melakukan itu, karena alasan politik. Itu bukan menyenangkan.)

Jika dukungan benar-benar penting untuk bisnis, Anda harus memperlakukannya seperti itu. Jika Anda bersikeras memiliki tim dukungan yang terpisah, dan penting untuk memiliki tim pendukung yang baik, Anda perlu mengatasi masalah ini. Pastikan ada jalur karier yang lebih tinggi. Publikasikan uang yang Anda hasilkan dari dukungan, sebagian untuk harga diri mereka, sebagian untuk membuat orang lain menyadari nilai mereka, sebagian sehingga mereka dapat menempatkan angka dolar untuk kegiatan mereka di resume mereka. Tetapkan standar, dan berikan masukan pada tim pendukung apakah suatu proyek siap untuk beralih dari pengembangan ke dukungan. Karena pekerjaan itu kurang menyenangkan dan mungkin lebih penting, bayar mereka lebih baik. (Saya akan lebih bersimpati dengan manajer yang mengeluh "kami tidak bisa mendapatkan pelamar yang kami butuhkan" jika biasanya tidak diterjemahkan sebagai "kami tidak bisa pelamar yang kami butuhkan murah".)

Walaupun saya setuju bahwa mendukung biasanya tidak menyenangkan, banyak pengembang mungkin benar-benar menikmati prestise yang sejalan dengan "kepemilikan" proyek, bahkan jika mereka tidak menulis sendiri perangkat lunaknya. Pemrogram yang menjadi goto pada proyek itu, dan mereka benar-benar menjadi ahli yang tak ternilai dalam sistem. Walaupun saya terutama terlibat dalam pengembangan baru di perusahaan tempat saya bekerja, banyak kolega saya yang lebih dari kompeten sebenarnya cukup dihormati karena pemeliharaan perangkat lunak kami yang paling penting. Setelah semua, perangkat lunak yang saat ini didukung mungkin adalah yang saat ini menghasilkan uang (seekor burung di tangan bernilai dua di semak-semak).
Saya hanya akan mengatakan bahwa tidak semua orang melihat dukungan sebagai pekerjaan bawah tanah yang mengerikan bagi programmer sub-par, dan saya akan mempermainkan sentimen itu untuk menarik lebih banyak orang.

Beberapa pemikiran:

1) Anda mengatakan itu dilihat sebagai jalan buntu dan membatasi karir. Jika ini tidak benar dan orang-orang telah beralih ke hal-hal lain (pengembangan, manajemen proyek, menjalankan tim) maka saya yakin Anda memiliki contoh yang dapat Anda gunakan. Jika Anda tidak memiliki contoh maka Anda mungkin harus menerima bahwa itu adalah jalan buntu dan membatasi karir dan perlu mengatasi masalah ini.

2a) Jika dukungan termasuk perbaikan bug lalu mengapa mereka terpisah? Jika seseorang mengkodekannya dengan buruk maka apa yang Anda ajarkan dengan memberikan kekacauan kepada orang lain untuk diselesaikan. Terlebih lagi jika pengembang dukungan tidak terlihat sebagus para pengembang bagaimana Anda dapat mengharapkan mereka untuk memperbaiki apa yang pengembang tidak dapat lakukan dengan benar? Serius aturannya seharusnya kamu aja, kamu perbaiki.

2b) Jika dukungan tidak termasuk perbaikan bug maka itu pekerjaan yang sangat berbeda dan menekankan keterampilan yang berbeda. Anda tidak perlu khawatir tentang menyeberang di sini seperti Anda tidak khawatir tentang persilangan antara pengembangan dan pembersihan.

3) Anda mengatakan itu menguntungkan bagi perusahaan - kemudian membuatnya menguntungkan bagi orang-orang yang terlibat. Ini mungkin melalui uang yang lebih baik, pelatihan yang lebih baik, peralatan yang lebih baik dan memberi mereka semua yang mereka butuhkan untuk melakukan hal ini dengan sangat baik. Jika ada uang yang tersedia membuatnya menjadi pekerjaan yang hebat.

Masalah dari membaca posting Anda adalah bahwa Anda tampaknya tidak percaya itu pekerjaan yang baik. Jika itu benar maka tidak heran Anda tidak bisa menjualnya sebagai satu.

Dukungan adalah pekerjaan yang sulit, tidak ada orang yang suka mendengarkan orang mengeluh sepanjang hari. Menemukan orang yang baik bisa memakan waktu, tetapi begitu Anda memilikinya, Anda harus mempertahankannya

1. Bayar uang baik, bahkan jauh di atas tarif industri untuk mempertahankan orang-orang baik
2. Menyediakan lingkungan kerja yang baik, hal-hal kecil seperti bekal makan siang dan minuman membantu
3. Jangan menjejalkan semua staf pendukung Anda ke ruangan kecil yang bising

Saya pikir zappos.com telah menunjukkan bahwa pekerjaan tidak harus jelek ketika Anda bekerja untuk perusahaan yang baik. Bagian terburuk dari dukungan adalah tidak bisa membantu seseorang. Jika Anda mengacaukan pengguna dengan kontrak layanan cetak atau perangkat lunak buggy yang dikirim yang tidak akan diperbaiki dalam waktu dekat, dukungan akan payah. Mereka perlu didorong untuk menemukan solusi untuk masalah; semacam pemrograman seperti.

Saya mendukung selama beberapa tahun untuk perusahaan pertama saya di luar perguruan tinggi. Apa yang membuat saya mendaftar selama beberapa tahun adalah:

1. Jalur karier yang diperlukan untuk menjadi Insinyur Perangkat Lunak.
2. Saya membutuhkan waktu untuk memoles bahasa utama perusahaan (Fortran, Circa 1989)
3. Saya tidak menikah sehingga saya bisa berhenti jika saya tidak menyukai perusahaan atau pekerjaan itu.

Bagaimana dengan beberapa campuran pengembangan dan dukungan (peran terpisah)? Saya pikir Anda masih akan berjuang untuk mendapatkan dukungan untuk itu karena alasan yang telah disebutkan (pengembang! = Orang-orang pendukung produk). Tetapi jika produk Anda bergantung pada pemahaman yang luas tentang teknologi internal, mungkin pengembangan 80%, dukungan 20% akan menjadi tradeoff yang adil. Atau semacam mentoring / membayangi untuk karyawan baru untuk memastikan mereka mendapatkan informasi yang benar tentang produk.