Sinnvolle Aufgaben für Einstellungstests (Softwareentwicklung)

[Velicity]

Moin,

wollte mal fragen welche Aufgaben ihr bei Einstellungstests so kennengelernt habt, wie das bei euch im Betrieb gehandhabt wird und was ihr persönlich für sinnvoll haltet für den Bereich Softwareentwicklung.

Bei uns gab es sowas früher gar nicht, mit der Folge, dass man natürlich auch Leute an Bord holt, die zwar gut reden konnten, wo es da dann aber auch aufgehört hat und man die Zeit von beiden Seiten verschwendet hat. Mittlerweile machen wir da zwar ein wenig was aber ich denke immer noch zu lasch. Eher generische Aufgaben mit ein paar Loops und etwas String- und Array-Manipulation.

International und bei großen Konzernen haben sich ja scheinbar so Sachen in der Form von Leetcode Aufgaben etabliert. Häufig irgendwelche Algorithmen mit Graphen, Rekursion usw. Auf der einen Seite denke ich, dass es ein wenig Wahnsinn ist, dass sich Bewerber da auf etwas vorbereiten müssen und in was einarbeiten müssen, dass ggf. kaum Anwendung findet im Job später. Sowas muss man ggf. auch mal machen und verstehen aber 90% der Arbeit ist bei uns eher Branchenabläufe im Code abbilden und da sind selten komplizierte Algorithmen notwendig.

Auf der anderen Seite sind das wohl Sachen, die so viel logisches Denken erfordern, dass man dann davon ausgehen kann, dass es bei simpleren Sachen keinerlei Probleme gibt. Realistische Aufgaben sind denke ich schwer, da sie Branchenwissen erfordern. Klar könnte man die irgendwie anonymisieren und auf was anderes ummünzen, wobei das von der Qualität und Sinnhaftigkeit ggf. ähnlich gut ist wie automatisch übersetzte Bedienungsanleitungen von Elektrogeräten oder dem Bewerber ggf. tatsächlich mit etwas Branchenspezifisches konfrontieren und ihn Fragen stellen lassen bzw. die Abläufe erklären.

Was haltet ihr da für am sinnvollsten um abzuklopfen, dass der Bewerber genug logisches Verständnis mitbringt und dass es am Ende nicht an das Programmierung scheitert? Was für Aufgaben? Welcher Umfang? Lieber branchenspezifisch oder generisch?

[allesweg]

Die Aufgaben sollten passen:

• zum Unternehmen
• zur Vorgeschichte des Bewerbers
• zu den vorgesehenen Aufgaben
• kapazitätsmäßig

Welche Aussagekraft hat eine rein theoretische Aufgabe zu Sortieralgorithmen, wenn die Aufgabe in Zukunft Softwarewartung ist?

Weshalb sollte ich bei einem langjährigen Softwareentwickler mit arbeitszeugnis-belegter Architekturerfahrung logisches Denken abfragen?

Weshalb sollte ich als Bewerber eine Woche Urlaub in eine 0815-Entwicklerstelle investieren?

 

Ach: und die Aufgabenstellung sollte fehlerfrei und möglichst eindeutig sein.

[KeeperOfCoffee]

Ich finde es etwas ... seltsam logisches Verständnis abzufragen. Wenn jemand mehrere Jahre Entwicklung macht, sollte man von logischem Verständnis ausgehen...anonsten hat man den Job nicht lange. Es macht in DE weniger Sinn LeetCode abzufragen, da die meisten Bewerber hier diese Katas nicht lernen bzw. üben. Das wäre für den dt. Markt unüblich. Viele Unternehmen finden zu wenig Leute bzw. haben zu großen Bedarf, als dass sie 80% der Leute aussortieren weil diese nicht auf LeetCode Aufgaben vorbereitet sind.

Es ergibt mehr Sinn auf die eigesetzten Technologien einzugehen. Wenn in den CV steht, dass man an einem Projekt mit Framework XY gearbeitet hat, dann sollte man eine typische Frage stellen, die jemand beantworten kann, wenn Erfahrung mit XY da ist. Man sollte so überprüfen, ob man im CV dick aufgetragen hat, oder ob es den Tatsachen entspricht. Wenn drin steht, dass man mit Azure gearbeitet hat, dann sollte man nicht an üblichen Fragen zu Azure scheitern usw. Es geht dabei weniger um logisches Denken, als um fachliche Kompetenz mit Technologie X. Hierbei muss man nicht die Doku 1:1 widergeben, sondern durch freies Sprechen Wissen verständlich vermitteln können.

Es können auch Fragen drankommen wie z.B. welche Vorteile hat Design Pattern X gegenüber Design Pattern Y wenn Technologie Z im Projekttyp A eingesetzt wird. Das betrifft nur begrenzt logisches Denken... man muss wissen was Technologie Z ist, was die Design Patterns grob machen...und dann entweder Wissen oder durch Logik herausfinden, welches Pattern vermutlich für Aufgabe A besser geeignet ist. Kann auch eine Fangfrage sein, weil Y üblicherweise bei A eingesetzt wird...mit Ausnahmen etc.

Kurz: Man spricht Fragen an, die sich auf die Projekte aus der Vergangenheit beziehen...und die jeder Entwickler, der an solchen Projekten gearbeitet hat, normalerweise beantworten kann.

Dies sollte nicht per schriftlichen Test geprüft werden, sondern einfach in einem netten Gespräch zwischen Bewerber und einem Vorgesetzten für das entsprechende Team (bzw. kann man langjährige Entwickler hinzuziehen).

Edit: Ausnahmen hier sind evtl. Embedded Programming, Kryptographie etc. ... dass sind aber Spezailfälle

 

Bearbeitet 12. April 2022 von KeeperOfCoffee

[Whiz-zarD]

vor 46 Minuten schrieb KeeperOfCoffee:

Es macht in DE weniger Sinn LeetCode abzufragen, da die meisten Bewerber hier diese Katas nicht lernen bzw. üben. Das wäre für den dt. Markt unüblich. Viele Unternehmen finden zu wenig Leute bzw. haben zu großen Bedarf, als dass sie 80% der Leute aussortieren weil diese nicht auf LeetCode Aufgaben vorbereitet sind.

Zumal ich auch oft LeetCode in einer produktiven Software nicht sehen möchte, denn bei LeetCode geht es oft darum, den kürzesten Code zu schreiben und nicht leicht verständlich und wartbaren Code. Auch sieht der reelle Alltag eines Entwicklers doch anders aus. Ja, es sind gute Übungen, die man so mal nebenbei machen kann aber ich würde denen jetzt kein so hohen Stellenwert geben. Ich hab auch so ein Kollege, der die tollsten Hacks und Tricks drauf hat und recht exotische Patterns kennt aber was bringt nachher so ein Code, wenn ihn keiner versteht?

Daher bin ich auch der Meinung von @KeeperOfCoffee. Stellt den Bewerbern ein paar Fragen zu den Frameworks, die sie in ihrem CV angegeben haben.

Bearbeitet 12. April 2022 von Whiz-zarD

[Velicity]

vor 31 Minuten schrieb KeeperOfCoffee:

Ich finde es etwas ... seltsam logisches Verständnis abzufragen. Wenn jemand mehrere Jahre Entwicklung macht, sollte man von logischem Verständnis ausgehen

Realität ist eben, dass es hier hin und wieder genau am logischen Verständnis mangelt. Sowohl die jeweiligen Probleme in Code zu bringen oder Code von anderen zu verstehen, einen Bug zu finden oder ein Problem auch nur einzugrenzen oder ein Aufgabe anhand einer Doku/API vernünftig umzusetzen. Oder sich an Beispielen orientieren, welche die Leute kriegen.

Es gibt ja durchaus genug Arbeitsplätze, wo man quasi nur mit einem sehr starr geführten Framework hier und da ein wenig Code in ein paar Controller Methoden schreibt, ein wenig Ein- und Ausgabe und das wars, auch dafür brauch es Personal, ist aber eben nicht was wir suchen.

Das können aber natürlich auch Leute sein, die seit Jahren programmieren und das was sie da gemacht haben wundervoll gemacht haben, was so auch im Arbeitszeugnis steht. Das heißt aber nicht, dass die Person sich z.B. schnell in neue Sachen einarbeiten kann, was bei uns durchaus wichtig ist. Kundenspezifische Projekte, verschiedenste externe Systeme die angebunden werden.

