Haruskah insinyur perangkat lunak juga bertindak sebagai dukungan teknis? [Tutup]

Haruskah seorang insinyur perangkat lunak juga bertindak sebagai dukungan teknis? Artinya, seandainya perusahaan mengizinkan insinyur mereka untuk memakai insinyur perangkat lunak dan topi dukungan teknis. Tampaknya itu akan menghapus kemampuan untuk menulis perangkat lunak jika banyak waktu seorang insinyur diambil oleh dukungan teknis.

Ini adalah masalah klasik di perusahaan yang memiliki komponen pengembangan perangkat lunak dalam pekerjaan mereka, apakah mereka perusahaan perangkat lunak atau tidak. Saya berjuang dengan ini sepanjang waktu.

Memiliki Pengembang yang terlibat dalam Dukungan Produksi

Pro

• Perkelahian sindrom "Pengembangan dalam ruang hampa" . Sangat berharga untuk mendapatkan paparan tentang bagaimana pengguna menggunakan aplikasi. Sampai akhirnya saya melihat ini sebagai pengembang muda, saya tidak menyadari betapa jeleknya saya sebagai pengembang UI. Yang saya pedulikan hanyalah coding dan bukan desain, analisis atau perspektif pengguna.
• Pengembang yang tidak sebaik yang mereka kira dapat direndahkan (meskipun tidak ada jaminan Anda akan mendapatkan manfaat ini; beberapa pengembang benar-benar tidak menyadari, egois, dan keras kepala).
• Pengembang akan mendapatkan pengetahuan domain . Ini sangat penting jika pengembang Anda pada akhirnya menjadi lebih baik dalam mengidentifikasi dan mengisi celah-celah dalam fase analisis bisnis (dengan asumsi ada) yang hilang.
• Dukungan yang baik adalah titik pemasaran. Jika Anda melakukannya dengan baik, klien akan menghargainya. Dan pengembang yang berpengetahuan luas dengan keterampilan komunikasi dan pengetahuan domain mampu melakukan ini dengan baik. Namun, saya masih lebih suka bahwa aplikasi memiliki kualitas yang cukup tinggi sehingga mereka tidak memerlukan dukungan. Kualitas unggul adalah bentuk dukungan pelanggan sendiri (dan juga titik pemasaran).

Cons

• Faktor gangguan . Ini adalah kesalahan nomor satu dalam mencampur pekerjaan proyek dan pekerjaan pendukung, tidak ada. Proyek mengganggu dukungan, dan dukungan mengganggu proyek. Proyek tergantung pada perkiraan dan kemajuan pencapaian, dukungan tidak dapat diprediksi dan dapat melibatkan urgensi dadakan. Proyek berbasis jadwal, dukungan berbasis gangguan. Bukan kombinasi yang menyenangkan, dan sangat menyebalkan bagi para pengembang untuk dihadapi.
• Tidak semua orang pandai mendukung . Seseorang yang kurang berpengalaman dengan aplikasi atau bisnis, atau seseorang yang kepribadian atau keterampilan komunikasinya sedemikian rupa sehingga mereka lebih terlindung dari akses pengguna mungkin tidak bekerja dengan baik dalam mendukung.
• Penggunaan sumber daya yang tidak efisien . Frank Shearar mencatat dalam komentar bahwa pengembang yang melakukan dukungan sepele bisa lebih mahal daripada teknologi dukungan tingkat satu.

Dalam pengalaman saya, sebagian besar pengembang tidak suka dukungan. Setelah melayani di sisi proyek dan dukungan, saya dapat bersimpati. Ketika harus melakukan keduanya pada saat yang sama, faktor mitigasi seringkali lembur, biasanya tidak dibayar, untuk menangani keadaan darurat dukungan dan masih membuat tenggat waktu proyek. Manajer proyek suka lembur yang tidak dibayar karena itu berarti membuat kencan tanpa biaya lebih banyak uang, tetapi untuk para devs, itu hanya semangkuk besar pengisap.

Namun, saya juga percaya bahwa jika pengembang melakukan pekerjaan yang lebih baik dengan menciptakan sistem yang andal dan intuitif, Anda akan memiliki lebih sedikit dukungan. Jadi ini menciptakan argumen melingkar yang aneh untuk menggabungkan keduanya. Apa yang saya pikir harus Anda lakukan jika Anda harus melakukan keduanya adalah menemukan cara untuk menghindari membuatnya secara bersamaan.

Saya pikir pengembang sudah memakai dua topi. Dukungan lebih seperti filter yang digunakan untuk melindungi pengembangan dari masalah sepele seperti tidak memasang komputer. Namun, harus ada hubungan erat antara pengembangan dan dukungan. Beberapa pelanggan memiliki masalah sah yang mungkin disebabkan oleh bug. Seharusnya menjadi tanggung jawab pengembangan untuk membantu menyelesaikan masalah ini sesegera mungkin. Jadi dalam arti tertentu pengembang sudah menjadi bagian dari tim dukungan ... sebut saja dukungan tingkat 2.

Secara empati, tidak.
Kita semua tahu betapa sulitnya harus menghentikan apa yang Anda lakukan untuk mengajukan pertanyaan. Saya menjawab telepon untuk help desk dan saya menulis beberapa aplikasi utilitas.

Saya tidak bisa fokus menyelesaikan masalah karena setiap 5 menit saya harus mengangkat telepon. Tidak ada pekerjaan yang diselesaikan sebaik mungkin karena saya terus-menerus memikirkan apa yang bisa saya lakukan untuk menyelesaikan masalah, dan saya tidak pernah mengerjakan pemrograman cukup lama untuk sepenuhnya mengimplementasikan solusi yang mungkin saya miliki.

Sekali lagi, saya tidak bisa cukup menekankan betapa pentingnya untuk dapat fokus pada satu aspek atau yang lain.

Saya tidak akan pernah menempatkan pengembang sebagai dukungan lini pertama. Jumlah interupsi dan jumlah yang harus Anda ulangi sendiri akan mendorong sebagian besar pengembang untuk berteriak RTFM dan menutup telepon pada orang berikutnya yang menelepon. Ini bukan sesuatu yang dibutuhkan klien Anda, dan ini juga bukan sesuatu yang Anda inginkan agar pengembang Anda tahan lama.

Ada aturan tertentu dalam setiap posisi layanan pelanggan. Untuk penelepon yang marah, orang pertama yang menjawab telepon salah. Apakah mereka memiliki presiden perusahaan, orang yang mengembangkan aplikasi, atau manajer pendukung, itu tidak masalah. Setelah klien mendapatkan orang kedua, yang mungkin atau mungkin tidak tahu apa yang mereka lakukan, klien akan dapat tenang dan menjelaskan masalahnya dengan lebih jelas.

Ini bukan lingkungan yang Anda ingin mempertahankan pengembang yang baik. Apakah ada nilai dalam memiliki pengembang berinteraksi dengan klien pada masalah yang sangat sulit yang melampaui "mengapa pemegang cangkir saya tidak berfungsi lagi"? Benar. Tapi itu setelah permintaan dukungan diperiksa melalui jalur dukungan tingkat pertama dan kedua.

Itu tergantung pada perusahaan.

Pekerjaan saya persis seperti ini . Saya seorang pengembang perangkat lunak, tetapi karena kami adalah perusahaan yang cukup kecil, setiap pengembang mengambil peran dukungan "tidak resmi" yang biasanya berbasis pada perangkat lunak mereka sendiri. Beberapa pengembang harus melakukan lebih banyak dukungan daripada yang lain, tergantung pada sejumlah faktor seperti berapa banyak produk yang telah mereka kembangkan / kirim, seberapa buggy produk mereka, dan seberapa efektif mereka mendukung . Jika Anda dapat memberi pelanggan apa yang mereka butuhkan untuk menyelesaikan masalah, mereka akan terus kembali kepada Anda untuk menyelesaikan masalah secepat mungkin. Pedang bermata dua? Iya. Anda menderita karena berkurangnya produktivitas, tetapi pelanggan senang, dan lebih mungkin untuk tetap menjadi pelanggan. Ini penting untuk perusahaan kecil.

Kami memang memiliki tim pendukung sistem, tetapi karena sifat dari apa yang kami lakukan, mereka sebagian besar harus berurusan dengan masalah yang terkait dengan perangkat keras. Secara pribadi, di perusahaan yang lebih kecil, masalah ini tidak mengganggu seperti yang dibayangkan. Tentu, Anda mendapat panggilan saat Anda mencoba mencari beberapa fitur penting, tetapi pada saat yang sama, layanan pelangganjauh lebih baik; mereka dapat memiliki suara otoritatif yang tahu (dalam banyak kasus) bagaimana menyelesaikan masalah mereka alih-alih seseorang dengan informasi tangan kedua dan skrip dukungan. Jika Anda tidak dapat menyelesaikan masalah di sana dan kemudian, dapat meyakinkan mereka secara pribadi bahwa Anda akan menerapkan perbaikan untuk bug mereka, atau mempertimbangkan permintaan fitur mereka untuk rilis mendatang. Anda bisa mendapatkan umpan balik nyata langsung dari pengguna perangkat lunak Anda, sehingga versi Anda berikutnya bisa lebih baik daripada yang Anda pikirkan.

Saya suka berpikir bahwa pelanggan yang bahagia menciptakan citra yang lebih positif dari perusahaan Anda, yang biasanya mengarah pada lebih banyak pelanggan . Dan itulah sebabnya, sebagai insinyur perangkat lunak, saya menyukai dukungan teknis.

Tidak ada yang lebih membuat frustrasi daripada dukungan teknologi komputer yang tidak mau menghubungkan Anda dengan seseorang yang benar-benar mengerti apa yang sedang terjadi. Saya berharap bahwa setiap perusahaan aplikasi besar akan memiliki beberapa programmer yang akan bekerja dukungan teknis.

Pengembang harus menjadi lini dukungan terakhir.

Hanya ketika helpdesk dan departemen QA kami tidak dapat membantu pelanggan kami akan terganggu. Dan bahkan itu harus melalui sistem pelacakan bug kami yang diprioritaskan.

Jika itu masalah yang sangat besar, kita akan mendengarnya.

Saya hanya akan melakukan ini jika itu adalah pengembang baru atau yang tidak akrab dengan domain dan basis pelanggan. Menjadikannya hal yang permanen bukanlah ide yang baik.

Pekerjaan terakhir saya persis seperti ini. Kami mendukung sistem yang ada dan juga menulis yang baru sesuai kebutuhan. Itu benar-benar bencana. Saya akan terus-menerus terganggu. Semangat saya sangat rendah karena proyek dimulai akan membutuhkan waktu lama untuk selesai. Juga, kami harus membawa pager untuk dukungan di luar jam kerja tanpa bayaran tambahan (ini di bidang perawatan kesehatan). Saya pikir solusinya (yang saya sarankan kepada manajer saya pada saat itu), akan memiliki garis depan dukungan teknis, dan jika itu adalah bug perangkat lunak maka teruskan ke pengembang. Tidak perlu dikatakan bahwa saya hanya bertahan satu setengah tahun sampai akhirnya saya pergi untuk pekerjaan pengembangan yang lebih baik!

Terkadang ya. Menghadapi pelanggan sering kali memberikan perspektif yang tidak dimiliki oleh kebanyakan orang, terutama programmer. Bagaimana pengguna benar-benar menggunakan produk, atau benar-benar berpikir sering jauh dari cara pembangun (insinyur) berpikir s / dia lakukan.

Itu harus untuk tugas berkala pendek, agar tidak mengganggu tugas pembangunan yang sebenarnya.

Ada bakat dan keterampilan yang Anda butuhkan untuk mengembangkan perangkat lunak, dan bakat dan keterampilan yang Anda butuhkan untuk menjadi efektif pada dukungan lini pertama. Saya tidak tahu bahwa bakat ini memiliki korelasi.

Ini berarti bahwa Anda harus merekrut pengembang berdasarkan kemampuan mereka melakukan dukungan telepon, atau Anda membiarkan pelanggan berbicara langsung dengan orang-orang yang tidak pandai menangani pelanggan dan sejak awal tidak ingin melakukannya. Ini mungkin atau mungkin tidak lebih baik daripada meminta mereka berbicara dengan seorang pria dengan aksen India yang kental yang membaca dari naskah yang sopan.

Juga, ketika Anda membuat pekerjaan itu tidak menyenangkan (dan saya tidak tahu ada pengembang yang benar-benar menikmati dukungan lini pertama), beberapa pengembang Anda akan pergi. Biasanya ini adalah orang-orang yang bisa mendapatkan pekerjaan lain dengan lebih mudah: yaitu yang bagus. Seiring proses ini berlangsung, Anda berakhir dengan sebuah toko yang dipenuhi oleh orang-orang yang kurang berbakat, sehingga semakin tidak menyenangkan bagi yang kompeten untuk tetap melewati tawaran pekerjaan pertama dari orang lain.

Sejauh pengembangan serius dilakukan, lupakan saja jika ada gangguan. Istri saya telah banyak mengeluh tentang yang diharapkan untuk melakukan pengembangan dan mendukung pengguna secara bersamaan.

Saya pikir banyak tergantung pada perusahaan. Perusahaan BigCo tipikal Anda biasanya dapat memiliki dukungan orang untuk melindungi pengembang. Di sisi lain, startup dengan total tiga orang mungkin tidak memiliki sumber daya untuk menyediakan dukungan orang yang terpisah.

Saya pikir strategi umum terbaik (tanpa memperhatikan ukuran atau resor perusahaan) adalah dengan menggunakan tim pendukung untuk memecahkan masalah buah yang menggantung rendah dan masalah yang paling umum ("Sudahkah Anda mencoba mematikan dan menghidupkannya?"). Para insinyur harus bekerja dengan pelanggan pada masalah yang lebih rumit yang membutuhkan pengetahuan tentang bagaimana sistem bekerja bersama dengan lebih banyak dukungan berorientasi pengembang (API, alat pengembang, dll.). Anda bisa meminta orang yang bertindak sebagai "penghubung", tetapi saya menemukan bahwa biasanya masalah lebih dari nilainya.

Walaupun saya pikir tidak pantas untuk menggunakan devs sebagai pendukung sepanjang waktu, saya pikir ada sesuatu yang bisa dikatakan untuk meminta dev melakukan dukungan awal suatu aplikasi. Ini harus secara khusus mencakup dukungan setelah jam kerja. Saya juga berpikir dalam dapat bermanfaat agar mereka dijadwalkan untuk dukungan setelah jam untuk aplikasi mereka secara teratur.

Tidak ada yang seperti beberapa panggilan 3AM untuk membuat Anda menyadari apa efek keputusan desain dan / atau pintasan tertentu terhadap kemampuan orang untuk mendukung dan memelihara kode Anda.

Idealnya tidak karena alasan yang disebutkan di atas, tetapi ya sementara proyek masih baru, karena pengembang dapat memberikan resolusi cepat, sering kali diharapkan oleh bisnis, yang memberikan dukungan untuk peningkatan berkelanjutan dari perangkat lunak. Saya menghargai pengembang yang memberikan dukungan dengan cerdas: mereka yang memberikan keterampilan analitis mereka dengan memberikan contoh kepada tim pendukung penuh waktu yang lebih formal, dan mereka yang menjawab bisnis sedemikian rupa untuk menunjukkan semangat layanan dan kerja sama. Kunci keberhasilan ini termasuk manajemen yang mengakui dan memformalkan dukungan tingkat pertama dan kedua untuk dengan cepat menurunkan pengembang dari apa yang seharusnya hanya menjadi peran jangka pendek mereka. Pengembang yang menunjukkan bakat untuk pengembangan dan dukungan harus dibudidayakan sebagai dukungan tingkat ketiga, atau dukungan untuk orang-orang dukungan. Seharusnya begitu tergantung waktu, bakat dan keinginan tergantung, dan dikelola secara efektif.

Minat saya sendiri adalah untuk menjawab pertanyaan dukungan yang sulit, dan untuk mengambil apa yang telah saya pelajari dari pengalaman untuk mengurangi kebutuhan akan dukungan secara keseluruhan, yang bermanfaat bagi pengguna akhir dan dukungan primer yang sama.

