Wie gehe ich mit dieser leider nicht hypothetischen Situation bei Endnutzern um?

Ich arbeite in einem mittelständischen Unternehmen, aber mit einer sehr kleinen IT-Abteilung.

Letztes Jahr (2011) habe ich eine Anwendung geschrieben, die bei einer großen Gruppe von Endbenutzern sehr beliebt ist. Wir haben eine Frist zum Ende des letzten Jahres erreicht und einige Funktionen (ich werde funcA von jetzt an anrufen) wurden der Anwendung, die ganz am Ende gewünscht wurde, nicht hinzugefügt. Also, diese Anwendung läuft seit Ende 2011 in Live / Produktion, könnte ich ohne Problem hinzufügen.

Gestern hat sich eine ganze Gruppe von Endbenutzern darüber beschwert, dass eine Funktion, die nie in der Anwendung enthalten war, nicht mehr funktioniert. Unsere Priorität in diesem Unternehmen besteht darin, dass eine fehlerhafte Anwendung vor priorisierten Projekten behoben werden muss.

Ich habe Code und Abfragen verglichen und es gibt keinen Unterschied seit 2011, was proofA ist. Ich konnte dann einen der Endbenutzer dazu bringen, zuzugeben, dass es nie funktioniert hatB, aber seitdem ist dieser Endbenutzer zurückgegangen und hat gesagt, dass es zuvor funktioniert hat ... Ich glaube, die Horde von Endbenutzern hat sich assimiliert ihr. Ich habe auch meine Notizen zu diesem Projekt durchgesehen, in denen Anforderungen und tägliche Aktualisierungen zum Projekt aufgeführt sind, in denen konkret heißt: "FuncA wurde aus zeitlichen Gründen nicht erreicht", ProofC.

Ich habe mit vielen von ihnen gesprochen und ich kann sehen, wo sie verwirrt sein könnten, da sie sehr weit von einem Programmierhintergrund entfernt sind, aber ich weiß auch, dass sie intelligent genug sind, um in einer Gruppe zu agieren, um Projektpriorisierungsbefehle zu umgehen und zu erhalten Funktionalität, die ihnen die Arbeit erleichtern soll.

Das Schlimmste ist, dass jetzt Gruppendenken einsetzt und mein Chef und der Leiter der IT tatsächlich anfangen, ihnen zu glauben, obwohl es keine Code- oder Abfrageänderungen gibt. Was den Zustand der Logik angeht, so ist sie sehr kurz und trocken, bis 1 = 1, und funcA funktioniert nicht.

Das ist also das Ende der Beschreibung meines Szenarios, aber ich versuche, mich nicht ernsthaft von meinen Leistungsmetriken zu befreien, was mich dazu veranlasst hätte, ein Produktionsproblem zu beheben, das wahrscheinlich nicht existiert und das die Kontrolle übernehmen wird 1 Monat.

Streitigkeiten über leicht beobachtbare Tatsachen sind eigentlich recht leicht zu lösen: Beobachten Sie einfach die Tatsachen. Wenn ich sage "Es gibt einen Baum mit lila Holz außerhalb meines Hauses", kann jeder, der in mein Haus kommen kann, die Wahrheit oder Falschheit meiner Aussage für sich selbst überprüfen.

Wenn sie sich beschweren, dass FuncA in dem Produkt enthalten war und in einer früheren Version funktioniert hat und es jetzt nicht mehr funktioniert und Sie glauben nicht, dass es jemals in dem Produkt enthalten war, bitten Sie sie, es zu beweisen. (Oder, in sanfteren Worten, sagen Sie etwas wie "Wir haben Probleme, das Problem zu reproduzieren. Können Sie uns hier raushelfen?")

Geben Sie ihnen eine Kopie der früheren Version, falls sie noch keine haben, und laden Sie sie in ein LiveMeeting. Lassen Sie sich zeigen, wie sie FuncA verwendet haben. Wenn sie es nicht schaffen, stellen sie (hoffentlich) fest, dass es dort nicht vorhanden war, und bringen Sie Ihre Argumentation zum Abschluss, oder versuchen Sie zumindest eine andere Taktik, um es umzusetzen. (Und stellen Sie sicher, dass Sie jemanden vom Management oder von der PM für das LiveMeeting gewinnen.)

Dies ist kein Problem, mit dem sich Tatsachen befassen können - wenn Sie es versuchen, verlieren Sie die Glaubwürdigkeit.

Akzeptieren Sie zunächst, dass die Software "defekt" ist, da sie nicht das tut, was die Benutzer von ihr erwarten. Akzeptieren Sie nun, dass die Benutzer das Recht haben, die Software das tun zu lassen, was sie wollen - das ist also die Software. Wir haben also eine defekte Software und einen Ingenieur, der sich weigert, sie zu reparieren.

Wenn das von Ihnen ausgeführte System Prioritäten festlegt, können diese Benutzer ihre Software nicht über die normalen Kanäle reparieren. Daher verwenden sie Seitenkanäle und eskalieren die halben Wahrheiten in der Lebensmittelkette, um zu versuchen, das System zu manövrieren In der Zwischenzeit sehen Ihre KPIs schlecht aus (Ihr Hauptanliegen sollten die Kunden sein, nicht Ihre KPIs). - Ihre KPIs werden als "Kollateralschaden" angesehen, wenn sie Sie mögen, oder als vorteilhafte Nebenwirkung, wenn sie dies nicht tun. Sie haben jedoch eine gewisse Kontrolle darüber, wie viel passiert - am liebsten mögen sie Sie.

