Projekt begin

Ich würde ja mal Stichwörter wie Projektplanung, Pflichtenheft, Lastenheft usw. ausprobieren :-?

Du bist dir wirklich sicher, dass du ein Projekt durchziehen willst, wenn du a) das noch nie gemacht hast, weil du b) nicht einmal weißt, wie das geht? Das nenne ich mal 'ne Herausforderung...

Klar ist irgendwann immer das erste Mal. Ich hatte es nur so verstanden, dass du von jetzt auf gestern ins kalte Wasser geschmissen wurdest und nun selbst das gesamte Projekt leitest.

Was ein Programmierer in einem Projektteam zu tun hat? Nun, das sollte der Projektleiter dir sagen (können). Der sagt dir, was du wann, wie, wo, mit wem zu tun hast. Denn das ist sein Job.

Naja, etwas weniger kompakt ist es dann schon. Zunächst einmal hat der Auftraggeber ein Lastenheft zu erstellen. Darin ist definiert, was er von der Anwendung erwartet, sprich: wer soll mit ihr was schlussendlich einmal tun. Es ist also das Grobkonzept.

Daraus erstellst du und/oder deine Teammitglieder das Feinkonzept, das sog. Pflichtenheft, das zum Einen der Auftraggeber abnickt (wichtig!!) und zum Anderen schon sehr detailliert technische Aspekte behandelt. Hier definierst du also die Rechtestruktur (Editor- vs. Autorrecht, Rollen, Leserfelder etc.), die Beziehung der Dokumente (Antwortdokumente, aber auch Lookups, etc.) untereinander, sonstigen Code (Agenten und deren Laufintervalle, ScriptLibs, etc.), aber auch eben das Layout (Masken, Ansichten, Buttons, Pop-Ups, etc.). Selbstverständlich gehört hier noch kein fertiger Code rein, da bis hierhin noch alles sprachunabhängig ist. Der kommt erst im nächsten Schritt, nämlich in der Implementierung der ganzen Sache.

Und genau hier würde ich persönlich die Grenze zwischen Entwickler und Programmierer ziehen. Während der Entwickler nämlich die Spezifikationen festlegt und mit dem Auftraggeber abstimmt, muss der Programmierer "nichts weiter" tun, als das in die Sprache der Wahl umzusetzen. Dabei ist es relativ Latte, welche das nun ist. Sei es nun LS oder in anderen Umgebungen C, C++, C#, Java, sonstwas. Die Sprache wird erst in der technischen Spezifikation festgelegt, wo auch über Hardware (Anzahl der Maschinen und deren Ausstattung), deren Architektur (PPC, x86), Betriebssysteme und z.B. Servicezeiten geredet wird.

Die Entwickler-/Programmiererprofis dürfen mich gerne berichtigen, sollte ich falsch liegen.

Mein Beileid
In dem Fall schlage ich vor, dass du dir sehr sorgsam die ersten beide nSchritte, das Lasten- und das Pflichtenheft, überlegst. Machst du bereits im Feinkonzept Fehler, zieht sich das wie ein roter Faden durch deine Anwendung und ist -je nach Komplexität der Anwendung- später nur sehr schwer wieder zu beseitigen. Nimm dir dafür dann lieber mal etwas mehr Zeit als zu wenig.

Wenn du dann das Feinkonzept vernünftig hast, ist der Code dann wesentlich schneller runtergehackt. Stell es dir so vor: das Feinkonzepot sollte so gestaltet sein, dass jemand, der von der Sache nichts versteht, daraus die Anwendung bauen kann. Bekommst du das so hin, macht es dir das Leben viel einfacher.

damit ich meine Projektleiterausbildung nicht ganz um sonst mache hier noch mal eine Erklärung was ein Pflichten- und was ein Lastenheft ist:

Lastenheft - Das Lastenheft wird durch den Kunden erstellt und dieser definiert darin, was er will. Zum Beispiel eine Anwendung mit der man Reisekosten abrechnen kann. Weiterhin definiert er darin vllt. noch, dass dies in Lotus Notes passieren soll und er wünscht sich noch irgendas anderes, was aber aus Sicht der Entwicklung keinen Sinn macht, z.B. nicht mehr als 10000 Lines of Code.

Pflichtenheft - Das Pflichtenheft wird durch den Auftragnehmer geschrieben und enthält Teile des Lastenheftes, die Du als Auftragnehmer für erfüllbar hälst. Unsinnige Sachen lässt Du weg und dann bereitest Du auf Basis des Pflichtenheftes ein Angebot zu Umsetzung vor.

Damit geht es dann ab zum Kunden und der kann dann unterschreiben oder es lassen...

Wichtig ist in jedem Fall die Zieldefinition. Jedes Ziel sollte messbar sein. D.h., was muss vorliegen, damit ein Ziel erreicht ist? Z.B. eine DV-Konzept als Word-Dokument....

Das sind so die ersten Grundsachen....dann gibt es da aber noch die Projektplanung, Durchführung, Risikomanagement, Stakeholder, der Plan der Pläne (Projektstrukturplan) usw usw usw.....

Wenn es nur ein kleines Projekt ist, dann solltest Du das auch so schaffen. Sollte es was größeres sein, dann such Dir ein bißchen Unterstützung.

Wenn wir schon mal einen Experten in der Runde haben: was soll ein "Stakeholder" sein? Jemand, der ein Stück Fleisch hält und du hast das Wort falsch geschrieben?

Ansonsten kenne ich das Wort eigentlich als "Interessenvertreter", bzw. der Typ, der Wetteinsätze einsammelt, verwaltet und hinterher auszahlt. Beim Pferderennen z.B.
"Stake" bedeutet soviel wie Anteil oder Beteiligung oder eben eine Wette, aber auch ein (Holz-)Pflock oder ein Zaunpfahl ist ein Stake. "To hold a stake" heißt, eine Beteiligung zu haben (demzufolge wäre der Stakeholder jemand, der eine Beteiligung hält, aber was hat das mit Projektmanagement zu tun?), "to put somethin at stake" heißt, etwas aufs Spiel zu setzen (ob das aber im Sinne einer Projektdurchführung gemeint ist ... ich hoffe nicht ).

Entweder lassen mich gerade meine Englischkenntnisse im Stich, oder das ist wieder ein Buzzword, das leider sinnverdreht verwendet wird. Wer mich aufklären kann, nur zu, das würde mich schon interessieren...

/edit:
hab grad mal LEO gefragt und so schlimm haben mich meine Englischkenntnisse nicht im Stich gelassen. Während ich mir irgendwie noch zusammenreimen kann, dass "Stakeholder" als Übersetzung zu "Interessenvertreter" zur Projektarbeit passt, passt das aber nicht in die Aufzuählung Projektplanung, Durchführung, Risikomanagement, Stakeholder, der Plan der Pläne (Projektstrukturplan) rein.