Programmierstrategien technische Projektleitung

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat mich nicht so gut überzeugt.

Mich auch nicht. Eine vernünftige Projektleitung geht so, sorry:

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 trifft auch die Aussage "Sei der Dümmste im Raum".

 

[Blockmove]

Wer Menschen wirklich führen will, braucht mehr Demut als Durchgriffsfantasien.

Sehe ich auch so. Kein guter SPSler braucht einen Chef. Bei der Inbetriebnahme an der Anlage muss er in der Lage sein die Probleme selbstständig und im Team mit den anderen Fakultäten zu lösen. Gute Führung heißt einen jungen Mitarbeiter auf diesen Stand zu bringen. Also vernünftige Rahmenbedingungen schaffen un vielleicht manchmal eine schützende Hand bieten.

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mich auch nicht. Eine vernünftige Projektleitung geht so, sorry:

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 trifft auch die Aussage "Sei der Dümmste im Raum".

Einfach winken und sturr lächeln...

 

[Chräshe]

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.

Wenn Teammitglieder die Vorgaben oft unterschiedlich interpretieren, dann bieten die Vorgaben vermutlich auch zu viel Interpretationsspielraum.
Ergänzend gibt es auch immer wieder Vorgaben, die im exakten Wortlaut überhaupt nicht widerspruchsfrei sind.

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

Ein Problem, das mangels Erfahrung, Intuition und Weitsicht nicht erkannt wird, kann nicht umschifft werden.
In Folge sehe ich oft, dass bei erkannten Problemen nur die Symptome, nicht jedoch die Ursachen bekämpft werden.

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.

Das wird dir hier bestimmt jemand anders in einem Dreizeiler kurz erläutern… ;-)

- Es sind vorrangig Serienmaschine aber mit vielen Optionen und Variationen.

Das ist ein Punkt, der oft unterschätz wird. Wenn man Pech hat, entstehen Abhängigkeiten und das ganze läuft aus dem Ruder.

 

[Tmbiz]

Hallo zusammen,

vielen Dank für die Beiträge. Da war schon mal sehr hilfreich. Generell kann man sagen, dass sich viele der benannten Punkte auch mit meiner Einschätzung decken.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interpretationsspielraum lässt sich minimieren wenn übergreifend das gleiche Wording/Wortschatz zum Einsatz kommt.. dann ist der Bezug immer gleich.

Habt ihr aktuell viele Abstimmungstermine? Wir bei uns machen in der Gruppe alle zwei Wochen für 30min ein gemeinsames joure fix.. wir waren auch mal bei 1std jede Woche.. so lässt sich einfacher steuern/regulieren wer gerade wo Unterstützung bräuchte

Vllt macht es auch Sinn, die Kollegen in Arbeitsbereiche/Units einzuteilen.. immer gemischt was die Erfahrungsniveaus angeht.. jeder kann von jedem lernen.. Synergien untereinander finden, bzw Zusammenarbeiten die jetzt schon gut harmonieren auch fördern.. vllt auch mal Präferenzen abklopfen.. wer was am liebsten macht..

Auf einem gut sichtbar abgesteckten Spielplatz lässt es sich leichter orientieren als auf dem großen weiten Feld..

 

[TheC]

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.

Der tP sollte sich eigentlich aus allen fachlichen Sachen raushalten. Wie schon weiter oben geschrieben sollte der tP dafür da sein Probleme frühzeitig zu erkennen und aktiv gegenzusteuern. z.B. wenn die Deadline nicht erreicht werden kann, muss er gegensteuern in dem er dem Mitarbeiter hilft sein Zielt zu erreichen oder ein Kollege hier unter die Arme greift. Anschließend sollten die Gründe für das nicht erreichen reflektiert und für die Zukunft behoben werden.
Die Organisation kann man nicht einfach beschreiben. Es kommt auf dein Team und die verschiedenen Charakter darin an. Du musst dich als Leitung dementsprechend den unterschiedlichen Typen anpassen. Und du musst auch wissen wer mit wem kann und wer nicht

