Connect with us

Entwicklung & Code

Von Output zu Outcome: Entwickler als Produktgestalter


In vielen Softwareteams läuft die Entwicklung wie geschmiert. Entwicklerinnen und Entwickler sammeln Anforderungen, setzen Features um, schließen Sprints ab und liefern Releases aus. Es wird gebaut, getestet, deployt, immer und immer wieder. Und doch bleibt häufig ein diffuses Gefühl zurück. Warum diese Arbeit, warum der ganze Code? Selbst wenn man mit KI-Unterstützung noch schneller mehr Code erzeugen kann, heißt das noch lange nicht, dass am Ende viel Wert entsteht.

Weiterlesen nach der Anzeige


Dominique Winter

Dominique Winter

Dominique Winter ist Experte für erlebnisorientierte Produktentwicklung und unterstützt Organisationen dabei, begeisternde Produkte zu entwickeln. Praktische Erfahrungen aus der digitalen und nicht-digitalen Produktentwicklung ergänzt er durch langjährige Forschung in den Bereichen Organisationsentwicklung und User Experience. Seine Erfahrungen teilt er mit jedem, der Lust hat etwas Neues auszuprobieren und persönlich zu wachsen.

Darin liegt das Problem, das viele Produktteams haben: Der Fokus liegt auf Output. Die Teams setzen mehr und mehr Features um und messen den Fortschritt anhand der erledigten Arbeit. Produkte sammeln immer mehr Funktionalität an und wachsen kontinuierlich. Viele Produktverantwortliche glauben, dass das nötig ist, um sich vom Wettbewerb zu differenzieren und bestehenden Nutzerinnen und Nutzern ständig etwas Neues zu bieten. Dabei ist nicht immer „mehr“ die Lösung, sondern manchmal sogar ein Problem. Je mehr Features das Produkt umfasst, umso mehr Arbeit muss in Bugfixing und Wartung fließen. Und genau hier setzt der Gedanke an, sich mehr auf Outcome statt Output zu konzentrieren.


Product Owner Days 2026

Product Owner Days 2026

(Bild: deagreez/123rf.com)

Konferenz in Köln: Die Product Owner Days am 5. und 6. Mai 2026 befassen sich in über 20 Talks mit aktuellen Themen rund um Product Ownership, KI-Einsatz, User Research und mehr. Der Autor dieses Artikels, Dominique Winter, hält einen Workshop zu Produktvisionen.

Wo liegt der Unterschied zwischen Output und Outcome? Output beschreibt, was produziert wird. Outcome ist das, was das Produzierte bewirkt. Jede Funktion, jede neue Dokumentation, jeder neue Test ist erst einmal nur Output. Je mehr ein Team davon liefert, desto „produktiver“ ist es. Dabei bleibt zunächst unklar, was sich durch den erzeugten Output verändert. Was wird sich für Nutzerinnen und Nutzer ändern?

Zum Beispiel hat ein Onlineshop mit häufig wiederkehrenden Einkäufen (etwa für den Wocheneinkauf oder die Bestellung bei der Lieblingspizzeria) eine Funktion, die User beim Einkauf daran erinnern soll, dass sie ein oft gekauftes Produkt diesmal vergessen haben (zum Beispiel „Du nimmst normalerweise Pizzabrötchen dazu. Hast du sie vielleicht vergessen?“). Das Feature für diese Erinnerung ist erst einmal nur der Output. Wenn Kundinnen und Kunden das Feature aber nutzen und es dafür sorgt, dass sie mehr einkaufen, ist das der Outcome. In anderen Kontexten kann das dann auch eine schnellere Einarbeitung, glücklichere Kunden oder Ähnliches bedeuten. Outcome ist aber am Ende immer die Antwort auf die Frage, was sich durch den Output verbessern soll.


Vom Feature zum Ergebnis: Output entfaltet erst dann Wert, wenn Nutzung und Verhaltensänderung spürbar in Outcome übergehen.

Vom Feature zum Ergebnis: Output entfaltet erst dann Wert, wenn Nutzung und Verhaltensänderung spürbar in Outcome übergehen.

Vom Feature zum Ergebnis: Output entfaltet erst dann Wert, wenn Nutzung und Verhaltensänderung spürbar in Outcome übergehen.

Das Konzept von Outcome und Output bei einem komplexen Produkt lässt sich gut am Beispiel des Essens für eine Feierlichkeit verdeutlichen. Jedes einzelne Gericht, jeder Dip, jede Soße und jede Beilage ist Output. Misst man den Erfolg der eigenen Arbeit an Output, so geht es in erster Linie darum, dass möglichst viel Essen auf dem Tisch steht. Geht es aber um Outcome, dann sind die Freude beim Essen, das Lächeln der Gäste und das Genießen des Essens von Bedeutung. Man geht demnach anders an die Arbeit, wenn man sich andere Fragen stellt. Braucht es möglichst viel Essen oder geht es darum, die Personen kulinarisch zufrieden zu stellen? Geht es um schlichte Sättigung oder um Begeisterung beim Essen? Bezogen auf Software: Nutzerinnen und Nutzer freuen sich nicht über zusätzliche Features an sich. Vielmehr freuen sie sich darüber, wenn sie ein Problem einfacher lösen, eine Arbeit schneller durchführen oder eine Funktion leichter bedienen können.

Weiterlesen nach der Anzeige

Output-Orientierung lässt sich in vielen Produktteams beobachten. Sie streben dann oft danach, die Arbeitszeit von Entwicklerinnen und Entwicklern maximal auszulasten. Eine hohe Anzahl an Arbeitsergebnissen erzeugt das Gefühl von Produktivität. Langfristig führt das aber nicht nur zu Produkten mit begrenzter Wirkung, sondern auch zu Frustration im Team. Gerade Developer erleben häufig, dass sie technisch anspruchsvolle Lösungen umsetzen, ohne zu wissen, ob diese überhaupt sinnvoll sind.

Jetzt kann man es sich relativ einfach machen. Die Entscheidung, was gebaut wird, liegt häufig beim Produktmanagement oder der Konzeption. Als Entwicklerin oder Entwickler muss man „nur noch“ die Anforderungen umsetzen beziehungsweise in Code konvertieren. Dieses Übersetzen setzt jedoch einiges an Expertise voraus, denn gute Software zu bauen ist alles andere als trivial. Aber sich auf die Umsetzung von Features zurückzuziehen, entbindet Entwickler nicht von der Verantwortung, sich um die eigene Wirksamkeit zu kümmern. Sich nur als Umsetzende zu sehen, ist zu kurz gedacht, denn gerade Entwicklerinnen und Entwickler sitzen an zentraler Stelle. Sie übersetzen Ideen in Realität, treffen dabei aber wichtige Architekturentscheidungen und kennen die technischen Möglichkeiten und Grenzen am besten. Wenn sie in diesem Prozess Fragen zum angestrebten Outcome stellen, hilft Ihr Wissen dabei, gute Lösungen zu finden, statt nur Anforderungen umzusetzen.

Developer müssen aber nun keine neuen Rollen übernehmen. Häufig hilft es schon, an den richtigen Punkten die richtigen Fragen zu stellen (siehe Textkasten). Insbesondere in Terminen, in denen es um Anforderungen geht, entstehen oft wertvolle Diskussionen und somit auch Gelegenheiten, den Grund (den gewünschten Outcome) eines Features zu erfragen und durch das Gespräch gegebenenfalls den Fokus der Entwicklung zu verschieben. Warum soll das jeweilige Feature gebaut werden? Warum benötigen die User das Feature? Woran erkennt man hinterher, dass es sich gelohnt hat, das Feature zu entwickeln?

Natürlich ist es für diejenigen, die die Anforderungen stellen, einfacher, direkt eine bestimmte Funktion zu bestellen. Aber es ist überraschend, wie oft sich auch diese Menschen noch nicht so richtig Gedanken dazu gemacht haben, warum die Welt dieses Feature benötigt und welche Wirkung es eigentlich genau erzielen soll.

Fragen wie diese verändern Gespräche spürbar:

  • Woran erkennen wir am Ende, dass das, was wir bauen, wertvoll ist?
  • Welches Verhalten der Nutzerinnen und Nutzer soll sich dadurch verändern?
  • Welches Problem wird damit besser gelöst?
  • Was passiert in der Erlebniswelt der Nutzerinnen und Nutzer, wenn wir dieses Feature nicht bauen?
  • Was wäre die kleinste Lösung, die bereits Wirkung entfaltet?

Sicherlich sollte jemand aus dem Produktmanagement oder anderen Bereichen die obigen Fragen beantworten können, aber zwei wichtige Aspekte darf man dabei nicht vergessen. Zum einen arbeiten auch dort nur Menschen. Vielleicht finden sie die Idee für das Feature einfach spannend oder haben einfach Lust darauf, es im Produkt zu sehen. Welche Wirkung es bei den Usern auslöst, wurde vielleicht nicht bedacht. Zum anderen passiert es jeder und jedem hin und wieder einmal, dass man sich sehr in einer Lösungsidee verfängt und aus den Augen verliert, dass die gleiche Wirkung auch auf einem anderen Weg erreichbar wäre.

Entwicklerinnen und Entwickler haben als vollwertige Teammitglieder auch die Aufgabe, dafür zu sorgen, die richtigen Dinge zu tun. Manche Teammitglieder wollen aber nicht als Widerstand empfunden werden. Vor allem wer noch nicht viel Arbeitserfahrung hat, stellt mitunter die eigene Perspektive hinten an und geht davon aus, dass der Rest schon wissen wird, warum es sinnvoll ist, das Feature zu bauen. Aber Fragen bremsen nicht, sie schärfen. Sie helfen Teams, bewusster Entscheidungen zu treffen.

Eine verstärkte Outcome-Orientierung darf aber nicht vom Engagement einzelner Teammitglieder abhängen. Sie muss vielmehr Teil der Arbeitsroutine werden, und auch dazu gibt es wirksame Hebel. Einige Produktteams nutzen beispielsweise eine Definition of Ready (DoR), die beschreibt, welche Eigenschaften erfüllt sein müssen, damit eine Anforderung umgesetzt werden kann. Eine DoR kann dann unter anderem aufführen, dass bestimmte Fragen zum angestrebten Outcome beantwortet sein müssen. Zu diesen Fragen gehören beispielsweise die im Textkasten genannten. Durch die Einbindung solcher Fragen in die DoR müssen einzelne Entwicklerinnen und Entwickler nicht mehr jedes Mal nachfragen und gefühlt stören, sondern ein Team verpflichtet sich als Ganzes dazu, die Fragen abzuarbeiten. Wenn beim Überprüfen der DoR unklar ist, wofür eine Anforderung umgesetzt werden soll oder woran Erfolg erkennbar sein soll, ist es sinnvoll, die Umsetzung zu verschieben und erst einmal das angestrebte Ziel oder die angestrebte Wirkung zu klären.



Source link

Entwicklung & Code

C++-Entwickler nutzen KI häufiger, bleiben aber skeptisch


C++-Programmiererinnen und -Programmierer setzen immer häufiger KI-Assistenten für ihre Projekte ein. Das hat die Standard C++ Foundation in ihrer jüngsten Umfrage festgestellt. Deutlich wurde aber auch: Das Misstrauen gegenüber künstlicher Intelligenz ist immer noch hoch.

Weiterlesen nach der Anzeige

Als Grund dafür geben 77,5 Prozent der Befragten an, dass KI fehlerhaften Output liefert, während knapp 70 Prozent den von künstlicher Intelligenz generierten Antworten generell kein Vertrauen entgegenbringen. Für rund 51 Prozent der Teilnehmenden leistet KI hinsichtlich Kontextverständnis zu wenig. Bedenken bezüglich Datensicherheit melden 49,5 Prozent an und für 37,4 Prozent ist der Einsatz von KI vor allem eine Kostenfrage.

Dennoch werden KI-Assistenten im C++-Umfeld deutlich häufiger eingesetzt als letztes Jahr, auch wenn in sämtlichen von der Umfrage berücksichtigten Programmier-Aufgabenbereichen weiterhin die „Nein“-Sager dominieren.


Umfrage: Der Einsatz von KI im C++-Programmierumfeld

Umfrage: Der Einsatz von KI im C++-Programmierumfeld

Die meisten Umfrage-Teilnehmer sprechen sich gegen den Einsatz von KI im C++-Umfeld aus.

(Bild: Standard C++ Foundation)

Beim Schreiben von Code greifen nun jedoch 39,1 Prozent der Befragten ein- bis mehrmals pro Woche zum KI-Tool, während es 2025 noch 30,9 Prozent waren. Beim Schreiben von Tests sind es 32,2 statt vormals 20 Prozent, beim Debugging steigt der Anteil auf 23,2 Prozent (2025: 11,5 %) und beim Ermitteln von Performance-Problemen hat sich der Anteil mit etwa 14 Prozent ebenfalls mehr als verdoppelt (2025: 6,0 %).

