To Do - Datenbank Features

[TMC]

Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.

Allerdings ohne weitere Vorgaben.

Was macht Eures Erachtens Sinn, dort als Features anzubieten?

Ich habe mir mal in R6 die Standard - ToDo's im Mailfile angesehen - und auch schon mal das meiste übernommen - macht ja auch Sinn.

Ziel und Zweck:
Die Abteilung soll ToDo's zentral in einer DBs pflegen. Ziel u.a. ist es, wenn ein MA krank ist, dass man sofort sieht was ansteht.

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(?)

Habt Ihr weitere Ideen, was für eine allgemeine ToDo - DB noch sinnvoll wäre?

Und wie würdet Ihr Dokumente einbinden (z.B. EMails)? Als Antwort-Dokumente zum To-Do - Dokument oder direkt in das ToDo-Dokument in ein RTF kopieren?

Ich frage, weil bestimmt das schon der/die ein- oder andere umgesetzt hat.
Mich würden Eure Erfahrungen interessieren.
Und: Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.
Also User 1 hat schonmal Part1 erledigt, User 2 hat auch was gemacht, etc.

[koehlerbv]

Und wie würdet Ihr Dokumente einbinden (z.B. EMails)? Als Antwort-Dokumente zum To-Do - Dokument oder direkt in das ToDo-Dokument in ein RTF kopieren?

Wegen Ordnung und Sauberkeit im Schlachthaus: Als eigenes (Antwort-)Dokument.

Agenten im Mailfile, um Mails in ToDo's zu übernehmen/quote]
Wie das ? Alle Mails werden ToDos ? Oder wie ?

Erinnerungen falls gewünscht (optional: per Reminder Mail oder Kalender-Reminder)

Jo !

Leserechte, evtl. Verschlüsselung(?)

Leserechte erscheinen mir adäquat. Wenn Du Verschlüssleung brauchen solltest, dürfte es bei einer ToDo-DB um mehr gehen. Verschlüsselung erscheint mir sinnlos in diesem Zusammenhang.

Und: Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.

Haariges Problem. Auf jeden Fall never-ever ins ToDo-Doc zurückschreiben wegen Replizierkonflikten. Das gehört typischerweise in ein ResponseDoc. Das Prinzip Parent-Responses muss dabei möglichst aufgeräumt sein (da wir es beide kennen: Die Notes BP-Discussion ist da ein Anti-Beispiel).

Da ich mit sowas schon ziemlich beschäftigt war: Sag weiteres an, ich bin da gerne behilflich.

Servus,

Bernhard

[TMC]

Danke für Dein Feedback Bernhard.


Zu Antwort 1 und 2 (Mails übernehmen / werden zu Response oder nicht):

Ich denke wenn man sich entscheidet, Mails etc. als Antworten zu übernehmen (und nicht ins Hauptdokument), sollte man einen konsequenten Weg gehen:
Es gibt ein übergeordnetes ToDo-Dokument mit Basisdaten (due date, Beschreibung etc.). Darunter hängt man dann die einzelnen Sachen (Mails, Aktionen, etc.)

Zu Verschlüsselung:
War nur so ein Gedanke, werde ich aber wieder verwerfen, ist nicht die Personalabteilung für die ich das mache, von da her sollte Lesezugriffs-Management ausreichen.

Zu: "Wie stellt Ihr transparent dar, wenn mehrere Leute was gemacht haben.":
Deine Antwort bestätigt mir einmal mehr, dass man mit Response Docs arbeiten sollte.

Bernhard, danke nochmal. Ich werde mir das nochmal alles durch den Kopf gehen lassen.

Und bin über alle weiteren Anregungen / Erfahrungen dankbar.

[TMC]

Noch was:

Man könnte natürlich jetzt sehr weit gehen:

User erhält eine Mail -> sie/er stellt fest, das ist ja ein To Do. Also schnell mal ein neues ToDo-Dokument anlegen, und eMail per Mail-Agent zum ToDo-Dok als Response-Doc kopieren.

Nun muss eine Aktion in Form einer E-Mail folgen.
Jetzt könnte man ja ermöglichen, dass die E-Mail direkt aus der ToDo-DB erstellt wird (damit eine Kopie automatisch auch zum ToDo als Response angelegt wird).

Ist das übertrieben oder wird das gewünscht ?
Ich denke dabei auch an die Anwender. Es soll für den Anwender so einfach wie nur möglich sein, er soll aber auch intuitiv vorgehen können.

Umständlich würde ich finden, wenn Anwender nachträglich aus der $Sent - View das Dokument per Agent in die ToDo-DB kopieren müsste. Zumal da die Gefahr besteht, dass Anwender diesen Step einfach vergisst im Alltagsstress.

[animate]

Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.

Allerdings ohne weitere Vorgaben.

