Wie Sie Support als Karriereoption „verkaufen“ [geschlossen]

9

Wir finden es relativ einfach, Entwickler einzustellen, um an verschiedenen Projekten zu arbeiten.

Das Problem tritt auf, wenn das Projekt abgeschlossen ist, aber noch unterstützt werden muss.

Wir kämpfen wirklich darum, dass die Leute dem Support-Team beitreten. Es wird als Sackgasse, Karriere einschränkend, langweilig, zweitklassig usw. angesehen.

Derzeit umgehen wir dies, indem wir das Projektteam veranlassen, einen Teil seines Teams für eine Weile dem Support-Team zuzuweisen. Ein Teil der Aufgabe besteht darin, einen "Brain Dump" des Projekts durchzuführen, damit das Support-Team es versteht. Dies funktioniert so lange, wie die Zuordnung nur für einen festen Zeitraum erfolgt.

Der Versuch, Leute einzustellen, die Vollzeit im Support arbeiten, ist ein Problem. Es gibt nur wenige Anwendungen und das Kaliber ist nicht besonders hoch.

(Die finanzielle Realität ist jedoch, dass Support für ein Unternehmen sehr lukrativ sein kann. Sobald Sie sich einen Namen gemacht haben, werden Sie von anderen Unternehmen gebeten, ihre Unterstützung zu leisten, obwohl Sie nicht an der ursprünglichen Entwicklung beteiligt waren.)

nzpcmad
quelle
8
"Es wird als Sackgasse, Karriere einschränkend, langweilig angesehen ..." - Weil es normalerweise so ist. Entwickler sind oft Schöpfer, und Support schafft per Definition nichts.
Steven Evers
Können Sie Support so definieren, wie Sie es meinen? Umfasst dies die Fehlerbehebung oder alles bis zu diesem Punkt?
Jon Hopkins
Es würde eine Fehlerbehebung beinhalten.
nzpcmad
Gute Vollzeit-Fehlerbehebungen sind selten, aber vorhanden. Man muss als Unternehmen insgesamt nur sehr attraktiv sein und viele ehrliche (weil viele sonst bald gehen würden) Interviews führen.
Job

Antworten:

16

Tu es nicht

Für mich besteht die beste Option darin, die Entwickler nicht in erster Linie in Support und Nicht-Support zu unterteilen. IMHO gibt es drei Hauptgründe:

  • Menschen, die Dinge schreiben, die schwer zu unterstützen sind, lernen erst, wenn sie diese Dinge unterstützen müssen.
  • Menschen, die nur Unterstützung leisten, gehen normalerweise den Weg des geringsten Widerstands, um einen Fehler zu korrigieren, selbst wenn dies die zukünftige Arbeit behindert.
  • Die theoretische Zeitersparnis bei der Einhaltung des Zeitplans in der neuen Entwicklung durch die separaten Support-Entwickler wird immer mehr als verbraucht, wenn Anweisungen erteilt oder Arbeiten wiederholt werden müssen.

Innerhalb des Entwicklerteams können Sie Mitarbeiter haben, die Wartungsaufgaben haben, oder die Wartungsaufgaben als Trainingsgelände für die neueren Teammitglieder verwenden. Wenn Sie jedoch versuchen, sie als langfristiges Ziel der Position zu verkaufen, werden Sie nur gewinnen Menschen, die Sodbrennen verursachen, oder Menschen, die bald auf dem Weg nach draußen sind.

Es muss immer einen klaren Weg geben, um aus einer 100% igen Support-Entwicklerrolle herauszukommen, und / oder einen bestimmten Prozentsatz neuer Entwicklungsarbeit, um das Interesse guter Leute zu wecken.

Sie möchten nicht die Art von Menschen anziehen, die in dieser Rolle auf unbestimmte Zeit glücklich sind, und Sie werden ansonsten gute Entwickler niemals davon überzeugen, diese Rolle zu übernehmen und langfristig zu behalten, es sei denn, Sie bieten die Art von Bezahlung an, die sie niemals in Betracht ziehen würden ein Karriereschritt.