Die Standardisierung ist per se nichts schlimmes. Aber auch hier kommt es auf das Wie an. Es sollte alles einen Standard haben wenn es standardisiert werden kann, eine Namenskonvention eignet sich gut als Standard. Auch wenn öfters benötigte Funktionen in einen oder mehrere FB's zu packen. Kommt natürlich auch darauf an wer nachher Support leisten muss für die Anlage?
Für Neukunden ein Frage Katalog in dem relativ früh entschieden werden kann was will er Kunde? (Und jemand er das nachher auf den Programmieren übersetzt)

 

[Maagic7]

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.

Software von Grund auf neu gestalten: Man braucht eine verlässliche Bibliothek mit "minimierten" Funktionen. Die "Kunst" dabei ist, die Funktionen so zu zerteilen, dass sie "fast" allgemein anwendbar sind und keine Spezialfunktionen für eine Maschine. Auch ellenlange FC's/FB's mit riesigen Schnittstellen sind Kontroproduktiv.

Eine ganz wichtige Sache was immer mehr vergessen wird, ist eine einfache Diagnose an der Maschine. Sprich die Statusanzeige, so dass sie schnell verständlich ist. SCL ist zwar eine gute Sache, bei Logikverknüpfungen aber eine Katstrophe für den Service.

Auch wenn viele dagegen sind, aus welchen Gründen auch immer, KOP ist und bleibt die beste Form für gute Diagnose. Netzwerke, die nicht auf einen normalen Bildschirm eines Laptop passen sind untauglich.

D.h. wenn man Standards einführt, dann solche grundlegenden und wichtigen Dinge definieren. Das hat dann noch nichts mit der Umsetzung zu tun. Dazu gehören z.B. Namenskonvetionen: z.B. Motor Palettenlager; Ventil Palettenlager ist meist nicht die beste Variante. Wird aber intuitiv meist so gemacht:
Palettenlager: Motor
Palettenlager: Ventil

ist meist besser, da man so besser nach Funktionsbaugruppen sortieren kann.

Das ist alles viel wichtiger als fertige Programmteile als Standard vorgeben! Standardfunktionen müssen wachsen und immer wieder angepasst werden.

