Wie verwalten Sie Featureanforderungen und Softwareänderungen? [geschlossen]

Ich bin ein Software-Ingenieur und in den letzten Jahren bin ich der De-facto-Software-Projektmanager geworden, einfach weil es keinen gibt. Um unsere Vernunft in der F & E / Technik-Abteilung zu wahren, haben sich Kunden daran gewöhnt, mit ihren Anfragen zu mir zu kommen. Ich habe keine Erfahrung in diesem Bereich und bin zum ersten Mal als Projektmanager für Softwareprojekte tätig. Ich habe andere Dinge verwaltet, aber keine Software.

Wie verwalten Sie Softwareprojekte und markieren Prioritäten? Anfragen kommen in zu großen Abständen, so dass wir sehr gut auf etwas für jemanden anderen und dann eine andere Person mit einem „rush“ Job kommt arbeiten könnten, dass Bedürfnisse arbeiten. Ist es einfacher, einfach "Wer zuerst kommt, mahlt zuerst" zu sagen, oder ist es die Person mit dem meisten Geld?

Ich habe festgestellt, dass ein Kunde sich umso mehr darüber beschwert, wie dringend seine Anfrage ist. Wenn er nicht auch selbst Entwickler ist, ist dies in der Regel ein gutes Zeichen dafür, dass die Anfrage überhaupt nicht dringend ist. Einer meiner Professoren am College hat uns immer gesagt, wir sollen das Wichtige nicht dringlich unterbrechen lassen.

Normalerweise klassifiziere ich Anfragen in dieser Reihenfolge (YMMV):

1. Probleme im Zusammenhang mit einem kürzlich durchgeführten Upgrade oder einer Migration (am wichtigsten).
2. Sicherheitsupdates.
3. Defekte Funktionalität des bestehenden Systems.
4. Defekte Funktionalität in RC- und Beta-Funktionen.
5. Bezahlte Feature-Anfragen.
6. F & E-Funktionsanfragen von einem großen Teil der Anwenderbasis.
7. F & E-Funktionsanforderungen von nur einem oder zwei Benutzern.

Letzteres nimmt tatsächlich viel mehr Zeit in Anspruch, da es sich in der Regel um solche "dringenden, ich brauche es gestern" Anfragen handelt. In der Realität hat der Benutzer selten vollständig darüber nachgedacht, was er tatsächlich benötigt oder wie es sein Geschäftsmodell unterstützen wird. In den meisten Fällen werden diese dringenden Anfragen, wenn sie einmal zugestellt wurden, ein- oder zweimal verwendet und vergessen. Und wenn sie einmal vergessen sind, werden sie zu endlosen Kopfschmerzen von Sicherheitslücken und unbeabsichtigten Konsequenzen.

Ich mag ‚s Grundsätze:

1. QI - wichtig und dringlich
2. QII - wichtig, aber nicht dringend
3. FIII - Nicht wichtig, aber dringend
4. QIV - Nicht wichtig und nicht dringend

1. Richten Sie ein Feature / Bug / Request-Tracking-System ein und lassen Sie Ihre Kunden / Mitarbeiter Tickets ablegen. Wenn sie kein Ticket dafür einreichen, tun Sie es nicht. Tickets müssen detailliert genug sein, um umsetzbar zu sein, und eine "Dringlichkeit" angeben ("Ich brauche sie jetzt" vs. "Schön zu haben").
2. Gehen Sie neue Tickets durch und prüfen Sie sie sorgfältig . Geben Sie die Kosten im Ticket in US - Dollar, Entwickler, Ressourcen und / oder Zeit. Das ist wichtig . Wenn Ihre Kunden sehen, was etwas sie wirklich kostet, sehen Sie im Bereich "Dringlichkeit" sehr unterschiedliche Optionen.
3. Auf einer täglichen Basis, herauszufinden, Ihren Zeitplan auf den Karten basieren eingereicht und ihre Dringlichkeit. Machen Sie den Zeitplan für andere sichtbar, so dass es offensichtlich ist, was Sie bis zu und Ihre Verfügbarkeit für zukünftige Anforderungen.

Ich habe Projekte gesehen, bei denen Anforderungsänderungen von einem sehr schweren Änderungskontrollsystem verwaltet werden. Das ist schlecht. Viele wichtige Änderungen finden nicht statt, da der Kunde nicht die Mühe machen möchte, eine Änderungskontrolle einzureichen, sodass die Software nicht seinen Anforderungen entspricht. Einige kleine Änderungen werden "unter die Lupe genommen", um den Vorgang zu vermeiden, sodass die Software nicht einmal Ihren Vorstellungen entspricht.

