Kinek való: terápiás vagy fejlesztő csoportok

Use case 9

Terápiás / fejlesztő csoport

Amikor a ritmus nem szervezési kérdés, hanem szakmai felelősség

Előtte: amikor „mindenkinek jut időpont”, de mégsem jó így

Egy terápiás vagy fejlesztő csoport szervezése nem kapacitásfeladatként indul.
Nem az a kérdés, hogy:

• hány alkalom van a naptárban,
• hány ember fér be,
• és hogyan lesz tele a hónap.

Hanem az, hogy:

• kiszámítható-e a jelenlét,
• kialakul-e a biztonságérzet,
• és fenntartható-e a folyamat.

Sok admin itt követi el az első – teljesen érthető – hibát:
ugyanúgy kezeli ezt a szolgáltatást, mint bármi mást.

Az eredmény:

• az egyik résztvevő két alkalmat kap egymás után,
• a másiknál hosszú kihagyás keletkezik,
• a csoport ritmusa felborul,
• és a szakembernek utólag kell „összetartania” a folyamatot.

Papíron minden rendben.
Emberileg nem.

A valódi probléma: a kiszámíthatatlanság terhel

Terápiás vagy fejlesztő helyzetben a résztvevő nem „beugrik”.
Ő készül.

Időt hagy:

• mentálisan,
• érzelmileg,
• sokszor fizikailag is.

Ha az alkalmak:

• túl közel kerülnek egymáshoz,
• majd hirtelen szétesnek,
• vagy nem követhető a mintázat,

akkor nő:

• a szorongás,
• a bizonytalanság,
• és a lemorzsolódás kockázata.

Ez már nem adminisztrációs kérdés.
Ez szakmai kockázat.

A szemléletváltás: a hónap, mint biztonságos keret

Ebben a use case-ben a rendszer nem sűrít, és nem is „optimalizál” látványosan.

Egyetlen dolgot tart szem előtt:

legyen ritmus.

Amikor az admin elindítja a havi tervezést, a rendszer:

• nem az első szabad időpontot keresi,
• nem próbál mindent minél előbb kiosztani,
• hanem figyeli, kinek mikor volt már alkalma.

A cél az, hogy:

• a résztvevők alkalmai egyenletesen kövessék egymást,
• ne alakuljon ki túl sűrű vagy túl ritka jelenlét,
• és a csoport egészének legyen „lélegzete”.

Hogyan működik ez a gyakorlatban?

A rendszer a hónapot egy folyamatként kezeli.

Amikor kioszt egy új alkalmat:

1. megnézi, az adott résztvevő mikor volt legutóbb,
2. figyelembe veszi a csoport többi tagjának ritmusát,
3. és olyan napot választ, ami nem bontja meg az egyensúlyt.

Ez azt jelenti, hogy:

• ha valaki már kapott alkalmat a hónap elején,
  a következő nem kerül közvetlenül mellé,
• ha valaki lemaradt, nem „betömjük”,
  hanem visszavezetjük a folyamatba.

Ez nem egyéni optimalizálás.
Ez csoportszintű felelősség.

Miért fontos, hogy itt nincs „kivételgyártás”?

Mert minden kivétel:

• felborítja a ritmust,
• új elvárásokat szül,
• és növeli az admin terhelését.

Ebben a működésben a rendszer:

• nem személyes döntésekből építkezik,
• nem fárad el,
• és nem enged a pillanatnyi nyomásnak.

A keret stabil marad.

Ez ad biztonságot:

• a résztvevőnek,
• a szakembernek,
• és az adminnak is.

Mit lát az admin a hónap végén?

Mielőtt a következő hónapot megtervezné, ezt látja:

• a csoport minden tagja kapott alkalmat,
• az alkalmak ritmusa követhető,
• nincs hirtelen torlódás vagy hosszú szünet,
• és nincs „miért maradt ki ő?” típusú kérdés.

A beosztás:

• nem csak logikus,
• hanem emberileg vállalható.

Ez az a pont, ahol az admin nem magyarázkodik,
hanem nyugodtan tovább tervez.

Miért nem alkalmas erre egy hagyományos naptár?

Mert egy naptár:

• időpontokat lát,
• nem lát terhelést,
• nem lát folyamatot.

Ez a működés viszont:

• látja az előzményeket,
• számol a következményekkel,
• és nem engedi, hogy a ritmus véletlenszerű legyen.

Ez nem „okosabb” rendszer.
Ez érzékenyebb.

Kinek való ez a működés?

Annak, aki:

• terápiás vagy fejlesztő csoportot vezet,
• felelősséget vállal a folyamatért,
• és nem engedheti meg, hogy az adminisztráció felülírja a szakmai szempontokat.

Egyetlen naptár esetén
ez Pro szint.

Több csoport párhuzamos tervezésénél
ez már Enterprise gondolkodás.