Codenames für Software/Hardware
-
Codenamen können ganz praktisch sein. Für Entwickler, die ständig mit irgendwas hantieren, ist es wesentlich angenehmer, sich über die Unterschiede zwischen Foo und Bar zu unterhalten, als über 3.3.15b und 3.4.7a oä.
Und für End-User ist das oft auch nicht allzu unpraktisch, meine Mutter weiß, dass sie MacOS X Tiger verwendet, und dass Jaguar älter ist, auch wenn sie keine Ahnung hat, welche Versionsnummern die jeweiligen Systeme haben.
-
nman schrieb:
Codenamen können ganz praktisch sein. Für Entwickler, die ständig mit irgendwas hantieren, ist es wesentlich angenehmer, sich über die Unterschiede zwischen Foo und Bar zu unterhalten, als über 3.3.15b und 3.4.7a oä.
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
-
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Klar. Wobei das natürlich im Falle von MacOS X, Java oä wegfällt.
-
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!
-
junix schrieb:
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!
Was? Der Codename kommt doch vor der Fertigstellung. O_o
-
Lügner schrieb:
junix schrieb:
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!
Was?
Das:
Shade Of Mine schrieb:
[...]den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
-
junix schrieb:
Shade Of Mine schrieb:
mal abgesehen davon dass man oft den namen des produktes erst spaeter festlegt wenn man den vollen funktionsumfang kennt, zielgruppen analysiert hat, etc.
Sollte das nicht eignetlich vor der Fertigstellung des Produkts bekannt sein?!
Marktanalyse sollte auf jeden Fall vorher gemacht werden, denn sonst produziert man u.U. am Markt vorbei und verursacht nur unnötige Kosten. Was aber am Schluss im Programm drin ist, ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist, oder ob sogar mehr im Projekt ist als im Projektplan, weil dem Kunden mal wieder was eingefallen ist.
EDIT: Ich kann die Zahl zwar nicht mit Quellen belegen, aber IIRC scheitern 60-70% aller IT-Projekte in Deutschland wegen mangelnder Planung.
MfG
GPC
-
GPC schrieb:
[...]ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist,
Weniger im Projektplan als viel mehr im Pflichtenheft. Und das Pflichtenheft sollte doch eigentlich verbindlich sein?
-
junix schrieb:
GPC schrieb:
[...]ich bin mir nicht sicher, ob das was im Projektplan drinsteht dann auch im Projekt ist,
Weniger im Projektplan als viel mehr im Pflichtenheft. Und das Pflichtenheft sollte doch eigentlich verbindlich sein?
Um, jaaa, sowohl Pflichten - als auch Lastenheft bindet ja beide Seiten, jedoch habe ich es schon mehrfach erlebt, dass Leistungen nicht erbracht wurden. Diese nicht erbrachte Leistung wird dann halt nicht bezahlt. Sense.
-
Oder das zusätzliche Leistungen erbracht werden sollen die eine vorherige Planung zu nichte machen. Man kann dem Kunden ja auch nicht ständig das Pflichtenheft vor die Nase halten wenn er "kleine" Änderungen haben will.
-
Chris++ schrieb:
Man kann dem Kunden ja auch nicht ständig das Pflichtenheft vor die Nase halten wenn er "kleine" Änderungen haben will.
Aber sicher doch. Immer zusammen mit einer Kostenrechnung für die Extrawünsche. Sonst hört das nämlich niemals auf. Wenn jede kleine Änderung einfach so ausgeführt wird, gibt das ein ewiges Projekt.