Domino 9 und frühere Versionen > Entwicklung

To Do - Datenbank Features

<< < (2/5) > >>

TMC:
Danke Thomas, aber das habe ich bereits gemacht.

Grob-Fazit:
--- Zitat ---Ziel u.a. ist es, wenn ein MA krank ist, dass man sofort sieht was ansteht.
--- Ende Zitat ---

Die Leute wollen Aufgaben in einer DB verwalten.

Konkrete Vorschläge habe ich nicht erhalten - trotz aufzeigen der Möglichkeiten die Notes bietet.
E-Mail-Übernahme habe ich gezeigt, und wird auch gewünscht.
Genau so die Möglichkeit der E-Mail - oder Kalenderbenachrichtigung.

Genau da setzt meine Frage an:
Welche Features wären aus Eurer Erfahrung heraus sonst noch sinnvoll?

Ich suche da wirklich nach Erfahrungswerten, da die MA in der Abteilung noch nie mit einer ToDo-DB in diesem Sinne gearbeitet haben - und somit nicht der konkrete Input verständlicherweise seitens der MA erfolgen kann.

animate:

--- Zitat ---Ich denke was man braucht (jetzt mal zusätzlich zum R6 - Mail ToDo):
- Agenten im Mailfile, um Mails in ToDo's zu übernehmen
- Erinnerungen falls gewünscht (optional: per Reminder Mail oder Kalender-Reminder)
- Leserechte, evtl. Verschlüsselung(?)

--- Ende Zitat ---

was haben deine Mitarbeiter denn darauf genatwortet?
Brauchen sie sowas?


--- Zitat ---Ziel u.a. ist es, wenn ein MA krank ist, dass man sofort sieht was ansteht.

--- Ende Zitat ---
was bedeutet u.a.? Gibt es noch mehr Ziele?
Wie soll dieses Ziel erreicht werden? Wer genau soll sofort sehen, was ansteht? Alle anderen oder nur bestimmte MA? Heißt 'ein MA soll sofort sehen' nicht eigentlcih 'die DB soll den MA sofort benachrichtigen'?

Lieber MA, wie verwalten Sie zur Zeit Ihre Aufgaben? Was ist daran gut? Was ist verbesserungsfähig?

Die Person, die den Auftrag gegeben hat. Welche Vorstellungen hat die denn von der DB?
...

Ich hoffe, du verstehst, worauf ich hinaus will.
es ist sehr hilfreich, wenn alle an der DB Beteiligten ein gemeinsames Ziel haben.
Oder anders formuliert: es kann sich durchaus negativ auswirken, wenn das nicht so ist.

Wenn du Features einbaust, die jemand aus dem Forum hier ganz toll findet, von deinen MA aber nicht benötigt werden, dann hättest du dir Zeit und Fehlerquellen sparen können.

Kurzum: Mein Tipp ist, versuche mal die MA mehr in die Verantwortung zu nehmen. Sie müssen wissen, was sie wollen. Sie müssen schließlich später damit arbeiten. Und du musst das Wissen aus ihnen herauskitzeln.

Viel Spaß  :)

TMC:
Thomas, danke für Dein Feedback.

Meinem Posting sind durchaus einige Aktionen vorausgegangen.

Unter anderem: Erstellung Lastenheft.

Ich definiere – wie übrigens nicht überall so etabliert – es so:
(jetzt mal ohne theoretisches bla bla und so wie ich das sehe):
Lastenheft: das was die Anwender gerne hätten
Pflichtenheft: konkrete Doku. Genau danach wird programmiert. Enthalten sind alle – mit den verantwortlichen Leuten und natürlich den Usern - abgestimmten Vorgaben für die Applikation. Resultat aus dem Lastenheft.
Parallel dazu ein Projektplan mit Aktionen. Das Pflichtenheft ist die Basis für den Projektplan.

Ich weiß was Du meinst, Thomas. Es sind auch diverse Aktionen meinerseits erfolgt vor diesem Posting. Dieses Posting sollte auch mehr als „query market surveillance“ dienen (ist jetzt ein von mir definierter Begriff – als Gegenüber zu dem etablierten PMS post market surveillance)

Wir stecken aktuell mitten in der Lastenheft-Phase. Der Auftraggeber hat (wie so oft) null Plan. Er will einfach nur eine ToDo-DB. Ich will hier einfach mal nur Erfahrungen von anderen Umsetzungen abklopfen (gehört für mich auch zu meinem definierten „query market surveillance“.).
Ob wir dann wirklich diesen Weg gehen, ist mal dahingestellt.

Ich werde eine Teufel tun und jetzt einfach so zu starten. Aber mich interessieren halt auch Eure Erfahrungen, also QMS :-)

Hernan Cortez:
Hi,

Du gehst stark nach dem Wasserfallmodell vor. Erst sämtliche Requirements einsammeln. Dann sämtliche Planung bzgl. des Designs der Anwendung machen. Dann sämtliche Umsetzung und zum Schluß das ganze Teste
 
Dies wurde in den letzten Jahren gerade von Entwicklerseite sehr stark kritisiert (XP, Agile Bewegung, etc.). Selbst der nun als eher konservativ geltende Rational Unified Process betont stark den interativen Charakter von Softwareprojekten. D.h. die menschliche Fähigkeit komplexe change Prozesse vollständig zu überblicken, überfordert das menschliche Hirn. Es sollen also zu Anfang lediglich die wichtigen Grundlinien bezüglich der Requirements festgelegt werden. Die Anwender erhalten dann Prototypen und können bezüglich der Details bessere Vorhersagen über das treffen, was sie eigentlich wollen. Im Laufe des Projekts werden dann die Requirements immer detaillierter und verfestigen sich.
 
Ein iteratives Vorgehen ist IMHO sehr vernünftig. Das Problem ist, dass diese sich wandelnden Requirements im laufenden Projekt dann tendentiell kostenmässig unzureichend gewichtet werden. Man hat dann mit den Kunden auch eine gewisse menschliche Beziehung und der Rheinländer neigt dann zu diesen "o.k. dat jibt et ohne Quittung kullanzmässig dabei"-DisEconomics.  Deshalb sollte man von Anfang an einen gewissen Spielraum einrechnen.

Wie angesprochen, ist die Einführung einer neuen Software immer ein change-Prozess bezüglich der Arbeitsweise einer Organisation. Die Anwender als planlos zu diffamieren, weil sie das ohne Prototypen nicht wirklich überblicken können, halte ich persönlich für ein bischen vorschnell.

Iteratives Vorgehen wird auf der anderen Seite von Entwicklern leider oft zum Anlaß genommen auf wichtige und "langweilige" Planungselemente zu verzichten und direkt mit dem coding zu beginnen. Ich weiss inzwischen, dass dies sehr, sehr schlecht ist. Dokumentation der Requirements, des Designs und des Coding halte ich für sehr wichtig. Wenn man im Team entwickelt noch viel wichtiger. Leute, die subotimale Dokumentation mit ihrer speziellen "Entwicklermentalität" begründen, haben die Spielzeuge ihres Kinderzimmers noch nicht wirklich zur Seite gelegt.

Auf der anderen Seite kann auch zu viel upfront Planung extrem ineffizient sein. Hab zur Zeit des Booms mehr als einmal erlebt, dass dort endlose, gehaltlose Planungssitzungen stattfanden. Es gab auf Seiten der Organisation des Kundens oft mindestens einen "weitsichtigen Querdenker", der ohne Rücksicht auf meine Nerven ständig mit irgendwelchen zu diesem Zeitpunkt wirklich nicht so wichtigen Detailfragen kam.

In kleinen Teams und als Einzelentwickler ist IMHO die richtige Mischung aus frühzeitiger Planung und iterativen Vorgehen wichtig. Auch stark projektabhängig und Wie alles auch eine Frage von Erfahrung, Disziplin und Verständnis für die Seite des anderen. Perfekt ist es nie, aber man sollte sich Mühe geben.

Gruß Axel

Heiggo:

--- Zitat von: TMC am 14.05.04 - 23:02:45 ---Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.
Allerdings ohne weitere Vorgaben.

--- Ende Zitat ---

Das sollte mal einer bei uns versuchen. Wünsche ohne Anforderungsprofil/Vorgaben zum Selberraten ?!?!?
Nach dem Motto
Kunde zum Bäcker: Ich hätte gern ein Brot.
Bäcker zum Kunde: Welches hätten Sie gerne
Kunde zum Bäcker: Sagte ich doch, ein Brot.


Und da möchte man, das das Rad neu erfunden wird? Reicht die Standard-ToDo-Geschichte nicht aus, die man in einer MailDB findet?
Gibt es da keine übergreifende organisatorische Adresse,
z.B. Firma XYZ Personalabteilung
auf die die MA ZUgriff haben?

Whatever... da ich gerade an einer Org-Bereichsbezogenen Archiv-DB rumdenke muss ich direkt mal meine bisherigen Überlegungen etwas erweitern, ob das bei uns auch Sinn macht :-)

Mir würde da nun spontan noch einfallen, dass ein MA ein ToDo erstellt und dieses einem anderen auch namentlich zuweisen kann, wenn´s keine Gruppenaufgabe ist. Diese Zuweisung muss dann natürlich auch änderbar sein (im Krankheitsfall) und MA (2) muss dann natürlich auch einen Link zum Dokument per eMail erhalten können, was ja kein Hexenwerk ist. Hierzu muss jeder MA in der ArchivDB ein kleines persönliches ProDok erstellen, welche bei Zuweisungen in einer Auswahlliste bereitgestellt werden, damit nicht aus Versehen jemand mit einer Aufgabe betraut wird, der gar kein Zugriffsrecht auf die DB hat.
Selbstverständlich soll jeder MA schnell sehen können (zusätzliche kleine Ansichten) wer welche ToDos abzuarbeiten hat und natürlich muss der MA die Möglichkeit haben, einen Status für das ToDo setzen zu könnnen á la... In Bearbeitung, Dauert noch, Info´s fehlen, Übergeben etc. Natürlich möchte ich als MA auch vieleicht gleich sehen können, ohne das Dok zu öffnen, in welchem Status das ToDo ist... und und und.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete