Gehalt für FI-AE mit Berufserfahrung

[.Erbse]

Sprich mehr Geld für die gleiche arbeit nur weil man noch einen Wisch hat?

Jup, die eigentliche Praxis in deutschen Unternehmen. :mod:

Muss aber nicht heisen das es auch richtig ist.

Frech wie ich bin, hab ich jedoch gleich mal ca. 30 % gefordert

Cool! Weiter so!

[BadDog]

....... vor allem ohne Führungsverantwortung, verdiene aber aufgrund der guten Hypezeiten deutlich mehr als du... (nur mal als Anregung an die Gehaltsexperten!)

Du sagtest es bereits : Hypezeiten .... die sind aber vorbei.

Logisch, das es 2001 und früher, deutlich mehr zu "verdienen" gab.

Nicht das wir uns falsch verstehen : Dein Einwand ist berechtigt - alleine schon um aufzuzeigen das es schwer ist, das absolute Ende der "Fahnenstange" zu definieren.

Zuviele Faktoren spielen eine Rolle :

Soft-Skills, Berufserfahrung, nachweisbare Qualifikationen (Zertis, Abschlüsse)

usw.

Gruss

BadDog

[Akku]

Nö nö Terminator ohne Studium bleiben dir bestimmte Posten einfach schon mal aus prinzip verschlossen. Da kannste noch soviel Berufserfahrung haben FIAE's sind einfach nur Programmierer und keine Softwareentwickler :>

Meine Meinung...

