Wie soll mein Unternehmen mit Auftragnehmern umgehen, die unsere technische Anleitung ignorieren?

Wir werden das Ziel des Projekts nicht erreichen können, ohne dieses Problem zu lösen

Das ist überhaupt nicht wählerisch. Es geht darum, funktionierende Software zu liefern – wenn Entwickler Software liefern, die nicht funktioniert, machen sie es falsch.

Mein Vorgesetzter ist auch der gleichen Meinung

Das ist gut - es bedeutet, dass es nicht nur in der Lage sein sollte, in eine "Mithridates sagte, Auftragnehmer sagte"-Diskussion auszuarten.

Wie kann ich sicherstellen, dass unsere Auftragnehmer die technischen Kommentare und unsere Vorschläge in ihre Entwicklung einfließen lassen, ohne unhöflich zu sein oder als jemand zu wirken, der zu pingelig ist?

Fragen Sie sie einfach, wie sie die Probleme mit der aktuellen Implementierung lösen wollen. Es gibt drei realistische Möglichkeiten, wie sie reagieren:

• Sie schwafeln weiter, ohne eine klare Erklärung zu geben. In diesem Fall müssen Sie sie zu einer klaren Antwort drängen – das ist zwar direkt, aber nicht unhöflich.
• Sie beschreiben einen Weg nach vorne, der sich von Ihrer Lösung unterscheidet, aber Ihrer Meinung nach machbar ist. Hier müssen Sie ihnen wahrscheinlich einen kleinen Spielraum lassen, um zu zeigen, dass ihre Lösung funktionieren kann; Ich würde vorschlagen, es zeitlich einzugrenzen und zuzustimmen, zu Ihrer Lösung zu wechseln, wenn sie ihre Lösung nicht zum Laufen bringen können.
• Sie stimmen zu, Ihre Lösung zu implementieren. Alles ist gut.

Im schlimmsten Fall können Sie entscheiden, dass der Auftragnehmer nicht die richtige Person für den Job ist. In diesem Fall müssen Sie mit Ihrem Vorgesetzten darüber sprechen, wie Sie ihn durch eine geeignetere Person ersetzen können.

Es gibt einen wichtigen Punkt, der in Bezug auf Ihre technische Anleitung angesprochen werden muss. Das ist:

Funktioniert die Software tatsächlich und macht sie das, worum Sie sie gebeten haben, in Bezug auf die tatsächliche Reaktion auf Benutzereingaben?

Wenn die Antwort „nein“ lautet, geben Sie ihnen tatsächliche Fehlerberichte – was die Software tut und was Sie unter verschiedenen Umständen von ihr erwartet haben. Dies unterscheidet sich stark von "technischen Richtlinien". Sie sollten damit rechnen, dass diese Fehler behoben werden.

Wenn die Antwort ja lautet, funktioniert es, und Ihre technische Anleitung lautet, dass Sie sagen: "Wir würden es vorziehen, wenn der Code intern so funktioniert hätte", dann können Sie sie nicht wirklich dazu bringen, Dinge zu ändern. Sie haben nach Code gefragt, der etwas bewirkt hat, und sie haben Code geliefert, der dies bewirkt hat. Natürlich ist es anders, wenn Sie ihnen im Voraus (und am besten schriftlich) gesagt haben, dass Sie etwas auf eine bestimmte Weise machen möchten – dann können Sie sie vernünftigerweise bitten, Änderungen vorzunehmen, damit es so funktioniert, wie Sie es ihnen gesagt haben. Wenn Sie das nicht getan haben und die Dinge auf eine bestimmte Weise erledigt haben wollten, dann gibt es dort eine Lektion, die Sie Ihren Anforderungen im Voraus mitteilen sollten.

Haben Sie eine DOD (Definition of Done)? Enthält es UAT?

Im Umgang mit Drittanbietern finde ich es sehr hilfreich, eine ausdrücklich ausgeschriebene Definition of Done zu haben. Die Story ist erst fertig, wenn sie der zuvor vereinbarten Definition of Done entspricht.

Beinhaltet Ihre Definition of Done Benutzerakzeptanztests? Wenn dies der Fall ist, erstellen Sie einen Fehler, der das Problem ausdrückt, und lassen Sie die Story-/Feature-Anfrage offen, bis es behoben ist.

Wenn Sie kein DOD haben oder es kein UAT enthält, dann lassen Sie eines schreiben und holen Sie sich die Zustimmung aller. Wenn Sie dann vorankommen, haben Sie Kontrollen, um das durchzusetzen, was Sie brauchen, und sicherzustellen, dass das Projekt auf Kurs bleibt.

Wie kann ich sicherstellen, dass unsere Auftragnehmer unsere Anleitung in ihre Entwicklung einbeziehen, ohne unhöflich zu sein oder als jemand zu wirken, der zu wählerisch ist?

Ich würde dem Auftragnehmer Zeit geben, Ihre Lösung umzusetzen. Sie brauchten Ergebnisse, die sie präsentieren konnten, und vielleicht war das alles, was sie tun konnten, bis sie sich mit Ihrer Lösung auskennen. Nirgendwo in Ihrer Frage heißt es, dass die Verwendung Ihrer Lösung obligatorisch war.

Wenn es beim nächsten Meeting nicht umgesetzt wird, wäre der richtige Zeitpunkt, es voranzutreiben, stellen Sie sicher, dass Sie Ihren Vorgesetzten auf Ihrer Seite haben. Im Idealfall sorgt Ihr Vorgesetzter dafür.

Es hängt vielmehr von dem Vertrag ab, den Ihr Arbeitgeber mit dem Auftragnehmer hat.

Der Vertrag kann festlegen, was sie zu liefern haben und in welchem ​​Zeitraum. Sie arbeiten auf ihre Weise an dem Projekt.

Dann sagt ihnen ein Mitarbeiter ihres Kunden, dass sie es falsch machen, und sagt ihnen, wie sie ihre Arbeit machen sollen. Ihre Antwort ist, höflich zuzuhören, es dann zu ignorieren und weiterzumachen wie bisher.

Realistischerweise besteht Ihre Aufgabe möglicherweise darin, sicherzustellen, dass das, was sie liefern, den angegebenen Anforderungen entspricht, und sonst nichts.

Ich bitte Sie, zwei Dinge zu beachten.

Erstens muss gute Software:

1. Tue das Richtige
2. ...aus den richtigen Gründen...
3. ... so offensichtlich wie möglich.

Wenn eine Software auch nur eines dieser drei Kriterien nicht erfüllt, handelt es sich um einen kompletten Ausfall, Punkt.

Die Leute liegen falsch , wenn sie sagen: „Wenn die Software das richtige Erlebnis erzeugt, ist sie gut genug.“ Das ist 100% falsch. Warum? Denn wenn es sich nicht um einmalige Software handelt, die Sie später wegwerfen, muss der Quellcode qualitativ hochwertig sein, damit der langfristige Besitz kein Albtraum ist: Er muss einfach zu verstehen, zu ändern und zu verbessern sein . Wenn der Quellcode also um schlecht passende Konzepte herum organisiert ist oder wenn er mit problematischen Anti-Patterns gefüllt ist, bedeutet das, dass Sie ein Stück Müll kaufen.

Es ist ein Fehler, sich darauf festzulegen, wessen Implementierung verwendet wird. Aber:

• wenn eine Implementierung klarer ist als die andere, ist sie besser;
• Wenn eine Implementierung mehr Best Practices Ihres Unternehmens einhält als die andere, ist sie besser;
• Wenn eine Implementierung um die gleichen erstklassigen Geschäftskonzepte herum organisiert ist, die vom Rest Ihrer Organisation verwendet werden, und die andere nicht, ist es besser; usw.

Zweitens sollen Auftragnehmer Software bauen, die alle Anforderungen erfüllt. Abgesehen von allen anderen Argumenten darüber, was Software „gut genug“ macht, können Sie den Auftragnehmer immer noch an die geschäftlichen Anforderungen binden: Wenn nicht alle zufrieden sind, hält der Auftragnehmer seinen Teil der Abmachung nicht ein. Sie geben an:

Es gibt ein Problem mit der aktuellen Implementierung

Und:

dennoch zeigten sie [fehlerhafte] Ergebnisse, die von ihrer alten Implementierung erzeugt wurden

Es ist also ziemlich klar, dass Ihr Auftragnehmer nicht einmal das erste Element des oben genannten Dreiklangs erfüllt: Seine Software tut nicht das Richtige .

Angesichts dieser Tatsache sind ihre Gründe irrelevant: Es gibt keine Begründung, die die Lieferung von Software rechtfertigen könnte, die ihren Zweck nicht erfüllt.

Vielleicht hat der Auftragnehmer eine andere Lösung als Ihre im Sinn; gut: Sie haben das Recht, sich von ihnen ausführlich über ihren Plan informieren zu lassen, bevor sie Ihr Geld und Ihre Zeit für die Umsetzung aufwenden. Nehmen Sie kein „Nein“ als Antwort!

Aber Sie müssen unvoreingenommen zu diesem Treffen gehen: Vielleicht ist ihre Lösung besser als die, in die Sie verliebt sind, oder nicht weniger gut. Verlieren Sie nicht das Wesentliche aus den Augen: Tut die Software das Richtige, aus den richtigen Gründen, auf möglichst offensichtliche Weise? Wenn die Antwort ja ist, müssen alle zufrieden sein; Wenn die Antwort nein ist, bleibt mehr Arbeit. Niemandes Ego spielt dabei eine Rolle.

Die meisten anderen Antworten haben sich auf "die Software muss funktionieren" konzentriert, um zu erfahren, warum Ihr Fix durchgeführt werden sollte. Ich werde hier eine abweichende Meinung vertreten.

Die gesamte Software muss jederzeit funktionieren

Ihre Auftragnehmer sind für die gesamte Software verantwortlich, nicht nur für die eine fehlende/falsche Funktion, die Sie gefunden haben.

