Hallo, geht es euch auch so dass bei den Entwicklung neuer Produkte (in meinem Fall Software) hoher Druck vom Chef ausgeübt wird ? Alles soll so schnell wie möglich fertig werden, am besten gestern schon, aber selber weis man dass es noch Monate dauert. Wenn ja wie geht es euch damit bzw. wie geht ihr damit um. Mich setzt dies sehr unter Stress.
Ne, bei uns sagt der Chef: Lasst euch mal Zeit, arbeitet in eurem Tempo und macht euch bloß nicht kaputt.
Habt ihr keinen Projektleiter, der den Projektplan mit dem Chef bespricht? Oder ist das eine Minifirma mit einem Entwickler und einem Chef?
:
Bearbeitet durch User
Ein gewisser Zeitdruck ist doch normal. Da sollte man mit umgehen können. Irgendwer muss den Spaß ja auch bezahlen. Bei uns ist alles ordentlich und vor allem realistisch in Pflichtenheften mit Zeitstrecken, Milestones, usw. festgehalten und sorgt selten für Probleme. Der Aufwand ein rechtssicheres und realistisches Pflichtenheft zu erstellen sollte aber nicht unterschätzt werden Da muss man ein wenig Erfahrung haben. Meisten ist dann aber genug Zeit für Späßchen oder ein wenig Privatpfusch nebenbei und das steigert wieder die Stimmung, Motivation und Produktivität.
In den meisten Fällen liegt es daran, dass keiner sagt: "Scheiße das dauert aber länger". Derjenige der den Druck erzeugt, hat mit Sicherheit auch irgendeinen "Drückeberger" im Rücken und sehr oft ist in der Befehlshierarchie jemand der zwar bis drei (Stunden oder Euro) zählen kann, aber sonst von Tuten und Blasen keine Ahnung hat. Aber langer Rede kurzer Sinn: Solange alle nur nicken, werden sich alle, in der Hierarchie oben stehenden wundern, warum das Projekt nicht in die Pötte kommt.
Amateur schrieb: > Derjenige der den Druck erzeugt, findet sogar gelegentlich, daß seine Entwicklungsabteilung völlig überflüssig ist, und die nur zum Schein tun, als wenn sie arbeiten, weil es am Markt angeblich schon alles entwickelt fertig gäbe. Am besten gratis.
Softi schrieb: > geht es euch auch so dass bei den Entwicklung neuer Produkte > (in meinem Fall Software) hoher Druck vom Chef ausgeübt wird ? Leider: ja! Wobei bei uns der Grund z.T. die Kunden sind, die unrealistische Termine fordern. Leider wird das von den Chefs meist auch nicht wirklich entschärft. Z.T. versuchen sie's, aber die Termine sind meistens fest. Wenn wir das nicht abnicken, wird halt zur Konkurrenz gegangen. Aber dass man deshalb bei uns mehr Entwickler einstellen würde? Fehlanzeige. Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu programmieren, die aber nicht wirklich gefordet sind. Auch wenn ich mir denke, dass das 100%ig noch kommen wird, mache ich es nicht, denn ich weiß, dass dann am Ende gar nichts fertig sein wird. Wenn Umfang und Zeitschiene festgelegt sind, kann man leider nur an der Qualitätsschraube drehen. Da wird halt dann aus einem "Ist getestet, funktioniert!" eher mal ein "Nicht getestet, aber wird schon passen.". Leider habe ich schon von vielen Entwicklern (nicht nur Software, auch Elektronik, Masch.bau usw.) in anderen Firmen Ähnliches gehört. Da grenzt es natürlich an russischem Roulette, wenn man die Firma wechselt, um zu hoffen, es dort besser zu haben. Auf jeden Fall muss das jeder selber für sich entscheiden. Nicht jeder kann bei so einer chaotischen Arbeitsweise und Terminen im Nacken noch ruhig schlafen. Kaputt machen lassen darf man sich jedenfalls nicht. Das ist kein Geld der Welt wert.
Ein gewisser Druck ist immer notwendig, das ist einfach eine Folge aus dem Parkinson-Gesetz. Wenn man keinen Druck aufbaut, dauert es einfach viel länger als es müsste. Der Trick ist, genau so viel Druck auszuüben, dass die Mitarbeiter effizient arbeiten aber dabei nicht ausbrennen. Ideal ist, wenn der Druck durch innere Motivation entsteht, sprich die Leute sind von sich aus motiviert, die knappen Termine zu halten. Habe selbst erlebt, wie eine eher träge Entwicklungsabteilung plötzlich aufblüht, weil die Leute durch einen besonderen Umstand und einen sehr engen Terminplan eine sehr hohe Motivation für ein bestimmtes Projekt entwickelt hat. Außerdem muss sich Druck und Entspannung abwechseln. Man kann durchaus ein Entwicklungsteam auch mal ein paar Wochen oder Monate vor sich hin bummeln lassen, damit die Akkus wieder aufgetankt werden. Arbeit wird ja in der Zeit immer noch erledigt.
bei Software gibt es immer Probleme, die man vorher meist nicht voraus gesehen hat. Teilweise dauert manchmal ein einzelner Step für den 1 Tag eingeplant war, auch mal eine Woche. Oder man braucht zur Behebung eines auf die Schnelle trivial aussehenden Bugs mehrere Stunden, obwohl man dachte, das wäre in 10-15 Minuten erledigt. Dann dem Projektleiter sowas jedes mal zu erzählen, ist oft unangenehm, der muss es dann seinem Chef oder dem Kunden erzählen, der dafür meist wenig Verständnis hat. Dazu kommt, dass Individual Entwicklung extrem teuer ist, gerade wenn mit der Software nur sehr wenige Leute später arbeiten. Ein Entwicklertag kostet gerne mal 500 Euro (intern) und ein Projekt mit 300 PTs ist jetzt nicht mal ein größeres. Meist ist es bei der SW Entwicklung auch so, dass man selten Dinge entwickelt, die man schon sehr oft entwickelt hat, sonst würde man ja einfach eine Standardlösung benützen bzw. anpassen. Daher hat man meist sehr hohe Unsicherheitsfaktoren. Bei einem Hausbau ist das anders, da sind die Arbeitsschritte i.d.R. viel besser zu standardisieren. Industriealisierung der SW Entwicklung ist an sich nichts verkehrtes, aber das Problem ist, dass manche Manager meinen, man könnte SW Entwickler quasi genauso entwickeln lassen, wie angelernte Bandarbeiter, wo jeder Schritt bis ins genauste durchgeplant ist (inkl. Spezifikation!!!!!). Dabei kann man viele industrielle Prozesse nicht mit SW Entwicklung vergleichen. Die reine Fertigung bei der SW Entwicklung übernimmt nämlich der Compiler. Dazu kommt, dass Software nicht so sehr den riesen Wert zugesprochen wird. Viele meinen einfach, Software und sowas, das kostet doch alles nichts. Bei Anlagen, Autos und Maschinen wird da ganz anders gedacht. Insbesondere bei "Made in Germany".
>Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die >zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu >programmieren, die aber nicht wirklich gefordet sind. Solches sollte eigentlich durch ein Pflichtenheft festgelegt sein. Größere Projekte kann man einfach nicht nach dem Motto: "Nun macht mal" durchziehen. An dieser Stelle kann auch Druck, etwas positives, das Projekt förderndes, sein.
Amateur schrieb: > Solches sollte eigentlich durch ein Pflichtenheft festgelegt sein. eben. Solche Dinge die nützlich aber nicht gefordert sind, nennt man ja auch gerne "goldene Henkel". Sowas würde ich niemals extra dazu einbauen. Dann lieber mehr Zeit dafür einsetzen, damit das was gefordert ist, wirklich zu 100% stimmt, inkl. Dokumentation, Installationsanleitung, ggf. Beschreibung für die Wartung, Bedingungsanleitung usw. Dafür wird man bezahlt und das war auch gewollt. Solche nützlichen, aber nicht geforderten Dinge, kann man später immer noch als Change Request gut verkaufen und so sichert man sich ggf. Zusatzaufträge. Ein Autohersteller baut ja auch nicht für Umsonst Extras in ein bestelltes Auto mit ein, die der Kunde gar nicht gefordert hat. Am Ende sagt der Kunde vielleicht sogar "Ja ganz nett, brauchen wir aber gar nicht"
Marvin schrieb: > Ein Autohersteller baut ja auch nicht für Umsonst Extras in ein > bestelltes Auto mit ein, die der Kunde gar nicht gefordert hat. Oh doch, genau das tut er! Ich habe z.B. einen Berganfahrassistenten und eine Scheinwerferreinigungsanlage, die ich gar nicht wollte. > Am Ende sagt der Kunde vielleicht sogar "Ja ganz nett, brauchen wir aber > gar nicht" Exakt so ist es!
Dirk K. schrieb: > Oh doch, genau das tut er! Ich habe z.B. einen Berganfahrassistenten und > eine Scheinwerferreinigungsanlage, die ich gar nicht wollte. Das glaube ich kaum. Diese Extras gehen garantiert mit in den Fahrzeugpreis ein. Und wenn du das nicht wolltest bzw. nicht wusstest, dann hast du dich vor dem Kauf nicht ausreichend informiert.
Also meiner Erfahrung nach ist die Entwicklung nicht das Hauptproblem bezüglich Zeit, es ist die Fehlersuche und die Wartung. Und mit Erfahrung kann man leicht wartbare Software schreiben. Dazu kommt noch, dass man sich die Werkzeuge aussuchen muss, die zum Problem passen. Einige Firmen gehen in die genau umgekehrte Richtung und versuchen sich auf ein, oft minder geeignetes, Werkzeug zu einigen. Ein Problem, dass in einer Sprache Bildschirmseiten an Code benötigt, kann in einer anderen Sprache in 5 Zeilen erledigt werden. Deshalb gibt es auch unterschiedliche Sprachen, wie zum Beispiel Erlang http://www.youtube.com/watch?v=xrIjfIjssLE
>Dazu kommt, dass Software nicht so sehr den riesen Wert zugesprochen wird. Viele
meinen >einfach, Software und sowas, das kostet doch alles nichts. Bei Anlagen,
Autos und Maschinen >wird da ganz anders gedacht
Das kenne ich hier in der Firma auch. Besonders von den mechanischen
Entwicklerkollegen oder yprojektleitern. Die denken msnchmal, mit
Software kann man alles korrigieren, auch wenn die Mechanik das
überhaupt nicht unterstützt.
Ich schlage dann immer vor, die Elektrik komplett zu entfernen und alles
rein mechanisch zu erledigen. Kurvenscheiben, Baudenzüge, etc. Wenn sie
damit genauso flexibel sind, dann sollen die es doch machen.
Dem Chef sage ich dann immer, ich wäre schön froh, wenn die Software
wenigstens als notwendiges Übel, statt nur als Übel angesehen wird....
Ein großes Problem sehe ich darin, dass Software angeblich jeder Depp schreiben kann. Da hat der Nachbarjunge irgendetwas tolles gemacht. Also kann es ja nicht so schwer sein.
Christian Berger schrieb: > Ein > Problem, dass in einer Sprache Bildschirmseiten an Code benötigt, kann > in einer anderen Sprache in 5 Zeilen erledigt werden. das muss aber nicht unbedingt was gutes heißen. Wie jemand schon sagte, geht oft viel Zeit für die Wartung drauf, insbesondere dann, wenn die Wartung von jemand anderem übernommen wird. In so einem Fall steigt man ggf. besser durch einen etwas längeren aber weniger komplexen Code durch, als durch einen sehr kurzen, hoch eleganten Code, wo sich jemand 4 mal das Gehirn hat verbogen. Das ist natürlich nicht immer so und kommt auf den Einzelfall darauf an. Manchmal ist so eine Lösung z.B. aus Performance Gründen notwendig. Manchmal leidet auch sowas wie die Trennung von Zuständigkeiten in einem sehr kurzen Code. Vieles kann man z.B. ohne saubere Schichtentrennung etc. in sehr kurzem Code lösen, aber dann leidet manchmal die Wartbarkeit. Z.B. GUI Coding, Anwendungscoding und Datenhaltung alles in einer Routine. Im Einzelfall, gerade für triviale Anwendungen mag das noch Sinn machen, nicht aber für große Anwendungen.
genervt schrieb: > http://www.amazon.de/Clean-Coder-Verhaltensregeln-... Und was soll das bringen? Ich denke nicht das man bei entsprechendem Druck noch die Zeit für CCD findet. Das ist das gleiche wie agile Entwicklungsmethoden, natürlich hat sowas langfristig vorteile für die Firma, aber die meisten denken ja nur bis zum Ende der Woche. Bei solchen Dingen muss die Firma voll dahinter stehen und ich glaube nicht dass das bei einer Firma die schon so einen enormen Druck aufbaut der Fall sein wird.
FZ schrieb: > Bei solchen Dingen muss die Firma voll dahinter stehen und ich glaube > nicht dass das bei einer Firma die schon so einen enormen Druck aufbaut > der Fall sein wird. Das ist in reinen Softwarefirmen der Fall und deshalb arbeite ich auch nur noch selten für Firmen die Software als kostenintensiver Ballast ansehen, dementsprechend wird dort auch entwickelt, besser gesagt gefrickelt. Dort bist du als Softwaremensch in einem unternehmen das damit nicht sein Geld verdient immer der Arsch. Zeitgemässe Entwicklungsmethoden kannst du nicht einführen, weil "das nur Geld kostet und keine schnellen Ergebnisse bringt", denn nur das zählt dort wo der Controller das sagen hat, dann kommt halt nur Scheisse bei raus, das geht aber nicht in deren minderbemittelten Erbsenzählerhohlschädel die nur ein Jahr voraus "denken" können. Die letzte Bude wo noch nach Gutsherren Art entwickelt wurde, war ich ein Tag, dann hatte ich die Schnauze voll von solchen Firmen, wo wieder so ein BWL-Hans Wurst dir erklären will wie du Software zu entwickeln hast, welche Tools du nutzen darfts, von denen er gar nicht weiss wozu die gut sind. Allein schon die Arbeitsplätze die man zugewiesen bekommt: die übelste Kammer auf dem ganzen Stockwerk, mit dem ältesten Rechner und daraus soll man Spitzensoftware rauszaubern. Das ist wie wenn ein Sternekoch in einer Teeküche 200 Essen raushauen soll, auf Sterneniveau.
FZ schrieb: > genervt schrieb: >> http://www.amazon.de/Clean-Coder-Verhaltensregeln-... > > Und was soll das bringen? Ich denke nicht das man bei entsprechendem > Druck noch die Zeit für CCD findet. Nicht verwechseln mit: http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1393492473&sr=8-1&keywords=clean+code
@ fy (Gast) >Das ist in reinen Softwarefirmen der Fall und deshalb arbeite ich auch >nur noch selten für Firmen die Software als kostenintensiver Ballast >ansehen, dementsprechend wird dort auch entwickelt, besser gesagt >gefrickelt. >Dort bist du als Softwaremensch in einem unternehmen das damit nicht >sein Geld verdient immer der Arsch. Das mag sein und ist schlecht, aber . . . >Zeitgemässe Entwicklungsmethoden >kannst du nicht einführen, weil "das nur Geld kostet und keine schnellen >Ergebnisse bringt", denn nur das zählt dort wo der Controller das sagen >hat, Andererseits musst du ja irgendwann irgendwie mal beweisen, dass deine besseren Methoden insgesamt auch WIRKLICH besser und preiswerter sind! Dumm ist nur, wenn man das erst nach Jahren kann, wenn sie die Anlaufkosten und der Einführungsaufwand vorbei sind. Man kann nämlich auch Softwareentwicklung durch unzählige Tools und Framewokrs tierisch aufblasen! Also, wie willst du die Leute überzeugen? Mit deinem Expertenwort und treuen Gesichtsausdruck?
>Andererseits musst du ja irgendwann irgendwie mal beweisen, dass deine >besseren Methoden insgesamt auch WIRKLICH besser und preiswerter sind! >Dumm ist nur, wenn man das erst nach Jahren kann, wenn sie die >Anlaufkosten und der Einführungsaufwand vorbei sind. Gute Beispiele gibt es hier auch. Im Herbst letzten Jahres bekamen ein Kollege und ich eine SW überbeholfen. Macht mal schnell fertig. Ich habe nach Analyse des Codes und viel Flucherei vorgeschlagen, das neu zu schreiben. Angegeben habe ich 5-6Mann-Monate. Danach hätten wir, so argumentierte ich, eine saubere neue SW, wo die aktuellen Kernprobleme behoben sind (paar Zeilen anzupassen, reichte nicht, weil das Grundkonzept nocht passte, und somit wenn man eine Stelle anfasste, hundert andere sofort an der Backe hatte), die Visu so aussehen würde, wie alle anderen Maschinen (corporate identity heisst das wohl). Somit könnte jeder unserer Monteure das auch handeln und nicht nur zwei drei die es kennen. WEiterhin wären viele Anforderungen nicht dazu gebastelt, sondern im Konzept berücksichtigt, etc. Wollte man nicht. Der Kollege wird diese 5-6Mann-Monate bald verbracuht haben. Ergebnis: Viele Flicks und ein beruhigter Kunde. Aber nicht besonders zufrieden. Kein einheitliches (Visu)Design, schlecht wartbar, da (gegenüber den anderen Maschinenpark) völlig anders, etc... Anderes Beispiel ein selbstgeschriebenes PC-Tool. Das ist damals mit den Anforderungen gewachsen. Soweit ist das so. Es würde übernommen und mal schnell noch ein zwei Funktionen zu ergänzen. Ich habe dem, der es machen sollte, gesagt, schreib es neu. Wir wissen jetzt was es werden soll. Zumindest er sieht es mittlerweile ein. Auch dort, ungeeignete Tools. Die Entwicklungsumgebung ist ein Misch aus Borland und was weiss ich noch alles. zB hat ein riesen Aufwand mit UnicodeStrings. Ich sagte damal VisualStudio. System::String und fertig... Aber naja, die Chefs verstehen sowas nicht. Und im Nachhinein ist man immer schlauer, aber selten klüger...
Matthias Lipinsky schrieb: > Macht mal schnell fertig. Wenn solche Sätze zum Projektmotto werden, kann es nur schief gehen. Es wird in Pfusch, Hektik und Mehrarbeit enden. Es gibt einfach zu viele Projektkasper, die dem Kunden das blau von Himmel versprechen ohne Rücksprache mit den Leuten zu halten, die es ausbaden müssen! Es gibt drei Möglichkeiten: 1) Man bekommt den Projektkasper zum Projektmanager erzogen. 2) Man bekommt Projektkasper gegangen. 3) Man geht selbst. Leave it, love it or change it!
genervt schrieb: > Wenn solche Sätze zum Projektmotto werden, kann es nur schief gehen. Es > wird in Pfusch, Hektik und Mehrarbeit enden. So läuft es gefühlt bei 99.99% aller Firmen ab, man versucht natürlich es dennoch so strukturiert wie möglich zu machen. Wer es dann auf die Spitze treibt wie bei großen Konzernen wo alles irgendwo registriert sein muss beschäftigt dann einen Rattenschwanz an Leute die nur mit der Verwaltung beschäftigt sind - und raus kommt dann erst recht so etwas wie z.B bei Intel und AMD … Projektverzögerung, Rückrufe usw. Leider kann nicht jeder so eine tolle Stelle wie Mehdorn beim Flughafen BER haben wo man sich keine Gedanken machen muss dass das Staatsgeld irgendwann mal ausgeht.
>wie Mehdorn beim Flughafen
Der hat die Stelle doch nur bekommen, weil er sich mit Verspätungen
bestens auskennt ;-)
Auf Termine, die ich nicht bestaetigt habe, aber eingehalten werden sollen, sag ich jeweils : ja, ich schaue. Dabei ist mir voellig egal ob ueberzogen wird. Und wenn ich einen Termin bestaetigen soll, sage ich : ich schaue. Wir haben diese Unabwaegbarkeiten, die wir unterwegs erst abschaetzen koennen.... Wenn mich einer ersetzen will : Ok. Sofort. Macht mal.
Das habe ich auch schon erlebt, dass SW-Entwickler sich unentbehrlich machen indem es keine Doku gibt und wenn man es nachvollziehen will, müsste man an etlichen Schrauben ziehen (VHDL+Code). Eigentlich am besten neu schreiben... Wegen jeden Müll kann man dann nachfragen. Teilweise weiß dieser dann aber auch nicht so recht. "Probier mal..." "Aja, wenn man das einstellt, dann kann das meine SW nicht" Blutdruck++;
Softwerker schrieb: > Ich habe mir angewöhnt, keine Programmteile mehr mit einzubauen, die > zwar nützlich sind, oder wo man gerade Spaß daran hat, das zu > programmieren, die aber nicht wirklich gefordet sind. Ganz genau DAS ist der Grund, warum viele Softwareentwickler nicht mir ihrer Arbeit fertig werden. Sie denken, die seien kreativ, wollen selber mitentscheiden, was in die SW rein soll und bauen an der Funktion mit, wovon sie aber besser die Finger lassen sollten. Zudem konzeptionieren sie damit während der Umsetzung und designen hin und her. Das ist das typische Gehacke, was viele veranstalten. Klare Vorgaben und harte Termine sind die einzige Möglichkeit, die Kostem für die SW-Entwicklung gering zu halten. Lässt man den Softies freie Hand, bauen sie, was sie Lust haben, aber keiner gebrauchen kann, ausser ihnen selber keiner bedienen kann und vor allem keiner bezahlt!! Wenn SW-Leute "Ideen" zu Funktionen haben, sollten sie sie formulieren und mitsamt einem Termin- und Kostenentwurf nach oben kommunizieren. Der Projektleiter entscheidet dann mit dem Kunden, ob es rein kommt und wann. Ansonsten ist weder eine gesteuerte Projekt- noch Terminplanung möglich und Teamwork klappt schon garnicht, wenn die Ziele, auch die alle gleichzeitig zuarbeiten müssen, 100% klar sind.
Jürgen N.N. schrieb: > Klare Vorgaben Schon richtig. Nur: Kennst Du irgendeine Firma die es tatsächlich schafft, die Vorgaben (also Requirements) an die Software klar, vollständig, fehlerfrei und in sich konsistent zu halten? Wenn ja, schicke ich dort sofort eine Bewerbung hin. :-)
Jürgen N.N. schrieb:
> Klare Vorgaben
Ja. Toll. Ich bin nun schon seit 30 Jahren im Business und bin immer
noch weit davon entfernt alle Eventualitaeten vorherzusehen und zu
spezifizieren. Ich bin zwar um Groessenordnungen besser als vor Dekaden,
es fehlt aber immer ein Stueck.
Jürgen N.N. schrieb: > Klare Vorgaben Die gibt es vielleicht im Disneyland, aber nicht in der Realität! Requirements kommen erstens immer viel zu spät und zweites ändern sie sich dann noch mindesten drei mal.
Jubi schrieb: > Die gibt es vielleicht im Disneyland, aber nicht in der Realität! > Requirements kommen erstens immer viel zu spät und zweites ändern sie > sich dann noch mindesten drei mal. ja eben, nicht nur das. Oft merkt man erst in der Realisierung, dass etwas doch anders gemacht werden muss oder das Unklarheiten noch drin sind. Oft ist es halt in der Entwicklung so, dass man manchmal Probleme hat, wo man stundenlang debuggen muss und plötzlich macht es klick und es ist nur irgendwo ein Flag was man anders setzen muss, damit es geht. Quasi Arbeit eine Sekunde, aber Vorarbeit Stunden. Sowas dann an einen nicht so technisch-affinen PL heran zutragen ist dann halt nicht immer leicht. Von wegen "wie Sie haben 3 Stunden für das umsetzen eines Flags gebraucht?"
>Von wegen "wie Sie haben 3 Stunden für das umsetzen eines Flags gebraucht
Ich hab auch schon mal die Aussage "Die zehn Zeilen sind doch schnell
getippt", gehört, als ein Kollege, der die SW getreut, krank war. Der
Vergleich zielte wohl auf eine Sekretärin mit zehn Finger Suchsystem ab.
Aber das diese nur abtippt oder nachtippt und der Softie darüber
nachdenken muss, war nicht zu vermitteln...
Die letzt geposteten Beiträge über mir widerlegen nicht meine Forderung nach klaren Vorgaben. Zum einen sind Funktionen und Umsetzung zu trennen und selbstredend sind theoretisch jederzeit Funktionsänderungen denkbar, wenn der Kunde, die GL oder die IB das möchte. Aber dennoch muss sie klar definiert und eingeflochten werden und JA, DAS GEHT! Das geht genau dann, wenn es eine klare Doku und eine gemeinsame DB gibt, in welche die Ideen und Änderungen einfliessen. Und es geht genau dann, wenn eben nicht die Entwickler von unten die Funktionen beim Bauen ändern, weil eben Funktion und Art der Umsetzung getrennt werden. Es ging ja um den Einwand, dass nichtgeforderte Funktionen auch nicht eingebaut werden. Wichtig ist, dass die Entscheider über die Funktionen die Übersicht über die Kosten und Zeiten haben und das haben sie nur, wenn sie selber mal Entwickler waren und die Entwickler in der Lage sind, ihnen die Infos zu geben - insbesondere genau dann, wenn sich was tut, während der Umsetzung. Das erfordert alllerdings eine exakte Projektverfolgung, sodass Projektleiter UND Entwickler mit der Zeit lernen, wann was wieviel Zeit dauert und welche Kosten verursacht - z.B. was Test der vielen von Hackern reingestopften Funktionen angeht. Und ja, es geht! Das Problem ist nur, dass es nicht gemacht wird und Entwickler jahrelang im Chaos entwickeln, nichts dokumentieren und keinerlei Lerneffekt in der Beurteilung der eigenen Geschwindigkeiten und der Komplexitäten haben. Hier haben wir ein Beispiel: >Ja. Toll. Ich bin nun schon seit 30 Jahren im Business und bin immer >noch weit davon entfernt alle Eventualitaeten vorherzusehen und zu >spezifizieren. 10 Jahre sollten reichen, das weitgehend zu erlernen. Aber die meisten machen es wie gesagt nicht, stagnieren also. Werden diese dann Projektleiter, haben wir die stets unterschätzten Projekte und den hohen Druck,um den es in diesem Thema geht. Viele Entwickler machen sich kein Bild, dass die 200 Zeilen Code, die sie für eine Funktione reintippen, nur 15%...20% der Arbeit sind. Den Planungsanteil, den Koordinationsanteil, den Test- und Verifikationsanteil überschauen und berücksichtigen sie oft nicht. Und: Sie kommunizieren ihn nicht. Da sie ihn auch nicht dokumentieren, hat die PL auch keine Chance, das zu erkennen. Und damit bleibt es bei der altem Situation, dass sicher 80%-90% der gesamten Entwicklung in der SW (und auch HW?) chaotisch und impulsiv erfolgt. > Kennst Du irgendeine Firma die es tatsächlich > schafft, die Vorgaben (also Requirements) an die Software klar, > vollständig, fehlerfrei und in sich konsistent zu halten? Ich kenne einige, die sich darum bemühen. Dort, wo es nicht klappt, ist es Aufgabe der Entwickler, die REQs einzufordern.
@ Jürgen N.N. >Die letzt geposteten Beiträge über mir widerlegen nicht meine Forderung >nach klaren Vorgaben. Jo. Das kann man nur unterstreichen. Erst recht für Software. Denn Software kann ALLES, wird aber NIE fertig!!! :-( >Und damit bleibt es bei der altem Situation, dass sicher 80%-90% der >gesamten Entwicklung in der SW (und auch HW?) chaotisch und impulsiv >erfolgt. HW ist genügsamer, da nicht so extrem flexibel und mal fix komplett umgebaut wie Software. Das bringt eine Dämpfung und Linearisierungs ins instabile System ;-) >> Kennst Du irgendeine Firma die es tatsächlich >> schafft, die Vorgaben (also Requirements) an die Software klar, >> vollständig, fehlerfrei und in sich konsistent zu halten? >Ich kenne einige, die sich darum bemühen. Dort, wo es nicht klappt, ist >es Aufgabe der Entwickler, die REQs einzufordern. Vor allem ist die Logik der meisten Poster unlogisch. Weil man keine Perfekten Requirements aufschreiben kann, lässt man es gleich ganz bleiben? Hä? Je komplexer das Projekt, umso nötiger ist eine möglichst klare, systematische Vorgehensweise. Dass die nie perfekt sein wird ist dabei nicht schlimm. Schlimm ist das Rumwurschteln und die Lernresistenz! Ein Fehler machen ist das eine, ihn mehrfach zu wiederholen ist das wahre Problem!
Falk Brunner schrieb: > Vor allem ist die Logik der meisten Poster unlogisch. Weil man keine > Perfekten Requirements aufschreiben kann, lässt man es gleich ganz > bleiben? Hä? Unverständlicherweise begegnet einem diese "Logik" an jeder Ecke. Die haben wir auch in der Firma. Es ist sozusagen die erste reflexartige Antwort "... man kann nie alles festlegen, weil sich immer was ändert". Dabei ändert "sich" nie etwas. Keine Anforderung tauscht sich selber weg. Es sind immer Personen, die Informationen in das System eintreiben und irgendwas geändert haben wollen. Meistens sind es denk- und arbeitsfaule Personen, die keine Lust haben, sich hinzusetzen und etwas zu 100% hinzuschreiben und vorher entsprechend zu denken. Sie hauen lieber schnell ein Powerpoint raus und schicken 20 Änderungen hinterher, statt sich - wie früher die Schriftsteller zu Schreibmaschinenzeiten - einen Satz vorher zu überlegen und ihn dann zu Papier zu bringen. > Je komplexer das Projekt, umso nötiger ist eine möglichst klare, > systematische Vorgehensweise. Dass die nie perfekt sein wird ist dabei > nicht schlimm. Schlimm ist das Rumwurschteln und die Lernresistenz! 100% d'accord! > Ein Fehler machen ist das eine, ihn mehrfach zu wiederholen ist das Es geht eigentlich garnicht um die Fehler, die man sich scheut hinzuschreiben. Sondern es geht darum, sie hingeschrieben zu haben und bei deren Korrektur auch die Änderungen in die Tiefe treiben zu können. Dazu müssen vorher die Abhängigkeiten auch definiert worden sein. Wenn man das immer macht, geht das auch rasch von der Hand. Zudem werden Änderungen und deren Auswirkungen evident und dann auch oft unterlassen, so wie die schnell reingestreuten Verbesserungen aus dem PM. Der Fehler der gemacht wird, ist, aus Angst vor unnötiger Arbeit, die Sache nicht sauber zu dokumentieren und Konzepte zu Ende zu formulieren und damit alles in die Tiefe zu treiben, weil man sich eine schlampige Daueränderungstechnik angewöhnt hat. Richtig dagegen wäre, mehr zu denken, mehr zu planen und dann zielführender in die Tiefe zu gehen, damit das gesamte Team besser zu steuern ist. Bei einer Maschine muss auch alles exakt mit einander verbunden sein, damit Steuerimpulse zu jederzeit erfolgen und Änderungen der Richtung möglich sind. Und: Es muss bekannt sein. Meistens ist es aber so, dass einige voranrennen, indirek etwas festlegen und dann versuchen, es zusammenzubringen. Und dann haben wir sie: Die sich selbst installierenden und unaufgefordert auftauchenden Änderungen, die keiner vorhersehen konnte. Ein ungesteuertes waberndes System! Und wenn Leute das nicht konsequent erlernt haben, nach Requirements zu arbeiten, kriegen sie es aus dem Stand auch nicht hin. Und dann bestätigt sich für sie, dass es so "länger und umständlicher" ist.
Das Fehlen an Planung und Requirements ist aber selten ein alleiniger Fehler der Entwickler: - Es werden Requirements vom Kunden akzeptiert (oder aus historischen Gründen mitgeschleppt) die technisch nicht sinnvoll realisierbar sind - Es werden Termine den Kunden versprochen ohne das überhaupt die Requirements des Kunden klar erfasst sind - Nicht selten setzen auch PM darauf als erstes bei Doku zu sparen wenn der Terminplan knapp ust Nur so als Beispiele...
Jubi schrieb: > Die gibt es vielleicht im Disneyland, aber nicht in der Realität! > Requirements kommen erstens immer viel zu spät und zweites ändern sie > sich dann noch mindesten drei mal. Genau so sieht's aus. Falk Brunner schrieb: > Vor allem ist die Logik der meisten Poster unlogisch. Weil man keine > Perfekten Requirements aufschreiben kann, lässt man es gleich ganz > bleiben? Hä? Hat doch gar niemand so behauptet! > Je komplexer das Projekt, umso nötiger ist eine möglichst klare, > systematische Vorgehensweise. Einverstanden. > Dass die nie perfekt sein wird ist dabei > nicht schlimm. Schlimm ist das Rumwurschteln und die Lernresistenz! Die Lernresistenz treffe ich zumindest in meinem Umfeld hauptsächlich bei den Projektmanagern an, weniger bei den Software-Entwicklern. > Ein Fehler machen ist das eine, ihn mehrfach zu wiederholen ist das > wahre Problem! Wem sagst Du das? Ich bin ja völlig mit Dir einverstanden in vielen Dingen. Nur gibt es eben viele Entscheidungen, die auf der Ebene der Entwickler und der Tester gar nicht getroffen werden können. hagbard schrieb: > Das Fehlen an Planung und Requirements ist aber selten ein alleiniger > Fehler der Entwickler: > > - Es werden Requirements vom Kunden akzeptiert (oder aus historischen > Gründen mitgeschleppt) die technisch nicht sinnvoll realisierbar sind Weil der Vertrieb keine Ahnung hat, gar nicht oder zu wenig mit der Entwicklung in Kontakt steht. > - Es werden Termine den Kunden versprochen ohne das überhaupt die > Requirements des Kunden klar erfasst sind Exakt. > - Nicht selten setzen auch PM darauf als erstes bei Doku zu sparen wenn > der Terminplan knapp ust Das erlebe ich andauernd. Da heißt es dann "Ja eigentlich müssten wir das und das noch machen, aber uns läuft die Zeit davon und wir müssen fertig werden, also machen wir nur das Nötigste und Dringendste..." :-(
Bei mir herrscht ständig Unterdruck. Ihr müsst was falsch machen.
topstory schrieb: > Bei mir herrscht ständig Unterdruck. Ihr müsst was falsch machen. Bist du vielleicht im Arbeitnehmer-Disneyland? Das wäre eine Erklärung.
Druck habe ich nur auf´m Pott. Ganz ehrlich: "Druck" gehört doch dazu, das sollte man einfach nicht so ernst nehmen. Viele Dinge im (Berufs-)leben kann man relativ einfach durchschauen, gerade auch zwischenmenschliche Verhaltensweisen. So lebt es sich recht entspannt.
also ehrlich:
Entweder hier empfinden einige normale Arbeit, als Überlastung oder sie
sind in einer XXX-Firma. Ich kenne keinen SW-Entwickler, der sich kaputt
macht. Von einigen japanischen Firmen in Deutschland hört man seltsame
Sachen, aber deren Problem ist, dass sie nur billige Dödelprogrammierer
einstellen, die so arbeiten, wie oben angedeutet und dann ständig am
Wühlen sind und ihre Arbeit nicht fertig kriegen ("siehe 3h suchen am
flag"). Die Sorte hat dann logischwerweise Druck.
Ich für meinen Teil haben keinen Druck. Ich arbeite azyklisch zu den
anderen Kollegen, die meistens schon um 7.00 auf der Arbeit sind, damit
sie sich gegen 16.00 in den Feierabendverkehr stürzen können :-)
Den Stress spare ich mir und fahre frühestens um 8.30 morgens los, wenn
der grosse Schwung der Karossen schon durch ist und trudele nicht vor
9.00 im Büro ein. Statt 20min Strafzeit im Stadtverkehr, die meine
Kollegen, die 2h früher anrücken, auf den letzten Zufahrtstrassen von
der BAB zur Firma brauchen, sause ich in weniger als 10min durch und
spare täglich 20min. Dann lasse ich noch das "2. Frühstück" ausfallen
und bin wieder 30min näher dran. Ich verschwinde dann frühestens um
18.00, meistens um 19.00 und bin dann ruckzucki daheim. Weniger Benzin,
weniger Stress und vor allem keine Morgenhektik und 2 erholsame leise
Stunden abends, mit leerem Büro und herrlichen Surfmöglichkeiten.
Ich habe nur das Zeitfenster zwischen 14.00 und 16.00, wo ích voll
ranklotzen muss, ansonsten ist lockeres Kaffetrinken und warten auf den
Compiler angesagt.
Wer sich Stress und Druck machen lässt, hat den falschen Job.
>und warten auf den Compiler angesagt.
Wenn das machst du während dieser Zeit Wartung.
Mh also bei uns in der Firma scheint jeder (inkl. mir) ziemlich entspannt. Ja zu Milestones oder ähnlichen Terminen wirds mal weng stressiger und ein paar Überstunden fallen an, aber die landen auf dem Gleitzeitkonto und werden abgebummelt. Ich selber bin in einem 7-Kopf Team und wir arbeiten nach Scrum an einem mehrjährigen ~100-Mann Projekt für einen Kunden. Funktioniert meiner Meinung nach wunderbar. Ich bin zufrienden, die Kollegen sind zufrieden, der Projektleiter ist zufrieden, der Chef ist zufrieden und der Kunde ist zufrieden. Gefühlt würde ich sagen, dass Scrum auf den ersten Blick schon etwas teurer ist als "klassische" Entwicklung. Andererseits, für jeden ist transparent an was gerade gearbeitet wird und das an nichts rumgenudelt wird was nicht vereinbart war. Wir arbeiten in 3 Wochen Sprints und die sehen in etwa so aus: 1. Woche: - reine Abarbeitungszeit der User Stories (Arbeitspakete) - keine planmäßigen Meetings bzgl. Scrum, Meetings nur nötig wenn sich mit den Projektarchitekten abgestimmt werden muss 2. Woche: - Mittwoch 2 Stunden Grooming, dort gehen wir das Product Back Log durch in dem die User Stories festgehalten sind, was der Kunde sich in den nächsten Wochen so wünscht. Unklar spezifizierte Beschreibungen oder Akzeptanzkriterien klärt unser Projektleiter. Darüberhinaus haben wir Entwickler immer den Überblick was demnächst so kommt. Jeder Entwickler bekommt 1-2 Arbeitspakete zugewiesen (je nach Komplexität), die er schonmal grob vorplant wie man diese lösen könnte sobald der Projektleiter die Unklarheiten beseitigt hat. Zeitaufwand dafür 1-2h. - Restliche Zeit ist wieder reine Abarbeitungszeit - Freitags holt der Integrator den Main-Branch für eine Forward Integration um unseren Team-Branch auf den neuesten Stand zu bringen und für eine Reverse Integration am Montag vorzubereiten. Das geht manchmal zügig und manchmal ist es ein ewiges gemerge, jenachdem wieviel Reibungspunkte man mit anderen Teams und deren Bundles hatte. 3. Woche: - Montags ist die Reverse Integration in der unsere Arbeit in den Main-Branch integriert wird. Während unser Integrator das erledigt, zieht der Rest die EA-Diagramme / Dokumentation unserer Arbeit auf einen aktuellen Stand - Dienstag ist Abnahmemeeting, das dauert normalerweise nen halben Tag. Dort gehen wir mit dem Kunden Paket für Paket durch und lassen ihn die Ergebnisse anhand der Akzeptanzkriteren verifizieren und abnehmen. - Mittwoch 1-2h Retrospektive Meeting, dort diskutieren wir teamintern was gut und was schlecht lief im letzten Sprint und wo man was verbessern kann. Danach machen wir noch mittwochs unser Planungsmeeting, welches üblicherweise 5-6h geht. Dort werden die Vorplanungen der einzelnen Pakete vorgestellt und in einzelne Tasks überführt, darüberhinaus wird die Komplexität / der Zeitaufwand für jedes Paket geschätzt und anhanddessen treffen wir die Zusagen für den Kunden was möglich ist abzuarbeiten. Am Ende weiß jeder im Team was zu tun ist und prinzipiell auch wie, d.h. Krankheit eines Kollegen etc. fällt kaum ins Gewicht. Nicht eingecheckter Code landet am Ende des Tages in einem Shelveset, welches sich ein anderer reinziehen kann. - Ab Do wieder Abarbeitung der Pakete Es gibt projektweite Coding-Guidelines und teamintern halten wir uns an Clean-Code. Code darf in unserem Umfeld nur nach einem 4-Eye Review eingecheckt werden, Hazard-relevanter Code nur nach einem 6-Eye Review. So läuft es in dem Team in dem ich arbeite. Nicht jedes Team in unserer Firma kann agil arbeiten (hängt immer vom Kunden etc. ab), der Grundtenor wenn man sich am Mittagstisch austauscht ist jedoch, dass es in agilen Teams meist kontrollierter und fokussierter abläuft als in den nicht-agilen. Für mich persönlich kann ich nur sagen, dass die Meetings manchmal nerven aber andererseits erfüllen sie ihren Zweck und kosten nicht sinnlose Zeit. Ansonsten kann ich über meine tägliche Arbeit nichts negatives berichten. Meine Firma ist ein reines Softwarehaus (KMU ~200 Mann, Mitarbeiter-AG) und wir wickeln halt Kundenprojekte ab. Ich finds ganz nett, da man so die Möglichkeit hat in unterschiedliche Technologien abzutauchen wenn man was frisches machen will, da wir Know-How-bezogen breit aufgestellt sind, Themenwechsel sind meist kein Problem. Was ich hier manchmal über Softwareentwickler/-ung lese würde mir angst und bange machen. Das fiele für mich in den Bereich Folter und unprofessionelle Fricklerei. Hängt wohl wirklich stark davon ab, wie die Software im Gesamtkontext eines Produkts eingeordnet wird.
Matthias Lipinsky schrieb: >>und warten auf den Compiler angesagt. > > Wenn das machst du während dieser Zeit Wartung. Komisch sein Satz Deiner. Deutsch schreiben können Du? D. I. schrieb: > Hängt wohl wirklich stark davon ab, wie die > Software im Gesamtkontext eines Produkts eingeordnet wird. Das glaube ich aber auch. In kleinen Softwareklitschen, die Aufträge abarbeiten, schlägt die Zeit voll durch. Ist die SW nur eine kleine Teilkomponente und macht nicht viel aus, kann man sich Bummelei leisten. Komischerweise wird aber dort eher noch linear gearbeitet, als in der Dienstleisterklitsche, die drücken und nur das Nötigste machen.
>Matthias Lipinsky schrieb: >und warten auf den Compiler angesagt. >Wenn das machst du während dieser Zeit >Wartung >>Komisch sein Satz Deiner. Deutsch >>schreiben können Du? Beruhige dich mal. ich hasse diese pseudointelligenz von auto vervollständigen. .... der Satz soll heißen: wenn dann machst du während dieser Zeit Wartung. ..
Matthias Lipinsky schrieb: > wenn dann machst du während dieser Zeit Wartung. .. Wenn Du richtig schreiben würdest, könnte man den Satz auch mit einem kleinen Vertipper noch lessen. Ich hätte ihn auch nicht verstanden... -> wenn - dann machtest Du während dieser Zeit Wartung wäre korrekt gewesen.
Matthias Lipinsky schrieb: >>machtest > > Ok. Wieder ein neues Wort gelernt. Gerne doch. Für alle jene, die des gehobenen Deutschen weniger kundig sind: "Machtest" ist die etwas elegantere Form von "würdest machen", welche alternativ Verwendung hätte finden können, die aus inhaltlichen Gründen an dieser Stelle aber eher "würdest gemacht haben" zu verwenden gewesen waäre, weil im obigen Satzzusammenhang formell und inhaltlich ja der Konjunktiv, also eine Möglichkeitsform der Tenor ist.
@ Matthias Lipinsky (lippy) >>machtest >Ok. Wieder ein neues Wort gelernt. kommt das von Gemächt? SCNR
>kommt das von Gemächt?
Bildung kommt auch nicht vom Lesen. Dann hieße es Buchung. Bildung kommt
von Einbildung.
als ich neu in der firma war, hab ich die stresserei auch viel zu ernst genommen. "wenn fehler xy nicht heute gefixt wird, steht morgen der ganze betrieb" "feature xy muss bis morgen drinnen sein, sonst müssen wir pönale zahlen" ... und meine antwort war "ja klar, das ist machbar, ja klar, das mach ich schon, ..." irgendwann war der punkt erreicht, an dem ich wirklich viel fachwissen hatte, und in einigen wichtigen codeteilen der einzige war, der wirklich durchsteigt. ich hab gesehen, dass ich mit meinem jetzigen fachwissen locker einen anderen job bekommen würde. und seitdem ist mir das gerede relativ egal. die chefs und projektleiter sind doch ohnehin auf uns entwickler angewiesen. wenn jetzt wer herkommt und sagt er braucht aufgabe xy, so zeige ich ihm meine derzeitigen aufgaben, und sage ihm wann ich mit dem feature anfangen kann. meistens frühestens eine woche später. dann sind sie erstmal ganz nervös, weil der kunde das ja schon so dringend braucht. meine antwort: "kannst ja mit dem chef reden ob ich die aufgabe vorziehen soll, nur dann bleibt halt die derzeitige aufgabe liegen". das wars dann meist auch schon, weil die aufgabe eh nicht so wichtig ist. und wenn ich es dann 2 wochen später abgebe, so ist es interessanterweise meist eh gar nicht so wichtig gewesen. "von was redest du? ah, von der aufgabe. ja, das ist jetzt eh nicht so kritisch". also mein tipp: 1. schau dass du fachlich gut bist 2. schau dass du know how hast, dass dich auch für andere firmen interessant macht 3. merk dir, dass projektleiter und chefs ohne dich nicht können 4. erklär ihnen deinen terminplan, und dass du für ihre aufgabe erst am tag xy zeit haben wirst, sie aber mit dem chef gerne eine terminverschiebung besprechen können 5. interessante aufgaben kannst du natürlich sofort nach vorne schieben
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.