Voraussetzung und Kriterien für DB-Entwicklung

[theBastian]

Hallo,

ich wende mich mal an alle Entwickler, die sowas nicht als Fulltimejob warnehmen sondern eine Kombination aus Admin und Entwickler sind.

In Anlehnung an diesen Thread
http://www.atnotes.de/index.php?topic=8567.0
stehe ich auch vor dem genannten Problem. 
Im Prinzip haben jetzt alle Notes als Medium entdeckt und decken mich mit Anforderungen nach DBs ein.

Wie händelt ihr Anfragen die von Mitarbeitern kommen?
Nach welchen Kriterien entscheidet ihr, ob die Entwicklung überhaupt sinnvoll ist?
Welche Voraussetzungen erwartet ihr von den Mitarbeitern der Fachabteilung?

Danke schonmal im voraus für Eure Hilfe.

cu
Sebastian

[koehlerbv]

Das ist ein schwieriges (und eigentlich doch scheinbar einfaches) Kapitel, Andreas.
Auch wenn ich hier nicht mitspielen darf wegen

ich wende mich mal an alle Entwickler, die sowas nicht als Fulltimejob warnehmen sondern eine Kombination aus Admin und Entwickler sind.

wage ich mal einen Kommentar aus meiner Sicht:

Wenn die Anwender weitere DBs (oder Applikationen) verlangen, ist dies ein sehr positives Zeichen. Bei allen kaufmännischen Überlegungen sollte man dies nicht ausser acht lassen !

An sich ist ansonsten die Entscheidung scheinbar ganz einfach:
- Was bringt eine Applikation an Gewinn (hier ist auch ideeler Gewinn wie Motivation, Zufriedenheit etc. einzubeziehen)
- Was kostet die Erstellung dieser Applikation ?
- Welches Know-How ist inder Fachabteilung vorhanden ? Gibt es externe Ressourcen, die entweder die Applikation komplett programmieren oder beratend zur Seite stehen oder bei der Gelegenheit das interne Know-How durch ein Training-on-the-job anheben ?

Für ganz wichtig erachte ich zwei Punkte:
Die interne realistische Selbsteinschätzung und damit verbunden die Bereitschaft, auch Hilfe ggf. von aussen in Anspruch zu nehmen. Dieses sollte wenn irgendwie machbar immer verbunden sein mit der Option, dabei internes Know-How dazuzugewinnen (das kostet beim ersten Mal wohl mehr Geld, spart aber dann gewaltig, wenn man das richtig aufsetzt).
Und: Die Abschätzung der Konsequenzen einer neuen Applikation. Es kann sich hieraus eine endlose Spirale weiterer Anforderungen ergeben, die dann ggf. in der Frustration beider Seiten (Fachabteilung, Anwender) mündet.

Für mich sind die Kernpunkte: Selbsteinschätzung, Folgenabschätzung, Einbeziehung externer Partner mit maximalen Know-How-Abgriff.

Soweit meine 2 ct.

Bernhard

[TMC]

Wichtig finde ich noch:
- Wie integriert sich die Anforderung in die bestehende IT-Landschaft
- Wie vereinbart sich die Anforderung mit den mittel- bis langfristigen IT-Zielen

Auch die Frage: Warum in Notes? Ich habe in der Vergangenheit oft Anforderungen bekommen, die zwar in Notes umsetzbar sind, aber vielleicht andere Systeme einfach besser geeignet sind.
Es müssen also auch andere Systeme einbezogen werden, insbesondere das ERP-System.
Die IT-Ziele sind auch sehr wichtig. Was hilft es, wenn Du heute eine Anforderung bekommst, wenn z.B. ein Einkäufer seine Lieferanten-Kontakte in Notes verwalten möchte, weil das heute im ERP-System nicht geht, aber z.B. das ERP-System in 6 Monaten upgegraded wird und es dort evtl. eine solche Funktionalität gibt?

Es gibt sicherlich noch eine Reihe an weiteren Tipps, aber dazu müsste man Eure IT-Infrastruktur und Details zu Eurem Unternehmen kennen.

[koehlerbv]

Volle Zustimmung, Matthias. Vielleicht könnte man die Liste daher noch ergänzen um folgenden Punkt (obwohl es das jetzt für Sebastian nochmals schwieriger, aber für das Unternehmen sicher lukrativer macht):