vor 32 Minuten schrieb KeeperOfCoffee:

Es ergibt mehr Sinn auf die eigesetzten Technologien einzugehen. Wenn in den CV steht, dass man an einem Projekt mit Framework XY gearbeitet hat, dann sollte man eine typische Frage stellen, die jemand beantworten kann.

Frameworks werden bei uns nur in wenigen Bereichen überhaupt genutzt. Mal ab von .NET in der Dialogentwicklung. Die Technologien sind für viele durchaus mal neu, sprich da machen genaue Abfragen nicht immer Sinn. Wir haben quasi einen Desktop und einen Webbereich und ergänzend dazu kommt eigentlich immer die PL/SQL Entwicklung, wo die Businesslogik abgebildet ist. Das haben viele nicht gemacht ist aber vom Sprachumfang relativ simpel. Daran scheitert es meist auch nicht. Sondern dass die Leute nach der Einarbeitung und eine Zeit lang kleinere Aufgaben und Bugfixes mit ihrer ersten etwas größeren Aufgabe komplett überfordert sind und auch nicht den Anschein machen, dass sie sich jemals in sowas rein arbeiten könnten.

[KeeperOfCoffee]

Vlt. mal daran gedacht, dass hier der Fehler nicht bei den Bewerbern / neuen Kollegen, sondern bei euch liegt?

[Brapchu]

vor 19 Minuten schrieb Velicity:

Das heißt aber nicht, dass die Person sich z.B. schnell in neue Sachen einarbeiten kann, was bei uns durchaus wichtig ist.

"Schnell in neue Sachen einarbeiten" als frischer Neuling in der Firma lässt bei mir gleich die Alarmglocken schellen.

vor 20 Minuten schrieb Velicity:

Daran scheitert es meist auch nicht. Sondern dass die Leute nach der Einarbeitung und eine Zeit lang kleinere Aufgaben und Bugfixes mit ihrer ersten etwas größeren Aufgabe komplett überfordert sind und auch nicht den Anschein machen, dass sie sich jemals in sowas rein arbeiten könnten.

Wenn das häufiger passiert liegt das Problem vielleicht eher bei euch..?

[0x00]

Kann mich den anderen da nur anschließen. Wenn die Neuen mit kleineren Aufgaben und Bugfixes klar kommen, aber nicht mit der ersten(!) größeren Aufgabe war entweder die Einarbeitung nicht gut genug, der Sprung von klein zu größer viel zu groß oder eure Anforderungen sind einfach viel zu hoch.

Klingt für mich so als müsstet ihr nicht euren Bewerbungsprozess sondern eure Einarbeitung überarbeiten. Und sorry, bei dem was ihr bietet könnt ihr auch nicht die besten Kandidaten erwarten.

[KeeperOfCoffee]

Ich sags mal so: Wir wissen hier im Forum ja ganz gut, wie die Situation bei deinem Unternehmen ist.

Laut deiner Aussage ist also die angestrebte Lösung, statt Prozesse zu ändern, die Einarbeitung zu verbessern, noch bessere Entwickler einzustellen.

Die Frage die sich allerdings stellt: Warum sollten diese denn bei euch arbeiten. Nichts für ungut, aber es liest sich wie eine übertriebene Stellenanzeige mit "min. 10 years of experience". Dafür bietet dein AG aber nicht die Konditionen um solche Leute wirklich zu bekommen. Du selbst hast schon öfters kritisiert, dass bei euch einiges im argen ist. Jedenfalls nicht mit dem aktuellen Markt, in dem man es sich fast aussuchen kann wo man arbeitet.

Eine einseitige Veränderung wird hier nicht helfen.

Bearbeitet 12. April 2022 von KeeperOfCoffee

[Whiz-zarD]

vor 28 Minuten schrieb Velicity:

Daran scheitert es meist auch nicht. Sondern dass die Leute nach der Einarbeitung und eine Zeit lang kleinere Aufgaben und Bugfixes mit ihrer ersten etwas größeren Aufgabe komplett überfordert sind und auch nicht den Anschein machen, dass sie sich jemals in sowas rein arbeiten könnten.

