Kariyer seçeneği olarak desteği nasıl “satarsınız” [kapalı]


9

Çeşitli projelerde çalışmak için geliştiricileri işe almanın nispeten kolay olduğunu görüyoruz.

Sorun, proje bittiğinde ortaya çıkmaktadır, ancak yine de desteklenmesi gerekmektedir.

İnsanların destek ekibine katılmalarını sağlamak için gerçekten savaşıyoruz. Çıkmaz sokak, kariyer sınırlayıcı, sıkıcı, ikinci sınıf vb.

Şu anda, proje ekibinin bir takımını bir süreliğine destek ekibine atamasını sağlayarak bunu hallediyoruz. Görevin bir kısmı, destek ekibinin anlaması için projenin bir "beyin dökümü" yapmaktır. Bu, görev yalnızca belirli bir süre için geçerli olduğu sürece çalışır.

İnsanları tam zamanlı destek için işe almaya çalışmak bir sorundur. Az sayıda uygulama vardır ve kalibre özellikle yüksek değildir.

(Finansal gerçek şu ki, destek bir şirket için çok kazançlı olabilir ve bir kez ün kazandığınızda, orijinal gelişimde yer almasanız bile diğer şirketler tarafından desteklerini yapmaları için size yaklaşırsınız.)


8
"Bu çıkmaz sokak, kariyer sınırlayıcı, sıkıcı ..." - Çünkü genellikle öyle. Geliştiriciler genellikle yaratıcıdır ve destek, tanım gereği hiçbir şey yaratmaz.
Steven Evers

Desteği demek istediğin gibi tanımlayabilir misin? Bu, hata düzeltmeyi veya bu noktaya kadar olmayan her şeyi içerir mi?
Jon Hopkins

Hata düzeltmeyi içerir.
nzpcmad

İyi tam zamanlı hata düzelticileri nadirdir, ancak vardır. Genel olarak bir şirket olarak çok çekici olmanız ve çok dürüst olmanız gerekir (çünkü birçoğu aksi takdirde ayrılacaktı).
İş

Yanıtlar:


16

Yapma

Bana göre buradaki en iyi seçenek, geliştiricileri öncelikle destek ve desteksiz olarak ayırmak değil. IMHO'nun üç ana nedeni vardır:

  • desteklemesi zor şeyler yazan insanlar bu şeyleri desteklemek zorunda kalana kadar öğrenmezler.
  • sadece destek yapan insanlar, gelecekteki çalışmaları engelliyor olsa bile, bir hatayı düzeltmek için genellikle en az dirençli yolu izlerler.
  • ayrı destek geliştiricilerine sahip olarak yeni gelişimde programda kalmanın teorik zaman tasarrufu, talimat vermek veya işi tekrarlamak zorunda kalmaktan her zaman daha fazladır.

Geliştirici ekibinde bakım görevlerine sahip kişiler olabilir veya bakım görevlerinin yeni ekip üyeleri için eğitim alanı olmasına izin verme yaklaşımına sahip olabilirsiniz, ancak bunu pozisyonun uzun vadeli hedefi olarak satmaya çalışırsanız, yalnızca mide ekşimesi verecek insanlar veya yakında çıkacak insanlar.

Her zaman% 100 destek geliştirme rolünden ve / veya iyi insanların ilgisini çekmek için yeni geliştirme çalışmalarının belirli bir yüzdesinden çıkmak için açık bir yol olmalıdır.

Bu rolde sonsuza dek mutlu olan insanları çekmek istemezsiniz ve hiçbir zaman iyi geliştiricileri bu rolü üstlenmeye ve asla göz önünde bulundurmayacak bir ücret sunmadığınız sürece uzun vadede tutmaya ikna edemezsiniz. kariyer hamlesi.


Bu, A projesinde bir ekibimiz olduğu temel sorunu çözmez. Proje biter - ekip ayrılır. A Projesi'nin bir sorunu var - insanların onu düzeltmek için başka projelerden çıkarılması gerekiyor. Dolayısıyla bir destek ekibi fikri.
nzpcmad

3
Her zaman bu kısıtlamaya sahip olacaksınız. Ayrı bir destek ekibiniz olsa bile, orijinal dev ekip üyesinin belgelerini ve aktarımını ve ikinci kademe desteğini yapan döngülerini kaybediyorsunuz. IMHO, bu kayıp zaman sadece her zaman yetişmeye çalışan ve sadece yakalamaya çalışan ikinci sınıf bir dev ekibine sahip olmak yerine, projelerin tahminlerine göre hesaplanmış bir metrikse çok daha temiz ve personel için daha caziptir. birinci sınıf ekiplerin yarattığı sorunlar üzerinde çalışır. Destek geliştirme yaklaşımının iyi çalıştığını hiç görmedim. Her zaman personel karmaşası oluşturur.
Bill

8

Destek işini geliştiricileriniz için eğlenceli ve değerli hale getirin.

Aşağıdaki nedenlerle destek vermeyi seviyorum:

  • Dünyanın her yerinden insanlarla konuşuyorum. Birçok arkadaş edindimBöyle . Birkaç yıl önce, müşterilerimden biri beni düğüne davet etti! Ofisimde onları belirten pimlerle bir dünya haritası vardı.
  • Destek neredeyse en iyi getiri işiniz için . Kullanıcıları mutlu ettiğinizde, bu sizi gerçekten daha mutlu eder.
  • Şikayetler yararlıdır kendinizi geliştirmenin yoludur. Herhangi bir şikayeti ciddiye alıyorum ve çoğu durumda, öfkeli birini nihayetinde sözcüğü dağıtacak mutlu bir müşteriye / kullanıcıya dönüştürebilirim.
  • Müşterilerin / kullanıcıların neye ihtiyacı olduğunu anlamama yardımcı olur . O zaman daha iyi bir yazılım geliştirebilirim.

Bu sadece birkaç sebep.

Desteğin kendisiyle ilgili olarak, yönetimi kolay bir süreç uygulamayı öneririm.

Bir destek vakası aldığımızda aşağıdakileri yaparız:

  • Eğer tekrarlanabilir bir hata ise, bu biriktirmeyi biriktirme listesine ekler ve kimliğini müşteriye / kullanıcıya veririz. Ayrıca, kararları bildirmek ve kişiliklerini serbest bırakmak için müşterinin / kullanıcının kimliğini alırız. E-postasını doğrudan toplarsanız bu kolaydır.
  • Yazılımı kullanmayla ilgili bir sorun varsa, bunu belgeleri iyileştirmek için bir fırsat olarak değerlendiriyoruz. Herhangi bir cevap daha sonra veritabanımıza eklediğimiz bir bilgi tabanı makalesi gibi yazılır. Yazmak için üç kat zaman gerekiyor, ancak daha sonra tekrar etmiyoruz (çoğu kullanıcı KB'de gezinmeyi tercih ediyor).
  • Bir özellik isteği varsa kullanıcıyı doğrudan ürün sahibine bağlarız. Bu çok değerlidir. Elbette uservoice.com gibi sistemleri kullanıyoruz, ancak kullanıcıyla doğrudan konuşmak çok daha iyi.
  • Bu bir şikayetse, bunu sürecin dışında yönetmeye çalışırız. Şikayeti olan kişiler önemli sayılmak isterler (şikayet önemsiz olsa bile).

Müşterinin gerçekten ne istediğini bulmanın en iyi yolu olarak destek için +1 .
AShelly

3
Rolü bir "destek geliştiricisi" olarak adlandırmayın, "yeniden düzenleme mühendisi" gibi motive edecek bir şey kullanmayın ve onların uğraştıkları / geliştirdikleri şeyler konusunda yaratıcı olmalarını teşvik edin.
Nick Josevski

@Nick Josevski - Kesinlikle, mevcut sistemde iyileştirme / iyileştirme geliştirme özgürlüğü vermek, 'destek geliştirme'nin' sadece 'kırıldığında çalışmasını sağlamak' anlamına gelmiyor. İlk geliştirme rolüm destek / bakımdı (gerçek proje çalışmasına ilk başladığımda çok keyif aldım).
Adam Luchjenbroers

@Pierre 303, herkesin senin gibi olmadığından şüpheleniyorum. Bahse girerim, içe dönüklüğe karşı dışa dönüklük denklemin bir parçasıdır.
Meslek

Burada daha fazla ayrıntı veriyorum

3

Neden sadece destek devs'i inşa ve unut devs 5 veya 10k daha fazla ödemek değil?

Rolleri desteklemek için ekstra bir prim ekleyerek; "müşteri irtibat" ve "üretim kodu bakımı" nın ek zorluklarının kabulünde; sadece ekstra motivasyon sağlamakla kalmaz, daha da önemlisi roller daha fazla prestije sahip olarak görülür. Sonuçta, daha yüksek bir maaş daha önemli bir rol anlamına gelmelidir ve durum böyle olmasa bile, bu şekilde alınacaktır.


Bunun alıkoymayı artıracağını sanmıyorum. Elbette, daha fazla kişinin oturum açmasını sağlayacaksınız, ancak bir miktar nakit banka yaptıktan sonra ayrılacaklar. Bazı çalışmalarda para sadece göstermiştir ki gerçekten bunu yokken önemli. 'Bilgi çalışanları' için iki katına çıkar.
Steven Evers

3

Desteğin ikinci sınıf bir iş olduğunu düşünüyorsanız, bunun için insanları işe almakta sorun yaşayabilirsiniz. Eğer bunu kariyer sınırlayıcı ve çıkmaz bir iş olarak görürseniz, iyi başvuru sahibi alamazsınız.

Destek genellikle yeni gelişme kadar eğlenceli değildir ve ayrı geliştirme ve destek ekipleriniz varsa, destek ekipleri gelişimin kendilerine verdikleri şeyleri almak zorundadır, ki bu genellikle eğlenceli değildir. (Bir zamanlar Ar-Ge'nin bize harika bir şey yapan, ancak genellikle üretim kalitesinde yeniden tasarıma ihtiyaç duyan bir yazılım vereceği bir yerde çalıştım ve bunu yapmak için politik nedenlerden dolayı yeterli zamanımız olmadı. eğlence.)

Destek gerçekten iş için kritikse, ona bu şekilde davranmanız gerekir. Ayrı destek ekiplerine sahip olmak konusunda ısrar ediyorsanız ve iyi ekiplere sahip olmak önemlidir, bu sorunları ele almanız gerekir. Bir kariyer yolu olduğundan emin olun. Kısmen öz saygıları için, kısmen diğer insanların değerlerini fark etmelerini sağlamak için destekten kazandığınız parayı tanıtın, kısmen de faaliyetleri için dolar rakamlarını özgeçmişlerine koyabilirler. Standartlar oluşturun ve destek ekiplerinin bir projenin geliştirmeden desteğe geçmeye hazır olup olmadığı konusunda bazı girdilere izin verin. İş daha az eğlenceli ve muhtemelen daha önemli olduğu için onlara daha iyi ödeme yapın. ("İhtiyacımız olan başvuru sahiplerini alamayız" şikayet eden yöneticilere daha fazla sempati duyarım, eğer genellikle "ucuza ihtiyacımız olan başvuru sahiplerini yapamayız" olarak tercüme edilmez.)


1

Ben destek olmak genellikle emmek kabul ederken, birçok geliştirici yazılım yazmamış olsa bile, aslında projenin "mülkiyet" ile birlikte prestij tadını çıkarabilirsiniz. Bu programcı o projeye gitmeye başlar ve sistemde gerçekten paha biçilmez bir uzman haline gelir. Öncelikle çalıştığım şirkette yeni gelişime dahil olmama rağmen, yetkinlikten daha fazla olan meslektaşlarımın çoğu, en önemli kritik yazılımımızı sürdürmelerinde oldukça saygı görüyor. Sonuçta, şu anda desteklenen yazılım muhtemelen şu anda para kazanıyor (eldeki bir kuş çalıda iki değerinde).
Sadece herkesin alt-par programcıları için korkunç bir zindan işi olarak görmediğini söyleyebilirim ve daha fazla insanı çekmek için bu duyguyu ortadan kaldıracağım.


1

Birkaç düşünce:

1) Bunun çıkmaz sokak ve kariyer sınırlaması olarak görüldüğünü söylüyorsunuz. Bu doğru değilse ve insanlar başka şeylere (geliştirme, proje yönetimi, ekibi yönetme) geçtiyse, kullanabileceğiniz örneklere sahip olduğunuzdan eminim. Örnekleriniz yoksa, bunun çıkmaz ve kariyer sınırlayıcı olduğunu kabul etmeniz ve bu sorunları ele almanız gerekebilir.

2a) Destek hata düzeltmeyi içeriyorsa neden ayrılırlar? Birisi başlamak için kötü bir şekilde kodladıysa, bunları çözmek için başka birine karışıklık vererek onlara ne öğretiyorsunuz? Dahası, destek geliştiricileri geliştiriciler kadar iyi görünmüyorsa, geliştiricilerin doğru yapamayacaklarını düzeltmelerini nasıl bekleyebilirsiniz? Cidden kural yazmış olmalısınız, düzeltin.

