Tipps zur Verwendung von Redmine für dein Projekt

Nach fast 10 Jahren der Nutzung von Redmine für eine Vielzahl von Projekten und mit sehr unterschiedlichen Teamgrößen sind hier meine praktischen Tipps, wie du es für dein Projekt verwenden solltest:

Super-Projekte

Erstelle ein Super-Projekt, von dem alle Projekte Unterprojekte sind. Dies ermöglicht dir, alle Projektmanagement-Funktionen wie Gantt, Meilensteine etc. im Super-Projekt zu nutzen.

Beispiel-Projektstruktur

• My Company Inc (Super-Projekt)
  • R&D
    • Migration zu Cloud Computing
    • Machine Learning Forschung
  • Operations
    • Kunde X
    • Kunde Y
  • Management

Indem du die Ticketliste für das Super-Projekt öffnest, siehst du alle Tickets aller Unterprojekte — und hast daher mehr Werkzeuge zur Verfügung für das übergeordnete Management des Unternehmens. Du könntest beispielsweise Meilensteine für die Geschäftsentwicklung im Super-Projekt erstellen, die von Aufgaben in einem R&D-Unterprojekt abhängen.

Keine öffentlichen Projekte!

Leute machen oft den Fehler, ein Redmine-Projekt öffentlich zu machen — vielleicht weil das die Standardeinstellung für neue Projekte ist.

Jedoch kann jeder, der die Projekt-URL kennt, z.B. https://redmine.mydomain.com/projects/test/, ALLE DATEN im Projekt standardmäßig sehen, auch wenn das Projekt nicht in der Projektliste der Suchleiste aufgeführt ist

Lösung: Mache alle Projekte nicht-öffentlich: Als Admin gehe zum Projekt, zum Settings-Tab, deaktiviere das Public-Kontrollkästchen und klicke auf Save. Es sei denn, du willst tatsächlich, dass alle Daten über Redmine öffentlich verfügbar sind…

Mehrere Issue-Tracker vermeiden

Unternehmen, die organisch auf ihre heutige Größe gewachsen sind, haben oft separate Systeme, die im Wesentlichen denselben Zweck erfüllen, aber meist nicht miteinander verbunden sind — und meist von verschiedenen Untergruppen des Personals genutzt werden.

Typisches Beispiel: Das (Projekt-)Management nutzt Redmine, während die Entwickler Gitlab für quellcodeorientiertes Bug-Management nutzen und nur mit Redmine kommunizieren, um mit den Projektmanagern zu sprechen.

Während diese Konstellation über längere Zeiträume hinweg einigermaßen gut funktioniert, führt sie unweigerlich zu einer ungesunden Streuung von Informationen und infolgedessen zu Ineffizienz bei der Informationssuche. Manche low-level-Entwicklungsdiskussionen oder Dokumentationen landen in Redmine, während einige projektmanagementbezogene Diskussionen unweigerlich in Gitlab landen.

Wenn irgend möglich, versuche, die Nutzung eines Systems zu fördern und die Nutzung des anderen für jeden Zweck, der sich überschneidet, zu missbilligen. Versuche, aktiv mit Personen, die dieser Politik entgegenstehen, Lösungen zu finden, wie sie ihren bekannten Prozess im neuen System anpassen können.

Unterstützung für eingehende E-Mails aktivieren

Die meisten Redmine-Setups sind auf einem Smartphone notorisch schwer zu bedienen — die UI ist nicht wirklich für mobile Nutzung optimiert.

Um die Nutzung auf mobilen oder anderen Geräten zu erleichtern, ist ein einfacher Weg, dem Benutzer zu erlauben, auf Benachrichtigungs-E-Mails zu antworten, wobei seine Antwort als Update zum Ticket gepostet wird. Während dies etwas schwer einzurichten ist, wird ein paar Stunden von einem kompetenten Admin oder Experten dir mit Sicherheit ein paar Jahre wartungsfreie Updates durch eingehende E-Mails bringen.

Beachte, dass dies nicht den Anwendungsfall abdeckt, neue Tickets zu erstellen oder anderweitig mit Redmine zu interagieren, aber in der Praxis werden Personen, die aktuell nur mobil sind, entweder vorhandene Tickets aktualisieren oder was auch immer sie vorhaben, ausreichend wichtig ist, dass sie sich mit der suboptimalen mobilen UI von Redmine befassen werden.

Während es einige Redmine-Mobile-Apps gibt und es sicherlich einen Versuch wert ist, hatte ich in vergangenen Projekten keinen großen Erfolg mit ihnen.

(Teile des) Wikis zur Sammlung unstrukturierter Informationen nutzen

Viele Unternehmen haben keinen strukturierten und durchsuchbaren Weg, unstrukturierte Informationen zu sammeln. Was ist mit dem SSH-Befehl, den der Admin verwendet, um sich mit einem Server zu verbinden? Jeder, der in R&D gearbeitet hat, weiß, dass das Land der perfekten Dokumentation reine Utopie ist und während das Schreiben von Top-Down-Dokumentation für alle anstehenden Aufgaben eine Zeit lang funktionieren mag, wird es meist nur verwendet, um zu beschreiben, was zu tun ist, während Details darüber, wie es zu tun ist, ziemlich leicht weggelassen werden.

Darüber hinaus ist die Dokumentation oft nicht mit der Realität synchron, besonders wenn die Personen, die sie ursprünglich geschrieben haben, zu anderen Projekten oder sogar anderen Jobs gewechselt sind. Mach nicht den Fehler anzunehmen, dass du irgendeine Möglichkeit hast, die Disziplin durchzusetzen, technische Dokumentation bis auf Kommando- oder Komponentenebene über einen längeren Zeitraum zu schreiben & synchron zu halten. Anfängliche Erfolge in dieser Hinsicht sind viel schlechter geeignet, den langfristigen Erfolg von Dokumentationsprojekten vorherzusagen, als die meisten Projektmanager zugeben würden — und es ist fraglich, ob gute, aber fürchterlich veraltete Informationen in einem mehrjährigen Projekt von irgendeinem Nutzen sind.

Wenn du das Redmine-Wiki für keinen anderen Prozess verwendest, versuche, Leute dazu zu bringen, es zu nutzen, um zu dokumentieren, was sie getan haben, auch wenn es nur ein prototypisches Kommandozeilen-Skript oder etwas ist, das später nicht funktioniert (du kannst es löschen, wenn es keinen Zweck mehr erfüllt).

Wenn du das Wiki jedoch für andere Dokumentation verwendest, reserviere einfach einen bestimmten Bereich, z.B. jede Seite, die von einer speziellen Documentation-Seite aus erreichbar ist, für strukturierte Informationen und erstelle Seiten für verschiedene Arten unstrukturierter Informationen

Falscher Alarm: Dringende und Sofortige Prioritäten nicht überbeanspruchen

Jeder, der in der Technologiebranche gearbeitet hat, weiß, dass einige Projektmanager die unheimliche Fähigkeit zu haben scheinen, immer noch eine Dringende Aufgabe im Ärmel zu haben, egal wie viele man bereits behoben hat. Außerdem gibt es so viele Dringende und Sofortige Aufgaben, dass niemand mehr wirklich weiß, was diese Wörter bedeuten — besonders da man sich kaum noch an das letzte Mal erinnern kann, als man eine Niedrig-priorisierte Aufgabe behoben hat.

Wenn du die Nutzung eines fortschrittlichen Issue-Tracking-Tools einführst, hast du eine weitere Chance, diesen Teufelskreis zu durchbrechen. Es ist eine produktive Politik, eine Regel durchzusetzen, dass Projektmanager zu jedem Zeitpunkt nur eine Sofortige und drei Dringende Aufgaben offen haben dürfen. Dies ermöglicht Entwicklern, tatsächlich zu priorisieren und vermeidet das Risiko, von einem Manager angeschrien zu werden, der die vorhandenen Werkzeuge nicht richtig genutzt und so falsche oder unklare Einschränkungen für die Entwickler auferlegt hat.

Immer jemanden zugewiesen haben & Nach Priorität sortieren

In praktischen Projekten ist ein Phänomen, das oft in Verbindung mit Issue-Trackern auftritt, die Ticket-Verwaistung. So passiert es.

• Das Management erstellt ein Ticket mit hoher Priorität und weist es einem Entwickler zu
• Der Entwickler behebt das Problem und meldet sich selbst ab, wobei er das Management benachrichtigt, jemanden zur ordnungsgemäßen Prüfung des Fixes über den Issue-Update-Text zuzuweisen
• Das Management vergisst, tatsächlich jemanden zuzuweisen (z.B. wegen Urlaub oder dringenderen Aufgaben) und das Ticket gelangt in die endlose Liste von nicht-geschlossenen-aber-nicht-so-wichtigen Tickets, die (fast) behoben wurden, aber ein kleiner Teil fehlt noch