Und das bekommt man mit einem Einstellungstest wie gelöst?

Vielleicht solltet ihr euch Fragen, ob ihr evtl. nicht am "Not invented here"-Syndrom leidet. Wenn ihr schon sagt, dass bei euch kaum Frameworks zum Einsatz kommen, klingt es schon sehr danach, als hättet ihr euch eine eigene Welt aufgebaut, anstatt auf gängige Standards zu setzen. Bei PL/SQL schlackern mir dann echt die Ohren. Ich hab auch viel mit PL/SQL zu tun und ich fluche über die Sprache wie ein Rohrspatz, weil die Sprache so inkonsequent ist. Dass dann bei größeren Aufgaben, Überforderungen auftreten, ist dann auch normal.

[Velicity]

vor 19 Minuten schrieb KeeperOfCoffee:

Vlt. mal daran gedacht, dass hier der Fehler nicht bei den Bewerbern / neuen Kollegen, sondern bei euch liegt?

Nun selbstverständlich kann man an allen Ecken was besser machen. Die meisten Bewerber kriegen es aber hin, also wird das nicht unmöglich sein. Hauptproblem sehe ich dann eher die Anforderungen klar zu kommunizieren und die passenden Bewerber raus zu filtern. Und genau wegen diesen Fehler, der logischerweise an uns liegt, stelle ich diese Frage ja.

vor 14 Minuten schrieb Brapchu:

"Schnell in neue Sachen einarbeiten" als frischer Neuling in der Firma lässt bei mir gleich die Alarmglocken schellen.

Frischer Neuling ist nun auch hart gesagt, wir reden da schon davon, dass die Leute eine Einarbeitung gekriegt haben, in unseren System an vielen Stellen kleinere Aufgaben hatten. Irgendwann vor Ende der Probezeit muss man jemanden aber auch mal eine größere Aufgabe geben, wenn nicht dann, wann sonst? Und das sind meist schon leichtere Sachen oder Sachen die schon einmal ähnlich existiert haben, wo man Beispiele hat usw.

Irgendwann muss der Mitarbeiter eben mit Kundenanforderungen und Schnittstellenbeschreibungen von anderen Gewerken arbeiten. Da geht es eben um die eigene Einarbeitung in Probleme und diese abbilden können.

vor 12 Minuten schrieb 0x00:

Wenn die Neuen mit kleineren Aufgaben und Bugfixes klar kommen, aber nicht mit der ersten(!) größeren Aufgabe war entweder die Einarbeitung nicht gut genug, der Sprung von klein zu größer viel zu groß oder eure Anforderungen sind einfach viel zu hoch.

Hast du dafür konkrete Ideen? Die erste größere Aufgabe gibt es bei uns i.d.R. einige Zeit vor Ende der Probezeit, denn dann muss man auch spätestens wissen, ob man mit dem Mitarbeiter was anfangen kann. Unsere Einarbeitung ist sicher nicht perfekt, vor einigen Jahren als ich angefangen habe, gab es überhaupt keine, wir sind also diesbezüglich sicher noch am Anfang.

Nix desto trotz kommen 80% hier gut klar, die keine andere Einarbeitung kriegen als die anderen und auch vor den Einarbeitungen haben Leute ins System gefunden. Probleme sind aber wie gesagt aktuell weniger die Einarbeitung in unser System, sondern sich selbst in neue Sachen rein arbeiten können. Sachen die für jeden, der sie auf den Tisch kriegen würde neu sind, wo 90% der Arbeit nix mit unserem System zutun hat, sondern mit den Anforderungen des Kunden oder Schnittstellen eines anderen Gewerks.

vor 17 Minuten schrieb KeeperOfCoffee:

Nichts für ungut, aber es liest sich wie eine übertriebene Stellenanzeige mit "min. 10 years of experience".

Gerade was sowas angeht haben wir relativ geringe Anforderungen. Wir haben z.B. auch Quereinsteiger an Bord oder eben Leute wie mich, die nur eine schulische Ausbildung haben und gut die Hälfte ist direkt nach der Ausbildung oder dem Studium hier her.

Mal davon ab, dass die exp alleine auch nicht viel gesagt hat in der Vergangenheit. Hatten hier schon promovierte Leute, die seit Jahrzehnten in dem Bereich sind, die keinen Anschluss gefunden haben und Fachfremde Leute, die richtig fix mit der Arbeit warm geworden sind.

[allesweg]

vor 4 Minuten schrieb Velicity:

Hast du dafür konkrete Ideen?

Refactoring der bestehenden Software auf branchenübliche best practices und geläufige Frameworks?

[Velicity]

vor 19 Minuten schrieb Whiz-zarD:

Wenn ihr schon sagt, dass bei euch kaum Frameworks zum Einsatz kommen, klingt es schon sehr danach, als hättet ihr euch eine eigene Welt aufgebaut, anstatt auf gängige Standards zu setzen. Bei PL/SQL schlackern mir dann echt die Ohren. Ich hab auch viel mit PL/SQL zu tun und ich fluche über die Sprache wie ein Rohrspatz, weil die Sprache so inkonsequent ist. Dass dann bei größeren Aufgaben, Überforderungen auftreten, ist dann auch normal.

Bin ich voll und ganz bei dir. Das System war soweit ich weiß mal vor 30+ Jahren komplett in C und wurde irgendwann in PL/SQL überführt, wo die ganze Businesslogik liegt. Ebenfalls nicht schön geschrieben und noch sehr nach C-Manier, sprich Fehlercodes als Rückgabe, Flags etc. pp.

Ist auch nix, wofür ich PL/SQL als auch nur irgendwo passend sehe, ist aber nun eine Anwendung, die so mit den Jahrzehnten gewachsen ist, die Millionen von Zeilen Code hat und bei zig Kunden in Betrieb ist und aktiv erweitert und supportet wird, also nix, was man mal eben ändern könnte.

Geht letztlich um Intralogistik, sprich Lagerverwaltung, Kommissionierlösungen, Materialflussrechner usw. Wobei das in dem Bereich scheinbar gar nicht so selten genutzt wird. Hatten durchaus mit einigen anderen Gewerken zutun, die auch so gut wie alles in der Oracle DB hatten, teilweise noch weitaus absurdere Konstruktionen.

Aber wie gesagt, an PL/SQL scheitert es selten, sondern Kundenanforderungen in Code bringen, Schnittstellen von anderen verstehen und vernünftig anbinden usw.

[Velicity]

vor 6 Minuten schrieb allesweg:

Refactoring der bestehenden Software auf branchenübliche best practices und geläufige Frameworks?

Leider komplett unmöglich. Mal vom Aufwand, der in mehrere Jahre gehen würde, müssen natürlich auch die ganzen aktiven Kunden noch betreut werden. Nicht dass ich kein Bock hätte auf was anderes als PL/SQL im Core. An den Rändern des Systems gibt es durchaus mal entsprechende Umstellungen, wie die Webentwicklungen, die darauf aufsetzen oder im .NET Bereich. Aber das Hauptsystem wird man schwerlich ersetzen können.

[allesweg]

Wenn Wartung aufgrund Personalmangel nicht mehr möglich ist und Refactoring auch nicht in Frage kommt, bleibt nicht viel übrig.

[0x00]

Sorry, dann hatte ich das missverstanden. Das klang eher so als würde die Aufgabe keiner schaffen, dann ist das ganze ja halb so wild. 

Ich würde in der Probezeit den Fokus des Neuen relativ zentriert halten. Eben nicht an vielen Stellen kleinere Aufgaben machen, sondern das ganz auf wenige, im Optimalfall eine Stelle beschränken. Erst kleinere Aufgaben, dann größere Aufgaben im Pair Programming oder enger Zusammenarbeit. Wenn ihr dann noch vor Ende der Probezeit so einen "Test" machen wollt sollte sich der Neue damit deutlich einfacher tun, weil er sowohl eure Herangehensweise als auch die entsprechenden Codestellen schon (grob) kennt.

Zum Thema Vorstellungsgespräch: Ich greife jetzt mal das auf was @allesweg sagte: Aufgaben müssen auf die späteren Aufgaben zugeschnitten sein. Wenn ihr also jemanden wollt, der sich relativ schnell in neue Themen einarbeiten kann, dann solltet ihr genau das testen. Hierzu würde ich eine relativ abstrakte Aufgabe stellen und schauen wie der Bewerber an die Sache herangeht. 