Mit 53,4 Prozent der Nennungen landet GitHub Copilot auf Platz eins der am häufigsten verwendeten codespezifischen KI-Assistenten. Es folgen Claude Code mit 44,2 Prozent und OpenAI Codex mit 14,3 Prozent. Unter den nicht-codespezifischen KI-Tools führen ChatGPT mit 53,4 Prozent und Google Gemini mit 39 Prozent. Kaum genutzt werden dort Grok (6,3 %) und Perplexity (4,2 %).

Weiterlesen nach der Anzeige

Laut Umfrage ordnen sich die meisten C++-Projekte den Kategorien Entwicklertools (26,1 %), Hardware/IoT (24,7 %), Gaming (23,5 %) sowie Utility-Apps (21,6 %) zu. Umgesetzt werden sie überwiegend mit CMake, das 81,9 Prozent der Befragten als bevorzugtes Build-Tool nennen. Ebenfalls hoch im Kurs stehen Ninja mit 46,2 Prozent, MSBuild mit 33,5 Prozent und Make/nmake mit 30,7 Prozent.

Bei den IDEs greifen rund 40 Prozent der Befragten zu Visual Studio Code, das mit dem Februar-Update neue Features für die KI-Agenten-Konfiguration erhielt. Als Compiler kommt überwiegend GCC zum Einsatz (53,1 %).

Danach gefragt, was sie an C++ ändern würden, nennen viele Teilnehmer unter anderem ein standardisiertes Paket- und Abhängigkeitsmanagement, kürzere Build-Zeiten, die Unterstützung von ABI- und Kompatibilitätsbrüchen sowie mehr Sicherheit durch strengere Defaults.

Die Umfrage der Standard C++ Foundation startete am 21. April dieses Jahres. Sie lief eine Woche lang und sammelte Feedback von 1434 Teilnehmerinnen und Teilnehmern, was einem Anstieg von 38 Prozent gegenüber 2025 entspricht (1036 Personen). Davon attestieren sich 80,6 Prozent eine C++-Programmiererfahrung von mindestens sechs Jahren. Mehr als zehn Jahre Erfahrung geben 60,5 Prozent an und bei fast 33 Prozent der Teilnehmer sind es mehr als 20 Jahre. Auf der Webseite der gemeinnützigen Stiftung steht die vollständige Umfrage mit vielen weiteren Details zum Download bereit.


(mro)



Source link

Weiterlesen

Entwicklung & Code

OpenAI: Neue Audio-Modelle für Echtzeit-KI-Support


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Künstliche Intelligenz wird in Zukunft immer häufiger am anderen Ende der Leitung sein, wenn Menschen eine Supporthotline anrufen oder in einer App Unterstützung suchen. Mit drei neuen Audio-Modellen, die per Entwicklerschnittstelle (API) zur Verfügung stehen, will OpenAI jetzt deren Qualität auf eine neue Stufe stellen. Konkret hat das US-amerikanische KI-Unternehmen die Modelle GPT-Realtime-2, GPT-Realtime-Translate und GPT-Realtime-Whisper vorgestellt.

Weiterlesen nach der Anzeige

Wie die Namen schon erahnen lassen, geht es um einen Dreiklang an Funktionen: GPT-Realtime-2 soll Echtzeit-Gespräche zwischen Maschine und Mensch ermöglichen, GPT-Realtime-Translate kommt in der Mensch-zu-Mensch-Kommunikation als Übersetzer und GPT-Realtime-Whisper zur Transkribierung von Mensch zu Maschine zum Einsatz. GPT-Realtime-2 ist überdies das erste Sprachmodell mit GPT-5-Reasoning in Echtzeit. OpenAI hat zuletzt auch GPT-5.5 als agentisches Arbeitsmodell vorgestellt, das Aufgaben selbstständig planen und über längere Zeiträume konsistent bearbeiten soll.

In Praxisvideos zur Ankündigung zeigt OpenAI die Modelle im Einsatz. Ein Augenmerk liegt darauf, dass sich die KI besser in die menschliche Kommunikation einfügt. Da ist zum Beispiel eine Situation, wo jemand ein Mensch-KI-Gespräch unterbricht und die KI angewiesen wird, für den Moment abzuwarten. Auch die Rückmeldungen der KI kommen menschlicher daher: sei es, wie Zahlen- und Buchstabenfolgen ausgesprochen werden oder bei der Live-Übersetzung, dass die KI jeweils abwartet, bis sie genug gehört hat, um sinnhaft übersetzen zu können. Zudem sollen Probleme besser kommuniziert werden, anstatt die Kommunikation einfach stillschweigend scheitern zu lassen.

Das Kontextfenster von GPT-Realtime-2 wurde gegenüber dem Vorgängermodell GPT-Realtime-1.5 von 32.000 auf 128.000 Token erweitert. Reasoning-Stufen sind einstellbar: von minimal bis sehr hoch, im Standard ist es auf niedrig eingestellt. Auch sind parallele Aufrufe von Tools möglich, sodass das Modell im laufenden Gespräch parallel mehrere externe Dienste abfragen kann. OpenAI wirbt zudem mit einem deutlich besseren Abschneiden bei Benchmarks, etwa bei Big Bench Audio von 81,4 auf 96,6 Prozent im Vergleich zu GPT-Realtime-1.5. Beim allgemeinen Release der Realtime API im vergangenen Jahr hatte das Vorgängermodell diesen Benchmark gegenüber der Beta-Version bereits von rund 65 auf über 82 Prozent verbessert.

GPT-Realtime-Translate unterstützt über 70 Eingangssprachen und kann in 13 Sprachen übersetzen. Die Deutsche Telekom testet das Modell laut OpenAI bereits, um es im mehrsprachigen Kundensupport einzusetzen. Die Kosten für Entwickler betragen 0,034 US-Dollar pro Minute Nutzung.

Weiterlesen nach der Anzeige

GPT-Realtime-Whisper soll Live-Transkription mit sehr niedriger Latenz ermöglichen. Typische Einsatzbereiche sind Untertitel in Meetings oder bei Streams, Kundensupport, medizinische Anwendungen und der Handel. Die Kosten betragen 0,017 US-Dollar pro Minute.

Alle drei Modelle stehen ab sofort über die Realtime API zur Verfügung. Die neuen Modelle reihen sich in OpenAIs jüngste Strategie spezialisierter KI-Modelle ein: Neben der Sprachverarbeitung hat das Unternehmen zuletzt auch GPT-Rosalind für die Biologieforschung vorgestellt, das auf Wirkstoffentdeckung und Genomik zugeschnitten ist. Die Nutzung von GPT-Realtime-2 kostet für den Input 32 US-Dollar pro Million Token (0,40 US-Dollar für gecachte Token) sowie 64 US-Dollar pro Million Token im Output. Damit bleiben die Preise gegenüber dem Vorgängermodell unverändert. Für europäische Entwickler relevant: Die Realtime API unterstützt EU Data Residency, sodass Anfragen und Antworten in der EU verarbeitet und nicht auf OpenAIs Servern gespeichert werden – allerdings mit einem Vorbehalt: Das Tracing, also die Nachverfolgung von API-Aufrufen zu Debugging-Zwecken, ist derzeit noch nicht EU-Data-Residency-konform.


(mki)



Source link

Weiterlesen

Entwicklung & Code

Atlassian: KI-Agenten übernehmen die Routinearbeit


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Atlassian hat auf seiner Hauskonferenz Team ’26 mehrere neue Funktionen vorgestellt, die KI-Agenten stärker in die tägliche Zusammenarbeit von Anwendern einbinden sollen. Im Mittelpunkt stehen der Ausbau des Teamwork Graph als unternehmensweite Kontextschicht sowie die Weiterentwicklung der KI-Plattform Rovo. Deren Agenten sollen Aufgaben künftig nicht nur unterstützen, sondern eigenständig planen und ausführen.

Weiterlesen nach der Anzeige

Atlassian entwickelt Werkzeuge für Zusammenarbeit und Softwareentwicklung. Hierzu zählen Jira, Confluence und Loom. Alle diese Tools sollen Aufgaben, Wissen und Kommunikation in Teams zusammenführen.

