Hallo,
ich habe techn. Informatik studiert und absolviere gerade mein Praktikum
in einer Firma, die Hard- und Software entwickelt.
Bisher (also während des Studiums als auch privat) fand ich sowas
absolut klasse, neue Geräte zu entwickeln.
Leider macht es mir nun überhaupt keinen Spass mehr.
Erstens ist es etwas komplett anderes, ob man in der Uni in einem
Projekt etwas entwickelt (ich habe da ein Interface mit GrafikLCD und
Drehgeber gebaut, das Geräte wie Netzteil, Funktionsgenerator etc [so
wie das ct'lab, aber eben alles selbst entwickelt] über I2C
kontrolliert).
In der Firma macht es aber überhaupt keine Freude mehr. Es wird
projektorientiert gearbeitet; ich hab mehr Projektoverhead, als ich
eigentlich hinterher produziere. Die Arbeitsweisen, wie ich sie mir in
der FH angeeignet habe, scheinen dort nicht praktiziert zu werden; es
ist eher ein einziges Chaos.
Die Entwicklung, wie ich sie mir bisher vorgestellt habe, ist in der
Realität (ich zähle die Uni, wo ich wie gesagt auch entwickelt hab,
nicht dazu) ganz anders. 90% ist nur Papierschlacht...
Das alles lässt mich mehr und mehr daran zweifeln, ob mir das wirklich
Spass macht. Ich glaube nicht...
Das wundert mich, weil ich mich in diesem Bereich eigentlich bisher wohl
gefühlt habe.
In welchen Bereichen arbeitet ihr? Was kann ich mit einem B.Sc. Techn.
Inf. machen?
Ich bin am überlegen, noch den Master draufzusetzen. Das verlagert das
Problem, was ich dann machen will, aber nur etwas nach hinten...
Gruß
Jens
Hallo,
bin als Softwareentwickler im Automotive tätig und man kann über den
Daumen sagen, dass ich vielleicht 10% meiner Zeit programmiere und
sonst:
- Requirements anpassen\reviewen
- Analyse erstellen\ anpassen\reviewen
- Design erstellen\ anpassen\reviewen
- Modultests Spezifikation schreiben\ anpassen\reviewen
Und dazu kommen jede menge Code - Reviews\Meetings usw.
Und wenn ein Fehler in der Software entdeckt wird und man die Software
anpasst, dann fängt alles wieder von vorne an, da neue Seiteneffekte
auftreten könnten.
Vielleicht ist es im Automotive Exterm, aber habe das schon von mehreren
Kollegen gehört, die in verschiedenen Bereichen tätig sind.
Das ist halt die Realität.
Gruss
Hi,
genau abschätzen kann ich es noch nicht, aber die Größenordnung vermute
ich hier auch.
Genau so, wie du es beschreibst.
Und ich glaube, das geht mir gewatltig auf den Keks. Das ist ja alles
nur formaler Krieg, wo man (ich jedenfalls zur Zeit :)) regelmäßig zur
Sau gemacht wird.
Ich habe bis jetzt noch keine einzige Zeile Code geschrieben etc.
Stört dich das denn überhaupt nicht? Gewöhnt man sich daran?
Gibt es da denn keinen Ausweg...? Es wird ja wohl relativ egal sein, in
welcher Firma ich arbeite - der Projektoverhead wird wohl immer
erschlagend sein.
1. Am Anfang ist immer alles toller. Da kann man nichts machen.
2. Es gibt immer Phasen wo alles sch.. ist. Da muss man durch. Dann
wirds besser.
3. Es gibt definitiv auch Firmen wo nicht >75% Papierkrieg ist.
Den Hinweis auf keine Auto-/Flugzeug-/Rüstungsfirmen halte ich auch für
richtig. Klar gibt es aber auch da Stellen, wo man nicht soviel
schreiben muss. Wenns gar nicht anders geht musst Du Dir halt eine
solche suchen. Da helfen Bekannte/alte
Kommilitonen/Praktikumserfahrungen sicherlich weiter.
@Jens: Willkommen in der Realität. Ich arbeite beim Fraunhofer Institut,
und einen höheren Verwaltungsaufwand hat wohl nur noch der Bundestag
oder Gott persönlich. Aber es macht trotzdem Spaß. Den Papierkrieg hat
man überall, das dazwischen muss halt stimmen.
Das Problem mit dem Papierkram wirst Du in praktisch allen Branchen
wiederfinden. Sobald ein Produkt/Gerät eine Zulassung braucht, musst Du
je nach Zulassungsland die jeweiligen Dokumente liefern. Auch wenn Du
für bestimmte Länder bestimmte Produkte entwickeln willst, musst Du die
entsprechenden Dokumente vorweisen können.
Wenn Du also z.B. Medizinprodukte in den USA verkaufen willst, kommt bei
Dir die FDA vorbei und prüft, ob Du alle Dokumente so geführt hast, wie
sie das wollen. Ansonsten darfst Du Deine Produkte da halt nicht
verkaufen.
Ausserdem: Was ist, wenn Du eine Software geschrieben hast, Du diese
Firma verlässt und nichts dokumentiert hast? Wenn jetzt diese Software
weiterentwickelt werden soll, müssen die sich erst Wochen oder Monate
damit beschäftigen, Deinen Code zu verstehen.
Der ganze Papierkrieg wird nicht ohne Sinn veranstaltet. Damit muss sich
jeder Entwickler rumschlagen. Aber dadurch solltest Du Dir die Freude am
entwickeln nicht nehmen lassen.
MFG
Patrick
Ja, das ist mir schon klar.
Ich hab mir die Entwicklung nur ganz anders vorgestellt.
Es ist so, wie Jim gesagt hat.
Aber selbst wenn man den Papierkrieg einmal ignoriert, ist auch der
Teil, der die eigentliche Entwicklung sein soll, absolut nicht so, wie
ich dachte.
Ich habe bis heute nicht verstanden, wie ich im Vorweg eine Kalkulation
anstellen soll, wenn ich das Produkt erst in der Planung habe. Woher
weiß ich, ob das Design, was mir vorschwebt, so klappt? Ob ich andere
Bauteile / Resourcen brauche? Und was das kostet?
Ich muss aufstellen, wieviel Zeit mich was kostet, und was an
Materialkosten anfällt. Und danach geht man erst in die eigentliche
Entwicklung, also die Umsetzung der Spezifikation. Woher soll ich aber
vorher wissen, ob die "sauber" ist? Vielleicht passt das Programm, das
ich schreibe, nicht in einen ATmega, oder der ist einfach zu langsam?
Dann kann ich das gesamte Produkt neu entwerfen, weil sich der
Prozessor, das PCB, das Gehäuse, ... ändert.
Das ist nur frustrierend. Ich stocher eigentlich nur im Trüben und
versuche, irgendwas zu kalkulieren. Ich könnte wetten, ich habe ungefähr
1.000 Sachen nicht bedacht. Im besten Fall resultiert das dann einfach
in Nachtschichten...
Und außerdem: Wo bleibt die Freude bei der Entwicklung, wenn alles auf
Papier passiert?
Der Firma wäre es am liebsten, wenn man das Ganze nicht einmal mehr
aufbauen muss, um es zu testen. Wo bleibt denn da der Spass an der
Sache?
Und was passiert, wenn ich erst nach der ganzen Designphase ein
Problem feststelle, wie z.B. einen zu langsamen Prozessor (oder einen zu
vollen oder so)?
@Bernd G:
Was machst du denn? Magst du mal etwas berichten, wie das so läuft etc.?
Die Antwort auf Deine Fragen lautet: Erfahrung!
Alle diese Entwurfsentscheidungen basieren auf Deiner Erfahrung. Und
wenn Du jetzt noch keine hast, irgendwann muss man ja anfangen.
Seh's mal so:
Viel von diesem Papierkram ist eben genau das, was einen Ingenieur
ausmacht:
Requirements festlegen, Design erstellen, Testfälle ausdenken,
Spezifikationen schreiben mit denen andere arbeiten können etc. Um "nur"
zu programmieren, braucht man kein Studium, die meisten Sprachen kann
man sich sogar selbst aneignen wenn man motiviert ist.
Es geht eben nicht darum, Frickelprogramme zu erstellen die zwar super
funktionieren, aber außer dir keiner versteht. Es geht um
ingenieurmäßige Entwicklung, also planbare Abläufe innerhalb der
Entwicklung.
Dazu kommt, je nach Branche, der Zeitaufwand für
Projektsteuerungsmaßnahmen (Meetings, Schriftverkehr mit dem PM,
Dokumentation was man gerade macht/gemacht hat) sowie alles was unter
Qualitätssicherung fällt.
Im Automotive-Bereich ist Projektsteuerung und QM schon sehr aufwendig,
weil Autos sozusagen das Aushängeschild der Wirtschaft sind und alles
perfekt sein muss. Dazu kommen die Sicherheitsüberlegungen (ein Fehler
in der Software kann Leben kosten, ähnlich wie in der
Flugzeugindustrie). Von daher hast du wohl genau die falsche Branche für
dein Praktikum erwischt, andererseits wirst du ähnliche Dinge in allen
Branchen finden, wenn vielleicht auch nicht ganz so extrem. Aber auf
Projektmanagement und QM kannst du heute kaum noch verzichten, wenn du
mit günstigeren Anbietern aus dem Ausland konkurrieren mußt.
Bin selbst in einer Firma der Automotive-Branche unterwegs und fühlte
mich am Anfang auch erschlagen von den formalen Abläufen. Sollte zur
Einarbeitung einem Kollegen über die Schulter gucken. In den ersten zwei
Wochen hat er nicht eine Zeile Code getippt!
Jede kleinste Änderung an einem Softwaremodul, und wenn es nur die
Umbenennung einer Variablen oder Verbesserung von Tippfehlern in
Kommentaren ist, muss in einer Datenbank kommentiert werden. Zudem muss
auf Kommentare von anderen Beteiligten gewartet werden, die ebenfalls
davon betroffen sein könnten. Nach der Codeänderung muss dann über das
Versionsmanagement-Tool ein neues Release des Moduls erfolgen, man muss
wieder kommentieren was man gemacht hat und warum. So gehen schonmal 2
Stunden drauf für eine Änderung von einer Zeile Code, die 1 Minute
gedauert hat inklusive Compilerdurchlauf.
Aber diese Standards verlangt eben der Kunde, deshalb muss man sich
anpassen. Im Studium hast du für dich selbst programmiert, da konnte
höchstens der Prof irgendwelche Anforderungen an den Arbeitsablauf
stellen. In der Industrie arbeitest du innerhalb eines Teams, das
wiederum innerhalb eines Projektes arbeitet. Viele Stellen müssen von
deinem Tun informiert werden, du musst dich auf andere verlassen. Das
erfordert eben Verwaltungsaufwand.
Natürlich steigt dieser Aufwand, je größer die Firma ist. Eine kleine
Firma hat nur mit den Kundenanforderungen zu kämpfen, das interne
Projektmanagement kann evtl. lockerer sein.
Aber kannst dich trotzdem schonmal drauf einstellen, dass du ohne diese
Dinge nicht auskommst. Code tippen lassen kann man auch in China oder
Rumänien, Spezifikationen und Designs erstellen lassen nicht unbedingt
überall, von Qualitätsstandards ganz zu schweigen. Das ist im Moment
noch unser Vorteil gegenüber anderen Ländern, der aber auch mehr und
mehr schmilzt weil die anderen dazulernen.
Also, halt die Ohren steif.
>Ich habe bis heute nicht verstanden, wie ich im Vorweg eine Kalkulation>anstellen soll, wenn ich das Produkt erst in der Planung habe. Woher>weiß ich, ob das Design, was mir vorschwebt, so klappt? Ob ich andere>Bauteile / Resourcen brauche? Und was das kostet?
Das kannst du auch noch gar nicht wissen. Wie schon jemand schrieb, das
kommt über die Erfahrung. Jetzt im Praktikum fühlst du dich natürlich
total überfordert davon. Aber ich denke, es erwartet auch niemand von
dir dass du das schon kannst. Du wirst halt ins kalte Wasser
geschmissen, zum Üben.
>Ich muss aufstellen, wieviel Zeit mich was kostet, und was an>Materialkosten anfällt. Und danach geht man erst in die eigentliche>Entwicklung, also die Umsetzung der Spezifikation. Woher soll ich aber>vorher wissen, ob die "sauber" ist? Vielleicht passt das Programm, das>ich schreibe, nicht in einen ATmega, oder der ist einfach zu langsam?>Dann kann ich das gesamte Produkt neu entwerfen, weil sich der>Prozessor, das PCB, das Gehäuse, ... ändert.
Ja, sowas kann passieren. Aber besser sowas passiert im Praktikum, als
später bei einem Kundenprojekt, oder?
Für mich sind grade die Abschätzungen nach einem halben Jahr
Berufserfahrung immer noch sehr schwierig. Ich frage meistens
erfahrenere Kollegen oder schaue mir ähnliche Projekte an. Sicher bin
ich mir dann trotzdem nicht. Aber es reißt dir auch niemand den Kopf ab
wenn es nicht 100%ig stimmt. Auch die erfahrenen Kollegen haben da immer
noch Probleme.
Es nennt sich deshalb ja auch AbSCHÄTZUNG ;)
Frag doch am besten Mal in deiner Firma jemand, der sowas schon öfter
gemacht hat.
>Das ist nur frustrierend. Ich stocher eigentlich nur im Trüben und>versuche, irgendwas zu kalkulieren. Ich könnte wetten, ich habe ungefähr>1.000 Sachen nicht bedacht. Im besten Fall resultiert das dann einfach>in Nachtschichten...
Man bedenkt selten alles in so einer Kalkulation. Wenn man ungefähr ein
Gefühl dafür entwickelt hat, sollte man immer versuchen noch etwas
draufzuschlagen, falls etwas schief geht. Ein bißchen Flunkern ist
besser, als wenn ein Projekt in den Sand gesetzt wird weil die
Abschätzung viel zu knapp war.
>Ich habe bis heute nicht verstanden, wie ich im Vorweg eine Kalkulation>anstellen soll, wenn ich das Produkt erst in der Planung habe. Woher>weiß ich, ob das Design, was mir vorschwebt, so klappt? Ob ich andere>Bauteile / Resourcen brauche? Und was das kostet?
Jetzt aber mal im Ernst: Welche Firma erwartet das den von einem
Absolventen der nur schulisches Wissen besitzt?
Muss ein solcher Absolvent nicht erst einmal für ein Jahr der Assistent
eines Senior-Entwicklers sein?
@Nixwisser:
Genau so ist es.
Zu dem:
Softwareentwicklung hat nichts mit (reinen) Programmieren zu tun.
Das Programmieren ist der kleinste Teil davon.
Gruss
Projektaufwand und Kosten abschätzen ist tatsächlich etwas vom
schwirigsten überhaupt in der Hard- und Softwareentwicklung... vor allem
wenn man nicht weiss, wie oft und andauernd man während des
entsprechenden projektes noch mit anderem beauftragt wird... (hatte
gerade letzthin ein Projekt, wo ich mit einem halben jahr bis zur
0-Serie kalkulierte... nach 2 monaten musste ich 2 Monate ein anderes
7-Wöchiges Projekt dazwischenschieben und wurde dann gefragt, wiso ich
nicht zur zeit fertig geworden bin ggg
Da ich ich trotz 4 jahren Berufserfahrung den Aufwand meist etwas
unterschätze, nehme ihc jeweils meine Abschätzung und multipliziere sie
mit 3... Klappt ganz gut...
P.S. ich hab vielfach ein gegenteiliges Problem wie die meinsten hier,
sprich zu wenig Papierkram ggg. Bin ziemlich frei was ich
dokumentieren will und was nicht (naja solange es eine brauchbares
usermanual gibt) was grundsätzlich zur tendenz führt, das man messungen
aus zeitgründen zu wenig ausführlich dokumentiert, oder auch allgemein
das dokumentieren auf nächste woche verschiebt... :-)
Daniel wrote:
> Da ich ich trotz 4 jahren Berufserfahrung den Aufwand meist etwas> unterschätze, nehme ihc jeweils meine Abschätzung und multipliziere sie> mit 3... Klappt ganz gut...>
Hihi, wir multiplizieren mit Pi, das klappt auch meist ganz gut :)
Sagen Euch die Namen Toll Collect oder Transrapid etwas?
Hehe, soviel zum Thema Abschätzung und Kalkulation. Manchmal dauerts
eben ein bißchen länger oder übersteigt den Etat um ein Vielfaches.
Hallo Jens,
ich komme erst jetzt zu einer Antwort:
Das Problem, dass in der Entwicklung einer Firma alles anders ist, als
gedacht, hatte ich auch, alles war auf Papier, weit und breit kein
Lötkolben, keine Meßgeräte, nichts, nur eine Papierwüste. Im ersten Jahr
habe ich nur Akten und Dokumentation einsortiert. Als Krönung des ganzen
durfte ich auch mal ein Stammoriginal bearbeiten (wissen nur noch die
Alten hier im Forum, was das ist).
Dann habe ich Prüf- und Inbetriebsetzungsvorschriften für Geräte und
Anlagen geschrieben, die ich nur vom Hörensagen kannte.
Aber: ich wurde einem erfahrenen Ing zur Seite gestellt, der mich
einzuarbeiten hatte. Den Absolventen selbst schwimmen lernen zu lassen,
halte ich für unverantwortlich
Irgendwann habe ich gekündigt und bin zu einer richtigen Entwicklung
gegangen.
Die Entwicklung war dort auch nicht so toll, wenn man bedenkt, dass es
eben nicht so einfach ist, High-tech ohne die heutigen Möglichkeiten
(PC, Nutzung des Internet als Informationsquelle) zu machen.
Schaltkreisentwurf:
auf dem Mainframe-Rechner mit Verilog.
Zum Problem der Kalkulation von Entwicklungsaufwendungen haben meine
Vorredner eigentlich schon alles gesagt: es geht nur, wenn man alle
Detailprozesse kennt und bewerten kann. Das ist eine Sache der
Erfahrung,
die nie jemand sicher ausführen kann. Ich dimensioniere meine Geräte
lieber erst mal mit einem gewissen Overkill. Was es dann gekostet hat,
weiß man erst in der Retrospektive.
Zur Selbständigkeit: würde ich erst nach Aneignung von umfassenden
Berufserfahrungen empfehlen.
Denke aber bitte nicht, dass ich kein Papier erzeuge. Das passiert bei
mir ganz genauso: Zeichnungsnummernverwaltung, Entwicklungssdok.,
Fertigungsdok., Kundendok., Änderungen, Änderungsmitteilungen,
Änderungsanweisungen, Ausgabestände, Prüfberichte usw. usf. Bei der
Riesenanzahl von Baugruppen und Geräten kann man sich nichts mehr
merken. Der Kunde darf mit Recht erwarten, dass seine Geräte auch nach
10 Jahren noch repariert und gewartet werden können!
Mein Vorteil ist klar erkennbar: ich muß zu keinen Blabla-Meetings mit
den ewig gleichen Selbsdarstellern gehen und der Entwicklungsanteil
passiert noch mit fleischgewordenen Baugruppen und richtigen Meßgeräten.
Da ich vermute, dass die Angabe meiner HP als Werbung aufgefasst wird,
lasse ich es sein.
Prüfmittelbau (für den firmeninternen Gebrauch) ist auch noch ein
interessantes Thema. Viel Freiraum, alles Einzelstücke, wenig
Papierkram... aber mäßiger Verdienst.
Kleiner Tip:
In Bereichen wo man mit Papier erschlagen wird, also alles was Normung
angeht, Verfahren nach IEC61508, V&V Plan, Sicherheitstechnik kann man
Geld verdienen. Als Hardwaremuckel in einer privaten Bastelbude hast Du
erstens kaum Rechte, verdienst schlecht und zweitens fliegst Du, wenn es
Deinem AG grad passt. In Rüstungsfirmen ist das alles noch etwas
heftiger, muss aber jeder selbst wissen ob er mit Waffen glücklich wird.
Diehl Defecence sucht derzeit Leute für FPGA Design für
Raketensteuerungen aber eher Leute mit Erfahrung.
Ich empfehle nur grosse zertifizierte Konzerne und weiss auch warum,
gerade wegen der Regelungen, die einem AN Pflichten und Rechte
einräumen.
Und Kalkulationen gehören nunmal dazu, das lernt man aber mit der Zeit,
wenn man erstmal einige Aufträge abgewickelt hat geht das wie im Schlaf.
Was kann man denn sonst mit einem BSc in Techn. Informatik anfangen?
Auf so typischen Server- und Rechnernetze-Wartungs-Krams hab ich
eigentlich keine rechte Lust...
>Auf so typischen Server- und Rechnernetze-Wartungs-Krams hab ich>eigentlich keine rechte Lust...
Würde ich auch nicht machen, für sowas muss man nicht studiert haben und
deshalb sitzen in den IT-Abteilungen auch oft noch Quereinsteiger ohne
Studium.
Wenn das wirklich so ein Problem für dich ist, such dir ne kleine
Klitsche wo drauf los entwickelt wird. Aber erwarte nicht, dass du da
groß verdienst oder Aufstiegschancen hast.
Hallo,
ist das wirklich so wie hier geschrieben wird?
Ich studiere grade technische informatik (2. Semester, natürlich auch
Bachelor), aber wenn ich dass hier lese, vergeht mir etwas die lust.
Wird echt alles mit Papier erschlagen (ich soll 90% meiner Zeit mit
Papierkrieg vertun??), oder gibt es vll auch andere Beispiele wo es
besser läuft?
Ist das bei jedem Ingenieurs-Beruf so? Wo ist es besser?
mfg
Johannes
Moin,
habe vor 10 Jahren mal ein Praktikum und anschließend einen Ferienjob in
einer Forschungseinrichtung gemacht. Dort wird noch (bzw. wurde damals)
noch "richtig" gebastelt. Alle Versuchsstände etc. werden dort von Hand
aufgebaut und sind unikate - Damals gab es dort keinen Papierkram...
Vielleicht ist das ja eher was ?
Gruß
Andreas
@ Johannes L.
> Wird echt alles mit Papier erschlagen (ich soll 90% meiner Zeit mit
Papierkrieg vertun??), oder gibt es vll auch andere Beispiele wo es
besser läuft?
Ich würde es so definieren: mit 70%-iger Wahrscheinlichkeit wirst du
solch eine Stelle erwischen.
Das Problem ist, dass die Papierstellen meist besser bezahlt werden, als
die Lötstellen.
Denkst du etwa, ein Maschinenbau-Ing steht im Blaumann an der Drehbank?
Am Ende kommt es darauf an, was du selbst daraus machst. Also kein Grund
zur Verzweiflung.
Verabschiedet euch von dem Gedanken, wie im Studium drauf los
programmieren zu können. Try'n Error wird bei den wenigsten Firmen
geduldet. Man will gut dokumentierten, leicht wartbaren, leicht zu
testenden und wiederverwertbaren Code. Anständiges Design und Papierkram
zur Qualitätssicherung - das ist es was einen Ing. auszeichnet und was
von den Kunden verlangt wird. Die Umsetzung in die Programmiersprache
kann man jedem Schimpansen beibringen. Dieser "Overhead" ist im Übrigen
auch noch unser Vorteil gegenüber Frickelbuden in Indien oder China.
Wenn ihr das nicht machen wollt könnt ihr euch ja dort bewerben ;)
>Denkst du etwa, ein Maschinenbau-Ing steht im Blaumann an der Drehbank?
Allerdings denke ich das. Es kann nie schaden, wenn man vor dem Studium
einen anstaendigen Beruf gelernt hat und auch mal selbst ein Drehteil
herstellen kann.
Hochachtungsvoll
Herbert von Caravan
>Bisher (also während des Studiums als auch privat) fand ich sowas>absolut klasse, neue Geräte zu entwickeln.>Leider macht es mir nun überhaupt keinen Spass mehr.>Erstens ist es etwas komplett anderes, ob man in der Uni in einem>Projekt etwas entwickelt (ich habe da ein Interface mit GrafikLCD und>Drehgeber gebaut, das Geräte wie Netzteil, Funktionsgenerator etc [so>wie das ct'lab, aber eben alles selbst entwickelt] über I2C>kontrolliert).
wilkommen im Leben, wo Du Deine Subsistenz-Mittel selber
selber erwirtschaften mußt!
3 x Angestellte
1 x Ich
Gruß Fred