[Velicity]

vor 12 Minuten schrieb allesweg:

Wenn Wartung aufgrund Personalmangel nicht mehr möglich ist und Refactoring auch nicht in Frage kommt, bleibt nicht viel übrig.

Wie gesagt, so schlimm ist es nicht. Mal geht einer, dann sucht man wen Neuen. Wir haben keinen großen Personalmangel. Ist eben nur für beide Seiten ärgerlich, wenn man Monate verschwendet und es nicht klappt. Und unser System, so hässlich es ist, ist immer noch nicht das Hauptproblem beim Einstellen neuer Leute.

Wenn wir statt PL/SQL nun Java, C# oder was weiß ich was nutzen würden, dann muss der Mitarbeiter trotzdem in der Lage sein sich in eine Kundenanforderung reinzudenken und die in Code umzusetzen oder eine externe Schnittstelle anzubinden usw. Das ändern Änderungen an unseren System gefühlt gar nix.

Frage mich aber auch, wie so ein Refactoring aussehen würde bei sowas. Am Ende hängen eben zig Kunden dran, die kundenspezifische Lösungen haben, die Support brauchen, wo andere Schnittstellen auch an uns dran hängen, die Erweiterungen kriegen usw. Bastelt man denen je ein neues System für Lau und steckt da jeweils ein Jahr aufwärts rein? Oder stellt man den Support und Erweiterungen komplett ein für Altkunden und lässt die je Millionen auf den Tisch legen für ein Retrofit, wenn sie eine kleinere Erweiterung wollen für ihr System, was ansonsten läuft? Wo sie keinen Mehrwert drin sehen, damit man eine schönere Codebase hat?

Aber am Ende eh am Thema vorbei, weil das nicht das Problem ist, dass die Bewerber haben. Nicht dass das nicht frustrieren würde.

[Velicity]

vor 2 Minuten schrieb 0x00:

Erst kleinere Aufgaben, dann größere Aufgaben im Pair Programming oder enger Zusammenarbeit. Wenn ihr dann noch vor Ende der Probezeit so einen "Test" machen wollt sollte sich der Neue damit deutlich einfacher tun, weil er sowohl eure Herangehensweise als auch die entsprechenden Codestellen schon (grob) kennt.

Pair Programming fände ich tatsächlich mal eine gute Idee für viele Stellen bei uns gerade für die Einarbeitung in unser System. Sowas gibt es per se bei uns nicht bzw. entsteht eher natürlich, dass jemand fragt, ob man mal mit draufguckt usw. Aber nicht wirklich als Prozess.

Problem ist aber wie gesagt häufig das selbstständige Einarbeiten in andere, neue Sachen, also eher Kundenanforderungen und Schnittstellen anderer Gewerke. Und da gibt es nicht viel, was man an Einarbeit leisten kann. Klar kann ich jemand neben mich setzen, sowas umsetzen und ihn erzählen wie ich da ran gehe. Das hat an der Stelle aber wenig mit unseren System zutun, sondern dem Verständnis von der Anforderung oder externen Schnittstelle.

Die Codestellen kann man dann natürlich nicht kennen, die gibt es noch nicht.

[0x00]

Habt ihr mal überlegt einen Produktmenschen einzustellen, extra für Kundenkontakt und Anforderungsdefinition? Das ist aus guten Gründen in vielen Firmen getrennt, weil sich die hier benötigten Skillsets nicht zwangsläufig mit denen eines Entwicklers überschneiden müssen. Viele Entwickler, die ich kenne haben eher die technischen Anforderungen im Sinn - etwas das dem Kunden meist völlig egal ist.

Wenn die Anforderungen oder externen Schnittstellen definiert sind dürften sich viele deutlich einfacher tun. Klar gibt es Entwickler, die auch das alles selber machen können, aber diese Schnittmenge ist halt ungleich kleiner.

Natürlich rede ich jetzt nicht von technischen Schnittstellen oder vorgegebenen APIs, sowas sollten die schon können. Aber wenn es um Kundenanforderungen geht macht es durchaus Sinn, wenn man jemand hat, der das ganze mal für die Entwickler "vorkaut". Da dann jeder seine Spezialgebiete hat dürfte sich auch der ganze Ablauf merkbar beschleunigen.

