Oh man, die Schneide ist runter. Ach ja,
aber das ist mir nichts, was kann das denn jetzt raushauen?
Das reicht noch. Ja, ich glaube, das geht, ne?
Das ist der Kack und so, das war ich zusammen.
Abwehr manchmal, ja. Na, Maus ist zwar
egal. Egal. Das stört er nicht. So,
also ich hatte mich ja schon kurz vorgestellt. Johannes,
mein Name, ich will ein bisschen was erzählen.
Und zwar, ich habe das jetzt genannt, Design-Team,
Without Design-Team, über den Hintergrund erzähle ich noch ein bisschen.
Und wollte einfach so ein bisschen unseren Erfahrungsbericht erzählen,
wie wir als Designer jetzt hier in verschiedenen Teams arbeiten,
also nicht mehr als reines Design-Team.
Was wir uns da so überlegt haben,
was wir da für Probleme hatten und so weiter.
Deswegen würde ich erstmal gerne von euch wissen,
wer von euch ist denn ein Designer?
Vielleicht mal so kurz checken, okay? Ja. Glaube
ich nicht. Wer ist Entwickler? Gibt es noch was
anderes? Kann ich Konzeption? Alles klar. Gibt es
Produktmanagers im Produktmanager anwesend
Alles klar. Ich wollte das nur... Nee, nee,
lach, Quatsch. Ich wollte das nur kurz wissen.
Ich glaube, dann werdet ihr einiges wiedererkennen. So,
also ich fange einfach mal an. Mit einem Blick zurück
. Also als ich vor vier Jahren hier angefangen bin,
waren wir ungefähr 30 Leute. Ich weiß keine genauen Zahlen,
vielleicht zehn Entwickler und irgendwie zwei Designer und noch Supporter und so weiter.
Und da waren so Strukturen noch ein bisschen anders.
Wir hatten nämlich ein großes Entwicklerteam eigentlich und ein etwaes kleineres Designerteam.
Und Das funktioniert dann vielleicht so, dass zum Beispiel ein Entwickler sagt so,
ey, wir haben was Geiles gebaut, mach das doch mal schön.
So war das. Warum ist fertig eigentlich eingeladen? Ja,
und dann hat das Design-Team gesagt,
und Designer sagen dann oft ganze, ja, super,
aber aus Jose Willigs Gesicht, bla, bla, bla,
warum habt ihr denn das, bla, bla, bla,
bla, bla? Kann man das grundsätzlich nicht vielleicht auch,
bla, bla,
bla.
Ich weiß, es ist jetzt schon implementiert,
aber bla, bla, bla, bla,
bla.
Also,
wer kennt das
Hat jeder schon mal gehört, ne? Ja. Und
das ist schlecht. Also es ist natürlich nicht immer so gelaufen,
aber das ist halt sowas, was halt oft so läuft.
Und das ist einfach auch in kleineren Teams schon ein Problem,
weil im Endeffekt ist ein Team immer das Bottleneck,
weil dann sagen vielleicht die Designer, ja,
wir würden das Interface mal gerne grundsätzlich ändern, bla bla bla.
Und die Entwickler sagen natürlich, und das auch zu Recht,
oh, schöne Idee, leider nein, keine Prio,
geht auch komplett andersrum, dass die Entwickler sagen,
ja, Das Interface müsste mal überarbeitet werden.
Und dann sagen die, dass einer, ja,
aber wir sind gerade an einem anderen Projekt dran,
das hat Prio und übrigens brauchen wir dann auch Entwicklerressourcen.
Und ja, da, das funktioniert so nicht so gut.
Und also, das Resultat ist natürlich,
dass dann solche Entscheidungen immer nach oben delegiert wird.
Oben ist bei uns im Endeffekt die Gründer so.
Und irgendein Team ist immer das Bottleneck.
Und das ist halt blöd. Jetzt kommt noch dazu,
dass wir natürlich in den letzten Jahren sehr gewachsen sind.
Ich habe erzählt, wir waren angefangen, wir waren mal 20,
30 Leute, jetzt sind wir hier, 150,
glaube ich, um den Dreh,
oder 140.
Und das wird halt
immer schwieriger
Und deswegen hatten wir eine schlaue Idee. Und zwar haben wir gedacht,
wir bauen Teams. Schon mal ganz gut. Und zwar,
wir bauen Teams um, bestimmte Themen herum,
wo es halt vorher so war, dass wir gesagt haben,
okay, wir machen was, wir bauen jetzt was,
irgendwie beispielsweise an dem Shop-Modul, dann,
ich gehe nochmal zurück.
Oh nein, nein, nein, nein, nein,
nein, nein, nein. So, ich baue was am Shop-Modul,
wir brauchen Designer und dann haben wir wieder das gleiche Problem.
Die müssen, also ist halt nicht so super. So,
also Teams, und zwar, wir packen in die Teams alle Leute,
die dieses Team braucht, um autark arbeiten zu können.
Also packen wir ein paar Entwickler rein. Und wir packen da
noch einen Designer rein. Und natürlich auch noch andere Leute.
Aber ich bin Designer und hier geht es um Design-Entwickler,
deswegen habe ich die mal rausgelassen. So,
und die Idee ist natürlich, dass diese Teams für sich
ihre eigenen Ideen verwirklichen können und schnell arbeiten können.
Und diese Abhängigkeiten, die ich gerade erzähle,
zwischen den einzelnen Teams einfach nicht passieren und dass kein
Team zum Bottleneck wählt sozusagen
Und das ist es von der Idee super.
Deswegen bauen wir mehr davon. Wichtige Kernkomponenten, die
irgendwie unabhängig voneinander arbeiten können. Warum wir Teams mit mehr
oder weniger Designern und mit mehr oder weniger Entwicklern und Supportern
und was sonst noch alles gebraucht wird in diesem Team.
Super Idee. Soweit so gut. Also hat natürlich Vorteile,
liegen auch auf der Hand, Verantwortlichkeiten werden besser verteilt.
Das heißt, das Team ist halt nur für seinen begrenzten
Bereich verantwortlich. Man hat eine größere Fokussierung. Man muss
sich halt nicht, das ist der dritte Punkt,
man muss sich nicht
um alles kümmern
Vorher ist es halt so, also wir waren halt ein Design-Team und alles,
was irgendwie nach Design riecht, muss dann von dem Design-Team gemacht werden.
Und dann hat man natürlich immer im Hinterkopf, ja,
aber wir wollten ja eigentlich noch den Sign-Up verbessern.
Und der Checkout-Prozess ist nicht so super. Und das Modulsystem eigentlich,
da können wir auch noch mal ran und so weiter.
Aber man baut sich halt immer nur so einen Riesenhaufen an
To-dos auf und irgendwann verliert man auch den Glauben daran,
dass man das einfach gut umsetzen kann.
Das hat man dann natürlich nicht mehr,
weil ich muss mich jetzt nicht mehr darum kümmern,
was im anderen Team, was sehr gemacht wird,
ich vertraue dem Team einfach,
die haben halt alles,
was sie brauchen,
um da weiterzukommen
Das ist gut. Und deswegen können diese Teams halt einfach
Geschwindigkeit aufnehmen. Genau. So, das hat aber,
und jetzt spreche ich halt so aus der Designperspektive,
weil ich Designer bin, hat das halt auch Nachteile.
Also wir haben jetzt kein Design-Team mehr, das heißt,
wie gehen wir denn überhaupt mit Feedback um?
Die Designer werden das kennen, wenn man im Design-Team arbeitet,
ist das halt einfach so,
also das,
was die Entwickler mit Pair-Programming jetzt machen und was halt der geilste Shit ist,
macht man als Designer eigentlich in einem Team ständig
Zu zweit vorm Rechner, guckt sich die Sachen an,
wenn ich irgendeine Idee habe,
dann lasse ich einen rübergucken und der sagt dann, ja, nee.
Also und wenn der halt das nicht in der Luft zerreißt,
ist das eigentlich ein gutes Zeichen.
Also dann kann man so viel nicht falsch gemacht haben.
Dieses Feedback hat man natürlich nicht mehr.
Also außer ich bin zu mehreren Designern in einem Team,
aber das ist halt auch eine Ressourcenfrage und eher der Ausnahmefall.
Also wie mache ich das? Wie hole ich mir Feedback von
meinen Designkollegen vor allen Dingen ab? Zweiter wichtiger Punkt ist,
wer macht denn eigentlich den Kram, für den es kein Team gibt?
Weil es gibt immer wieder Aufgaben, die auf ein Design-Team zukommen,
wir jetzt gerade nicht die Ressourcen haben, da ein Team für zu machen.
Zum Beispiel Country-Manager brauchen für irgendeine Veranstaltung Pressematerial,
das muss ausgedruckt werden zum Beispiel. Oder schönes Beispiel,
Weihnachten ist wieder da, wir müssen ja noch eine Weihnachtskarte machen.
Und dafür macht es halt wenig Sinn, im Endeffekt ein Team zu bauen,
aber das muss halt irgendwie trotzdem gemacht werden.
Weiterer wichtiger Punkt, wie funktioniert die Synchronisation zwischen den Designern?
Das heißt, wenn wir jetzt zwei Teams haben, die an ähnlichen Sachen arbeiten.
Also jetzt ein Beispiel, wir haben ein Team,
das arbeitet an dem Shop-Bereich so und wir haben ein zweites Team,
das arbeitet an unserem Modulsystem im CMS.
Das ist im Endeffekt arbeiten die an gleichen Sachen,
aber in verschiedenen Teams und Konsistenz und Design ist natürlich,
also das will man gerade in so einem Produkt einfach hochhalten,
das muss und aufrechthalten,
da muss es eine Synchronisation,
eine sinnvolle Absprache geben
So, da muss man sich auch irgendwie drum kümmern.
Einheitliche Qualitätskriterien ist auch so ein Punkt,
wenn ich mit Designern in einem Team arbeite wie früher,
dann ist das nicht so ein Problem,
weil da sitzen dann vier, fünf Leute,
relativ eng zusammen, gucken sich ständig auf den Rechner,
können sich über den Tisch Sachen zu rufen sozusagen.
Da will man auch keine schlechtere Arbeit abliefern als sein Kollege.
Also das ist halt, es passiert im gewissen Weise automatisch.
Natürlich machen einheitliche Qualitätskriterien sowieso Sinn,
aber das wird jetzt natürlich zum größeren Problem
Weil ich habe verschiedene Teams, die Designer sitzen räumlich getrennt,
verschiedene Stockwerke und so weiter.
Und der Designer muss sich mit seinem eigenen Team,
also mit den Entwicklern in seinem Team und so weiter, absprechen.
Wie wird denn das, wie wir da eine einheitliche Qualität
gewährleistet über verschiedene Teams sind weg?
Ja, und das Teamgefühl geht verloren. Es gibt halt
kein Design-Team mehr. Das ist auch irgendwie schade. Genau,
also das sind so die Punkte, die wir jetzt gedacht haben,
naja, das ist einfach schade.
Und da wollen wir jetzt irgendwie einen Weg finden,
wie wir das denn wieder aufholen können
So, und dann haben wir gedacht, juhu,
Community of Practice, was ist denn das?
Das ist ja super. Die Wikipedia sagt,
in so einem Satz, a group of people,
share a craft our profession. Wir sind alle Designer,
das passt, also probieren wir das mal aus.
Da gibt es auch bestimmt eine Menge Theorie von,
wenn ihr das bei Wikipedia eingibt, dann könnt ihr das alles lesen.
Da gibt es Leute, die haben da irgendwie Destinationen drüber
geschrieben und so weiter und so fort.
Ich habe das alles nicht gelesen. Das Einzige,
was ich über diese Community of Practice wusste und immer noch weiß,
außer meinen eigenen Erfahrungen,
ist das,
was da steht
Und das wussten wir eigentlich auch nur alle, bevor wir das mal versucht haben.
Und also haben wir angefangen. Was heißt denn das für uns,
Community of Practice? Also was machen wir denn da?
Und was wollen wir damit eigentlich erreichen? Also das ist,
haben wir gedacht, das ist sinnvoll,
dass wir alle Designer aus allen Teams uns regelmäßig treffen,
soweit, so gut.
Wir wollen in diesem Umfeld unsere Themen bearbeiten,
also wirklich Design-Themen, die uns alle betreffen.
Wir wollen eine Richtung festlegen. Das heißt,
wir wollen eigentlich alle gemeinsam ein Gefühl haben,
wo wollen wir denn mit unserem Design und mit unserer Gestaltung
an allen Komponenten,
wo wollen wir da eigentlich hin
Wir wollen auch Sparrings-Partner haben. Das ist auch das,
was ich vorhin meinte. Ich möchte auch irgendwie mich mit anderen Designern austauschen.
Ich möchte halt, was machst du denn gerade?
Und wie hast du das gelöst und so weiter?
Da will ich halt dran wachsen. Und wir wollen diese
eine Entscheidung treffen. Also Logo, CI und so weiter.
Bitte. Seid ihr denn in dieser Konnotierungsspekte? Oh,
zehn? Zehn. Zehn Leute ungefähr. Also da sind jetzt auch nicht,
also es sind Designer drin,
wir haben aber auch noch Leute drin,
die zum Beispiel Video machen,
weil sich da sehr viel überschneidet,
weil es da
sehr viel Überschneidung gibt
Und genau. Gibt es dazu erstmal noch Fragen?
Was heißt regelmäßig? Bei uns jetzt,
also bei uns heißt das momentan wöchentlich, da komme ich
aber gleich noch zu, das war nicht immer so.
Das ist jetzt auch, was es folgt, ist so
wie wir das gemacht haben. Ich habe vorher kein Regelwerk gelesen,
wie man das machen soll,
sondern wir haben das einfach für uns ausprobiert und das ist
glaube ich auch ganz wichtig im Hinterkopf zu haben,
dass man das immer auf die eigenen Bedürfnisse anspricht.
Das ist halt im Endeffekt jetzt nur ein Erfahrungsbericht,
so haben wir es gemacht,
das ist
nicht für jeden gültig
Aber vielleicht kann der eine oder andere was lernen,
wenn er ähnliche Probleme hat. Da muss man auch
dazu sagen, wie wir selbst lernen, da auch.
Richtig. Wir machen das jetzt mal auf der Zeit lang,
aber wir hassen das auch in regelmäßigen Abständen schon wieder an.
Genauso muss man es halt auch wieder dann,
dass Johannes dann erzählt hat, ja auch sich anpassen.
Und auch da wahrscheinlich würde man nicht sagen, wir fangen
jetzt so mit ein. Und das geht dann immer,
wir sind alle hier gegangen, sondern so,
sondern man ist halt ein Prozess auch an dieser Stelle.
Genau. Ja? Ich halte eine kleine Frage. Es waren ein paar Slider vorher,
aber er ist, du hast gesagt, Design ist,
arbeiten zusammen oder entwickle es zusammen in ein Team.
Aber du hast einmal zwei Designs in einem Team.
Bis dann. Wie geht das? Meine arbeiten Sie auf die gleiche Projekte? Ja,
also das mit den Teams musst du dir so vorstellen,
dass wir einfach, also im Mittelpunkt des Teams steht halt ein Thema.
Das ist ganz wichtig. Also wir sagen, Beispiel,
wir wollen denen unser Shop-System voranbringen.
Also gibt es ein Team dazu und dann wird geschaut,
was brauchen wir denn überhaupt, damit ein Team,
unabhängig dieses Shop-System voranbringen kann.
Und manche Teams brauchen halt vielleicht nur einen Designer,
weil es halt nicht so interface-lastig ist oder weil es halt eher ein technisches Thema ist.
Es gibt auch Teams, die brauchen gar keinen Designer.
Aber es gibt auch Teams, die brauchen zwei,
weil sie halt sehr viel Interface zum Beispiel machen.
Es ist halt immer abhängig von den Anforderungen,
die in diesem Team einfach entstehen.
Aber sie arbeiten zusammen. Sie arbeiten zusammen. Also ein
Team sitzt auch immer in einem Raum oder also an einem Tisch.
Also das ist halt auch wirklich lokal zusammen an einem Projekt.
So. Genau, das sind so so Genau,
das wollen wir damit erreichen. Dann haben wir uns überlegt,
wie sieht denn das für uns jetzt erst mal aus?
So, stark. Ich bin auch Designer. Ja.
Ja, und zwar deine, mein Freund. So,
wir haben uns überlegt, okay, wir wollen ein moderiertes Meeting haben.
Dazu muss man sagen, das ist was,
wo wir auch ein großes Glück haben,
dass es bei uns in der Firma sehr stark gefördert wird.
Wir sind der Überzeugung in jedem Meeting,
dass es Sinn macht,
ein Meeting zu moderieren
Hier haben wir uns entschlossen,
dass immer einer aus dieser Community of Practice das moderiert,
dessen Aufgabe ist, dieses Meeting vorzubereiten, dass alles da ist.
Er soll sich selber aus dieser Diskussion ein bisschen zurücknehmen.
Er soll die Agenda erstellen und so weiter und so fort.
Und er soll auch auf die Timebox achten,
das ist ganz wichtig, damit wir halt in diesem Zeitraum,
den wir uns dafür abstecken für dieses Meeting,
damit wir da auch durchkommen.
Da gibt es auch einen Artikel für in dem 3Founders-Blog,
wo nochmal über moderierte Meetings eine Menge steht,
habe ich den Link jetzt nicht da.
Aber findet man bestimmt,
kann ich auch noch nachreichen
Genau, wir wollen halt dieses moderierte Meeting haben.
Der Turnus haben wir erstmal auf wöchentlich gestellt sozusagen, zwei Stunden.
Und wir haben uns überlegt, wir machen zwei Formate,
merkt schon, das ist schon sehr kompliziert jetzt.
Wir machen zwei Formate und die machen wir abwechselnd jede Woche.
Also Format A, ich fange mit Format B an, das ist einfacher.
Vom MFB, Format B ist einfach eine Feedback-Runde.
Ich hatte ja vorhin gesagt, wir wollen einfach Spellingspartner haben,
wir wollen dieses Feedback haben, was wir in unserem Designteam vorher hatten.
Also treffen wir uns für zwei Stunden, stellen uns alle so Sachen,
die wir in der Zeit in unseren eigenen Teams gemacht haben, vor und sammeln Feedback ein und so weiter.
Das war so erstmal geplant und ganz offen gelassen und das haben wir versucht. Das andere Format war eher durchstrukturiert und hat gesagt,
okay, diese zwei Stunden nutzen wir folgendermaßen,
wir beginnen mit einem Madset-Gläd, also für die,
die das nicht kennen, das ist so eine Methode,
wo man einfach erstmal am Anfang auf Zettel schreibt,
was hat mich in dem letzten Tonus,
also in den letzten zwei Wochen wütend gemacht,
was hat mich traurig gemacht, was hat mich glücklich gemacht,
dann wird das an die Wand gepackt,
dann wird das nach Themen geordnet Und dann sieht man,
wo sind denn jetzt Problemfelder im Team?
Was müssen wir demnächst anfassen, um da halt Lösungen zu finden?
Danach haben wir uns das so vorgestellt,
dass wir dann diese Themen,
die auf der Agenda sind oder die über dieses Madshead Glädt aufgepoppt sind sozusagen,
dass wir die bearbeiten, danach Maßnahmen beschließen.
Und genau, dann noch ein paar Planungssachen machen.
Wir wollen noch einen Moderator für das nächste Mal beschließen und
den Termin festlegen und so weiter und so fort.
Das war so, wie wir uns das vorgestellt haben
Einfach so mal die Planung. So. Genau, so war die Theorie.
Da haben wir angefangen. Also wir haben das so,
also wir haben im Endeffekt mit diesem, mit diesem,
mit einem Madset Glad angefangen, bei unserem ersten Meeting und haben gesagt,
was sind denn die Sachen, die uns als Designer in allen Teams stören?
Und dann haben wir halt, haben wir das gesammelt,
dann haben wir das, haben wir das mit,
also haben wir das gevotet, welche Themen sind die wichtigsten?
Und dann kam im Endeffekt so eine Agenda raus,
also diese Themen wollen wir jetzt als Community of Practice für Design.
Bei Jimlo wollen wir bearbeiten. Das tut so ein bisschen weh.
Also wir wollen natürlich erstmal eine Vision haben. Dateiablage ist auch so ein Thema,
was halt interessant wird,
wenn man nicht mehr zusammen in einem Team arbeitet,
weil wenn man im Team arbeitet, ist so eine schlechte Dateiablage durchaus,
also ist wahrscheinlich immer da, aber wenn ich halt rüberrufe zum Kollegen,
sage, hier, wo ist Datei XYZ,
dann weißt du das komischerweise immer.
Und dann ist das ganz gut, wenn ich das nicht mehr kann,
stehe ich doof da. Dokumentation, QA brauche ich,
glaube ich, nicht viel zu sagen. Jimlo CI,
da gab es kein Team für, da mussten wir auch
so ein bisschen ein paar Entscheidungen treffen und so weiter und so fort.
Designsupport Hat ein bisschen auch was. Also wir haben halt
einen Design-Support bei uns, das heißt Support-Anfragen aus anderen Teams,
die irgendwas mit Design zu tun haben, kommen erstmal bei uns an.
Die Frage ist, wie regeln wir das und so weiter.
Schulung, Teambuilding ist, glaube ich, klar. So,
das hat eigentlich ganz gut geklappt beim ersten Mal. So,
und dann haben wir gesagt,
okay, dann haben wir dann das nächste Mal,
haben wir halt diese Feedback-Runde gemacht, die war schon ein bisschen schwieriger,
weil zehn Designer in einem Raum, geben sich alle gegenseitig Feedback,
zwei Stunden sind da relativ kurz.
Also das kann man durchaus einen ganzen Tag machen,
glaube ich
Dann haben wir uns überlegt, machen wir jetzt mit der Vision weiter,
klar, fangen wir mit an, Mets at Glad,
okay, alles gut,
dann bearbeiten wir jetzt das Thema Vision für unser Team,
also für unser Community, für unsere Communitive Practice für Design.
Und das ist gehörig, ja, schiefgelaufen würde ich nicht sagen,
wir hatten zum Schluss eine Vision, aber das hat mehr
als zwei Stunden gedauert und mehr als diesen einen Termin.
Und da haben wir schon gemerkt, so richtig geil funktioniert das jetzt nicht.
Ja, weil so war das jetzt die Vision,
was wir als Klima machen wollt oder wir mit schönen Halloween
Wo wir mit Jimlo insgesamt hin, also aus Design-Perspektive hinwollen,
weil im Endeffekt, wir sind ja kein Design-Team an sich,
aber trotzdem gibt es ja übergeordnete Themen,
die Designer durchaus ansprechen wollen, welche Richtung gehen wir,
wie wollen wir uns nach außen präsentieren,
wie wollen wir kommunizieren mit den Nutzern und so weiter.
Und wie soll das in unser Design und unsere tagtägliche Gestaltung in allen Teams mit einfließen?
Darum ging es im Endeffekt. Und das war wirklich gar
nicht so einfach. Und da haben wir schon gemerkt,
naja, Das ist so ein bisschen schwierig.
Und da hatten wir auch Probleme mit dem, was wir
vorher uns überlegt haben, zum Beispiel dieser zweiwöchige Tournus.
Wie machen wir das denn eigentlich, wenn jetzt ein Designer krank ist?
Und danach hat er Urlaub. Und dann wurde aber in
so einem Community of Fractice-Meeting was beschlossen,
was ihn auch und sein Team irgendwie betrifft.
Und er ist da gar nicht mit einverstanden. Das ist
auch irgendwie doof. Das muss man auch irgendwie anders machen.
Und irgendwie kam das nicht so richtig hin.
Und dann haben wir uns überlegt, okay, ah,
da habe ich nochmal Probleme
Ich hatte es ja schon gesagt, Diskussionen statt Lösungen,
war halt eines dieser Probleme. Das heißt,
wir haben immer sehr viel diskutiert, zu zehnt und so weiter,
über bestimmte Themen und kamen nicht so recht zu Lösungen, ja.
Das ist eine Frage, wenn er zum Beispiel in der
Feierablage als Thema 2020 dann austauscht und die anderen von denen ist,
bei denen er den Mittlerweiler genau das zweite Problem war.
Wie geht es um damit, wenn irgendeine Probleme identifiziert,
tatsächlich in die anderen Teams, gegen so meinen Arpetit.
Ja, also die Idee ist natürlich, wenn wir da eine Lösung gearbeiten,
die so gut ist, dass sie auch die Entwickler interessieren,
dass das natürlich der jeweilige Designer mit in sein Team trägt.
Aber da ging es um erster Linie,
um unser eigenes Datei, System, also unsere eigene Dateiablage,
die halt schon über Jahre auch gewachsen war,
wo wir sagen, okay, unsere Logos liegen da,
die PSD ist für, bla bla bla,
liegen da und das Pressematerial liegt da.
Und genau, also da ging es halt wirklich erstmal um unsere Sachen.
Nachhaltigkeit, das ist so ein bisschen das Ding,
wo ich gerade meinte, dieser zweiwöchige Turnus,
die Leute müssen ja auch nach zwei Wochen dann auch irgendwie wissen,
über was haben die denn geredet. Was machen wir denn,
wenn wir jetzt in diesen zwei Stunden zu keiner Lösung kommen,
dann müssen wir ja wieder zwei Wochen warten,
um da jetzt weiter zu diskutieren, das blockt ja auch total.
Gerade wenn es halt ein wichtiges Thema ist. Zudem haben wir auch gemerkt,
dieses Feedback, was wir auch gemacht haben,
das war diese Variante B, die ich vorhin gesagt habe,
das funktioniert auch gar nicht, weil wir standen da und haben uns,
also das erste Problem war, wenn wir uns gegenseitig unser Designarbeiten zeigen,
dann ist dann,
dann ist das vielleicht schon live.
Dann stehen wir halt so ein bisschen da. Also das
ist halt irgendwie ein bisschen zu spät nach zwei Wochen vielleicht.
Also das ist halt so ein bisschen ein Problem
Also, was haben wir gemacht? Hier ist nochmal das,
was wir uns am Anfang überlegt haben. Moderiertes Meeting ist super,
das machen wir weiter. Den Turnus haben wir auch gelassen,
haben nur das Meeting auf eine Stunde begrenzt.
Dafür haben wir aber dieses zweite Format, diese Feedback-Runde,
haben wir erstmal aus unserem COP rausgenommen und haben dafür gesagt,
okay, wir machen das anders.
Wir reservieren uns im Kalender, einen bestimmten Zeitraum am Tag X,
so, zwei Stunden und je nach Bedarf kann dann,
können wir dann uns irgendwie zu zweit oder so zusammensetzen und mal überarbeiten, rübergucken.
Weil ein Problem ist natürlich, Feedback will man haben,
aber nicht von zehn Leuten gleichzeitig,
sondern ich will eigentlich mich mit einem darüber unterhalten,
das würde ich mitnehmen, dann gehe ich vielleicht noch zu einem zweiten, so.
Das ist eigentlich ganz logisch, so. Aber extra ist,
wenn es um... Genau, also ich will halt Feedback haben,
wenn ich es brauche, ja, und nicht in zwei Wochen.
Genau, das haben wir da rausgenommen.
Deswegen runter auf einer Stunde. Dann haben wir gesagt,
bei der Agenda haben wir so gesagt, ja, gut,
Netzerklärt funktioniert so gut, aber Wir bearbeiten die Themen nicht wirklich,
sondern wir sammeln sie nur und beschließen Maßnahmen.
Und dann sagen wir, dann bilden wir eventuell eine Taskforce,
die sich dann bis zum nächsten Termin darum kümmert.
Was den Vorteil hat, ich habe eine kleinere Gruppe,
es ist halt nicht so viele Köche verderbende Brei,
sondern ich habe irgendwie dann drei Leute, die kümmern sich meinetwegen um darum,
dass irgendwie das Logo jetzt grün gestreift ist und dann machen die das.
So, und dann kommen die zum nächsten Meeting.
Nächste Woche kommen die hin, hat gesagt, hier,
das ist unser Ergebnis.
Was haltet ihr davon?
Ja oder nein
So, und wenn dann halt noch eine zweite Runde von nöten ist,
dann sagt man halt wieder, okay, alles klar,
Taskforce, weitermachen, nächstes Mal wiederkommen.
Aber die Diskussion sollte bloß nicht in dieser Community of Practice
wirklich ausgefochten werden, weil das verbrennt Zeit.
Und zwar von zehn Leuten. Genau. Und das hat
für uns dann ganz gut funktioniert im Endeffekt.
Gibt es dazu erstmal noch Fragen? Ja. Also bis dann
freitags dann, dass man sich als Taskforce seid, oder?
Guter Punkt. Ja, also, es ist so,
dass das, dass das die Taskforce selber bestimmt. Ja,
also die müssen halt, also erstmal, wenn ich weiß,
ich habe in meinem Team so viel zu tun als Designer,
dann sollte ich mich nicht für diese Taskforce melden und sagen, ja klar,
ich bin voll dabei, ich bringe mich da voll ein.
Das ist erstmal eine Grundvoraussetzung. Das heißt,
ich muss mir die Zeit nehmen, es muss klar sein,
das ist Teil der wöchentlichen Arbeit, dann mache ich das.
Aber in der Tat ist das auch nicht immer so einfach,
das haben wir auch zum späteren Zeitpunkt nochmal festgestellt,
das sage ich ganz zum Schluss nochmal kurz was zu
Genau. Ja? Also ich entnehme den Vortrag so
ein bisschen, ihr habt da keine weiteren Hierarchien,
die Schuhvorraschung über den Szenen, ne?
Nein. Haben wir nicht. Nee. Ja. Wir haben
die ganzen Tier- und Ergebnisse wo festgehalten, wenn wir uns nicht da ist.
Super, das habe ich vergessen, zu sagen. Das ist,
also es wird Teil des moderierten Meetings ist natürlich auch,
dass es da ein Protokoll für gibt und das ist bei uns ein Google Dog,
was immer weitergeführt wird,
da kann jeder reingucken
Und die Leute, die krank sind oder im Urlaub,
können da auch reingucken und dann sehen die auch,
okay, da gibt es eine Taskforce zu dem Thema,
da habe ich auch was zu sagen oder ich habe eine starke Meinung zu,
dann gehe ich zu denen hin.
Also da muss man sich auch aktiv drum kümmern,
ob die Themen dann bearbeitet werden, die einen auch interessieren.
Ja, genau, Fazit. Ich habe jetzt einfach nochmal uns Anforderungen hingeschrieben.
Und im Endeffekt sind die eigentlich erfüllt. Wir gehen mit Feedback um,
okay, haben wir eine Lösung für gefunden, Kram,
Kram, der kein Team macht, haben wir auch eine Lösung für gefunden.
Innerhalb dieses COPs, also das hat mit diesem Design-Support zu tun,
den ich kurz erwähnt habe, muss ich jetzt,
glaube ich, nicht so ins Detail gehen,
einen Platz für die Synchronisation zwischen den Designern, haben wir auch Qualitätskriterien,
haben wir auch, weil wir einen Platz haben,
wo wir miteinander reden.
Und wir haben jetzt quasi wieder ein Design-Team-Gefühl,
weil wir halt gemeinsam schließen, in welche Richtung soll es denn gehen.
Und ja, das ist so ein bisschen
das Fazit
Jetzt bin ich schon zum Schluss eigentlich. Design-Timone,
Design-Team, würde ich auf jeden Fall sagen, ausprobieren.
Also wenn ihr ähnliches Problem habt, dass ihr denkt,
irgendwie, weiß ich nicht, wir müssen da irgendwie was machen,
die Kommunikation verbessern, einfach ausprobieren, vor allen Dingen dranbleiben,
das ist ganz wichtig, flexibel bleiben.
Also das heißt, das Format muss immer dem Team angepasst werden, nicht andersrum.
Und man muss das reflektieren. Das hatte Björn vorhin schon gesagt,
also wir haben jetzt eine Retrospektive gemacht von dem letzten,
wie, wir haben das ein Jahr gemacht?
Nee, knappes Jahr. Und da sind auch noch
ganz viele interessante Dinge
bei rausgekommen
Und da sind auch noch Stellschrauben herausgekommen, wo wir
noch dran drehen können, um es einfach zu verbessern.
Ich glaube, es gibt nicht das Format,
was gut ist, sondern man muss es halt immer weiterentwickeln.
Und genau, das ist, ja. Was war das
jetzt für Euro Zusammenarbeit? Naja, also das Format erst mal direkt nicht,
aber indirekt natürlich schon, weil jeder Designer arbeitet direkt mit Entwicklern zusammen.
Das ist ja das, also weil ich bin nicht mehr in einem Design-Team.
Ich bin in einem Team, wo ich direkt mit Entwicklern zusammenarbeite. Und das ist,
glaube ich, Der riesige Vorteil, das,
was ich jetzt beschrieben habe, ist eigentlich nur ein Mittel,
um die Folgen daraus oder die Nachteile, die dadurch entstehen,
einfach nochmal, ja, zu negieren und sagen, ja, nee,
wir können das mit einem anderen Format, holen wir uns diese Vorteile alle wieder rein.
Aber der wirkliche Vorteil ist einfach, wir sind kein Design-Team mehr,
sondern arbeiten direkt mit Entwicklern zusammen an einem bestimmten Teil des Produkts.
Ich mache mal so, weil da sind wir nämlich schon.
Du warst, glaube ich, zuerst,
macht das nur die Designer bei euch oder auch die
Jetzt. Zu anderen Themen, auch,
also es ist so eine Community of Factness,
wie hieß er für die Finition eigentlich nur,
ein Treffen von Leuten mit gleichen Interessen oder den gleichen Fähigkeiten,
ja, übergeordnet, über ihre Teamstrukturen hinaus.
Also das, was man durch diese Teamstruktur vielleicht wegnimmt und
flexible Idee, guckt man da nicht mehr raus.
Es gibt jetzt bei uns, glaube ich, schon mehrere,
ich glaube, drei oder vier und wie viel Frakt das ist.
Ich bin mir nicht sicher, aus verschiedensten Themen.
Das Design hier ist nur die, die es,
glaube ich, schon am längsten machen.
Weil da war halt das Problem einfach greifbar und dann,
wir haben halt eine Lösung besucht, das zu machen.
Und ich könnte mir auch vorstellen, dass andere Teams
das komplett anders machen
Weiß ich nicht, ehrlich gesagt. Oh, jetzt,
du, dachtest du noch, Kacke. Ihr habt das ja jetzt so zweimal nach,
naja, das ist mir sehr gut aufgefallen,
dass ihr jetzt halt ein richtiges Team hat,
ihr werdet es ja immer davon, nicht für das Design-Team geführt,
aber meiner Meinung nach solltet ihr ja ein Produkt arbeiten,
also das Produkt, würde für mich die Vorordnung stehen.
Was wir sagen, fragen wollte, ist ja,
wenn ihr an einem Blick arbeitet,
wenn ihr ein Aspekt des Produktes, dann im Team,
nicht im Design-Team,
sondern ich habe einen Entwickler und ihr entscheidet euch vielleicht nie was Neues zu machen.
Es liebt sich ab, dass ihr es
Neues machen wollt
Hier muss Fleisch oder eine Holzleite, die mich erwähntests machen würden,
was funktioniert besser, auch für irgendwelche Learnings.
Wie fließt das zurück in das Design-Team und in den Prozess
und wie fließt das dann zurück, in die anderen Projekte?
Also das sagt eher so ein agiles Vorgehen,
das ja auch was ausprobiert und dann sagt, hey,
ich habe was gemacht und das ist jetzt, das funktioniert gut,
guckt euch das auch mal an und finde ich keine Weiterung,
sagen wir, negativen Bewerkungen haben, dann können wir das ja allgemein übernehmen.
Und wenn ihr halt so Vorschläge habt,
dann können wir auch ein altes oder unser Projekt,
weil mein Projekt, das Objektiven verbessern.
Also einmal vorweg, dass das zu Hause ist, ist das Projektiv.
So, das ist halt immer, genau, da arbeite ich.
Ja, ich nehme ja mal ein Beispiel. Also,
nee, wenn, gut, dann können da halt die Sachen entschlossen werden,
die machen ein Erwähnters und so weiter,
dann kann der Designer aus dem Team,
das ist natürlich in diese COP tragen und sagen,
hier, das ist für euch vielleicht auch gut,
guckt euch das doch mal an, vielleicht wollt ihr das auch mal machen, weil es gibt keine Entscheidung, ihr macht das alle.
Ja, das meinte ich auch nur sehr. Aber wenn
ihr jetzt halt gegen etwas ausprobiert, ihr wisst ja nicht,
ob das Produkt funktionieren will oder diese Iteration,
das Produkt ist,
also werden die ja wahrscheinlich ein bisschen testen
Ja. Und dann wäre die in Funktionalität, sondern auch
diese altesten im Zweifelsfall. Und das hören die mittlerweile nicht probieren.
Und das gilt wahrscheinlich genauso gut auch für andere Bereiche,
weil es war ja einigermaßen attraktiviert. Gibt es da Interesse,
das halt weiterzutragen oder bleibt es dann dem Produkt so ein
bisschen anbehaftet und im Zweifelsfall definiert das seit den Jahren Bereiche,
was auch nicht.
Also ich sag mal, du meldest dich halt die ganze Zeit. Ja,
das ist ja, eigentlich ist das ja so ein Selbstläufer,
wenn ich was Cooles mache,
erziehe ich das auch allen und alle haben Interesse daran,
das zu wissen
Wer immer über Design zusammensprechen und ich baue was Cooles,
was einfach funktioniert und ich weiß auch, ich baue irgendwas,
was überhaupt nicht funktioniert, dann tragen das alle weiter. Also das eigene Interesse von mir,
wenn ich was baue, beziehungsweise das Interesse von den anderen,
ist da und wir haben diesen ständigen Feedback-Loop,
der sich nicht nur auf die Community of Practice beschränkt,
sondern können wir Feedback holen und geben,
wenn ich das Bedürfnis dazu habe,
also auch von jedem Tag in der Woche,
wir arbeiten da, show or,
wäre dieser Austausch schon da und wenn gute Sachen da rauskommen,
dann wird das auch gleich weitergetragen.
Ich weiß nicht, auf der persönlichen Ebene habt ihr
gar nicht das Bedürfnis, das zu formalisieren.
Es ergibt sich einfach und Das wird halt einfach gelöst.
Also die positiven Dinge werden weitergetragen und negativen Dinge genauso,
dass man sich halt versucht zu vermeiden.
Also Erfahrungsaussagen, ja. Also Beispiel, in diesem Teamshop
entschließt sich, wir machen jetzt ein guter Festival.
Und auch der Designer im Teamshop macht das dann.
Also das ist dann Aufgabe des Designers und des Teams
hat das zu organisieren, das zu machen.
So, die haben da super Erfahrung mitgemacht. Und natürlich ist derjenigen dann daran interessiert,
dass an alle Designer vor allen Dingen weiterzutragen,
wie das vielleicht in ihre Teams auch wieder zurückzutragen.
Aber wie dieser User-Test vonstatten geht es immer,
Ist immer Aufgabe des Eingeblichen, des kleinen Teams sozusagen.
Die Anforderung kann ja unterschiedlich sein. Und das,
was Jan war, doch sagte, also wenn das gut funktioniert,
dann will das jeder hören. Das ist halt im Endeffekt,
wenn ich was Neues entwickle, als kleines Team-Team,
dann biete ich das natürlich allen anderen an.
Sollte es natürlich auch so entwickeln, dass alle anderen das leicht adaptieren.
Wenn sie es nicht tun, aus welchen Gründen auch immer,
ich bin, indem ich ihn nicht,
da gibt es Runde für, das nicht zu machen.
Dann müssen sie es auch nicht tun. Aber wenn es
doch gut funktioniert und ich eine geile Erfahrung damit,
warum sollte ich das nicht aufnehmen können,
mein eigenes Team reintragen
Das ist so die Idee dann. Tschüss. Von diesem Informationsaustausch zu sichern,
haben wir auch für die Firma eine eigene, ja,
eines Facebook-Jammer, wo wir sehr viele Sachen austauschen,
die AB-Fest auch präsentieren.
Sag ich vielleicht wieder nichts wieder rausgezogen haben. Und wir haben wöchentlich ein Video,
wo die ganze Firma sich trifft und Sachen,
die wirklich sehr wichtig sind und die toll gelaufen sind,
werden nach diesen Medien präsentiert.
Und es wird gesagt, das ist gut gelaufen,
das ist deshalb gut gelaufen.
Und wenn ihr das machen wollt,
kommt zu unseren Fällen
und diese Learnings weitergehen
Ja. Eine Sache, habe ich jetzt noch nicht gelernt, verantwortlich.
Also ein Problem, was in mir ist zu sein,
der sofort auffallen würde, eben das spontane Feedback von dem Mars Fellenpartner.
Das war ja irgendwie noch nicht ganz gelöst durch das einmal
wöchentliche Ding. Selbst wenn du dir dann von fertigen Dingen
mit deiner Taskforce geflossert Feedback geholt hast oder so,
aber dieses, es muss doch manchmal so spontan gehen.
Also es geht noch, oder? Wenn es so ist,
also dann brauchen wir uns, glaube ich,
auch nicht formulisieren, wie gehe ich einfach dahin.
Und sage,
hast du gerade Zeit
Aber also um das halt so auch so ein bisschen zu formulieren und dass die Leute
auch irgendwie ihre Woche planen können, haben die halt gesagt,
ey, wir haben diesen alten Termin, der ist freigehalten.
Und da kann man halt so anderen sagen, wie wir hier sein.
Natürlich kann ich jederzeit, und das machen wir,
glaube ich, auch alle, zu einem Design angeben.
Und das hat sich dann so eingebürgert. Das ist natürlich
ein Nachteil gegenüber dem eigentlichen Sandteam, wo ich direkt sitze,
aber ich glaube, das kann man verschmerzen,
wenn man sich die Vorteile klar macht,
eigene Teams haben wirklich ihre Themen nach vorne bringen können,
eigenverantwortlich brauchen
Zudem habe ich jetzt auch noch was überlegt,
was wir ausprobieren sollen, dass wir zum Beispiel,
um halt so ein bisschen den Fokus auch zu verbreitern,
dass wir halt so was wie Pairing auch im Silentinel machen.
Das heißt, dass ein Designer mal eine Stunde
in der Woche sich einfach mal neben dem anderen Design,
aus dem komplett anderen Team,
besetzt und dass sie einfach mal gemeinsam arbeiten.
Das ist, glaube ich, gut. Also das probieren
wir halt so ein bisschen aus. Steht auch aus,
als dass die Tätigkeit so sinnvoll ist oder nicht.
Aber das ist halt auch so ein Punkt,
um das so ein bisschen abzufangen.
Du meintest, ich freue mich
die ganze Zeit beendet
Gut. Eure Designer machen dann nur Screen Design oder machen
die auch Print und Merchandise und was weiß ich nicht,
alles, was es so gibt,
mit dazu oder habt ihr dafür dann doch ein eigenes Team,
was sich mit so einem Fragen schätze?
Ja, also eigentlich schon. Also wir haben,
also das ist natürlich bei uns ist der Anteil nicht so groß,
was in Printsachen. Also ein Großteil der Designer machen einfach
Screen Design. Aber wir haben jetzt ein Design Team,
was halt größt, also diese ganzen Printsachen irgendwie macht,
weil das ist halt auch so ein einen Punkt,
wo man jetzt auch nicht wirklich einen Entwickler zu laufen.
Dieses Team arbeitet aber dafür halt sehr eng mit den ganzen
Länderteams zusammen, mit den Kampfmengenschaften, die ich nichts.
Und da läuft das halt, dass es den Ausgleich ein bisschen in dieser Sache ist.
Ihr teilt jetzt quasi diesen Designer konkret bestimmten Themen zu,
die sie mit Entwicklern zusammen bearbeiten. Ich könnte mir vorstellen,
dass man sich dadurch ja in dem Bereich weiter spezialisiert oder sich primär in dem Bereich findet.
Wie wirkt ihr dem entgegen, dass man quasi über den
Feature mit auf das man sich primär konzentriert betritt, glückt wird.
Dass man quasi nur noch in so meinen Bereich arbeiten kann.
Ja, das ist nicht immer ganz live. Einmal soll
natürlich dieses Community of Practice da so ein bisschen entgegengeben,
dass man auch halt schaut, wie sieht das,
was passiert gerade bei den anderen Designern,
oder halt, dass man sich einfach mal zusammensetzt.
Und das halt so gemacht. Der große Vorteil ist natürlich,
dass halt man, also der Designer in dem Team,
im Endeffekt auch viel ein Know-how von den Entwicklungen zum Beispiel mitkriegt.
Also bei uns ist, glaube ich,
kein Designer der wirklich nur den Funshop aufmacht und das Ding fertig macht und sagt,
hier, mach das mal, sondern man ist da viel mehr,
also wie viele.
Ey, das ist eigentlich, glaube ich, echt ein großer Fordnung.
Und wir haben natürlich die Möglichkeit, uns freitags,
also am Freitags ist es so ein bisschen,
bilde dich weiter und mach mal was anderes.
Da hat jederzeit sich anderen Projekten zu widmen und auch sich weiterzubilden.
Einfach mal was Neues zu lernen, da andere Projekte zu sehen.
Und du kannst auch natürlich immer den Boden speichern,
dass immer ein anderes Team ist
Wie funktioniert das denn mit der teamübergreifenden Stilrichtung oder so? Ich stelle mir das jetzt,
also ich kann es mir noch nicht genau so vorstellen,
wie das so funktioniert,
dass da tatsächlich auch ein einheitliches Design nach herausfordert und ich,
was weiß ich, wie du vorhin mal sagtest,
die Leute vom Shop, die arbeiten viel mit Illustrationen machen,
alles geht spund und ja, die Leute,
die halt fürs Login zuständig sind, die machen das ganze Playing und schaffen das.
Größtenteils kommen diese Themen in diesem Man-Set leer zu sprachen. Ja,
wenn dich halt in meinem Bereich arbeite, ich habe da eine Vorstellung,
ich merke dann, was ist einer, macht da was.
Das passt eigentlich gar nicht so. Also wie wir eigentlich sonst immer arbeiten,
dann wird das halt durch dieses Mehr-Set-Lab zum Forschabkommen,
da wird es ein Ticket geben und sagt, ja,
das hat mir nicht gefallen, das hat mich irgendwie traurig gemacht.
Da hatte ich das Gefühl,
wir arbeiten nicht mehr in die richtige Richtung und dann wird
das halt einmal die Woche klimatisiert und haben gesagt, okay,
was gibt es denn da für Lösungen, wie können wir denn entgegengehen?
Also bestimmen bei euch auch Designer, die tatsächlich die Richtung,
wie es dann nachher aussehen wird und nicht der Product meines
oder hat der Schreckholder, der den ganzen Kram eigentlich haben will.
Ja. Cool, ja. Also es, ja,
Product-Manager lassen sich. Hammerliebes romantisch. Das ist jedes Team
, organisiert sich da vielleicht anders.
Und es gibt manche Teams, die ein Product-Rowner definieren.
Da ist dann aber vielleicht anders definiert als in anderen Teams.
Und im Endeffekt die Schachel, die wir sprechen,
wahrlich ist eigentlich der Designer. Also das ist das,
was sie das anhatten. Also klar gibt es auch dann
da Absprech am Spart mit der Geschäftsführung, wenn jemand sagt,
ja, der Vorstoß hat mir jetzt nicht so gut gefallen.
Da müssen wir nochmal
drüber reden
Machen wir es natürlich. Dann wird das
auch wieder durch dieses Format in aller Teams reingetragen.
Gut, dann würde ich einfach sagen,
noch einen schönen Abend und noch einmal in eine eigene Sache natürlich.
Werden wir interface design haben. Das Thema Johnson.
Kann sich gerne dran helfen oder die Karte geben oder wie
Friedl F. Jimmy schreibt.
Ja,
das war's von mir