Workflows standardisieren » History » Sprint/Milestone 3
Thomas Carney, 06/03/2016 02:33 PM
1 | 2 | Thomas Carney | # Workflows standardisieren |
---|---|---|---|
2 | 1 | Thomas Carney | |
3 | 2 | Thomas Carney | Eine der Stärken Planios: Immerwiederkehrende Aufgaben zu Workflows machen. |
4 | 1 | Thomas Carney | |
5 | 2 | Thomas Carney | Wir erklären wie’s geht. Am Beispiel eines einfachen Workflows für Urlaubsanträge. Das Schöne ist auch hier gilt: Einmal gelernt, immer verstanden. Für Ihren persönlichen Workflow. |
6 | 1 | Thomas Carney | |
7 | {{>toc}} |
||
8 | |||
9 | 2 | Thomas Carney | ## Die Planio Workflow-Basics |
10 | 1 | Thomas Carney | |
11 | 2 | Thomas Carney | Die Idee dahinter: Jede Aufgabe gehört zu einem Tracker, der den Workflow definiert. Am besten wir schauen uns das mal genauer an: |
12 | 1 | Thomas Carney | |
13 | 2 | Thomas Carney | ### Tracker |
14 | 1 | Thomas Carney | |
15 | 2 | Thomas Carney | Für uns sind Tracker so etwas wie eine Art Überaufgabe. Deswegen gehört jede Einzel-Aufgabe immer zu **einem** Tracker. Sie ist somit Teil der Überaufgabe. Kleines Beispiel? **Supportanfragen**, **Software-Bugs** oder – richtig geraten – **Urlaubsanträge**. |
16 | 1 | Thomas Carney | |
17 | 2 | Thomas Carney | ### Status |
18 | 1 | Thomas Carney | |
19 | 2 | Thomas Carney | Der Status beschreibt die einzelnen Zustände einer Aufgabe in Planio – z. B. **Offen**, **In Bearbeitung** oder **Erledigt**. Jede Aufgabe kann immer nur einen Status haben, der sich dabei im Zuge der Aufgabenbearbeitung verändert. |
20 | 1 | Thomas Carney | |
21 | 2 | Thomas Carney | ### Rollen |
22 | 1 | Thomas Carney | |
23 | 2 | Thomas Carney | Nutzer haben ihren eigenen Planio Zugang. Für die Teilnahme an Projekten. Dabei nimmt jeder eine oder mehrere Rollen gleichzeitg ein – z. B. von **Manager** und **Mitarbeiter** bis hin zu anderen Rollen wie **Kunden**. Die Rolle gibt die Berechtigungen vor. Die Berechtigungen wiederum, was jeder einzelne Nutzer sehen und nicht sehen kann. Innerhalb eines Projektes definieren sie damit auch den Workflow der Nutzer. |
24 | 1 | Thomas Carney | |
25 | ### Workflows |
||
26 | |||
27 | 2 | Thomas Carney | Innerhalb eines Workflows kommt alles zusammen: Die auswählbaren Tracker, alle erlaubten Rollen sowie jeder mögliche Aufgaben-Status. Der Workflow gibt als vor, welchen der verfügbaren Status ich wählen kann. Oder welche Teile einer Aufgabe für mich sichtbar oder unsichtbar sind. |
28 | 1 | Thomas Carney | |
29 | 2 | Thomas Carney | Kompliziert? Keine Sorge. Wir führen Sie in Ruhe durch. Damit auch Sie in den Genuss einer der größten Stärken von Planio kommen. Los geht’s! |
30 | 1 | Thomas Carney | |
31 | 2 | Thomas Carney | ## Die Schritte zum Urlaubsantrag |
32 | 1 | Thomas Carney | |
33 | 2 | Thomas Carney | Sie träumen vom perfekten Strand in der Karibik? Wunderbar! Dann beantragen wir doch gemeinsam Ihren Urlaub: |
34 | 1 | Thomas Carney | |
35 | 2 | Thomas Carney | In den meisten Unternehmen wird der Urlaub üblicherweise vom Vorgesetzten genehmigt. In der Regel bedeutet das: Wir füllen den vorgedruckten Urlaubsantrag aus. Geben ein Start- und Enddatum an. Anschließend wird der Urlaub entweder genehmigt oder abgelehnt. Wenn der Antrag durch ist, können die Daten nicht mehr beliebig geändert werden. Falls der Urlaubsantrag abgelehnt wurde, ändern wir das Datum, hoffen das alles glatt geht und schwupp sind wir in der Karibik. Herrlich! |
36 | 1 | Thomas Carney | |
37 | 2 | Thomas Carney | Und jetzt zeigen wir Ihnen wie dieser Prozess in Form eines Workflows mit Planio umsetzen lässt. Natürlich mit Anzeige im Planio Kalender. Damit jeder weiß, wann jeder Urlaub hat. |
38 | 1 | Thomas Carney | |
39 | 2 | Thomas Carney | ## Die Werkzeuge: Tracker, Status, Rollen und Workflow |
40 | 1 | Thomas Carney | |
41 | 2 | Thomas Carney | Wir brauchen folgende Zutaten: Ein **Tracker** namens **Urlaubsantrag**. Den jeweils passenden Status – **Offen**, **Genehmigt** und **Abgelehnt**. Zwei Rollen: **Manager** und **Angestellte**. Und los! |
42 | 1 | Thomas Carney | |
43 | 2 | Thomas Carney | ### Tracker anlegen |
44 | 1 | Thomas Carney | |
45 | First things first. Let's get down to business: |
||
46 | |||
47 | 2 | Thomas Carney | - Bitte unter **Administration → Tracker** – Klick auf **Neuen Tracker** mit Namen Urlaubsantrag. |
48 | - **In der Roadmap** anzeigen bitte Häkchen weg, da wir keine Urlaube nicht in der Projekt-Roadmap benötigen. |
||
49 | - Häkchen weg in allen Standardfeldern, bis auf **Beginn** und **Abgabedatum**, die wir für Anfang und Ende unseres Urlaub nutzen werden. |
||
50 | - **Workflow kopieren von** – bitte nichts auswählen. Dann auf **Anlegen**. |
||
51 | 1 | Thomas Carney | |
52 | ![](creating_a\_new_tracker.png) |
||
53 | 2 | Thomas Carney | *So sieht Ihr Tracker jetzt aus* |
54 | 1 | Thomas Carney | |
55 | 2 | Thomas Carney | ### Aufgabenstatus anlegen |
56 | 1 | Thomas Carney | |
57 | 2 | Thomas Carney | Jetzt legen wir den passenden Status an für **Offen**, **Genehmigt** und **Abgelehnt:** |
58 | |||
59 | - Bitte unter **Administration → Aufgaben-Status** |
||
60 | 3 | Thomas Carney | - **Offen – gefunden?** Dann bitte Klick auf den Status. Und darauf achten, dass ein Häkchen gesetzt ist unter **Standardeinstellung**. Damit jede neue Aufgabe immer mit dem Status *Offen* beginnt. |
61 | - **Offen – nicht gefunden?** Dann bitte Klick auf **Neuer Status**, *Offen* in das Feld **Name** eintragen, Häkchen unter **Standardeinstellung** setzen. Kein Häkchen bei **Zu allen Workflows hinzufügen**, wir wollen ja hier speziell den *Urlaubsantrags-Workflow* anlegen. |
||
62 | - Klick auf **Anlegen** oder bzw. auf Neuer Status. |
||
63 | - Status für **Genehmigt** und **Abgelehnt** genauso wie bei Offen anlegen und darauf achten, dass bei **Genehmigt** ein Häkchen gesetzt ist unter **Aufgabe erledigt**. Und darauf achten: Genehmigt oder Abgelehnt nicht als Standardeinstellung speichern. |
||
64 | 1 | Thomas Carney | |
65 | ![](create_an_issue_status.png) |
||
66 | 3 | Thomas Carney | *So sieht der Status Genehmigt aus* |
67 | 1 | Thomas Carney | |
68 | 3 | Thomas Carney | ### Rollen anlegen |
69 | 1 | Thomas Carney | |
70 | 3 | Thomas Carney | Das hier wird schön einfach: |
71 | 1 | Thomas Carney | |
72 | 3 | Thomas Carney | - Bitte unter **Administration → Rollen und Rechte** |
73 | - **Manager und Mitarbeiter – gefunden?** Dann haben Sie diesen Schritt schon geschafft. In der Regel sind beide Rolle bereits voreingestellt. |
||
74 | - **Manager und Mitarbeiter – nicht gefunden?** Dann bitte Klick auf Neue Rolle, Mitarbeiter in das Feld Name eintragen, den Rest ignorieren. Aber sicherstellen, das Häkchen gesetzt sind bei **Kalender ansehen, Aufgaben anzeigen** und **Aufgaben hinzufügen** gesetzt sind. Bitte Häkchen für beide Rollen setzen. |
||
75 | 1 | Thomas Carney | |
76 | ![](how_to_add_a\_role.png) |
||
77 | 3 | Thomas Carney | *Eine neue Rolle anlegen* |
78 | 1 | Thomas Carney | |
79 | ### Define the workflow |
||
80 | |||
81 | This is the fun part. Here is where it all comes together. |
||
82 | |||
83 | - Navigate to **Administration** -\> **Workflow**. |
||
84 | - Select the *Staff* role and your *Vacation request* tracker. |
||
85 | - Uncheck the **Only display statuses that are used by this tracker** checkbox and click on **Edit**. |
||
86 | - The checkbox matrix that appears lets you configure all allowed status transitions for a given role and tracker. For instance, the *Staff* workflow should have the checkbox at the lower left checked. This means that members having the role *Staff* can set an issue having a **current status** of *Rejected* back to *Open*. |
||
87 | - Now, let's configure the *Staff* workflow according to the following screenshot: |
||
88 | ![](vacation_request_workflow_for_staff.png) |
||
89 | *Workflow for Staff role* |
||
90 | - Click on **Save**. |
||
91 | - Next, select *Manager* as a role, make sure the **Only display statuses that are used by this tracker** checkbox is unchecked click on **Edit** again. |
||
92 | - Configure the *Manager* workflow according to the following screenshot: |
||
93 | ![](vacation_request_workflow_for_manager.png) |
||
94 | *Workflow for Manager role* |
||
95 | - Click on **Save**. |
||
96 | |||
97 | Wait, what did we just do? Have a look at the screenshots again. What we defined is: |
||
98 | |||
99 | - *Managers* can set an open vacation request to *Approved* or *Rejected* and a *Rejected* vacation request to *Approved* (in case they changed their mind). |
||
100 | - *Staff* can only set a *Rejected* vacation request back to *Open*. (This is for when they change their dates and want to re-request approval.) |
||
101 | |||
102 | ### Adapt fields permissions |
||
103 | |||
104 | Now, let's customize the issue form fields a bit according to the issue status. |
||
105 | |||
106 | - Still on the **Workflow** screen, select the **Fields permissions** tab. |
||
107 | - For *Manager*, set everything to *read-only* except the **Subject**: |
||
108 | ![](fields_permissions_manager.png) |
||
109 | *Fields permissions for Manager role* |
||
110 | - For *Staff*, do the same except for the **Start date** and **Due date** fields: |
||
111 | ![](fields_permissions_staff.png) |
||
112 | *Fields permissions for Staff role* |
||
113 | This makes sure only *Staff* can actually set the dates for a vacation request and that those dates cannot be changed anymore, once approved. |
||
114 | |||
115 | ## Put it all to work in an actual project |
||
116 | |||
117 | That's enough of prep work. Let's try it out. |
||
118 | |||
119 | - Start by creating a new project via **Projects** -\> **New project**. |
||
120 | - Give your project a name, e.g. **Vacation planning**. |
||
121 | - Disable all modules but **Issue tracking** and **Calendar**. |
||
122 | - Select only your **Vacation request** tracker and nothing else. |
||
123 | - Click **Create**. |
||
124 | |||
125 | That's it, you're done. Your users can now use this project for your new vacation request planning workflow. In order to submit a vacation request, all they'd have to do is create a new issue. Selecting a **start date** and a **due date** will be required when creating *vacation request* issues and all other useless fields will be hidden. |
||
126 | |||
127 | ![](new_issue_form.png) |
||
128 | *Stripped down issue form for vacation requests* |
||
129 | |||
130 | In order to try it out for yourself and play around with it, we recommend you create two users that have no administrator privileges and add the as *Staff* and *Manager* to your project respectively. |
||
131 | |||
132 | (If you try it out as an administrator, don't be alarmed by the fact that you can always choose from all statuses when updating an issue. That's normal if you're an admin. Regular users will only see the statuses as defined by their workflow.) |
||
133 | |||
134 | ### Bonus: The calendar view |
||
135 | |||
136 | What's up with the **Calendar** module we've enabled in the roles and your project, you ask yourself? Well, after adding a couple of vacation requests, check out the **Calendar** tab in your project. The Planio calendar will give you a nice monthly overview of all vacation requests which have been tracked. |
||
137 | |||
138 | ![](vacation_calendar.png) |
||
139 | *Vacation calendar view in Planio* |
||
140 | |||
141 | By using a [custom query](http://plan.io/blog/post/25072622222/trackers-viewing-and-grouping), you can even create a calendar view that displays only approved vacation requests. Or create a query for your managers that shows only *Open* requests that have to be approved still. |