[allesweg]

Ihr habt regelmäßige Personalfluktuation spätestens kurz nach der Probezeit und du suchst nach Verbesserungen bei der Bewerberauswahl, um weniger Zeit zu verschwenden, aber es ist nicht schlimm?

Wieso willst du dann die Personalauswahl verbessern?

[Velicity]

vor 1 Minute schrieb 0x00:

Habt ihr mal überlegt einen Produktmenschen einzustellen, extra für Kundenkontakt und Anforderungsdefinition? Das ist aus guten Gründen in vielen Firmen getrennt, weil sich die hier benötigten Skillsets nicht zwangsläufig mit denen eines Entwicklers überschneiden müssen.

Ich glaube bei sowas scheitert es bei uns ein wenig an der Firmengröße. Wir reden hier von 10-15 MA an dem Standort. Da haste eher Generalisten. Das ist nix was von Anfang an gefordert ist, sondern schleift sich eher so ein mit den Aufgaben.

Und es geht schon um technische Umsetzung. Problem ist da nicht, dass Kunde und Entwickler aneinander vorbeireden, sondern generell wie löse ich das, wie bilde ich das ab. Gleiche bei den externen Schnittstellen, da geht es um Bits und Bytes.

Mal ein Beispiel vom letzten Mitarbeiter, wo das nix wurde. Der Kollege hat vorher tatsächlich schon mit PL/SQL gearbeitet. Zwar nicht in unserem Bereich (Lagerverwaltung/Materialfluss), sondern im ERP/Host Bereich. War auch schon einige Jahre Entwickler.

In unseren System wurde er eingearbeitet, hat immer wieder kleinere Aufgaben gekriegt, natürlich nach und nach etwas größer werdend. Das erste halbwegs große dann war die Umsetzung eines Simulators für eine Fördertechnik.

Schnittstelle ist extern vom Fördertechnikanbieter. Der eigentliche Prozess auf unserer Seite war quasi schon fertig und hat auch schon mit der Echtfördertechnik gearbeitet. Seine Aufgabe war nun einen Simulator zu schreiben, der quasi unsere Datenübertragung simuliert und das Verhalten der Fördertechnik.

Dafür hatte er die entsprechende Schnittstellenbeschreibung, konnte den Prozess der Gegenstelle (also unsere Seite) sehen und hatte quasi Millionen von Datensätzen wie der Verlauf der Daten in echt aussieht. Als auch einen ähnlichen Simulator, den es vor Jahren mal gab für ein ähnliches Szenario.

Echtablauf war quasi Fördertechnik meldet wo eine Palette/Kiste, wir haben einen Netzwerkprozess der pollt und den Baustein der SPS ausliest, die Sachen bei uns in eine Tabelle schreibt als Hexstring als gelesenen Zustand, dort steht also drin, wie es in der SPS echt aussieht. Der Fördertechnikprozess auf unserer Seite liest diesen Satz, konvertiert ihn in entsprechende Strukturen, führt damit ein paar Sachen in unseren System aus (Pathfinding, Buchungen, Validierungen etc. pp.) und schickt auf der anderen Seite generiert aus unseren Transportaufträgen Ziele in einen entsprechenden ausgehenden Satz, der dann wieder vom Netzwerkprozess an die SPS geschickt wird, der dient nur zur Übertragung und hat nur die Sachen, die geändert werden.

Aufgabe also ohne den echten Netzwerkprozess die ausgehenden Daten einlesen (sind auch gespiegelt in den Gelesenen). Die Daten von unserer schreibenden Seite in die Lesende schreiben. Beachten, dass es da Möglichkeiten gab was zu escapen bzw. nicht zu senden, sprich eine Schnittmenge aus beiden Sätzen bilden. Und quasi in einer weiteren Prozessstufe dann schlicht die Palette auf das dort eingetragene Ziel zu buchen mit einen Aufruf einer Funktion in unserem System. Leicht vereinfacht und sicher gibt es da noch Details aber das wars in groben.