Rechnung
quelle
Dies löst nicht das Grundproblem, bei dem wir ein Team für Projekt A haben. Projekt beendet - Team aufgeteilt. Projekt A hat ein Problem - Leute müssen von anderen Projekten entfernt werden, um es zu beheben. Daher die Idee eines Support-Teams.
nzpcmad
3
Sie werden immer diese Einschränkung haben. Selbst wenn Sie ein separates Support-Team haben, verlieren Sie die Zyklen der ursprünglichen Entwickler-Teammitglieder, die die Dokumentation und Übergabe sowie den Support der zweiten Ebene ausführen. IMHO ist es viel sauberer und für das gesamte Personal attraktiver, wenn diese verlorene Zeit nur eine Metrik ist, die in die Schätzungen der zukünftigen Projekte einfließt, anstatt ein zweitklassiges Entwicklerteam zu haben, das immer versucht, aufzuholen und nur arbeitet an den Problemen der erstklassigen Teams. Ich habe noch nie gesehen, dass der Support-Dev-Ansatz gut funktioniert. Es erzeugt immer eine Abwanderung von Mitarbeitern.
Bill
8

Machen Sie den Support-Job für Ihre Entwickler unterhaltsam und wertvoll.

Ich unterstütze gerne aus folgenden Gründen:

  • Ich spreche mit Menschen auf der ganzen Welt. Ich habe so viele Freunde gefunden . Vor ein paar Jahren hat mich einer meiner Kunden zu seiner Hochzeit eingeladen! Früher hatte ich in meinem Büro eine Weltkarte mit Stecknadeln, auf denen sie sich befanden.
  • Support ist fast das Beste, um Befriedigung für Ihre Arbeit zu erhalten. Wenn Sie Benutzer glücklich machen, macht es Sie auch wirklich glücklicher.
  • Beschwerden sind ein nützlicher Weg, um sich zu verbessern. Ich nehme jede Beschwerde ernst und kann in den meisten Fällen jemanden, der wütend ist, in einen zufriedenen Kunden / Benutzer verwandeln, der irgendwann das Wort verbreitet.
  • Es hilft mir zu verstehen, was Kunden / Benutzer brauchen. Dann kann ich bessere Software erstellen.

Das sind nur einige Gründe.

In Bezug auf den Support selbst schlage ich vor, einen einfach zu verwaltenden Prozess zu implementieren.

Wenn wir einen Support-Fall erhalten, gehen wir wie folgt vor:

  • Wenn es sich um einen reproduzierbaren Fehler handelt, fügen wir ihn dem Backlog hinzu und geben dem Kunden / Benutzer seine ID. Wir nehmen auch die ID des Kunden / Benutzers, um ihn über Beschlüsse zu informieren und persönlich freizugeben. Dies ist einfach, wenn Sie seine E-Mail direkt sammeln.
  • Wenn es ein Problem mit der Software gibt, nutzen wir diese Gelegenheit, um die Dokumentation zu verbessern. Jede Antwort wird wie ein Knowledge Base-Artikel geschrieben, den wir anschließend in unsere Datenbank aufnehmen. Das Schreiben dauert dreimal so lange, aber wir wiederholen uns später nicht mehr (die meisten Benutzer bevorzugen das Surfen in KB).
  • Wenn es sich um eine Funktionsanforderung handelt, verbinden wir den Benutzer direkt mit dem Product Owner. Das ist sehr wertvoll. Natürlich verwenden wir Systeme wie uservoice.com, aber es ist viel besser, direkt mit dem Benutzer zu sprechen.
  • Wenn es sich um eine Beschwerde handelt, versuchen wir, diese außerhalb des Prozesses zu verwalten. Personen, die sich beschweren, werden gerne als wichtig angesehen (auch wenn die Beschwerde trivial ist).

quelle
+1 für Support als beste Möglichkeit, um herauszufinden, was der Kunde wirklich will.
AShelly
3
Beziehen Sie sich nicht einmal auf die Rolle als "Support-Entwickler", sondern verwenden Sie etwas, das Sie motiviert, wie "Refactoring-Ingenieur", und ermutigen Sie sie, auch kreativ mit dem umzugehen, was sie tun / verbessern.
Nick Josevski
@Nick Josevski - Auf jeden Fall bedeutet die Freiheit, Verbesserungen / Verfeinerungen am bestehenden System zu entwickeln, dass "Support-Entwicklung" nicht nur "funktioniert, wenn es kaputt geht". Meine erste Entwicklungsrolle war Support / Wartung (obwohl es mir sehr gut gefallen hat, als ich zum ersten Mal zur eigentlichen Projektarbeit überging).
Adam Luchjenbroers
@Pierre 303, ich vermute, dass nicht jeder wie du ist. Ich wette, dass Introversion gegen Extroversion ein Teil der Gleichung ist.
Job
3