Es sei denn, du gehörst zu den glücklichen wenigen, die es schaffen, über einen längeren Zeitraum alle Tickets zu schließen und ordnungsgemäß & regelmäßig zu bearbeiten, erhöht das kleine Versäumnis, kurzzeitig niemanden zugewiesen zu haben, exponentiell die Wahrscheinlichkeit, dass ein Ticket nicht ordnungsgemäß abgeschlossen wird.

So sollte es funktionieren:

• Das Management erstellt ein Ticket mit hoher Priorität und weist es einem Entwickler zu
• Der Entwickler behebt das Problem und weist es dem Management zu, mit dem Hinweis im Update-Text, dass der nächste Schritt ist, einen Tester zu finden, der es testen kann. Der Entwickler setzt das Ticket auf eine angemessene Prioritätsstufe
• Das Management wird die Tickets immer auf der My tickets-Seite sehen

Mit anderen Worten: Es muss immer jemand zugewiesen sein. Während dies Probleme von Personen, die das Projekt verlassen, im Urlaub oder krank sind, nicht automatisch löst, so sollte es funktionieren:

• Wenn der nächste Schritt an diesem Ticket von dir erledigt wird, lass dich selbst zugewiesen
• Wenn es mehrere nächste Schritte gibt, die parallel passieren sollen, erstelle Sub-Tickets und weise entsprechend zu
• Wenn die nächste Aufgabe dir unbekannt ist, weise sie dem Management oder dem leitenden Entwickler zu und notiere, dass die nächste Aufgabe bestimmt werden muss
• Wenn du die nächste Teilaufgabe kennst, aber nicht weißt, wer sie erledigen soll, weise sie dem Management zu und notiere, dass X getan werden muss und sie bestimmen sollen, von wem (dies entspricht unserem oben aufgeführten Beispiel)
• Wenn die Aufgabe dir zugewiesen wurde und du nicht weißt, was zu tun ist, weise sie dem leitenden Entwickler oder dem Management zu und notiere so klar wie möglich, warum du dir unsicher bist, was zu tun ist. Häufiges Auftreten dieses Falls weist typischerweise auf ein Versäumnis des Managements oder des Entwicklungsleiters hin, die Aufgaben in einer entwicklerkompatiblen Weise zu kommunizieren.

Unabhängig von den vorgenannten Entscheidungen:

• Nutze Sub-Tickets intensiv: Jedes Mal, wenn du siehst, dass etwas in mehrere Aufgaben aufgeteilt werden kann, auch wenn du alle diese Aufgaben ohnehin erledigen wirst
• Erstelle keine Sub-Issues für Teilaufgaben, bei denen prognostiziert wird, dass sie weniger als 10 Minuten dauern
• Erstelle immer Sub-Issues für Teilaufgaben, bei denen prognostiziert wird, dass sie mehr als 60 Minuten dauern
• Es ist die Verantwortung des Managements, die Aufgaben vorübergehend nicht verfügbarer Projektmitglieder durchzusehen und Issues, die nicht warten können, entsprechend neu zuzuweisen
• Es ist die Verantwortung des Managements, die Aufgaben dauerhaft nicht verfügbarer Projektmitglieder durchzusehen und alle Issues als Grundsatz neu zuzuweisen

Ein guter Weg, Sub-Tickets zu konzeptualisieren, ist als lokale Mini-Meilensteine. Während einige Tickets einen größeren Umfang als ein typischer Meilenstein haben könnten, sollten Sub-Tickets sich primär darauf konzentrieren, Beziehungsinformationen an Entwickler zu vermitteln, während Meilensteine sich primär darauf konzentrieren sollten, Informationen an das Management zu vermitteln.

Angesichts dieses Prozesses sollte jeder hauptsächlich auf der My tickets-Liste arbeiten, nicht so sehr auf der Projekt-Ticketliste. Die Projekt-Ticketliste ist primär für das Management, um einen Überblick zu bekommen, und Entwickler sollten sie nur nutzen, um zusätzliche Informationen zu erhalten oder Aufgaben abzugleichen.

