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.
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 ;-)
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ß
