Sind die Prozesse meines Teams außer Kontrolle geraten?

Ich bin ein Softwareentwickler-Teamleiter (ich habe kürzlich die Kontrolle über ein neues Team übernommen) und bin letztendlich verantwortlich für die Aufrechterhaltung einer hohen Produktivität, guter Qualität und organisierter Prioritäten.

Ich habe 6 leitende Entwickler in meinem Team, aber die Dinge fühlen sich hier wie ein Chaos an. Die Situation ist, dass ich JIRA-Anfragen von ungefähr 10 verschiedenen Kontaktstellen in unserem Unternehmen bearbeiten muss und sie alle verschiedene Geschäftsbereiche oder Kunden repräsentieren.

Das Problem, das ich habe, ist, dass mein Job hauptsächlich darin besteht, den ganzen Tag Feuer zu löschen und sicherzustellen, dass an allen Problemen gearbeitet wird. Leider war die Kultur in unserem Unternehmen eine hohe Produktivität (schnelle Veröffentlichung), aber eine niedrige Qualität (Produktionsfehler), und unsere Kunden akzeptieren keine plötzlichen Verzögerungen bei den Ergebnissen.

Was sind einige gute Möglichkeiten, damit umzugehen? Ich habe jede Menge Theorien, aber ich suche nach einer Antwort von jemandem, der tatsächlich Berufserfahrung in einer Situation wie meiner hat.

Hier ist eine kleine Liste, wie die Dinge funktionieren:

• Jeder Entwickler ist für eine bestimmte Anwendung und die damit interagierenden Dienste verantwortlich.
• Versionen werden normalerweise vom Client auf einem simulierten Produktionsserver getestet und dann auf dem Live-Server bereitgestellt.
• Jede Anwendung wird von durchschnittlich 50-80 Personen mit insgesamt 8 Anwendungen verwendet.

Vielen Dank

Unsere Kunden akzeptieren keine plötzliche Verzögerung der Ergebnisse

Dann müssen sie die schlechte Qualität akzeptieren, die sie bekommen.

Was Sie haben zu tun , um dies zu ändern ist Ihre Kunden erhalten die Realität der Software - Entwicklung zu übernehmen (oder jede andere Produktion!): Dass die Dinge rauschen Qualität auswirkt.

Erstellen Sie eine große Liste der Dinge, die schief gehen - der Dinge, die kaputt sind, der Zeiten, in denen sie Anlass hatten, sich zu beschweren. Erklären Sie ihnen den Grund für diese Probleme und sagen Sie ihnen, was Sie tun möchten, um dies zu ändern. Stellen Sie sicher, dass Sie den Prozentsatz der Zeit erklären, die Ihr Team für die Unterstützung und Behebung von Live-Anwendungen aufgewendet hat. Wenn Sie die Daten dazu nicht erfassen, können Sie jetzt beginnen (und einen Monat lang erfassen, bevor Sie die Informationen den Kunden präsentieren).

Holen Sie sich die wichtigsten Stakeholder in einen Raum und sagen Sie: "Möchten Sie, dass X repariert wird, oder möchten Sie, dass Y geliefert wird? Wir haben nur Zeit für einen der beiden." Machen Sie sie für die Festlegung der Prioritäten verantwortlich und stellen Sie klar, dass Sie nur über begrenzte Kapazitäten verfügen. Wenn sie nach etwas Neuem fragen, fragen Sie sie, was sie bereit sind, von ihrer aktuellen Roadmap zu opfern, um dies zu erreichen.

Fragen Sie Ihr Team, wie viel Zeit und Ressourcen es benötigt, um "die Dinge in Ordnung zu bringen" (sowohl hinsichtlich der Behebung grundlegender Fehler als auch hinsichtlich der Behebung größerer Probleme in Bezug auf Codequalität / Architektur usw.) Nehmen Sie diese Elemente in die Liste der Dinge auf, die Ihre Stakeholder priorisieren müssen.

Das Beste, was ich jemals in meinem aktuellen Job getan habe, war, die acht wichtigsten Stakeholder gleichzeitig in einen Raum zu locken und einen Stapel mit 16 Karteikarten auszulegen, die die gewünschten neuen Funktionen darstellen. Ich trat vom Tisch zurück und sagte: "Wir können jeweils eine davon liefern. In welcher Reihenfolge möchten Sie sie haben?" Lassen Sie sie debattieren sie über die Geschäftspriorität statt Sie in der Mitte stecken.

Anhalten, fallen lassen und rollen. Feuer brauchen Brennstoff und oft kommt es in Form von Panik. Nehmen Sie sich die Zeit, sich selbst und das Team in Ordnung zu bringen. Bewerten Sie Ihre Entwickler und stellen Sie fest, ob sie nicht über ausreichende Kenntnisse verfügen und / oder nicht hart genug arbeiten, um die gewünschten Ergebnisse zu erzielen. Entscheide, wer bleibt (und bemühe dich, sie zu behalten), wer einen kleinen Schub braucht, der Rest muss gehen. Bewerten Sie die Unterstützung und Tools, die Ihre Programmierer erhalten, um sicherzustellen, dass sie ihre Arbeit erledigen können. Stellen Sie sicher, dass die Audiotests, die Überprüfung, die Quellcodeverwaltung und die Dokumentation befolgt werden. Gute Leute mit guten Werkzeugen müssen zur Rechenschaft gezogen werden, um gute Arbeit zu leisten.

Es muss ein System geben, um zu wissen, was Ihr Team tun muss, woran es gerade arbeitet und wann es voraussichtlich fertig sein wird. Viele Methoden, Theorien, Software, Trockenlöschbretter und Haftnotizen, Dokumente und E-Mails, um dies zu erreichen. Lass etwas funktionieren, indem du dafür sorgst, dass sich alle daran halten. Wenn jeder einen Beitrag zum System leistet, gibt es mehr Anreize, ihm zu folgen.

