Hallo, mich würde eure Meinung zu folgenden Sachverhalt intressieren: Ein neues Software-Projekt steht in den Startlöchern einer kleinen Firma. Entstehen soll ein Produkt womit der Kunde arbeiten kann. Das Unternehmen hat sehr viel Kompetenz im eigenen Fachbereich, allerdings fehlt mMn viel Kompetenz im Bereich der Softwareentwicklung. Die fachliche Logik soll mittels eigener Sprache/Compiler/ToolChain umgesetzt werden. Es ist schon eine gewisse Vorarbeit entstanden und die derzeitigen Entwickler machen das auch bestimmt mit den besten Vorsätzen... Aber ich bezweifle allerdings stark, dass eine eigene Sprache/Compiler/ToolChain zielführend für das Produkt sind. Oder ums kurz auszudrücken: Ich denke es wurde sich in eine sehr komplexe Lösung verrannt die für mich viel mehr offensichtliche Nachteile als Vorteile bietet. Wie würdet ihr beim Management um Verständnis für Änderung werben? PS: mir geht es hier nicht um die Diskussion von technischen Details. Mich würde nur intressieren was ihr für einen guten Ansatz haltet, um das Produkt an sich evtl. noch auf eine andere Schiene zu heben.
sid schrieb: > was ihr für einen guten Ansatz haltet Da gibts nur die folgenden Gründe: spart Geld spart Zeit bringt mehr Nutzen bringt mehr Kunden und zwar nachvollziehbar in Zahlen ausgedrückt. Ansonsten steht dir frei in deiner Freizeit ein (Teilprojekt) mit der von dir propagierten Technologie zu implementieren und deinen Chefs das dann als Beleg deiner These zu zeigen. Das Posting klingt für mich wie das Gejammer eines Teils unserer SW-Entwicklung, die ständig neue Tools und Methoden ausprobiert aber seit Jahren nix gescheits rausgebracht hat mit dem man Geld verdienen kann. Das wird seit über 10 Jahren durch die Gruppen verdient, die mit den bewährten Tools bestehende Produkte erweitern und auch neue (Teil)Produkte implementieren.
sid schrieb: > Die fachliche Logik soll mittels eigener > Sprache/Compiler/ToolChain umgesetzt werden. Mache Dich mit der Sprache und der fachlichen Logik vertraut und setze das in einer für Dich genehmen Sprache um. Wenn Du innerhalb von einem Tag keinen vielversprechenden Ansatz findest, dann vergiss es.
>Da gibts nur die folgenden Gründe: >spart Geld >spart Zeit >bringt mehr Nutzen >bringt mehr Kunden >und zwar nachvollziehbar in Zahlen ausgedrückt. Konkrete Beispiele helfen da meistens gut weiter. Wenn ein Management trotzdem nicht vernüftig entscheidet bleibt nur noch eins: >sid schrieb: > Wie würdet ihr beim Management um Verständnis für Änderung werben? >Kündigen.
@ sid (Gast) >Unternehmen hat sehr viel Kompetenz im eigenen Fachbereich, allerdings >fehlt mMn viel Kompetenz im Bereich der Softwareentwicklung. Die >fachliche Logik soll mittels eigener Sprache/Compiler/ToolChain >umgesetzt werden. Optimale Kombination. > Es ist schon eine gewisse Vorarbeit entstanden und die >derzeitigen Entwickler machen das auch bestimmt mit den besten >Vorsätzen... ;-) >Aber ich bezweifle allerdings stark, dass eine eigene >Sprache/Compiler/ToolChain zielführend für das Produkt sind. Wahrscheinlich. Man sollte als ersten Ansatz so weit wie möglich mit Standardlösungen arbeiten und nur dann, wenn es WIRKLICH nötig ist und DEUTLICHE Vorteile bringt, auf Sonderlösungen einschwenken. >Ich denke es wurde sich in eine sehr komplexe Lösung verrannt die für >mich viel mehr offensichtliche Nachteile als Vorteile bietet. Kann sein, ist aber nur deine Ansicht. >Wie würdet ihr beim Management um Verständnis für Änderung werben? Warum? Damit die vermeintliche Sackgasse verläßt, bevor noch mehr Geld verbrannt wird? Damit du glücklich bist? Das ist gar nicht dein Job und in den allermeisten Situationen ist deine Meinung gar nicht gefragt. >Mich würde nur intressieren was ihr für einen guten Ansatz haltet, um >das Produkt an sich evtl. noch auf eine andere Schiene zu heben. Das ist ein gefährliches Pflaster, auf dem du dich bewegst. Denn neben den technischen Belangen, die fast immer als Letztes eine Rolle spielen, geht es hier vor allem um Psychiologie. "Die da oben", Chef und seine Freunde haben das Projekt losgetreten und die Eigenentwicklung als ganz tolle Idee gehabt. Und wenn sich jetzt rausstellt, daß das eher ein Eigentor war? Hmm, ob der Chef (oder wer auch immer) selbstkritisch genug ist, um das zu erkennen und zu korrigieren? Mal abgesehen davon, daß man auch ansatzweise technisch nachweisen muss, daß es eine Sackgasse ist. Da kann man sich auch den Mund fusselig reden. Mach's wie die Arbeiter beim BER. Einfach laufen lassen, solange man dafür bezahlt wird. "Die da oben" müssen und wollen das schließlich entscheiden und nicht der kleine Pampel.
Der Andere schrieb: > spart Geld > spart Zeit > bringt mehr Nutzen > bringt mehr Kunden Klingt erstmal logisch, erwarte da aber typische Konter: "Wir haben schon so viel Zeit/Aufwand/Geld investiert, wir müssen das jetzt so durchziehen." Oder "Mehr Nutzen / mehr Kunden ist doch nur spekulativ" Der Andere schrieb: > Das Posting klingt für mich wie das Gejammer eines Teils unserer > SW-Entwicklung, die ständig neue Tools und Methoden ausprobiert aber > seit Jahren nix gescheits rausgebracht hat mit dem man Geld verdienen > kann. > Das wird seit über 10 Jahren durch die Gruppen verdient, die mit den > bewährten Tools bestehende Produkte erweitern und auch neue > (Teil)Produkte implementieren. Das sehe ich genauso, es sollte zur Umsetzung eines Projekts eben nicht noch künstliche Komplexität mit eingebracht werden. Ich halte es allerdings schon für notwendig auch mal über den Tellerrand zu schauen. Nur muss das eben im sinnvollen Rahmen bleiben. Achim S. schrieb: > Mache Dich mit der Sprache und der fachlichen Logik vertraut und setze > das in einer für Dich genehmen Sprache um. > > Wenn Du innerhalb von einem Tag keinen vielversprechenden Ansatz > findest, dann vergiss es. Die eigentliche fachliche Logik ist Algorithmik die mit einer beliebigen Hochsprache erschlagen werden kann. Mir fehlt der "aha"-Moment, warum unbedingt eine eigene Sprache&Compiler dafür entwickelt werden muss. Und das möchte ich gern beim Managment anbringen. Wenn mir jemand plausibel erklären kann warum das Ganze notwendig ist --> ok. Quatsch schrieb: >> Wie würdet ihr beim Management um Verständnis für Änderung werben? > > Kündigen. Bin erst paar Monate in der Firma. Und ich möchte auch nicht gleich die Flinte ins Korn werfen, vor allem weil ich meine Softskills erweitern will. Kündigen würde sicher für die Firma erstmal bedeuten neue Leute zu rekrutieren, aber ich glaub es ändert sich dann trotzdem nicht viel am Managment. Ich möchte das ändern, aber möglichst ohne "Hau drauf" Methode.
@Falk: hab grad noch deinen Beitrag bemerkt ;) Du scheinst da schon viele einschlägige Erfahrungen zu haben.. Falk B. schrieb: > Optimale Kombination. Du sagst es. :D Falk B. schrieb: > Mach's wie die Arbeiter beim BER. Einfach laufen lassen, solange man > dafür bezahlt wird. "Die da oben" müssen und wollen das schließlich > entscheiden und nicht der kleine Pampel. Ich hab bedenken, dass die Firma dadurch den Bach runter geht. Ok muss auch nicht mein Bier sein. Es ist aber total unbefriedigendes (&sinnfreies) Arbeiten.
@sid (Gast) >Das sehe ich genauso, es sollte zur Umsetzung eines Projekts eben nicht >noch künstliche Komplexität mit eingebracht werden. Du vergißt den Spieltrieb der Leute. Des Chefs, der Softwerker etc. > Ich halte es >allerdings schon für notwendig auch mal über den Tellerrand zu schauen. >Nur muss das eben im sinnvollen Rahmen bleiben. Sollte es, ist aber oft nicht der Fall. >Die eigentliche fachliche Logik ist Algorithmik die mit einer beliebigen >Hochsprache erschlagen werden kann. Dazu ein paar gute Beispiele wie man das Spezialproblem damit darstellt und fertig. > Mir fehlt der "aha"-Moment, warum >unbedingt eine eigene Sprache&Compiler dafür entwickelt werden muss. Siehe oben. Plus der Drang, etwas Besonderes zu schaffen. Die Pharaonen ließen Pyramiden bauen, die sind heute noch zu sehen. Der kleine Chef/Angestellte baut halt die eigene Toolchain. ;-) > Und >das möchte ich gern beim Managment anbringen. Wenn mir jemand plausibel >erklären kann warum das Ganze notwendig ist --> ok. 90% der Erklärung sind nichttechnischer Natur. Willst du die WIRKLICH hören? >> Kündigen. Ist Unsinn. >Bin erst paar Monate in der Firma. Und ich möchte auch nicht gleich die >Flinte ins Korn werfen, vor allem weil ich meine Softskills erweitern >will. Kündigen würde sicher für die Firma erstmal bedeuten neue Leute zu >rekrutieren, aber ich glaub es ändert sich dann trotzdem nicht viel am >Managment. Ich möchte das ändern, aber möglichst ohne "Hau drauf" >Methode. Funktioniert auch nicht. Und das mit den Änderungen einbringen ist harte, politische Langzeitarbeit. Die Technik ist da nebensächlich. Willst und kannst du das leisten? > hab grad noch deinen Beitrag bemerkt ;) >Du scheinst da schon viele einschlägige Erfahrungen zu haben.. Tja, Ü40 ;-) >Ich hab bedenken, dass die Firma dadurch den Bach runter geht. Kann sein, ist es oft nicht. In der Praxis wird in kleinen wie großen Läden teilweise arg rumgemurkst, trotzdem fließt Kohle in rauen Mengen. Klingt komisch, ist aber so. >Ok muss auch nicht mein Bier sein. Es ist aber total unbefriedigendes >(&sinnfreies) Arbeiten. Stimmt, aber da mußt du deinen Spaß bzw. Erfüllung halt woanders suchen. In der Familie, Hobby, Welteroberung. Nicht zutreffendes bitte streichen ;-) Im einfachsten Fall in einem anderen Projekt in der gleichen Firma. Beitrag "Re: Was machen wenn der Chef keine Ahnung hat?" Dein Problem ist also nicht neu, im Gegenteil, es ist eher Standard. Beitrag "Kunde wirft die fertige Arbeit weg."
sid schrieb: > Mir fehlt der "aha"-Moment, warum > unbedingt eine eigene Sprache&Compiler dafür entwickelt werden muss. Und > das möchte ich gern beim Managment anbringen. Wenn mir jemand plausibel > erklären kann warum das Ganze notwendig ist --> ok. dann finde das doch heraus. Was nützt es, wenn der Kunde (Beweg-)Gründe hat und Du sie nicht kennst. Es ist sein Business.
@Achim S. (achs) >> Mir fehlt der "aha"-Moment, warum >> unbedingt eine eigene Sprache&Compiler dafür entwickelt werden muss. Und >> das möchte ich gern beim Managment anbringen. Wenn mir jemand plausibel >> erklären kann warum das Ganze notwendig ist --> ok. >dann finde das doch heraus. Was nützt es, wenn der Kunde (Beweg-)Gründe >hat und Du sie nicht kennst. Es ist sein Business. Glaubst du ernsthaft, "der Kunde" hätte entschieden, eine eigene Toolchain zu entwickeln?
sid schrieb: > Hallo, > > mich würde eure Meinung zu folgenden Sachverhalt intressieren: Mich würde erst einmal interessieren, welche Rolle du dabei spielst? Kunde? Berater? Mit dem Projekt betrauter Entwickler, Manager? Firmenmitarbeiter, aber nicht in diesem Projekt? Außenstehender Beobachter? Werkstudent? Dann, welche realen Erfahrungen hast du in solchen Projekten: Als Leiter? Als "Architekt"? Als Entwickler? Wie sieht deine Kompetenz im speziellen Anwendungsbereich aus? > Entstehen soll ein Produkt womit der Kunde arbeiten kann. Das man das heutzutage erwähnen muss ... Wenn es nicht gerade SAP oder Microsoft ist, dann ist es allgemein üblich Produkte zu liefern mit denen der Kunde arbeiten kann. > Das > Unternehmen hat sehr viel Kompetenz im eigenen Fachbereich, allerdings > fehlt mMn viel Kompetenz im Bereich der Softwareentwicklung. Die > fachliche Logik soll mittels eigener Sprache Domain Specific Languages (DSLs) können sehr erfolgreich sein. Gerade wenn die Sprache von jemandem mit "sehr viel Kompetenz im eigenen Fachbereich" gemacht wird. > /Compiler/ToolChain > umgesetzt werden. Den Unterbau unter der DSL kann man nachträglich immer noch gerade ziehen. Z.B. Compiler-Spezialisten (für viel Geld) kaufen die optimieren. Wichtig ist erst einmal dass die DSL gut ist und nicht gerade 12 Passes benötigt um compiliert zu werden. Ein halbwegs vernünftiger Informatiker der in den Grundlagen nicht gepennt hat sollte das überwachen können. > Aber ich bezweifle allerdings stark, dass eine eigene > Sprache/Compiler/ToolChain zielführend für das Produkt sind. Oder ums > kurz auszudrücken: > Ich denke es wurde sich in eine sehr komplexe Lösung verrannt die für > mich viel mehr offensichtliche Nachteile als Vorteile bietet. Klingt nach einer Einzelmeinung. > Wie würdet ihr beim Management um Verständnis für Änderung werben? Wie schon geschrieben, was hast du eigentlich mit dem Projekt zu tun? Als Kunde sähe die Verständniswerbung zum Beispiel so aus: "Will ich nicht, kauf ich nicht. Noch Fragen?" Als Mitarbeiter außerhalb des Projektes: Gar nicht. Man kann ein Projekt nicht eigenhändig retten. Als Mitarbeiter im Projekt: Zusehen dass die DSL gut wird.
Falk B. schrieb: > Glaubst du ernsthaft, "der Kunde" hätte entschieden, eine eigene > Toolchain zu entwickeln? Ich nahm an, der Kunde hat die Fachsprache mitgebracht. Falls nicht, dann sollte es für sid ja noch leichter sein, dem Management seine Alternative zu skizzieren. Also ernsthaft, entweder weil sein Weg plausibel ist oder mit einem rudimentären Mockup.
sid schrieb: > Wie würdet ihr beim Management um Verständnis für Änderung werben? Erstmal gar nicht. Lieber zunächst Fragen stellen: - "Warum wird eine eigene Sprache/Compiler/ToolChain verwendet?" - "Was sind die Vor- und Nachteile?" - "Hat jemand mal was anderes ausprobiert bzw. sind alle happy, dass eine eigene Sprache/Compiler/ToolChain verwendet wird?"
Eigene Ideen werden von den meisten bis in den Tod verteidigt, weil sich die Leute nicht eingestehen wollen, dass Kritiker allenfalls recht haben könnten. Wenn die Personen aber aus eigenem Antrieb als erste erkennen das die Idee doch nicht das Wahre ist, sieht das schon ganz anders aus. Dann ist ihre Idee nicht suboptimal, sondern sie haben eine Lösung gefunden diese nochmals zu verbessern. Ergo führe ihn ohne das er es merkt mit einfachen Fragen auf die Schiene das erkannt wird das die Idee doch nicht so gut ist.
sid schrieb: > Die fachliche Logik soll mittels eigener Sprache/Compiler/ToolChain > umgesetzt werden. Ohne nähere Details gibts keine sinnvolle Antwort. Die richtigen Fragen wurden schon oben gestellt. Also rück mal mit den Fakten raus.
Sag dem PM ihr solltet Scrum anwenden, dann fällt ggf. früh wenn keine sinnvollen Inkrements rauskommen.
sid schrieb: > Wie würdet ihr beim Management um Verständnis für Änderung werben? Gar nicht! Was interessiert Dich das auch? Die Darstellung von Dir klingt mir stark danach, das Du als Außenseiter im entsprechenden Projektbereich mitschwätzen willst. Warum? Kennst Du die Motive, die zu der Entscheidung geführt haben, eine eigene Toolchain zu entwickeln? Warum wurden vorhandene Lösungen (die prinzipiell immer angestrebt werden - alleine schon aus wirtschaftlichen Gründen) abgelehnt? Was man im Berufsleben lernt: Egal ob man selbst der Überzeugung ist, die anderen machen Käse - solange es nicht um Manipulation oder Betrug geht, ist das ein Thema, dass nur diejenigen angeht, die damit selbst zu tun haben. Das ist der PM, die Entwickler und der VG. Natürlich kann man immer Anregungen geben, aber wenn Du da jetzt hinrennst, und sagt: Ich weiß, Sie haben das so entschieden, aber sie machen da gerade Käse; ja dann wird Dir das keinen Gefallen tun ;-)
Ich glaube der Threadstarter will nicht mehr mit uns reden. So eine geballte Ladung Realität kann abschrecken.
Danke für eure Beiträge, die Beiträge von Geheim & realist & Falk & jack fand ich bisher am sinnvollsten. Ich bin zukünftiger Entwickler im Projekt von daher habe ich berechtigtes Interesse. Meine Motivation: in bisherigen Firmen, in denen ich arbeitete habe ich Projekte gesehen, die vor sich hin vegetieren. Entweder an der Grenze des Wirtschaftlichen und/oder an der Grenze der Wartbarkeit. Martin S. schrieb: > Warum wurden vorhandene Lösungen (die > prinzipiell immer angestrebt werden - alleine schon aus wirtschaftlichen > Gründen) abgelehnt? Die Begründung ist: weil es technisch geht. --> aber nicht alles was technisch geht sollte auch benutzt werden. Jack schrieb: > Domain Specific Languages (DSLs) können sehr erfolgreich sein. Gerade > wenn die Sprache von jemandem mit "sehr viel Kompetenz im eigenen > Fachbereich" gemacht wird. Es ist leider keine echte DSL sondern eine generische Metasprache die intern entstanden ist. --> "over the top" Nochmal zur Erinnerung: mir geht es nicht um eine technische Diskussion sondern um eure Erfahrungen ob/wie ihr dem Management Bedenken beibringen würdet.
Der Schluessel zur Bewertung der Aussagen des TO ist doch hier ganz klar: sid schrieb: > Bin erst paar Monate in der Firma. Damit ist doch auch Alles klar. yugbchjm
sid schrieb: > Ich bin zukünftiger Entwickler im Projekt von daher habe ich > berechtigtes Interesse. Ahhh, die Info wäre natürlich auch wichtig gewesen -.- Mensch, geizt doch nicht immer so rum mit Fakten. Dann verstehe ich auch Dein Dilemma. Du bist erst recht kurz dabei, wirst irgendwann selbst Entwickler im Projekt und siehst, dass sich der PM mit seiner dämlichen Entscheidung (das scheint wohl bei PMs normal zu sein) verrennt. Wenn Du ihm also jetzt vorwirfst, einen Irrweg zu gehen, dann wirfst Du ihm indirekt auch vor, inkompetent zu sein. Wenn Du also wissen möchtest, wie Du ihm das am besten beigringen kannst, dann frage Dich, wie Du wolltest, das man Dir das sagt, wenn Du selbst von der Idee überzeugt bist. Keiner kennt deinen PM. Es kann sein, dass man mit ihm Reden kann, wenn man sinnvolle Argumente auf den Tisch legt, und sachlich bleibt, es gibt aber auch Menschen wie meinen Chef, bei dem Entscheidungen nach Sonnenstand um 15:34 getroffen werden, und dann absolut unumstößlich sind. Ich habe Monate an einem Projekt deswegen verloren. Entsprechend würde ich es einfach konstruktiv sehen. Vllt. aus anderem Grund ein Gespräch suchen (z.B. Entschuldigen Sie, dass ich neugierig bin, aber so langsam habe ich mir hier eingefunden, und bin daran interessiert, was zukünftig hier so alles geplant ist ... irgendein bla bla halt). Dann kann man das Gespräch auch schnell auf das aktuelle Projekt richten, und im Zuge dessen ganz unverblümt fragen: Ach ja, das Projekt. Da bauen wir doch aktuell eine eigene Toolchain. Jetzt wollte ich doch glatt mal fragen, warum wir sowas selbst machen? So könntest Du es machen, erstmal abklopfen, warum ER das so wollte, und dann kann man auch konstruktiv einhaken und fragen "Aber was spräche gegen Lösung xyz? Immerhin wäre das schon fertig und wir könnten uns auf die Hauptarbeit konzentrieren?!"...
@Martin Schweikert: Vielen Dank für Deinen Beitrag und das Du Dir die Mühe gemacht hast so ausführlich zu schreiben. Finde ich gut formuliert und sehr aufs Thema bezogen. Die Information, dass ich mehr mit dem Projekt zu tun habe schien wirklich noch gefehlt zu haben. Martin S. schrieb: > Keiner kennt deinen PM. Es kann sein, dass man mit ihm Reden kann, wenn > man sinnvolle Argumente auf den Tisch legt, und sachlich bleibt Das Reden an sich halte ich nicht für das Problem, dass bringen von guten Argumenten, die wirklich überzeugen schon. Es geht dabei nicht mal um das Argument eine technische besser Lösung zu haben. Es geht vor allem darum, diese Argumente zu entkräften: - wir haben einen funktionalen Prototyp, welcher für einige Dinge brauchbare Code liefert, warum nochmal anfangen, es funktioniert doch? - was ist mit der Zeit / dem Aufwand der schon investiert wurde? Ich finde es schwierig eine Diskussion mit guten Argumenten zu führen, wenn auf der Gegenseite wenig Verständnis ist für softwaretechnische Dinge wie Komplexität, Wartbarkeit, Planung. (KISS,YAGNI, BDUF ...) Martin S. schrieb: > es gibt > aber auch Menschen wie meinen Chef, bei dem Entscheidungen nach > Sonnenstand um 15:34 getroffen werden, und dann absolut unumstößlich > sind. Ich habe Monate an einem Projekt deswegen verloren. Wie gehst Du damit um? Arrangieren? Meinung äußern? Wie ist dann Dein Frustlevel / Deine Motivation?
Hmm, immer schwierig sowas von aussen zu beurteilen, da uns ja nicht die Vorzeichen alle bekannt sind um aus einem Erfahrungsschatz schöpfen zu können. Irgendjemand KANN hier einem Fehlurteil unterliegen, entweder Du als Entwickler (kein Angriff, nur mal hypothetisch für die Diskussion) oder auch die anderen aus dem betreffenden Team. Ich hab da schon fast ALLES erlebt, supermotivierte Tekkies denen keiner was vorgemacht hat , aber auch protektionistische Eigenbrötler, die nichts drauf hatten als sich durch proprietäre Eigenentwicklungen unentbehrlich und unkündbar zu machen. Schwierig. Ich denk Du darfst/kannst/willst auch nicht zu sehr aus dem Nähkästchen plaudern um das zu präzisieren, verstehe ich. Ich glaub da können wir (ernsthaft) nix groß raten, was man da am besten macht. Klar, es gibt so eindeutig Sachen ... wo man gleich merkt dass das ne Scheissidee ist. Und Leute, nicht gleich pauschal aufs PM bashen, sind auch nur Menschen. Gibt Leute die nach 20 Jahren Berufserfahrung "an der Front" da rein rutschen weil sie Expertise mitbringen ;-) Muss nicht immer ein ahnungsloser Powerpoint-Blender-Schlipsi sein ... PS: Der Trick ist, das mit dem PM zu erörtern, ohne dabei den Kollegen eins reinzuwürgen ... Wenn das PM gut ist, hört es wenigstens mal zu und berücksichtigt die Bedenken. Wenn net, lasse machen und seh zu dasses für Dich schadlos bleibt. Gruß
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.