Das ist ja nicht zu fassen. In unserem Unternehmen (Ausbildungsstand 15%, 120 Mitarbeiter, davon ca. 75% Dipl. Ing.

und Dipl. Inf's) wurde ein FIAE'ler zum Softwaredesigner und eine FIAE'lerin zur Projet- und Produktmanagerin erkohren. Tut das eigentlich weh in so einer kleinen Welt zu leben?

[fiae am rhein]

Wow! Hier ist ja richtig was los. Ich hätte nicht gedacht, dass ich auf meine bescheidene Anfrage so viele Meinungen bekomme.

@Icemanemp

Ja ich arbeite wirklich nur mit VB/VBA. Das liegt daran, dass ich auch nur an einem Projekt arbeite, dass scheinbar ewig läuft. Da gibt es immer wieder Erweiterungen und Änderungen seitens des Kunden. Das Pflichtenheft bekomme ich dabei als Vorgabe, aber für die technische Umsetzung bin ich dann selbst verantwortlich. Während der Erstellung des Pflichtenhefts kann ich meine technische Meinung dazu abgeben und sagen, ob das so machbar sein wird. Aber das Grundkonzept mit Tabellen-Diagrammen und die fachlichen Vorgaben stehen eigentlich schon fest. Aber nach 9 Jahren kann ich doch trotzdem kein Junior-Entwickler mehr sein. Ich hab doch insbesondere auch im Projekt schon jede Menge Wissen gesammelt, dass meine Firma bei einem anderen Entwickler erstmal nicht vorfinden wird und bin der Hauptverantwortliche Entwickler in diesem Projekt.

Richtung Projektleitung würde ich gerne gehen, aber das hat bisher nicht so gut funktioniert. Das liegt aber auch daran, dass der derzeitige Projektleiter die Sache ziemlich gut im Griff hat und sobald ich mit einsteige läuft es aufgrund der Umstellung der Personen und meiner zugegeben nicht vorhandenen Erfahrung nicht mehr ganz so reibungslos. Da wird dann gerne schnell wieder zurückgerudert, um den Kunden nicht zu verärgern. Aber ich meine ohne praktischen Einsatz kann man sowas doch nicht lernen.

Frage dich einfach: Erhälst du für das, was du der Firma einbringst eine angebrachte Gegenleistung?

Gute Frage! Aber woher weiß ich, was ich der Firma einbringe. Das Projekt läuft noch, also kann es nicht so schlecht sein. Aber es wird auch immer gejammert, dass die Entwicklung oft länger dauert als geplant wobei der Kunde dafür nicht mehr als den vereinbarten Preis zahlt. Aber ob das mit dem länger dauern nun an meiner Arbeit oder an der vorher geschätzten Dauer liegt, weiß ich nicht.

@IJK und Erbse

Weiterbildung wäre mir auch sehr recht. Ich glaube aber nicht, dass die Firma das zahlt. Ich wäre der erste und vor allem würde meine Arbeitszeit wegfallen plus den Kosten für die Weiterbildung. Da ist die Firma mit einem etwas höheren Gehalt doch fast besser bedient.

Noch ein grundsätzliche Frage zu den Gehaltsverhandlungen: Muss ich erst mehr Leistung zeigen und zumindest teilweise die Projektleitung übernehmen und nachdem sich das bewährt hat gibt es mehr Gehalt oder kann ich erst mehr Gehalt verlangen unter der Vorgabe, dass ich diese Rolle übernehmen werde und muss mich dann beweisen. Mein Chef will immer erst die Leistung sehen und begründet das damit, dass er das Gehalt ja auch nicht wieder zurücksetzen kann, wenn ich die neuen Aufgaben nicht zufriedenstellend erfülle. Wer entscheidet eigentlich, was zufriedenstellend ist? Mein Chef ist da ziemlich anspruchsvoll, weil er selber die gleiche Arbeit macht und andere dann zumindest indirekt immer mit seiner Leistung vergleicht.

[Cleo]

Naja die Frage mit der Gehaltsverhandlung hast du dir ja dann selber schon beantwortet...

Aber warum willst du unbedingt mehr Leistung zeigen.. das würde ja ewig dauern um festzustellen, dass es gut oder schlecht läuft. Ich persönlich würde nicht wirklich das als Argument nehmen. Es ist ein Weilchen her mit deiner letzten Erhöhung und es wird mal wieder Zeit. Würde mich dann auch noch wo anders Bewerben und ihm das Brav unter die Nase reiben.. Also ala "Ich hab mich mal auf dem Markt umgesehen und musste feststellen, dass mein Gehalt unter xy liegt"... Irgendwie so . Solltest aber vorher für dich selber klären, ob er auf dich angewiesen ist bzw. dich unbedingt halten will.. dann kannste ein wenig fordender sein.. Zudem sind neue Aufgaben etc. in Ordnung für einen grossen Gehaltsspruch aber das wird dann wohl eher mit der Zeit kommen, wenn du andere Aufgaben übernimmst. Jetzt ist m.E. ein etwas kleinerer Gehaltsspruch rauszuholen alleine schon wegen deiner Zugehörigkeit zu der Firma und deinem aufgebauten Wissen.

Noch zur Info: Das ist meine eigene subjektive Meinung! Ein richtiges Vorgehen gibts da wohl nicht! Es kommt immer darauf an, wer vor einem sitzt und wie man sich präsentieren/verkaufen kann etc....

[perdian]

Aber woher weiß ich, was ich der Firma einbringe.

Da muss man einfach ein Gefühl für bekommen. Was kommt an Feedback vom Kunden bzw. demnjenigen, der die Applikation tatsächlich einsetzt zurück? Wenn hier ein "super, jetzt komme ich endlich wieder dazu auchmal was anderes zu tun als immer nur Tätigkeit X auszuführen" dann ist das schonmal ein sehr gutes Zeichen. Je nach Einsatzgebiet lässt sich das auch direkt in Zahlen ausdrücken. Wenn plötzlich die Bestellungen um 20% ansteigen und pro Bestellung X EUR eingenommen werden, dann kannst du dir ganz direkt ausrechnen wieviel dein Einsatz bringt. Das sind nur zwei Beispiele, da gibt es noch eine ganze Reihe mehr - da ist ein wenig Erfahrung und Fingerspitzengefühl gefragt.

Aber es wird auch immer gejammert, dass die Entwicklung oft länger dauert als geplant wobei

Wenn die Entwicklung immer länger dauert als geplant, dann ist schlicht und ergreifend die Planung falsch und nicht an der Realität ausgerichtet. Wenn ich mich 10x in meiner Zeitplanung nach oben hin verschätze, dann muss ich beim 11. Mal eben hingehen und von vorneherein mehr Zeit einplanen.

würde meine Arbeitszeit wegfallen plus den Kosten für die Weiterbildung. Da ist die Firma mit einem etwas höheren Gehalt doch fast besser bedient.

Das ist eine schlecht Argumentation, wenn du tatsächlich die Weiterbildung machen möchtest. Genauso könnte man argumentieren, dass du zwar kurzfristig als Arbeitskraft ein paar Tage ausfällst, jedoch längerfristig deutlich bessere Kenntnisse hast um deine Aufgaben schneller und effizienter zu erledigen. Und genau diese Einsparungen an Zeit/Geld/Resourcen refinanziert letzten Endes wieder die Kosten für die Schulung und den Ausfall deiner Arbeitszeit.

Muss ich erst mehr Leistung zeigen und zumindest teilweise die Projektleitung übernehmen und nachdem sich das bewährt hat gibt es mehr Gehalt oder kann ich erst mehr Gehalt verlangen unter der Vorgabe, dass ich diese Rolle übernehmen werde und muss mich dann beweisen.

Da gibt es keine Regelung für. Für (d)eine Argumentation ist es sicherlich deutlich besser, wenn du sagen kannst/könntest "Ich habe die letzten Monate zusätzlich die Projektleitung übernommen und die Mitarbeiterkoordination durchgeführt und deshalb habe ich eigentlich auch Anspruch auf eine bessere Entlohnung" aber ich sehe so etwas nicht als muss an.

Wer entscheidet eigentlich, was zufriedenstellend ist?

Derjenige, der letzten Endes für die Leistung bezahlt, was im Falle deiner Arbeitsleistung dein Chef ist.

In letzter Konsequenz ist es eigentlich ganz einfach: Wenn dein Chef dich nicht angemessen für deine Leistung entlohnt (das muss nicht immer unbedingt durch Geld erfolgen), dann musst du dir einen anderen Job suchen, wo genau das der Fall ist.

[.Erbse]

In letzter Konsequenz ist es eigentlich ganz einfach: Wenn dein Chef dich nicht angemessen für deine Leistung entlohnt (das muss nicht immer unbedingt durch Geld erfolgen), dann musst du dir einen anderen Job suchen, wo genau das der Fall ist.

Der Meinung bin ich auch!

Wenn sich deine Firma dein Können und deine Erfahrung nicht mehr leisten kann, ist das Wechseln des Arbeitsplatzes die einzig richtige Entscheidung.

Hast du dich schon als Freiberufler versucht?

[fiae am rhein]

Da muss man einfach ein Gefühl für bekommen. Was kommt an Feedback vom Kunden bzw. demnjenigen, der die Applikation tatsächlich einsetzt zurück?

Wenn die Entwicklung immer länger dauert als geplant, dann ist schlicht und ergreifend die Planung falsch und nicht an der Realität ausgerichtet. Wenn ich mich 10x in meiner Zeitplanung nach oben hin verschätze, dann muss ich beim 11. Mal eben hingehen und von vorneherein mehr Zeit einplanen.

Die Rückmeldung vom Kunden besteht darin, dass es immer neue Wünsche gibt, also scheint das System genutzt zu werden. Nach Updates gibt es immer erstmal Stress, weil nicht alles auf Anhieb funktioniert. Aber ansonsten ist das ein ganz angenehmes arbeiten.

Wenn ich bei der Zeitplanung so plane, dass ich hinkommen würde oder zumindest mal glaube es würde reichen, dann fragen Kunde und Chef immer, warum das denn so lange dauert und dass es doch eigentlich schneller gehen müsste. Also entweder ich bin zu langsam oder die erwarten zu viel. Meine Meinung dazu ist eindeutig.

@Erbse:

Als Freiberufler nur mit VB/VBA könnte das schwierig werden. Mir gefällt die Arbeit ja auch ganz gut und das Betriebsklima ist auch ok. Nur die Bezahlung würde ich gerne verbessern.

Aber nach den vielen Tipps von euch werde ich nochmal alles zusammenfassen und mich auf das nächste Gespräch vorbereiten. Bin gespannt, was dabei rausspringt.

[perdian]

Nach Updates gibt es immer erstmal Stress, weil nicht alles auf Anhieb funktioniert.

Dann ist der Update Prozess schlicht. Wenn etwas nicht funktioniert heisst das, dass ein vorheriger Test schlecht (oder gar nicht?) gelaufen ist, denn genau dort hätte so etwas herauskommen müssen. Wenn ich als Kunde ein Programm vorgesetzt bekomme mit den Worten "so, alles neu, alles besser" und es funktioniert nicht so, wie ich möchte, dann ist etwas schief gelaufen. Entweder ist nicht gut genug kommuniziert worden, was das Programm denn genau können soll, oder aber bei der Implementierung ist geschlampt worden.

Wenn ich bei der Zeitplanung so plane, dass ich hinkommen würde oder zumindest mal glaube es würde reichen, dann fragen Kunde und Chef immer, warum das denn so lange dauert und dass es doch eigentlich schneller gehen müsste.

Kommt mir doch irgendwoher bekannt vor... bei mir war das damals einer von mehreren Gründen, wieso ich in meiner alten Firma gekündigt habe. Wenn ein Vorgesetzter nicht akzeptiert, dass die Umsetzung bestimmter Features, mit dem Anspruch ein qualitativ hochwertiges Produkt abzuliefern, eben nicht innerhalb einer kurzen Zeit fertig ist, dann ist das kein Zustand unter dem ich längere Zeit arbeiten kann.

Wer dann hingeht und auf irgendeine Weise versucht schneller zu arbeiten wird unnötige Fehler einbauen. Diese nach dem Release wieder zu beheben braucht Zeit, der Kunde ist unzufrieden, weil auf Anhieb nicht alles so läuft wie gedacht (siehe oben) und so weiter. Unter dem Strich schlechter, als wenn man sich direkt von Anfang an mehr Zeit genommen hätte.

Gut, billig, schnell - wähle zwei!

[Bubble]

Ich bin es in einer kleinen Firma eher gewöhnt sehr tief mit im Entscheidungs- und Planungsprozess eingebunden zu sein, und möchte das eigentlich auch nicht mehr missen.

Ab einer gewissen Projektgröße sind solche Eingriffe in alle Aspekte eines Projektes nicht nicht mehr vernünftig koordinierbar, sondern allenfalls noch in einem vorab klar begrenzten Teilbereich umsetzbar, da nicht mehr alle Beiteiligten einen vollständigen Überblick über alle Teilaspekte besitzen.

Natürlich ist ein FI dafür geeignet, aber ich würde es als wenig herausfordernd und von daher als nicht wirklich interessant empfinden nur nach Schema F Vorgaben, die mir von "oben" gegeben werden abzuarbeiten ohne selbst noch irgendwo konzeptionell tätig zu werden.

Kann man verstehen, aber wieso sollten grade Studenten dies anders sehen?

[Bubble]

Ja ich arbeite wirklich nur mit VB/VBA. Das liegt daran, dass ich auch nur an einem Projekt arbeite, dass scheinbar ewig läuft.

Hast Du wirklich seit 9 Jahren nur an diesem einzigen Projekt entwicklet?

[perdian]

Ab einer gewissen Projektgröße sind solche Eingriffe in alle Aspekte eines Projektes nicht nicht mehr vernünftig koordinierbar, sondern allenfalls noch in einem vorab klar begrenzten Teilbereich umsetzbar, da nicht mehr alle Beiteiligten einen vollständigen Überblick über alle Teilaspekte besitzen.

Richtig, aber wenn ein Projekt solche Ausmaße erreicht, dann hat der Projektleiter seine Arbeit erst recht auf das planerische zurückzuführen und der Fachabteilung keine Vorgaben zu Datenbankmodellierung oder ähnlichem zu machem. Es läuft letzten Endes auf ein sehr einfaches Grundmodell heraus: Jeder macht das, was er am besten kann und dazu gehört - für mich - eben Entscheidungen zum Software-Design von denen machen zu lassen, die die Funktionalität umsetzen müssen. Entscheidungen zum Projekt als solches - und nur die - werden vom Projektmanager gefällt.

aber wieso sollten grade Studenten dies anders sehen?

Weil die (nicht immer, aber häufig) alleine schon zeitlich einen ganz anderen Rahmen haben. Wer 2x die Woche für ein paar Stunden "vorbeikommt" wird von es von sich aus schon eher begrüßen einen klar umschriebenen Arbeitsauftrag zu haben, den er nur abarbeiten muss. Wer hingegen acht Stunden, fünf Tage die Woche entwickelt fühlt sich mit sowas sehr leicht unterfordert.

[Bubble]

Richtig, aber wenn ein Projekt solche Ausmaße erreicht, dann hat der Projektleiter seine Arbeit erst recht auf das planerische zurückzuführen und der Fachabteilung keine Vorgaben zu Datenbankmodellierung oder ähnlichem zu machem.

Er kann durchaus sagen: Gruppe A entwift das gemeinsame DB-Modell, Gruppen B-F Softwarekomponenten, die auf dieses Modell zugreifen. Geh' ruhig davon aus, dass alle Gruppen im Vorfeld auch kommunizieren und A nicht einfach irgendwas im völligen Alleingang zusammenmodelliert.

Wer hingegen acht Stunden, fünf Tage die Woche entwickelt fühlt sich mit sowas sehr leicht unterfordert.

Man kann auch argumentieren, wer pro Woche 40h (oder mehr) entwickelt ist eh zu eingespannt, um noch wirklich geistig kreativ zu sein, und die Dinge auch mal aus einem anderen Blickwinkel zu sehen.

[perdian]

Geh' ruhig davon aus, dass alle Gruppen im Vorfeld auch kommunizieren und A nicht einfach irgendwas im völligen Alleingang zusammenmodelliert.

Na wenn das der Fall ist - wunderbar. Ich bin vielleicht einfach schon zu realitätsgeschädigt und kenne nur die Fälle, wo es nicht funktioniert

Man kann auch argumentieren, wer pro Woche 40h (oder mehr) entwickelt ist eh zu eingespannt, um noch wirklich geistig kreativ zu sein, und die Dinge auch mal aus einem anderen Blickwinkel zu sehen.

Das mag sicherlich dem ein oder anderen so gehen - ist wohl eine Frage der Persönlichkeit. Aber gerade in Zeiten, wo es darum geht sich durch Kenntnisse und Fähigkeiten abzusetzen halte ich doch viel mehr von der Einstellung "wenn möglich auf einer breiten Basis am Entwicklungsprozess mitwirken".

[fiae am rhein]

Hast Du wirklich seit 9 Jahren nur an diesem einzigen Projekt entwicklet?

Das nun nicht. Aber in meiner aktuellen Firma bei der ich seit 3 Jahren bin habe ich wirklich nur an einem Projekt gearbeitet. Das geht eben immer weiter und da ich am besten eingearbeitet bin, bin ich auch der erste derzuständig ist wenn der Kunde neue Wünsche hat.

Das war ihr alles zur Aufgabenteilung und Zuständigkeiten schreibt ist ja richtig trifft aber bei uns nicht wirklich zu, weil das Projekt zu klein ist. Es gibt nur 2-3 Personen, die mit dem Projekt zu tun haben.

Vielleicht ist das Problem auch mehr der Projektleiter, der sich bei der Entwicklung auch gut auskennt und dann sehr viel vorgibt und mit meinen Lösungen nicht zufrieden ist. Auch wenn die funktionieren, aber nicht "hübsch" genug oder verständlich genug sind.

[Bubble]

Vielleicht ist das Problem auch mehr der Projektleiter, der sich bei der Entwicklung auch gut auskennt und dann sehr viel vorgibt und mit meinen Lösungen nicht zufrieden ist. Auch wenn die funktionieren, aber nicht "hübsch" genug oder verständlich genug sind.

Kannst Du ein paar Beispiele nennen, was er konkret anders möchte?

3 Jahre beim gleichen Projekt klingt für mich nicht mehr so bedenklich, wie beinahe 10 Jahre mit nichts anderem beschäftigt.

[fiae am rhein]

Was er anders möchte?

Er findet meine Tabellenentwürfe nicht optimal und meint mit einer besseren Strukturierung seien die erweiterbarer, so dass ich bei neue Anforderungen nicht mehr so viel Arbeit hätte.

Oder im Code würde ich zu wenig auf Wiederverwendbarkeit oder algorithmische Strukturen achten sondern einfach nur drauflos coden. Außerdem würde ich zu wenig versuchen, den schon vorhandenen Code anzupassen und stattdessen immer was neues coden.

Aber wie gesagt, meine Lösungen funktionieren auch. Sie sind ihm aber nicht immer gut genug. Wenn ich aber meinen Stil verwende, komme ich gut klar und weiß auch, wie es funktioniert. Wenn ich zu viele Funktionen verwende und alles zerstückelt wird, finde ich, kann man das nicht mehr so gut lesen oder debuggen.

[kingofbrain]

Servus,

es kommt mir bei Deiner Beschreibung so vor, als hätte Dein Chef durchaus Recht mit seiner Kritik.

Code vernünftig zu strukturieren, evtl. sogar objektorientiert zu arbeiten (kommt auf die Sprache an), Algorithmen auszulagern, wiederzuverwenden usw. sind bewährte und anerkannte Mittel der Softwareentwicklung.

Bei Dir kommt es mir - wieder aufgrund Deiner Beschreibung - so vor, als würdest Du bei einem neuen Problem folgendermassen vorgehen (Achtung, ein wenig überspitzt):

Problem: neuen Dateneingabedialog, der den bestehenden Login-Dialog ersetzt.

Lösung: Dialog codieren, Login-Logik codieren, testen, fertig.

Ergebnis: Ein Stück Code, das einen Dialog definiert, die GUI zusammensetzt, die Actions abhandelt und fertig.

Eigentlich sollte es aber anders laufen. Login ist ein elementarer Teil der Software, es benötigt Eingabe-Informationen und liefert ein Ergebnis. Man müsste - wenn man richtig gearbeitet hat - bei einer Erweiterung der Logik beim Login nur die Logikkomponente anpassen, sonst nichts.

Natürlich ist es erst mal einfacher, seinen gewohnten Stiefel zu programmieren. Aber das ist keine Softwareentwicklung sondern fabriziert schlecht wart- und erweiterbaren Code.

Peter

[perdian]

Er findet meine Tabellenentwürfe nicht optimal und meint mit einer besseren Strukturierung seien die erweiterbarer, so dass ich bei neue Anforderungen nicht mehr so viel Arbeit hätte. [...] Aber wie gesagt, meine Lösungen funktionieren auch. Sie sind ihm aber nicht immer gut genug. Wenn ich aber meinen Stil verwende, komme ich gut klar und weiß auch, wie es funktioniert.

Das ist doch aber schonmal ein Punkt, wo du durchaus ansetzen kannst. Dein Chef ist letzten Endes derjenige, der beim Kunden für die Software geradestehen muss und auch derjenige, der dir dein Geld überweist. Von daher: Wer die Musik bestellt, der bestimmt auch was sie spielt. Wenn dein Chef will, dass das Programm so und so geschrieben und strukturiert wird, dann ist für dich als Angestellter ganz klar die Vorgabe: Machen!

Ich habe mich in meinem altern Job auch oft tierisch darüber geärgert, dass mein Chef nicht mit meinen Lösungen zufrieden war. Und natürlich war ich im Glauben es besser und "richtiger" machen zu können, als er es gerne möchte (in dem Glauben bin ich übrigens immer noch). Aber wenn er mir sagt "Nein, ich möchte das so", dann mache ich halt mal die Faust in der Tasche und mache es genauso wie er es will - aus diesem Grund ist er Chef, weil er eben sagen darf, wie er es haben will.

Wenn es sich dann hinterher rausstellt, dass es auf die Art und Weise deines Chefs schlechter war, nicht funktioniert oder voller Bugs ist kannst du immer noch sagen "siehst du - ich wollte es ja auch anders machen, aber durfte nicht". Bis dahin kannst du aber als Punkt bei genau diesem Thema anführen, dass du es genauso gemacht hast wie dein Chef sich das vorgestellt hat.

Wenn ich zu viele Funktionen verwende und alles zerstückelt wird, finde ich, kann man das nicht mehr so gut lesen oder debuggen.

Auch wenn es nicht mehr wirklich zum Thema passt: In der Regel ist genau das Gegenteil der Fall. In je mehr kleine (möglichst unabhängige) Teile du dein Programm aufsplitten kannst, desto besser ist es sowohl von der Wiederverwendbarkeit, als auch von der Wartbarkeit und der Möglichkeit zu debuggen.

Ein richtig gutes objektorientiertes Programm z.B. zeichnet sich dadurch aus, dass eine einzelne Klasse praktisch kaum noch "wirkliche" Arbeit ausführt. Es gibt sogar ganze Aufsätze und Styleguides die nüchtern technisch vorschreiben "Mehr als X Zeilen Code pro Methode gibt Grund zu einem Refactoring". Da halte ich zwar persönlich recht wenig von, aber es zeigt den generellen Weg - erst im Zusammenspiel von mehreren Komponenten und Teilen wird ein Programm zu dem was es ist - eben mehr als die Summe seiner Teile.

Ohne die genaueren Zusammenhänge zu kennen und daher eine wirklich kompetente Bewertung abgeben zu können möchte ich mich trotzdem dem Statement anschließen:

es kommt mir bei Deiner Beschreibung so vor, als hätte Dein Chef durchaus Recht mit seiner Kritik.