Ziemlich offensichtlich müssen Sie eine Support-Dokumentation erstellen, damit das Support-Team über die verfügbaren Informationen verfügt, um auftretende Probleme zu ermitteln und zu beheben.

Natürlich wird auf alles zurückgegriffen, was außerhalb des Geltungsbereichs des Dokuments liegt Das Entwicklungsteam und die Support-Dokumentation entwickeln sich daraus.

Es hört sich so an, als ob Ihr Support-Team Ihrem Entwicklerteam unterlegen ist. Dies kann zu einer Reihe von Problemen führen:

• Ihr Support-Team weiß möglicherweise nicht, wie die Probleme behoben werden können. Vielleicht sind sie jünger oder weniger erfahren, vielleicht fehlt ihnen das Training. Wenn Sie Leute einstellen, die für 15 US-Dollar pro Stunde telefonieren, können Sie nicht erwarten, dass sie Probleme wie einen Senior DBA (65 US-Dollar pro Stunde) lösen.
• Ihr Support-Team hat wahrscheinlich das Gefühl, dass es viel unter den Bus geworfen wird. Die Endbenutzer wissen nicht, dass ihr 15-Dollar-Telefonjockey kein 65-Dollar-Datenbankaffe ist. Sie können den Unterschied nicht erkennen und es wäre ihnen egal, selbst wenn sie könnten. Auf der anderen Seite, wenn Ihre Entwickler nicht die Verantwortung für ihre Entwicklung übernehmen, werfen sie möglicherweise auch Unterstützung unter den Bus. "Es hat die Qualitätssicherung bestanden, daher ist es nicht mein Problem."
• Ihr Support-Team hat wahrscheinlich nicht das Gefühl, bei der Einführung neuer Entwicklungen mitreden zu können. Eines Tages kommt ein neues Widget in prod an, verursacht eine ganze Reihe von Problemen und jetzt müssen sie sie beheben. Das ist nicht wirklich fair.

Folgendes würde ich versuchen:

Mischen Sie Ihre Entwickler- und Supportteams. Einige Ihrer Entwickler möchten möglicherweise eine Beförderung zum Produktions-DBA. Einige Ihrer Support-Mitarbeiter möchten möglicherweise eine Beförderung zum Entwickler. Sie erhalten ein kompetenteres Support-Team und einen besseren QS-Prozess.

Lassen Sie Ihre Support-Mitarbeiter schulen. Sind sie qualifiziert, Dinge in der Produktion zu reparieren? Wahrscheinlich nicht.

Schützen Sie Ihre Support-Mitarbeiter . Niemand repariert gerne Dinge im Handumdrehen. Es gibt soooo viele Möglichkeiten, öffentlich und spektakulär zu scheitern. Manchmal müssen Sie und wenn Sie dies tun, ist dies ein Fehler Ihrer Entwicklungs- und QS-Teams (und natürlich des Managements). Wenn der Support-Mitarbeiter in die Live-Maschinerie greift, versucht, ein Teil zu reparieren und sich metaphorisch den Arm abreißen lässt, wird er das nicht noch einmal tun wollen.

TLDR: Hier ist Ihr Problem:

zum Schutz der Entwickler

Wer schützt Ihre Support-Mitarbeiter?

Mit freundlichen Grüßen, Senior DBA in einem Krankenhaus in NYC

In sehr schlechten Umgebungen scheinen sich Support-Teams die Hände von Problemen zu waschen, von denen sie glauben, dass sie nicht gelöst werden können, und ihr Update für Kunden lautet "Es ist in der Entwicklung".

Wenn Menschen in jeder Situation können ihr Leben leichter machen, indem sie jemanden dazu bringen, es zu tun. Wahrscheinlich werden sie es tun. Wenn es für das Support-Team wirklich trivial ist, es bei der Entwicklung einfach über den Zaun zu werfen und zu sagen, dass sie sich darum kümmern werden, dann passiert genau das.

Stellen Sie stattdessen sicher, dass die Eigentümerin eingeschaltet ist Das Support-Team muss anhand eines reproduzierbaren Beispiels beweisen, dass es sich um ein Entwicklungsproblem handelt, bevor es dem Entwicklungsteam vorgeworfen wird. Sie sollten in der Lage sein, die Abfrage des Benutzers zu verwenden, um eine schrittweise Anleitung zu erstellen, was genau passiert (und was stattdessen passieren sollte), zu überprüfen, ob dies in einem aktiven Staging-System immer noch der Fall ist, und (nur!), Wenn dies der Fall ist kann dann das Entwicklungsteam mit einem reproduzierbaren Fehlerbericht treffen. Dies ist der einzige Fall, in dem der Entwicklungswarteschlange etwas hinzugefügt werden sollte.