Warum nicht einfach die Support-Entwickler 5 oder 10k mehr bezahlen als die Build- und Entwickler vergessen?

Durch Anhängen einer zusätzlichen Prämie zur Unterstützung von Rollen; in Anerkennung der zusätzlichen Herausforderungen der "Kundenbindung" und der "Pflege des Produktionscodes"; Sie sorgen nicht nur für zusätzliche Motivation, sondern vor allem dafür, dass die Rollen mehr Prestige haben. Schließlich muss ein höheres Gehalt eine wichtigere Rolle bedeuten, und selbst wenn dies nicht der Fall ist, wird dies auf diese Weise vorweggenommen.

sipwiz
quelle
Ich denke nicht, dass dies die Retention verbessern wird. Sicher, Sie werden mehr Leute anmelden, aber sobald sie etwas Geld eingezahlt haben, werden sie gehen. Einige Studien haben gezeigt, dass Geld nur dann wirklich wichtig ist, wenn Sie es nicht haben. Doppelt so für "Wissensarbeiter".
Steven Evers
3

Wenn Sie der Meinung sind, dass Support ein zweitklassiger Job ist, werden Sie wahrscheinlich Probleme haben, Mitarbeiter dafür einzustellen. Wenn Sie es als karrierebeschränkenden Job und Sackgasse betrachten, werden Sie keine guten Bewerber bekommen.

Support macht im Allgemeinen nicht so viel Spaß wie Neuentwicklungen. Wenn Sie separate Entwicklungs- und Supportteams haben, müssen die Supportteams die Entwicklung übernehmen, was ihnen oft keinen Spaß macht. (Ich habe einmal an einem Ort gearbeitet, an dem F & E uns Software überreichte, die etwas Cooles leistete, für die jedoch normalerweise eine Neugestaltung erforderlich war, um die Produktionsqualität zu gewährleisten, und aus politischen Gründen hatten wir nicht genügend Zeit dafür. Das war nicht der Fall Spaß.)

Wenn Support wirklich geschäftskritisch ist, müssen Sie ihn als solchen behandeln. Wenn Sie darauf bestehen, separate Support-Teams zu haben, und es wichtig ist, gute zu haben, müssen Sie diese Probleme angehen. Stellen Sie sicher, dass es einen Karriereweg gibt. Veröffentlichen Sie das Geld, das Sie mit Unterstützung verdienen, teils für ihr Selbstwertgefühl, teils, um andere Menschen dazu zu bringen, ihren Wert zu erkennen, teils, damit sie Dollar-Zahlen für ihre Aktivitäten in ihren Lebenslauf aufnehmen können. Legen Sie Standards fest und geben Sie den Supportteams einen Beitrag dazu, ob ein Projekt bereit ist, von der Entwicklung zum Support überzugehen. Da die Arbeit weniger Spaß macht und möglicherweise wichtiger ist, zahlen Sie sie besser. (Ich hätte mehr Sympathie mit Managern, die sich beschweren, "wir können nicht die Bewerber bekommen, die wir brauchen", wenn es normalerweise nicht übersetzt "wir können nicht die Bewerber, die wir brauchen, billig" bedeutet.)

David Thornley
quelle
1

Obwohl ich der Meinung bin, dass Support im Allgemeinen scheiße ist, können viele Entwickler tatsächlich das Prestige genießen, das mit dem "Eigentum" an dem Projekt einhergeht, selbst wenn sie die Software nicht selbst geschrieben haben. Dieser Programmierer wird zum Goto für dieses Projekt, und sie werden wirklich zu einem unschätzbaren Experten für das System. Während ich in dem Unternehmen, für das ich arbeite, hauptsächlich an Neuentwicklungen beteiligt bin, werden viele meiner mehr als kompetenten Kollegen für die Wartung unserer geschäftskritischsten Software sehr geschätzt. Schließlich ist die Software, die derzeit unterstützt wird, wahrscheinlich diejenige, die derzeit Geld verdient (ein Vogel in der Hand ist zwei im Busch wert).
Ich würde nur sagen, dass nicht jeder Unterstützung als schrecklichen Dungeon-Job für unterdurchschnittliche Programmierer ansieht, und ich würde dieses Gefühl ausspielen, um mehr Menschen anzulocken.

Morgan Herlocker
quelle
1

Ein paar Gedanken:

1) Sie sagen, es wird als Sackgasse und Karrierebegrenzung angesehen. Wenn dies nicht der Fall ist und die Leute sich anderen Dingen zugewandt haben (Entwicklung, Projektmanagement, Leitung des Teams), haben Sie sicher Beispiele, die Sie verwenden können. Wenn Sie keine Beispiele haben, müssen Sie möglicherweise akzeptieren, dass dies eine Sackgasse und eine Einschränkung der Karriere darstellt, und diese Probleme angehen.

2a) Wenn der Support Fehlerbehebungen umfasst, warum sind sie dann getrennt? Wenn jemand es anfangs schlecht codiert hat, was bringen Sie ihm dann bei, indem Sie jemand anderem das Chaos geben, um es zu klären. Wenn die Support-Entwickler nicht so gut sind wie die Entwickler, wie um alles in der Welt können Sie dann erwarten, dass sie das beheben, was die Entwickler nicht richtig machen konnten? Im Ernst, die Regel sollte sein, dass Sie es geschrieben haben, Sie reparieren es.

2b) Wenn der Support keine Fehlerbehebung umfasst, handelt es sich um sehr unterschiedliche Aufgaben und es werden unterschiedliche Fähigkeiten hervorgehoben. Sie sollten sich hier nicht mehr Gedanken über Überkreuzungen machen als über Überkreuzungen zwischen Entwicklung und Reinigung.

3) Sie sagen, es ist lukrativ für das Unternehmen - dann machen Sie es lukrativ für die beteiligten Personen. Dies könnte durch besseres Geld, besseres Training, bessere Ausrüstung und alles, was sie brauchen, um dieses Zeug wirklich wirklich gut zu machen, geschehen. Wenn Geld verfügbar ist, machen Sie es zu einem großartigen Job.

Das Problem beim Lesen Ihres Beitrags ist, dass Sie nicht glauben, dass es ein guter Job ist. Wenn das stimmt, ist es kein Wunder, dass Sie es nicht als eines verkaufen können.

Jon Hopkins
quelle
0

Unterstützung ist eine schwierige Aufgabe, kein Körper hört gerne zu, wie sich Menschen den ganzen Tag beschweren. Gute Leute zu finden kann einige Zeit dauern, aber wenn Sie sie haben, müssen Sie sie behalten

  1. Zahlen Sie gutes Geld, sogar weit über den Branchentarifen, um gute Leute zu halten
  2. Sorgen Sie für ein gutes Arbeitsumfeld, kleine Dinge wie Arbeit, Mittagessen und Getränke helfen
  3. Packen Sie nicht alle Support-Mitarbeiter in einen kleinen, lauten Raum
Craig
quelle
0

Ich denke, zappos.com hat gezeigt, dass ein Job nicht beschissen sein muss, wenn Sie für ein gutes Unternehmen arbeiten. Das Schlimmste an der Unterstützung ist, jemandem nicht helfen zu können. Wenn Sie Benutzer mit Kleingedruckten von Serviceverträgen oder ausgelieferter fehlerhafter Software, die nicht in Kürze repariert werden kann, fertig gemacht haben, wird der Support schaden. Sie müssen ermutigt werden, Lösungen für Probleme zu finden. Art wie Programmierung.

JeffO
quelle
0

Ich habe ein paar Jahre lang meine erste Firma nach dem College unterstützt. Was mich dazu brachte, mich für ein paar Jahre anzumelden, war:

  1. Der erforderliche Karriereweg, um Software Engineer zu werden.
  2. Ich brauchte die Zeit, um die Hauptsprache des Unternehmens aufzufrischen (Fortran, Circa 1989).
  3. Ich war nicht verheiratet, also konnte ich kündigen, wenn ich feststellte, dass mir die Firma oder der Job nicht gefielen.
Mark Thalman
quelle
0

Wie wäre es mit einer Mischung aus Entwicklung und Unterstützung (geteilte Rollen)? Ich denke, Sie werden aus den bereits genannten Gründen (Entwickler! = Produkt-Support-Mitarbeiter) immer noch Schwierigkeiten haben, sich dafür zu engagieren. Wenn Ihr Produkt jedoch auf einem umfassenden Verständnis der internen Technologie beruht, möglicherweise 80% Entwicklung, wäre 20% Support ein fairer Kompromiss. Oder eine Art Mentoring / Shadowing für neue Mitarbeiter, um sicherzustellen, dass sie korrekte Informationen über das Produkt erhalten.

Tim Claason
quelle