Was macht Eures Erachtens Sinn, dort als Features anzubieten?

Ich kann die nur raten, einige Mitarbeiter der Abteilung zu interviewen (oder natürlcih auch andere Erhebungstechniken einzusetzen), um herauszufinden, was sie sich von der neuen DB erwarten und was nicht.
Was dieser und jener in diesem Forum hier gut oder schlecht findet, interessiert die, die später damit arbeiten müssen, wahrscheinlich herzlich wenig.

[TMC]

Danke Thomas, aber das habe ich bereits gemacht.

Grob-Fazit:

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

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]

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(?)

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

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

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]

Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.
Allerdings ohne weitere Vorgaben.

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.

[TMC]

@Axel:

Danke für Deine Anregungen.

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

Stimmt. Hier mache ich das bewußt. Obwohl gerade Notes sehr gut geeignet wäre, um z.B. Chaos-Programming zu betreiben. (wenn man denn die Zeit hat. Ich habe zu Chaosprogramming noch kein Buch gelesen - es aber auch schon vollzogen).
Ich bin hier hergegangen, und habe eine einfache Maske zusammengesetzt (sieht so ähnlich aus wie die ToDo-Maske des R6 - Mailfile) um den Leuten erstmal zu zeigen wie es aussehen könnte. Und dann nachgefragt was sie denn noch wollen (inkl. dezenter Hinweise meinerseits, dass vieles möglich ist: u.a. E-Mail-Übernahme ins ToDo und Reminder per Email).

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.

Das kam wohl falsch rüber. Auftraggeber ist ein Abteilungsleiter der ziemlich neu in der Fa. ist. Er will dass eine ToDo-DB eingeführt wird. Trotz mehrmaligem Nachfragen keine Details. Er kennt auch die Prozesse in seiner Abteilung nicht.
Die Anwender sind bestimmt nicht planlos - eher lethargisch - wobei das wohl auch am Führungsstil des ABL's liegt. Die DB selbst werde ich auch größtenteils zusammen mit den Anwendern erstellen und nicht mit dem ABL. Und dabei werde ich mein bestmögliches tun, um die Anwender für die DB zu begeistern.

Fazit
Wir sprechen hier - im Vergleich - von einem kleinen Projekt. Ich hätte als Ergebnis gerne eine App, die ich auch selber nutzen kann (zumindest dann leicht angepasst).
Und klopfe daher auch im Vorfeld mal Erfahrungswerte Eurerseits ab.
Nachdem ich von den Anwendern selber wenig Feedback habe, werde ich das ganze wohl zweiteilen:
Ein Erstrelease zum starten.
Dann werde ich nach ein paar Wochen die AW interviewen und herausfinden wo Verbesserungspotential besteht, welche Wünsche die haben, etc. Ich denke erst dann werden die Anforderungen klar sein, da die Anwendergruppe eben noch nie mit einer ToDo - DB gearbeitet hat.

[TMC]

@SiebertH:

Ich habe die Aufgabe eine To Do - Datenbank für eine Abteilung zu erstellen.
Allerdings ohne weitere Vorgaben.

Das sollte mal einer bei uns versuchen. Wünsche ohne Anforderungsprofil/Vorgaben zum Selberraten ?!?!?

Mit "für eine Abteilung" war gemeint, dass die ToDo's zentral verwaltet werden - und nicht in jedem einzelnen Mailfile.
Ich denke es ist im Notes-Umfeld auch einigermaßen klar, was überhaupt unter "ToDo-DB" verstanden wird. Ich habe dies auch mit dem Auftraggeber vorab abgeklärt - da dieser ziemlich neu in der Fa. ist und ich seinen Background nicht kenne/kannte.

Von da her hinkt Dein Vergleich mit dem Bäcker etwas - aber ich gebe Dir Recht: ohne Spezifikation stellt es sich schwierig dar, was konkretes umzusetzen.

Aber danke auch für Deine Hinweise.

Ciao,

[animate]

Obwohl gerade Notes sehr gut geeignet wäre, um z.B. Chaos-Programming zu betreiben. (wenn man denn die Zeit hat. Ich habe zu Chaosprogramming noch kein Buch gelesen - es aber auch schon vollzogen).

Schon wieder offtopic von mir, aber mich interessierts halt.
Was ist denn das? Chaos Programming?

[TMC]

So wie ich diese Methodik verstehe, wird hier wortwörtlich chaotisch das Projekt durchgezogen.

Hier erfolgt während des Projektes engste Zusammenarbeit mit dem AG / den Usern.

Man erstellt eine Maske und hat schonmal was zum zeigen. User sagen, dass sie noch 8 weitere Felder brauchen. Man setzt das um und zeigt das wieder. Nun müssen 2 Felder wieder raus, und dafür 3 neue rein. etc. etc.
Ein klassisches Pflichtenheft gibt es in dem Sinne nicht.
Ein Projektplan-Fanat wird imho wahnsinnig dabei.

