Programmierstrategien technische Projektleitung

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich suche nach Ratschlägen, um die technische Projektleitung in der SPS-Programmierung effizienter zu gestalten. In unserer Abteilung, die erst vor einigen Monaten gegründet wurde, gibt es verschiedene Rollen: einen Teamleiter für Personal und Administration, einen Verantwortlichen für die technische Projektleitung und ein Berater für technische Fragen.

Aktuell besteht das Team aus etwa sieben SPS-Programmierern, die unterschiedliche Erfahrungslevels haben – einige sind sehr erfahren und kennen die Maschinen gut, während andere neu im Bereich sind. Die allgemeine Stimmung im Team ist positiv, jedoch gibt es Herausforderungen, die den Überblick erschweren.

Ein zentrales Problem ist, dass die Teammitglieder die Vorgaben oft unterschiedlich interpretieren, was dazu führt, dass viele Aufgaben nicht wie geplant verlaufen. Nach einigen Schwierigkeiten mit der alten Software und den Zulieferern haben wir uns entschieden, von Grund auf neu zu starten. Gleichzeitig gibt es Vorgaben der Geschäftsleitung, dass die Umsetzung zügig erfolgen muss, da die Software dringend benötigt wird.

Ich frage mich, wie die technische Projektleitung (tP) in diesem Kontext am besten organisiert werden kann. Es wäre ideal, wenn die tP alle Details der Projekte kennt, aber ich erkenne auch, dass dies in der Praxis oft nicht möglich ist. Mir scheint, dass viele Teammitglieder eher reaktiv handeln, anstatt proaktiv Probleme zu vermeiden.

Ich wäre dankbar für Tipps oder Best Practices, die helfen könnten, die technische Projektleitung in dieser Situation zu optimieren und die Zusammenarbeit im Team zu verbessern.

Vielen Dank im Voraus für eure Unterstützung!

Update:
- Es geht um alle Fragen wie z.B. Mitarbeiterführung, Organisation, Qualitätssicherung, Richtlinien usw. Im Kern werden alle Themen berührt, welche es da zu finden gibt.

- Verwendetet Tools: Jira, Confluence, Tia Portal, Projektserver, GitHub
Aber: Die Tools sind noch nicht mit einander verbunden und vieles muss händisch geleistet werden.

- Es sind vorrangig Serienmaschine aber mit vielen Optionen und Variationen. Die Maschinen werden in der Luft und Raumfahrt eingesetzt und sind eine Eigenentwicklung der Firma. Aber es gibt viele Komponenten die zugekauft werden.

 

[roboticBeet]

Geht es dir eher um Fragen des Projektmanagements bzw. der Mitarbeiterführung, um Qualitätsprüfung in der (SPS-)Softwareentwicklung oder um Programmier- und Projektierungsvorgaben/-richtlinien?

Falls es um um letztere Aspekte, also die direkte technische Umsetzung, geht, welche Tools nutzt ihr in der Regel? TIA Portal?

 

[roboticBeet]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und im Sonder- oder Serienmaschinenbau, Anlagenbau oder baut ihr für die Eigenverwendung und optimiert/erweitert zugekaufte Maschinen?

 

[Blockmove]

Bei 7 Programmierern einen Admin, einen technischen Leiter und einen Berater … Aus meiner Sicht nicht sehr effizient.

 

[Tmbiz]

Geht es dir eher um Fragen des Projektmanagements bzw. der Mitarbeiterführung, um Qualitätsprüfung in der (SPS-)Softwareentwicklung oder um Programmier- und Projektierungsvorgaben/-richtlinien?

Falls es um um letztere Aspekte, also die direkte technische Umsetzung, geht, welche Tools nutzt ihr in der Regel? TIA Portal?

Und im Sonder- oder Serienmaschinenbau, Anlagenbau oder baut ihr für die Eigenverwendung und optimiert/erweitert zugekaufte Maschinen?

Ich habe im Beitrag oben ein paar Updates eingefügt. Aber im Kern geht es um alle Fragen. Von der Führung der Mitarbeiter bis zum Git Hub. Was man aktuell erkennen kann, ist dass unter den steigenden Drück verschiedenen Vorstellungen kommuniziert werden, wie man den Herausforderungen begegnen sollte. Da gibt es die Leute, die der Ansicht sind, dass man doch jetzt einfach mal machen sollte und die Probleme später behoben werden können und andere, die meinen, dass es besser ist, erst die die Probleme anzugehen.

 

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei 7 Programmierern einen Admin, einen technischen Leiter und einen Berater … Aus meiner Sicht nicht sehr effizient.

Was wäre aus deiner Sicht zu ändern und anzupassen?

 

[DerOnkel]

Bei so vielen Leuten muss die Anlage in einzelne Blöcke aufgeteilt werden, die Interfaces für die Blöcke klar definiert und mit einer Doku versehen werden. Dann kann jeder Block immer wieder einzeln getestet/erweitert werden. Damit lassen sich die Fortschritte besser beurteilen und die Fehlersuche eingrenzen.

Mit einem nicht eingespielten Team in alten Code rumzurühren ist meiner Erfahrung nach nicht gut, wenn es möglich ist, dann einen Spezialisten ernennen und ihm die Arbeit übergeben. Ansonsten mit neuen Konzepten arbeiten und zukunftsorientiert arbeiten, wenn das Budget es hergibt.

Hat die entsprechende Person (Projektleiter) schon Erfahrungen im Opensource Bereich?

 

[kafiphai]

Hier ein sehr klarer Anfang.

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was wäre aus deiner Sicht zu ändern und anzupassen?

Als SPS-Programmierer brauchst du Informationen. Was hat sich der mechanische Konstrukteur gedacht? Warum hat der Hardware-Planer diesen Sensor gewählt? Welche Schnittstellen mit welchen Daten gibt es? Usw.
Also muss - aus meiner Sicht - ein einfacher direkter Zugriff auf die notwendigen Informationen möglich sein.
Und am einfachsten ist wohl die direkte Kommunikation.
Klar kann man alles spezifizieren. Aber nimm mal eine Ablaufbeschreibung ... Wenn die richtig ausführlich ist, dann ist sie länger als das SPS-Programm. Der mechanische Konstrukteur braucht ewig zum Schreiben, der SPSler ewig zum Lesen. Sperr ich den Mechaniker und den SPSler einen Nachmittag zusammen, dann sparen beide viel Zeit. Mit Hardware und Schnittstellen das Selbe.
Ein technischer Projektleiter kann bei sowas dabei sein, sollte aber weitgehend passiv sein. Er muss ja die Software nicht erstellen. Ich hab mal zu einem Chef gesagt, dass ich ihn als Dienstleister sehe. Er muss das Umfeld so gestalten, dass ich effizient arbeiten kann.
Du hast als Tools Jira und Confluence genannt. Also liegt die Vermutung nahe, dass ihr mit agilen Methoden arbeitet?
Viele gehen davon wieder weg. Das Managen und Dokumentieren der Aufgaben braucht oft mehr Zeit als die eigentliche Arbeit selbst. Ausserdem verhindern solche Tools oft auch den direkten Austausch untereinander und im Team. Ich kann bei ner gemütlichen Kaffeerunde mehr klären als mit 3 Stunden Jira pflegen. Proaktives Arbeiten erschweren solche Tools, zumindest wenn sie nicht richtig eingesetzt werden.
Manchmal ist es besser sich an nem kleinen Handwerksbetrieb zu orientieren als an nem riesen IT-Konzern.

 

[ducati]

Nach einigen Schwierigkeiten mit der alten Software und den Zulieferern haben wir uns entschieden, von Grund auf neu zu starten.

Oft ist das so ne Trotzreaktion, weil man das alte nicht versteht. Am Ende ist nicht garantiert, dass das neue wirklich besser ist.
Wenn man was neu aufzieht, braucht man wirklich gute erfahrene motivierte Leute, die das neue Konzept definieren und umsetzen.

Gleichzeitig gibt es Vorgaben der Geschäftsleitung, dass die Umsetzung zügig erfolgen muss, da die Software dringend benötigt wird.

ja, wir machen alles neu, muss aber morgen fertig werden. Da kommt sicherlich nix gutes bei raus. Zumal ein neuer Standart auch erstmal über 2-3 Projekte reifen und sich etablieren muss.

Mir scheint, dass viele Teammitglieder eher reaktiv handeln, anstatt proaktiv Probleme zu vermeiden.

Ein Problem der heutigen Zeit, es wird nur nach Schuldigen gesucht und nicht mehr auf dem kurzen pragmatisch Dienstweg nach Lösungen.

Ich wäre dankbar für Tipps oder Best Practices, die helfen könnten, die technische Projektleitung in dieser Situation zu optimieren und die Zusammenarbeit im Team zu verbessern.

Tja, schwierig aus der Ferne da Tipps zu geben. Am Ende läufts schon irgendwie und keiner weiss warum.
Jedenfalls nicht, weil man sich so viele Gedanken über Projektmanagement gemacht hat, sondern weil wenigstens 1-2 Leute mal pragmatisch und ordentlich was weggearbeitet haben.

 

[ducati]

Als SPS-Programmierer brauchst du Informationen.

Vor allem auch immer aktuelle und die richtigen.

Oft immer ein Problem der "Projektleitung" aufeinander abfolgende Arbeiten einzuschätzen und und zu wissen, wer braucht wofür wie lange. Dazu dann Änderungsmanagement.
Wenn dann bei Termindruck noch "parallel" gearbeitet werden muss, endets oft im Chaos, wenn die Leute zu unerfahren sind.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

ja, wir machen alles neu, muss aber morgen fertig werden. Da kommt sicherlich nix gutes bei raus. Zumal ein neuer Standart auch erstmal über 2-3 Projekte reifen und sich etablieren muss.

Wenn man das dann noch über Jira und Git macht, dann dauert es noch länger.
Bei 7 Programmierern kann man über Best Practice einfach mal nach der Mittagspause einmal in der Woche 1-2 Std. diskutieren. Wenn dann was Vernünftiges rauskommt, dann kann es dokumentiert und eine lockere Ideensammlung gepackt werden. Daraus kann dann ein Standard entstehen. Und nicht vergessen: Mit einem Standard kann man eine Firma in den Untergang treiben.

 

[ducati]

Wenn man das dann noch über Jira und Git macht, dann dauert es noch länger.
Bei 7 Programmierern kann man über Best Practice einfach mal nach der Mittagspause einmal in der Woche 1-2 Std. diskutieren. Wenn dann was Vernünftiges rauskommt, dann kann es dokumentiert und eine lockere Ideensammlung gepackt werden. Daraus kann dann ein Standard entstehen. Und nicht vergessen: Mit einem Standard kann man eine Firma in den Untergang treiben.

Ich weiss ja nicht, obs dem TE jetzt vorrangig um einen neuen Programmierstandard geht oder allgemein um Projektchaos?
Für beides bräuchtest jeweils einen top erfahrenen Mann, der die Arbeit für die restlichen 5 definiert und koordiniert.
Wenn Du anfängst über Programmierstile zu diskutieren, endets so wie hier im Forum im Chaos.
Welcher Programmierstil "besser" ist, ist eigentlich scheißegal.
Er muss sehr sehr einfach sein und funktionieren und dann für x Jahre unverändert bleiben.

Was man auf jeden Fall versuchen sollte zu vermeiden ist "german overengineering". So gut wie immer ist weniger mehr! Dass die Vertriebler das "weniger" trotzdem als das nonplusultra verkaufen, kriegen die schon hin

 

[Blockmove]

Für beides bräuchtest jeweils einen top erfahrenen Mann, der die Arbeit für die restlichen 5 definiert und koordiniert.
Wenn Du anfängst über Programmierstile zu diskutieren, endets so wie hier im Forum im Chaos.
Welcher Programmierstil "besser" ist, ist eigentlich scheißegal.
Er muss sehr sehr einfach sein und funktionieren und dann für x Jahre unverändert bleiben.

Was man auf jeden Fall versuchen sollte zu vermeiden ist "german overengineering". So gut wie immer ist weniger mehr!

Man muss immer im Hinterkopf haben: Je mehr Standard umso weniger Innovation.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man muss immer im Hinterkopf haben: Je mehr Standard umso weniger Innovation.

Innovation hin oder her, abundzu muss man aber auch effizient Projekte abarbeiten ohne ständig drüber nachzudenken, was man anders machen könnte
Zumal anders meist nicht zwangsläufig besser ist.

 

[Blockmove]

Innovation hin oder her, abundzu muss man aber auch effizient Projekte abarbeiten ohne ständig drüber nachzudenken, was man anders machen könnte
Zumal anders meist nicht zwangsläufig besser ist.

Ich hatte mal eine Diskussion mit einem Zulieferer über den Einsatz eines anderen Frequenzumrichters. Aussage war: Ist nicht in unserem Standard drin. Wir erzeugen Schaltpläne und SPS-Grundstruktur automatisch über Generatoren. Da nen anderen Umrichter einzupflegen geht nicht so einfach. Ich denk mal, dass war auch so ein Beispiel für das von dir angesprochene "german overengineering".

 

[ducati]

Ich hatte mal eine Diskussion mit einem Zulieferer über den Einsatz eines anderen Frequenzumrichters. Aussage war: Ist nicht in unserem Standard drin. Wir erzeugen Schaltpläne und SPS-Grundstruktur automatisch über Generatoren. Da nen anderen Umrichter einzupflegen geht nicht so einfach. Ich denk mal, dass war auch so ein Beispiel für das von dir angesprochene "german overengineering".

jein. Eigentlich hattest Du den Fall, dass der Standard des Zulieferers mit dem Standard des Endkunden kollidiert. Das ist immer Mist, entweder zwingst den Zulieferer zu Deinem Standard, dann wirds aber teuer und Scheisse, weil der Zulieferer sich mit Deinem Standard nicht auskennt. Oder Du nimmst den Standard des Zulieferers, dann ist zwar die Maschine top, aber die Instandhalter/Betreiber krigen die Krise irgendeinen Tod musst sterben.
Ansonsten hab ich ja oben geschrieben, ein Standard mus sehr sehr einfach sein.
In meiner alten Firma hatten wir KEINEN Superspezialmotorspsbaustein der nur mit Danfoss konnte. Sondern einen Standard-Baustein der irgendwas ein/ausschalten konnte, einen Standard-Baustein der irgendwas stetig ansteuern konnte, einen Spezial-Baustein zur Busankopplung von Danfoss. Damit bleibst flexibel... Trotzdem haben wir nach Möglichkeit immer Danfoss eingesetzt, weil damit kannten sich halt alle erstmal aus.

 

[DerOnkel]

Zuviel Werbung?
-> Hier kostenlos registrieren

jein. Eigentlich hattest Du den Fall, dass der Standard des Zulieferers mit dem Standard des Endkunden kollidiert. Das ist immer Mist, entweder zwingst den Zulieferer zu Deinem Standard, dann wirds aber teuer und Scheisse, weil der Zulieferer sich mit Deinem Standard nicht auskennt. Oder Du nimmst den Standard des Zulieferers, dann ist zwar die Maschine top, aber die Instandhalter/Betreiber krigen die Krise irgendeinen Tod musst sterben.
Ansonsten hab ich ja oben geschrieben, ein Standard mus sehr sehr einfach sein.
In meiner alten Firma hatten wir KEINEN Superspezialmotorspsbaustein der nur mit Danfoss konnte. Sondern einen Standard-Baustein der irgendwas ein/ausschalten konnte, einen Standard-Baustein der irgendwas stetig ansteuern konnte, einen Spezial-Baustein zur Busankopplung von Danfoss. Damit bleibst flexibel... Trotzdem haben wir nach Möglichkeit immer Danfoss eingesetzt, weil damit kannten sich halt alle erstmal aus.

Ja so ähnlich ist es bei uns auch, ein allgemeiner Baustein für An/Aus/Drehrichtung/Drehzahl/Drehmoment und die Rückführung des Istwert. Der Spezialbaustein kommt dahinter, der beinhaltet die komplexen Dinge, aber am Programm ändert das nichts, egal was hinten dran hängt. Selbst zwischen FU/Sanftanlauf/Schützschaltung.

 

[Cassandra]

Hier ein sehr klarer Anfang.

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

Hat mich nicht so gut überzeugt.

Ein Hochglanz-Versprechen auf Knopfdruckführung – realitätsfern und selbstherrlich.
Wer Menschen wirklich führen will, braucht mehr Demut als Durchgriffsfantasien.

 

[DerOnkel]

Hat mich nicht so gut überzeugt.

Ein Hochglanz-Versprechen auf Knopfdruckführung – realitätsfern und selbstherrlich.
Wer Menschen wirklich führen will, braucht mehr Demut als Durchgriffsfantasien.

Würde ich so nicht unterschreiben. Es kommt auch auf den Ort des Unternehmens an, ist der auf einem Dorf mit schwacher Umgebung freut man sich über jede Hand, in einer Großstadt kann man natürlich sieben wie ein Weltmeister.

Hier ein sehr klarer Anfang.

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

Das Video war interessant und inspirierend, eignet sich mehr für ein Neubeginn.