Ich möchte klarstellen, dass dies keine Fehler sind, sondern häufig Aufgaben, die ein größeres Unternehmen zuweisen würde für betriebsbereite Datenbankadministratoren ... Datenkorrekturen, Informationsanfragen, Problemanalyse ... so etwas.

Hier gibt es zwei Ansätze - langfristig würde ich auf die Beschaffung von Tools & hinarbeiten Dokumentation, damit das Support-Team anfangen kann, solche Anfragen zu besitzen, ohne die Entwickler stören zu müssen.

In der Zwischenzeit muss es immer noch von der gesamten Entwicklungswarteschlange ferngehalten werden - solche setzen Sie nicht Informationsanfragen und Problemanalyse im Sprint. Idealerweise haben Sie jemanden, der sich ausschließlich mit diesen Problemen befasst, aber in einem kleineren Unternehmen können Sie sich trotzdem darum kümmern, indem Sie diese Rolle in Teilzeit zuweisen (Bob nimmt möglicherweise Mittwochnachmittag und Alice Freitagnachmittag Zeit, um solche Anfragen zu bearbeiten Zum Beispiel, und sie werden bis dahin in eine separate Support-Warteschlange gestellt.)

Ja, auf diese Weise haben Sie möglicherweise im Wesentlichen einen Manntag pro Woche verloren, aber das ist eine Konstante, die Sie vorhersagen können. Diese ist viel einfacher zu handhaben als eine potenziell endlose Menge an Supportanfragen, die zufällig zu einem Sprint hinzugefügt werden. p>

Ich weiß, dass dies lang ist, aber ich habe viel zu diesem Thema zu sagen. Ich habe über 10 Jahre im technischen Support für Unternehmenssoftware auf hoher Ebene gearbeitet. Support-Mitarbeiter sind technisch versierte Leute, wenn sie hochrangige technische Aufgaben erledigen und nicht nur Papageien machen. "Haben Sie versucht, sie aus- und wieder einzuschalten?" Wir lösen Probleme gerne selbst; es ist das, was wir gut können; Deshalb sind wir in dieser Position. Wenn dies nicht für Support-Mitarbeiter gilt, die Sie für Support mit DBA-ähnlichen Arbeiten in Live-Client-Umgebungen eingestellt haben, haben Sie die falschen Mitarbeiter eingestellt.

TL; DR: Wenn der Support Probleme nicht selbst lösen kann, verfügt er nicht über genügend Zeit, Fähigkeiten oder Zugriff oder es gibt keinen Workflow-Prozess, der ihn darüber informiert, wie er mit diesen Arten von Anfragen umgehen soll.

Sie haben diese Begriffe verwendet, um einen Support-Mitarbeiter zu beschreiben: "Fühlen Sie sich überfordert" und "glauben Sie, dass er [einige Probleme] nicht lösen kann". Sind sie überfordert und nicht in der Lage, alle Probleme zu lösen, die ihnen gestellt werden?

Gibt es genügend Mitarbeiter im Support-Team, um mit den richtigen Fähigkeiten alle eingehenden Anfragen beantworten zu können? Wenn mehr Anfragen eingehen, als das Support-Team beantworten kann, ist dies ein offensichtliches Problem. Beachten Sie, dass Support-Mitarbeiter in unterbesetzten Abteilungen eine Algebra erstellen müssen, die so aussieht: Ich kann mich mit diesem einen komplizierten Problem befassen und heute vier weitere Probleme unbeantwortet lassen, oder ich kann den für diesen Bereich zuständigen Entwickler um Hilfe bitten Problem, und in der Lage sein, zu allen 5 Problemen zurückzukehren. Nach meiner Erfahrung möchte der Support-Mitarbeiter die Zeit haben, sich mit dem komplizierten Problem zu befassen und sich selbst über das Produkt zu informieren. Wenn jedoch keine Zeit vorhanden ist, ist dies keine Option, insbesondere wenn Support-SLAs vorhanden sind du musst dich treffen.

