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


48

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.



2
Dengan dukungan teknis, maksud Anda mendukung aplikasi spesifik yang mereka kembangkan, atau semacam "admin sistem" umum? Saya dapat memberitahu Anda bahwa menjengkelkan bekerja di sebuah perusahaan kecil dan memiliki orang-orang yang mengganggu Anda untuk menginstal Excel.
Carlos

12
Haruskah kita Tidak. Benarkah? Iya. Saya membencinya.
Rachel

7
Seorang insinyur harus selalu berusaha untuk membuat kesalahan yang tampaknya tidak bersalah yang menyebabkan lebih banyak pekerjaan untuk orang yang berpikir itu akan menjadi ide bagus untuk menggunakannya untuk dukungan teknis.
Erik Reppen

Jawaban:


74

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.


1
Saya pikir membuat dukungan untuk proyek dalam pengembangan tidak buruk. Berbicara dengan klien itu baik. Tetapi jika Anda bekerja di 7 proyek dengan 7 tenggat waktu dan urgensi yang berbeda ... Setelah beberapa saat, ini benar-benar tidak baik. itu jenis mengisap sangat buruk.
Loïc Faure-Lacroix

4
Saya juga melihat toko-toko di mana pengembang yang kehilangan tenggat waktu hanya mengangkat bahu dan berkata, "Saya punya banyak waktu dukungan minggu ini. Tidak ada bug, para pengguna hanya perlu berpegangan tangan." Biasanya tidak ada cara untuk mengetahui apakah itu terjadi atau pengembang hanya lambat minggu itu. Selama Anda mengendalikannya, saya mendukung pengembang yang mendukung kode mereka, tetapi tidak sebagai telepon depan yang menjawab dukungan.
Kate Gregory

10
Seharusnya ada lapisan dukungan garis depan untuk menangkap pertanyaan RTFM, hanya menyisakan pertanyaan dengan konten teknis yang berguna / umpan balik bagi para pengembang.
Robert Harvey

4
@Christopher: Sistem yang menggambarkan diri sendiri adalah ideal yang bagus untuk diperjuangkan, tetapi sulit untuk dicapai dalam praktik. Ada banyak faktor orang dan tekanan pemangku kepentingan yang berkonspirasi menentangnya dengan baik, dan akan selalu ada pengguna yang "tidak mengerti".
Robert Harvey

1
Jawaban yang sangat bagus. Perusahaan saya menemukan jalan tengah yang bagus - masing-masing pengembang menghabiskan satu hari di dukungan teknis lini ke-3, berputar melalui tim. Jika Anda menggunakan teknologi, Anda dapat diganggu dengan alasan, tetapi semua orang kebal kecuali sesuatu yang besar muncul. Selama hari-hari kami di bidang teknologi, kami cenderung melakukan perbaikan bug yang lebih ringan, hal-hal admin dll untuk menghindari berada dalam sesuatu yang kompleks ketika terganggu ... Jadi pada dasarnya kita semua mendapatkan hari untuk melakukan hal-hal yang para pengembang benci lakukan tetapi harus lakukan, tetapi ketahuilah bahwa kami mendapat panggilan dukungan sesekali untuk memecahnya. Lebih penting lagi, sangat menyenangkan mengetahui Anda kebal dari sisa waktu!
Jon Story

18

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

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.


+1 Saya dapat menghubungkan dengan semua yang Anda katakan. Saya berada di posisi yang sama beberapa minggu yang lalu. Sekarang kami tidak memiliki telepon tetapi mereka tetap mengetuk pintu, bahkan untuk hal-hal seperti: "Hei teman-teman, apakah Anda sudah melihat X?" Ya ampun!
jasonco

1
Anda dapat menyisihkan 'jam kantor' untuk menghindari gangguan. Dukungan lewat telepon bukanlah ide yang baik.
JeffO

2
Setuju juga, programmer semi-disfungsional tidak membuat orang yang sangat baik :)
Homde

6
Ini jawaban yang buruk menurut saya. Seorang Dev yang TIDAK PERNAH mendukung tidak akan pernah bisa belajar bagaimana keputusan mereka memengaruhi pengguna, baik atau buruk. Hanya menonton seseorang mencoba menggunakan perangkat lunak dapat menjadi panggilan bangun utama, bahkan jika Anda berpikir itu cocok dengan spesifikasi. Ada cara untuk mengurangi bagian negatifnya, memutar jadwal di antara para dev, help desk untuk menangani panggilan weedout sehingga Anda hanya mendukung aplikasi Anda, dll. Jika Anda memiliki dev yang 'tidak berfungsi', harus bertanya-tanya seberapa berguna mereka sebenarnya jika mereka bahkan tidak dapat berbicara dengan pengguna. Awasi jika perlu, agar mereka bisa belajar.
Jay

1
@BryanOakley: punya rencana yang akan mendapatkan dukungan teknis. Walaupun saya masih mendukung jawaban saya, tidak realistis untuk mengharapkan permulaan untuk memiliki semua personel yang diperlukan untuk dukungan dan pengembangan pelanggan yang memadai . Saya masih akan merekomendasikan bahwa tugas utama pengembang adalah pengembangan - bukan dukungan pelanggan. Masalahnya adalah bahwa ketika pengembang memiliki hubungan dekat dengan pelanggan, pengembang akan: (a) selalu dihubungi langsung oleh pelanggan alih-alih saluran teknologi yang tepat, atau (b) akhirnya berkembang secara khusus untuk kebutuhan pelanggan itu daripada ruang lingkup luas pengembangan yang diperlukan.
IAbtract

10

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.


Zappos telah membangun sebuah kerajaan yang bertentangan dengan aturan orang pertama.
JeffO

Saya tidak tahu tentang Zappos, tetapi tampaknya cukup benar untuk sebagian besar perusahaan. Yang saya tahu adalah bahwa jika saya cukup frustrasi untuk memanggil dukungan teknis, saya merasa buruk untuk orang di ujung telepon.
Berin Loritsch

Tidak pernah? Seperti dalam pernah, tidak pernah? Bahkan jika Anda adalah perusahaan kecil yang terdiri dari tenaga penjualan dan satu atau dua pengembang? Bahkan jika pengembang Anda adalah komunikator yang sangat kuat dan suka berbicara dengan pelanggan?
Bryan Oakley

Anda ingin pengembang Anda dianggap berpengetahuan luas - jadikan mereka orang kedua yang diajak bicara oleh pelanggan. Pada saat itu pelanggan akan menenangkan beberapa dan berperilaku sedikit lebih masuk akal. Sekarang, jika itu adalah pelanggan Anda memiliki hubungan yang baik dengan dan itu bukan pengantar pertama yang dimiliki pengembang ke klien, maka itu akan baik-baik saja. Kontak pertama harus diperiksa melalui orang lain terlebih dahulu.
Berin Loritsch

Sebagai seseorang yang telah mendukung lini pertama - saya pikir aturan untuk "penelepon yang marah berpikir orang pertama yang menjawab telepon salah" tidak benar. Padahal, saya hanya bisa berbicara dari pengalaman saya sendiri . Penelepon marah sesekali yang melakukan pikir ini baik menyadari kesalahan mereka ( asalkan lini depan sebenarnya adalah berpengetahuan ) atau mereka hanya tidak mencari solusi, melainkan seseorang untuk menyalahkan - cara yang tidak ada yang bisa membantu mereka. Saya masih setuju secara keseluruhan - pengembang harus menjadi kontak terakhir, setelah ditentukan ada bug di suatu tempat (atau kemungkinan tinggi salah satunya)
DoubleDouble

9

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.


Saya berada di kapal yang sama dengan Anda dan sepenuhnya setuju dengan Anda. Namun, itu harus mungkin dan lebih sering bahwa resepsionis menerima telepon dan menuliskan pesan untuk Anda agar pelanggan itu menelepon kembali. Dengan cara itu Anda bisa terus tidak terganggu dalam pekerjaan Anda dan menelepon kembali ketika itu cocok untuk Anda. Namun, hubungi kembali pada hari yang sama, sebaiknya dalam waktu 2 jam setelah panggilan masuk.
Htbaa

3

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.


4
Ada hukum tertentu dengan dukungan teknis: orang pertama yang Anda dapatkan selalu salah. Dia bisa menjadi orang yang cerdik dan paling teknis di tim, dan berdasarkan fakta dia mengangkat telepon terlebih dahulu klien tidak akan bisa mempercayai mereka. Pada dasarnya, lelaki pertama ada untuk membiarkan klien melampiaskan dan mengasapi sehingga yang berikutnya bisa menjadi "penyelamat". Ini adalah kasus dalam profesi layanan pelanggan - bukan hanya dukungan teknis.
Berin Loritsch

@BerinLoritsch Itu adalah hukum yang dipelajari dari pengalaman, bukan prasangka yang tidak adil seperti yang tampaknya Anda maksudkan. Saya tidak tahu apa yang diperlukan untuk meyakinkan pusat dukungan bahwa, ya, saya telah mencoba solusi yang biasa. Jelas itu tidak bisa didasarkan pada apa yang saya minta, tetapi saya perhatikan bahwa dalam 20 kata atau kurang saya bisa tahu apakah orang itu telah melakukan pemecahan masalah dasarnya.
Milind R

3

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.


2

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.


2

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!


2

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.


2

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.


1

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.


1

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.


2
Koreksi: Tidak ada yang seperti beberapa panggilan 3AM untuk membuat Anda menyadari apa dampak keputusan desain tertentu dan / atau pintasan yang dipaksakan manajer Anda pada kemampuan orang untuk mendukung dan menjaga kode Anda. Desain dan kode yang buruk lebih sering merupakan hasil dari manajemen yang buruk daripada programmer yang buruk.
David Thornley

0

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.


0

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.


-1

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.


3
Letakkan mereka di hotline selama sebulan. Kemudian cari pengembang pengganti, karena orang itu tidak akan lama. Selanjutnya, cari seseorang yang pandai hubungan pelanggan untuk menenangkan orang-orang yang berbicara dengan seseorang yang sedang dalam mood yang buruk sebelum dia ditugaskan untuk melakukan sesuatu yang dia benci dan yang tidak menunjukkan rasa hormat dari perusahaan.
David Thornley

Setuju dengan David, jika Anda harus menjalankan tim Anda seperti ruang kelas, Anda mungkin ingin mempertimbangkan kembali praktik perekrutan Anda, dan / atau lingkungan kerja Anda.
Matthieu

-1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.