Ich bin freiberuflicher Programmierer/Engineer und arbeite als Berater für ein mittelständisches Unternehmen. Dieses mittelständische Unternehmen hat viele Kunden, darunter ein sehr großes Finanzunternehmen (eines der 10 größten Finanzunternehmen der Welt), das wir „Kunde X“ nennen werden. Vor Jahren (bevor ich anfing, hier zu arbeiten) erstellte mein Kunde eine benutzerdefinierte Fulfillment-Website für Kunde X.
Ich wurde ursprünglich eingestellt, um einfach ein neues Design über die vorhandene Infrastruktur der Website zu implementieren, aber bald erhielt ich neue Aufgaben – Fehlerbehebungen, kleine Verbesserungen – und dann größere Projekte – neue Anwendungen für die Website usw.
Die meisten dieser Aufgaben und Projekte wurden mit sehr rudimentären Tabellenkalkulationen, E-Mail-Kommunikation und gelegentlichen Meetings verwaltet. Ich habe immer wieder nach Funktionsspezifikationen und/oder Geschäftsregeldokumenten von Kunde X gefragt, aber sie haben mit keinem von beiden geantwortet. Stattdessen bekomme ich eine Liste mit einzeiligen Aufgaben/Projekten und Fristen für jedes (was normalerweise unangemessen ist).
Darüber hinaus hilft Client X selten bei Benutzerakzeptanztests und erwartet stattdessen, dass ich einfach ihre Anfragen entgegennehme, sie erstelle und bereitstelle und alles genau so funktioniert, wie sie es angefordert haben.
Wenn Käfer auftreten, werden ihre Federn sehr zerzaust. Sie beschweren sich über die Fehler und über die Zeit, die benötigt wird, um sie zu beheben usw.
Jetzt weiß ich, dass ich als alleiniger Softwareentwickler für meinen Kunden für die Fehler verantwortlich bin. Ich habe jedoch das Gefühl, dass es ohne ein angemessenes Projektmanagement schwieriger ist, fehlerfreien Code zu erstellen. Aufgrund mangelnder Unterstützung von Kunde X musste ich mich für die Durchführung aller folgenden Aufgaben für jedes Projekt verantwortlich machen:
Verstehen Sie mich nicht falsch, ich genieße jeden Schritt des Prozesses – ich bin ein Perfektionist und mag es, organisiert zu sein. Allerdings muss ich zugeben, dass ich kein großer QA- oder User Acceptance Tester bin. Ich bin kein "normaler" Benutzer der betreffenden Website, daher kann ich mir nicht jedes Szenario zum Testen vorstellen. Außerdem nimmt mir die Zeit, die es braucht, um jede Funktion richtig zu testen, die Zeit weg, die ich an anderen Projekten für Client X arbeiten könnte.
Es ist ein Haken 22: Sie möchten, dass ihre Aufgaben/Projekte schnell und fehlerfrei erledigt werden, aber sie erkennen nicht, dass diese beiden Dinge nicht immer zusammen existieren.
Der erste Schritt, den ich unternommen habe, besteht darin, mit dem Schreiben von Testskripten zu beginnen und diese für jede Aufgabe/jedes Projekt, an dem ich arbeite, durchzugehen.
Aber auch hier gibt es Nachteile. Ich werde als Programmierer/Softwareingenieur bezahlt. Ich habe kein Problem damit, meinen bestehenden Tarif zum Testen von Anwendungen/Funktionen zu erhalten, aber es erscheint mir lächerlich, mir so viel zu zahlen, wie sie für diesen Aspekt sind, wenn sie jemandem viel weniger zahlen könnten (idk, 15-20 $/Stunde ?) um ein Tester zu sein. Client X beschwert sich über die finanziellen Auswirkungen meiner Arbeit an Fehlerbehebungen, aber für mich würde es einfach Sinn machen, einen Tester für viel weniger Geld einzustellen, um Testskripte auszuführen und meine Zeit zum Schreiben von Code freizusetzen.
Ich habe versucht, diese Dinge meinem Vorgesetzten zu erklären, der 1. der Verbindungsmann für Kunde X, 2. der ursprüngliche Programmierer für die Website und 3. ein VP für meinen Kunden ist, aber er hält an dem alten Sprichwort fest: „Der Kunde ist immer richtig" und denkt, dass, wenn sie keine funktionalen Spezifikationen schreiben wollen und sie nicht beim Testen helfen wollen und sie kein richtiges Projektmanagement verwenden wollen, dass WIR uns darum kümmern müssen.
Also, was sind einige Möglichkeiten, wie ich mit dieser Umgebung/diesem Kunden „umgehen“ kann?
Mein Rat wäre, einen agilen/iterativen Ansatz zu wählen.
Abhängig von der Komplexität des Systems und den Änderungen, die Sie vornehmen, ist es möglicherweise nicht erforderlich, eine vollständige traditionelle Wasserfallmethode anzuwenden.
Stellen Sie jedoch sicher, dass Sie über eine angemessene Quellcodeverwaltung und eine Art Änderungsverfolgungssystem verfügen (auch wenn es sich vorerst nur um eine Tabelle handelt).
Wenn die Frage unklar ist, stellen Sie weitere Fragen, bis Sie es verstanden haben, und nehmen Sie dann die Änderungen vor.
Erklären Sie ihnen, dass Sie frühzeitig und häufig veröffentlichen und die Software nach besten Kräften selbst testen werden.
Von dort aus kann es in der Verantwortung des Endbenutzers liegen, zu überprüfen , ob das, was Sie getan haben, tatsächlich das ist, was er wollte.
Mit einem kurzen Veröffentlichungszyklus können Sie dieses Feedback aufnehmen, die Änderungen schnell umsetzen und sie glücklich machen!
Ich habe eine ganze Mini-Site mit einigen zusätzlichen Tipps zusammengestellt, die ebenfalls hilfreich sein könnten: http://doingitwrong.jasonhanley.com/
"Welche Möglichkeiten gibt es, mit dieser Umgebung/diesem Kunden 'zurechtzukommen'?" Ganz einfach - lernen, es auf ihre Weise zu tun.
Ich verstehe zwar Ihre Frustration, insbesondere als Perfektionist, aber Tatsache ist, dass Sie ein von einem Drittanbieter beauftragter Berater sind. Ihre Aufgabe ist es, das zu tun, wofür sie Sie eingestellt haben, und dies in ihrer Umgebung zu tun. „Du“ musst dich anpassen, nicht sie.
Wie Sie betont haben, haben die beiden Unternehmen eine Geschichte, und gut oder schlecht, richtig oder falsch, es funktioniert für sie. Du wirst es also nicht ändern.
Also, wie David vorgeschlagen hat – akzeptieren Sie, dass sie so Geschäfte machen, und lernen Sie, innerhalb dieses Modells zu arbeiten. Erwarten Sie nur nicht, dass sie ihre Methoden ändern.
Und vielleicht haben Sie Glück und bringen sie zumindest dazu, „einige“ Ihrer Vorschläge zu übernehmen.
Es hört sich so an, als hätten Sie verschiedene Dinge, bei denen Sie Hilfe benötigen. Ich werde versuchen, einige Hinweise zu einigen von ihnen zu geben, aber die grundlegende Antwort besteht darin, mit dem Sammeln von Metriken zu beginnen (falls Sie dies noch nicht getan haben) und Ihre Informationen mit echten $-Zahlen zu versehen.
1. Testen
Möglicherweise sind Sie diesen Weg bereits gegangen, aber wenn ja, habe ich ihn in Ihrer Frage nicht gesehen. Haben Sie versucht, Ihrem Vorgesetzten den Business Case zu erarbeiten, dass es sich lohnt, einen Tester einzustellen? Es hört sich so an, als ob Kunde X keinen Tester einstellen möchte, aber was ist mit Ihrem direkten Kunden? Können Sie folgende Informationen zusammenstellen und Ihrem Vorgesetzten vorlegen:
Die ersten drei davon werden wahrscheinlich etwas einfacher für Sie sein, die Informationen zu erfassen, als die letzteren. Aber die letzten beiden sind es, die Ihnen wirklich helfen werden, Ihren Fall zu vertreten.
2. Anforderungen / gemeinsames Verständnis
Waren irgendwelche Fehler in den letzten 6 Monaten auf eine Diskrepanz zwischen dem, was Client X wollte, und dem, was Sie implementiert haben, zurückzuführen? Wenn dies der Fall ist, sollten Sie eine ähnliche Übung wie oben durchführen (Testen durch Anforderungserfassung ersetzen). Stellen Sie sicher, dass Kunde X versteht, in welchem direkten Zusammenhang Ihre Forderung damit steht, dass er in kürzerer Zeit ein qualitativ besseres Produkt erhält.
Haben Sie in den letzten 6 Monaten Änderungsanfragen/Ergänzungen erhalten, die Sie veranlasst haben, zurückzugehen und große Änderungen an bestehendem Code vorzunehmen, den Sie kürzlich wegen anderer Änderungen/Ergänzungen berührt hatten? In der Lage zu sein, dies zu erfassen und einen $-Wert dagegen zu setzen, kann dazu beitragen, dass sie mit Ihnen über ihre vollständigen Ziele sprechen, anstatt einzelne Änderungen auf einmal herauszuarbeiten. Und wenn Sie ihre Endziele besser verstehen, können Sie sie besser darüber beraten, ob bestimmte Funktionen miteinander verbunden sind und gemeinsam durchgeführt werden sollten.
Erwägen Sie, nach Alternativen zu formalen Funktionsspezifikationen zu suchen, um Anforderungen darin zu erfassen. Prüfen Sie Optionen wie die Verwendung von User Stories, die es Client X ermöglichen, das zu vermitteln, was er möchte, in einer Sprache, die für ihn möglicherweise angenehmer ist.
3. Gesamtprojektmanagement
Es klingt so, als ob Sie ein offenes Gespräch mit Ihrem Vorgesetzten führen sollten. Wenn Ihr "Team" das Management des Projekts übernehmen soll (weil dies die Erwartung von Kunde X ist), muss klar sein, wer diese Rolle übernehmen soll. Du sollst es sein? Dann müssen Ihr Zeitplan und Ihre Fristen widerspiegeln, dass die Rolle selbst bei einem kleinen Projekt eine gewisse Zeit in Anspruch nimmt, um korrekt ausgeführt zu werden.
Sie haben hier mehr Probleme als nur eine fehlende PM-Methode. Aber andererseits hört es sich so an, als ob Ihr Client und Client X seit "Jahren" so arbeiten. Ich habe den Eindruck, dass sie nicht viel Geld in die Fähigkeiten investieren wollen, die Sie aufbauen, und vielleicht ist es nur kulturell, sich zu beschweren und zu beschweren.
Eine fehlerfreie Lieferung von irgendetwas ist unmöglich, und wenn Client X nicht mit Affen besetzt ist, ist diese Vorstellung bekannt. Ich habe also den Eindruck, dass sie sich nur beschweren, um ihre Lieferanten zu verwalten.
Ich denke, die Wahrscheinlichkeit, dass Sie hier etwas ändern, ist ziemlich gering. Es scheint, dass diese Aufstellung das Maß an Fähigkeiten und Reife ist, das sie für Ihren Bereich wünschen, dh das Investitionsniveau entspricht ihren Renditeerwartungen.
Thiago Cardoso
Lunivore
Eric Belair
jhsowter
Provokateur