Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#108 - Einen eigenen Time Tracker für Consultants - taod Consulting Case Study
196 Plays6 months ago
In dieser Folge spricht Adriano mit einem unserer Entwickler - Luka Weingärtner.
Luka hat für einen unserer Kunden - taod Consulting - eine Software zur Zeiterfassung gebaut. Das Ganze läuft über Bubble und Make mit der Integration von Personio und Jira.
Wie das Ganze zustande kam und wie Luka das Projekt umgesetzt hat, erfährst du in dieser Folge.
Links zur Folge:
taod Consulting: https://www.taod.de/
Unsere Case Study: https://www.visualmakers.de/case-studies/intuitive-zeiterfassung-mit-bubble-make-mit-personio-jira-integration
/// Gefällt dir unser VisualMakers Content? Werde selbst zum VisualMaker mit einem unserer vielen kostenlosen Kurse. Starte jetzt durch und werde No-Code Profi: https://www.visualmakers.de/academy
/// Werde Teil der größten deutschsprachigen No-Code Community: Slack: https://bit.ly/vm-slack
/// Folge uns auf
LinkedIn: https://bit.ly/3SfL6oO
Youtube: https://bit.ly/3OF5jBj
Instagram: https://bit.ly/3cMYH6N
///Jetzt Newsletter abonnieren und keine No-Code News mehr verpassen!
https://bit.ly/3cMYNeF
Recommended
Transcript
00:00:00
Speaker
Das
Einführung in die Tech-Stack-Entscheidung
00:00:00
Speaker
heißt, die haben sich genau wie jeder andere erstmal in die Tools eingearbeitet, geschaut, was gibt es auf dem Markt überhaupt, was könnte da passend sein, sich dann eben für Bubble und Made entschieden, was meiner Wahrnehmung auch dann eine gute Wahl war für den Tag Stack und haben einfach mal losgelegt und haben eben selbstständig was gebaut und das auch in Eigenregie eben so weit gebracht, dass sie es dann auch tatsächlich im kompletten Unternehmen eben genutzt haben.
00:00:30
Speaker
Herzlich
Vorstellung von Luca Weingärtner
00:00:30
Speaker
willkommen zu einer neuen Folge des Visual Makers Podcast. Heute spreche ich mit Luca Weingärtner. Luca ist einer unserer Entwickler hier bei Visual Makers und wir sprechen über ein Projekt, das er kürzlich beendet hat, nämlich den Tout Time Tracker. Das ist jedenfalls der interne Name bei uns und das Produkt ist an sich auch ein internes Produkt von einem Kunden. Der Kunde
00:00:51
Speaker
Taut hat dieses Produkt selber angefangen zu bauen und irgendwann mal dann an uns abgegeben. Die ganze Story dahinter, wie Luca das angenommen hat, umgesetzt hat und was er daraus gemacht hat, das hören wir heute. Und ich freue mich sehr darauf, dass er heute da ist. Herzlich
Luca's Hintergrund und Übergang zu No-Code
00:01:07
Speaker
willkommen, Luca. Ich freue mich sehr, dass du dabei bist. Wie ist die Lage? Vielen Dank für die Einladung. Ja, sehr gut. Danke. Sehr schön. Du hast natürlich auch das richtige Branding an. Ich habe meinen Pulli leider nicht dabei.
00:01:18
Speaker
Aber genau, wie ihr seht. Ja, ich habe es schon angekündigt in der Intro. Du bist Teil des Visual Makers Teams. Du bist Entwickler bei uns. Ja, vielleicht kannst du dich den Zuhörenden einmal vorstellen, wer du bist, was du so machst, bevor wir über das heutige Thema sprechen. Ja, sehr gerne. Also Luca ist mein Name. Ich komme eigentlich so aus dem wirtschaftlichen Bereich. Also habe Betriebswirtschaft studiert und dann auch nach dem Bachelor gegründet.
00:01:44
Speaker
und habe dadurch auch meine ersten Beratungspunkte mit Node-Code gehabt. Das heißt, das Grundungskonzept wurde auch dann bei uns mit Node-Code umgesetzt. Und genau jetzt bin ich seit etwas über einem Jahr hier Node-Code-Entwickler bei VisualMajors. Sehr cool. Und heute sprechen wir über den Taut Timetracker. Das
Herkunft des Tout Time Trackers
00:02:06
Speaker
ist einer deiner letzten Projekte gewesen, richtig? Wann hast du das fertig gemacht?
00:02:11
Speaker
Das ist schon Ende letzten Jahres gewesen. Ich glaube November, Dezember. Ist schon ein bisschen her. Sehr cool. Kannst du uns einmal kurz dazu abholen, was und wer TAUT genau ist? TAUT hat es leider nicht in dem Podcast geschafft, weil die natürlich auch sehr, sehr busy sind. Als Consulting und Agency haben die natürlich viel zu tun, aber sie haben sich sehr gefreut darüber, dass wir jetzt über das Projekt sprechen.
00:02:36
Speaker
So, kurzer Kamerawechsel. Bei mir spinnt die Kamera hier die ganze Zeit, also für diejenigen, die es auf YouTube sehen, nicht wundern. Aber wir springen jetzt zurück zur Frage, was oder wer TAUT ist. Ja, sehr gerne. Genau, wie du es schon angesprochen hast, TAUT Beratungsagentur hier auch aus dem schönen Köln, aus dem Rheinland.
00:02:56
Speaker
Und die einzelnen Buchstaben, also TAU steht für die Art of Data, was auch ziemlich gut beschreibt, was die machen, quasi im großen Stil eben Datenanalysen und große Datenmengen zu verarbeiten und damit eben Unternehmen zu helfen. Sehr cool.
Funktionsweise des Time Trackers
00:03:10
Speaker
Genau. Und ja, also für alle, die sich dafür interessieren, was TAU im Detail macht und was sie so machen, den Link zur Website findet ihr natürlich in der Episodenbeschreibung.
00:03:21
Speaker
So, und TAUT hatte dann ein Anliegen, mit dem sie auf uns zugekommen sind. Und das ist das, was wir, das habe ich im Intro auch schon gesneakpeakt sozusagen, das nennen wir in TAUT Timetracker. Es ist etwas, was die auch so nennen, weißt du das? Ja, das nenne ich tatsächlich genauso. Also der Name kommt sogar von denen.
00:03:42
Speaker
Ah ja, okay, gut, dann haben wir den Namen so übernommen. Was ist denn der Taut Time Tracker? Wenn wir schon beim Namen sind, der Name ist eigentlich ein bisschen irreführend, weil die Zeit gar nicht getrackt wird in dem Tool, sondern es ist mehr eine Art Zeit-Synchronisations-Tool. Das bedeutet, die hatten das Problem, dass sie zwei Services nutzen. Das ist einmal Jira als Projektmanagement-Tool und einmal Sonio als Personaltool, wenn man so möchte.
00:04:10
Speaker
Und dort müssen die gleichen Daten immer eingetragen werden. Das heißt, die Beratenden setzen dann da am Abend, wollen ihre Zeiten eben eintragen und müssen das einmal eben in dem Tool machen und dann die Summe aus allen Projekt-Tickets dann nochmal in Personio. Und das war einfach ziemlich redundant. Und dann sind sie hin und her und haben sich gedacht, okay, das muss doch eigentlich auch einfach handeln.
00:04:31
Speaker
und haben eben dieses Tool dann tatsächlich auch selber entwickelt, selber entworfen, was diese Doppelarbeit eben abnimmt. Das heißt,
Technologie-Stack und Verbesserungen
00:04:40
Speaker
die BeraterInnen können einfach hingehen, in dem Tool selbst ihre Tickets auswählen, ihre Zeiten auf die einzelnen Jira-Tickets buchen. Und dann wird das eben sowohl an Jira synchronisiert, als dann auch die Summe der einzelnen Zeit einträgt, dann als Gesamtarbeitszeit an Personio. Und so, ja, müssen nicht mehr in beide Tools angebucht werden, sondern es kann alles in einem gebucht werden.
00:05:02
Speaker
Okay, das heißt, ich bin da in diesem ganzen Thema gar nicht so detailliert drin, aber seit einiger Zeit ist es ja so, dass Arbeitszeiten genau erfasst werden müssen, gesetzlich. Das ist ja, ich meine, das kennen wir als Agentur ja selber auch so, das müssen wir auch alle machen. Und Taot hatte dann wahrscheinlich
00:05:18
Speaker
dasselbe Problem in Anführungszeichen. Das Problem hat aber eher die Natur, dass es in mehreren Tools passieren musste. Und das natürlich voller Pain. Und ich glaube gerade bei Consultants, die jede Minute sehr, sehr wertschätzen, das ist wahrscheinlich super nervig, wenn du dich dann verschiedene Tools einloggen musst. Und dann haben die aber angefangen, dass
00:05:39
Speaker
die Lösung dafür, selber zu konzipieren und sogar selber umzusetzen, richtig? Also das MVP, ich weiß nicht, wie weit das schon war in der Funktionalität und in der Nutzung, aber die haben erst mal angefangen, das intern selber zu bauen. Genau, und es war tatsächlich auch schon im Einsatz. Also die haben das auf einen Stand gebracht, wo sie es selber auch dann schon live geschaltet haben und wo die BeraterInnen das auch tagtäglich genutzt haben. Und das komplett ohne, dass wir dabei waren zu dem Zeitpunkt.
00:06:13
Speaker
Worüber wurde das gebaut und wie war der Stand von dem Time Tracker, bevor es an uns abgegeben wurde? Und vielleicht kannst du auch schon erzählen, wie es dazu kam, dass das Tout dann auf uns zukam und gesagt hat, hey, könnt ihr das übernehmen? Also, der Tag-Stack von dem ganzen Tool ist Bubble und Make.
00:06:33
Speaker
Babel einfach natürlich als Frontend und auch als Datenbasis und Maid dann für die Synchronisation einerseits dann von Jira hin zu Babel, als dann auch eben die Einträge, die dann in Babel getätigt werden, eben hin zu Jira und auch zu Personio, also diese ganze Synchronisationsschnittstelle, da ist Maid nochmal zwischengeschaltet, weil dann nochmal ein paar Schritte quasi erforderlich sind, damit das Ganze auch reibungslos funktioniert.
00:06:55
Speaker
Genau, und der Stand, also an sich lief die App und war funktional. Dann sind aber halt so ein paar kleinere Sachen aufgetreten, also das waren sowohl kleinere Bugs, als auch eben Feature-Wünsche vor allen Dingen, dass man gesagt hat, okay, kann man nicht irgendwie die Funktion noch mit reinnehmen, wir würden gern Favoriten speichern können, wir würden gern hier,
00:07:20
Speaker
Die Filterungen sollen noch mit drin sein, etc. Und das waren einfach Wünsche, wo dann auf der Seite die Zeit gefehlt hat, die umzusetzen.
Erweiterung des Projektumfangs
00:07:30
Speaker
Und da wir sowieso im Vorhinein schon Kontakt bestanden über ein anderes Projekt, war dann der Weg kurz zu sagen, hey, habt ihr nicht auch noch Zeit, uns da weiter zu helfen, weil uns intern einfach die Kapazität fehlt, da die Fortschritte zu machen und das in der Schnelligkeit, wie wir es denn gerne hätten.
00:07:46
Speaker
Genau, und dann kam sie auf uns zu, eben einfach mit einer Liste hier, die Features würden wir uns wünschen, die Buds sind uns aufgefallen. Macht mal. Du hast mir eben im Vorhinein ja auch schon verraten, dass die Idee war ja erst mal so, hey, könnt ihr die Kleinigkeiten noch umsetzen, ein paar Features, und dann hat es aber nochmal einen anderen Ausmaß angenommen, weil auf einmal doch
00:08:10
Speaker
viel mehr von dem Tool gewollt wurde oder erwartet wurde? Oder war das einfach, weil im Zuge der neuen Features das alles viel zu komplex wurde? Weil du meintest zu mir, wenn ich mich richtig entsinne, dass da schon viel ... Also, so einige Kernfunktionen sind heute noch so drin, wie sie damals übernommen wurden. Aber ... Ich weiß nicht, prozentmäßig, wie viel würdest du sagen, hast du dann komplett neu ansetzen müssen?
00:08:39
Speaker
Ja, also da die komplette App noch auf der alten Battle Engine gebaut wurde, auf diesem Fixed Layout, sodass die App eben nicht responsive war, musste ich tatsächlich auch jedes Element anpacken und das eben vom Design her anpassen. Von der Grundfunktionalität würde ich schon sagen,
00:08:59
Speaker
vielleicht so 50 Prozent beibehalten werden konnten. Auch von den Make-Workflows konnten ungefähr 50 Prozent so benommen werden und dann eben angepasst. Genau, also erst mal waren es eben so kleinere Feature-Wünsche. Hier, das würden wir uns noch wünschen, das würden wir uns noch wünschen. Hier sind ein paar Bugs. Das war einfach so hier, das ist uns irgendwie aufgefallen und könnt ihr euch darum kümmern.
00:09:27
Speaker
Und dann der nächste Schritt war, dass sie intern unter allen Beratern quasi die Umfrage gemacht haben, was wünscht ihr euch vom Tool, wie nutzt ihr das Tool, was ist vielleicht gerade nervig. Und da kam eben heraus, dass das Tool, so wie es aktuell aufgebaut ist, vom Prozess des Time-Tracking,
00:09:46
Speaker
dass das einfach nicht so effizient war. Ein Beispiel ist, dass beim Tool wurde zu Beginn nach der Gesamtarbeitszeit gefragt, zum Beispiel acht Stunden, und dann konnte im nächsten Schritt diese Gesamtarbeitszeit eben auf die einzelnen Tickets verteilt werden.
00:10:04
Speaker
Das ist aber vom Prozess her gar nicht so clever, weil die BeraterInnen auch während des Tages schon mal Zwischenbruchungen machen möchten, wo sie noch gar nicht wissen, wie viel Gesamtzeit. Und vor allem auch dieser Input der Gesamtzeit.
00:10:19
Speaker
den separat einzutragen, ist eigentlich auch gar nicht notwendig, weil man ja einfach die Summe der einzelnen Zeitbuchen, der einzelnen Tickets quasi nehmen könnte. Das
Benutzeroberfläche und Benutzererfahrung
00:10:28
Speaker
entspricht in der Gesamtarbeitszeit. Das heißt, das war so ein Schritt, den haben wir einfach komplett rausgeschmissen und der wird dann am Ende des Prozesses automatisch berechnet und dann eben automatisch an Personio übermittelt. Also da einfach so ein paar kleinere
00:10:42
Speaker
Stellschrauben gedreht, Automation gemacht, dass eben dieser komplette Prozess des Zeitbuchens verschlangt werden könnte, was dann eben auch dazu führt, dass es einfach besser und einfacher und schneller nutzbar ist. Ich glaube, das ist auch ein gutes Beispiel für so ein bisschen User Flow beziehungsweise
00:11:03
Speaker
UI UX, aber einfach so die User Experience insofern, dass die erste Version war funktional, also hat das getan, was sie sollte. Aber, und das kennen wir natürlich aus dem Daily Agency Leben mit jedem neuen Kunden, ist das ja, wir wollen das so genau haben und dann sind wir so, okay, vielleicht sollten wir uns erstmal mit User Stories und User Flow auseinandersetzen, weil
00:11:28
Speaker
Das wird so nicht funktionieren, das wird so keiner nutzen wollen, das wird sich in einem Monat dann irgendwie nicht bewähren können und so. Und das ist ja, glaube ich, ein ganz gutes Beispiel, genau dieses so.
00:11:37
Speaker
Klar, am Ende sollst du zwar eintragen, wie viel hast du an dem Tag gearbeitet, aber wie nutzen das die Leute wirklich? Und wenn du dann rausfindest, naja, die tragen alle paar Minuten, tragen die was ein, oder dreimal am Tag tragen die was ein, dann, genau, entlang so einem Userflow, jeder, der Produkte schon mal entwickelt hat, dem wird das wahrscheinlich ein Begriff sein, merkt man dann eben so, aha, okay, vielleicht muss ...
00:12:00
Speaker
das Interface doch so aussehen. Wie habt ihr das dann damals mit Taut gemacht? Also sie kam ja mit Wünschen zu euch. Habt ihr die direkt so umgesetzt oder habt ihr dann nochmal mit den BeraterInnen gesprochen, ob das wirklich so in der Form passieren soll?
Herausforderungen und technische Lösungen
00:12:18
Speaker
Ne, also mit dem Berater in selbst direkten Totat hatten wir nicht, sondern es lief dann alles eben über unsere Totatpersonen bei Tarot. Was darf natürlich schon rutsprachen, dass dann von der Seite auch gefragt wurde, okay, dieses Feature, lässt sich das so umsetzen? Wie aufwendig ist das? Habt ihr da eine andere Idee, wie man das vielleicht machen könnte? Und da sind wir dann schon quasi in die Diskussion gegangen, um zu schauen, wie können wir die App eben
00:12:41
Speaker
nach eurem Wünschen da bestmöglich gestalten. Und dann auch eben haben wir sowas wie Performance-Themen mit reingenommen. Das Ganze quasi auch in die Entscheidung, wie was umgesetzt wird. Also da kam schon so ein bisschen Input von uns, aber natürlich in erster Linie statt die Funktionalität im Raum oder im Vordergrund, die die sich gewünscht haben. Wenn du Performance-Themen sagst, was ist jetzt konkret bei dem Produkt gemeint?
00:13:09
Speaker
Konkret ist gemeint, dass die Liste an Tickets, die eben in Jira vorhanden sind, die dann auch in Babel läufig vorhanden sind, die ist schon sehr lang. Und da gibt es dann einfach bestimmte Tweets, die man machen kann, dass die Datenbandabfragen schneller laufen mit Vorfilterungen et cetera. Einmal um ein bisschen ins Technische reinzugehen. Du hast ja gesagt,
00:13:35
Speaker
Wir haben's übernommen als altes Bubble-Layout noch. Musstest du das komplett ... Also, musstest du sozusagen in Bubble ein neues Projekt anfangen, oder konntest du das einfach in dem Existierenden umbauen? Ich hab's in dem Existierenden umgebaut. Okay. Und es gibt ... Grundsätzlich gibt's auch von Bubble selbst die Option zu sagen, ich hab eine Page, die ist noch auf einem Fixed-Layout, übertrat mir die bitte mal ins Responsive-Layout. Funktioniert, Furchtbar. Kann ich nicht empfehlen. Hab ich fast gedacht.
00:14:05
Speaker
Also an sich tatsächlich, wenn man jetzt gar keine Zeit reinstellen möchte, funktioniert das sogar okay, aber Bubble geht halt hin und erstellt sehr, sehr viele Gruppen, um eben das Layout, so wie es vorher war, nachbilden zu können, um es quasi responsive zu machen. Und das ist dann überhaupt nicht mehr übersichtlich im Editor, wenn man damit eben weiterarbeiten möchte. Also da würde ich jedem empfehlen, der das gleiche Problem hat, da einfach mal schnell
00:14:33
Speaker
die Hand zu legen und das ganze händlich zu machen. Und es geht dann auch. Ist nett gemeint, aber wie wir im Deutschen so schön sagen, verschlimmbessert. Ja, total.
00:14:45
Speaker
Okay, hat Bobble wahrscheinlich damals mit der neuen Engine gedacht, so hey, lass uns die Funktion anbieten, um es den Leuten leichter zu machen. Aber insofern leichter, dass man nicht viel umbauen muss, aber insofern schlechter, dass am Ende alles Kuddelmodel ist wahrscheinlich. Na gut, aber du hast es dann also in dem existierenden Projekt auf die neue Engine umgebaut.
00:15:07
Speaker
Und da bist du in ... Also, wie bist du dann da rangegangen? Also, responsiveness first sozusagen im Kopf gehabt? Oder ... Nutzen das die BeraterInnen von Taot auch mobil, oder ist das hauptsächlich nur Web? Na ja, also, mobil ist eigentlich überhaupt kein Thema. Was aber ein Thema ist, ist, dass dann auf dem Laptop wird das Fenster mit der App eben auf den halben Screen. Also, Speedscreen-mäßig dann ...
00:15:34
Speaker
dann geteilt. Und das hat tatsächlich zu Problemen geführt, dass dann bestimmte Elemente verschwunden sind, irgendwie verrutscht sind, nicht mehr richtig anzeigt wurden, etc. Deswegen da musste quasi dann die Responsiveness gegeben sein, dass man es auf kleinen Bildschirmen nutzen kann. Und das ist einfach beim Entwickeln, hat man das dann so, also wir entwickeln ja tagtäglich in der neuen Bubble Engine. Das heißt, es ist dann einfach, ich habe jetzt nicht grundsätzlich drüber nachgedacht oder es müssen da irgendwelche besonderen Schritte gehen, sondern ich habe es einfach
00:16:04
Speaker
so gebaut, wie ich es jetzt auch bauen würde, wenn ich es komplett neu von Grund auf baue. Das hat kein Problem.
00:16:11
Speaker
Zum Thema Daten, weil es sind ja sowohl Jira als auch Personio angebunden, richtig? Das läuft über normale API-Calls bei Bubble oder wie sind die Sachen angebunden? Genau, die sind tatsächlich halt über Maid angebunden. Ach, das ist es, ja. Genau, die Kommunikation funktioniert von Bubble zu Maid und dann eben von Maid zu Jira und Personio.
00:16:36
Speaker
Und auf dem anderen Weg genauso, also auch von Jira. Die Daten werden erstmal in Maid gespielt über Webhooks. Und dann eben von Maid in Bubble synchronisiert. Ist das, also was ist der Grund, dass Maid dazwischen geschaltet ist? Und nicht direkt Bubble API? Ja, es werden einfach nochmal Zwischenfragen eben gestellt, Zwischenabfragen, es wird geschaut, gibt's diesen Eintritt schon, gibt's dieses Ticket schon, muss das neu angelegt werden, muss das bearbeitet werden.
00:17:05
Speaker
Also ein paar Zwischenschritte, die notwendig sind, dafür, dass die App reibungslos läuft. Und dass auch, wenn irgendwo ein händlicher Fehler passiert, dass es eben trotzdem dann alles zu tun bleibt. Fair. Genau. Ich glaube, bei Make hat man ja da eine sehr, sehr gute Übersicht über das Ganze dann.
00:17:22
Speaker
Okay, so, wir verstehen jetzt ungefähr, wie das im Backend funktioniert. Du hast das responsive umgebaut. Die Daten werden über Make als Mittelstück sozusagen dann in Jira und Personium eingespielt und zurück. Du
Frontend-Funktionen und Benutzerinteraktion
00:17:33
Speaker
hast mir auch vorhin einen erklärt, dass der Prozess etwas komplexer, weil man ja auch sicherstellen muss, dass es keine Doppelbuchungen und sowas gibt, richtig? Aber das funktioniert jetzt gut, nehme ich an.
00:17:45
Speaker
Und die gesamte Idee, haben wir am Anfang ja auch schon erwähnt, war ja, dass die BeraterInnen dann einfach auf den Tower-Trying-Tracker gehen, ihre Sachen eingeben und sich nicht darum kümmern müssen, ob das jetzt in richtig in Personio und in Jira, sondern das läuft über die eine Schnittstelle. Wie sieht das denn im Frontend aus? Also, wenn du uns jetzt so ein Bild malen müsstest, wie kann man sich das vorstellen, die UI UX? Mhm.
00:18:10
Speaker
Wenn sich die Beraterin einloggen, auf der Startseite ist der Hauptteil der Seite das Kalendermodul und da sind auch die notwendigen Informationen direkt mit integriert. Das heißt, man sieht quasi auf den ersten Blick, habe ich für diesen Tag schon Zeiten gebucht, fehlen noch Zeiten, habe ich die letzte Woche komplett gebucht, ist auch in beide Tools, also sowohl Jira als auch Personio, sind da die Daten ordentlich synchronisiert hin.
00:18:37
Speaker
Das heißt, man sieht quasi über dieses Kalendermodul auf den ersten Blick, wie ist mein aktueller Stand. Und dann, wenn die Beraterinnen auf die einzelnen Tage klicken, dann werden eben rechts daneben die Tickets angezeigt mit der jeweiligen Zeitbuchung, auf welche Tickets eben gebucht wurde. Und auch da nochmal dann die Zusammenfassung der Gesamtzeit synchronisiert an Jira und Personio. Genau. Und dann gibt es eben die Möglichkeit, diese Einträge zu bearbeiten.
00:19:04
Speaker
zu löschen oder wenn ich eben auf einer Datum bin, was noch keine Zeitenträge hat, dann eben neue Zeitenträge zu starten. Darüber komme ich dann eben auf die nächste Page, auf der ich dann die einzelnen Tickets auswähle, auf die ich buchen möchte. Auch da haben wir neue Funktionen eingeführt. Zum Beispiel, was jetzt der Fall ist und was jetzt möglich ist, ist, dass
00:19:29
Speaker
die Funktion, welche Tickets mir zugewiesen sind in Jira, also in dem Project Management Tool, wird mir jetzt als Entwickler dieses Ticket zugewiesen. Und dann muss ich das im Time Tracking Tool nicht noch irgendwie manuell suchen oder auswählen, sondern ich hab dann direkt Liste hier, diese Tickets mir zugewiesen. Man kann ebenso auch sehr schnell eben auf die Tickets zugreifen, auf die ich buchen möchte. Genau, wähl mir dann da einfach meine Tickets zusammen, kann auch Favoriten festlegen, etc.
00:19:56
Speaker
Und im nächsten Schritt wird dann einfach noch eine Description abgefragt, also eine Arbeitsbeschreibung in dem Fall, plus natürlich der Zeiteintrag. Genau, das wird dann abgeschickt. Und dann im letzten Schritt, und das war auch ein ex-minizierter Wunsch von Taut, erscheint dann noch mal ein Pop-up, wo quasi die Synchronisation dargestellt wird. Das heißt, man sieht die Tickets und natürlich auch den Personio-Eintrag. Und über einen Ladebalken wird dann eben symbolisiert, ob dieses Ticket
00:20:26
Speaker
schon erfolgreich eben an Jira oder Personio synchronisiert wurde. Weil da gab es nämlich im Vorhinein auch das Problem, dass wenn mal irgendwas gewesen sein sollte, dass aus irgendeinem Grund eben die Synchronisation nicht geklappt hat, dann ist es im alten Tool erstmal gar nicht aufgefallen. Und das ist natürlich dann blöd, wenn ein Fehler passiert und man ihn gar nicht mitbekommt. Und deswegen hier nochmal quasi dieses extra Safety-Feature, dass eben über das Pop-up nochmal in Echtzeit geschaut wird. Okay, hat die Synchronisation jetzt stattgefunden? Ja, dann hätt ich ihn dran.
00:20:56
Speaker
Und dann Trend-Liberator in noch sicher sein, dass alles funktioniert hat. Nice. Ja, das ist, ich glaube, das ist auch so ein klassisches Feature, was man
00:21:05
Speaker
Irgendwie, wenn es das immer gibt, dann nimmt man das so als gegeben, weil man das ja kennt aus guten UIs und UX, dass man immer so eine Art Bestätigung hat. Selbst aus so haptischen Geschichten hast du es ja immer lieber, wenn du sozusagen Feedback hast, wenn etwas passiert ist, funktioniert oder nicht funktioniert hat. Und das ist ja genau so ein Fall, der, ich glaube, wenn man so ein bisschen mit No-Code schon mal was oder wahrscheinlich auch generell entwickelt hat,
00:21:31
Speaker
oft komplizierter ist, als man denkt. Aber das ist auch so ein Prozess, der über Make läuft. Also, wenn die Buchung erfasst wird, geht es über Make an Personi und Jira, und dann geht sozusagen ein Feedback zurück, wenn eins geklappt hat. Genau so läuft das, ja. Okay, spannend. Ja, all das, genau diese kleinen Features, die man dann wahrscheinlich erst im Laufe der Nutzung merkt, wie wichtig sie doch sind, und dass man sie doch braucht.
00:21:57
Speaker
Cool. Ja, für alle die, die das sich
00:22:01
Speaker
optisch nochmal angucken wollen. Wir haben die Case Study zum Tao Time Tracker auf unserer Webseite. Der Link dazu ist auch in der in der Episoden Beschreibung. Da könnt ihr euch ungefähr angucken, wie das alles aussieht. Das ist eine sehr, sehr cleane, sehr einfache UI. Ich glaube, für ein Tool wie das einfach perfekt. Es ist ein internes Tool. Die Leute müssen es sowieso nutzen. Nichtsdestotrotz muss man das irgendwie trotzdem schön und clean hinkriegen und vor allem intuitiv. Und ich glaube, dass das
00:22:30
Speaker
Ich habe damit nicht gearbeitet, aber ich bin ja sehr zufrieden damit. Und es gibt bisher noch kein Feedback, das einfach komplett neu zu machen. Das würde ich sagen, das ist ein gutes Zeichen. Ja, je einfacher, desto besser. Gerade
Projektmanagement und Kommunikation
00:22:43
Speaker
bei so einer App quasi alles raus, was stört. Ja, so sieht's aus.
00:22:50
Speaker
Wie war denn sonst so die Zusammenarbeit jetzt für dich mit Taot, gerade die Kommunikation? Du hast etwas gemacht, du hast es ihnen geschickt, um zu gucken, ob das so ist, wie sie sich das vorgestellt haben. Und wie hat da die Kollaboration funktioniert? Genau, also man muss da quasi unterscheiden in diese zwei Projektphasen, die wir hatten. Zu Beginn waren das ja einfach klassische Tickets hier, das wir uns wünschen. Und dann wurden eben die Tickets einzeln abgearbeitet und dann noch abgenommen.
00:23:20
Speaker
Jetzt bei dem größeren Projekt wurde eben am Anfang oder zu Beginn ein Anforderungskatalog erstellt, so würden wir uns das vorstellen. Und dann wurde da in dem Zug auch schon direkt diskutiert, wie das genau umgesetzt werden soll, sodass da auch nicht zwischendurch noch mal grundsätzliche Absprachen notwendig waren. Natürlich war es trotzdem so, dass bei Projekthälfte
00:23:45
Speaker
einmal das Tool, wie es jetzt ist, gezeigt wurde. Und natürlich wurden zwischendurch auch noch kleinere Absprachen gemacht. Aber so grundsätzlich stand von dem Projektbeginn ganz klar fest, wie die App aufgebaut sein soll, wie die Funktionalität sein soll. Und dann war da auch im Laufe des Projekts nicht mehr viel Projektmanagement notwendig. Sehr cool. Dann noch zwei abschließende Fragen. Erstens, hattest du Spaß am Projekt? Auf jeden Fall. Also tatsächlich ist es irgendwie eine coole App, weil es
00:24:16
Speaker
weil es so direkt was bewirkt. Also du hast ein ganz konkretes Problem und eine ganz konkrete Lösung. Das finde ich immer sehr schön. Und natürlich ist es auch wieder so eine App, die ist im Frontend extrem simpel. Und dadurch, dass sie im Frontend so simpel sein kann, muss natürlich bestimmte Backend-Logiken einfach dann vorhanden sein. Das heißt, im Backend ist es dann schon nochmal komplizierter. Und das freut einen Entwickler wie mich dann auch, wenn ich quasi die UI da sehr
00:24:44
Speaker
sehr sleek und sehr minimalistisch ist und da halt viel Logik im Hintergrund drinsteckt, was den BeraterInnen dann leicht macht, das eben effizient zu nutzen.
Abschlussgedanken und No-Code-Potenzial
00:24:54
Speaker
Ja, das glaube ich. Das ist auch dieser klassische Fall von
00:24:59
Speaker
je weniger die User im Frontend merken, wie komplex es ist, desto besser. Das ist eigentlich, weil ich glaub, man kennt's, wenn man jemanden irgendwas zeigt und die Person denkt sich so, okay, cool, ich versteh nicht, warum du so ... excited darüber bist. Weil du im Background so irgendwie 15 Stunden lang an einer einzigen Funktion irgendwie gearbeitet hast. Aber das ist dann meistens genau dieses so, ah ja, okay, jetzt hab ich ein Feedback, dass die Sachen bei Personen eingetragen sind.
00:25:28
Speaker
Aber eigentlich, wenn man dann weiß, was da alles hintersteckt, ist es so, ja, genau, du hast jetzt ein Feedback, dass es geklappt hat. Ja, das hat zum Glück keine 15 Stunden gedauert. Aber ja, auch quasi so Filterfunktionen etc., die dann auch nach dem, welche Bereiche ausgefüllt sind etc. Da steckt dann bestimmt, da steckt dann schon eine gewisse Komplexität drin, aber die macht natürlich auch Spaß.
00:25:52
Speaker
Sehr gut. Und dann, was ist denn dein größtes Learning aus diesem Projekt? Was hast du da rausgezogen? Was würdest du anderen Leuten noch mitgeben, die entweder selber an so Projekten arbeiten als Entwicklerin oder an Companies, Startups, die überlegen, mit No-Code vielleicht anzufangen? Ja, also was ich an dem Projekt extrem spannend finde und was das Projekt auch unterscheidet von vielen anderen Projekten, die wir haben, ist, dass
00:26:17
Speaker
der grundsätzliche MVP gar nicht von uns stammt, sondern da ein Unternehmen war, die hatten ein Problem erkannt, die wollten eine Lösung dafür haben, haben auf dem Markt erst mal keine Lösung gefunden, haben sich gedacht, okay, dann machen wir die halt selbst. Und das sind jetzt auch, klar, die haben schon ein technisches Know-how, aber sind jetzt auch keine Softwareentwickler im klassischen Sinne. Das heißt, die haben sich genau wie jeder andere erst mal in die Tools eingearbeitet, geschaut, was gibt es auf dem Markt überhaupt, was könnte da passend sein, sich dann eben für Bubble und Made entschieden, was
00:26:47
Speaker
meiner Wahrnehmung auch dann eine gute Wahl war für den Tech Stack und haben einfach mal losgelegt und haben eben selbstständig was gebaut und das auch in eine Regie eben so weit gebracht, dass sie es dann auch tatsächlich im kompletten Unternehmen eben genutzt haben und auch gut funktioniert hat. Und ich finde, das ist so ein richtig gutes Zeichen, auch eben mal No-Code und dann viele Mittelständler, dass man sagt, hey, wenn ihr ein Problem habt und ihr findet keine Lösung dafür,
00:27:11
Speaker
Überlegt doch einfach mal, ob ihr es nicht selber machen könnt. Gerade so was wie jetzt eben, ich hab da Redundanzen und will die wegtreten, dafür eignet sich No-Code ja perfekt. Ja, absolut. Und ich glaube, für kleine Probleme, bei denen man vielleicht schon weiß, die Lösung ist gar nicht so komplex sowieso, aber selbst bei größeren Sachen nicht davor zurückschreckend zu sagen, okay, vielleicht kann ich das mit einem relativ simplen No-Code-Tool
00:27:36
Speaker
selber bauen und taut ist dieses mal also die sind direkt am bubble gegangen so ne ist wahrscheinlich nicht immer die erste empfehlung für jemand der sich noch nicht damit beschäftigt hat vielleicht können das tools wie gleich oder softer schon schon erledigen aber ja selbst wenn man das nicht hinkriegt und dann aber
00:27:52
Speaker
Weiß, okay, ich brauch diese Lösung trotzdem. Genau, dann gibt es natürlich da draußen immer Leute, die euch helfen können. Entweder wir natürlich, als Visual Makers Agentur. Aber es gibt auch genug tolle Freelancer. Auch bei uns in der Community gibt's ganz viele Freelancer. Genau, ich glaube, ja, meine zwei Szenen dazu wären eben, hey, wenn ihr da glaubt, ihr könnt euch eine einfache Lösung relativ schnell entweder selber bauen oder bauen lassen, dann nicht davor zurückschrecken.
00:28:21
Speaker
Genau, einfach mal starten, einfach mal loslegen. Ja, total. Und dann merkt man im Prozess ja auch, worauf kommt es wirklich an? Wie ist der Workflow? Macht es irgendwie Sinn, da Schritte wegzulassen? Also man hinterfragt diesen Workflow auch nochmal intensiver, wenn man das eben selber versucht, umzusetzen. Also das Problem. Von daher, wenn ihr Zeit und Lust habt, es macht ja auch Spaß, sich in so ein Thema einzuarbeiten, einfach mal auszuprobieren.
Ausblick auf neue Projekte
00:28:48
Speaker
Genau, und wenn's dann aus Kapazitätsdrücken nicht klappen sollte, dann gibt's andere, die Labort drauf haben. So sieht's aus, zum Beispiel Luca. Cool. Ja, Luca, sehr schön, dass du dabei warst. Hab mich sehr gefreut in deinem Podcast-Debüt bei uns. Hoffentlich nicht das letzte Mal. Am welchem Projekt sitzt du gerade? Was kannst du darüber erzählen, ohne dann vielleicht irgendwie in NDA zu sprechen? Gute Frage. Müssen wir vielleicht cutten im Nachhinein, ich weiß nicht.
00:29:17
Speaker
Aber aktuell sitze ich an einer Mobile App. Sorry, an einer was? An einer Mobile App, also an einer Native App, die dann eben in den App Store und in den Google Play Store gepublished wird, die Menschen mit Autismus helfen soll im Alltag. Ja, cool. Das ist dein erstes Flutterflow-Projekt in der Form, oder? Genau, das ist jetzt Flutterflow und Firebase als Text App bei uns.
00:29:42
Speaker
Sehr nice. Ich bin gespannt. Ich hoffe, dass wir dann, wenn das fertig ist, wieder darüber sprechen können. Ja, soviel können wir schon mal verraten. Den Rest dann im Nachgang, wenn es eben soweit ist. Aber ich bin gespannt. Ich auch, Herr. Vielen Dank für die Einladung. Hat mir sehr viel Spaß gemacht. Hoffentlich bald wieder. Das hoffe ich auch. Danke dir, Luca. Bis bald. Mach's gut. Ciao ciao.