Der Kollege konnte auch nach hundert mal erklären nicht verstehen, dass die gelesenen Sätze der Zustand in der SPS ist und die schreibenden Sätze nur Sätze sind, die dazu da sind, den Zustand in der SPS zu ändern und hat das dauernd durcheinander gebracht mit Telegrammschnittstellen, unsere Sätze und deren Sätze etc. pp. Und hat nicht verstanden, dass er erstmal die Datenübertragung von einen in den anderen Satz machen soll, sprich den Teil, den sonst der Netzwerkprozess macht.

Der hat da viele Wochen dran rumgedoktert, man hat ihn wirklich immer wieder die gleichen Sachen erklärt, die Probleme, die es macht wie er es gerade probiert. Ich weiß echt nicht, was man noch machen hätte können, als ihn die Tastatur wegnehmen und das selbst tippen. Er konnte einfach die logischen Abläufe, die physisch passieren nicht in entsprechenden Code nachstellen bzw. verstehen wie das in welcher Richtung passiert.

Nächste Aufgabe war dann wieder was mit einer externen Schnittstelle. Anbindung an eine Pick-By-Light Anlage, auch da ähnliche Probleme, wie man das nun aufbaut, in welcher Reihenfolge er die Sachen abarbeiten muss usw. Das waren einfach reine Logiksachen, die nix mit unseren System zutun hatten, sondern psychische Abläufe in richtiger Reihenfolge mit seiner Anwendung abzubilden.

[Velicity]

vor 16 Minuten schrieb allesweg:

Wieso willst du dann die Personalauswahl verbessern?

Weil es komplette Zeitverschwendung für beide Seiten ist. Wir haben knapp über 10 Leute hier. Da drunter viele, die schon Jahrzehnte hier sind, einige die ein paar Jahre da sind. Mal geht wer in Rente, mal wechselt auch wer nach ein paar Jahren. Dann brauch man eben eine neue Person. Ist eben nicht so als laufen uns die Leute hier alle paar Monate weg.

Nix desto trotz haben wir eben dann doch mal Leute, wo das gar nicht passt. Und da das zuletzt zweimal hintereinander aufgetreten ist, stelle ich mir eben die Frage ob man frühzeitiger abklären könnte, ob das passen könnte. Einfach weil ich weiß, dass sowas aktuell im Bewerbungsgespräch relativ milde abgeklopft wird und das wohl nicht mit den Anforderungen übereinstimmt.

[allesweg]

10-15 Entwickler sind zu wenig für EINEN lumpigen Anforderungsmanager? Janee, isklar.

[Velicity]

@allesweg Keine Ahnung, ich habe noch nie gesehen, was so ein Anforderungsmanager macht und womit man den 40 Stunden die Woche beschäftigen könnte. Bei uns steht am Anfang des Projektes die Projektleitung, die das Lastenheft durcharbeitet, dann die Pflichtenheftspräche beim Kunden führt und dieses erstellt, da draus dann Arbeitspakete für die einzelnen Abteilung macht, welche angereichert werden mit Schnittstellenbeschreibungen.

Daneben gibt es eben Kleinkram, der via JIRA, Mail oder Telefon läuft, genauso wie der Support. Dafür muss der Entwickler trotzdem die Sprache des Kunden sprechen können.

Gibt natürlich noch Sachen dazwischen, da sind dann i.d.R. die erfahrenen Leute der Fachabteilungen gefragt, die das entsprechend definieren. Den Code muss der Entwickler aber eben schon selbst noch zu Stande bringen, genauso wie technische Schnittstellen verstehen. Oder soll da einer neben stehen und diktieren?

[treffnix]

Aber ihr habt doch, ähnlich wie wir hier auch, einen großen Monolithen, der bei zig Kunden im Einsatz ist? Und wenn Fa. Müller dann über PL Meier Feature A anfordert, wird das umgesetzt, ohne zu überlegen ob das die anderen Kunden auch bekommen sollen? Oder bekommt Fa. Schulze, die von PL Schröder geleitet werden einfach das Update durchgedrückt, obwohl es für die Kontraproduktiv sein sollte?

Es muss doch eine Stelle geben, die sagt "Das kommt in den Standard", "Das kommt als Kundenerweiterung", .... oder nicht? So läuft es bei uns zumindest.