Eine zentrale Rolle spielt der Teamwork Graph. Er bildet Beziehungen zwischen Aufgaben, Dokumenten, Personen und Systemen ab und liefert KI-Agenten den nötigen Kontext. Neu ist, dass dieser Kontext nicht mehr nur innerhalb der Atlassian-Produkte zur Verfügung steht. Über ein neues Kommandozeilentool – das sich aktuell in einer Open Beta befindet – greifen Entwickler direkt im Terminal auf den Graph zu. Zusätzlich stellt Atlassian Schnittstellen über das Model Context Protocol (MCP) bereit, sodass auch externe Agenten und Copiloten die Daten nutzen können. KI-Systeme können damit Zusammenhänge wie Verantwortlichkeiten, Abhängigkeiten oder frühere Entscheidungen einbeziehen, statt isolierte Abfragen zu beantworten. Ein Agent kann so zum Beispiel ermitteln, welche Incidents mit einem bestimmten Deployment zusammenhängen und wer für deren Behebung zuständig ist.

Parallel baut Atlassian Rovo – ein KI-gestütztes Such- und Wissensermittlungstool – aus und entwickelt es von einem reinen Assistenzwerkzeug zu einem Tool für agentisches Arbeiten weiter. KI-Agenten sollen komplexe, mehrstufige Aufgaben eigenständig zerlegen, planen und ausführen. Der bereits angekündigte Reasoning-Modus „Max“ in Rovo Chat soll künftig solche Abläufe über mehrere Werkzeuge hinweg orchestrieren. Ein Beispiel für den Praxiseinsatz wäre ein Quartalsbericht, für den ein Agent Daten aus verschiedenen Quellen zusammenführt, aufbereitet und fehlende Informationen kennzeichnet.

KI-Agenten rücken zudem näher an bestehende Arbeitsabläufe. In Jira lassen sich Aufgaben nun gezielt an Agenten zuweisen (genannt Agents in Jira, bereits allgemein verfügbar), die diese eigenständig bearbeiten oder vorbereiten. In Confluence überführt die Funktion Remix Inhalte in andere Formate wie Präsentationen oder Diagramme, ohne dass Anwender die Umgebung verlassen müssen. Loom wandelt Videoanleitungen in strukturierte Aufgaben um, die sich beispielsweise als Jira-Tickets weiterverarbeiten lassen. Punktuelle KI-Abfragen sollen damit einer dauerhaft eingebetteten Automatisierung weichen.

Mit Rovo Studio bietet Atlassian zudem eine No-Code-Plattform, auf der Anwender eigene Agenten, Automatisierungen und Anwendungen erstellen. Sie setzt auf dem Teamwork Graph auf und richtet sich ausdrücklich nicht nur an Entwickler. Workflows lassen sich ereignisbasiert definieren und mit Funktionen wie Rollenmodellen, Freigaben und Versionierung absichern. Ein Beispiel wäre ein Onboarding-Prozess, bei dem ein Agent automatisch Konten anlegt, Dokumente bereitstellt und Aufgaben verteilt, sobald ein neuer Mitarbeiter im System erfasst ist.

Weiterlesen nach der Anzeige

Speziell für Softwareentwickler erweitert Atlassian sein Angebot im Bereich Developer Experience (DX). Neue Funktionen wie „Agent Experience“, „AI Code Insights“ und „AI Pulse“ sollen Transparenz über den KI-Einsatz im Entwicklungsprozess schaffen. Damit lässt sich nachvollziehen, welcher Anteil des Codes von KI stammt, wie Agenten in Workflows eingebunden sind und wie sich das auf Produktivität und Qualität auswirkt.

Mit der Product Collection kündigt Atlassian außerdem eine neue Produktreihe für das Produktmanagement an. Sie erweitert bestehende Werkzeuge wie Jira Product Discovery und soll den gesamten Prozess von der Sammlung von Kundenfeedback über die Priorisierung bis zur Umsetzung und Erfolgsmessung abdecken.

Neu sind zudem die Dia Reports, wobei es sich um browserbasierte Briefings handelt, die Informationen aus dem Teamwork Graph mit Daten aus typischen Arbeitswerkzeugen wie Kalendern oder Kommunikationsplattformen verbinden. So entstehen etwa automatisch generierte Tageszusammenfassungen, die offene Aufgaben, relevante Diskussionen und anstehende Termine bündeln.

Mehr Details zu allen neuen Funktionen finden sich im Atlassian-Blog.

Lesen Sie auch


(fo)



Source link

Weiterlesen

Beliebt