Umgekehrt habe ich auch Projekte gesehen, bei denen der Projektmanager der Meinung ist, dass "reaktiv" bedeutet, dass die Programmierer auf jede Anfrage der Benutzer reagieren. Dies bedeutet lediglich, dass Sie niemals eine Kernentwicklung durchführen und Ihr Code zu einem großen, unhandlichen Durcheinander von Hack-Attacken wird hacken. Im Grunde haben Sie jetzt keine Entwickler mehr, Sie haben ein Team von überqualifizierten Vertriebsingenieuren.

Man könnte also hoffen, dass es eine Situation zwischen diesen beiden Polen gibt, die gut funktioniert, und ich gehe davon aus, dass das, was für Sie am besten funktioniert, sowohl eine persönliche Entscheidung als auch eine Standortbestimmung ist. Es ist auf jeden Fall sinnvoll, die Kosten jeder Änderung zu erfassen. In einem Framework wie Scrum können Sie die Kosten in Story-Punkten ausdrücken, und das Team kann die in jeder Iteration geleistete Arbeit gegen den insgesamt verfügbaren Aufwand austauschen. Wenn Sie einen Produktmanager haben, kann dieser den erwarteten Nutzen einer Änderungs- oder Funktionsanforderung quantifizieren. Dies geschieht normalerweise in Bezug auf geschützte Einnahmen (wie viele Kunden würden gehen, wenn Sie dies nicht tun) und angezogene Einnahmen (wie viele Kunden werden ankommen, wenn Sie dies tun). Dies kann bei der Priorisierung hilfreich sein, kann aber auch nur die Vorurteile oder persönlichen Vorlieben des Produktmanagers widerspiegeln.

Hier ein paar Gedanken ...

Auf dem Markt gibt es eine Menge Software, die Ihnen hilft, http://www.fogcreek.com/ mit Fogbugz, GeneXus USA mit XPM http://www.genexususa.com/xpm usw.

Es ist wie eine Kunst, neue Feature-Anforderungen mit Fehlerbehebungen und eigenen Ideen in Einklang zu bringen. Man muss Essen für den nächsten Winter bekommen, aber man muss auch heute essen.

Sie haben Zeit, Ressourcen und Spielraum, machen Sie das Beste daraus.

Henry Ford sagte auch einmal: "Wenn ich Kunden zugehört hätte, hätte ich ihnen ein schnelleres Pferd gegeben" ...

Persönlich: Sei dynamisch, schreibe keine Regeln wie die, die du gesagt hast ... und achte auf die Regeln anderer Leute ... sie funktionieren vielleicht gut in ihrem Kontext, aber nicht in deinem.

Am Ende hatten wir zwei monatliche Vertriebs- / Engineering-Meetings, um aktuelle Projekte und bevorstehende oder zukünftige Featureanfragen zu besprechen. Die Vertriebsingenieure werden zu Projektmanagern und sind zumindest auf die neuesten Produktangebote abgestimmt. In der Vergangenheit war es einfach, es an Engineering weiterzugeben und es zu vergessen. Dies wird wahrscheinlich die Belastung verringern, die ein Softwareentwickler zu bewältigen hat, und den Vertrieb und das Management in die Pflicht nehmen, unsere Zeit mit Bedacht einzusetzen.

Das Unternehmen, für das ich arbeite, verwendet zwei Hauptanwendungen, ein webbasiertes Tool namens JIRA, um die projektbezogenen Aspekte zu bearbeiten, und unser Helpdesk-System, um die Änderungsanforderung über seine RFC-Funktionalität zu bearbeiten

Die Antworten, die ich bisher sehe, sind gut. Eine Sache, auf die ich ausdrücklich eingehen möchte, ist, dass Sie gut darin sein müssen, einigen Anfragen "Nein" zu sagen.

Wenn Sie dem Kunden erlauben, die Dringlichkeit einzustellen, ist sie fast immer "Hoch" (oder höher).

Sie (entweder Sie selbst oder ein Team, je nach Konfiguration) müssen diese Anforderungen bewerten und sie auf der Grundlage Ihrer eigenen Kriterien priorisieren.