Domino 9 und frühere Versionen > ND6: Entwicklung

Anonymer Autor?

<< < (3/4) > >>

Semeaphoros:
Danke ...  :D

Ich bin tatsächlich am Ueberlegen, wo man was (natürlich wohlformuliert) publizieren könnte, bin mir aber noch nicht so ganz schlüssig, ausserdem brauch ich noch ein bisschen mehr Infos für einen guten Artikel.

Axel Janssen temp:
Garantiert nicht böse, sondern humorvoll gemeint

Man sollte mal eine "zoologische" Beschreibung von Software-Projekt-Consulting Kunden schreiben.

Typ A: Juchu. ich bin irgendwie Management.  
"Ich hab zwar keine technische Ahnung aber Budget"
Merkmale:

Kümmern sich nicht um so Details wie Programmiersprachen, Compiler, Server oder ähnlichen Tüdelskram. Kennen sich aber gut mit Computern aus. Schließlich haben sie in ihrer Uni eine Internet-Schulung besucht und sämtliche Uni-Arbeiten auf MS-Word und Powerpoint geschrieben. Ausserdem hatte er/sie auch mal einen Semesterferienjob, wo Excel-Makros geschrieben wurden.

Software-Architektur ist etwas für Spinner. Sie wollen auf jeden Fall damit verschont werden. Die extremst-super-spezielle Situation der IT ihres Unternehmens kann mit solchen generalistischen Ansätzen sowieso nicht abgedeckt werden. Dafür braucht es schon hartgesottenere Typen. Solche nämlich, die die IT ihres Unternehmens immer super-spezieller machen.

Neigen dazu auf schwachsinnige Requirements zu beharren, die zwar nicht unbedingt logisch sind, aber die sie irgendwie kreativ finden. Also quasi ihre persönliche Duftnote in der IT-Landschaft des Unternehmens. Diese Requirements nehmen dann 80% der Kosten in Anspruch und machen spätere Änderungen um den Faktor 4 teurer. Das ist aber nicht so schlimm.

Halten Software-Leute für 120% verlogen. Glauben denen kein Wort. Niemals.

In der Frühphase ihrer Karriere beharren sie auf Dokumentation der Grösse des Himalayas. Später lernen sie, dass diese Dokumentation nichts bringt, und wollen überhaupt keine Dokumentation mehr. Zwar gibt es in den Beauftragungen immer den Punkt Dokumentation 4 Tage. Sie haben aber gelernt, dass gerade dieser Posten mit der Consulting prima gegen Requirements getauscht werden kann, die ihnen erst während des Projekts eingefallen sind. Und dieses Postengeschiebe muß nicht mal intern besprochen werden. Genial.
 

Typ B: Software-Entwicklung ist geil, aber auf Kundenseite ist es doch schöner:
"Geht das nicht auch mit xml?"

- Sind bereit für Projekte mit brandneuer, nicht-funktionierender hype-Software viel Geld auszugeben, auch wenn das für das Unternehmen eigentlich nix bringt.
Ihnen gehts eben mehr um den kick von nicht sauber implementierten beta-Produkten und humboldinische Bewußtseinserweiterung in ihrem Lieblingsbereich.  

- Erwarten irgendwann in der Mitte eine gute Präsentation vor der Geschäftsführung. Am Ende scheitert das Projekt sowieso, aber in der Mitte können sie Punkte sammeln.

- Programmieren teilweise Stücke selbst, wenn die Zeit knapp wird. Finden im code des Entwicklers eine Menge an schlechten code. Sind dabei aber meist fair. Wollen es nur angemerkt haben.

- V.a. gegen Ende des Projekts werden dort bedenkenlos Nachtsitzungen geschoben, an denen sie selber teilnehmen.

Gruß Axel

Semeaphoros:
Vor mehr als 10 Jahren, potentieller Kunde von mir, Besitzer einer Druckerei:


".... ich will die und die Lösung ......... und es muss in C programmiert sein ....."

... was weder sinnvoll noch in meinem Sinne war ... :-)

Ich fragte ihn dann:

"Was meinen Sie zu einer Anfrage für Briefpapier, wenn der potentielle Kunde am Schluss sagt: '... aber die Sache muss unbedingt auf der Linotype 1020xyz pipapo gedruckt werden ...' .... haben Sie nicht das Gefühl, dass Sie als Drucker eigentlich besser wissen müssten, welches die bestgeeignete Maschine und das beste Verfahren für diese Drucksachen sein sollten? ......"


... soviel zu "... und könnte man das nicht auch in XML machen?"

qu1cke:
Das ist genau die leidige Diskussion, die ich hier vermeiden wollte. Kurzum: Ich habe lediglich wissen wollen, ob jemand vielleicht eine Idee hat, wie man das Problem gekonnt umschiffen kann. Wir wollen nicht wegen einer kleinen Sache, die so schon so gut wie fertig ist, eine Consulting-Firma beschäftigen.

Wir machen solange es geht, in Richting Notes/Domino alles alleine, um uns schlichtweg nicht von anderen Dienstleistern/Consultingfirmen abhängig zu machen, was nicht heißt, daß wir kein Vertrauen in deren Kompetenz haben, oder es uns (selbstverständlich nach Kosten-Nutzen-Schätzung) nicht leisten könnten.

BTW: Unser Haus beschäftigt als kleine Privatbank etwa 600 Mitarbeiter weltweit, davon ca. 1/5 im IT-Bereich, wir haben Kompetenzen in allen möglichen Bereichen der Anwendungsentwicklung und entwickeln so fast alle von uns benötigten Clearing- und Verwaltungssysteme sowie Teile einer einzigartigen Fondshandelsplattform selbst. Die IT wird als wesentlicher Bestandteil eines funktionierenden Geschäftsbetriebes angesehen und so gehen auch die jählichen Investitionen zum großen Teil in diesen Bereich.

Also: es ist doch möglich, daß eine Bank kapiert, wie wichtig die IT für sie selbst sein kann...

Grüße
René

Semeaphoros:
Klassische "Make or buy" Problematik. Alles ausserhalb des Kerngeschäftes selber machen zu wollen, ist meistens keine gute Idee, und doch erleben wir genau das im Moment. Gegen Abhängigkeit kann man sich gerade in dieser Situation absichern, indem man - extrem gesagt - Know how einkauft statt Produkte, das verhindert, dass man alles selber erfinden muss. Der richtige Mix ist der kritische Punkt. Und klar, das wollte ich unbedingt auch noch sagen, das Problem liegt sicher nicht bei Dir, das sind Sachen die auf Ebene der Geschäftsleitung und so ihren Ursprung haben. Und das speziell merkwürdige bei den Banken (sicher nicht bei allen und gerade die kleineren Banken haben das Problem besser erkannt als die Grossen), dass das Abbauen von Kompetenzen eben gerade auch im Kernkompetenzbereich passiert. Kunststück, wenn gewisse Manager am Schluss für ihren Abgang dann auch noch vergoldet werden. Langfristig zerbricht das Sozialgefüge ...... alles schon ein paarmal in der Geschichte dagewesen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete