it-swarm-id.com

Haruskah insinyur perangkat lunak juga bertindak sebagai dukungan teknis?

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.

49
Brian

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 sebagus yang mereka kira dapat direndahkan (meskipun tidak ada jaminan Anda akan mendapatkan manfaat ini; beberapa dev benar-benar lupa, egois, dan keras kepala).
  • Pengembang akan mendapatkan pengetahuan domain. Ini 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 poin 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).

Kekurangan

  • Faktor interupsi. 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 membuat frustasi bagi para pengembang untuk berurusan.
  • 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 terlindungi dari akses pengguna mungkin tidak bekerja dengan baik dalam mendukung.
  • Penggunaan sumber daya 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 kedua 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.

74
Bernard Dy

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.

18
Pemdas

Secara empati, tidak.
Kita semua tahu betapa sulitnya untuk menghentikan apa yang Anda lakukan meminta menjawab 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.

18
IAbstract

Saya tidak akan pernah menempatkan pengembang sebagai dukungan lini pertama. Jumlah interupsi dan jumlah yang harus Anda ulangi sendiri akan mendorong sebagian besar pengembang 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.

10
Berin Loritsch

Itu tergantung pada perusahaan.

Pekerjaan saya adalah 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 mengalami penurunan produktivitas, tetapi pelanggan senang, dan lebih cenderung 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 pelanggan jauh 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 senang membuat citra perusahaan Anda lebih positif, yang biasanya mengarah ke lebih banyak pelanggan. Dan itu sebabnya, sebagai insinyur perangkat lunak, saya menyukai dukungan teknis.

9
badgerr

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 ini masalah yang sangat besar, kita akan mendengarnya.

3
Carra

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 mendukung teknologi.

3
user1842

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 untuk melakukan dukungan telepon, atau Anda membiarkan pelanggan Anda 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 tidak menyenangkan (dan saya tidak tahu ada pengembang yang benar-benar menikmati dukungan lini pertama), beberapa pengembang Anda akan pergi. Biasanya ini adalah mereka yang bisa mendapatkan pekerjaan lain dengan lebih mudah: mis., 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.

2
David Thornley

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 tanpa bayaran tambahan (ini di bidang perawatan kesehatan). Saya pikir solusinya (yang saya sarankan kepada manajer saya pada saat itu), seharusnya memiliki garis depan dukungan teknis, dan jika itu adalah bug perangkat lunak maka teruskan ke pengembang. Tak perlu dikatakan saya hanya bertahan satu setengah tahun sampai akhirnya saya pergi untuk pekerjaan pengembangan semua yang lebih baik!

2
Bmw

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.

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

2
talonx

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

2
JeffO

Sementara saya tidak berpikir itu tepat untuk menggunakan devs sebagai dukungan semua waktu, saya pikir ada sesuatu yang bisa dikatakan untuk memiliki dev melakukan dukungan awal 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.

1
dietbuddha

Saya pikir banyak tergantung pada perusahaan. Perusahaan BigCo tipikal Anda biasanya dapat memiliki dukungan orang untuk melindungi pengembang. Di sisi lain, startup dengan tiga orang total sama sekali tidak memiliki sumber daya untuk menyediakan orang-orang dukungan 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 dapat meminta orang yang bertindak sebagai "penghubung", tetapi saya menemukan bahwa biasanya masalah lebih dari nilainya.

1
Jason Baker

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 mencakup 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. Jadi harus tergantung pada 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.

0
Kit

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 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 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 benar-benar semakin sulit untuk memperbarui pengetahuan dan pengalaman saya. Saya bahkan tidak bisa meninggalkan pekerjaan saya untuk memulai lagi karena komitmen keluarga.

Sayangnya saya menemui jalan buntu.

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

0
Stranger