Hallo zusammen, ich bin Projektleiter im Bereich Maschinenbau und kümmere mich zusätzlich um das Thema Prozessoptimierung. Ich habe immer mehr Berührungspunkte mit IT-Themen, weil ich die funktionalen Anforderungen des Fachbereichs vertrete. Begriffe, die für jeden ITler selbstverständlich sind (z.B. GUI, Klassendiagramme, relationale Datenbank..) muss ich mir bisher aneignen, um bei den Diskussionen "mitzuhalten". Ich suche dementsprechend nach geeigneter Literatur, um entsprechende IT-Grundlagen zu lernen. Mein Ziel ist es, größere IT-Projekte leiten zu können. Was ich bisher für den groben Überblick recht gut fand: - Handbuch für Softwareentwickler vom Rheinwerk-Verlag - Modernes Projektmanagement von Timinger, Holger Folgende Bücher klingen für mich ansprechend: - IT-Projektmanagement: Was wirklich funktioniert – und was nicht. von Matthias Geirhos - Handbuch IT-Projektmanagement von Ernst Tiemeyer - Systematisches Requirements Engineering von Christof Ebert Habt ihr weitere Tipps? Gerne auch Blogs oder Youtube-Kanäle zu dem Thema. Schon mal vielen Dank!
Beitrag #5935856 wurde von einem Moderator gelöscht.
Beitrag #5935860 wurde von einem Moderator gelöscht.
Beitrag #5935863 wurde von einem Moderator gelöscht.
Die Recherche nach passender Literatur sollten studierte Leute bzw. Studenten an Universitäten eigentlich selbst leisten können. (Das wurde uns im Studium sinngemäß von den Profs so gesagt.)
Beitrag #5935877 wurde von einem Moderator gelöscht.
Peter123 schrieb: > Die Recherche nach passender Literatur sollten studierte Leute > bzw. Studenten an Universitäten eigentlich selbst leisten können. (Das wurde > uns im Studium sinngemäß von den Profs so gesagt.) Sehe ich auch so. Deswegen habe ich ja schon Recherche betrieben. Habe nun mit einem Fernstudium in Informatik begonnen, den Scrum-Master gemacht (weil ja überall nur noch von Sprints die Rede ist..) und eigne mir Sachen bisher über verschiedene Medien bei Bedarf an. Ich hatte mir erhofft, dass sich hier auch andere weiterbilden und gute Tipps haben.
Einen Tipp kann ich dir aber doch geben: Ist quasi ein Standardwerk mit vielen Auflagen: - Ian Sommerville, Software Engineering Einfach mal den Titel in der Amazon Suche eingeben
"The mythical man month" ist auch ein lesenswerter Klassiker.
@Peter123 & Walter T. Danke! Werde ich mir mal genauer anschauen.
In einem Informatikstudium ist Softwareentwicklung eigentlich nur (wenn überhaupt) ein Randthema. Das meiste ist einfach nur knallharte Mathematik. GUIs und Sprints interessieren da auch niemanden. Es geht um Algorithmen, Beweise und Mathematik. Das wird dir also für die Praxis nicht viel bringen.
@Test (Gast) Ja, dem bin ich mir bewusst. Ich bin derzeit als Akademie-Student an der Fernuni-Hagen eingeschrieben. Gerade lerne ich Software Engineering (sehr UML lastig), was ich interessant finde. Mit dem Thema Datenbanken hatte ich beruflich Berührungspunkte und werde ich das kommende Semester auch belegen. Programmierkenntnisse habe ich in Maßen, weil ich beruflich ab und zu kleinere Anwendungen schreibe (Daten abgleichen, Texte verarbeiten). Ob ich mir wirklich ein komplettes Studium antue, weiß ich noch nicht. Mathe hatte ich schon im Maschinenbau-Studium genug und braucht man als Projektleiter realistisch gesehen nicht. Mir geht es eher darum, mir das Vokabular anzueignen. Als Projektleiter im Maschinenbau sind die Tätigkeiten (meine Vermutung) ähnlich wie in der Software-Entwicklung: - Anforderungen richtig erfassen (nicht das machen, was der Kunde einem vorgibt, sondern das machen, was den Kunden am Ende wirklich zufrieden stellt) - Arbeitspakete planen und Abhängigkeiten der Pakete auf dem Schirm haben - Arbeitspakete gut vorbereiten, dass man für die Abarbeitung nicht zwingend das beste Pferd im Stell einsetzen muss - Die Änderungswünsche der Kunden aus den Besprechungen bewerten und koordiniert ins Team streuen - Schauen, wer aus dem Team dafür geeignet (und verfügbar ist). Sprich: Macht's der Senior oder kann ich darauf auch mal einen Einsteiger loslassen, weil da nichts anbrennt. - Wenn ein Arbeitspaket nicht nach Plan läuft, darauf verstärkt den Fokus legen - Zeitabschätzungen & Kompetenzen der Mitarbeiter hinterfragen (ich hab manchmal Berufseinsteiger, die bessere Leistung liefern als manch ein geduldeter "Erfahrener") - Schauen, dass kein unkontrolliertes Produkt an den Kunden geht - und das Finanzielle wie Stunden haken, Projekt ausplanen, Lenkungsausschüsse, Rechnungen stellen, Chef beruhigen, dass man alles im Griff hat etc. Mir fehlt ein bisschen der Abgleich, ob der Arbeitsalltag so viel anders ist als jetzt im Maschinenbau. Am schwierigsten stelle ich es mir derzeit vor, die Kompetenz von anderen Mitarbeitern richtig einzuschätzen, da mir die Kompetenz dafür fehlt.
Beitrag #5936171 wurde von einem Moderator gelöscht.
Ja in Zukunft noch mehr, wenn nicht schon heute, wird die IT das Zentrum sein.. Hypewort"Digitalisierung"... Klar klassisches Engineering bzw Leute die es verstehen, wird man immer noch benötigen. Aber auch da, wird vieles automatisiert werden... Von IT..
Beitrag #5936181 wurde von einem Moderator gelöscht.
@Einfach unverbesserlich (Gast) Ja, leider.. ich war bisher stets bemüht, nicht das typische Ende von Peterchen zu erleiden.. Wie Klaus schreibt, schreitet die Digitalisierung immer mehr voran, auch im Maschinenbau. Ich hab ab und zu Studenten, die für mich Sachen programmieren und Chefs, die nicht einsehen, dass diese auch von kompetenten Fachleuten betreut werden müssen. Am Ende muss ich als Laie selbst drüber schauen, warum irgendwas nicht funktioniert oder das Programm anpassen, wenn der Student wieder weg ist. Oder ich soll in Vorstellungsgesprächen beurteilen, ob der Werkstudent kompetent genug für den Job ist. Bisher agiere ich nur anhand von "gesundem Menschenverstand" wie Variablen sinnvoll benennen, Versionierungen einführen, modularer Aufbau der Programme Wiederverwendung von Modulen Testen von Extremfällen etc. Ich merke bei meinem AG, dass man aus Mangel an guten IT-Projektleitern irgendwelche Entwickler nimmt, die die Anforderungen an die Software nicht verstehen, keine sinnvollen Prioritäten setzen und teilweise unnütze Software ausrollen (die dann den üblichen Tod stirbt, weils keiner benutzt).
Beitrag #5936214 wurde von einem Moderator gelöscht.
Schau dir mal diesen edX Kurs an: https://www.edx.org/course/software-engineering-essentials Der ist als Uebersicht wirklich super und aufbauend auf diesem Wissen wuerde ich dann entsprechend nach Literatur suchen. Es werden auch Literaturempfehlungen gegeben an die man sich halten kann. Ein Buch das alles abdeckt wird schwierig zu finden sein, dazu gibt es einfach zuviele verschiedene Teilbereiche. Wenn es mehr um die Prozesse gehen soll, als um die Entwicklung, dann kann ich noch das Buch https://www.oreilly.com/library/view/the-devops-handbook/9781457191381/ empfehlen. Wenn man so wirklich bei 0 anfangen muss, dann unbedingt vorher noch diesen Roman lesen https://www.amazon.de/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 Sehr kurzweilig und macht richtig Spass. Gibt es mittlerweile auch auf deutsch.
Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil die Musik einfach in den USA spielt und deutsche Autoren den Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken abschreiben. Zudem liest sich das häufig so spannend wie Steuerparagraphen. Mythical Man Month wurde ja schon genannt. Der Termin ist ein sehr gutes Buch über Projektmanagement, als kurzweiliger Roman verpackt. Peopleware ist der Klassiker zum Umgang mit den Entwicklern. Wenn's praktischer sein soll auch Clean Architecture. Einfach, damit man weiss, dass es sowas wie Software Architektur überhaupt gibt und die Entwickler nicht alles nur schnell zusammen hacken sollen.
Dipl. Inf (FH) schrieb: > Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil > die Musik einfach in den USA spielt und deutsche Autoren den > Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken > abschreiben. Die obige Empfehlung war fuer den deutschen Roman. Es liesst sich auch auf Englisch sehr gut, jedoch finde ich es gut, dass eine deutsche Alternative gibt. Es geht auch darum wie die verschiedenen Charaktere untereinander in Beziehung stehen, da ist das schon in Ordnung. Allerdings ist die englische Originalfassung wirklich in verstaendlichem Englisch geschrieben, das koennte laessig als Schullektuere durchgehen.
@Tobias B. Der edx-Kurs klingt sehr gut! Danke! Vom Phoenix- Buch hatte ich bisher nur eine kindle Leseprobe. Dort gings um die Beförderung vom Protagonisten, weniger um technische Details. Ändert sich das im Laufe des Buchs? @Dipl. Inf Danke für die Buchtipps! Bisher lese ich sehr "pragmatische" Bücher und schau mir ab und zu Youtube-Videos dazu an, aber Romane sind zur Auflockerung auch gut. Mir ist bewusst, dass in der IT Englisch noch wichtiger ist als im Maschinenbau. Für den Scrum Master habe ich mit dem Original Scrum-Guide gelernt, weil mir der Umweg über die deutsche Übersetzung auch zu umständlich vorkam. Bin aber auch nicht abgeneigt, wenn es gute deutsche Literatur gibt. Liest sich schneller und ich bin nicht so mit der Interpretation von manchen Begriffen beschäftigt.
Dipl. Inf (FH) schrieb: > Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil > die Musik einfach in den USA spielt und deutsche Autoren den > Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken > abschreiben. Dann könnte man auch chinesische Literatur empfehlen. Dipl. Inf (FH) schrieb: > Zudem liest sich das häufig so spannend wie Steuerparagraphen. Das ist mein Hauptargument für amerikanische Literatur und Vorlesungen. Es wird so einleuchtend erläutert, dass es im Prinzip jeder direkt versteht. Zitat eines Professors: Ich habe Elektrotechnik nicht während des Studiums verstanden, nicht während meiner Promotion, nicht in meiner 10 jährigen Industrietätigkeit, sondern richtig tiefgreifend erst seit dem ich Professor bin. Ein Teilgrund dafür ist meiner Meinung nach, dass die deutschen Lehrbücher ähnlich formuliert sind wie das deutsche Steuerrecht. Samenstau im Maschinenbau schrieb im Beitrag #5935860: > Das Softwareteam streitet sich immer mit dem Elektronikteam. > Aber beide können sich darauf einigen, dass die Maschinenbauer gegenüber > die wahren Deppen sind. Kindergarten! Tobias B. schrieb: > Allerdings ist die englische Originalfassung wirklich in verstaendlichem > Englisch geschrieben, das koennte laessig als Schullektuere durchgehen. Das ist meistens so.
Also ehrlich! Ihr seid wieder einmal so über alle Maßen überheblich und teilweise beleidigend! Muß das wirklich so sein? Mit Euch würde ich, wenn Ihr Euch im Betrieb auch so benehmt, nicht arbeiten wollen. Auch Maschinenbauer sind Menschen:-) Der TO hat aus seiner Sicht bestimmt guten Grund zu seiner Frage und es ist sein Privileg und Angelegenheit. Wenn ihr was dagegen habt, dann bleibt doch einfach still. Man ist auch in einem Forum nicht zu einer Entgegnung gezwungen.
Beitrag #5936429 wurde von einem Moderator gelöscht.
@Ron Jeremy Vermutlich Mangel an Alternativen. Die ITler & Consultants bei meinem AG verstehen die komplexen Anwendungsfälle nicht. Befriedigen ihre Tickets und ignorieren User-Rückmeldungen, so lang der Chef oder Kunde die Tools "cool" findet. Die merken erst Jahre später, dass es ein Millionengrab ist, weils keiner nutzt. Dann kommen sie wieder zu mir, weil ich ihnen das von Anfang an so prognostiziert habe & andere Ideen hatte. Bin vielleicht IT-technisch ein Noob, aber zumindest das Buttons nicht nur schön aussehen müssen, weiß ich.
Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute zusammenzubringen.
Beitrag #5936561 wurde von einem Moderator gelöscht.
MeineMeinung schrieb: > @Tobias B. > Der edx-Kurs klingt sehr gut! Danke! > Vom Phoenix- Buch hatte ich bisher nur eine kindle Leseprobe. Dort gings > um die Beförderung vom Protagonisten, weniger um technische Details. > Ändert sich das im Laufe des Buchs? Ohja, da gehts drunter und drueber. Ich will jetzt nicht zu viel Spoilern, aber erst wird der Laden an die Wand gefahren und beim Aufbau von vernuenftigen Prozessen wirds dann auch technischer. In der Regel werden auf die Koryphaeen der jeweiligen Prozessbereiche eingegangen und auf deren Standardwerke. Im Anhang wird das dann noch technischer und detailierter ausgefuehrt. Ich wuerde das Buch jetzt nicht unbedingt als technischen Leitfaden nehmen, dafuer ist dann das Buch von Gene Kim, et al ("The DevOps Handbook") viel besser geeignet (hab gerade geehen dass es das mittlerweile auch auf deutsch gibt, ob das aber taugt weiss ich nicht). Der Roman eignet sich eher als Motivation und da man super mit den Charakteren mitfuehlen kann (und das DevOps Handbook auch immer wieder auf die Geschichte referenziert) hat man einen wirklich tollen Praxisbezug, auch wenn die Geschichte fiktiv ist.
:
Bearbeitet durch User
Peter123 schrieb: > Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit > ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute > zusammenzubringen. Full ACK. Leider braucht man selbst entsprechende Expertise und die Expertise anderer einzuschaetzen. Interessant dazu auch foglender Wiki Artikel: https://de.wikipedia.org/wiki/Anti-Pattern#Organisations-,_Management-_bzw._Prozess-Anti-Pattern Ich wuerde daher sogar noch eine Stufe runtergehen und behaupten, ein guter Projektleiter vertraut auf die Expertise seiner Experten.
Tobias B. schrieb: > Peter123 schrieb: >> Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit >> ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute >> zusammenzubringen. > > Full ACK. Leider braucht man selbst entsprechende Expertise und die > Expertise anderer einzuschaetzen. Interessant dazu auch foglender Wiki > Artikel: > > https://de.wikipedia.org/wiki/Anti-Pattern#Organisations-,_Management-_bzw._Prozess-Anti-Pattern > > Ich wuerde daher sogar noch eine Stufe runtergehen und behaupten, ein > guter Projektleiter vertraut auf die Expertise seiner Experten. Sehr interessanter Artikel. Vielen Dank für den Link!
@Tobias B. Das klingt gut! Kommt auf meine Liste, wenn ich mal ein wenig was Entspanntes zwischendrin lesen will. Von der Story her war die Leseprobe unterhaltsam. Wobei ich auch genug Storys von meinem AG schreiben könnte.. Hatte in letzter Zeit viel mit der Management-Ebene zu tun. Da wundere ich mich oft, wie manche Leute an so eine hohe Stelle kommen konnten. Der Link ist echt genial. Gilt nicht nur für den IT-Bereich. Mir wurde zu dem Thema ein gutes Video von Fefe empfohlen: https://www.youtube.com/watch?v=E0_Y53ci9cw @Peter Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler und unter Stress versemmeln die besten Leute was. Wenn man das als Team abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf. viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu finden, wo derjenige nicht so viel Schaden anrichtet.
Quereinsteiger schrieb: > @Tobias B. > Das klingt gut! Kommt auf meine Liste, wenn ich mal ein wenig was > Entspanntes zwischendrin lesen will. Von der Story her war die Leseprobe > unterhaltsam. Ok, dann findest du sicher zu jedem Charakter eine Person, die du im realen Leben mal kennen gelernt hast. Das macht das Buch auch autenthisch und ich wette das der Autor aehnlichs erlebt hat, es beschreibt einfach den allgemeinen Wahnsinn im Alltag, jedoch mit Happy End. :-) Quereinsteiger schrieb: > Der Link ist echt genial. Gilt nicht nur für den IT-Bereich. > Mir wurde zu dem Thema ein gutes Video von Fefe empfohlen: > Youtube-Video "34C3 - Antipatterns und Missverständnisse in der > Softwareentwicklung" Danke fuer den Link, werde ich mir mit Vergnuegen ansehen.
:
Bearbeitet durch User
Quereinsteiger schrieb: > @Peter > Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler > und unter Stress versemmeln die besten Leute was. Wenn man das als Team > abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem > geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen > Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf. > viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu > finden, wo derjenige nicht so viel Schaden anrichtet. Mag ja alles wahr sein. Aber das hängt auch von der Größe und Struktur Eurer Organisation (Firma) ab, ob der Projektleiter (der Chef) im operativen Geschäft (bei der Softwareentwicklung) noch direkt mitmischen sollte oder nicht. Weil ich die ja nicht kenne, kann ich auch dazu keine Aussagen machen. Es ist nämlich ein großer Unterschied, ob du als Projektleiter z.B. 10 Mitarbeiter/Softwareentwickler oder 100 Mitarbeiter/Softwareentwickler leitest. Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der Erstellung einer Softwarelösung mitzuarbeiten. Aber ich denke bei 100 Mitarbeitern, aufgeteilt in verschiedene Projektgruppen, wird es schon schwierig.
Hi Peter, sind je nach Projektphase 5-15 Leute.
Peter123 schrieb: > Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der > Erstellung einer Softwarelösung mitzuarbeiten. Selbst bei 10 Leuten ist der SW Projektleiter normalerweise wegen Meetings, Freigaben, Releaseplanung und Koordination so zu, dass er bestenfalls mal über die SW schauen kann, aber nicht mehr selbst programmieren. Ausnahme: Sein Team besteht aus Frischlingen, die es nicht gebacken bekommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.