Technische Konzepte
In dieser Folge sprechen Sebastian und Tobias über technische Konzepte. Ein Thema, das wir bei Sandstorm in einem unserer letzten Foren diskutiert haben und dabei der Frage auf den Grund gegangen sind, wie ein Konzept geschaffen sein soll, damit es einen möglichst großen Mehrwert hat.
Im Gespräch gehen wir darauf ein, welchen Bestandteile ein technisches Konzept haben sollte, wie wir das - zu Beginn - weiße Blatt füllen und sprechen über Beispiele, wie uns Konzepte unseren Alltag in der Softwareentwicklung erleichtern.
Diese Themen haben wir in der Folge angesprochen:
Wir freuen uns auf eure Erfahrungen und Gedanken zum Thema dieser Folge:
Sebastian auf LinkedIn: Sebastian Kurfürst
Tobias auf LinkedIn: Tobias Gruber
Sandstorm auf Instagram: @sandstormmedia | LinkedIn: Sandstorm
Oder auch per Mail an kontakt@sandstorm.de
Das Sandpapier ist der regelmäßig unregelmäßige Podcast der Sandstorm Media GmbH. Wir erzählen aus unserem Alltag, was wir versuchen, anders zu machen und welchen Herausforderungen und Experimenten wir uns auf unserem Weg stellen.
Transkript
Tobias
Herzlich willkommen zu einer neuen Folge vom Sandpapier, dem regelmäßig unregelmäßig erscheinenden Podcast von Sandstorm. Wir sind mal wieder bei unregelmäßig, wir hatten jetzt eine längere Pause. Nichtsdestotrotz wollen wir heute mal wieder über Themen, Herausforderungen und Experimente aus unserem Alltag als Softwareunternehmen sprechen. Heute eine Folge zum Thema technische Konzepte in unserer Softwareentwicklung und dazu im Gespräch heute der Sebastian und ich der Tobias. Nachdem wir jetzt eine längere Pause hatten, hat es uns mal wieder gepackt. Wir hatten als Anlass für diese Folge das Thema technische Konzepte in unserem letzten Forum besprochen. Ganz kurzer Exkurs, was ist unser Forum? Das ist quasi ein Team-Meeting, ein All-Hands-Meeting, unser regelmäßiges Format, bei dem wir uns entweder über Dinge austauschen, wie zum Beispiel technische Neuerungen oder Themen besprechen, die fürs ganze Team relevant sind. Das letzte Mal eben das Thema technische Konzepte. Sebastian, du hast das Thema mit reingebracht, was hat das Thema für dich so aktuell gemacht? Warum gerade jetzt?
Sebastian
Genau, also es sind eigentlich zwei Faktoren, würde ich sagen. Das eine ist ein kurzfristiges. Also ich habe gerade in einem Kundenprojekt quasi, wo viele Parteien involviert sind, die Planung gemacht und dafür ein technisches Konzept geschrieben, ein sehr ausführliches in dem Fall, und habe in dem Kontext mal wieder gemerkt, wie hilfreich das halt ist, darüber zu sprechen, was wir eigentlich machen wollen, warum wir das machen wollen, was unsere Ziele sind, die wir verfolgen. Und genau, diese ganzen Faktoren helfen halt massiv, wenn es dann Richtung Entwicklung geht. Das ist so der eine Faktor. Und der andere Faktor ist, ich hatte vor ungefähr einem Jahr, würde ich sagen, hatte ich mal so überlegt, okay, was ist denn so ein Thema, was ich mir für mich ganz persönlich mal machen will. Und ich habe ja relativ fragmentierte Tage einfach durch die vielen Themen, die anstehen und das macht mir auch Spaß, ist Teil meines Jobs. Aber da war immer so ein bisschen das Problem, wenn ich dann mal zwischendurch Zeit habe, was zu entwickeln, zum Beispiel da immer wieder schnell reinzufinden. Und da habe ich vor ungefähr einem Jahr angefangen, total konsequent Konzepte zu schreiben, für mich ganz persönlich in den jeweiligen Projekten und habe gemerkt, wie viel mir das bringt, wie viel schneller ich einfach wieder ins Doing komme, wenn ich mal ein Thema ablegen musste, zum Beispiel. Und genau, das waren so die beiden Impulse, wo ich gedacht habe, es wäre irgendwie sinnvoll, da mal darüber zu sprechen.
Tobias
Das Thema hast du dann in unser Forum mitgebracht. Und heute hier in dem Podcast wollen wir quasi die Erkenntnisse daraus zum einen gemeinsam besprechen und zum anderen das ganze Thema, was sich darum bewegt, technische Konzepte, was gehört dazu? Da wollen wir ein bisschen einsteigen und trotzdem versuchen, die Folge auf circa 30 Minuten mal zu begrenzen. Liebe Hörerinnen und Hörer, gibt uns gerne dazu Feedback, wie euch so ein kürzeres Format gefällt. Steigen wir doch mal direkt ein, was? Wenn du über das Thema technisches Konzept sprichst, dann stellen sich mir sofort zwei Fragen und die lassen sich wahrscheinlich gar nicht so leicht voneinander trennen. Die eine Frage ist, was gehört denn da rein und wie fange ich an?
Sebastian
Ich sage mal, genau, grundsätzlich würde ich sagen, da gehört alles rein, was einem später hilft, auf dem richtigen Weg zu bleiben, mal ganz abstrakt gesprochen, wir wollen irgendein Ziel erreichen, wir wollen irgendein Problem lösen, und ich sage mal, wir sind quasi, wenn wir im Arbeiten sind, müssen wir ganz, ganz viele Entscheidungen treffen und aus meiner Sicht hilft das Konzept, uns quasi auf diesem Weg zu bleiben, also, um sich vorher Gedanken zu machen, wie sieht eigentlich der Weg aus, wie viel kenne ich eigentlich über den Weg bis zum Ziel und so weiter, ja, und genau, bei der Frage, was kommt da rein, ich glaube, das kann ganz unterschiedlich aussehen, also Konzepte können teilweise nur eine Stichpunktliste sein, manchmal ist es ein bisschen was Größeres, was ich für mich immer durchziehe, sind eigentlich zwei Seiten, einmal die Problemseite, also man ist quasi erklärt, was will ich eigentlich lösen und warum, und die andere Seite ist, wie will ich rangehen, also die Solutions-Seite, die Lösungsseite quasi, und genau, das würde ich mal sagen, sind für mich die zwei immer enthaltenen Bestandteile in einem Konzept.
Tobias
Was wir da als Begriffe in der Vergangenheit, glaube ich, hier auch im Podcast schon verwendet haben, war eben Problem Space und Solution Space. Hier bei uns bei Sandstorm zwei Begriffe, unter denen sich hoffentlich jeder was vorstellen kann, weil es uns eben hilft, schön zu differenzieren. Wenn wir über ein Konzept auch sprechen, reden wir über einen möglichen Teil der Lösung oder reden wir gerade über einen Teil des Problems, was wir gerade genau kennen. Weil häufig kommt es ja vor, wenn wir zu schnell in den Solution Space rennen, dann kann es sein, dass wir das falsche Problem lösen. Du hattest gerade gesagt, was gehört in ein Konzept rein? Diese beiden Seiten auf jeden Fall, Problem Space und Solution Space. Wir hatten im Forum auch das Thema Shape Up angesprochen. Wie spielt das hier mit rein?
Sebastian
Ja, genau. Ich habe selber auch immer eine Hürde, wenn ich anfange, ein Konzept zu schreiben. Also man macht seinen Texteditor auf oder man nimmt seinen Zettel und der ist weiß am Anfang und es steht nichts drauf. Und ich finde das immer echt persönlich schwierig. Ja, wie fange ich eigentlich an? So, und was für mich persönlich gut funktioniert ist, es gibt in Shape Up, also das ist ein Buch von Basecamp, wo die quasi ihre Projektmanagementmethodik oder einen Teil ihrer Projektmanagementmethodik vorstellen. Und die machen sehr viel mit schriftlicher Kommunikation. Und eins der Kernkonzepte, worum es da geht, ist das sogenannte Pitch. Das ist im Prinzip so eine Art paarseitiges Dokument, wo im Prinzip für jedes Thema, was die angehen wollen, beschrieben wird, was ist eigentlich unser Problem, was ist eine Lösung, was sind Rabbit Holes, was sind Logos, wie lange soll das dauern. Also so eine Menge an Punkten.
Tobias
Ich glaube, ein paar davon müssen wir erklären, was das ein Rap genau ist.
Sebastian
Ja genau, also fangen wir vielleicht mal strukturiert an. Also erst mal genau, dieses Buch ist kostenlos im Internet auch verfügbar, und was ich immer mache, ich kopiere mir diese fünf Bullet Points in mein leeres Dokument rein. Mit den sozusagen Kurzdefinitionen, die da drin stehen. Quasi als Überschriften. Als Überschriften, genau. Und dann kann ich anfangen, das quasi mit Leben zu füllen. Je nachdem, wonach mir zuerst ist oder was mir zuerst einfällt.
Tobias
Quasi als Überschrift, als Überschriften, genau.
Sebastian
Das erste ist quasi Problem. Das ist also die Problembeschreibung. Das ist also das technische oder Business-Problem, was wir eigentlich lösen wollen. Da kann so was reinkommen, wie, na ja, wir möchten das, also zum Beispiel unsere bisherige Lösung hat bestimmte Nachteile. Die wollen wir gerne verbessern oder da wollen wir anders auf das System gucken. Wir haben zum Beispiel, vor Kurzem habe ich mal ein Konzept gemacht für unser Logging-internen und Monitoring-System. Da hatten wir schon was im Einsatz und da habe ich in dem Teil beschrieben, was sind eigentlich die Probleme mit dem aktuellen Monitoring-Setup. Damit man dann quasi genau gucken kann, löst man eine neue Lösung, eine neue mögliche Lösung, dass überhaupt diese Probleme, dass man quasi fokussiert ist, auch das zu lösen und nicht einfach nur was Neues zu machen, was halt shinier und toller ist, sage ich jetzt mal, sondern halt wirklich die echten Probleme, die wir halt haben. Und was auch ganz typisch ist, ist, dass ich reinformuliere, was sind eigentlich die Themen, also zum Beispiel, welches Feature soll implementiert werden aus Kundensicht? Welche Funktionalität soll neu geschaffen werden und was bedeutet das eigentlich?
Tobias
Das war jetzt der erste Teil in Chapeau. Ich glaube, lasst uns ruhig die fünf Punkte mal durchgehen.
Sebastian
Genau, der zweite Teil, das ist der Appetite, das ist auch, finde ich, ein ganz interessantes Konzept, also der Appetit, das heißt quasi, wie, ich sage mal, wie viel Lust habe ich auf die Lösung, also wie viel ist mir die Lösung wert, wie groß darf die sein, sozusagen. Und das heißt, es geht nicht darum, in dem Fall eine Schätzung zu machen, also nicht zu sagen, das ist aber so und so aufwendig, sondern das ist eher der umgekehrte Weg, das sagt sozusagen mal top down, habe ich das Gefühl, ist mir diese Lösung zwei Wochen wert an Arbeit, oder zwei Tage mal ganz grob gesagt, ja, also es geht auch wirklich nur um diese grobe Einschätzung, das ist nicht in jedem Konzept gleich hilfreich, finde ich, aber manchmal kann das ein hilfreicher Aspekt sein, finde ich.
Tobias
weil alle Arbeit, die wir tun in unserem Projektgeschäft, ist schon damit getrieben, dass es Budgets gibt. Es gibt nicht unendlich viel Geld. Insofern ist die Frage, wie viel sind wir denn überhaupt bereit, in dieses Thema zu investieren, schon eine ganz wertvolle, um auch die Größe der Lösungen entsprechend dann zu skalieren.
Sebastian
Genau. Also das ist ein großer Punkt. Also im Prinzip, je nachdem, wie man da abbiegt, kommt man oder muss man die Lösung komplett anders denken, weil sozusagen die Zielgröße, die man hat, also ob jetzt mein System für 200 User parallel oder 200.000 User parallel in meinem Extremfall funktionieren soll, ist halt völlig anders. Ja, und dementsprechend habe ich auch einen anderen Appetit, das Problem zu lösen. Je nachdem, ist es eher ein Edge-Case, ist es ein Randfall oder ist es ein Standardszenario und so weiter. Das spielt alles da rein. Das war der Appetit. Genau, das ist der Appetit. Und jetzt kommen wir zu dem eigentlichen Hauptteil der Solution, also der Lösung selber. Also das ist quasi eine Beschreibung, wie könnte eine oder wie sollte die Lösung sein. Das ist sozusagen jetzt vom Problem Space in den Solution Space umswitchen. Und was ich da reinschreibe, ist extrem unterschiedlich. Also manchmal ist es zum Beispiel so ein explorierendes "Ja, Lösung eins könnte mit dem und den Technologien sein. Lösung zwei könnte mit den und den Technologien sein. Was haben die für Vor-Nachteile?" Beispielsweise. Was anderes könnte sein, wirklich mal genau hinmalen. Welche Komponenten brauche ich bis zu einer funktionierenden Lösung? Welche Teile müssen miteinander interagieren? Und genau, worauf ich eigentlich am meisten Wert lege, in dem Bereich ist das Datenmodell, also wie sind die Daten strukturiert und wie fließen die Daten von A nach B, also quasi welche Systeme oder welche Teilkomponenten sind involviert und in welcher Art und Weise kommunizieren die miteinander.
Tobias
Was würdest du sagen vom Detailierungsgrad? Gibt es da irgendwas, woran du dich orientierst, wie detailliert ein Konzept wird? Also genau.
Sebastian
Das hat aus meiner Sicht zwei Aspekte. Das eine ist, wer ist die Zielgruppe für das Konzept? Also wenn ich jetzt sozusagen ein Konzept produziere für mich selbst, dann bin ich ja derjenige, der entscheidet, wann es quasi detailliert genug ist. Wonach ich da eigentlich immer gehe, ist, es gibt immer irgendeinen Punkt im Konzept, wo ich so das Gefühl habe, ja, jetzt habe ich es wirklich komplett umrissen und jetzt steht es auch alles da irgendwo, sage ich mal. Also wo ich das Gefühl habe, jetzt juckt es mich in den Finger und jetzt will ich eigentlich anfangen. Also jetzt kommt durchs drüber nachdenken kein allzu großer Erkenntnisgewinn mehr sozusagen. Und dann lasse ich auch ein Stift fallen, egal in welchem Zustand dann das Konzept ist.
Tobias
Die Frage, wann du aufhörst, kommen wir gleich noch zu. Und auch die Frage des Prototypings würde ich kurz mal noch ausklemmen, weil wir gerade noch die Punkte von Shaker durchgehen bei uns in der Lösungsbeschreibung.
Sebastian
Die Frage, wann du aufhörst, kommen wir gleich noch zu. Und auch die Frage des Prototypings würde ich kurz mal noch ausklemmern, weil wir gerade noch die Punkte von Schalker durchgehen, weil es in der Lösungsbeschreibung, ne? Genau. Und die andere Aspekt ist immer eine Frage, also die Frage war ja, wann sind wir fertig, ne? Und die andere Frage ist also, ist die Frage der Zielgruppe. Also manchmal ist es hilfreich, Konzepte zu produzieren, damit die alleinstehend, ich sag mal, wirken können. Also sprich, damit die jemand von vorne bis hinten durchlesen kann und ich sag mal, alle relevanten Informationen, die er oder sie benötigt, für dieses Thema bekommt und vor allem Kontext bekommt. Das ist eigentlich das Entscheidende, ne? Das ist auch der Vorteil von einem Konzept gegenüber fünf Tickets beispielsweise, dass man halt gezwungen ist, einen Narrativ zu produzieren, einen Text zu produzieren, Kontext zu produzieren. Und dieses Gesamtbild ist halt, aus meiner Sicht, eine Idee.
Tobias
Das ist in unserem Fall, in unseren Projekten, wenn wir gerade auch für größere Kunden unterwegs sind, wo mehrere Stakeholder oder verschiedene Ebenen oder Business Units involviert sind, sehr, sehr wertvoll, wenn das Konzept als eigenständiges Dokument quasi auch begutachtet werden kann. Ja, absolut. Okay. Nächster Punkt auf der Shape-up-Liste nach der Solution.
Sebastian
Und dann kommen die "Rabbit Holes". "Rabbit Holes" ist so dieses Bild, ich sag jetzt mal, die Löcher, die man nicht sieht auf der Wiese, aber wo man reintreten kann, mal so ganz plakativ gesagt. Also sprich, die Fallstrecke, die wir haben könnten, die wir jetzt schon erkennen. Weil was wir ja machen bei diesem ganzen Thema Problem- und Lösungsbeschreibung, wir beschäftigen uns sozusagen schon sehr intensiv mit, welches Problem wollen wir lösen, und dann auch, wie sollte die Lösung aussehen. Und es ist relativ wahrscheinlich, dass wir dabei schon feststellen, na Moment mal, wenn wir hier eine Entscheidung in eine andere Richtung treffen, dann wird es viel komplizierter zum Beispiel. Und im Prinzip sind diese "Rabbit Holes", das ist sozusagen schon jetzt in der Konzeptphase bekannte Komplexität. Und das Ziel ist die zu managen sozusagen. Und dann zu sagen, na ja, also ich muss mal überlegen, was ein Beispiel ist. Genau, ein Beispiel könnte sowas sein, wie wenn ich einen PDF generieren will beispielsweise und ich möchte mir das relativ einfach machen. Dann gibt es quasi die Möglichkeit sozusagen im Prinzip, so wie die Druckfunktion des Browsers zu verwenden, beispielsweise als Idee sozusagen dann im Programmcode. Und das funktioniert für viele Fälle sehr, sehr gut. Aber es gibt bestimmte Spezialszenarien, wo das ein Problem wird und wo das nicht gut funktioniert. Zum Beispiel, wenn ich irgendwelche riesenlangen, wenn ich da einen PDF erzeugen will, was hunderte Seiten ist beispielsweise. Oder wenn ich einen PDF erzeugen will, was irgendwie ganz viele Tabellen hat, wo sich die Zwischenüberschriften auf jeder Seite wiederholen müssen und solche Geschichten. Und in den "Rabbit Holes" könnte man zum Beispiel sagen, hey, Achtung, das sind Probleme, die man da haben könnte. Wie gehen wir damit um sozusagen? Im Sinne von, ja, das ist out of scope, ist eine Möglichkeit. Also zu sagen, das wollen wir eigentlich gar nicht lösen. Unsere PDFs sind nur Rechnungen, die sind nur zwei Seiten lang beispielsweise. Oder auf der anderen Seite, na ja, das ist ein Problem. Da müssen wir noch mal dediziert reingucken und müssen uns dafür eine Lösung überlegen. Genau. So, und der letzte Teil, das ist damit so ein bisschen related. Also es ist nah bei, würde ich sagen. Das sind die No-Go's. Also das sind Dinge, die quasi man bewusst ausschließt aus dem Konzept. Also mit dem Ziel, nicht nur zu sagen, was man will, sondern auch zu sagen, was man nicht will sozusagen.
Tobias
In dem Kontext "Shape Up" möchte ich das hier nochmal ergänzen. Das ist ja von Basecamp ein integriertes Konzept, das heißt dieser Gedanke, wie groß ist denn mein Appetit für dieses Thema, für dieses Problem, das ich lösen möchte. Und die denken ja immer in ihren sechs Wochen Zyklen, diese Zeit haben, um ein bestimmtes Problem zu lösen. Das heißt, da ist es umso entscheidender, wenn die Zeitkomponente fix ist in einem Projekt, dass die Scope-Komponente variabel ist und darüber steuern die das ganz, ganz stark, dass sie sich eben im Vorhinein über die Rabbit-Holes-Gedanken machen, also Themen, wo man abtauchen könnte, die so null her werden könnten. Und auch, indem sie schon ganz klar von Anfang an sagen, was nicht Teil dieses Projektes ist, was ist jetzt nicht Teil dieser Umsetzung. Und das zu beschreiben ist ja auch super hilfreich, weil das A, die Erwartungshaltung derer, die das Konzept lesen, managt. Und zum anderen, auch denen, die es umsetzen sollen, ganz klar hilft. A, hier ist eine Linie, das ist nicht Teil meines Scopes, das kann man anders dran kommen. Aber jetzt hilft es mir, mich zu fokussieren und mein aktuelles Ziel zu erreichen.
Sebastian
Genau, ich glaube, diese No-Goes und Rabbit-Holes sind insbesondere dann relevant, wenn halt andere Leute die Umsetzung machen, als die Leute, die das Konzept geschrieben haben. Weil dann hast du genau diese Leitplanken-Geschichte, die da noch wichtig ist und diesen Aspekt, genau.
Tobias
Okay, wir waren abgebogen bei der Frage, wie du ganz konkret anfängst ein Konzept zu schreiben und hast gesagt, hey, dir helfen diese diese fünf Überschriften, um nicht mehr eine weiße Seite vor dir zu haben, sondern da sind dann schon mal ein paar Überschriften und ein paar Stichpunkte, was da jeweils dazugehört. Und dann?
Sebastian
Also eigentlich ist es dann eher, was, also man hat ja immer irgendeine Stelle, wo man anfängt. Also man hat entweder ein Problem, was man schon relativ genau beschreiben kann, oder man hat eine Lösungsidee. Das kann ja beides sein. Und ich bringe eigentlich immer erstmal das zu Papier, was ich sozusagen, was schon im Kopf da ist. Genau. Und dann geht's eigentlich von dort weiter auf die andere Seite, je nachdem, was das dann halt ist. Also ich sag mal, was ich schon versuche, ist, zum Beispiel, wenn ich, also manchmal hat man eine konkrete Lösungsidee und das Problem ist noch eigentlich eher so ein bisschen implizit im Hinterkopf, dann versuche ich schon vom Problem anzufangen. Und sie sagen, gut, die zehn Minuten nehme ich mir jetzt noch mal und schreibe jetzt noch mal zumindest ein paar Stichpunkte in, was weiß ich, fünf Sätzen oder acht Sätzen, was will ich eigentlich lösen. Genau. Und mir hilft das auch. Also dabei merke ich persönlich auch, wie stark sich dadurch meine Gedanken strukturieren. Also ich würde mich schon eher als strukturierten Denker bezeichnen, aber trotzdem ist es so, dass dieses selber aufschreiben und feststellen, Moment mal, hier habe ich irgendwie was noch nicht so klar. Also das ist ein völlig anderes Level an Klarheit, finde ich, was ich auch dafür finde, dadurch für mich selber im Kopf erzielen kann.
Tobias
Gibt es da einen Unterschied, ob ein Konzept eine Seite ist oder 30, was jetzt diese Klarheit angeht?
Sebastian
Ne, nicht unbedingt. Also mein Ziel ist eigentlich immer sozusagen, also wie soll ich sagen, es gibt natürlich gewisse Konzepte, die werden eine gewisse Länge haben. Also im Sinne von, wenn ich jetzt zum Beispiel fünf Fremdsysteme miteinander integriere auf verschiedenartige Art und Weise, dann wäre ich das nie auf einer halben Seite beschreiben können sozusagen. Das ist einfach, das hat eine intrinsische Komplexität und damit wird auch das Konzept eine gewisse Länge haben, weil das muss ja so sein.
Tobias
Weil es eben nicht nur dein Schmierzettel ist, sondern auch anderen sozusagen in sich nachvollziehbar sein soll.
Sebastian
Naja, ja, wobei ich finde, also mir ist wichtig, dass es halt eben kein Schmierzettel ist, auch für mich. Also mein Ziel ist es, dass ich selber in der Lage bin, in drei Jahren auf das Konzept zu gucken und mich wieder zu erinnern, was ich damit gemeint habe. Also im Prinzip müssen da genug Hinweise drinstehen, dass ich sozusagen anknüpfen kann wieder und dass es wieder vorkommt aus dem Gedächtnis sozusagen. Und das ist eigentlich immer mein Ziel davon, wenn ich das schreibe.
Tobias
Natürlich mal besser mal schlechter. Das ist auch klar. Da frage ich doch gerade mal wie es unter dem Teppich aussieht, wenn du gerade das Beispiel bringst: wenn ich nach ein paar jahren mal wieder ein konzept von mir in die hand kriege. Hast du ein Beispiel?
Sebastian
Ja. Also ich habe jetzt zum Beispiel vor kurzem unsere interne Infrastruktur die Dokumentation dort neu strukturiert und die ist jetzt ja über die letzten, weiß ich nicht, fünf oder zehn Jahre, oder sieben Jahre, glaube ich, jetzt gewachsen, sozusagen. Und da habe ich halt immer geguckt, von wann war das Dokument und dann habe ich halt das sozusagen auch zeitlich dort so ein bisschen einsortiert. Und hatte damit relativ viele dieser Konzepte wieder sozusagen mal gesehen. Und das war ganz lustig, weil ich schon das Gefühl hatte, dass dann, dass mir wieder bewusster war, ah ja, weshalb haben wir diese Entscheidung getroffen, wie ist immer dahingekommen? Und vor allem, und das ist eigentlich das Entscheidende, ist es denn jetzt gerade noch relevant oder ist es obsolet? Weil das ist ja eigentlich, wenn man das später mal wieder sieht, sozusagen, also die Fragestellung. Und was ich auch manchmal mache, ehrlich gesagt, es gibt manchmal so Iterationen, also zum Beispiel bei dem Monitoring Beispiel, was ich vorhin genommen habe, da machen, also da haben wir jetzt, glaube ich, die dritte oder vierte Iteration von dem Monitoring Setup bei Sandstorm. Und da habe ich zum Beispiel bei dem, also es gibt halt ein Konzept für die letzten beiden Iterationen. Und bei dem ersten davon habe ich halt fett oben dran geschrieben, Achtung, obsolet, einfach nur so einen Link auf das Neue, so.
Tobias
Also ich habe jetzt zum Beispiel vor kurzem unsere interne Infrastruktur, die Dokumentation dort neustrukturiert und die ist jetzt ja über die letzten fünf oder zehn Jahre oder ja sieben Jahre glaube ich jetzt gewachsen sozusagen und da habe ich halt immer geguckt von wann war das Dokument und dann habe ich halt das sozusagen auch zeitlich dort so ein bisschen einsortiert und hatte damit relativ viele dieser Konzepte wieder sozusagen mal gesehen. Und das war ganz lustig, weil ich schon das Gefühl hatte, dass mir wieder bewusster war, ah ja, weshalb haben wir diese Entscheidung getroffen, wie ist immer dahin gekommen und vor allem, und das ist eigentlich das Entscheidende, ist es denn jetzt gerade noch relevant oder ist es obsolet, weil das ist ja eigentlich, wenn man das später mal wieder sieht sozusagen, also die Fragestellung und was ich auch manchmal mache ehrlich gesagt, es gibt manchmal so Iterationen, also zum Beispiel bei dem Monitoring Beispiel, was ich vorhin genommen habe, da haben wir jetzt glaube ich die dritte oder vierte Iteration, von dem Monitoring Setup bei Sandstorm und da habe ich zum Beispiel bei dem, also es gibt halt ein Konzept für die letzten beiden Iterationen und bei dem ersten davon habe ich halt fett oben dran geschrieben, Achtung obsolet, einfach nur so einen Link auf das Neue, so relativ simpel halt.
Sebastian
-
Tobias
Mir kam gerade eine Erinnerung, ein Beispiel vor kurzem, es ist ein Edge-Case, es ist ein Sonderfall, es ist die Ausnahme, aber in einem Projekt war quasi das, was wir gemacht hatten, gelöscht, das war weg und da half es uns, dass es das Konzept noch gab, um daraus quasi die Lösung wieder herstellen zu können. Das ist hoffentlich der Ausnahmefall, warum auch immer das System weg war, es war weg, wir konnten es wieder, und es ließ sich auch nicht einfach aus dem Backup oder so wieder herstellen, das war wirklich, das war so, das war weggeräumt, einmal Garbage Collection. Ja, ich habe auch in unserem Forum kam ja, kam mir die Frage auf, ab wann darf ich denn überhaupt etwas als Konzept bezeichnen, sind so drei Stichpunkte, zählt das schon als Konzept und wenn ich ein Ticket bearbeite, wo ich so abschätzen kann, naja, das wird jetzt ein paar Stunden dauern, muss ich dann, ich formuliere es bewusst so, muss ich dann jetzt hier noch ein Konzept schreiben, wie stehst du dazu?
Sebastian
Ich würde es ausprobieren. Ich würde es empfehlen, sagen wir es mal so. Wenn ich jetzt eine Arbeit habe, die mich jetzt drei Stunden beschäftigt, dann finde ich es auch völlig okay, wenn ich am Anfang eine Viertelstunde darüber nachdenke, was ich eigentlich machen will. Das können dann noch Stichpunkte werden oder eine To-do-Liste oder das ist völlig okay. Also alles, was mir hilft, auf diesem Weg zu bleiben. Und das coole ist daran, ich versuche die immer möglichst nah am Code zu haben. Wenn wir das Code produzieren, also quasi auch mit dem Projekt zu haben, weil das einfach ein gutes Wissenskompetium ist. Und das schöne ist, das ist schon ein Riesenschritt hin zu zum Beispiel dokumentiertem Code. Weil dann kann ich halt sehr einfach an der entsprechenden Klasse einfach dran schreiben. Achtung, hier steht in dem und dem Konzept. Ich habe dieses Dokuproblem mit einer Zeile gelöst. Oder ich kann auch vielleicht manchmal aus dem Konzept bestimmte Grafiken, Visualisierungen, Absätze von der Doku übernehmen und an die richtige Stelle schieben, schieben im Quellcode beispielsweise. Also es ist halt, es macht halt, diese Hürde senkt es halt auch einfach wieder ab, weil ich habe ja schon was produziert. Also das ist zumindest das, was jetzt für uns, würde ich sagen, recht gut funktioniert. Aber ich sage mal, wir sind als Organisation ja sehr Quellcode und auch Git getrieben. Also wir haben ja jetzt kein klassisches File Share. Wir haben zwar ein Wiki in der Firma, aber auch da sind eigentlich diese ganzen Code-Geschichten eigentlich das Endliche im Git. Also das heißt, für uns funktioniert das gut. Aber am Ende des Tages ist es eigentlich egal, solange alle wissen, wo man suchen muss. Also wo die Konzepte am Ende stehen, spielt, würde ich sagen, keine Rolle, solange man sich einig ist, wo es denn ist. Damit halt alle es finden, wenn sie es brauchen.
Tobias
Die Krux liegt wahrscheinlich darin, wenn man ein schönes Konzept geschrieben hat, dann ist die Realität passiert, das Projekt, und dann haben die sich schön auseinander gelebt.
Sebastian
Ja, das finde ich persönlich gar nicht so schlimm. Für mich ist ein Konzept erst mal primär eine Beschreibung dieses Standes. Das ist so ein Snapshot in der Zeit sozusagen. Ich würde mich mal versuchen, von diesem Ballast zu befreien. Das muss immer aktuell sein, weil ich schreibe immer ein Datum dran, damit man einfach weiß, okay, das ist drei Jahre alt, das ist ein Jahr alt. Wenn ich das Konzept das nächste Mal in die Finger kriege, aus welchen Gründen auch immer, und dann feststelle, na ja, jetzt überarbeite ich, das kommt schon auch manchmal vor, dass ich was ausprobiere und dann arbeite ich drei Monate später an derselben Idee weiter, und dann stelle ich fest, ah ja, funktioniert leider nicht, wir müssen noch was ansetzen. Und dann kommt halt ein Absatz dazu und dann ändere ich auch das Datum, weil ich das Gesamtding dann wieder in der Mache hatte und quasi ein sinnvolles Update gegeben habe sozusagen. Aber für mich ist es wirklich so ein Snapshot in der Zeit, nicht mehr und nicht weniger. Und das heißt, Konzepte können für mich jetzt keine Doku per se ersetzen, aber trotzdem ist es schon ein, also wie ich soll sagen, wenn ich so mich an Projekte zurückdenke, auch die ich so in meiner beruflichen Laufbahn, egal ob bei uns oder bei anderen gesehen habe, ich sag mal, wenn man eine Ritmi hat im Projekt, die sagt, wie man das Projekt startet, dann ist schon viel gewonnen. Also ich kenne auch ganz viele Projekte, wo das nicht existiert hat in der Vergangenheit, und ich bin sehr froh, dass wir mittlerweile an dem Punkt sind, dass es einfach zur Kultur gehört und einfach dass alle das mit pflegen und weil das so wichtig ist.
Tobias
Ich wollte nochmal einen Punkt aufgreifen. Du hast für uns das Stichwort Weg, den Weg, den ich gehen will, genannt. Und in unserem Forum kam eine schöne Metapher auf ein schönes Bild, wurde da gesagt. Und zwar wurde das Arbeiten ohne Konzept beschrieben als, na ja, ich habe eine Vorstellung, wie das, was das Ziel sein soll. Und jetzt gehe ich in das Labyrinth rein und werde gucken, wo ich, wo ich rauskomme. Und das wurde damit verglichen. Wenn ich ein Konzept habe, dann schaue ich wie von oben auf dieses Labyrinth drauf und mache mir quasi vorher Gedanken, wo sind denn die Sackgassen? Welche Richtung sollte ich abbiegen, um eine große D-Tour, Umweg zu vermeiden? Dieses Bild finde ich ganz schön, weil es ist quasi der Heck, um vorher sich einen Plan zu machen, wo gehe ich lang. Und dadurch wird der Weg nicht automatisch einfacher oder kürzer oder sonst irgendwas. Aber ich vermeide halt vielleicht ein paar Sackgassen, die ich eben von vornherein sehen kann. Und damit für uns auch als Projekt-Umsetzer steckt der große Vorteil drin. Naja, es wird planbar, weil wir sind verlässlicher in dem, wo wir sagen, wie lange wird es denn dauern? Wir haben uns Gedanken darüber gemacht und es ist nicht mehr so lange, wie es dauert.
Sebastian
das nimmt halt viel Risiko raus, also ich sag mal, du hast trotzdem noch diese unknown unknowns, also die Unbekannten, die niemand auf dem Zettel hatte vorher, das ist natürlich immer so, je nach Problemfeld und Problemgröße, aber du hast zumindest hier über die known unknowns, also die Sachen, wo du weißt, dass sie kommen werden, so dieses Ja, da ist ein Thema in der Ecke, da hast du mal hingeguckt und das ist eigentlich der Mehrwert, würde ich sagen, typischerweise ist ja diese Rate known zu unknown unknowns, ist ja 90 zu 10, also würde ich mal sagen, also sprich, das meiste ist eigentlich, wenn man strukturiert übernachtet, eigentlich in der known Ecke zu finden, also in der bekannten Ecke und deshalb ist das so effektiv.
Tobias
Jetzt haben wir über den Weg gesprochen, du hattest vor uns, als wir darüber gesprochen haben, was steckt denn in so einem Konzept eigentlich drin, hattest du schön beschrieben, du machst ja auch Gedanken über mögliche Lösungen.
Sebastian
Tobias
Wege. Wie kommst du denn dazu, dich dann für einen zu entscheiden oder wie schließt du welche davon aus?
Sebastian
Also, wie soll ich sagen, ich finde, wenn man, also zum Beispiel, wenn ich mich für irgendeine Technologie entscheiden muss beispielsweise, also für ein Projekt, um PDFs zu generieren beispielsweise, das ist jetzt ein Konzept, was zum Beispiel ein Kollege von mir vor kurzem geschrieben hat, was da schön ersichtlich war, war sozusagen, okay, ich habe das und das Problem in dem Szenario, was ich lösen will, ich brauche zum Beispiel Tabellen in einer bestimmten Variation und dann halt kann man, weil man das ja schon das Problem beschrieben hat, kann man quasi immer dann gucken für jedes, für jede, alles, was man findet, erst mal auf die Liste packen sozusagen und dann gucke ich halt nach Kriterien, dann gucke ich halt einfach nur wirklich relativ stupide, sage ich mal, ist das Projekt gemaintaint, also ist das gepflegt, kann es das, was ich möchte, gibt es vielleicht Beispiele dafür, gibt es Doku für dieses Szenario, was ich halt, also ich kann viel spezifischer danach suchen, weil ich halt zum Beispiel dann nicht nur suche, ah, kommt da ein PDF bei raus, sondern PDF-Generierungsgeschichte, sondern ich kann halt gezielt danach suchen, gibt es mehrseitige Tabellen, das ist eine ganz konkrete Frage, da kann ich super nach suchen, kann auch auf Stack Overflow vielleicht andere Antworten dazu finden und das ist aus meiner Sicht da der, was einem da hilft.
Tobias
Und du hattest vor uns noch das Stichwort Prototyp gebracht, das wäre jetzt noch ein Schritt weiter zu "ich suche nach" oder "ich kann besser nach möglichen Lösungen suchen".
Sebastian
ja mal so. Was man mit meinem Konzept auch merken kann, ist so dieses Szenario, man stochert. Also das ist so, man versucht was aufzuschreiben, aber irgendwie, es finden sich keine Worte. Das ist für mich eigentlich ein Symptom für entweder, wir haben das Problem noch nicht gut genug verstanden, oder wir haben so wirklich gar keine Ahnung von der Lösungsdomäne, von dem Lösungsraum. Und in beiden Fällen bin ich nicht in der Lage, ein gutes Konzept oder überhaupt ein Konzept zu schreiben, sondern da kann ich eigentlich mich nur in Plattitüten verlieren. Da kann ich nur sagen, ja das muss alles ganz toll und ganz schnell und ganz performant sein, aber ich kann gar nicht mehr formulieren, was eigentlich so. Und da können aus meiner Sicht ein paar Sachen helfen, da kann man halt, man kann mit anderen Leuten reden, man kann sich Feedback einholen. Und was für mich persönlich sehr gut funktioniert, ist da parallelen Prototypen zu bauen. Und wenn ich sozusagen eine ganz konkrete Fragestellung habe, wie zum Beispiel dieses PDF-Generierungsbeispiel, um dabei zu bleiben, dann kann ich mit wenig Zeit, ich nehme mir so eine Library oder ich habe zum Beispiel die Auswahl schon eingedampft, ich weiß, es gibt A oder B, die in Frage kämen für dieses Generieren von Tabellen. Und dann ist jetzt die Frage, ja welche nimmt man jetzt? Und dann finde ich es hilfreich, an so einem Punkt zu sagen, okay ich nehme mir mal eine halbe Stunde Zeit und ich sage jetzt bewusst eine halbe Stunde, also sehr wenig Zeit. Ich nehme mir irgendeine lange Tabelle und wenn da nur "Hallo Welt", "Hallo Welt", "Hallo Welt", "Hallo Welt" drin steht, die aber über drei Seiten geht und ich probiere das einfach mal und werfe das mal in dieses Tool rein und gucke mal, was passiert. Und das ist auch ein sehr effektiver Weg, um Erkenntnisse zu gewinnen und ebende den Weg dann Richtung Implementierung irgendwann mal auch. Aber das geht nur dann, wenn ich wirklich auch eine konkrete Fragestellung habe. Also deshalb ist es so wichtig vorher irgendwo ein Konzept zu haben, weil ich dann quasi die neuralgischen Punkte kenne und, also Stichwort "Rabbit holes" und quasi genau weiß, wo muss ich denn drauf achten bei der Generierung zum Beispiel von PDFs und was will ich eigentlich ausprobieren. Und dann sinkt auch der Aufwand, so einen Prototypen zu bauen massiv, weil ich quasi eine ganz konkrete Fragestellung habe und nicht mehr nur so allgemein bin, ja ich will das Werkzeug XY mal ausprobieren.
Tobias
Da brauchst du dann nicht den Prototypen sozusagen für die komplette Lösung schon, sondern um einzelne Aspekte daraus.
Sebastian
Um quasi Hochrisikoaspekte sozusagen anzuschauen und um auch selber so ein gewisses Feeling zu bekommen, wie fühlt sich denn eine gewisse Lösung an? Also kann ich mir wirklich vorstellen, die dann auch längerfristig zu entwickeln?
Tobias
Ich glaube, das Thema Prototyping als Technik können wir auch separat nochmal beleuchten in der Folge und auch das Thema Sebastians ominöses Gefühl zu beschreiben, werden wir uns noch mal anschauen. Ja, dann kommen wir schon zum Schluss der heutigen Folge. Mein Gefühl, was Konzepte angeht, hat sich durchaus verbessert durch das Gespräch in unserem Forum. Auch jetzt nochmal hier auf den Punkt gebracht. Dein Fazit, Sebastian, du hast es ja eingangs auch gesagt, du hattest dir das auch vorgenommen als persönliches Entwicklungsthema.
Sebastian
Zwischenfazit? Also, mir hilft es mega mäßig, muss ich sagen. Also, ich merke auch, dass ich damit in der Lage bin, viel schneller wieder in ein Thema einzutauchen, auch diese, ich sag mal, diese, diese Kontextwechselzeit zu reduzieren, was jetzt bei mir ein Extremfall ist, weil ich halt viele Kontextwechsel habe. Aber trotzdem habe ich das Gefühl, ich kann viel leichter sozusagen Fäden wieder aufsammeln, die ich halt, die ich halt am Tag davor oder eine Woche davor oder wo auch immer halt gemacht habe. Und ich merke auch, wie schwierig es mir fällt. Manchmal habe ich, ich mache natürlich auch nie immer Konzepte, sondern manchmal bin ich halt auch lazy und denke mir so, dann sehe ich das irgendwann eine Zeit x später, denke mir so, ja, was habe ich jetzt mir dabei gedacht, ja, wie war das nochmal? Und dann kommt es zwar alles wieder, aber ich merke einfach, es braucht viel, viel länger. Also, ich würde empfehlen, probiert es aus. Es ist natürlich nur ein Werkzeug, es ist nicht der heilige Gral, aber ich denke, es kann einen sehr, sehr großen Impact haben. Und genau deshalb würde ich jeden dazu motivieren, das mal auszuprobieren.
Tobias
Sind wir das sehr gespannt, was unsere Hörerinnen und Hörer uns als Feedback zu dieser Folge und zum Thema technische Konzepte zuschicken werden? Probiert es aus. Wir sind gespannt, wie eure Erfahrungen damit sind. Lasst es uns gerne wissen. Auf den verschiedenen Kanälen, die sind auch wieder in den Show Notes verlinkt, per E-Mail auf unseren Social Media Kanälen. Und dann bleibt mir noch zu sagen, Sebastian, danke für das Gespräch.
Sebastian
Hat Spaß gemacht.
Tobias
Mal wieder eine technische Folge. Und wir freuen uns schon, wenn ihr wieder einschaltet zur nächsten Folge vom Sandpapier. Macht's gut und tschüss.