Erhalten Sie ein besseres Verständnis dafür, was die Kunden erwarten. Dies ist möglicherweise nicht Teil Ihres Jobs. Möglicherweise gibt es andere Personen, die so tun, als ob ihre Haare in Flammen stehen, ihre Kunden unglücklich sind und der Himmel fällt. Es ist, was sie tun und einige sind wirklich gut darin. Wenn alles ein Notfall ist, ist nichts ein Notfall, weil nicht alles erledigt wird. Bieten Sie an, gelegentlich an Gesprächen mit Kunden teilzunehmen. Sie werden feststellen, dass viele "nett zu haben" sich in "Deal Breaker" verwandeln, wenn sie das Entwicklerteam erreichen. Sei der technische Liason oder eine andere Ausrede, um zu helfen. Versprechen zu machen, die man nicht halten kann, ist schlimmer, als ihnen zu sagen, was sie überhaupt nicht hören wollen. Wir wollen einen guten Job machen, also brauchen wir 8 Wochen und nicht 5. Sie werden auf lange Sicht glücklicher sein.

Letztendlich müssen Sie Ihre Kunden über Softwareentwicklung aufklären und sie so weit wie möglich in den Prozess einbeziehen. Was sie jetzt sehen, ist die schnelle Bereitstellung neuer Funktionen, aber auch Fehler in der Software. Während sie mit ersteren glücklich sein werden, werden sie mit letzteren nicht glücklich sein (oder sollten).

Sie müssen ihnen erklären, dass es bei besseren Prozessen, während die Lieferung neuer Software um einen kleinen Betrag verzögert wird, weniger Fehler gibt (es wird nie null geben). Wenn Sie sich einig sind, dass dies der richtige Weg ist, können Sie mit der Einführung der Prozesse beginnen, die Sie benötigen, um die Kontrolle über Ihre Entwicklung zurückzugewinnen.

Die Verwendung von Agile-Prozessen kann hier hilfreich sein, da sie andeuten (und in einigen Implementierungsmandaten), dass der Kunde Teil des Teams ist. Wenn Sie die Kunden sehr eng einbeziehen, werden sie sehen, was funktioniert und was Sie aus erster Hand produzieren können.

Meine (wenig erfahrene) Meinung: Ich denke, es gibt zwei Probleme zu lösen. Erstens, der Qualitätsprozess. Benutzt du Scrum / Waterfall / etwas dazwischen? In Scrum können Sie zusätzliche Aufgaben für jede Story hinzufügen: 1 um ein Testskript / einen Testplan zu erstellen, eine andere, um ihn auszuführen, eine andere, um den Code zu überprüfen, usw. Können Sie diese Schritte in Waterfall einfach hinzufügen?

Das andere Problem ist das massive Hauptproblem, das überall in der Software existiert. Erwartungen managen. Das heißt, die Zeit wird länger, wenn jemand schreit, dass er einen Knopf braucht, um X zu tun, damit er geliefert wird.

Wenn Sie dem Prozess zusätzliche Schritte hinzufügen und eine große Fanfare-Ankündigung darüber machen können [wir implementieren jetzt diesen Qualitätsprozess: Das bedeutet weniger Zeit für die Behebung von Fehlern! und bessere Ergebnisse! große E-Mails / Meetings usw., um sie zu informieren] und regelmäßig Ergebnisse zu liefern (ala scrum). Die Idee ist, dass diejenigen, denen Sie liefern, den Wert in den zusätzlichen Prozessschritten kennenlernen und sehen und sich daran beteiligen. Weniger Zeit für das Beheben von Fehlern = mehr Zeit für das Implementieren und Testen von Funktionen.

Kunden akzeptieren keine plötzliche Verzögerung der Ergebnisse? Sie müssen so ziemlich. Es ist klar, dass es nicht so weitergehen kann, wie es ist. Vielleicht können Sie die zusätzlichen QS-Schritte hinzufügen und dann, falls erforderlich, weitere Teammitglieder hinzufügen? Die Qualitätsschritte sind aber unbedingt erforderlich.

Wenn Sie Scrum oder ähnliches verwenden, können Sie einen einwöchigen Sprint anstreben, sodass regelmäßig Ergebnisse geliefert werden. Das wird die Leute genauso beruhigen wie eine schnelle Abwicklung.

Hoffe, das hilft bis zu einem gewissen Grad. Hoffentlich habe ich den Punkt nicht verpasst.

Was Sie beschrieben haben, klingt ganz normal und überhaupt nicht alarmierend.

• Kunden denken in der Regel anders als Ingenieure. Wir möchten, dass die Dinge richtig sind, aber die Kunden stehen vor einer Realität, die Pünktlichkeit vor Reinheit belohnt. Sie müssen ihre Probleme schnell lösen , um wettbewerbsfähig zu sein, und genau dafür bezahlen sie Sie.
• Das Setzen von Prioritäten ist zu umfangreich und zu aufwändig, als dass nur eine Person allein damit fertig werden könnte. Sie verfügen über einen Überhang an wichtigen Problemen (Sie verwenden also JIRA). Die Kontrolle der einzelnen Interessenbereiche durch die Leutnants ist die beste Option, um wichtige Aufgaben in den Griff zu bekommen der Stundenplan.

Da gibt es nichts worüber man sich Sorgen machen müsste. Trotzdem können Sie sich viel Mühe ersparen, indem Sie so viele Verwaltungsaufgaben wie möglich auf den zahlenden Kunden verlagern, indem Sie ihn in den Entwicklungsprozess der Festlegung von Prioritäten einbeziehen und die Technologie so weit wie möglich automatisieren möglich.