Es ist durchaus möglich, dass Ihre Lösung für das spezifische Problem, mit dem Sie es zu tun haben, funktioniert, aber an anderer Stelle Auswirkungen hat. Vielleicht unterbricht es andere Funktionen; oder vielleicht ist es funktional in Ordnung, hat aber Leistungsprobleme, was bedeutet, dass es nicht skaliert, wenn Sie eine Million Benutzer oder eine Million Datenpunkte haben; oder vielleicht ist es nur eine Lösung für sonnige Tage und berücksichtigt keine Fehler-/Ausnahmebehandlungsbedingungen; oder vielleicht verwendet es eine Bibliothek, die Sie legal nicht in eine veröffentlichte Version aufnehmen können.

Das Wichtigste, was Sie ihnen gegeben haben, ist ein klarer Beweis dafür, was das Problem tatsächlich ist. Wie sie eine produktionsreife Lösung für dieses Problem finden, ist ihre Aufgabe. Es ist schließlich buchstäblich das, wofür Sie ihnen Geld zahlen. Sie müssen nur die erwarteten Ergebnisse und Fristen festlegen.

Sie müssen entscheiden, ob dies ein Sprint ist oder nicht

Wenn es sich um einen Sprint handelt, sollte das, was sie tun, zu Beginn des Sprints festgelegt worden sein. Wenn Sie etwas Neues mitgebracht haben, dann geht es in den nächsten Sprint.

Wenn Sie den Sprint stoppen und ihn stattdessen etwas anderes tun lassen, ist das machbar – aber es erfordert mehr Diskussionen, als nur einen Lösungsvorschlag zu senden. Und wenn Sie möchten, dass Ihr Fix dem Sprint hinzugefügt wird (was im Allgemeinen nicht so funktioniert, wie Sprints funktionieren), ist das auch machbar – aber auch hier brauchen Sie viel mehr Diskussion. Sie müssen eine klare Zustimmung von Ihrem Vorgesetzten, seinem Vorgesetzten und seinen Ingenieuren erhalten. Normalerweise beinhaltet das ein Treffen, bei dem alle darüber sprechen. Es muss auch erwartet werden, dass jemand, der mitten im Sprint von etwas anderem abzieht, einen gewissen Kontextwechsel für ihn mit sich bringen wird, was etwas weniger effektiv sein wird.

Im Grunde geht die erforderliche Diskussionsebene weit über das bloße „Versenden eines Notizbuchs“ hinaus.

Und Sie müssen ein leitender Ingenieur sein

Ich mache mir Sorgen um den Satz

ohne klar zu erklären warum.

Wenn dies ein 1000-Meter-Übersichtsmeeting für das Management ist, würde ich nicht erwarten, technische Fragen zu diskutieren. Aber wenn dies ein technisches Treffen zwischen Ingenieuren ist - und das ist sicherlich ein Sprint-Abschluss-Meeting! - dann würde ich das sicher tun. Eine Diskussion bedeutet nicht, dass sie nur Informationen über Sie abgeben sollten. Es ist ein Gespräch. Wenn Sie Fragen haben, müssen Sie die verdammten Fragen stellen!

Als Ihr Vorgesetzter fände ich es inakzeptabel, wenn einer meiner leitenden Ingenieure eine technische Diskussion über das Gelieferte miterlebt und erst danach sagt: „Das fand ich nicht richtig, aber ich wollte nichts sagen“. Wenn Sie ein leitender Ingenieur sind, besteht Ihre Aufgabe darin, die technischen Details im Auge zu behalten und genug darüber zu wissen, was Ihre jüngeren Ingenieure (oder Auftragnehmer) tun. Wenn Sie nicht fragen, wer sonst wird es tun?

Ich bin auch besorgt darüber, dass Sie den Sprint-Planungsprozess nicht zu respektieren scheinen. Du kannst nicht einfach etwas mitten im Sprint hinschmeißen und erwarten, dass es passiert.

Beim Dienstalter als Ingenieur geht es nicht nur darum, wie gut Sie als Ingenieur sind, sondern auch darum, wie gut Sie Ihre Erfahrung einsetzen können, um Ihr Team zu stärken. Eine unangenehme Wahrheit ist, dass Sie, je älter Sie werden, desto weniger Zeit damit verbringen, Ihre eigene Arbeit zu erledigen, und desto mehr Zeit damit verbringen, anderen Menschen aus Löchern zu graben. Es sieht so aus, als ob Sie die technische Seite geklärt haben, aber Sie können noch etwas Übung auf der Seite der Teamführung gebrauchen.

Es ist alles ein Lernprozess

Die positiven Elemente, die Sie daraus mitnehmen können, sind eine Strategie für das nächste Mal. Erstens müssen Sie eine angemessene Zustimmung für die von Ihnen vorgeschlagenen Änderungen erhalten. Und zweitens müssen Sie keine Angst haben, Captain Awkward zu sein, wenn es so aussieht, als würde jemand versuchen, eine klare Antwort zu geben.