Die effizienteste (& offensichtlichste) Art, Redmine zu nutzen, ist, die My tickets-Liste beginnend mit den hochpriorisierten Aufgaben abzuarbeiten. Denke daran, regelmäßig zu prüfen, ob Aufgaben mit höherer Priorität aufgetaucht sind.

Eine der Hauptaufgaben des Projektmanagers ist es sicherzustellen, dass der beschriebene Prozess automatisch dazu führt, dass Personen an Meilensteinen arbeiten, mit einigen hochpriorisierten Aufgaben außerhalb des Meilensteins dazwischen gestreut. Proper Kommunikation an die Entwickler stellt sicher, dass während jeder nach dem vorgenannten Schema arbeitet, das gemeinsame Ziel, den Meilenstein zu erreichen, klar in den Köpfen der Entwickler definiert ist.

Regelmäßige Updates durch Mikrotasks durchsetzen

Ein typischer Fehlschlagmodus des Software- und Hardwareprojektmanagements ist, dass das Management top-down denkt und es versäumt, einen Prozess durchzusetzen, der bis ganz nach unten denkt.

Bezüglich Issue-Trackern manifestiert sich dieses systematische Problem oft darin, dass es nur grobe Makro-Aufgaben gibt, die, selbst wenn sie Entwicklern richtig zugewiesen sind, niemandem erlauben, den aktuellen Zustand des Projekts genau einzuschätzen (z.B. weil es keine Möglichkeit gibt, einen 0%…100% Fortschritt einer unklar definierten weitreichenden Aufgabe einzuschätzen) und oft dazu führen, dass Entwickler keine regelmäßigen Updates geben.

Je nach Managementstil führen unregelmäßige Updates bezüglich bestimmter Teile der Entwicklung oft zur Prokrastination von Aufgaben auf Seiten der Entwickler, was ihre Effektivität stark reduziert.

All diese Fehlschlagmodi können vermieden werden, indem kleinere, strenger definierte Mikro-Aufgaben verwendet werden. Während diese Lösung aus konzeptioneller Sicht offensichtlich ist, ist die praktische Implementierung meist irgendwo zwischen völligem Desaster und auf Dauer nicht umsetzbar. Die häufigsten Probleme sind:

• Das Management hat keinen Einblick in die „niedrige Ebene“ der Entwicklung und kann daher nicht beurteilen, wie man die Aufgaben über ein bestimmtes Niveau hinaus aufteilt
• Von Entwicklern wird gesagt, sie hätten nicht genügend Einblick in das größere Ganze des Projekts und es wird daher als nicht machbar angesehen, sie Aufgaben selbst aufteilen zu lassen
• Das Management hält den Overhead der Erstellung und Mikromanagement von Mikro-Aufgaben für zu groß und daher sei dieser Prozess ineffizient

Die meisten dieser Bedenken werden jedoch durch eine Kombination aus unangemessenen Prozessen und grundlegenden Missverständnissen über Mikro-Aufgaben verursacht:

• Das Management neigt oft dazu, künstliche Barrieren zwischen sich und den Entwicklern zu errichten — wie etwa die Möglichkeit nicht in Betracht zu ziehen, dass jemand, dem eine Aufgabe zugewiesen ist, am besten wissen sollte, wie man sie aufteilt
• Viele Prozesse operieren unter einem No-Error-Paradigma bezüglich der Issues (d.h. es soll praktisch keine Fehler geben wie falsche Aufgabenaufteilung). Doch unter realen Bedingungen ist es fast immer effektiver, kurz- und langfristig die Möglichkeit von falsch behandelten Tickets auf jedem Niveau zu akzeptieren, so wie die Industrie die Existenz von Software-Bugs akzeptiert hat. Das Akzeptieren eines gewissen Fehlerlevels reduziert auch signifikant bestimmte Arten unerwünschten Verhaltens, das prominenteste ist die Neigung, eigene Fehler zu verbergen, sobald man erkannt hat, dass sie gemacht wurden, um soziale Konsequenzen (wie angeschrien werden) zu vermeiden, selbst wenn solche Konsequenzen in der Praxis rein hypothetisch sind. Diese Strategie mildert oft auch die Neigung, künstliche Barrieren zu errichten, wie oben beschrieben, weil der zugrundeliegende Grund für diese Barrieren oft in einem Kompetenzkonflikt und daher einem Kampf um Autorität liegt.
• Das Overhead-Problem kann leicht & effektiv behoben werden, indem man einfach die wünschenswerte Größe von Mikrotasks definiert, wie im letzten Kapitel aufgeführt.
  • Niemals eine Mikro-Aufgabe erstellen, wenn man annimmt, dass die Aufgabe weniger als 10 Minuten dauern wird
  • Immer eine Mikro-Aufgabe erstellen, wenn man annimmt, dass die Aufgabe mehr als 60 Minuten dauern wird
  • Zwischen diesen Werten nutze dein eigenes Ermessen als Entwickler
• Zudem ist es effektiv, bei der Verwendung von Mikro-Aufgaben das Erstellen einer Mikrotask so schnell & einfach wie möglich zu machen. Im schlimmsten Fall wird der Entwickler bei genauen Prognosen eine Mikro-Aufgabe für je 10 Minuten Entwicklungsarbeit erstellen. Wenn irgendeine Anforderung, Politik oder Prozess das Erstellen der Aufgabe für die Entwickler ineffizient macht, kann sich der Overhead schnell ansammeln — jedoch ist dies in der Praxis selten, da die meisten technologieorientierten Entwickler, die nicht unter strenger & direkter Managementaufsicht stehen, eine Art Selbstregulierung anwenden und weniger Mikro-Aufgaben erstellen, wenn der Overhead ausreichend groß ist
• Jedoch kann derselbe Selbstregulierungsmechanismus unter bestimmten Umständen auch dazu führen, dass zu wenige Mikro-Aufgaben erstellt werden. Dies kann nur durch aktive Ermutigung und Kommunikation vom Management gelöst werden, inklusive einem gewissen Maß an Geben und Nehmen auf beiden Seiten.

Da das Management größerer Unternehmen oft unter der Annahme operiert, dass jeder Untergebene bis zu einem gewissen Grad austauschbar sein soll und dieses Konzept oft durch die Hierarchie prevails, fällt es einigen schwer zu schlucken, dass einige Aufgaben von einem Entwickler in mehrere Mikro-Aufgaben aufgeteilt werden, während ein anderer sie monolithisch behandelt, basierend auf Unterschieden in ihrer prognostizierten Zeitspanne. Doch selbst bei einer großen erwarteten Abweichung von der prognostizierten Zeit, die eine Aufgabe dauern wird, zur tatsächlichen darauf verwendeten Zeit (plus die Tatsache, dass es viel einfacher ist, die Dauer einer kurzen Aufgabe im Vergleich zu einer langen einzuschätzen) bleibt dies ohne praktische Konsequenz, da die Mindest-Aufteilungszeit von 60 Minuten so klein im Vergleich zur Dauer des gesamten Projekts ist. Alle verbleibenden Probleme müssen ohnehin durch Kommunikation zwischen Management und Entwicklern gelöst werden, wie dem Entwickler mitzuteilen, dass er diese oder jene Aufgabe hätte aufteilen sollen, nachdem er wiederholt versäumt hat, dies zu tun.

Zusätzlich zur Erleichterung des effektiven & automatischen Informationsflusses zwischen Management und Entwicklern tendieren Mikro-Aufgaben in Kombination mit effektiver Aufsicht durch Entwicklungsleiter oder Management dazu, viele Fälle des Feststeckens zu vermeiden: Ein typisches Verhalten von Entwicklern ist es, an einer technisch anspruchsvollen Aufgabe weiterzuarbeiten, auch wenn sie völlig feststecken beim Umgang mit dem aktuellen Problem.

Meine Empfehlung ist das, was ich die 15-Minuten-Regel nenne: Sobald du innerhalb von 15 Minuten keinen messbaren Fortschritt bei einem Problem erzielen kannst, solltest du eine andere Aufgabe versuchen oder (falls nicht möglich) das Problem aus einem anderen Winkel angehen. Während dies erheblichen Interpretationsspielraum lässt und ohnehin eher als Heuristik denn als Regel behandelt werden sollte, hat die Selbst-Anwendung dieser Regel vielen unerfahrenen Entwicklern geholfen.

Mikro-Aufgaben befassen sich mit diesem Problem in einem Projektsetting, indem sie dem Management oder dem aufsichtsführenden Entwickler (je nach Projektgröße) erlauben, alle aktuell aktiven Aufgaben mit sehr kurzen Zykluszeiten von weniger als einer Stunde periodisch zu prüfen: Wenn es keinen Fortschritt bei einer Mikro-Aufgabe innerhalb von ein oder zwei Stunden gegeben hat, kann man erwarten, dass entweder der Entwickler die Aufgabe nicht richtig aufgeteilt hat oder er feststeckt und möglicherweise von der Unterstützung durch den in der Regel erfahreneren Supervisor profitieren könnte.

Ohne Mikro-Aufgaben variiert die Zeitspanne, in der man ein Feedback erwarten oder annehmen kann, dass festgesteckt wird, nicht nur stark je nach einzelner Aufgabe, sondern ist auch extrem lang — manchmal sogar Wochen oder Monate. Dies erhöht die Wahrscheinlichkeit, dass viel Zeit verloren geht, weil Entwickler lange Zeit an einer Aufgabe feststecken ohne messbaren Fortschritt. In der Praxis erweitern Mikro-Aufgaben das Werkzeugarsenal des aufsichtsführenden Entwicklers, indem sie Mittel bereitstellen, einzugreifen, bevor viel wertvolle Zeit verloren geht, während vermieden wird, dass die Arbeitsumgebung als überwachungsorientiert von den Entwicklern wahrgenommen wird.

Benutzerfreundlichkeit

Die Art, wie Redmine in vielen Unternehmen eingerichtet ist, macht es effektiv unwahrscheinlich, dass Personen, besonders nicht-technisch orientierte Personen, Redmine nutzen, um ihre Issues zu dokumentieren.

Beispiel 1: Redmine nur über VPN

Aus Sicherheitsgründen ist Redmine oft nur über ein Virtual Private Network verfügbar. Bezüglich der Benutzerfreundlichkeit hat dies den Effekt, dass ein Benutzer oft durch mehrere Sicherheitsebenen anmelden muss (VPN-Login, Redmine-Login).

Darüber hinaus erfordert der VPN-Client oft ein spezielles Setup, das nicht immer.

Ein besonderer Fall, an den ich mich erinnere, ist ein Unternehmen, in dem alle Projektmanagement-Tools nur über VPN zugänglich waren — und mein VPN-Account konnte nur einen Benutzer gleichzeitig verwalten. Wenn ich also von meinem Desktop zu meinem Notebook wechselte, konnte sich das VPN nicht verbinden und ich konnte Redmine nicht nutzen.