2b) Destek hata düzeltmeyi içermiyorsa, çok farklı işler ve farklı becerileri vurgularlar. Buraya geçme konusunda endişelenmemelisiniz, geliştirme ve temizlik arasında geçmekten endişe etmeyin.

3) Şirket için kazançlı olduğunu söylüyorsunuz - daha sonra ilgili kişiler için kazançlı hale getirin. Bu daha iyi para, daha iyi eğitim, daha iyi kit ve onlara bu işi gerçekten çok iyi yapmak için ihtiyaç duydukları her şeyi vermek olabilir. Kullanılabilir para varsa harika bir iş çıkar.

Gönderinizi okumanın sorunu, bunun iyi bir iş olduğuna inanmamanızdır. Bu doğruysa, o zaman bir tane olarak satamazsınız.


0

Destek zor bir iştir, hiç kimse bütün gün şikayet eden insanları dinlemeyi sevmez. İyi insanlar bulmak zaman alabilir, ancak sahip olduktan sonra onları tutmanız gerekir.

  1. İyi insanları korumak için endüstri oranlarının çok üstünde bile iyi para ödeyin
  2. İyi bir çalışma ortamı sağlayın, iş tarafından sağlanan öğle yemeği ve içecekler gibi küçük şeyler yardımcı olun
  3. Tüm destek personelinizi küçük, gürültülü bir odaya sıkıştırmayın

0

Bence zappos.com iyi bir şirket için çalışırken bir işin boktan olması gerekmediğini gösterdi. Destekte olmanın en kötü yanı birisine yardım edememek. Kullanıcıları kısa bir süre içinde düzeltilmeyecek servis sözleşmesi ince baskı veya sevk edilmiş buggy yazılımı ile mahvettiyseniz, destek emilir. Sorunlara çözüm bulmaya teşvik edilmeleri gerekir; bir çeşit programlama gibi.


0

Kolej dışındaki ilk şirketime birkaç yıl destek verdim. Birkaç yıllığına kaydolmamı sağlayan şey şuydu:

  1. Yazılım Mühendisi olmak için gerekli kariyer yolu.
  2. Şirketin ana dilini geliştirmek için zamana ihtiyacım vardı (Fortran, 1989 dolaylarında)
  3. Evli değildim, bu yüzden şirketi veya işi beğenmediğimi fark edersem bırakabilirim.

0

Bazı geliştirme ve destek karışımına ne dersiniz (bölünmüş roller)? Zaten bahsettiğimiz nedenlerden dolayı hala bunun için satın almak için mücadele edeceğinizi düşünüyorum (geliştiriciler! = Ürün destekçileri). Ancak ürününüz iç teknolojinin geniş bir anlayışına, belki% 80 gelişimine dayanıyorsa,% 20 destek adil bir takas olacaktır. Ya da yeni çalışanlar için ürün hakkında doğru bilgi aldıklarından emin olmak için bir tür mentorluk / gölgeleme.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.