Was also passiert, ist, dass das System kaputt ist und jeder versucht, Dinge zu manipulieren, um das zu bekommen, was er will. Sie möchten eine Funktion, und Sie möchten Ihre makellosen KPIs behalten.

Wenn Sie das System nicht reparieren oder schnell lernen können, Büropolitik zu betreiben, ist das Spiel zu Ende: Sie verlieren.

Hinweis: Keine dieser Diskussionen beinhaltet Deadlines, Bug-vs-Feature-Diskussionen, wer zahlt usw. Dies sind Fakten - und Fakten spielen keine Rolle (na ja, sie funktionieren irgendwie, aber sie können auf so viele Arten manipuliert werden ... ) in der Büropolitik.

Organisatorisch spüre ich ein Problem.

Es gibt eine Hierarchie, die den IT-Leiter und Ihren Chef umfasst. Wenn Ihre Organisation traditionell ist (es klingt nicht so, als wäre sie agil), sind Sie eine Ressource und sie sind Ressourcenmanager. Sie haben einen Vollzeitjob, der als Softwareentwicklung bezeichnet wird. Wenn Endbenutzer Funktionen direkt anfordern, Prioritäten festlegen und versuchen, Ihre Zeit zu verwalten, sind Ihre Manager redundant. Sie sind möglicherweise gegenüber Endbenutzern rechenschaftspflichtig, aber wenn sie ihre Arbeit tun, sind Sie ihnen gegenüber rechenschaftspflichtig und müssen Sie vor dem Verlassen schützen fokussierten Entwicklermodus in den defensiven Entwicklermodus überzugehen.

Ein paar Punkte, um den Kontext meiner Antwort festzulegen:

• Softwareentwickler sind keine Zeitreisenden, daher müssen die Ergebnisse danach beurteilt werden, was sie sind und nicht danach, was sie gewesen sein könnten.
• Wenn eine Funktion in einer Anforderungsspezifikation, einem Zeitplan enthalten war und Vorrang vor der abgeschlossenen Arbeit hatte, liegt möglicherweise eine berechtigte Beschwerde vor. Was ist sonst die Rechtfertigung, Sie zur Rechenschaft zu ziehen?
• Ihre Strafe muss, wenn sie verdient ist, von Ihrer Befehlskette kommen. So wie Marketing und Vertrieb es nicht mögen würden, wenn die Produktentwicklung Kunden schimpfen würde, haben die meisten Unternehmen Produktmanager, die den Zorn (und das Lob) der Kunden entgegennehmen und ihn über Kanäle verbreiten.
• Produktmanager können äußerst schwierige Beziehungen aufbauen, wenn sie die Wärme erfolgreicher Teile von Projekten genießen, aber nur dann die Peitsche knacken, wenn sie sich Entwicklern stellen.
• Wenn Sie ein funktionsfähiges Produkt mit einem Arbeitsvolumen von einem Jahr geliefert haben und es einen Monat (oder zwei) dauert, um die gewünschte Funktion hinzuzufügen, war Ihre Einschätzung überdurchschnittlich.
• Eine faire und produktive Lösung des Problems erfordert, dass die Schuldigen die Finger in die Tasche stecken und einen Plan für das weitere Vorgehen erstellen.

Sie werden in der Lage sein, qualitativ hochwertigere Arbeit mit höherer Motivation zu leisten, wenn Sie geschätzt werden, anstatt die Ziege in einem Prozess zu sein, den der IT-Leiter besitzen sollte. Es ist der faire Weg und der produktive Weg. Ich hoffe, Sie werden auf diese Weise verwaltet, und irgendwann in der Zukunft hoffe ich, dass Sie andere auf diese Weise verwalten.

Im Falle eines solchen Versagens in der Realität ist es am besten, sich vorwärts zu bewegen. Anstatt über die Vergangenheit zu streiten, sprechen Sie darüber, wie einfach oder schwierig dies sein wird. Es spielt keine Rolle, ob das Problem behoben oder zum ersten Mal implementiert wird. Wenn das Management möchte, dass A erledigt wird, bevor B es schafft.

Sind Sie der einzige Entwickler, der an diesem Projekt gearbeitet hat? Klingt so, als hättest du jemandem geantwortet, als du das Projekt erstellt hast. Wo ist diese Person in all dem? Wo steht in der Dokumentation des Projekts, was geliefert wurde?

Es sollte eine Dokumentenpapierspur geben. Ein Trainingsdokument, das die Verwendung der Anwendung zeigt. Eine funktionale Spezifikation, die beschreibt, was entwickelt wurde. Wenn ein Feature nicht enthalten war, sollte es auch eine Dokumentation dazu geben. Jemand hätte sich abmelden müssen, um zu sagen, dass er das akzeptiert.

Es sollte nicht dein Wort gegen ihr sein, es sollte alles in der Dokumentation sein.

Wenn Sie diese Dokumentation nicht haben ... dann fürchte ich, müssen Sie diese beißen. Betrachten Sie es als eine Lektion fürs Leben. Am Ende des Tages sind Ihre Benutzer Ihre Kunden, und wie das Sprichwort sagt: Der Kunde hat immer Recht. Legen Sie fest, wie und wie lange diese Funktion hinzugefügt werden soll. Nehmen Sie an einem Meeting teil und sagen Sie etwas in Anlehnung an „Unsere Unterlagen zeigen, dass dieses Feature nie implementiert wurde, aber wir können es in x Wochen umsetzen. Sollen wir einen Kopf gehen? '

Und aus Liebe zu allem, was heilig ist ... besorgen Sie sich die Dokumentation, die Sie benötigen, um zu zeigen, dass sie genehmigt wurde.