Sicherheit wird normalerweise durch wiederkehrende Überprüfungen durch Admins und/oder externe Spezialisten ausreichend gehandhabt — diese Überprüfungen sollten auch deine Website abdecken. Meine Hauptempfehlung bezüglich Redmine ist es, die Projekt-URLs (z.B. https://redmine.gridbox.de/projects/test) zu kopieren, wenn du eingeloggt bist, und sie in einem Inkognito-Modus-Fenster zu öffnen (wo du nicht eingeloggt bist). Wenn du das Login-Formular siehst, ist alles in Ordnung für dieses Projekt. Wenn du die Projekt-Übersichtsseite siehst, hast du das Projekt auf Public gesetzt — siehe oben, wie man das behebt.

Im Allgemeinen sollte Sicherheit nicht als Optimierungsziel konzipiert werden (wie es oft von technologieaffinen Personen getan wird), sondern eher als ein Tradeoff zwischen bestimmten Arten von Risiko und Benutzerfreundlichkeit. In diesem Kontext kann Benutzerfreundlichkeit als die Wahrscheinlichkeit modelliert werden, dass Personen ein Werkzeug oder einen Prozess freiwillig nutzen — oder, äquivalent, der Aufwand, den man betreiben muss, damit eine bestimmte Gruppe von Personen ein bestimmtes Werkzeug oder einen Prozess in einem gegebenen Ausmaß nutzt.

Dies impliziert, dass jede gebildete Diskussion über Sicherheit ein Modell des Risikos definieren muss, über das gesprochen wird, und die Personen, die. In vielen Fällen ist der Fehler, der besonders von technologisch affinen Personen gemacht wird, das Benutzerfreundlichkeitsmodell auf ihre eigene Eignung & Fähigkeit zu basieren, extrem suboptimale Werkzeuge effektiv zu nutzen, während manchmal ihr Risikomodell von dem Wunsch beeinflusst ist, besser zu sein als der aktuelle Stand des Marktes. Während beide Eigenschaften in fast jeder Hinsicht grundsätzlich wünschenswert sind, müssen praktische Unternehmen irgendwann den grundlegenden Sicherheit-Benutzerfreundlichkeit-Tradeoff machen, explizit oder implizit, ob sie es wollen oder nicht.

Beispiel 2: Zu wenige Privilegien in Redmine

Oft nehmen Redmine-Admins den Benutzern alle bis auf die offensichtlichsten erforderlichen Privilegien für alle Unterprojekte. Das bedeutet, dass Benutzer oft keine Beschreibungen bearbeiten, Issues nicht schließen oder wieder öffnen können. Selbst wenn sie den Admin kontaktieren können, um z.B. ein irrtümlich geschlossenes Issue wieder zu öffnen, werden Benutzer es nicht effektiv nutzen, aus einem gewissen Maß an Angst, etwas zu tun, das sie nicht selbst rückgängig machen können — und der sozialen Scham, den Admin deswegen kontaktieren zu müssen, selbst wenn der Admin sie nicht für ihr Verhalten zu verurteilen scheint.

Die einzige Aktion, die ich empfehle nicht zu erlauben, ist das Löschen (im Gegensatz zum Schließen) eines Issues, da dies sehr schwer wiederherzustellen ist. Es gibt bestimmte Projekte, in denen bestimmte (niedrige Ebene) Benutzer faktisch nichts tun sollten (z.B. könnte Marketing nur R&D-Informationen lesen, aber nicht dazu beitragen), aber in vielen Projekten gelten Einschränkungen für alle Projekte und hemmen die effektive Nutzung besonders durch nicht-technisches Personal in Projekten mit mehr als ~3 aktiven Teilnehmern.

Beispiel 3: Zu strenge Richtlinien für Redmine

Wenn man aktiv ein bestimmtes Format, eine Länge oder eine andere Politik für das Erstellen oder Aktualisieren von Tickets oder Dokumentation durchsetzt, schafft dies nicht nur eine erhebliche Eintrittsbarriere für neue Benutzer (die oft davon absehen werden, Projektmanagement-Tools ganz zu nutzen, außer auf dem Niveau, das aktiv durchgesetzt wird), sondern auch eine harte Mauer der Trennung zwischen den Veteranen (die die Regeln kennen, oder, wie einige sagen würden, die Interpretation der Regeln definieren) und allen anderen — wobei alle anderen mehr oder weniger Angst haben, den Regeln nicht folgen zu können, und daher davon absehen, es über das minimal durchgesetzte Niveau hinaus zu nutzen.

Zusätzlich, wenn du Richtlinien für das Format einer Dokumentation auferlegst, vergiss nicht, den Fall zu berücksichtigen, dass einige relevante Informationen nicht in ein vorgegebenes Schema passen könnten. Wenn du zu aggressiv bei der Durchsetzung der Politik bist, könnten wichtige Informationen verloren gehen, da sie aus Updates gestrichen werden. Daher solltest du immer ein zusätzliche Informationen-Feld in jedem vorgegebenen Format einschließen, auch wenn es oft missbraucht wird.

Beispiel: Ein Unternehmen setzt durch, dass Entwicklungs-Tickets nur durch Git-Commits geschlossen werden dürfen. Doch sie versäumten zu berücksichtigen, dass viele Bugs entweder versehentlich durch ein sekundäres Ticket ohne den anderen Entwickler, der das primäre Ticket kannte, behoben werden — oder auf einem Missverständnis beruhen und daher kein wirklich behebbarer Bug sind.

Die scheinbar gute Absicht, alle Tickets auf Git-Commits abbilden zu können, könnte daher dazu führen, dass entweder viele Tickets gar nicht geschlossen werden, oder auf eine andere weit vom Ideal entfernte Weise behandelt werden, während Personen nach einem Workaround für die Politik suchen. Der Unternehmensprozess zur Behebung der Richtlinien, sobald solche Fälle bekannt und dokumentiert sind, ist oft sowohl zu langsam als auch zu komplex für den Benutzer, um ihn im Vergleich zu einem schnellen Workaround zu nutzen. Langfristig wird der unbekannte Status eines großen Teils deines Bug-Trackers dich jedoch fast sicher einholen!

Stell es dir so vor: Dein Bugtracker könnte dasselbe Schicksal erleiden wie viele der klassischen Internet-Foren, die seit den frühen 2000ern allgegenwärtig sind: Wenn du eine Frage stellst, bekommst du nur eine Antwort wie

Use the search function ! What you are looking for has been answered SO MANY TIMES on this forum!

von einem Veteranen, wird dies wahrscheinlich die letzte Frage sein, die du freiwillig in besagtem Forum stellst.

Warum ist das so? Weil es nicht nur nicht so offensichtlich einfach ist, die Suchfunktion zu nutzen und tatsächlich sinnvolle Ergebnisse daraus zu ziehen, wie besagter Veteran impliziert (weil der neue Benutzer normalerweise nicht die richtige Frage kennt, d.h. nach welchen Begriffen er suchen soll), sondern besagter Veteran hätte genauso leicht 10 Sekunden seiner Zeit nutzen können, um dir ein oder zwei der scheinbar allgegenwärtigen Antwort-auf-deine-Frage-Links zu geben, um dich zumindest auf den Weg zu bringen.

Beispiel 4: Erzwungene Fristen

Ein Projekt, an das ich mich erinnere, hatte vorübergehend die Politik, dass jedes Ticket ein Fälligkeitsdatum haben soll, das höchstens 4 Wochen in der Zukunft liegt, um es über Gantt etc. in Erinnerung rufen zu können. Das hat nicht funktioniert, da ständige unnötige Update-E-Mails zur Verlängerung des Fälligkeitsdatums (z.B. für ein verschobenes Issue) alle Benutzer nervten. Auch,

Meine Empfehlung ist es, Fälligkeitsdaten nur dort zu verwenden, wo sie funktional impliziert und gleichzeitig funktional vom Projekt erforderlich sind. Beispiel: Wenn die Software in 6 Monaten geliefert werden muss, sollten die Kernfunktions-Implementierungsaufgaben vielleicht in 3 Monaten fällig sein.

Im Allgemeinen ist es ratsam, Meilensteine anstelle von Fälligkeitsdaten zu verwenden, um einen schlanken Entwicklungsprozess zu behalten und trotzdem den Fortschritt genau verfolgen zu können. Wenn du z.B. Fälligkeitsdaten für Tickets setzt, die zum nächsten Sprint gehören, hättest du genauso gut einen Meilenstein für besagten Sprint erstellen können, und so den Fortschritt genau verfolgen, während du das oft unrealistische Damoklesschwert der Fälligkeitsdaten aus dem Kopf des Entwicklers entfernst.

Stell es dir so vor: Der effektivste Weg, Menschen in besagtem Kontext zu motivieren, ist, dass alle auf ein gemeinsames Ziel (Meilenstein) hinarbeiten, anstatt dass jeder Angst hat, es nicht zu treffen und angeschrien zu werden. Komm nicht mit Argumenten wie Wir schreien nicht bei meinem Unternehmen. Selbst wenn es keinerlei explizit negative Reaktion gibt, werden unbewusste Reaktionen auf den negativen Motivationsversuch dein Ziel nicht leichter erreichbar machen — oder dein Projekt leichter zu managen.

Schlussfolgerung

Wenn du Werkzeuge für Menschen schwer nutzbar machst, werden Menschen die Werkzeuge nicht nutzen — oder sie nur in dem Ausmaß nutzen, das du aktiv durchsetzt. Da du besseres zu tun haben solltest, als die Nutzung von Werkzeugen durchzusetzen, versuche dein Bestes, sie nicht schwer nutzbar zu machen — und höre auf, Gründe zu erfinden, warum du sie scheinbar schwerer nutzbar machst.

In der Praxis reicht es oft aus, Verhalten, das mit einer Politik inkompatibel ist, nicht zu bestrafen, sondern stattdessen Verbesserung zu ermutigen & zu belohnen. Du könntest beispielsweise schlecht geschriebene Issues mit einer niedrigeren Priorität behandeln, bis sie verbessert werden, aber mach nie den Fehler, die Benutzer erziehen zu wollen, indem du sie abweisend behandelst.

Ein Demo-Projekt für alle Benutzer haben

Oft wenn du neue Benutzer in Redmine einführst oder neue Funktionen testen willst, kann ein Demo-Projekt sehr praktisch sein. Es ermöglicht dir, Funktionen zu testen und Benutzern zu zeigen, ohne realweltliche Konsequenzen, selbst wenn du etwas vermasselst. Gib allen Benutzern permanenten Zugriff auf das Demo-Projekt — damit sie bei Bedarf ebenfalls Dinge ausprobieren können.