Nur um einen Kontext zu geben: Es gibt ein Offshore-Team in Indien für einen Kunden in San Francisco. Das Offshore-Team besteht aus etwa 9 Entwicklern und 4 QA mit einem Projektmanager. Ich übernehme die Vor-Ort-Koordination für dieses Team vom Kundenstandort aus. Bei jedem Sprint (2-wöchige Iteration) gehe ich den Stories vorher nach, verstehe sie und gebe während ihrer Story-Time einen Überblick. Ich kläre auch die Eckfälle für sie, um sicherzustellen, dass jede Anforderung klar ist und der Umfang auch gut definiert ist. Trotzdem gibt es Fälle von Überraschungen, die sowohl bei den Anforderungen als auch beim Umfang auftauchen (meine Pech, einverstanden!). Wir haben auch damit begonnen, Mock-ups für jede UI-Story zu versenden. Aber stattdessen bemüht sich das Team dort nicht um ein Brainstorming und versteht die Anforderung im Voraus, sondern sie fangen sofort an, ohne das richtige Verständnis zu haben.
Am Ende des Sprints (1/2 Tage vorher) stellen sie dieselben Fragen, die durch das Mock-up und die während der Storytime und den anschließenden Mails geklärt wurden. Wenn ich schließlich ja sage, das soll gemacht werden usw., sagen sie, das sei vorher nicht geklärt worden. (Woher weiß ich, dass diese Frage ihnen angezeigt wird?)
Sie schaffen es offensichtlich nicht, Sprint für Sprint abzuliefern. Der Manager dort versteht nicht einmal ein Stück Entwicklung, da er QA ist, und hat keine Kontrolle über das Projekt (leider wurde er zum Manager desselben Teams befördert, als er versuchte zu kündigen - was bei indischen Dienstleistungsunternehmen häufig vorkommt). Und dieser Manager versucht nicht einmal zu verstehen, dass der Entwickler oder die Qualitätssicherung keine angemessene Planung, kein Brainstorming oder zusätzliche oder geringe Anstrengungen unternommen hat, um ein Feature und seine Konsequenzen zu verstehen, und kommt direkt zu dem Schluss, dass die Anforderungen nicht klar sind. Der Manager verbringt auch nicht genügend Zeit mit dem Team und er verbringt Zeit woanders beim Ausgehen! (seltsam, vom Hörensagen!)
Es gibt auch einen erheblichen Mangel an technischem und Produktwissen über Entwicklung und QA, und es werden keine Schritte unternommen, um dies zu verbessern. In der ersten Woche höre ich, dass sie alle frei sind, in der zweiten Woche ändern sich die Dinge drastisch - ich schätze, das ist, wenn sie anfangen zu arbeiten. Mit jedem Sprint wird es schlimmer und es werden nur harsche Kommentare und E-Mails ausgetauscht. „Anforderungen nicht klar“ scheint der einfache Ausweg zu sein, und das Team dort hat sich daran gewöhnt, dies zu sagen, um seine Unfähigkeit zu kompensieren.
Ich kann das nicht erklären, da sie bei dieser einfachen Entscheidung eine Gruppe bilden und mit mehreren unhöflichen E-Mails abprallen. Was würden Sie tun, um diese Dinge richtig zu machen? Wie viel von angemessen ist angemessene Klarheit in der Anforderung? Ich bin mir da wirklich unsicher. (Die Teams in SFO sind ziemlich klar mit der noch geringeren Menge an Erläuterungen zu den Anforderungen.) Wie kann ich das richtig einstellen? Ist meine Vermutung bezüglich des Offshore-Teams richtig? (Entschuldigen Sie, dass ich zu ausführlich bin!)
Keine Garantie dafür, aber hier ist, was ich versuchen würde:
Entweder verstehen sie Ihre Dokumente nicht oder sie machen die Arbeit nicht und benutzen die Dokumente als Sündenbock. Es ist ein wenig extrem, aber bitten Sie um eine Wiederholung Ihrer Dokumente zusammen mit dem erwarteten Ansatz. Holen Sie sich dies bis zum nächsten Tag als Vorstufe, damit sie mit der Arbeit am Sprint beginnen können. Dies wird das Brainstorming formalisieren, das sie durchführen sollen, und unter den gegebenen Umständen denke ich, dass dies ein notwendiger Schritt ist.
Führen Sie eine ehrliche Bewertung Ihrer Dokumente durch, um festzustellen, ob sie mit einem angemessenen Englischniveau verfasst sind. Der klügste Entwickler kann die Erwartungen nicht erfüllen, wenn die Sprachanforderungen über das Angemessene hinausgehen. Es ist viel einfacher, komplizierte Dokumente zu schreiben als einfache, und es erfordert kontinuierliche Anstrengung.
Es hört sich so an, als hätten Sie während des gesamten Sprints keinen Kontakt zu ihnen? Wenn das der Fall ist, muss es geändert werden, damit Sie nicht 1/2 Tag vor dem Ende des Sprints feststellen, dass die Dinge aus dem Ruder laufen. Sie benötigen ein dokumentiertes tägliches Engagement für ihre Fortschritte und Probleme.
Angesichts der Unzufriedenheit, die Sie mit ihren technischen Fähigkeiten und ihrer Kommunikation haben, scheinen Sie nicht in der Lage zu sein, die Beziehung zu beenden. Können Sie den Kunden dazu bringen, Druck auf ihn auszuüben, mehr sachkundige Ressourcen für das Projekt einzusetzen?
Diese Situation kann keine Überraschungen in den Anforderungen und im Umfang bieten. Sie müssen das dem Kunden erklären und sicherstellen, dass es einfach nicht passiert. Indem Sie es zulassen, verringern Sie die Wahrscheinlichkeit, dass ein herausgefordertes Team liefert, und geben ihm etwas, das es gegen Sie verwenden kann.
Schließlich ist es am schwierigsten, ehrlich einzuschätzen, ob Sie Ihren Arbeitgeber um Hilfe bitten müssen. Mit Sprint um Sprint verpasst geht das schon eine Weile so. Es ist schmerzhaft zuzugeben, dass eine Situation außerhalb unserer Erfahrung liegt, aber viel besser, als darauf zu bestehen, dass wir es können, und dann zu scheitern.
Ich stimme Michael und Mark vollkommen zu. Beide haben das Problem mit der Bitte um eine Neuformulierung Ihrer Dokumente zusammen mit ihrer erwarteten Vorgehensweise auf den Punkt gebracht . Sie verstehen die Anforderungen eindeutig nicht. Das Problem ist ... versuchen sie vorher zu verstehen? Wenn sie die Anforderungen nicht analysieren und direkt zum Entwickler springen, werden sie es später schwer haben.
Eine Sache, die Sie berücksichtigen müssen, ist der kulturelle Unterschied vor Ort. Es gibt HIER ein erstaunliches Video von Robert Dempsey , in dem er über kulturelle Unterschiede spricht und ein kleines Detail hervorhebt, das alles verändern kann: Inder sind es nicht gewohnt, „nein“ zu sagen, selbst wenn sie nicht verstehen, wovon Sie sprechen (ich bin es aus Brasilien und ich weiß, dass ähnliches auch hier passieren kann).
Es gibt einen weiteren Punkt, den Brooks (wenn ich mich nicht irre) in seinem TMMM erwähnt : Es ist unwahrscheinlich, dass Sie einen haben, der Fragen aufwirft, wenn Sie Raum haben, Dinge anzunehmen . Es kann mit dem ursprünglichen Problem übereinstimmen, Anforderungen sind nicht klar. Wenn Sie also die Anforderungen mit ihnen durchgehen, stellen Sie sicher, dass Sie trennen, was sie von den Anforderungsdokumenten verstanden haben und was sie auf der Grundlage dieser angenommen haben.
Sie haben sicherlich ein Problem. Letztendlich liegt das Problem bei Ihnen, auch wenn das Team aus totalen Faulpelzen besteht. Sie sind für die pünktliche Lieferung verantwortlich; Das Team ist nur Ihnen gegenüber rechenschaftspflichtig. Ich bin mir nicht sicher, ob Offshore/Onshore relevant ist; Ich bin mir nicht sicher, ob viele der oben genannten Details relevant sind (abgesehen davon, dass wir gefragt hätten, wenn Sie sie nicht bereitgestellt hätten). Was aus POV relevant ist, ist, dass Ihr Team ständig nicht liefert. Was sind die Folgen dieses Scheiterns? Was sind die Konsequenzen für das Projekt? Was sind die Folgen für die Stakeholder? Die Folgen für das Team? Und was sind die Folgen für Sie?
„Unser Versanddatum liegt jetzt 4 Wochen über unserer Basislinie. Wenn Team India nicht in Sprint 7 liefern kann, verschiebt sich dieses Datum um weitere zwei Wochen. Wenn die Verzögerung 8 Wochen erreicht, beträgt das Risiko, dass das gesamte Projekt nicht geliefert wird, 50 % . Wenn wir dieses Risiko mindern wollen, können wir ein anderes Entwicklerteam beauftragen, die Arbeiten zu übernehmen, die derzeit für Team India geplant sind.“
Bevor ich anfange, sollte ich erwähnen, dass ich in den letzten 10 Jahren Indien-Teams mit einer Größe von bis zu 180 in über 100 Projekten geleitet und genau dieselben Probleme durchgemacht habe. Es ist in jedem Projekt entscheidend, die richtigen Fähigkeiten für das jeweilige Projekt zu finden, aber in Indien ist es aufgrund von Kultur, Kommunikation, Zeitunterschieden usw. zehnmal wichtiger.
Andere Poster haben auf die Hauptprobleme hingewiesen;
Was ich getan habe, das funktioniert, ist, mindestens einen indischen Top-Entwickler (oder Manager) zu finden, der das Team leitet, Kommunikation ist das Hauptanliegen, dann technische Kompetenz. Ohne diesen Manager wird es sehr schwierig sein, erfolgreich zu sein. In der Zwischenzeit werden Sie von 23:30 bis 3:00 Uhr oder von 6:00 bis 9:00 Uhr aufstehen, um direkt mit den Entwicklungs- und QA-Managern zu arbeiten/zu koordinieren/zu betreuen/zu schulen. Ihre andere Alternative besteht darin, die ???? aus allem heraus annehmen, dass sie so gut wie nichts über alles wissen und entsprechend dokumentieren. Es mag hart klingen, aber es ist Realität. Sie müssen dann alle Ausgaben ständig überprüfen. So oder so für ein 14-köpfiges Team wird es ein Fulltime-Job sein. Eine andere Möglichkeit besteht darin, einen Auftragnehmer einzustellen, der es gewohnt ist, mit indischen Teams zusammenzuarbeiten, um die Bemühungen zu leiten. Es ist eine Kunst, effektiv mit indischen Ressourcen zu arbeiten.
Diesen Top-Manager/Entwickler zu finden, das ist eine ganz andere Frage...
Eine Welt
Eine Welt
Ashok Ramachandran
Eine Welt
Mondfliege