Aber so wie ich Axel kenne, hat er da bestimmt einen Link für uns und Detailinfos  

[animate]

kann es sein, dass du Extreme Programming meinst? nicht Chaos Programming? Google spuckt nicht mal 100 Treffer für den Begriff aus

[Hernan Cortez]

In der SCEA_J2EE yahoo group gab es dazu am 14.5. eine - sagen wir - Diskussion.

Ich wäre da ein bischen vorsichtig mit Pauschalurteilen. So Dinge wie XP haben sehr wohl ihre Berechtigung und es gibt Leute, die damit erfolgreich arbeiten.

Ich habe auch zu viele Leute erlebt, die vorgaben wer weiss wie strukturiert vorzugehen, in deren Kopf aber völliges Chaos herrschte. Die wussten eigentlich nur, wie sie irgendwelche Geldgeber davon überzeugen konnten, dass sie strukturiert wirken. Sie waren aber völlig damit überfordert, ein Projekt strukturiert zu leiten. Je komplexer das Projekt, desto schwieriger das upfront-Planung. Soll jetzt nicht arrogant klingen, aber es geht IMHO wirklich nicht um Felder in Masken. Das kann oft sogar eher Implementierungsdetail sein.

Persönlich bin ich aber zur Zeit ein Freund von relativ viel upfront-Planung, v.a. wenn es um Entwicklung im Team geht.
In meinem Spiel-Projekt hab ich z.B. wegen meiner Begeisterung über JDOM 1.0 und die eingebaute xslt-Fähigkeit völlig übersehen, dass ich da eigentlich nicht wirklich transaktionales Verhalten einbauen kann und das 1 HSQLDB pro User die beste Lösung für den Persistenzlayer ist (soll jetzt nicht arrogant klingen).
Effekt: ich werde da die ganze Logik für das Speichern von Datensätzen umschreiben. In einem Projekt mit Geld und Kollegen, wäre das ein Problem.

HSQLDB ist total cool. Es ist eine single user "rdbms" mit Transaktionen als jar Datei.

Gruß Axel

[Hernan Cortez]

HA!

http://www.wikiservice.at/dse/wiki.cgi?IljaPreu%df
insbesondere: http://www.wikiservice.at/dse/wiki.cgi?ExtremeProgramming

[Hernan Cortez]

Das kam wohl falsch rüber. Auftraggeber ist ein Abteilungsleiter der ziemlich neu in der Fa. ist. Er will dass eine ToDo-DB eingeführt wird. Trotz mehrmaligem Nachfragen keine Details. Er kennt auch die Prozesse in seiner Abteilung nicht.

Das ist mir auch schon mehr als einmal begegnet. Die Prozesse nicht richtig überblicken, aber erstmal die Schachfiguren herumschieben, um Stärke zu zeigen oder/und um Bewegung in die ganze Sache zu bekommen. Vielleicht auch ein bischen Selbstüberschätzung.  
Da ist -glaub ich - ein relativ hohes Risiko vorhanden, dass der Typ sich in den Fuß schießt. Ich hab jedenfalls schon Fälle gesehen, wo jemand auf Grund dieser Strategie irgendwann mit viel Gegenwind leben mußte.

Vielleicht ist es eine gute Idee 4 Wochen nach der Einführung mit einem kleineren Kreis an Usern ein Review zu veranstalten. Da sollte es dann nicht nur um rein technische Aspekte gehen, sondern auch um Dinge wie "Wie verständlich sind die ToDos." und warum sind manche ToDos nicht verständlich. Aber ich glaube das meinst du mit dem "post market surveilance". Ich würd vorschlagen, die Leute auf jeden Fall persönlich an einen Tisch zu bringen und den Kreis inkl. dir und Abteilungsleiter auf 5 Leute beschränken. Keine Massenveranstaltung.

Gruß Axel

[TMC]

kann es sein, dass du Extreme Programming meinst?

Sorry, natürlich, ich meinte Extreme Programming.

[eknori]

@TMC:

und nun ?? hin und hergerissen zwischen Theorien und halbgaren Ansätzen; hilt dir das nun weiter mit deiner Aufgabe?
 Die Realität sieht zumeist ein bisschen anders aus.
Du arbeitest, wie ich , als Angestellter in einem Unternehmen. Dort erwartet man von dir, Ergebnisse abzuliefern. Mir bleibt keine Zeit, mich erst Äonen in Theorien einzulesen; sei es XP, RUP und wie diese ganzen Worthülsen auch heißen mögen...
Klar, ich weiß, daß ich mich jetzt hier extrem unbeliebt mache,; spart euch die Kommentare!


Ulrich