Saya masuk perangkap ini ketika saya bergabung dengan perusahaan dengan gaji yang bagus. Selama wawancara saya telah diberitahu bahwa akan ada pengembangan 70% dan dukungan 30% dan saya menerima tawaran itu. Mungkin itu perusahaan atau lingkungan yang sedang saya kerjakan. Tapi sebenarnya itu 90% mendukung dan 10% pengembangan. Sudah beberapa tahun sekarang saya kehilangan cengkeraman pembangunan. Saya menyesal telah menerima tawaran ini.

Tapi saya merasa seperti saya telah kehilangan pegangan pengkodean lebih banyak di sana banyak teknologi dan kerangka kerja baru. Sekarang saya tidak tahu harus mulai dari mana lagi. Saya terus mempersiapkan, tetapi contoh-contoh helloworld ini tidak cukup untuk memiliki pengalaman praktis yang baik dan itu benar-benar semakin sulit untuk memperbarui pengetahuan dan pengalaman saya. Saya bahkan tidak dapat meninggalkan pekerjaan untuk memulai kembali karena komitmen keluarga.

Sayangnya saya menemui jalan buntu.

Tolong jangan terima peran jika Anda tidak suka atau tidak tertarik.

Kontra - dengan asumsi Anda harus berhadapan langsung dengan pelanggan.

1) Memanjakan Pelanggan Anda

Jika ini adalah dukungan lini pertama / 2/3 (maksud saya dukungan garis kabur) di mana pengembang berurusan langsung dengan pelanggan, maka itu adalah con besar. Pengembang memiliki keahlian yang diperlukan untuk men-debug masalah atau mengembangkan solusi untuk menyelesaikan masalah. Jika pelanggan memiliki akses penuh ke pengembang (garis kabur) - tidak ada yang menghentikan pelanggan dari "penyalahgunaan" hak istimewa ini - yang mengakibatkan pelanggan manja, menuntut, dan istimewa yang membayar tidak lebih dari pelanggan lain mana pun.

2) Mengkondisikan Pengembang Anda untuk Berbohong dan Make Up Stories.

Siapa pun yang berurusan dengan pelanggan tahu bahwa itu merupakan prasyarat untuk bisa berbohong kepada mereka. Ada bug dengan perbaikan 1 baris yang dapat dilakukan dalam 5 menit. Seseorang yang mendukung pelanggan akan dilatih untuk mengelola harapan pelanggan - bahwa akan memakan waktu hingga 3 hari untuk menyelesaikannya.

Sebagai pengembang, jika Anda harus berhadapan langsung dengan pelanggan, Anda harus memikirkan cara-cara kreatif untuk menenangkan atau menipu pelanggan ketika pekerjaan utama Anda adalah menyelesaikan masalah teknis dan memastikan sistem berjalan dengan lancar.

3) Curriculum Vitae Anda Menderita.

Kecuali jika Anda beralih dari Insinyur Perangkat Lunak ke Analis Bisnis / Konsultan IT / Manajemen Proyek, CV Anda akan menderita dari aspek teknis.

Pekerjaan dukungan berbayar yang berputar di antara tim adalah cerita yang berbeda.

Pro

1) Hentikan Pengeluh dari Merengek

Pengembang yang melakukan apa yang mereka benci akan membuat mereka lebih menghargai pengkodean. Punya programmer yang terus-menerus mengejek? Letakkan mereka di hotline selama sebulan.

Ya karena mereka melakukannya. Saya suka ketika saya membaca pertanyaan ini? Saya seperti bagaimana ini bahkan sebuah pertanyaan (bukan bahwa saya mempertanyakan hak Anda untuk mengajukan pertanyaan OP), tetapi ini cukup retoris karena hampir setiap Dev yang pernah saya temui memiliki beberapa jenis pekerjaan dukungan teknis yang tersirat dalam atau fungsi pekerjaannya. Anda tidak bisa menghindarinya. Dalam kebanyakan kasus, Anda adalah orang yang secara teknis paling patuh tidak hanya dalam domain fungsional Anda, tetapi dalam hal IT secara umum. Sangat sulit untuk dihindari sepenuhnya.