Wie kann ein Kunde am besten zu einem Projekt beitragen?

Wir haben ein CRM für einen Kunden erstellt. Nachdem die erste große Phase abgeschlossen und eine zweite vereinbart wurde, möchte der Kunde einen Teil der Arbeit übernehmen und in der ersten Phase geringfügige Änderungen am Datenbankschema und den Geschäftsprozessen vornehmen, während wir die zweite Phase erstellen .

Ich bin unschlüssig, ob dies überhaupt praktikabel ist, aber wenn es so ist, möchte ich einige Hinweise, welche Maßnahmen ergriffen werden können, um dies überhaupt umsetzbar zu machen. Folgendes habe ich bisher:

• Bisher hat der Kunde das Projekt hauptsächlich aus der Sicht eines Benutzers gesehen. Es ist klar, dass ein zweiteiliges Seminar stattfinden sollte, in dem wir ihn in das Innenleben einführen:

  • Zunächst wird das vorhandene Datenbankschema angezeigt und beispielhaft erweitert.
  • Zeigen Sie dann Beispielcode an und schreiben Sie einen neuen Geschäftsprozess für die Schemaerweiterung.
• Der Code befindet sich derzeit in einem internen Subversion-Repository. Wir könnten zwar ein öffentliches oder ein öffentliches in seinem Netzwerk einrichten (mit dem wir VPN-Verbindungen herstellen können), aber ich bin der Meinung, dass ein verteiltes System besser funktionieren würde. Ich scheine der einzige zu sein, der so denkt, also könnte ich einige überzeugende Argumente verwenden.

• Ich bin nicht sicher, wie ich festlegen soll / sicherstellen soll, dass Code, der in der Produktion ausgeführt wird, festgeschrieben wird. Es scheint, als hätte "x kurz vor Urlaubsantritt eine kritische, undokumentierte Änderung vorgenommen; jetzt versucht y, diesen Bug herauszufinden, der seitdem aufgetreten ist". Katastrophen sind unvermeidlich. Im Idealfall würden alle Änderungen vor der Bereitstellung:

  • in einem Issue-Tracking-System dokumentiert sein,
  • zuerst in einer separaten Testumgebung auftreten und
  • müssen automatisierte Tests bestehen.

  Leider bezweifle ich, dass sich die Disziplin für einen von denen durchsetzen wird.

Angenommen, eine Plug-in-Architektur oder ein separates Projekt sind keine realisierbaren Optionen, da 1) die erste nicht existiert und 2) die zweite dem Client verbietet, vorhandenen Code zu betrachten und möglicherweise zu ändern auf etwas bestehen.

Dies wird die am wenigsten bevorzugte Antwort sein - aber hier ist sie doch!

Es ist riskant (genauso wie es einem Neuling erlaubt, ein brandneues Auto zu fahren) - aber es ist keine schlechte Idee.

Verstehen Sie, warum sie dies tun wollen: Es ist nicht so, dass sie über freie Ressourcen verfügen, sondern nur, um sich unter Kontrolle zu fühlen.

Was Sie tun müssen, ist Folgendes:

1. Informieren Sie Ihren Kunden - Software ist mehr als ein Code. Wenn sie teilnehmen möchten, lassen Sie sie zunächst architektonische Aspekte, Entwürfe usw. überprüfen. Stellen Sie Fragen an sie und zeigen Sie ihnen die Auswirkungen der Entscheidungen, die sie getroffen haben.

2. Sie sollten immer mit Optionen zu Vor- und Nachteilen bei Ansätzen zurückgehen (und diese Besprechungen gut dokumentieren), aber Sie sollten zulassen, dass sie Entscheidungen treffen. Zumindest werden sie zu schätzen beginnen, dass sie nicht viel wissen - oder sich selbst zu eigen machen.

3. Sie können separate Bereiche erstellen, z. B. Zweige, damit sie in der Lage sein müssen, alles zu codieren, was sie möchten. Vor dem Festschreiben oder Zusammenführen sollten die Dinge ordnungsgemäß getestet werden.

Obwohl ich weiß, dass Komplikationen auftreten können, ist jedes Problem eine Chance. Wenn alles gut geht, wird Ihr Kunde tatsächlich mehr Wertschätzung für interne Probleme entwickeln und ein besseres Vertrauen entwickeln, weil er weiß, wie Sie gute Arbeit geleistet haben!