Wie können sich die bestehenden Systeme ergänzen ? ERP beherrscht keine dokumentorientierte Verwaltung - das ist aber die Stärke von Notes. Notes gleicht "Stammdaten" mit ERP ab, auf dieser Basis können "weiche Daten" in Notes erfasst werden. Deren Existenz (aber nicht deren Inhalt) werden dann wieer im ERP abgebildet.

Nur so als Beispiel ... Wegen ihres stringenten Verfahrens der Datenhaltung sollten aus meiner Erfahrung ERP-Systeme dann immer das führende System sein.

Bernhard

[Marinero Atlántico]

Das ist eine Frage, für die es weder eine einfache Antwort noch einen simplen Prozess gibt.
Die User müssen ja mit dem System arbeiten, also sollen sie auch Vorschläge machen dürfen, zumal sie den Gegenstand, den das System abbildet (ihre Arbeit), besser kennen.
User sehen aber bestimmte Dinge nicht.
Setzt man deren Anforderungen unkritisch auf Zuruf um, endet das System leicht im Chaos.
Was User nicht sehen, sind viele der Auswirkungen ihrer Anforderungen auf die sogenannten nicht-funktionalen Anforderungen des Gesamtsystems:
(alles ausser die Use-Cases:)
Anpassbarkeit in der Zukunft
Allgemeine Logische Kohärenz
Übersichtlichkeit
Konfigurierbarkeit
Performance
Fehler-Robustheit
Wiederherstellbarkeit im Fehlerfall
und einiges mehr.

Systeme, in denen unkritisch auf Zuruf gearbeitet wird, weisen immer Schwächen hinsichtlich der Umsetzung der nicht-funktionalen Anforderungen auf. 

[Roalf]

Klassische Dialoge: Fachabteilung/Notesverantwortlicher


Fachabtlng. =  "wir brauchen nur eine kleine Anwendung um dies und das zu machen...ganz einfach, ganz simpel"

Notesverantwortlicher = "och dann mach ich eben schnell dies und das.....und dann sind sie glücklich"

Ergebnis = Wenn diese Anwendung nur halbwegs was taugt, will die Fachabteilung bald mehr und mehr in dieser Anwendung.
Und wenn’s schnell und einfach zu programmieren war, natürlich das zukünftige auch  so schnell.....
Nach einem halben Jahr ist die Frage "Was,  für das bisschen brauchen sie auf einmal soooo lange?" so sicher wie der nächste Steuerbescheid.

Anm: Abteilungsleiter schaffen es dann tatsächlich das "so" mit 4 o zu sprechen.

 ---------------


Fachabtlng. =  "diese Daten brauchen NUR wir und zwar NUR für....."

Notesverantwortlicher = "och dann mach ich eben was ganz spezielles...."

Ergebnis = Nach nur wenigen Wochen stellt jemand fest, dass Schnittstellen zu dieser und jener Datenbank auch ganz nett wären. Auf den zarten Hinweis des Notesverantwortlichen, dass man das hätte vorher bedenken sollen, gibt’s dann die vorwurfsvolle Frage "Und warum haben sie uns nicht darauf hingewiesen?"

-----------

Fachabtlng. =  "wir brauchen das gaaanz Dringend!!.....")
Anm: Auch 4 a sind für Abteilungsleiter kein Prob.


Notesverantwortlicher = "na dann wird das Priorität haben...."

Ergebnis = Der Abteilungsleiter hatte gehofft , damit einige Dinge besser regeln zu können. Hat sich aber als Irrtum rausgestellt, weil es da noch so ein Produkt gibt, was der neue Assistent danach vorgestellt hat, was alles viel besser kann.....Nun nutzt das Dingen kein Schwein  (bis auf die verknöcherte Sekretärin) .  Aber wehe es wird abgeschaltet weil ja eigentlich zwei redundante Systeme.......

-----------

Fazit:
Jede Fachabteilung hat nur den Tellerrand ihrer eigenen IT-Bedürfnisse im Auge.  Das ist auch Gut und Richtig so, dafür werden sie bezahlt. Aber wenn da niemand aufpasst, endet es so, wie ich schon oft bei Firmen erlebt habe: mehrere Abteilungen, jede hat für ein und die gleiche Aufgabe ein anderes System (Die einen haben dafür eine Access-DB, die anderen Notes und die Dritten pflegen diese Daten mit Excel, je nach dem womit der AL besser klar kommt).
Und keine der Abteilungsinsel hat eine Schnittselle zu irgendwas anderes...

Wenn also eine Abteilung auf den Notesverantwortlichen zukommt und eine Anforderung hat....liegt schon was prinzipiell im Argen. Eigentlich müsste der Verantwortliche gemäß der IT auf die AL zukommen und sagen "ihr schaltet nun die Excel-Tabellen ab , weil hier habe ich (Access, ERP-Modul, eine Notes-DB....).

Ein Notesverantwortlicher der diese Möglichkeit nicht hat und nur Wasserträger für die Abteilungen ist, braucht eine ganz besondere Fähigkeit -> unbegrenzte Leidensfähigkeit, den er ist immer der Dumme und zwar unabhängig davon wie gut er ist. 

Wenn jemand eine Abteilung fragt, warum denn das und das nicht geliefert wurde oder dies und das in die Hose gegangen ist....ist die Ausrede "unbrauchbare Software" schnell bei der Hand, weil keiner blickt was den nun so „unbrauchbar“ ist, keiner will sich mit Unwissenheit über IT blamieren. Und wenn man dieses auch noch mit einem Namen (der des Notesfrikels) verbinden kann....interessiert niemanden mehr wie genial das im inneren auch programmiert sein mag....

Oder anders: ein Notesverantwortlicher braucht keine guten Programmierkenntnisse, schweres kann er zu Not außer Haus geben. Er braucht aber Übersicht, Durchsetzungswille und Rückrad. Ohne das ist er Kandidat für ein Magengeschwür......

[theBastian]

Moin,

erst mal vielen Dank für Eure vielen Infos.

@Bernhard

Auch wenn ich hier nicht mitspielen darf ...

War natürlich so nicht gemeint. Bin für jede Hilfe dankbar. 

Für mich sind die Kernpunkte: Selbsteinschätzung, Folgenabschätzung, Einbeziehung externer Partner mit maximalen Know-How-Abgriff.

Das sind so die Voraussetzungen, die ich erfüllen sollte, mal abgesehen von den externen Partner (da kommt dann der AL ins Spiel).
Folgenabschätzung kann man von der Fachabteilung nicht erwarten. Mir gehts aber eher um die User-Seite. Wenn die kommen und sagen, "Ich will eine DB.", dann will ich nicht einfach loslegen und dann vielleicht 3x neu anfangen, weil es so nicht gewünscht ist oder nicht geht oder, oder, oder.

@Marinera Atlántico

Die User müssen ja mit dem System arbeiten, also sollen sie auch Vorschläge machen dürfen, zumal sie den Gegenstand, den das System abbildet (ihre Arbeit), besser kennen.

Genauso sehe ich das eigentlich auch, denn ich kann und will nicht für die User denken und ihnen vielleicht auch noch einen Workflow aufdrücken, der sich vielleicht komplett von dem bisherigen unterscheidet.

Aber wie detailliert laßt ihr euch die Vorgaben stecken?

• Welche Daten sollen eingegeben werden?
• Was soll rauskommen?
• Wie sollen die Forms aussehen?
• Welche Views sind gewünscht?
• Pflichtenheft?
• Im- und Export?

@Roalf
Deine Dialoge spiegeln meine bisherige Arbeit wider. 

Wenn also eine Abteilung auf den Notesverantwortlichen zukommt und eine Anforderung hat....liegt schon was prinzipiell im Argen. Eigentlich müsste der Verantwortliche gemäß der IT auf die AL zukommen und sagen "ihr schaltet nun die Excel-Tabellen ab , weil hier habe ich (Access, ERP-Modul, eine Notes-DB....).

Keine Chance. Kann ich nicht bringen. Da laufen die wichtigen Fachabteilungen sofort zum Vorstand und "können nicht arbeiten, sind von der EDV eingeschränkt usw."

cu
Sebastian

[theBastian]

Hallo,

leider bin ich mit meinem Problem noch nicht weiter gekommen. 

Ihr als Profi-Programmierer habt doch sicher Vorlagen, die das enthalten, was Ihr von Eurem Auftraggebern abverlangt, wenn es um die Erstellung einer DB geht.

Bin für jede Info dankbar.

cu
Sebastian

[Mark³]

Es gibt hierfür verschiedene Vorgehensweisen. Die eine ist, alles genau zu dokumentieren und 50% des Aufwands in das Produzieren von Pflichten- und Lastenheften zu stecken, die wochenlang mit dem Kunden abgesteckt werden und sich ständig ändern.
Der andere Weg ist, grob die Anforderungen abzuklären und einen Prototyp zu basteln, der so ungefähr die Funktionalität beinhaltet (geht bei den meisten Notes-Projekten schneller als das Erstellen vom Pflichtenheft) und anhand des Prototyps gemeinsam mit dem Kunden festzurren, was wie umgesetzt werden soll. Meist gibt es in dieser Phase einige Überraschungen 
Dann Aufwandschätzung und - ganz wichtig - immer Abrechnung nach tatsächlichem Aufwand.
Da die wenigsten Anwender sich in die Denkweise von Notes reindenken können (und die meisten Entwickler ebensowenig in die Arbeitsweise der Anwender) sollte man auf jeden Fall in regelmässigen Intervallen den derzeitigen Stand der Entwicklung mit dem Anwender abgleichen (bei grösseren Projekten).

[Marinero Atlántico]

Es gibt keine einfachen Vorlagen.
Die User wissen erst nach einem Prototypen, welche Ansichten, Masken sie wirklich benötigen. Masken sollte man aber relativ frühzeitig festzurren. Bei einem neuen System würde ich mich von diesen technischen Notes-Begriffen lösen und mit Use Cases oder User Stories arbeiten (näheres in der einschlägigen RUP bzw XProgramming Literatur).
Ansichten sind nicht so wichtig. Ich halte das für ein ziemlich naives vorgehen. Die User sollen definieren, was sie sehen werden. Sie vergessen dabei sehr viel, weil sie es nicht vor sich haben.
Für am erfolgversprechensten halte ich:
User beschreiben ihre Arbeit und dafür wird ein Prototyp gemacht. Dann sagen die User was fehlt. Usw. iterativ.
Läßt man User Workflows definieren so werden sie meist zu komplex. Gleiches gilt für die Berechtigungsstruktur.

Du kannst natürlich sagen, dass RUP- und XP-Literatur nur was für Spinnner ist und Realisten ihre User saubere Listen generieren lassen, wo genau notiert ist was das System "darstellen" soll.
Genau diese besserwisserische Analphabeten-Mentalität sehe ich aber mittlerweile eine wichtige Ursache für die lachhafte Wirtschaftsentwicklung dieses Landes an.

Axel

[Mark³]

und noch was wichtiges fällt mir ein:
es ist nicht immer ratsam, in der Datenbank die tatsächlich gelebten Arbeitsprozesse abzubilden. Oft wird beim Entwickeln erst klar, wie unsinnig der abzubildende Prozess eigentlich ist. Wenn man so etwas feststellt sollte dringend der Prozess angepasst werden. Dies wird im richtigen Leben allerdings selten gemacht weil ein Notes-Entwickler meist kein Prozessverantwortlicher ist 
Und die Verantwortlichen lassen sich ungern von einem Entwickler belehren und sehen meist nicht ein, wie unsinnig ihr Prozess eigentlich ist.

[Marinero Atlántico]

Im übrigen ist das sowieso sehr Projektabhängig.
Hast du ein sehr großes Projekt mit sagen wir 30 bis 100 Beteiligten, dann macht der Wasserfallprozess (also genaue Planung, dann umsetzen, dann testen) schon Sinn, weil sonst die Kommunikationskosten zu hoch werden.
Beispiele für solche Wasserfall-Projekte sind etwa die Umstellung quasi sämtlicher Daimler-Internetauftritte auf das Java CMS Day.
Oder ein großes Java Portal Projekt der GAD mit Code-Generierung, tagelangen Konfigurationen der WSAD-Entwicklungsumgebung, komplexen Deployment-Prozessen, etc.
Aber das ist wirklich was anderes...

[Marinero Atlántico]

... aber das mit den "haben die Profis nicht Listen..." treibt meine Hormone in den Aufstand.
IMHO ist das die Sprache der nix-klappt-weil-keiner-für-verantwortlich-ist Welt mit den täglichen Verkehrsstaus um 9:00 und 15:30.
Nur in diesem Land war es IBM möglich ein Projekt, dass bereits im Jahr 2000 (oder früher) bei der Deutschen Bank gescheitert ist, ab 2001 an einige weitere Großkunden zu verhökern (unter den verschiedenen Decknamen LISA, LSA).
Da gab es eine Menge Listen drin und die Bezeichner sahen auch noch so technisch-professionell-kryptisch aus, dass es sich keinr merken konnte.

 

[Thomas Schulte]

Decknamen LISA, LSA).
Da gab es eine Menge Listen drin und die Bezeichner sahen auch noch so technisch-professionell-kryptisch aus, dass es sich keinr merken konnte.