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.

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.

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.

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ß  

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

@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.

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?

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

HA!

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

kann es sein, dass du Extreme Programming meinst?

Sorry, natürlich, ich meinte Extreme Programming.