Gibt es Anfragen, die Fähigkeiten erfordern, die nicht im Support-Team vorhanden sind, sondern nur in der Entwicklung? Sie haben DBA-Kenntnisse erwähnt. Wenn im Support niemand versteht, wofür Sie Datenbanken für Ihr Produkt verwenden, können sie die Probleme nicht selbst lösen (zumindest nicht rechtzeitig; siehe vorherigen Punkt). Bitten Sie die Support-Mitarbeiter um die Schulung, die sie benötigen, um die Art von Problemen zu lösen, die ihnen gestellt werden. Wenn Sie sich keine allgemeine Schulung leisten können, lassen Sie sie beim Entwickler sitzen, an den sie diese Art von Problemen normalerweise weiterleiten, während der Entwickler den Fehlerbehebungsprozess durchläuft, damit er genug lernen kann, um diese Fragen selbst beantworten zu können. Sobald Sie dies einmal getan haben, sollte das Support-Team selbst einen Experten auf diesem Gebiet haben, und andere Mitglieder des Teams können diese Person und nicht den Entwickler fragen. Wenn Ihre Support-Mitarbeiter nicht genügend Zeit haben, um die Fähigkeiten zu erlernen, die sie zur effizienten Beantwortung von Fragen benötigen, sind Sie wieder bei Problem Nr. 1 - nicht genügend Mitarbeiter.

Sie haben Informationsanfragen erwähnt. Welche Informationen horten Ihre Entwickler vom Support? Wenn es Unterlagen gibt, die Dev nicht mit dem Support teilt, muss der Support Dev darum bitten. Wenn die Informationen dem Support zur Verfügung stehen, sollte Dev nur in der Lage sein, den Support darauf hinzuweisen. Dies gilt auch für die Codebasis. Gibt es einen Teil der Codebasis, den der Support nicht sehen darf? In diesem Fall können Sie weitere Fragen erwarten, die vom Support zu diesen Teilen des Produkts weitergeleitet werden.

Nun, um den Prozess zu diskutieren. Es sollte einen technischen Supportprozess oder Workflow geben. Wahrscheinlich ein Flussdiagramm für jeden Anfragetyp mit Schritten wie: Zuweisen einer Ticketnummer, Zuweisen eines Support-Technikers, Eskalieren zum Support-Manager, Eskalieren zur Entwicklung, Auflösen usw. Für jeden unterschiedlichen Anforderungs- und Bedingungstyp sollte der Workflow zugeordnet werden aus. Hier gibt es einen Platz für Entwicklungsbeteiligung, beispielsweise wenn legitime Fehler gemeldet werden oder weil wir alle wissen, dass es diesen einen Entwickler gibt, der die einzige Person im gesamten Unternehmen ist, die [obskuren Authentifizierungsprozess] in [obskuren Umgebungen] wirklich versteht. . Wenn der Prozess grafisch dargestellt wird, kann jeder erkennen, wann eine Beteiligung an der Entwicklung angemessen ist.

Ich habe festgestellt, dass ich dort auch einen Support-Manager eingesetzt habe. Hat Ihr Support-Team einen Manager? Während das Support-Team seinen neuen Prozess lernt - d. H. Wie man selbständiger wird - kann es Teil des Prozesses sein, dass Eskalationen zur Entwicklung einen Manager durchlaufen müssen. Um ehrlich zu sein, sobald das Team die Gewohnheit hat, zuerst die internen Optionen auszuschöpfen, werden Sie feststellen, dass Sie diesen Schritt nicht benötigen, aber während Sie Ihre Gewohnheiten ändern, kann es nützlich sein, jemanden im Support zu haben Team, um den Anruf zu tätigen, mit dem es sich lohnt, die Entwicklung zu belästigen. Ein Support-Manager sollte die Fähigkeiten und Zeitpläne beider Teams kennen, um festzustellen, wann es angemessen ist, Ressourcen von Dev auf Support zu verlagern. Der Support-Manager ist auch derjenige, mit dem Sie (als mutmaßlicher Manager des Entwicklerteams) diskutieren können, wenn Sie das Gefühl haben, dass der Support den Entwickler zu sehr anruft.