PS: Um Ihnen einen Einblick zu geben - ich komme aus Indien; und ich kenne sehr viele IT-Shops, in denen das Management nicht wirklich viel Ahnung hat. Normalerweise stört es sie nicht, dass der Kunde zusätzliche Ressourcen einsetzt, um sicherzustellen, dass das Projekt nicht in den Mülleimer fällt. Das funktioniert gut für sie; Sie alle gehen mit einer Einstellung "Was auch immer Sie sagen, Sir!". Das soll nicht meinen eigenen Landsmann erniedrigen, sondern zeigen, dass gemeinsame Entwicklung keine so schlechte Idee ist. Es ist schließlich, was viele Management-Gurus darstellen, " Prosumer-Ansatz " für geschäftliche Probleme.

Autsch ... Sie haben die richtige Idee, aber ich habe gesehen, wie chaotisch dies werden kann, und beide Parteien leiden erheblich. Ich betreue derzeit eine solche Anwendung.

Finden Sie die wahren Gründe heraus, warum der Kunde es für notwendig hält, direkt zum Projekt beizutragen. Wollen sie das Projekt jetzt schneller fertigstellen, als Sie es realistisch umsetzen können? Möchten sie bereits Änderungen, haben aber Angst, dass Ihnen zusätzliche Kosten entstehen, wenn Sie technische Änderungen vornehmen oder zusätzliche Funktionen anfordern? Befindet sich in ihrer Organisation ein politischer Kampf, bei dem interne Entwicklungsressourcen mehr Kontrolle und Input in das Projekt einbringen möchten, oder bei dem sie eine beschäftigte Arbeit für interne Entwickler suchen? (dieser letzte Treffer trifft für mich in der Nähe von zu Hause)

Finden Sie heraus, was ihre wahren Beweggründe sind, und sprechen Sie sie an, wenn dies überhaupt möglich ist. Die Tatsache, dass sie es sogar vorschlagen, ist ein riesiges Warnsignal dafür, dass Probleme die Straße hinunter kommen. Versuchen Sie, ihre wahren Bedenken zu zerstreuen, bevor Sie sich auf so etwas einigen, denn es wird höchstwahrscheinlich passieren, dass sie die Kontrolle über das Projekt stärken und Sie auslaufen lassen, oder sie werden massives Chaos und ein gescheitertes Projekt verursachen.

EDIT: Leider ist dieses Schiff für Sie gesegelt, aber verzweifeln Sie noch nicht. Es gibt immer noch Dinge, die Sie tun können, um die Schmerzen, die auftreten werden, stark zu minimieren. Stellen Sie auf jeden Fall sicher, dass es sich um EINEN UND EINZIGEN PROJEKTMANAGER und PRODUKTBESITZER handelt und dass diese Person mit Ihrer Organisation / Firma verbunden ist. Diese Person muss in der Lage sein, Sprints zu planen, User Storys aufzunehmen oder zu entfernen und Aufgaben den Ressourcen in Ihrem Unternehmen sowie dem Unternehmen Ihres Kunden zuzuweisen. Stellen Sie in jedem Fall sicher, dass die Entwicklungsressourcen in Ihrem Unternehmen nicht unabhängig von den Ressourcen Ihrer Kunden arbeiten und, was noch wichtiger ist, NICHTErmöglichen Sie Entwicklern in Ihrem Unternehmen, ihren Projektmanagern oder Produktbesitzern Bericht zu erstatten! Sie werden entweder die vertraglich nicht abgedeckte freie Arbeit voll ausnutzen oder Sie aus Ihrem eigenen Projekt herausholen. Es ist eine Gewissheit.

Aus juristischer Sicht fragen Sie sich im Grunde: "Wie kann man einen Esel mit verbundenen Augen durch ein Minenfeld reiten?"

Aus Sicht der Programmierung würde ich um weitere Informationen bitten. Kann das, was der Client wünscht, mit einem benutzerdefinierten EAV-System oder mit Hooks implementiert werden, die dem System hinzugefügt werden können? Im Idealfall möchte ich den Client-Code aus verschiedenen Gründen so weit wie möglich von Ihrem trennen.

Jemand, der normalerweise die Rolle des Kunden spielt, der sich einschaltet. Ich hätte dieses Problem ehrlich gesagt nicht, denn wenn es so weit gekommen wäre, wären Sie in meiner Quellcodeverwaltung, wenn Sie mein CI-Setup und mein QA-Setup verwenden, um Dinge zu testen. Diese Vereinbarung kann ziemlich schwierig zu treffen sein - ich bekomme viel Rückstoß von den Beratern, vor allem, wenn es darum geht, Dinge in Gang zu bringen. Es scheint, dass Prozessstörungen mit abrechenbaren Stunden einhergehen.

Ich denke, deine Perspektive ist ehrlich gesagt etwas verzerrt. Denken Sie zunächst daran, dass dies nicht Ihre Codebasis ist, sondern unsere Codebasis. Zweitens: In den meisten Fällen ist der IT-Shop auf Kundenseite wesentlich motivierter, dafür zu sorgen, dass dieses Produkt wie geplant funktioniert und auch in Zukunft einfach zu warten, zu verwalten und zu unterstützen ist. Im Gegensatz zu den meisten Beratern ist es für uns nicht mehr möglich, zur Fehlerbehebung zurückzukehren. Darüber hinaus ist es weitaus wichtiger, Dinge so zu gestalten, dass sie leicht konfigurierbar sind und auf vorhersehbare Weise versagen, wenn Sie auch Eigentümer der operativen Seite der Medaille sind. Es kann sein, dass Sie am Ende ein Projekt von höherer Qualität haben, da ein Teil des Entwicklungspersonals nicht durch abrechnungsfähige Stunden eingeschränkt ist.

Was die Funktionsweise angeht, ist DCVS definitiv der richtige Weg, wenn dies möglich ist. Die Wahl von etwas Neutralem (Bitbucket, Github) kann helfen. Es ist auch ein Glücksfall, wenn CI installiert ist - es ist schwieriger, Probleme zu lösen, wenn alle wissen, dass sie beim letzten Commit nicht mehr funktionieren. Wenn Sie die Bereitstellung von Dingen über CI erzwingen können - etwas, das wir normalerweise Lieferanten aufzwingen müssen - können Sie wirklich sicherstellen, dass alle Änderungen übernommen werden. Haben Sie, was das Training betrifft, überlegt, für ein paar Tage eine Partnerschaft mit dem Kunden einzugehen? Das könnte ein guter Weg sein, um die seitlichen Bindungen herzustellen, die Sie benötigen. Insgesamt ist die beste Wette, alle davon zu überzeugen, dass sie zur selben Mannschaft gehören. Weil sie im selben Team sind.

Es scheint, als sei dies ein Managementproblem, da es sich um ein technisches Problem handelt. Mit solchen Situationen habe ich mich sowohl in Beratungs- als auch in Softwarefirmen befasst. Aus einer Gesamtsumme "Wie viel Wert wird der Kunde aus der Software ziehen?" und "Wie viel Aufwand brauche ich, um die Postproduktion aufrechtzuerhalten?" das ist eigentlich eine gute situation für dich. Viele Kunden bestehen darauf, dass ihre Mitarbeiter einbezogen werden. Es wird jedoch eine Menge Arbeit erfordern.

Beginnend mit dem Ziel, benötigen Sie ein gutes Statement of Work . Dies listet auf, wofür Sie aufgelegt sind und wofür sie aufgelegt sind. Eine Rollen- und Verantwortlichkeitsmatrix ist ein weniger legalistisches Dokument, das beschreibt, wem jedes Element gehört, wer beteiligt ist und wer nur informiert werden muss. Beides setzt voraus, dass Sie eine genau definierte Projektstrukturplanstruktur haben , die auf einer niedrigen Ebene (niedrig genug, um abzuschätzen) auflistet, was jede Aufgabe ist.

In Bezug auf die Erstellung ist es normalerweise die umgekehrte Reihenfolge: Umfang (den Sie eindeutig bereits haben) -> PSP (den Sie möglicherweise haben) -> Rollen- und Verantwortlichkeitsmatrix -> SOW.

Sobald Sie den Eigentümer klar definiert haben, ist es Zeit, den Code und die Umgebungen zu verwalten. Ich bin ziemlich agnostisch in Bezug auf Code-Management-Tools. Was ich sagen werde ist, dass es wichtig ist, eine Codeüberprüfung für alles, was von jemandem außerhalb des Kernteams durchgeführt wird, durchzuführen. Wenn das von Ihnen verwendete Tool dies kennzeichnet, ist dies umso besser. Sie möchten vermeiden, dass jemand etwas einklemmt, das den zuvor getroffenen wichtigen Architekturentscheidungen widerspricht. Das 4-Augen-Konzept (2 zusätzliche Augen, die alles überprüfen) ist die wichtigste taktische Entscheidung, die Sie treffen können.

Das Management von Umgebungen ist ebenfalls schmerzhaft. Normalerweise habe ich Situationen erlebt, in denen "Wir arbeiten an unserer Umgebung, wenn wir fertig sind" und sowohl der Verkäufer als auch der Kunde sich durchkämpfen. Ihre Situation klingt komplexer. Ich rate Ihnen, einen Weg zu finden, wie sie in Ihrer Umgebung arbeiten können, bis das Projekt abgeschlossen ist. Wenn Sie einen Weg finden, um den Kunden in der Verwaltung seiner Umgebungen zu schulen (nehmen Sie nicht an, dass er darin gut ist), dann umso besser.

Ein paar andere Vorbehalte ...

1. Gehen Sie nicht davon aus, dass der Kunde die gleiche Produktivität hat wie Ihr Team. (Sie werden Überraschungen in Bezug auf die Domain-Kenntnisse und Überraschungen in Bezug auf die Geschwindigkeit Ihrer Software erleben.)

2. Gehen Sie nicht davon aus, dass der Kunde Ihre Methodik kennt.

3. Gehen Sie nicht davon aus, dass der Kunde die Arbeitsmoral Ihres Teams teilt. (Ich habe Überraschungen sowohl nach oben als auch nach unten gesehen.)

4. Verbringen Sie viel Zeit mit dem Training und dem Zusammenfinden.

5. Jede Stunde, die Sie dem Kunden für die Fehlerbehebung beibringen, spart in Zukunft viele Tage.

6. Nutzen Sie den Kunden, um die interne Organisation für Sie zu durcharbeiten und Experten für inhaltliche und fachliche Fragen zu finden.

7. Nutzen Sie den Kunden, um seine Organisation auszubilden.

8. Wenn Sie Kunden standardmäßig in Ihren Entwicklungsprozess einbeziehen, werden Sie gezwungen, wie ein professionelles Dienstleistungsunternehmen zu denken. David Maister hat das beste Buch zum Thema geschrieben. Auch wenn nur 20% für Sie relevant sind, ist es eine Lektüre wert.

Trotz all dieser Einschränkungen können Kunden in Ihren Teams Wunder bewirken, dass Sie Ihren Käufern näher kommen. Bei diesen Kunden handelt es sich wahrscheinlich um zukünftige Referenzen. Viel Glück dabei, das Beste aus dieser Situation zu machen!

Ihr Kunde sollte auf jeden Fall eine Einweisung in die Einrichtung erhalten, es sollte eine Voraussetzung für die Abmeldung in der ersten Phase gewesen sein. Sie sollten erneut zulassen, dass Ihr Kunde etwas direkt bearbeitet. Er sollte eine Änderungsanforderung ausfüllen, die in Ihr Issue-Tracking-System eingegeben und mit dem Rest der Arbeit priorisiert wird. Es liegt an Ihnen und Ihrem Kunden, zu entscheiden, welche Anfragen nicht zum Vertragsumfang gehören. Wie dies geschieht, sollte in einer Art Workflow / Dokument für das Änderungsmanagement festgelegt werden. Wenn eines nicht vorhanden ist, empfehle ich Ihnen dringend, ein solches zu erstellen und Ihren Kunden zu veranlassen, zuzustimmen, dass dies der Prozess ist, durch den er die Dinge ändern und einarbeiten kann Schreiben. Sonst kann man nicht viel anderes tun, als zu beten. Nichts geht schief.