Im Projektmanagement, für Softwareprojekte, gibt es viele Ansichten. Manche sind gut; Manche eher nicht. Wir wollen unterschiedliche Aspekte in diesem Blog-Beitrag betrachten, welche sich in den letzten 40 Jahren meiner Kariere als Software-Entwickler bzw. in den letzten 25 Jahren als Projektleiter etabliert haben.

Vorweg: Es gibt nur wenig Richtiges und noch weniger Falsches. Es gibt unterschiedliche Ansichten. Manche haben sich als gut herausgestellt; Manche halt eben nicht. Ich habe mich viel mit Projektmanagern (oder in den letzten 25 Jahren mit Geschäftsführern) darüber gestritten, was richtig und was falsch ist. Wir können unterschiedlicher Meinung sein. Die C-Cloud-App vertritt allerdings meine Meinung und meine über 40 jährige Berufserfahrung und verfolgt diese als Dogma.

Produktentwicklung vs. Projektgeschäft

Viele Stakeholder verstehen den Unterschied zwischen Produktentwicklung und Projektentwicklung nicht; Dabei ist das im Grunde ganz einfach. In der Projektentwicklung fehlt einfach eine Hierarchie-Ebene; Eben das Produkt.

Arbeiten wir z.B. in einer Agentur und vorrangig im Projekt-Geschäft kommt der Kunde zu uns und wünscht sich z.B. eine neue Software. „Ich wünsche mir eine Software, mit der meine Kunden effizient bei mir bestellen können“. Das Projekt ist geboren. Das Ziel des Projektes ist es ein neues Produkt zu schaffen. Die Bestell-App.

Im Produkt-Management funktioniert das ganz anders. Das Produkt ist z.B. eine eCommerce-Software. Nun kommt der Geschäftsführer (oder Produktentwickler) zur Entwicklungsabteilung und sagt: „Ich wünsche mir ein neues Feature, das (bestehende) Produkt soll nun auch auf Mobilgeräten funktionieren. Das Projekt ist geboren. Das Ziel des Projektes ist es das (bestehende) Produkt auf ein neues Level zu heben; Eben die Mobilgeräte-Kompatibilität.

Das hört sich total trivial an, sind aber zwei wichtige Aspekte die es von Anfang an zu berücksichtigen gilt.

Begriffsdefinition

normalerweise würde man TOP-DOWN mit den Projekten als oberste Hierarchie anfangen (ausgenommen bei der Produktentwicklung, wenn es das Produkt noch gar nicht gibt). Wir fangen hier bei der kleinsten Entität an; Der Aufgabe! Das größte Missverständnis in der Softwareentwicklung.

Aufgabe / Task

Das hört sich total trivial an und ich kann mir vorstellen, wie Ihr mit dem Kopf schüttelt, wenn Ihr das lest.
Was ist eine Aufgabe?

  • Mach mal das Produkt besser (ist keine Aufgabe für einen Softwareentwickler)
  • Mach das es funktioniert (ist keine Aufgabe für einen Softwareentwickler)
  • Ich brauche eine Statistik, darüber wie effektiv die Abteilung agiert (ist keine Aufgabe für einen Softwareentwickler)
  • Wir müssen die Logistik in unserem Unternehmen verbessern (ist keine Aufgabe für einen Softwareentwickler)
  • Wir müssen effektiver werden (ist keine Aufgabe für einen Softwareentwickler)

Aber was ist den nun eine Aufgabe für einen Softwareentwickler?

Das ist ganz einfach zu definieren.
Eine Aufgabe ist etwas, was der Softwareentwickler ohne Rücksprache selbstständig erfüllen kann!

OK, also wir haben geklärt was eine Aufgabe ist. Die Definition ist aber etwas komisch zu lesen. Also mal ein Beispiele für obige 3. Geschichte (Story):

  • Es wird eine monatliche Statistik benötigt, in der
    • pro Tag
    • der Mann-Stunden-Einsatz in Stunden und Verrechnungssätzen der Abteilung,
    • der Umsatz/die Einnahmen der Abteilung aufzeigt und daraus
    • die Pearson-Korrelation abzuleiten
  • damit die Abteilungsleitung frühzeitig bei Problemen gegensteuern kann.
  • Eine grafische Übersicht wäre wünschenswert!
  • Es steht ein Budget von 10 Mannstunden zur Verfügung.

Der zweite Teil (damit der…) ist eher die Begründung für die Aufgabe und nicht mehr Teil der Aufgabe. Je nach Unternehmensstruktur kann dieser Zusatz wichtig sein oder nicht.