Wenn Sie sich große Sorgen darüber machen, wie viele Anforderungen an die Entwicklung übergeben werden, sollten Sie in der Lage sein, Metriken dafür in Ihrem Support-Ticketing-System zu erstellen (Sie verwenden ein Ticketing-System, das nachverfolgt, wer an welchen Problemen arbeitet und wie lauten die Problemstatus, richtig?) Metriken dienen nicht nur dazu, die Person im Support zu beschämen, die die meisten Fragen an Dev stellt (dieser Support-Techniker stellt wahrscheinlich die schwierigsten Fragen), sondern auch nach Trends wie "wir" Übergeben Sie viele Fragen zu seltsamen Oracle-Berechtigungen an Dev. "oder" Zwei Wochen nach einer neuen Version steigt das Fragenvolumen, und wir müssen Dev-Ressourcen in Anspruch nehmen. " Diese können dabei helfen, Lösungen zu finden, z. B. "jemanden im Support für Oracle-Schulungen gewinnen" oder "Wir müssen wahrscheinlich x Wochen nach einer neuen Version ein zusätzliches Volumen an Support-Anfragen einplanen".

Gute Frage. Ich würde dies umformulieren, da Entwicklung und Support das Geschäft unterstützen. Das Unternehmen verdient das Geld für Ihr Unternehmen, das es uns ermöglicht, einen Job zu haben.

Zunächst (dies ist äußerst wichtig) müssen Sie Ihr Management und (hoffentlich) das Management für das Support-Team, das an der Abgrenzung von Rollen und beteiligt ist, beauftragen Verantwortlichkeiten. Ohne Management-Buy-In werden Sie nicht viel erreichen.

Einige dieser Dinge, über die Sie sprechen, sollten Entwicklungsinput haben. Oder zumindest Business Analyst Input. Wenn Sie Ihren agilen Prozess zum Nachteil verfolgen oder das Geschäft unterstützen, ist Ihr Prozess das Hauptproblem. Und obwohl ich Agilität als Prozess liebe, kann es nicht der letzte entscheidende Faktor sein. Die Unterstützung des Geschäfts ist der entscheidende Faktor. Es ist ihnen (dem Unternehmen) egal, ob es sich um einen Helpdesk-Techniker oder einen erfahrenen Java-Entwickler handelt - sie möchten nur, dass das Problem behoben, Fragen beantwortet usw.

Eine Sache, die wirklich helfen kann, ist die Verwendung Ihres Ticketing System. Alle (und ich wiederhole alle) Supportanfragen müssen zuerst Ihr Support-Team durchlaufen, wo sie entweder bearbeitet oder dem richtigen Team zugewiesen werden können (und dies ist wichtig), aus welchem ​​Grund sie zugewiesen werden. Diese können dann verfolgt, Metriken gemeldet und zukünftige Schritte geplant werden.

Entweder Sie, Ihre Firma oder beide leben in einem Fantasieland. Jemand muss Zeit geben.

So sehr Ihr Team diese festen Sprints mit festen Anforderungen gerne hätte, das klingt für mich nicht sehr agil (beachten Sie das Kleinbuchstaben 'a'). Sprints müssen zu der realistischen Zeit geplant werden, die Ihrem Entwicklungsteam zur Verfügung steht. Einer oder mehrere von Ihnen verbringen möglicherweise den größten Teil eines Sprints damit, ein Problem zu beheben. Planen Sie also nicht, dass sie Ihre Aufgabenliste stark abbrennen.

Ein weiterer Bereich, für den Ihr Team wahrscheinlich Zeit aufwenden muss, ist die Unterstützung Schulung der Mitarbeiter. Jemand mit Autorität muss eine Geschäftsentscheidung treffen und bestimmen, was er tun kann, wie lange es dauern kann (Ihr Team ist wahrscheinlich zehnmal so schnell) und wie viel Schulung und Überwachung er möglicherweise benötigt.

Ein typisches Szenario für den Moment ist es, sich zu diesem Zeitpunkt mit ihnen zusammenzusetzen und mit ihnen durch das Szenario zu gehen. Überprüfen Sie ihre Arbeit. Beantworten Sie Fragen schnell. Machen Sie deutlich, dass sie in Zukunft damit umgehen können. Wenn sie es dann an Ihr Team weitergeben, können Sie es sicher zurückwerfen und sie wissen lassen, dass sie wissen sollten, wie es geht.

Irgendwann erhalten die Leute Aufgaben und entweder können sie damit umgehen oder nicht. Ihre Support-Mitarbeiter sind möglicherweise völlig unterqualifiziert, und das Unternehmen hat nicht die Absicht, mehr zu zahlen und bessere Mitarbeiter zu finden. Sie lassen nur die Entwickler damit umgehen. Sie müssen sicherstellen, dass sie verstehen, wie viel Zeit für diese Aufgaben aufgewendet wird, um den Arbeitsaufwand zu begrenzen, den Sie beim nächsten Sprint erwarten können. Besonders die nach einer Veröffentlichung.