So organisieren Sie technischen Support in einem Webstudio

    Technischer Support ist im Allgemeinen das A und O auf dem Webentwicklungsmarkt. Die tränenreichsten Beschwerden kommen zu uns mit der Bitte, ein Projekt zur Fertigstellung abzuholen.

    Die Nachfrage nach technischem Support ist heute um ein Vielfaches höher als das Angebot. In naher Zukunft wird es nur noch wachsen, weil Viele Unternehmen werden Knochen schneiden und ihre Projekte in einem mehr oder weniger lebendigen Zustand halten, ohne neue Wege zu beschreiten.



    Viele erklären technische Unterstützung. Einheiten können systematisch und kostengünstig tun. Dieser Text ist eher für Studios gedacht (damit sie ihre Prozesse verbessern oder sagen können, wie sie unsere verbessern können). Aber es ist nützlich für diejenigen, die wirklich daran interessiert sind, herauszufinden, ob es ein Leben nach der Veröffentlichung gibt. Wir haben zig Stunden im Studio diskutiert und gestritten, um zu entscheiden, dass unser Prozess ungefähr so ​​aussehen soll. Und obwohl wir einige Aspekte des technischen Supports recht flexibel konfigurieren können (z. B. die Arbeit im bevorzugten Aufgaben-Tracker des Kunden), scheint mir das Framework, zu dem wir gekommen sind, ziemlich gut zu sein.

    Wohnküche


    Ich werde eine Reservierung machen, dass ich über technischen Support nur vom Standpunkt der Programmierung sprechen werde. Design, Kreativität und Inhalt sind ebenfalls wichtig, aber es ist viel einfacher, sie zu organisieren (nach ungefähr demselben Schema).

    Wir führen unsere Projekte nach der flexiblen Scrum-Methode durch. Dies bedeutet, dass der Kunde sich bei der Arbeit nicht an eine dicke und langwierige TK halten muss, sondern dass Sie unterwegs jede Wunschliste hinzufügen / entfernen / ändern können. Vorteile: Flexibilität und das Ziel, das Projekt sofort kontinuierlich weiterzuentwickeln. Nachteile - ständig irrelevante Dokumentation.

    Gewitterwolke: alte und neue Projekte.


    Ein TEAM von Entwicklern arbeitet an jedem Projekt. Dies ist wichtig, da nach dem Start des Projekts mindestens zwei bis drei Personen am Code beteiligt sind und ihn unterstützen können. In der Praxis ist dies viel besser, als wenn ein „unersetzliches“ Genie die gesamte Entwicklung übernehmen würde.

    Zwei Dinge tragen auch dazu bei, der Unentbehrlichkeit entgegenzuwirken: strenge Codierungsstandards und regelmäßige Codeüberprüfungen, die wir bei unseren Projekten durchführen.

    Vorübergehende Verbindung zur Unterstützung weiterer Programmierer, die nicht an der Umsetzung des Projekts beteiligt waren, gefällt mir nicht wirklich: Es besteht ein hohes Risiko, dass eine fortschreitende Vergiftung des Projekts einsetzt. Dieses Phänomen ist eine Manifestation des menschlichen Faktors und scheint größtenteils auf die russische Mentalität zurückzuführen zu sein. Der Wunsch, in großen Strichen zu kreieren und nicht mühsam die Details zu bringen.

    Die Abneigung des neuen Entwicklers, sich in den Code eines anderen hineinzuversetzen, und sein Verständnis, dass er an dem Projekt beteiligt ist, führen vorübergehend dazu, dass Krücken im Code stecken bleiben. Nachdem die kritische Masse an Krücken im Code angezeigt wird, beginnt auch das Team, das das Projekt ursprünglich entwickelt hat, den Code als Fremden zu betrachten und Probleme mit neuen Krücken zu lösen. Nach einiger Zeit will sich niemand mehr mit dem Projekt befassen und jeder jammert, dass er ein Govnokod ist. Es ist möglich, die Vergiftung zu stoppen, aber es ist ziemlich kostspielig: Oft ist es notwendig, eine Tiefencodierung und ein Refactoring durchzuführen. Manchmal zwei bis drei Mal hintereinander. Generell halte ich das Hinzufügen neuer Leute zur Unterstützung nur in drei Fällen für gerechtfertigt:

    1. Ich muss eine neue Person in das Projekt einführen, damit sie weiter daran arbeitet.
    2. Für die Entwicklung von Anfängern unter der Aufsicht eines Kurators.
    3. Sehr, sehr selten (und auf die Gefahr, dafür Karma-Minuspunkte zu bekommen), aber dennoch: als Maß für die Erziehung eines zu ehrgeizigen Entwicklers zum Gourmet. Ich meine, diese seltenen Leute, die anfangen, sich über irgendeine Aufgabe zu lustig zu machen, an der sie nicht interessiert sind, alle Technologien - na ja, der Code anderer - sogar ihre eigenen, die er vor einer Woche geschrieben hat - sind ebenfalls veraltet. Er kann sich in den nächsten 2-3 Monaten (oder bis er sich niederlässt oder bis klar wird, dass wir nicht arbeiten werden) Projekte nur zur technischen Unterstützung in die Hände bekommen (während seine Kollegen neue, interessante Projekte erhalten).

    Bei der Planung des Arbeitspensums für Entwickler gehen wir davon aus, dass ihr Arbeitstag aus zwei Teilen besteht: Arbeit am Hauptprojekt (6 Stunden) und technischer Support (die restlichen zwei Stunden). Die Öffnungszeiten des technischen Supports sind in der Regel von 16:00 bis 18:00 Uhr. Diese Zeit eignet sich gut zur Lösung kleiner und einfacher Aufgaben. Die Kehrseite der Medaille ist die Bereitstellung auf produktiven Servern am Ende des Arbeitstages, und in diesem Fall kann die ganze Nacht so am Produkt hängen. Bei kritischen Projekten übertragen wir die Bereitstellung oder einen Teil des Supports auf den Vormittag. Wenn es an einem Tag keine technischen Supportaufgaben gibt, ist der Programmierer mit dem Hauptprojekt beschäftigt.

    Zwischen den Sprints (z. B. wenn intensive Tests durchgeführt werden und Sie sich nicht mit dem Projekt befassen können) können wir gegebenenfalls mehr technischen Support leisten. In den Morgenstunden der Entwickler versuchen wir nicht zu ziehen (es sei denn unbedingt notwendig). Dies liegt daran, dass es wichtig ist, dass Entwickler in einem Thread arbeiten und so wenig wie möglich abgelenkt und gewechselt werden. Entropie reduzieren. Darüber hinaus kann sich der Entwickler nicht nur auf die Unterstützung des alten konzentrieren (viele mögen es nicht, aber hier bin ich hart: Jedes mehr oder weniger erfolgreiche Projekt wird mit Sicherheit nach Entwicklung fragen), sondern auch neue (neue Technologien) für neue Projekte ausprobieren.

    In diesen zwei Stunden pro Tag, von 16 bis 18, erledigen wir also kleine und dringende Aufgaben (unter Berücksichtigung der Teamarbeit können es 4 bis 6 Stunden sein, je nachdem, ob die Aufgaben parallel sind). Wir starten große Aufgaben, die durch Sprints (jeweils mindestens 40 Stunden) in den Hauptstunden in einem ruhigen Modus erledigt werden können. Sprinten ist für den Kunden günstiger (in Bezug auf die Kosten einer Stunde) als dringende und dringende Aufgaben, die gestern erledigt werden müssen.

    In den meisten Fällen ist derselbe Manager für die Kommunikation mit einem Kunden für technischen Support verantwortlich, der an dem Projekt gearbeitet hat. Leider ist dies unter dem Gesichtspunkt der Verwendung teurer Zeitmanager nicht immer sinnvoll (teuer - nicht nur in Bezug auf die Kosten, sondern im Sinne des Inhaltsverzeichnisses: Manager werden sehr oft zu Engpässen eines Systems, und eine Stunde Ausfallzeit in einem Engpass entspricht einer Stunde Ausfallzeit des gesamten Systems).

    Wenn der Manager aufgrund des technischen Supports überlastet ist (wir nennen es "Regenbogenzerreißen") und sich der Verlust der Übertragung des Projekts auf einen anderen Manager grundsätzlich auszahlt, kann ich den Manager wechseln. In vielerlei Hinsicht fallen Unterstützungsprojekte in die jüngere Generation, um ihre eigenen Stärken zu entfalten und einen Kundenstamm zu gewinnen. Es ist äußerst selten, den Manager zu wechseln, wenn ein Konflikt mit dem Client im Projekt vorliegt und Sie die Beziehung von vorne beginnen müssen.

    Auch hier arbeitet der Programmierer in äußerst seltenen Fällen, in denen es an Management-Zeit mangelt, direkt mit dem Wortlaut des Kunden. Wir versuchen jedoch, solche Kommunikationen so gering wie möglich zu halten Die Unbestimmtheit des Wortlauts ist für Programmierer äußerst ärgerlich, und die Beantwortung von Kundenfragen durch Programmierer ohne vorherige Prüfung kann den Kunden vor Ort in Verlegenheit bringen.

    Klicken Sie auf das Bild, um zur interaktiven Karte zu gelangen.

    Was von uns am liebsten wäre


    1. Erhalten Sie proaktive Vorschläge zur Verbesserung des Projekts.
    2. Die Aufgabe selbst in den verrücktesten Formulierungen zu erledigen. Verständnis auf einen Blick. Denken "offensichtlich". Analyse der möglichen Konsequenzen der Umsetzung der angeforderten. Warnungen vor möglichen negativen Folgen und Hinweise auf rationalere Ansätze. Manchmal - halten Sie den Mund mit Ihren klugen Analysen und tun Sie lange, um zu erklären, warum.
    3. Stellen Sie eine Aufgabe über einen beliebigen Kanal (Skype, Telefon, Handy, SMS-Ku). Zu jeder Zeit, Tag und Nacht.
    4. Genaue Schätzungen.
    5. Verantwortung für das, was getan wurde.
    6. Effizienz.
    7. Nun, das wäre nicht teuer.

    Alles andere ist eher exotisch.

    Als nächstes gehe ich einfach und langweilig jeden dieser Punkte durch und erkläre, wie es bei uns funktioniert, warum es getan wurde und in welchen Situationen es schlecht oder überhaupt nicht funktioniert.

    Proaktive Vorschläge zur Projektverbesserung


    Hier muss ich Ihnen sagen, welche Projekte zu unserer Unterstützung kommen. Nur drei Arten:

    1. Kostenlose technische Unterstützung für unsere Projekte.
      Dies sind alles Projekte in der Inbetriebnahmephase und während der Garantiezeit. Dies ist vertraglich geregelt. Support für die Inbetriebnahme (wenn der Projektmanager einen heißen Start hat und bereit ist, alle Fragen des Kunden zu beantworten) beträgt diese in der Regel drei Monate. Gewährleistungsfrist (in der Regel ein Jahr) - Innerhalb eines Jahres sind wir bereit, alle versteckten Mängel zu beheben, die der Kunde zu Beginn des Projekts nicht festgestellt hat. Der grundlegende Unterschied zwischen dem ersten und dem zweiten besteht darin, dass sich das Projekt bei der Inbetriebnahme im „RAM“ des Managers befindet und viele Probleme einfacher und schneller gelöst werden. In der Garantiezeit beheben wir kostenlos nur offensichtliche Fehler. In umstrittenen Fällen behalten wir uns das Recht vor, den Kunden zu begründen, warum dies ein Fehler ist. Wenn die Diagnose einige Zeit in Anspruch nimmt und der Fehler tatsächlich kein Fehler war, behalten wir uns das Recht vor, die für die Diagnose aufgewendete Zeit in Rechnung zu stellen. Formal ist das ehrlich, aber wir greifen in Einzelfällen auf solche Maßnahmen zurück, weil Dies führt zwangsläufig zu einer Konfliktsituation.
    2. Entwicklung von von uns entwickelten Projekten.
      Projekte, die in unserem Unternehmen umgesetzt wurden, begleiten uns oft über viele Jahre. Entwickeln und weiterentwickeln. Normalerweise fügen wir Sprints neue Funktionen hinzu (ab 40 Stunden). Es ist bequemer und billiger, eine große Arbeitseinheit zu erledigen, als 100.500 kleine, dringende Aufgaben: Managern wird Zeit gespart, es besteht weniger Risiko, Fehler zu machen, es ist viel weniger Kontrolle erforderlich, und der Prozess läuft reibungsloser ab. Bei dringenden und geringfügigen Aufgaben sollte sich der Klient jedoch nicht ansammeln (dies ist schlecht für seine Gesundheit). Daher können solche Aufgaben auch entwickelt werden, jedoch mit einem Aufpreis für die Dringlichkeit.
    3. Projekte, die wir nicht gemacht haben.
      Wir nehmen sehr selten Projekte von Drittanbietern zur Unterstützung. Viele kleine Projekte entsprechen nicht den globalen Zielen und der Ideologie unseres Unternehmens. Leben durch IMHO-Unterstützung, ein stabileres, aber langweiliges Geschäft. Es gibt keinen Antrieb, keine Anstrengung oder etwas. Deshalb nehmen wir Projekte von Drittanbietern äußerst selten und widerstrebend an. Die Kriterien hier sind (in der Reihenfolge der Priorität aufgelistet):

    • Das Projekt sollte (oder könnte möglicherweise) die Nr. 1 oder Nr. 2 in seiner Nische sein. Oder sollte er uns gefallen?
    • Der Projektcode muss kompetent sein.
    • Das Projekt hat einen ausreichenden Aufgabenbereich.
    • Der Kunde versteht unsere Grundsätze und Einschränkungen des technischen Supports angemessen und stimmt diesen grundsätzlich zu.

    Ich wiederhole noch einmal, dass wir solche Kriterien absolut bewusst ausgewählt und viele Bewerbungen abgeschnitten haben. Wenn Sie bereit sind, Projekte von Drittanbietern zu unterstützen, und dies kompetent organisieren können, haben Sie mit Sicherheit eine große Warteschlange. Wir sind für große Projekte inhaftiert und viele kleine werden den gesamten Förderer für uns aufwickeln.

    Also, über die Proaktivität.

    Für Projekte in der aktiven Unterstützungsphase sollte der Projektmanager eine proaktive Position einnehmen. Er ist motiviert,% der Projekte zu erhalten. Für Projekte, für die es keine Arbeit gibt, gehen wir mehrmals im Jahr systematisch durch und versuchen, sie aufzuwecken. Dies ist eine gute Praxis, die Früchte trägt. Wacht schlafende Kunden auf, normalerweise einen Account Manager. Nicht immer muss ein schlafender Kunde geweckt werden :)

    Stellen Sie die Aufgabe in einer beliebigen, auch in der verrücktesten Formulierung


    Dies ist ein wichtiger Punkt in Bezug auf die Haftung. Verantwortung ist eine zweischneidige Sache. Hier gibt es mehrere Grundsätze, die wir mit dem Kunden vereinbaren. In der Regel wird der Kunde nicht mit den Grundsätzen selbst streiten (sie sind klar und logisch), er wird jedoch versuchen, eine Lücke zwischen den Grundsätzen zu finden. Übrigens auch der Projektleiter.

    1. Scheiße am Eingang - Scheiße am Ausgang.
      Hier ist es klar. Eine schlecht gestellte Aufgabe mit hoher Wahrscheinlichkeit wird falsch ausgeführt.
    2. Ohne Telepathie.
      Das heißt, wir glauben im Allgemeinen, dass es standardmäßig keine Telepathie gibt. "Es war offensichtlich" oder "Ich meinte, dass es für sich sein würde", leider kein Argument.
      Ich halte das für das richtige Prinzip. Es gibt jedoch einen Fehler darin. Dies ist eine sehr große Lücke für einen skrupellosen Projektmanager, um endlos Geld zu verdienen und die gleiche Aufgabe zu erledigen. Erstens fühlt der Kunde jedoch intuitiv, wenn er gemolken wird, und zweitens mag er es wirklich nicht, und er wird Ihnen davon erzählen. Und drittens können Sie ein formelles Verfahren für die Analyse von Flügen implementieren, um solche Andeutungen zu erfassen.

      Aber dazu später mehr.
    3. Die erhaltene Aufgabe sollte in Bezug auf Machbarkeit, Machbarkeit, Vollständigkeit und Ressourcen analysiert werden.

      Gewitterwolke: Kunde und Studiomanager.


      Wahrscheinlich werden 70-80% der Arbeitszeit des Managers für die Eingabe der Aufgabe, die Klärung des Wortlauts, das Verständnis dessen, was sie beeinflussen kann, das Vorschlagen effektiverer Schritte, das Vorhersehen aller Risiken oder die Bewertung der Aufgabe aufgewendet. Es ist möglich, dass der Manager, anstatt die Aufgabe zu erledigen, Fragen benennt und stellt. Oder sogar den Kunden davon abhalten. Ja, sie werden uns nicht für das bezahlen, was wir davon abgehalten haben. Und manchmal ist es sehr schwierig, Argumente zu finden, um davon abzubringen. Aber so - karmisch korrekter. Wenn unsere Argumente jedoch nicht helfen, haben wir keine andere Wahl, als die Klappe zu halten und zu tun, wie gewünscht :).
    4. Wir verstehen, dass Doppelinterpretationen nicht vermieden werden können.
      Auf der Ebene des gesunden Menschenverstands ist dies so. Auch hier gibt es eine Lücke sowohl für den Manager als auch für den Kunden - „mach den Narren an“. Wenn Sie jedoch systematisch arbeiten, können Liebhaber des Durchschnüffelns von Schlupflöchern gefangen und bestraft werden, und es kann eine Kontrollmaßnahme angewendet werden.
    5. In einigen Fällen ist die bezahlte Arbeit eines Analysten oder Programmierers erforderlich, um den Wortlaut zu klären.
      Dies betrifft hauptsächlich große Aufgaben oder solche, bei denen ein Experiment oder eine Zeichnung benötigt wird. Oder absolut verwirrende Produktionen und Legasthenie.

    Insgesamt behalten wir uns das Recht vor, die Aussagen des Kunden klarer zu fassen und neu zu formulieren. Details klären und ergänzen. Und sogar den Kunden von einigen Aufgaben abzubringen (wenn sie unserer Meinung nach das Projekt verschlechtern). Für den endgültigen Wortlaut ist jedoch der Auftraggeber verantwortlich. Die Formulierungen, die wir eins zu eins festgelegt haben, werden an die Entwicklung gesendet. Und auf ihnen wird unser Tester prüfen. Und auf ihnen werden wir die Aufgabe bestehen.

    Ich möchte Aufgaben über einen beliebigen Kanal (Skype, Telefon, Handy, SMS) festlegen. Zu jeder Tages- und Nachtzeit


    Ja aber nein Ein klarer Wunsch, blinder Genuss, der im Studio Verwirrung, Panik und Verwirrung stiftet und jedes technische Support-Projekt unrentabel macht. Um dies zu handhaben, muss der Projektmanager nichts tun, sondern die ganze Zeit in der Leitung sein. Und es ist wirtschaftlich unzweckmäßig und moralisch schwierig. Für alle technischen Support-Projekte verfügen wir über ein einheitliches Kunden-Task-Storage-System. Task-Manager. Dort werden sie geklärt, bewertet und Statusangaben angebracht. Was es technisch für das System sein wird, ist nicht so wichtig (die operative Arbeit kann sowohl in Google Docs als auch im Bitrix-Portal organisiert werden). Das allererste, woran sich der Manager und der Kunde gewöhnen müssen, ist, dem Kunden beharrlich, aber höflich das Schreiben beizubringen und dem Task-Manager zu antworten. Es ist klar, dass der Client in einigen Fällen ohnehin über Skype schreibt, 50 Briefe innerhalb einer Stunde per Post anrufen oder schreiben. Die Aufgabe des Managers besteht darin, höflich darum zu bitten, Aufgaben in den Task-Manager zu übernehmen. Sie können sogar darauf hinweisen, dass die Aufgabe in Skype verloren geht. Bitte legen Sie sie im Aufgaben-Manager ab. Dies kann den Kunden zunächst ärgern, doch mit der Zeit werden ihm die Vorteile dieses Ansatzes klar.

    Trotzdem ist die Diskussion besonders großer Aufgaben im Tracker ineffizient. Skype, ein Telefon mit der obligatorischen Fixierung der Ergebnisse eines Gesprächs in bestimmten Aufgaben. In der Regel fasst unser Projektleiter das Gespräch zusammen. Aufgabe des Auftraggebers ist es, den Wortlaut zu überprüfen und zu validieren und grünes Licht für die Arbeit zu geben.

    Es ist klar, dass es Situationen gibt, in denen alles zusammengebrochen ist und Sie anrufen und das Problem dringend lösen müssen. Zum Beispiel hatten wir einen Fall, in dem in einem Online-Schuhgeschäft zum Zeitpunkt einer Währungspanik 100 Bestellungen pro Stunde eingingen und der Kunde den Verkauf dringend einstellen musste, weil Logistik konnte nicht bewältigen. Es ist klar, dass wir in Fällen höherer Gewalt aufgeben und das Problem telefonisch lösen. Auch am Wochenende und nach Feierabend. Aber wir können es uns nicht leisten, über alles in Panik zu geraten. Fast alle Kunden verstehen das, wenn sie es erklären.

    Genaue Schätzungen


    Bei den meisten technischen Support-Projekten richtet sich die Zahlung nach der tatsächlich aufgewendeten Zeit. Die Aufgabe des Managers besteht darin, vorläufige Schätzungen der Komplexität abzugeben und vom Kunden herauszufinden, ob wir Aufgaben ausführen oder nicht. Für den Fall, dass wir anfangen, von der Einschätzung abzuweichen (zum Beispiel gab es eine Funktion im Projekt, die es uns nicht erlaubt, die Arbeit rechtzeitig abzuschließen), ist es die Verantwortung des Managers, den Kunden zu warnen, neue Prognosen über die Schätzungen zu informieren und zu klären, ob wir die Aufgaben ausführen oder nicht. Termine und Schätzungen aufzupumpen macht da nicht viel Sinn Der Kunde fühlt dies und wird es uns in einer Zufriedenheitsumfrage mitteilen.

    Für einige Projekte des Unternehmenssektors, bei denen ein umständliches Budgetierungsverfahren vorliegt, ist dieser Ansatz jedoch nicht geeignet: Alle Schätzungen und Budgets müssen im Voraus unterzeichnet und genehmigt werden. In diesem Fall berücksichtigen unsere Bewertungen die maximale Anzahl von Risiken, die wir für jede der Aufgaben vorhersehen können.

    Ich stelle fest, dass die Arbeit an Zeit und Material in der Praxis für den Kunden schneller und billiger ist. Dies ist jedoch nur möglich, wenn der Kunde vertraut und zufrieden ist. Das kommt uns auch zugute, denn reduziert die Kosten für Management und Bürokratie (und der Manager, ich erinnere Sie, wir haben einen Engpass des Systems).

    Zur Frage der genauen Noten: Es gibt zwar gute Benotungsmethoden, genaue Schätzungen liegen nicht vor. Diese Idee ist für den Klienten schwer zu vermitteln und es ist sehr leicht, Demagogie zu betreiben. Ich ziehe es vor, mich nicht von dem Kunden mitreißen zu lassen, der dieses Thema diskutiert, sondern nur zwei Arbeitsschemata zu skizzieren: mit Einschätzungen, die unsere Risiken enthalten, und Einschätzungen, bei denen alle Risiken vom Kunden getragen werden, und eine Auswahl zu treffen. Letztendlich müssen wir verstehen, dass die Budgets des Kunden begrenzt sind und dass es für uns keinen Sinn macht, ohne Gewinn zu arbeiten.

    Wenn Sie ernsthaft an der Frage nach genauen Schätzungen interessiert sind, finden Sie am Ende des Artikels Links.

    Verantwortung für das getan


    Nach dem Schema der Arbeit an endgültigen Schätzungen liegen alle Kodierungsrisiken auf unserer Seite. Ich stelle fest, dass wir nicht bereit sind, Projekte nach einem solchen Schema zu betreuen.

    Mit dem Zeit + Material-Schema liegen im Wesentlichen alle Risiken beim Kunden. Wenn es viele Fehler gibt und deren Korrektur dem Kunden auffällt, ist er unglücklich und wird Sie darüber informieren. In der Regel ist es wirtschaftlich rentabler, auf eigene Kosten keine Streitigkeiten zu führen und Fehler zu korrigieren, ohne die Situation zu eskalieren, obwohl der Arbeitszeitplan für die tatsächlichen Stunden vereinbart wurde. Ich halte mich an die Korrektur von Fehlern auf unsere Kosten, wenn:

    • Projekt unterstützen;
    • es ist in Schritten klar, wie der Fehler reproduziert wird;
    • Es ist für beide Parteien offensichtlich, dass dies ein Entwicklungs- (Implementierungs-) Fehler ist.

    Der letzte Absatz bietet Anlass zu Unterstellungen sowohl des Kunden als auch des Entwicklers, weshalb eine formelle Beschreibung nicht möglich ist. Wenn der Grund für den Fehler beispielsweise die Unvollständigkeit der Problemstellung war, liegt die Verantwortung dafür beim Kunden (da er für die Annahme der endgültigen Formulierungen verantwortlich ist). Darüber hinaus bedeutet dies, dass sie dem Kunden kein Geld abgenommen haben, um die Aufgabe vollständig zu erledigen.

    Wenn das Gelenk offen gesagt uns gehört, nehmen wir es und reparieren es, ohne unser Gehirn zu kompostieren. Am Ende ist es also billiger.

    Ausnahme: sehr komplexe Systeme mit vielen Abhängigkeiten. Wenn Sie das Komma in der Produktkarte ändern, wird ein schwieriger Import abgebrochen, der einmal im Monat beginnt. Hier benötigen Sie entweder Code Freeze + einen vollständigen Systemtest für jede Änderung (was sehr teuer ist) oder eine vollständige Codeabdeckung mit Tests (was auch sehr teuer ist) oder Demut, dass solche Situationen möglich sind.

    Ich stelle fest, dass Streitigkeiten so selten wie möglich auftreten müssen, damit das System funktioniert. Andernfalls ist der Kunde mit dem Support unzufrieden oder der Support ist für das Studio unrentabel.

    Eine weitere Nuance - wir übernehmen keine Verantwortung für 3 Personen (zum Beispiel Hosting) oder entgangenen Gewinn. Dies wird in der Regel angemessen wahrgenommen.

    Schnelligkeit


    In unseren Mitarbeiterverträgen garantieren wir eine Reaktionszeit von 24 Arbeitsstunden. In 97% der Fälle ist dies eine geeignete Option. Ich mache Sie darauf aufmerksam, dass es sich um die Reaktionszeit und nicht um die Bereitschaftszeit einer Aufgabe handelt. Dies alles entspricht dem gesunden Menschenverstand, und es gibt keinen besonderen Grund, den Schaum um 24 Uhr mit Schaum in den Mund zu schieben.

    Grundsätzlich hängt die tatsächliche Arbeitsgeschwindigkeit davon ab, wie schnell die Aufgabe zur Entwicklung gelangt. Woraus besteht es:

    0-8h für die Annahme und Klärung der Aufgabe. Der Manager wird über die Erstellung einer neuen Aufgabe informiert. Banale Geschäftsetikette und das  Prinzip einer leeren Kisteerfordert, dass alle derartigen Anfragen innerhalb von 24 Stunden bearbeitet werden. Abhängig von der Dringlichkeit kann die Aufgabe entweder verschoben werden, bis der Sprint gebildet ist, oder dringend in Betrieb genommen werden oder im Arbeitsplan für den Programmierer am nächsten Tag geplant werden. Oder wenn der Wortlaut unklar ist, beginnen wir mit der Klärung des Wortlauts. Formal hat der Manager hier eine Lücke, um den Dummkopf einzuschalten und für eine lange, lange Zeit etwas nicht zu verstehen und zu klären. Kunden spüren dies jedoch und werden in solchen Situationen äußerst unglücklich und werden Ihnen mit Sicherheit davon erzählen. Es bleibt nur die Ursachen zu verstehen und die Kontrollaktion anzuwenden.

    8-16 Uhr, normalerweise einen Tag nachdem die Aufgabe an den Projektmanager gefallen ist und alle Formulierungen klar sind, fällt sie in die Entwicklung. Dies liegt an der Tatsache, dass wir planen, welche Projekte jeder Programmierer in den Vormittagssitzungen (um 8:45 Uhr) durchführen wird, und dann versuchen wir, nicht von diesem Plan abzuweichen. In der Regel wird die Aufgabe des Kunden am Tag nach dem Festlegen in den Entwicklungsplan aufgenommen (dies geschieht jedoch am selben Tag).

    In den meisten Fällen werden kleine Aufgaben zwischen 16 und 24 Uhr erledigt und in den ersten 8 bis 16 Stunden an den Kunden versandt. Weitere 8 Stunden sind eine Reserve für die Anpassung unserer Arbeitsabläufe oder Tests.

    Für große und zeitaufwändige Aufgaben wird je nach Dringlichkeit und Kundenprioritäten entweder ein Sprint oder ein Leistungszeitplan erstellt. Es ist absolut unproduktiv, 30-40-Stunden-Aufgaben in Anfällen zu erledigen und 2 Stunden am Tag zu beginnen.

    Es ist klar, dass dort, wo höhere Gewalt herrscht, alles zusammengebrochen ist und Sie alles beenden und reparieren müssen - wir lassen es fallen und reparieren es. Wenn der Grad der höheren Gewalt über 3-5% aller Aufgaben liegt, ist dies eine Gelegenheit, nach Fehlern in der Organisation des Projekts selbst oder unserer Arbeit daran zu suchen.

    Nun, das wäre nicht teuer


    Wir haben zwei Tarifnetze:

    1. Normal, für Aufgaben, und die nicht brennen. Sie können im Rahmen unseres Zeitplans gesprintet oder ausgeführt werden.
    2. dringend (wenn "wir alles fallen lassen, tun Sie es um jeden Preis"), mit einer doppelten Rate.

    Der Kostenanstieg ist darauf zurückzuführen, dass kleine und dringende Aufgaben für uns den gesamten Förderer beschädigen und die Zeitpläne für andere Projekte gefährden können. Wir versuchen, dringende Aufgaben zu minimieren. Kunden mögen den Doppeltarif auch nicht, haben aber eine bewusste Wahl. Die Aufgabe des Projektmanagers ist es, dem Kunden diese Alternative anzubieten.

    Das wichtigste. Rückblicke. Nachbesprechung


    Dies ist der wichtigste Teil des technischen Supportsystems. Ohne sie wird sich gegenseitige latente Unzufriedenheit aufbauen, die sich eines Tages zu einem Konflikt entwickeln wird. Der Webentwickler wird immer schuld sein. Immer!

    Ich stelle fest, dass der Kampf eines Kunden auf lange Sicht fast unvermeidlich ist (na ja, oder ich kenne keine Fälle, in denen der Kunde mit dem 2-3-jährigen Ergebnis des Supports völlig zufrieden gewesen wäre, keine Beschwerden hatte und nicht von Zeit zu Zeit zur Seite geschaut hätte). Also

    Es ist völlig richtig, eine Überprüfung mit einem Kunden in 2-3 Monaten durchzuführen. Analysieren Sie die Aufgabenliste formell und untersuchen Sie die Fehlerursachen. Dies können Formulierungen sein, und in diesem Fall müssen Sie gemeinsam entscheiden, wie Sie Ihre Problemstellung verbessern möchten. Dies können zu häufige Programmierfehler sein, und hier müssen Sie nach Gründen suchen. Schließlich kann der Kunde unglücklich sein, dass er von keiner seiner Ideen abgehalten wurde und dies nur zu einer zusätzlichen Geldverschwendung führte.

    Sie sollten systematisch prüfen, ob der Kunde mit der Arbeit mit Ihnen zufrieden ist. Treffen Sie sich persönlich, sprechen Sie, besprechen Sie Projektaussichten, Kundengeschäftsaussichten und seine Pläne für das kommende Jahr. Sie sollten besonders vorsichtig sein, wenn Sie den Manager auf der Clientseite ändern. Es ist wichtig, dem Kunden mitzuteilen, wo Sie ihn treffen können und wo nicht und warum. Es erhöht die Offenheit und Handhabbarkeit.

    Ohne sie werden Sie auf lange Sicht zusammengeführt.

    Total


    Die Nachfrage nach technischem Support übersteigt jetzt das Angebot bei weitem. Vor allem in Krisenzeiten werden viele versuchen, die Website zu „flicken“, anstatt ernsthafte Arbeit zu leisten. Trotzdem ist es SEHR schwierig, die Arbeit kompetent, übersichtlich und kostengünstig zu organisieren. Zum einen, weil hohe und vielseitige Kompetenzen von Managern und Entwicklern gefragt sind. Effizienz, Multitasking und häufiges Umschalten. Viele, viele Routinen. Und das alles vor dem Hintergrund einer sehr widersprüchlichen Atmosphäre.

    Klicken Sie auf das Bild, um zur interaktiven Karte zu gelangen. Dies wird durch die Fähigkeit ausgeglichen, neue und interessante Projekte mit neuen, unbekannten Technologien in aller Ruhe zu realisieren.





    Was zu lesen



    Jetzt auch beliebt: