Wie plant man ein (größeres) Projekt richtig?
-
Guten Abend Forengemeinde,
Ich möchte einfach mal wissen,
was ihr so für Tricks und Tipps nutzt um auch bei größeren Projekten den Überblick zu behalten und auch ungefähr abschätzen könnt wie lange es nun braucht,
um seiner Vollendung nahe zu sein.Ob es nun das Nächste super Spiel ist oder das beste OS der Welt.
Irgendwie müssen diese ja geplant und organisiert worden sein,
denn niemand wird sich da wohl einfach mit einer Idee hinsetzen und munter drauf los programmieren bis alles passt.Wie strukturiert man die Planung?
Wie tief sollte man ins Detail gehen?Grüße
TheSupercompter
-
Angeblich verdienen diejenigen, die sowas planen, das meiste Geld, weil das gar nicht so einfach ist. Vereinfacht gesagt fängt man mit dem Hauptproblem ("Betriebssystem") an und zerlegt dieses in 2 oder 3 Teilprobleme ("Hardware" und "Benutzerschnittstelle"), welche man dann wieder in zwei oder drei Teilprobleme zerlegt und das macht man so lange, bis man irgendwann bei den Programmabläufen angelangt ist.
-
Hmm... Hmm...
Schwer zu sagen. Ich würd eigentlich sagen, man macht das so nicht, bzw. erst, wenn man das Zielprogramm sehr gut versteht. Und zwar wirklich genau das Zielprogramm.
Ich musste noch nie ein riesiges Projekt planen. Ich arbeite an einem vergleichsweise sehr großen System, aber das hat eben niemand geplant. Das ist über 20 Jahre hinweg immer weiter gewachsen und ist wie es ist. Viele von den neueren Komponenten sind schon viel besser durchdacht und geplant, aber für sich genommen sind sie nicht riesig. Dann kommt noch hinzu, dass sie nicht für sich allein stehen sondern in das Gesamtsystem eingebunden sind, mit vielen Ahhängigkeiten und Konsequenzen. Aber damit kennen wir uns eben aus, das haben wir im Griff.
Auf der Basis wäre es auch denkbar, das ganze System neu aufzubauen und zu planen. Weil die erfahreneren Entwickler schon seit vielen Jahren an dem System arbeiten und das sehr gut kennen. Und vor allem die Probleme kennen. Deswegen wäre es gut denkbar, dass wir auch das Gesamtsystem besser designen könnten. Das wär auch nicht so wahnsinnig schwer, zumindest wärs recht einfach, etwas zu entwerfen, was viel besser wäre, als das was wir jetzt haben. Es wär halt nur nicht ganz so einfach, dass dann auch zu implementieren (ohne sehr viele Fehler einzubauen).
Und ich glaub, das funktioniert nur fast auf die Weise. Ich hätte keine Ahnung, wie ich z.B. ein Photoshop planen würde. Da sind einfach sehr viele Teilprobleme, mit denen ich mich nicht auskenne und die mir nicht bewußt sind, und die Gesamtarchitektur beeinflußen würden. Das kann nur jemand machen, der jahrelang eben an Photoshop oder an ähnlicher Software gearbeitet hat. Bei Betriebssystemen usw. ist es ähnlich. Und diese großen Projekte (vor allem Betriebssysteme) bauen eben auf ihren Vorgängern auf und werden von Leuten entworfen, die die alten Systeme sehr gut gekannt haben. Da wird nichts komplett from Scratch entwickelt.
Bei Spielen ist es vielleicht ein bisschen was anderes. Spiele werden nicht für die Ewigkeit entwickelt, meist reicht eine Version und die muss kaum gepflegt werden. Und dann kann man die Erfahrungen schnell ins nächste Projekt mitnehmen (wenn nicht den ganzen Code).
-
Supercomputer schrieb:
Irgendwie müssen diese ja geplant und organisiert worden sein,
denn niemand wird sich da wohl einfach mit einer Idee hinsetzen und munter drauf los programmieren bis alles passt.Viele Projekte entstehen ziemlich genau so. Das soll nicht heissen dass kein Software-Design gemacht wird. Aber das vollständige Projekt im vorhinein planen, inklusive Zeitrahmen, das passiert recht selten und klappt dann auch meistens nicht so gut.
ps: Bezogen auf wirklich riesige Projekte. Spiele sind keine riesigen Projekte, zumindest nicht wenn man auf ne fertige Engine aufbaut. Und "mittlere" Projekte kann man, speziell wenn man sich in "der Domäne" schon gut auskennt, auch ganz gut planen.
-
also meine bisherige erfahrung sagt mir einerseits, dass ich das genau so planen sollte, wie oben beschrieben, und andererseits, dass es besser ist, einfach drauf los zu proggen, dann alles löschen und das ganze nochmal von vorne ohne die ganzen fehler machen sollte, weil mir irgendwie die praxis fehlt, um das alles von vorne durchzuplanen.
andererseits glaube ich eben, dass ich schon sehr genau überlegen sollte, was das programm eigentlich können soll. wenn ich ein auto bauen will, schraube ich ja auch nicht einfach drauf los, sondern überlege mir die anforderungen (welche leistung, welcher treibstoff, front- oder heckantrieb, ...), plane, rechne und dann wird irgendwann geschraubt.
also wenn dich die methoden ansich interessieren, such mach bei amazon oder in der örtlichen uni-bibliothek nach "software engineering".
-
Wade1234 schrieb:
also meine bisherige erfahrung sagt mir einerseits, dass ich das genau so planen sollte, wie oben beschrieben, und andererseits, dass es besser ist, einfach drauf los zu proggen, dann alles löschen und das ganze nochmal von vorne ...
Eine klassische Top-down-Planung (also von der Gesamtidee zum Detail) kannst du nur machen, wenn du das Projekt in Gänze überblickst, und wer tut das schon? Dazu müsstest du etwas sehr ähnliches schon mal gemacht haben.
Wenn das nicht der Fall ist, sollte man stattdessen eine Bottom-Up-Planung in Betracht ziehen, also erst die Teile entwerfen und brauchbare Prototypen (*) entwickeln, und dann überlegen, wie man alles zu einem Ganzen zusammensetzt.
Wahrscheinlich wird man auch hier mehrere Iterationen brauchen, bis sich alles richtig anfühlt, aber die richtig teuren Planungsfehler (auf halbem Weg erkennen, dass der Gesamtplan nichts taugt, oder für die letzten 10 Prozent nochmal soviel Zeit verbraten wie für die ersten 90) kann man hoffentlich vermeiden, indem man das Haus erst plant, nachdem man funktionstüchtige Bausteine hat.
(*) "brauchbare Prototypen" heißt: ausreichender Funktionsumfang, um was damit anzufangen, aber noch nicht unbedingt in jeder Situation kugelsicher.
andererseits glaube ich eben, dass ich schon sehr genau überlegen sollte, was das programm eigentlich können soll.
Was das Programm können sollte (und was nicht), sollte man sich vorher überlegen, das stimmt. Man muss das Was aber trennen vom Wie.
-
Wade1234 schrieb:
wenn ich ein auto bauen will, schraube ich ja auch nicht einfach drauf los, sondern überlege mir die anforderungen (welche leistung, welcher treibstoff, front- oder heckantrieb, ...), plane, rechne und dann wird irgendwann geschraubt.
Klar, das macht man wenn man schon mal ein Auto gebaut hat, bzw. wenn man schon weiss wie Autos üblicherweise aufgebaut sind, weil andere schon viele Autos gebaut haben.
-
Hi,
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Bei meiner ersten Abschlussarbeit hatte ich ein Programm zu erstellen, das auf einer nackten DOS-Oberfläche aufsetzen sollte aber mit einzelnen Masken, Auswahlfenstern, Popups, Linien, Rahmen, kompfortablen Zeileneditoren (getrennt nach Zeichenketten Integer und Float) und vor-und zurückspringen innerhalb der einzelnen Elemente bestehen sollte.
Also ist das Programm sowohl von unten nach oben als auch von oben nach unten gwachsen. Von unten erst mal die grundsätzlichen Basiselemente definieren und die darauf aufbauenden. Also z.B. Linie und Viereck aus vier Linien.
Gleichzeitig von oben her das Programm in die einzelnen Grundelemente zerlegen, z.B. Main mit Auswahl der einzelnen Grundfunktionen, und die dann schrittweise so weit untergliedern, bis sich "oben" und "unten" treffen. Danach ggf. noch aus jeder Ebene 1-2 Elemente codieren um einen Überblick über den Zeitbedarf zu bekommen und für alle Elemente aufsummieren. Und dann nicht vergessen einen Puffer für unvorhergesehenes mit vorzusehen, je nach Erfahrung 10 - 100%.
Gruß Mümmel
PS: es gab da mal von Dr. Günter Rothardt mal das Buch Praxis der Softwareentwicklung, das sich genau mit den Themen sehr ausführlich beschäftigt hat. Ist aber von 1987 und daher wohl kaum noch zu bekommen. Aber vielleicht haben es noch Bibliotheken zum Ausleihen.
2.PS: Grad gefunden bei Amazon ab 10 Euro: Na wenn das mal kein Schnäppchen ist.
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/3778514393
-
Ich finde auch die Kombination aus Top-Down und Bottom-Up am besten.
Macht man nur Top-Down, so werden die technischen Hürden erst viel zu spät entdeckt und umgekehrt bei Bottom-Up fehlt einem das Grundverständnis für die Gesamtarchitektur.
Gerade für einen Prototypen sollte man einen Durchstich entwickeln, welcher schon auf der Architektur aufbaut und schon einige technische Details enthält.Aber ein Projekt zu planen ist mehr als nur Code zu schreiben, dazu gehören alle Unterpunkte aus Software Engineering (und weitere nicht-technische, wie Infrastruktur, Teamkommunikation, etc.).
-
muemmel schrieb:
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Die Bildschirmmaske ist ja auch nicht das "nackte Gerippe", sondern im Gegenteil die Haut, die am Ende drübergezogen wird. Projektleiter sollten das nicht verwechseln, und sie sollten die Entscheider nicht in diesem Glauben lassen.
Entscheider, die immer nur nicken und nicht rückfragen, zeigen damit, dass sie das Projekt nicht verstanden haben. Erfahrene Projektleiter wissen das und verlangen die Rückmeldung. Wenn die Entscheider nicht nur nicken, sondern unterschreiben sollen (mit ihrem Namen auf einem Stück Papier), dann werden sie normalerweise wach.
-
Ich bedanke mich für die Zahlreichen sehr hilfreichen Antworten.
Gerade auch der Buchtipp, hier werde ich jedoch erst schauen, ob ich es in der Bibliothek finden kann, bevor ich es mir kaufe. An sich scheint es aber sehr gut zu sein.
Um die ganze Überlegung von der reinen Theorie hin zu einem greifbarem Beispiel zu führen, habe ich einmal grob angefangen eine "Gameengine" zu planen.
Dabei ist dann vorläufig diese Mindmap entstanden.
https://mind42.com/mindmap/28ff26b8-6cb6-47e4-a0be-e8cf224601feWenn ich das Grundkonzept, welches hier erwähnt wurde nun hierauf beziehe, dann war das eine Top -> Down Planung.
Als nächstes würde dann eine Bottom -> UP Ergänzung folgen.
Sobald diese dann abgeschlossen ist, würden einzelne Module konkret entwickelt und das gesamt Konstrukt bei Bedarf erweitert werden.Habe ich das so richtig verstanden oder ist mir hier ein Fehler unterlaufen?
Grüße
TheSupercmputer
-
muemmel schrieb:
Hi,
in den meisten Fällen wird (leider) erst mal irgendwas gewünscht, dann soll man schnell mal eine Bildschirmmaske vorzeigen, dann wird abgenickt, und wenn das das nackte Gerippe mit Fleisch behangen ist kommen alle hervor, die vorher nur genickt haben und stellen fest, dass sie es ja eigentlich gaaaaanz anders wollten.
Es gibt ein schönes Sprichwort, das heißt: "Die Frage war nach dem Himmel, die Antwort war ein Seil".
Ich weiß nur, dass es gewisses bewährtes Grundrüstzeugs gibt.
Z.B. ein Protokollheft mit Inhaltsaddressierung oder das (Stützradmäßige) Entlanghangeln an einem Modell, bzw. an einem Arbeitsplan nach Modell x, y, z,..
Das kann man genauso später bei z.B. Evaluationen so handhaben.Statt eines (bewährten) theoretischen Modells kann man in Software ein anderes Programm zum Vorbild nehmen. Tabellenkalkulationen oder Betriebssysteme haben auch mal klein angefangen.
Bei grundlegenden Entwürfen/Plänen kann ich nicht ohne Papier- und Bleistift-Schmierereien.
Bei Programmen kommt außerdem noch die lästige Frage auf, was ist der aktuellste (Haupt/Offiziell-)Code, bzw. wo war ich zuletzt?
Die Lösung ist auch hier wieder Transparenz - die sich auch im disziplinierten oder eben ritualisierten Handeln ausdrücken kann.Gute Planhilfen nach wie vor sind Plakate + A5-Zettel. Die Plakate lassen sich auch gut zusammenkleben, falls man Wandbreite/King-Size-Monitoring braucht.
-
Hi Printe,
Printe schrieb:
Die Bildschirmmaske ist ja auch nicht das "nackte Gerippe", sondern im Gegenteil die Haut, die am Ende drübergezogen wird. Projektleiter sollten das nicht verwechseln, und sie sollten die Entscheider nicht in diesem Glauben lassen.
Eigentlich ja, aber meine Erkenntnis ist, dass die "Entscheider" meist nicht weiter als bis zu einem bunten Bildchen denken können/wollen. Gerade im öffentlichen Dienst geht das von den Mitarbeitern, Doktoren und Professoren bis hin zu den verantwortlichen Entscheidern in den Ministerien.
In gut geführten Unternehmen ist das zum Teil ein wenig anders. Aber auch nicht immer. Jeder will was Buntes sehen, denn das kann er schön oder nicht schön finden. Mindestens die Hälfte aller Modulbeschreibungen ( na ja Bildschirmoberflächen) wurden mir als mit Excel/Powerpoint... gezeichnete Bildchen übergeben. Teilweise dann noch in einem Breitwand-Format, das gar nicht in die vorgesehene Bildschirmauflösung passt.
Ich kann mich noch an ein großes Projekt an der UNI erinnern, dass dan regelmäßig dem Professor vorgeführt wurde, um von ihm weitergehenden Input zu bekommen. Aber das einzige was da immer kam war der Hinweis, das an dieser oder jener Stelle noch ein Rechtschreibfehler war. Nur, dazu hätte ich auch die Sekretärin befragen können. Von den erwarteten gehobenen fachlichen Hinweisen kam da hingegen in den ganzen Jahren nicht ein einziges Mal was.
Man kann dem, der die Sache zu erledigen hat nur raten, selber in die Materie einarbeiten und die Chefs in dem Glauben lassen sie hätten dabei auch was zu melden.
Oder wie es mit mal jemand empfohlen hat, lassen sie sich die Zuarbeit von einem Lehrling des 2. oder 3. Lehrjahres machen, der blickt schon genug durch aber kommt noch auf den Punkt. Peinlich peinlich, aber ist leider so.Gruß Mümmel
-
Supercomputer schrieb:
Um die ganze Überlegung von der reinen Theorie hin zu einem greifbarem Beispiel zu führen, habe ich einmal grob angefangen eine "Gameengine" zu planen.
Ich finde, das ist jetzt wieder etwas anderes als das, wonach du ursprünglich gefragt hast. Da sind die Anforderungen und Voraussetzungen völlig unterschiedlich. Bei einer game engine gehts dir dann um das reine Design der Software. Das Projekt ist sehr überschaubar, die möglichen Anforderungen begrenzt, und du hast weniger Stakeholder.
Bei "großen" und realen Projekten gehts bei weitem nicht nur darum, Klassendiagramme auf der grünen Wiese möglichst sauber zu definieren. Dann kommen die meisten Probleme eher daher, dass man viel mit gewachsenen Strukturen zu tun hat, widersprüchlichen Anforderungen, unklaren Anforderungen, irgendwelchen Features, die schon seit Jahrzehnten drin sind und bei neuen Anforderungen stören, die man aber auch nicht loswerden kann, ohne wichtige Kunden zu verärgern usw...
-
muemmel schrieb:
Eigentlich ja, aber meine Erkenntnis ist, dass die "Entscheider" meist nicht weiter als bis zu einem bunten Bildchen denken können/wollen.
Ja, oft gehts um Bildchen. Man kann aber ab und zu jemanden dazu zwingen, irgendwas beizusteuern. Man fängt vielleicht mit einem Produkt an, und erste Version funktioniert so, wie Entwickler sich das halt gedacht hatten, also vielleicht etwas zu kompliziert für Consultants. Dann gibts vielleicht paar Configs und paar Einstellungen zu viel, die daher kommen, dass man als Entwickler das System genau versteht, und die Consultants das nicht so genau verstehen und nicht alles einstellen wollen. Dann bleibt erstmal der Eindruck, das Produkt ist zu kompliziert oder "funktioniert nicht", und benutzt es nur widerwillig.
Nebenbei gibts aber auch doch produktiven Input, z.B. es ist zu langsam, bestimmte Sachen funktionieren nicht, einige Kunden brauchen noch irgendwas usw... Dann versucht man sich als Entwickler an der nächsten Version und versucht mit den Verantwortlichen zusammen zu klären, wie man das jetzt alles in ein neues Konzept integriert, mit dem alle zufrieden sind.
Dann kommen Produktmanager und Consultants an einen Tisch (oder auch nicht, meist gehts lang hin und her und es gibt viele einzelne Besprechungen) und dann ist das, was am ehesten hängen geblieben ist, das war viel zu kompliziert, hatte keiner verstanden, und jetzt soll eine GUI her und jemand soll einen Vorschlag für die GUI machen. Und die Entwickler versuchen dann lange Zeit zu kommunizieren, die GUI ist egal, soll halt jemand einen Vorschlag machen, das macht 5% der Arbeit aus, aber lasst uns doch bitte die wichtigen Punkte klären. Das funktioniert dann aber eher schlecht, meist diskutiert man doch nur über die GUI und kriegt da das meiste Feedback. Bei den wichtigeren Sachen gibt man das dann irgendwann auf und macht es so, wie man es für richtig hält, bzw. fast noch paar Punkte, bei denen man wirklich eine Entscheidung haben will, so zusammen, dass man irgendwann halt auch eine Antwort bekommt.
-
muemmel schrieb:
Eigentlich ja, aber meine Erkenntnis ist, dass die "Entscheider" meist nicht weiter als bis zu einem bunten Bildchen denken können/wollen. Gerade im öffentlichen Dienst geht das von den Mitarbeitern, Doktoren und Professoren bis hin zu den verantwortlichen Entscheidern in den Ministerien.
In gut geführten Unternehmen ist das zum Teil ein wenig anders. Aber auch nicht immer. Jeder will was Buntes sehen, denn das kann er schön oder nicht schön finden.Vielleicht entsteht dadurch starkes Missverständnis. Wenn man z.B. ein Programm braucht, sagt, was es können muss bzw. man kann sich beschreibend/einigend auf Funktionen einigen - dann sind doch in erster Linie die Funktionen/das Werkzeughafte das wichtigste.
Beispielsweise https://www.tipp10.com/de/
Hier kommt es doch vor allem auf die Grundfunktionen an (Tippen lernen), die Datenbank (Verbesserung oder Lücken erfassen, Statistik) oder die Kosten und vor allem, dass das Programm als solches funktioniert (Ich habe ein Dos-Konsoleprg, das funktioniert ähnlich, aber mindestens genausogut). Eine Luft-Boden-Rakete, die bestimmte Panzer am Boden trifft, ist keine Wunderfunktion, das soll sie auch.Wann kommt bei den Linuxprogrammierern an, dass Rechner mit Internetbrowser auf Fensterbasis beim Verschieben der Fenster nicht abstürzen sollten?
Mein Senf zu diesem (unter der Haube komplexen Thema) ist, dass der Netscape Browser vor über 20 Jahren auf Unixsystemen fehlerfrei mit Maus benutzt werden konnte.
(Wie das heute ist, weiss ich nicht, entweder fehlt ein wichtiger Treiber bei den Unixen, Maus geht nicht, Internet geht nicht (Modul nicht erkannt o.ä.)
oder der Bildschirm bleibt komplett schwarz. Maus-/Internet- Nix am weitesten verbreitet.)
-
[quote="Mechanics"]
muemmel schrieb:
Dann bleibt erstmal der Eindruck, das Produkt ist zu kompliziert oder "funktioniert nicht", und benutzt es nur widerwillig.
...
Dann versucht man sich als Entwickler an der nächsten Version
...
Dann kommen Produktmanager und Consultants an einen Tisch ...... und damit sind wir schon bei Version 3, es ist ein Jahr vergangen und immer noch nichts Kundentaugliches da. Das ist leider der Normalfall, wenn Entwickler sich das Produkt ausdenken, weil kein anderer es tun will. Es muss anders laufen.
Sobald die Entscheidung fällt, dass das Produkt entwickelt werden soll, müssen alle (Produktmanager, Consultants, Vertrieb) ihren Senf dazugeben, und zwar zeitnah. Das müssen die, das gehört zu ihrem Job, da können sie sich nicht einfach raustun. Solange das nicht geschehen ist, startet die Entwicklung nicht, weil die Anforderungen noch unklar sind, so einfach ist das. (Dass man bestimmte Teile, die hundertprozentig kommen werden, schon mal vorbereiten kann, steht auf einem anderen Blatt. Das betrifft aber in erster Linie Dinge unter der Haube).
Und dieses "Senf dazugeben" ist auch keine Einbahnstraße. Da kann und soll rückgefragt und diskutiert werden. Oft fordern Leute ganz spezielle Dinge: "Wir wollen den XY-Button", und beim Nachfragen und Überlegen stellt sich raus, dass XY mit einer Dropdown-Liste noch viel besser ist.
Mit dem, was in dieser Phase genannt und als wichtig eingestuft wird (nicht alles, was ein einzelner Consultant für wichtig hält, ist tatsächlich wichtig - gleiches gilt aber auch für Entwickler), baut die Entwicklung einen Prototyp. Wenn der dann vorgestellt wird, kann keiner mehr nörgeln, dass es "nicht funktioniert" - außer es funktioniert tatsächlich nicht wie besprochen.
-
Hi Supercomputer,
Supercomputer schrieb:
Gerade auch der Buchtipp, hier werde ich jedoch erst schauen, ob ich es in der Bibliothek finden kann, bevor ich es mir kaufe. An sich scheint es aber sehr gut zu sein.
Mit ein wenig Suchen findet man es sogar für 4,95 Euro:
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/B0029GQ0ZW/ref=sr_1_2?s=books&ie=UTF8&qid=1518522238&sr=1-2
Da ist die Fahrt in die nächste Bibliothek teurer, und gute Fachbücher sollte mann selbst im Regal stehen haben.Gruß Mümmel
-
Printe schrieb:
Sobald die Entscheidung fällt, dass das Produkt entwickelt werden soll, müssen alle (Produktmanager, Consultants, Vertrieb) ihren Senf dazugeben, und zwar zeitnah. Das müssen die, das gehört zu ihrem Job, da können sie sich nicht einfach raustun. Solange das nicht geschehen ist, startet die Entwicklung nicht, weil die Anforderungen noch unklar sind, so einfach ist das.
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
-
Tyrdal schrieb:
Nö isses nicht. Zu Beginn sind die Anforderungen meist unklar und ändern sich zudem im Laufe der Zeit.
Der Threadtitel ist "Wie plant man ein größeres Projekt richtig?"
Und am Anfang einer richtigen Planung stehen nun mal klare Anforderungen. Solange die fehlen, gibts auch keine richtige Planung, sondern nur unsichere Planungsversuche, die jederzeit wieder einkassiert werden können.
Wenn das allen (inklusive Geschäftsführung) klar ist, spricht nichts dagegen, dass die Entwicklung "herumspielt" und "Machbarkeitsstudien" veranstaltet, denn mehr ist das nicht. Wenn die Entwicklung aber dafür eins auf den Deckel kriegt ("ihr verplempert Zeit und es kommt nichts dabei heraus"), dann wirds Zeit, mal zurückzufragen, was denn eigentlich erwartet wird, was herauskommen soll.
Es kann nämlich nicht sein, dass die Entwicklung die Arbeit des Produktmanagements / Vertriebs / Consultings tut und sich ausdenkt, welche Produkte mit welchen Eigenschaften in Zukunft gebraucht werden.
