Wir sind dabei, ein neues Projekt zu starten, das sehr ernst ist.
Das wird ein mobiles Projekt sein, und die Zielgruppe ist die gesamte Bevölkerung eines Landes. Der Kunde erwartet im ersten Monat mehr als 1 Million Downloads.
Das Projekt befindet sich in der Anfangsphase der Anforderungsanalyse, Dokumentation und Planung.
Die Hauptbedrohung für den Projekterfolg sind die Wissensbasis und die Fähigkeiten, die wir im Entwicklungsprozess verwenden werden. Die mobilen Entwickler haben wenig Erfahrung und was wichtiger ist, mittlere Fähigkeiten. Sie haben einige kleine Projekte erfolgreich durchgeführt, aber das reicht nicht aus, um sich an solchen Projekten zu beteiligen. Es gibt folgende Gründe, warum wir uns in dieser Situation befinden.
Es besteht also ein erhebliches Risiko, mit dem ich rechnen sollte, bevor ich mit der Entwicklung beginne. Ich stimme @DavidEspina vollkommen zu, der in dieser Antwort sagt
Im Gegensatz zu einem Betrieb, bei dem Sie möglicherweise gezwungen sind, eine Ressource zu einem Leistungsträger zu „wachsen“, haben Sie bei einem Projekt weder diesen Luxus an Zeit, noch sollte ein Kunde für dieses Wachstum bezahlen.
Welche Schritte sollte ich unternehmen, um von meinem zukünftigen Projekterfolg überzeugt zu sein?
Als PM müssen Sie ein Power-Grab-Spiel machen; Bauen Sie mit Ihrem Management einen Fall auf, dass Sie als PM die Befugnis haben müssen, Ressourcen zu verschieben, einschließlich deren Austausch, um die Erfolgswahrscheinlichkeit zu erhöhen. Akzeptieren Sie jedoch die Tatsache, dass Sie möglicherweise nicht die Leistung erhalten, die Sie benötigen, um das Projekt wirklich auszuführen. Viele von uns sitzen in demselben Boot.
Wie viele andere Variablen, die Projektergebnisse beeinflussen, kann diese Teamvariable eine sein, auf die Sie wenig oder gar keinen Einfluss haben. Großartige PMs haben nicht die Kontrolle über jede Variable, obwohl wir gerne so prahlen, wie wir es tun. Gute PMs werden jedoch frühe Signale einer Verschlechterung der Projektleistung lesen und diese Ergebnisse und Vorhersagen frühzeitig und oft kommunizieren und nach Möglichkeit abmildern.
Ein Teil Ihres Personalplans würde den Personalbedarf in Bezug auf die erforderlichen Kenntnisse, Fähigkeiten und Fertigkeiten (KSA) enthalten. Die KSAs geben auch das Dienstalter der Ressource innerhalb dieser Rolle an, z. B. Einstieg, Mitte, Senior, Führungskraft oder ähnliches.
Analysieren Sie basierend auf dem Ihnen zugewiesenen Team, was Sie haben, und was Sie brauchen, und DOKUMENTIEREN Sie die Lücken. Diese Lücken sind ein Input für Ihre Risikoanalyse, d. h. Sie und Ihr Team dokumentieren die Bedrohung, die diese Lücken verursachen, die Gefährdung und Ihren Plan, damit umzugehen.
Kommunizieren Sie dies Ihrem Managementteam auf eine nicht emotionale, sachliche Weise und verfolgen Sie Ihr Risiko während des gesamten Lebenszyklus des Projekts.
Tatsächlich steht der Untergang des Projekts NICHT unmittelbar bevor. Sie könnten am Ende sehr überrascht von Ihrem Team sein und hervorragende Ergebnisse erzielen, sei es, weil Ihre Personalanforderungen möglicherweise zu pessimistisch waren oder Sie ein bisschen Glück auf Ihrer Seite hatten oder dieses mittelständische Team von Natur aus talentiert ist oder eine Kombination aus diesen und andere Variablen. Behalten Sie im Hinterkopf, dass Erfahrung und Note schwache Prädiktoren für die Leistung sind. Eine Analogie, die ich verwende, ist das, was wir in der Luftfahrt sehen. Wir mögen immer den 20.000 Stunden alten, grauhaarigen Kapitän, der uns herumfliegt, aber wen schicken wir in diesen komplexen Jägern, Bombern und Transportern in den Krieg? Das 600 bis 800 Stunden alte 24-jährige Wunderkind … und das mit großem Erfolg.
Wenn sich Ihr Projekt verschlechtert, haben Sie dies als einen der Treiber gut dokumentiert mit Nachweisen aktiver Versuche zur Minderung über Ihre Risikoprozesse. Das macht Sie trotz eines möglichen Projektausfalls zu einem großartigen PM. Lassen Sie sich jedoch ein dickes Fell wachsen, denn Sie werden wahrscheinlich immer noch beschuldigt und zum Sündenbock gemacht; das liegt leider in der natur der politik.
Viel Glück!
Da es Ihrem Team an Erfahrung mangelt, ist es sehr riskant, ohne eine geeignete Person vorzugehen, die es anleitet. Es ist kein Problem, gering qualifizierte Entwickler einzustellen, es sei denn, Sie haben eine Person, die sie anleitet, und genügend Zeit, damit sie ihre Fähigkeiten erlernen und erweitern können.
Aber es funktioniert nicht so. Der Kunde hätte Fristen für das Projekt gesetzt, und wenn Sie diese nicht erreichen, verlieren Sie am Ende die Kundenzufriedenheit. Daher ist es besser, Ihr Management davon zu überzeugen, eine qualifizierte Person einzustellen und zu bezahlen, als eine ungelernte Person einzustellen und weniger zu bezahlen.
Sie müssen versuchen, Ihr Management auf die versteckten Kosten bei der Einstellung eines ungelernten Teams aufmerksam zu machen. Sie tragen deren Schulungskosten, Studienzeit usw. Wenn die Qualität des Produkts, das von einem ungelernten Team entwickelt wurde, nicht gut ist, müssen Sie am Ende alles von vorne beginnen. Es ist Zeit-, Kosten- und Energieverschwendung. Sie sind vielleicht bereit, es zu ertragen, aber wird Ihr Kunde es akzeptieren? Ich bin sicher nicht.
Versuchen Sie also zuerst, Ihr Führungsteam zu überzeugen, denn letztendlich arbeiten Sie daran, Ihre Kunden zufrieden zu stellen. Wenn sie nicht zufrieden sind, was bringt es dann zu arbeiten? Wenn sie streng sind, wenn es darum geht, ein gering qualifiziertes Team einzustellen, stellen Sie zumindest eine Person ein, die sie anleitet. Andernfalls tun Sie am Ende nichts und verschwenden Geld und verlieren einen Kunden.
Ernennen Sie einen leitenden Programmierer, jemanden, der Entscheidungen auf Architekturebene trifft, und implementieren Sie den Großteil des Kerncodes. Idealerweise sollte der leitende Programmierer oder ein sehr kleines Kernteam das Basisprogramm entwerfen, bevor er weitere Teammitglieder einstellt, aber ich denke, dass es in Ihrer aktuellen Situation schwierig sein könnte, die Dinge so zu arrangieren. Wenn Sie die Wahl haben, sind im Allgemeinen weniger Leute über einen längeren Zeitraum mehr Leuten über einen kürzeren Zeitraum weitaus vorzuziehen, und wenn Sie mehr Leute einstellen müssen, sollten Sie warten, bis das Projekt fertig ist Sie.
Ihre SE-Aktivität sieht so aus, als wären Sie selbst kein Programmierer. Anstatt zu versuchen, die Programmierfähigkeiten Ihres Teams direkt zu bewerten, sollten Sie versuchen, Ihre Teammitglieder dazu zu bringen, das Fähigkeitsniveau der anderen zu bewerten. Versuchen Sie, für jeden schnell einen grundlegenden Entwurfsplan zu erstellen, und lassen Sie alle die Pläne besprechen. Danach sollten sie als Gruppe eine Meinung haben, wer der beste Lead wäre, wenn man Glück hat, gibt es sogar Konsens.
Ich weiß nicht, ob dieser Ansatz mit der armenischen Arbeitskultur funktioniert, es erfordert, dass Ihre Programmierer ein möglicherweise unbequemes Maß an Ehrlichkeit ausüben.
Was ich bei kritischen Projekten normalerweise mache, ist, die Grundlagen so schnell wie möglich zu erledigen, normalerweise mit einer Form von inkrementellem Projektmanagement (zB Spiralmodell ), aber ich bin nicht der Typ, der blind an einem Konzept festhält, also ist das genauso eine Idee.
Das Konzept dahinter ist, so schnell wie möglich etwas "potenziell" Veröffentlichungsfähiges zu haben, um:
Und später, wenn Ihr Projekt Fahrt aufgenommen hat, können Sie Features einfach nach Priorität einzeln hinzufügen, ohne befürchten zu müssen, dass ein einzelnes Feature entweder fehlt, nicht wie gewünscht, die Zeit nicht wert ist oder beim Kombinieren nicht ins Ganze passt.
Auch der Kunde bekommt genau das, was er will, da er die Ergebnisse sehr früh kommentieren kann. Und Sie können später nach der Freigabe argumentieren, dass der Kunde viel Zeit hatte, einzugreifen oder Features zu korrigieren, sollte er sich danach noch beschweren.
Der beste Weg, dem Management Ihre Argumente vorzutragen, ist die Verwendung von Metriken. Wie von @David vorgeschlagen, würde ich die Risiken dokumentieren und mit der Überwachung beginnen. Sobald die Risikowahrscheinlichkeit zu steigen beginnt und sich auf den Zeitplan auswirkt (stellen Sie sicher, dass Sie dies so früh wie möglich erkennen), bringen Sie diese Zahlen zur Geschäftsleitung und versuchen Sie, sie zu überzeugen.
Vielleicht ist es besser, einen Berater einzustellen, der das Team für die Projektdauer leitet (anstatt eine Festanstellung zu übernehmen).
Wenn Sie noch keinen Codeüberprüfungsprozess haben , richten Sie einen ein. Jeder in die Quellcodeverwaltung eingecheckte Codeabschnitt sollte von mindestens einem anderen Entwickler auf Genehmigung/Ablehnung überprüft werden.
kleineg
saakisch
MCW