SpaceX vs Boeing

[HausD]

... erlaube ich mir nochmal das NASA Dokument vom November zu verlinken. ...

Und ich erlaube mir den Link zu reparieren:
https://oig.nasa.gov/docs/IG-20-005.pdf

Jetzt herunterladbar ... Gruß, HausD

[MillenniumPilot]

... erlaube ich mir nochmal das NASA Dokument vom November zu verlinken. ...

Und ich erlaube mir den Link zu reparieren:
https://oig.nasa.gov/docs/IG-20-005.pdf

Jetzt herunterladbar ... Gruß, HausD

Entschuldigung und danke. 

[FlyRider]

Der Film dreht sich ziemlich genau um die SpaceX vs. Boeing Geschichte. Deshalb dachte ich, das passt ganz gut hier rein. Zudem ist die Doku durchaus sehenswert.


https://www.youtube.com/watch?v=nnewZrf7v5U

[jdark]

Wahnsinn...SpaceX (in dem Kontext darf das erwähnt werden, vermute, hoffe ich) Software Ingenieur Jinnah Hosein übernimmt die Softwareentwicklung-Abteilung von Boeing:
https://www.golem.de/news/sicherheit-spacex-entwickler-soll-boeings-softwareprobleme-loesen-2011-151956.html

Die Flugzeug Problematik außer Acht gelassen, die Starliner Software soll auch von ihm betreut werden. Dabei fällt das Wort "Zentralisierung". Und das dürfte wohl schwieriger werden als getesteten Code einzuführen.

[McPhönix]

Hmmm... Was bringt einen gestandenen Fachmann dazu, von SpaceX wegzugehen ?
Wie stehts mit "Risiken und Nebenwirkungen"? Wie verhindert man den Transfer von Kenntnissen, die an dem bzw. durch den von Spacex bezahlten Arbeitsplatz erworben wurden?
(PS: In welchem Thread wäre die Frage evtl. besser aufgehoben?)

[TWiX]

Wahnsinn...SpaceX (in dem Kontext darf das erwähnt werden, vermute, hoffe ich) Software Ingenieur Jinnah Hosein übernimmt die Softwareentwicklung-Abteilung von Boeing:
https://www.golem.de/news/sicherheit-spacex-entwickler-soll-boeings-softwareprobleme-loesen-2011-151956.html

Ich finde, es sollte nicht unerwähnt bleiben, dass besagter Software-Ingenieur kein X-Beliebiger ist, sondern die Softwareentwicklung bei Falcon 9, Falcon Heavy CargoDragon und CrewDragon innehatte. Boeing hat sich also endlich jemanden geholt, der Erfahrung damit hat, eine Kapsel zum Fliegen zu bringen
 Quelle

[alepu]

Hmmm... Was bringt einen gestandenen Fachmann dazu, von SpaceX wegzugehen ?
Wie stehts mit "Risiken und Nebenwirkungen"? Wie verhindert man den Transfer von Kenntnissen, die an dem bzw. durch den von Spacex bezahlten Arbeitsplatz erworben wurden?
(PS: In welchem Thread wäre die Frage evtl. besser aufgehoben?)

In den USA ist es, im gegensatz zu uns, durchaus üblich alle paar Jahre den Arbeitsplatz zu wechseln.
Zahlreiche Beschäftigte bei SX werden nur *auf Zeit* angestellt.
EM Führungstil ist nicht jedermanns Sache.
Von BO ist es z.B. bekannt, daß wiederholt hochrangige Mitarbeiter mit dem Angebot von sehr hoher Bezahlung gezielt abgeworben wurden.

[MoonSeeker]

Die Frage ist ja auch, wie lange er dort bleibt und was er wirklich bewirken kann.
Wenn man agiles Arbeiten nach "eigenem Gusto" und viel Selbstverantwortung gewohnt ist und dann z.B. auf einmal in so einen trägen Prozess nach Wasserfallmodell gepresst wird, kann das sehr schnell sehr frustrierend werden.

Für Starliner wird der dort meiner Meinung nach ohnehin nicht mehr viel bewegen können: die Software steht und vorallem die Prozesse stehen!
Denn auch hier (oder gerade bei Boing) gilt Conway's law.

Er ist Boing hingegen sehr nützlich für neue Projekte, eventuell auch mit veränderter Personal- bzw. Führungsstruktur.

[alepu]

Möglicherweise steht die software ja doch noch nicht so ganz und sie haben evtl. sogar erhebliche Probleme damit und versuchen nun krampfhaft und *mit allen mitteln* dahinterzukommen wie zum Teufel SX das so toll hingekriegt hat! 
Und möglicherweise hat ja auch Jim Bridenstein seinen Freund EM gebeten den Freunden von Boeing etwas unter die Arme zu greifen, weil die das alleine nicht hinbekommen.
(Für die, die das jetzt wieder nicht so ganz erkennen, ist ironisch gemeint  )

[FlyRider]

Für mich ein eher seltsamer Zug. Wenn ich jemanden sooo spät in ein komplexes und überaus kritisches Softwareprojekt hole, dann ist das entweder eine Investition in die Zukunft und hat mit dem Projekt evtl. gar nicht so viel zu tun, oder ein Eingeständnis, dass man lieber noch mal neu anfangen sollte. Auch in der Softwareentwicklung kann man schlechtes Design nicht einfach mal so beheben. Und Prozesse in Unternehmen zu ändern, geht schon gar nicht von jetzt auf gleich.
 

[Kelvin]

Für mich ein eher seltsamer Zug. Wenn ich jemanden sooo spät in ein komplexes und überaus kritisches Softwareprojekt hole, dann ist das entweder eine Investition in die Zukunft und hat mit dem Projekt evtl. gar nicht so viel zu tun, oder ein Eingeständnis, dass man lieber noch mal neu anfangen sollte. Auch in der Softwareentwicklung kann man schlechtes Design nicht einfach mal so beheben. Und Prozesse in Unternehmen zu ändern, geht schon gar nicht von jetzt auf gleich.

Das sehe ich genau so. Aber auch das bedeutet nicht, daß es die Entscheider auch so sehen.   (Oder einfach keine bessere Lösung haben.)