Bei Standardfunktionen ist eines der wichtigsten Dinge: allgemeine TriState-Funktion einführen, Ventilbaustein/e, Schalterbausteine (Hand/Auto/Servie oder Hand/Auto/VorOrt. Einen MultiSwitch: dieser kann über Softwareschalter (INT) oder über digitale Schalter EIN/AUS geschaltet werden und hat einen Impulsschaltereingang. Multiplexerfunktionen haben sich bei mir über die Zeit als extenziell wichtig herausgestellt. Am effektigsten sind 4-fach Multiplexer (z.B. für Werteumschaltung wie verschiedene Geschwindikeiten). Der Atkive Kanal wird als Meldung aus dem Bausteine ausgegeben. Damit kann man dann leicht Visu-Anzeigen mit Sollwerpfaden relaisieren.

HMI Anzeigen standardisieren:
für mich hat sich als extrem effektiv herausgestellt, fertige LED-Anzeigen zu haben, die man von der SPS aus mit Farbe ansteuert.
Die 8-fach LED's mit den einstellbaren Farben grau, gelb, rot, grün sind bei mir am effektivsten.
Farbanzeigen für Ventile und Motore fest vordefinieren und standard Ansteuerbausteine dazu erstellen.

Eine gute aber durchaus schwierige Sache ist: Übersetzungen standardisieren. Das geht mit TIA aber so nicht automatisch.
Das bekommt man nur hin, wenn bereits der Projektierer eine leicht einsehbare List hat, welche Texte bereits in welche Sprachen übersetzt sind.

Statt dann Motor Transportband zu verwenden ist es evtl. besser den schon übersetzten Text "Atrieb Transportband" zu verwenden.
Wenn man da eine gute Bibliothek hat, dann spart das imense Arbeit und Kosten.
Hier gleich einen verantwortlichen für die Textbibliothek festlegen.

Wie kommt man auf sowas?
Ich hab das in der Praxis genau so über lange Jahre entwickelt. Der Impact, wenn das mal steht ist imens. Dauert aber viele Jahre.

Wichtig: 1 Person muss die Hoheit über die Library haben. Nur diese darf da Änderungen reinstellen - sonst bricht Chaos aus. Alle anderen, bringen Vorschläge bzw. Änderungen ein. (Das kann man dann auch z.B. über Github realisieren. Wichtig ab und zu mal ein Treffen/Workshop.

Ein Überblick welche Funktionen effektiv gebraucht werden kann man in meiner Library nachsehen. Das ist alles aus dem Bedarf raus entwickelt und optimiert. Ist aber alles noch für S7-Classic. Eine TIA Version gibt es davon noch nicht ofiziell.

An einer betriebseigenen auf eure Anforderungen spezalisierte Library wird wohl kein Weg vorbei gehen.
Damit würde ich Anfangen: da kann man sich mit Bausteinen von externen Libraries bedienen (Oscat, Maagic7) und das Beste aus der alten Software zusammensuchen.

Dann muss man das aktiv und effektiv pflegen. Wenn man Kapazität hat, einen abstellen, der Testcode schreibt, einen anderen, für Templates (z.B. Transportband ...). Dieses Template kopiert man dann für sein "Transportband_Einlauf" und ändert mit suchen/ersetzen die E/A's und individuellen Signale. Ich achte darauf, dass bei den Templates ein Eingang oder Ausgang immer nur 1x verwendet wird.
(Die E/A kann man auch als Übergabe and den FB verwenden. Für den Service/Status ist es erfahrungsgemäß einfacher, wenn diese Signale direkt im Baustein stehen - für die Programmierung ist das aber mehr Aufwand)

Softwarearchitektur:

FB, FC konventionen: Grundsätzlich einer Funktionseinheit wie Transportband, Pumpe ... immer einen FB zuweisen. FC sind nachteilig, da keine lokalen statischen variablen. Das erschwert das kopieren der Funktion. FC's nur für Standardfunktionen bzw. Hilfsfunktionen.

Wenn es sich um Produktionslinien handelt, seine Namen so vergeben, dass im TIA-Portal der Anfang der Linie nach oben sortiert wird und dann die FB's so hintereinader kommen wie die Maschine aufgebaut ist. Das erleichtert ungemein das Zurechtfinden in fremden Code! Instanz-DB unbedingt identisch benennen wie der zugehörige FB.

Das sind alles so Konvetionen, die man festlegen kann, ohne Inovationen zu behindern!

 

[Tmbiz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der tP sollte sich eigentlich aus allen fachlichen Sachen raushalten.

Das sehe ich auch so. Es gibt z.B. einige Leute, die meinen, der tP muss alles wissen und den Quellcode im Detail verstehen. Aber ich behaupte, dass das eine unrealistische Forderung ist. Sicher, bei "kleinen" Projekten ist das möglich, aber je grösser es wird, desto unwahrscheinlicher wird es. Ich sehe es eher so, dass der tP die Grenzen absteckt, in denen die "Spieler" dann tätig werden. Der tP muss sich dann um alles kümmern, was vom Soll abwicht und es wieder in handhabbare Bahnen lenken.

Software von Grund auf neu gestalten: Man braucht eine verlässliche Bibliothek mit "minimierten" Funktionen. Die "Kunst" dabei ist, die Funktionen so zu zerteilen, dass sie "fast" allgemein anwendbar sind und keine Spezialfunktionen für eine Maschine. Auch ellenlange FC's/FB's mit riesigen Schnittstellen sind Kontroproduktiv.

Eine ganz wichtige Sache was immer mehr vergessen wird, ist eine einfache Diagnose an der Maschine. Sprich die Statusanzeige, so dass sie schnell verständlich ist. SCL ist zwar eine gute Sache, bei Logikverknüpfungen aber eine Katstrophe für den Service.

Auch wenn viele dagegen sind, aus welchen Gründen auch immer, KOP ist und bleibt die beste Form für gute Diagnose. Netzwerke, die nicht auf einen normalen Bildschirm eines Laptop passen sind untauglich.

Ja, so ist es. Aber das Thema hatten wir ja schon mal bei der Handbedienung. Möglicherweise kannst du dich erinnern.

Wichtig: 1 Person muss die Hoheit über die Library haben. Nur diese darf da Änderungen reinstellen - sonst bricht Chaos aus. Alle anderen, bringen Vorschläge bzw. Änderungen ein. (Das kann man dann auch z.B. über Github realisieren. Wichtig ab und zu mal ein Treffen/Workshop.

Ein Überblick welche Funktionen effektiv gebraucht werden kann man in meiner Library nachsehen. Das ist alles aus dem Bedarf raus entwickelt und optimiert. Ist aber alles noch für S7-Classic. Eine TIA Version gibt es davon noch nicht ofiziell.

An einer betriebseigenen auf eure Anforderungen spezalisierte Library wird wohl kein Weg vorbei gehen.
Damit würde ich Anfangen: da kann man sich mit Bausteinen von externen Libraries bedienen (Oscat, Maagic7) und das Beste aus der alten Software zusammensuchen.

Dann muss man das aktiv und effektiv pflegen. Wenn man Kapazität hat, einen abstellen, der Testcode schreibt, einen anderen, für Templates (z.B. Transportband ...). Dieses Template kopiert man dann für sein "Transportband_Einlauf" und ändert mit suchen/ersetzen die E/A's und individuellen Signale. Ich achte darauf, dass bei den Templates ein Eingang oder Ausgang immer nur 1x verwendet wird.
(Die E/A kann man auch als Übergabe and den FB verwenden. Für den Service/Status ist es erfahrungsgemäß einfacher, wenn diese Signale direkt im Baustein stehen - für die Programmierung ist das aber mehr Aufwand)

Ja, das sehe ich auch so. Da wir mit Git über VCI arbeiten, ist das schon so.

 

[DCDCDC]

Das sehe ich auch so. Es gibt z.B. einige Leute, die meinen, der tP muss alles wissen und den Quellcode im Detail verstehen. Aber ich behaupte, dass das eine unrealistische Forderung ist. Sicher, bei "kleinen" Projekten ist das möglich, aber je grösser es wird, desto unwahrscheinlicher wird es. Ich sehe es eher so, dass der tP die Grenzen absteckt, in denen die "Spieler" dann tätig werden. Der tP muss sich dann um alles kümmern, was vom Soll abwicht und es wieder in handhabbare Bahnen lenken.

Natürlich sollte diese Person schon mit der Materie in irgendeiner Form vertraut sein.. ob sie den Quellcode auswendig wissen muss.. ist bisschen zu hoch gegriffen.. aber zumindest die Brücke schlagen können/wollen mit dem "was die Kollegen/Mitarbeiter" reden oder benötigen.

Die Projektleitung sollte eher dafür sorgen dass die Meilensteine erreicht werden und dementsprechend das ganze etwas steuern und eben den Kollegen im Team ein bisschen den Rücken frei halten damit die mal in Ruhe ein wenig arbeiten können, falls notwendig..

Micromanagement muss aber auch nicht sein. Das kann alles schnell darin ausufern. Solange an gesteckten Zeitschienen für die Punkte nichts davon läuft, muss vielleicht auch mal gar nicht nachjustiert/gesteuert werden.. solange die Kollegen früh genug die Hand heben wenn irgendwo "ein Stein im Weg liegt" kann man auch frühzeitig Anpassungen treffen.