Artikelbild - Frau hält Cheat Sheet als Poster in die Kamera

Planning Poker Regeln auf einer Seite erklärt [PDF]

3 Antworten

Die Planning Poker Regeln sind einfach. Planning Poker ist eine spielerische, aber durchaus ernstgemeinte Methode Aufwände in agilen Teams zu schätzen. Wir haben die Regeln mal zusammengefasst. Sechs einfache Phasen gibt es. Die Spielregln haben wir auf einer Seite zusammengefasst, zum Download. Auf einen Blick leicht verständlich. Daraus ist eine ganz nette Infografik, ein Cheat Sheet geworden, das sich gut im Team, bei der nächsten Remotesession teilen lässt. Auch ideal zum Ausdrucken und um es ins Office zu hängen.

Als Onlinetool für Planning Poker empfehlen wir das kostenfreie Agile Casino. Das online Planning Poker lässt sich ohne Registrierung in unbegrenzten Runden und mit mehr als 7 Spielern spielen.

Regeln für Schätzpoker

Schritt 1: Das Deck. Jeder Schätzer hält einen Stapel Planungspoker-Karten mit den Werten 0, 1, 2, 3, 5, 8, 13, 21 oder ? in der Hand, was der von uns empfohlenen Reihenfolge entspricht. Die Werte stehen für die Anzahl der Story Points, der idealen Tage oder anderer Einheiten, in denen das Team schätzt.

(Hier können natürlich andere Varianten bevorzugt werden. Zu erwähnen sind T-Shirtgrößen wie S, M, L, XL etc. oder „The Power of 2“, also 1, 2, 4, 16, etc.)

Schritt 2: Diskussion. Die Schätzer diskutieren ein Feature und stellen dem Product Owner bei Bedarf Fragen. Wenn die Funktion vollständig diskutiert wurde, wählt jeder Schätzer für sich eine Karte aus, die seine Schätzung darstellt.

Schritt 3: Aufdecken. Die Runde deckt alle Karten gleichzeitig auf.

Schritt 4: Fertig falls Konsens. Wenn alle Schätzer denselben Wert gewählt haben, wird dieser zum Schätzwert.

Schritt 5: Weiterdiskutieren. Wurde noch kein Konsens erzielt, diskutieren die Schätzer ihre Schätzungen. Insbesondere die Schätzer mit dem höchsten und dem niedrigsten Wert sollten ihre Gründe mitteilen. Nach einer weiteren Diskussion wählt jeder Schätzer erneut eine Schätzkarte aus und alle decken ihre Karten erneut gleichzeitig auf.

Schritt 6: Wiederholen: Der Prozess des Planning Poker wird so lange wiederholt, bis ein Konsens erreicht wurde. Ausnahme: Falls das Team zu der Einschätzung gelangt, über unzureichende Informationen zu Verfügen, kann es die Schätzung eines bestimmten Elements verschieben, bis zusätzliche Informationen vorliegen.

PDF zum kostenfreien Download

Kein Newsletterabo, keine Registrierung: Einfach so downloaden. Es wäre schön, wenn ihr das kostenfreie Scrum-Poker-Tool Agile Casino mal ausprobiert. Es gibt eine deutsche und eine englische Version. Schreibt gerne in die Kommentare, was ihr dazu denkt.

Vorschau Cheat Sheet Planning Poker
Vorschau des Cheat Sheets
scrum-poker-planning-infographic-cheat-sheet.pdf Download [EN-Version]
DE-scrum-poker-planning-infografik-cheat-sheet.pdf Download [DE-Version]

Artikelbild: Frau SRE-DevOps-Expertin angestrahlt mit Code

SRE oder DevOps: Rivalen oder Alliierte?

Schreibe eine Antwort

Die immer schneller werdende Geschäftswelt ist schon seit geraumer Zeit von dem Wort „Agilität“ besessen, wenn es um die Entwicklung von IT-Produkten geht. Und es ist nicht schwer zu verstehen, warum: Die Aussicht, die lang ersehnte Lösung zur Behebung von Problemen so schnell wie möglich zu erhalten, ist und bleibt verlockend.

Die COVID-19-Pandemie hat jedoch gezeigt, dass es nicht mehr ausreicht, einfach nur agil zu sein: Aus dem Transposit-Bericht geht hervor, dass die MTTR (mittlere Reparaturzeit) gestiegen ist (93,6 %), seit die Welt gezwungen ist, ein Remote-Arbeitsmodell einzuführen, wobei die Ausfallzeiten sogar um 68,4 % gestiegen sind!

Wie kann man nun sicherstellen, dass die Agilität nicht länger die Zuverlässigkeit beeinträchtigt? Das sind DevOps und Site Reliability Engineering (SRE). Diese Konzepte gibt es schon seit geraumer Zeit, und angesichts der Herausforderungen, die sich insbesondere im Zuge der Pandemie stellen, sind sie aktueller denn je.

DevOps und SRE wurden in den frühen 2000er Jahren entwickelt, um ein Gleichgewicht zwischen Entwicklungsagilität und Systemstabilität zu finden. Die Begriffe werden jedoch oft falsch verwendet: Manche denken, es handele sich um dasselbe, andere halten sie für konkurrierende Ideen. Die meisten glauben, dass sich ein Unternehmen immer zwischen beiden entscheiden muss. Gehen wir also der Frage auf den Grund, was DevOps und SRE sind und ob eine Debatte zwischen DevOps und SRE überhaupt Sinn macht.

DevOps ist im Kern eine Methodik, die Silos zwischen Entwicklungs-, Test-, Qualitätssicherungs- und Betriebsteams abbaut, um die Anwendungsentwicklung zu beschleunigen, die Softwarequalität zu verbessern, die Verfügbarkeit der Infrastruktur zu erhöhen, die Anwendungsleistung zu maximieren und die Kosten zu senken. All das klingt großartig. Allerdings gibt es ein Problem. DevOps ist im Grunde eine Reihe von abstrakten Prinzipien, von denen viele Unternehmen Schwierigkeiten haben, sie in die Praxis umzusetzen. Um diesen Kampf zu beenden, hat Google 2016 ein Buch mit dem Titel „Site Reliability Engineering“ veröffentlicht, das die internen DevOps-Praktiken beleuchtet, aber vor allem leicht verständliche praktische Ratschläge gibt, wie DevOps funktioniert.

Kurz gesagt: DevOps ist eine Philosophie, und SRE ist eine gute Möglichkeit, diese Philosophie umzusetzen.
Wie trägt SRE zur DevOps-Methodik bei?

Wenn Sie sich das DevOps-Manifest ansehen, werden Sie wahrscheinlich feststellen, dass es 5 Schlüsselkategorien gibt, in die DevOps unterteilt ist, die Mantras der Methodik, wenn Sie so wollen:

  • Beseitigung organisatorischer Silos
  • Akzeptieren von Fehlern als normal
  • Kleine inkrementelle Änderungen einführen
  • Nutzen von Werkzeugen und Automatisierung
  • Alles messen

All diese Punkte sind zweifellos für den Erfolg eines Teams bei der Suche nach einem ausgewogenen Verhältnis zwischen Agilität und Zuverlässigkeit von entscheidender Bedeutung, und wir werden gleich herausfinden, warum. Aber so schön sie auch klingen, sie sehen nicht wie konkrete Anweisungen aus („Alles messen“? Natürlich!). Gehen wir also diese Grundsätze nacheinander durch und sehen wir, wo der Unterschied zwischen DevOps und SRE wirklich liegt.
DevOps-Ideen und SRE-Implementierung
Aufhebung der organisatorischen Silos

DevOps-Idee: Die Kommunikation zwischen den Personen, die für die Programmierung zuständig sind (Entwickler), und den Personen, die die Wartungsdienste erbringen (Betreiber), muss nahtlos sein, um zu verhindern, dass schnelle Änderungen am Code die Infrastruktur beschädigen und die Stabilität des Systems ernsthaft gefährden. Ursprünglich sollte DevOps die Mauer zwischen Entwicklungs- und Betriebsteams durchbrechen, hat sich aber schnell über die Softwarebereitstellungspipeline hinaus auf Bereiche wie Sicherheit, Finanzen, HR, Marketing, Vertrieb usw. ausgebreitet, in denen eine Zusammenarbeit unerlässlich ist.

SRE-Implementierung: Sie müssen ein engmaschiges, funktionsübergreifendes Team aufbauen, indem Sie nicht nur Entwickler und Operatoren zusammenbringen, sondern auch synergiefördernde Praktiken auf die Bereiche Finanzen, Personalwesen, Führungsteams usw. ausweiten. Die Kultur der besseren Kommunikation und des Wissensaustauschs, die DevOps und SRE von Natur aus erfordern, kann durch häufige Stand-ups geschaffen werden, während Integration und Automatisierung mit speziellen Toolsets umgesetzt werden sollten.
Scheitern als normal akzeptieren

DevOps-Gedanke: Kein von Menschen geschaffenes System kann zu 100 % zuverlässig sein, daher sollte ein Ausfall des besagten Systems von keinem Unternehmen als Katastrophe empfunden werden, sondern als Normalität behandelt werden… solange daraus eine Lehre gezogen wird.

SRE-Implementierung: Sie müssen sich intern darauf einigen, wie viel Ausfallzeit unter den gegebenen Umständen akzeptabel ist, und darauf vorbereitet sein, Systemausfälle schnell zu bewältigen (da sie unvermeidlich sind und nicht überraschend kommen sollten); eine Möglichkeit, dies zu tun, ist die Durchführung so genannter „schuldloser Post-Mortems“, bei denen keine Zeit damit verschwendet wird, die Schuldigen für den Ausfall zu suchen. Stattdessen sucht das Team routinemäßig nach Möglichkeiten zur Verbesserung des Systems und konzentriert sich dabei auf die Zukunft, nicht auf die Vergangenheit.

DevOps-Idee: Häufige, aber kleine Änderungen am Code helfen, schneller auf Probleme zu reagieren und Fehler einfacher zu beheben. Und warum? Das ist ganz einfach. Die Suche nach einem Fehler in 100 Codezeilen ist viel einfacher als in 100.000 Codezeilen. Außerdem ist der Entwicklungsprozess dadurch generell viel flexibler und kann auf plötzliche Änderungen reagieren.

SRE-Implementierung: Sie müssen beachten, dass es nicht auf die tatsächliche Anzahl der Deployments pro Tag ankommt. Das Streben nach einer übermäßigen Anzahl von Deployments nur um der Deployments willen ist vergebliche Mühe. Sie sollten in der Tat häufig deployen, aber auch dafür sorgen, dass diese Deployments sinnvoll sind – je sinnvoller die Art des Deployments ist, desto einfacher ist es, einen potenziellen Fehler zu beheben, und desto geringer sind die Kosten für Fehlschläge.
Von Tools und Automatisierung profitieren

Die DevOps-Idee: Es liegt in der menschlichen Natur, dass wir monotone Aufgaben nicht effizient ausführen können. Genauso wie es viel Zeit und Energie kostet, wichtige Arbeitsabläufe manuell zu erledigen, können Unternehmen, die Tools und Automatisierung nutzen, diese Prozesse exponentiell verbessern.

SRE-Implementierung: Sie sollten sich überlegen, welche langfristigen Verbesserungen am System vorgenommen werden müssen, und die Aufgaben automatisieren, die in einem Jahr oder in ein paar Jahren regelmäßig anfallen werden (SRE nennt dies „die Arbeit von diesem Jahr weg automatisieren“). Auf diese Weise vermeiden Sie Investitionen in kurzfristige Gewinne und konzentrieren sich auf die langfristige Automatisierung.

DevOps-Idee: Konkrete Metriken, die verschiedene Aspekte Ihres Entwicklungsprozesses messen, helfen nicht nur dabei, festzustellen, ob das Unternehmen erfolgreich an einem bestimmten Projekt arbeitet, sondern liefern auch eine Rechtfertigung für diese oder jene Geschäftsentscheidung.

SRE-Implementierung: Sie sollten Service-Level-Agreements (SLA), Service-Level-Ziele (SLO) und Service-Level-Indikatoren (SLI) verwenden, die mittlere Zeit zwischen zwei Ausfällen (MTBF) und die mittlere Wiederherstellungszeit (MTTR) des Systems verfolgen und ein Fehlerbudget festlegen. So können Sie Ihr Projekt wesentlich effizienter gestalten.

Wir werden in Kürze näher darauf eingehen, was einige der Begriffe im obigen Absatz tatsächlich bedeuten, aber der Rest des Bildes sollte inzwischen mehr als deutlich sein. DevOps wurde geschaffen, um die IT-Entwicklung besser zu machen. In der Zwischenzeit sollte SRE zeigen, WIE genau wir das tun sollten. Wie viele SRE-Spezialisten zu sagen pflegen, „SRE implementiert DevOps“.

SRE als Konzept ist ohne Service-Level Agreement (SLA), Service-Level Objective (SLO), Service-Level Indicator (SLI) kaum vorstellbar. Wie bereits erwähnt, handelt es sich hierbei um die zentralen Begriffe, die sich in vielerlei Hinsicht auf die Messung des Erfolgs Ihrer SRE-Implementierung beziehen. Und genau wie die Namen dieser Konzepte sind auch ihre Eigenschaften einander sehr ähnlich, allerdings mit einigen entscheidenden Unterschieden:

  • SLA wird als Vereinbarung zwischen dem Service Provider und dem Kunden über Kennzahlen wie Betriebszeit, Ausfallzeit, Reaktionsfähigkeit, Verantwortlichkeiten usw. bezeichnet. Mit anderen Worten, es handelt sich um eine Reihe von Versprechen an den Kunden, die durch verschiedene Messgrößen dargestellt werden, sowie um eine Reihe von Konsequenzen, wenn diese Versprechen nicht eingehalten werden;
  • SLO wird wiederum als Vereinbarung innerhalb eines SLA über eine bestimmte Kennzahl bezeichnet, z. B. Betriebszeit oder Antwortzeit. Im Grunde ist ein SLO ein individuelles Versprechen an den Kunden. In dieser Hinsicht kann man ein SLA also als eine bestimmte Gruppe von SLOs betrachten;
  • Der SLI schließlich ist ein Indikator, der anzeigt, ob das System in Übereinstimmung mit diesem oder jenem SLO funktioniert.

Ein typisches Beispiel für das Zusammenspiel dieser drei Begriffe wäre etwas in dieser Art: Ein SLA, das Sie mit Ihrem Kunden abgeschlossen haben, besagt, dass das System 99,9 % der Zeit verfügbar sein wird (die so genannten „drei Neunen der Verfügbarkeit“), es würde also die SLO enthalten, die 99,9 % Betriebszeit bedeuten würde, und die SLI wäre die tatsächliche Messung der Betriebszeit des Systems.
Welche Arten von Unternehmen brauchen SRE und DevOps?

In Anbetracht der Tatsache, dass DevOps und SRE dazu da sind, Entwicklungsteams bei der Sicherstellung einer hohen Systemstabilität zu unterstützen und gleichzeitig sehr agil zu sein, kann man relativ sicher sagen, dass jedes Entwicklungsunternehmen bis zu einem gewissen Grad wissen sollte, was DevOps/SRE-Techniken sind und wie man sie implementiert. Sie sind das A und O der modernen Softwareentwicklung.

In unseren früheren Beiträgen haben wir uns bereits mit den Vorteilen von DevOps für große Produktionsunternehmen und den massiven Auswirkungen auf die Finanzdienstleistungsriesen befasst, aber die Genialität von DevOps und SRE liegt in ihrer universellen Anwendbarkeit – Ihr Unternehmen muss KEIN Softwareentwicklungsunternehmen sein, um von diesen Praktiken zu profitieren; solange Sie mit Update-Rollouts, Infrastrukturänderungen, Wachstum und Upscaling zu tun haben, können Sie sich mit dieser Philosophie beschäftigen.

Und tatsächlich ist kein Team zu klein für DevOps/SRE. Wenn Sie ein kleines Unternehmen sind, brauchen Sie nicht einmal einen speziellen SRE-Spezialisten. In diesem Fall kann es sich lohnen, eines Ihrer Teammitglieder in der Anwendung der SRE-Methode zu schulen, da die Lernkurve nicht so hoch ist.

Wenn man all dies berücksichtigt, kann man leicht zu dem Schluss kommen, dass die Ideen und Konzepte hinter DevOps und SRE für jedes Unternehmen interessant sind – ob Großunternehmen oder kleines StartUp, ob IT oder Nicht-IT, sie sind für jeden geeignet.

Bei dem Versuch, die Debatte zwischen Site Reliability Engineering und DevOps zu klären, können wir nun mit Sicherheit sagen, dass es keinen Sinn hat, entweder oder zu sagen. Wie können wir hier überhaupt von einer Debatte sprechen, wenn die beiden Dinge, die wir verzweifelt versuchen, einander gegenüberzustellen, praktisch dasselbe sind, wobei das eine ein wesentlicher Bestandteil des anderen ist?

Wenn Sie sagen, dass Sie DevOps gut machen können, ist es wahrscheinlich, dass Sie das mit Hilfe von SRE-Prinzipien tun.

Wenn Sie sagen, dass Sie SRE gut machen können, sollten Sie wissen, dass wir technisch gesehen über DevOps sprechen.

Es handelt sich also keineswegs um ein „rote Pille-blaue Pille“-Szenario. Sowohl DevOps als auch SRE sind zu begrüßen, und wir sind sehr gespannt, wie sich beide in den kommenden Jahren entwickeln werden.

Interessieren Sie sich für SRE und DevOps? Sprechen Sie mit unseren DevOps – Experten, um herauszufinden, wie DevOps und SRE Ihnen helfen können, neue Geschäftsmöglichkeiten zu erschließen.

Artikeltext: Ein Schloss als Symbol für Passwortsicherheit

Warum das Passwort noch nicht ganz tot ist

Schreibe eine Antwort

BRINGEN SIE IHRE VERWANDTEN DAZU, IHRE PASSWÖRTER ZU ÄNDERN –
Jeder hasst die alten Methoden der Authentifizierung. Doch der Wandel bringt auch Nachteile mit sich.

Es gibt bestimmte Science-Fiction-Versprechen, die die Zukunft bereithalten soll: Jetpacks, fliegende Autos, eine Marskolonie. Aber es gibt auch einige scheinbar leichter zu erreichende Ziele, die sich irgendwie immer nur am Horizont abzeichnen. Und eines der verlockendsten ist das Ende der Passwörter. Die gute Nachricht ist, dass die Infrastruktur – für alle wichtigen Betriebssysteme und Browser – weitgehend vorhanden ist, um die passwortlose Anmeldung zu unterstützen. Die weniger gute Nachricht? Sie geben immer noch jeden Tag Passwörter für mehrere Websites und Dienste ein, und das wird auch noch eine Weile so bleiben.

Es besteht kein Zweifel daran, dass Passwörter ein absoluter Sicherheitsalbtraum sind. Das Erstellen und Verwalten von Passwörtern ist lästig, daher werden sie oft wiederverwendet oder leicht zu erratende Logins gewählt – oder beides. Hacker machen sich das nur zu gern zunutze. Im Gegensatz dazu erfolgt die Authentifizierung bei passwortlosen Anmeldungen anhand von Merkmalen, die angeboren und schwerer zu stehlen sind, z. B. biometrischen Merkmalen. Keiner wird Ihren Daumenabdruck erraten.

Wahrscheinlich verwenden Sie bereits eine Version davon, wenn Sie Ihr Telefon entsperren, z. B. mit einem Scan Ihres Gesichts oder Ihres Fingers anstelle eines Passcodes. Diese Mechanismen funktionieren lokal auf Ihrem Telefon und machen es nicht erforderlich, dass Unternehmen einen großen Bestand an Benutzerpasswörtern – oder Ihre sensiblen biometrischen Daten – auf einem Server speichern, um Anmeldungen zu überprüfen. In bestimmten Fällen können Sie jetzt auch eigenständige physische Token verwenden, um sich drahtlos und ohne Passwort anzumelden. Die Idee ist, dass man das irgendwann für so ziemlich alles machen kann.

„Alle Bausteine haben einen Reifegrad erreicht, der es ermöglicht, dass sie von technikbegeisterten Early Adopters zum Mainstream übergehen“, sagt Mark Risher, Senior Director of Product Management für Identitäts- und Sicherheitsplattformen bei Google. „Sie haben eine starke Plattformunterstützung, sie funktionieren bei allen großen Anbietern und sie werden den Nutzern immer vertrauter. Früher wussten wir als Branche nicht einmal, wie man Passwörter loswerden kann. Jetzt wird es einige Zeit dauern, aber wir wissen, wie wir es machen.“

Ende Juni kündigte Microsoft mit Windows 11 eine tiefere Integration der passwortlosen Anmeldung an, insbesondere für die Anmeldung bei Geräten, die biometrische Daten oder eine PIN verwenden. In ähnlicher Weise kündigte Apple einige Wochen zuvor an, dass seine neuen Betriebssysteme iOS 15 und macOS Monterey eine neue Option namens Passkeys in den iCloud-Schlüsselbund integrieren werden, ein Schritt in Richtung der Verwendung von biometrischen Daten oder Geräte-PINs zur Anmeldung bei mehr Diensten. Und im Mai sprach Google über seine Bemühungen, eine sichere Passwortverwaltung zu fördern, während es gleichzeitig daran arbeitet, die Kunden von Passwörtern wegzubringen.

Trotz dieser und anderer Bemühungen der Branche, sowohl Entwickler als auch Nutzer für eine Welt ohne Passwörter zu gewinnen, bleiben jedoch zwei große Herausforderungen bestehen. Zum einen werden Passwörter zwar allgemein verachtet, sind aber auch sehr vertraut und in absurder Weise allgegenwärtig. Es ist nicht einfach, jahrzehntelang gewachsene Gewohnheiten zu durchbrechen.

„Es ist ein erlerntes Verhalten – das erste, was man tut, ist ein Passwort einzurichten“, sagt Andrew Shikiar, Geschäftsführer der FIDO Alliance, eines langjährigen Branchenverbands, der sich speziell mit sicherer Authentifizierung beschäftigt. „Das Problem ist also, dass wir von einer wirklich schlechten Grundlage abhängig sind. Was wir tun müssen, ist, diese Abhängigkeit zu durchbrechen.

Es war eine schmerzhafte Entgiftung. Eine FIDO-Arbeitsgruppe hat sich im vergangenen Jahr mit der Benutzererfahrung befasst, um Empfehlungen nicht nur für die passwortlose Technologie selbst, sondern auch für die Art und Weise zu geben, wie sie normalen Menschen präsentiert werden kann, damit sie die Sicherheitsvorteile besser verstehen. Die FIDO sagt, dass Organisationen, die ihre Standards für passwortlose Systeme umsetzen, Schwierigkeiten haben, die Benutzer dazu zu bringen, die Funktion tatsächlich anzunehmen. Daher hat die Allianz Richtlinien für die Benutzererfahrung veröffentlicht, die ihrer Meinung nach bei der Gestaltung und Präsentation helfen werden. „‚Wenn du es baust, werden sie kommen‘ ist nicht immer ausreichend“, schrieb Shikiar letzten Monat.

Die zweite Hürde ist noch schwieriger. Selbst wenn all diese Elemente vorhanden sind, funktionieren viele passwortlose Systeme nur auf neueren Geräten und erfordern den Besitz eines Smartphones und mindestens eines weiteren Geräts. In der Praxis ist das ein ziemlich begrenzter Anwendungsfall. Viele Menschen auf der ganzen Welt teilen sich Geräte und können sie nicht häufig aufrüsten, oder sie verwenden, wenn überhaupt, nur Funktionstelefone.

Und während passwortlose Implementierungen zunehmend standardisiert werden, gilt dies nicht für Optionen zur Wiederherstellung von Konten. Wenn Sicherheitsfragen oder eine PIN als Backup-Optionen dienen, verwenden Sie im Grunde immer noch Passwörter, nur in einem anderen Format. Daher bewegen sich passwortlose Systeme hin zu Systemen, bei denen ein Gerät, das Sie zuvor authentifiziert haben, ein neues als vertrauenswürdig einstufen kann.

„Nehmen wir an, Sie lassen Ihr Telefon im Taxi liegen, haben aber noch Ihren Laptop zu Hause“, sagt Risher von Google. „Sie besorgen sich ein neues Telefon und verwenden den Laptop, um das Telefon zu segnen, und können sich so gewissermaßen wieder aufbauen. Und wenn dann jemand Ihr verlorenes Telefon findet, ist es immer noch durch die lokale Gerätesperre geschützt. Wir wollen das Passwortproblem nicht einfach auf die Kontowiederherstellung abwälzen.

Es ist sicherlich einfacher, als die Codes für die Wiederherstellung von Sicherungskopien auf einem Zettel zu notieren, aber auch hier stellt sich die Frage, welche Optionen für Personen geschaffen werden sollen, die nicht mehrere persönliche Geräte verwalten wollen oder können.

Da sich die passwortlose Nutzung immer mehr durchsetzt, bleiben diese praktischen Fragen über den Übergang bestehen. Der Passwort-Manager 1Password, der natürlich ein geschäftliches Interesse daran hat, dass Passwörter weiterhin verwendet werden, sagt, dass er die passwortlose Authentifizierung überall dort, wo sie sinnvoll ist, gerne unterstützt. Auf Apples iOS und macOS können Sie beispielsweise Ihren 1Password-Tresor mit TouchID oder FaceID entsperren, anstatt Ihr Hauptpasswort einzugeben.

Es gibt jedoch einige feine Unterschiede zwischen dem Master-Passwort, das einen Passwortmanager sperrt, und den darin gespeicherten Passwörtern. Die vielen Passwörter im Tresor werden alle zur Authentifizierung bei Servern verwendet, die ebenfalls eine Kopie des Passworts speichern. Das Master-Kennwort, das Ihren Tresor verschließt, ist allein Ihr Geheimnis; 1Password selbst kennt es nicht.

Diese Unterscheidung macht die passwortlose Anmeldung, zumindest in ihrer aktuellen Form, für einige Szenarien besser geeignet als für andere, sagt Akshay Bhargava, Chief Product Officer von 1Password. Er weist auch darauf hin, dass einige seit langem bestehende Bedenken gegenüber Passwortalternativen bestehen bleiben. Zum Beispiel sind biometrische Daten in vielerlei Hinsicht ideal für die Authentifizierung, da sie buchstäblich Ihre einzigartige physische Präsenz vermitteln. Die breite Verwendung biometrischer Daten wirft jedoch die Frage auf, was passiert, wenn Daten über beispielsweise Ihre Fingerabdrücke oder Ihr Gesicht gestohlen werden und von Angreifern manipuliert werden können, um sich als Sie auszugeben. Und während Sie Ihr Passwort aus einer Laune heraus ändern können – ihre beste Eigenschaft als Authentifikatoren – sind Ihr Gesicht, Ihr Finger, Ihre Stimme oder Ihr Herzschlag unveränderlich.

Es wird Zeit und weitere Experimente brauchen, um ein passwortloses Ökosystem zu schaffen, das alle Funktionen von Passwörtern ersetzen kann, vor allem eines, das die Milliarden von Menschen, die kein Smartphone oder mehrere Geräte besitzen, nicht zurücklässt. In einer passwortlosen Welt ist es schwieriger, Konten mit vertrauenswürdigen Personen zu teilen, und alles an ein Gerät wie das Telefon zu binden, schafft noch mehr Anreize für Hacker, dieses Gerät zu kompromittieren.

Bis zur vollständigen Abschaffung von Passwörtern sollten Sie immer noch die Ratschläge befolgen, die WIRED seit Jahren gibt: Verwenden Sie starke, eindeutige Passwörter, einen Passwortmanager (es gibt viele gute Optionen) und eine Zwei-Faktor-Authentifizierung, wo immer Sie können. Wenn Sie jedoch die Möglichkeit sehen, bei einigen Ihrer sensibelsten Konten auf Passwörter zu verzichten, wie z. B. bei der Einrichtung von Windows 11, sollten Sie es ausprobieren. Vielleicht spüren Sie eine Erleichterung, von der Sie nicht einmal wussten, dass es sie gibt.

Low-Level: Configure Angular-Apps on different environments [How-To]

Schreibe eine Antwort

Disclaimer for german readers: Dieser Artikel beschäftigt sich mit technischen Details. Falls sie auf der Suche nach Heigh-Level-Erklärungen sind, werden Sie in andern Artikeln eher fündig.

It shouldn’t take a rebuild to reconfigure an app for a certain environment. It should be build once and in each deployed state (test, nightly, demo, pre-prod, staging, prod, etc) have the configuration that applies on the server, respectivly environment.

The most common way to configure an app in a certain environment is by using environment variables. You can easily set them through .env files in Docker, Vagrant, AWS and other service providers.

To archive that, let’s start at the server side: A JavaScript-application runs on a webserver. It consists out of plain text files. While running on a client’s browser, there is now way for the JavaScript to access server values such as environment variables during runtime.

We need to inject the values, that life inside our server into the text files of our JavaScript application.

First, prepare a file called env.template.js with the environment variables you expect.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "${TITLE}"; 
})(this);

And again, there is no pre-existing mechanism. Here we can see, we prepare that file with placeholders ${XYZ} as strings. To inject the environment variables, that live on the server and thus can be differ from one environment to another.

To create a mechanism we need to run the following command on the server (this can be done during the deployment process to a certain environment, e.g. in an CI/CD-pipeline.

envsubst < /home/nonroot/htdocs/assets/env.template.js > /home/nonroot/htdocs/assets/env.js

What this does is, it takes all the environment variables, set to a certain value currently on the machine, and replaces all the placeholders ${XYZ} that match.

For example if there was an environment variable TITLE set to "This is a title", then any occurance of ${TITLE} inside the file would be replaced by „This is a title“ (without the quotes). After that the new resulting file is written into a new file, here 

/home/nonroot/htdocs/assets/env.js

The contents of the new file would look like the following snippet shows.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "This is a title"; 
})(this);

That is what we wanted to have. We had no pre-existing mechanism, that lets us access the environment variables on the server inside a certain environment. Now we have injected them very clean into our application.

We have them available, how to process them in our application?

There is nothing wrong with simply including the env.js file in our index.html, right into the header (of course you can export and import it, which would be slightly cleaner).

Now, if the environemnt variable TITLE was declared on the machine the scripts are running on, window['env']['title'] should hold the value, in our case "This is a title" as string. Globaly, everywhere in our application (maybe some kind of anti-pattern, you have the force. Seal it with dependency injection and so on) Easy?

Use the environment variable inside the environment files

The environment file in angular are a bit misleading. The implay, that you should have one file for each environment. I just look at environment.ts and environment.prod.ts. In the latter we can use our window[„env“] variable now.

export const environment = {
  production: true,
  title: window['env']['title'] || 'A default value for a title',
};

That’s it. Comment if you like.

Artikelbild - Freelancer auf dem Sofa bei der Arbeit

5 Freelancer aus der Hölle, die jeder Auftraggeber kennt

2 Antworten

Ich muss leider gliech für diesen eher negativen Artikel um Verzeihung bitten. In diesem Fall halte ich es für meine Pflicht über meine Erfahrungen aufzuklären. Ich kann damit nicht der Einzige sein. Üblicherweise schreibe ich über Dinge, die funktionieren.

Der Titel dieses Betrags ist übrigens angelehnt an den Artikel „7 Kunden aus der Hölle, die jeder Freelancer kennt„.

Seit etwa 2017 habe ich die finanziellen Möglichkeiten, Aufgaben an Mitarbeiter, Dienstleister und Freelancer zu delegieren. Niemals hätte ich bis dahin gedacht, dass es so schwer ist, die beauftragte Arbeitsleistung auch tatsächlich zu erhalten. Ich habe mit Agenturen, Dienstleistern und Freelancern zusammengearbeitet – die extrem arroganten und unrealistischen Vorstellungen erlegen sind.

Ich arbeite mit professionellen Freelancern, Softwareentwicklern zusammen, die ein hervorragenden Job gemacht haben (Robert Metz, Michael Deichen, Markus Gottschau, Alecsandru, Gabriel – hervorragende Leute, danke für eure Arbeit).

Es hat sich aus meiner Sicht ein neuer Typ Freelancer gebildet, der irgendwie der Illusion erlegen ist, dass er selbst entscheidt, welche Leistungen er bei einem Auftrag erbringen wird, der Arbeitgeber seinerseits jedoch die Pflicht hat, für welches Arbeitsergebnis auch immer die Rechnung zu bezahlen.

Oft pochen diese Freelancer darauf, nicht weisungsgebunden zu sein. Im Folgenden möchte ich kurz meine Erfahrungen mit Freelancern auf den diversen Portalen und Plattformen und in den entsprechenden Aufgabengebieten darstellen.

1. Recherchen in wissenschaftlicher Qualität

Das war der Beginn meiner Erfahrungen mit virtuellen Assistentinnen. Eine wortgewandte, intelligente Frau, die gerade in den letzten Zügen ihres Studiums lag, bot wissenschaftliche Recherchen an. Ich beauftragte eine Wettbewerbsanalyse. Was ich bekam war eine Liste von Internetadressen weniger Firmen, die mal mehr mal weniger etwas mit dem in Frage stehenden Geschäftszweck und Unternehmensstandort zu tun hatten. Zu dem Zeitpunkt hielt ich es noch für einen Einzelfall.

Ich glaube nicht, dass sie mich vorsätzlich betrügen wollte. Sie hatte nur völlig realitätsferne Vorstellungen: Als fast fertige Masterstudierende hatte Sie wohl die Vorstellung, andere Stundensätze, jenseits der 50€ (2017) zu verdienen und dachte sich, die Qualität durfte auch entsprechend sein. Außerdem bat sie zwar Recherchen in wissenschaftlicher Qualität an, unterschätzte allerdings, dass die Kategorie Wirtschaft ein eigene Spezialgebiet ist.

Aus meiner Sicht war es trotzdem Betrug, als sie sich entschied, ein Arbeitsergebnis dieser Güte abzugeben und eine Vergütung zu fordern.

2. Katja (Name geändert), meine virtuelle Assistenz

Erneut hatte ich mich auf das Versprechen „virtuelle Assistenz“ eingelassen. Diesmal benötigte ich jemanden, der mit Kunden kaufmännische Angelegenheit wie das Rechnungswesen klärt. Remote. Sie bei Köln oder Unterwegs beim Wellenreiten, ich in Hamburg. Ich halte viel davon, die Möglichkeiten der IT in der Arbetis welt zu nutzen. Jeder soll nach seiner Facon selig werden. Doch die Voruteile, die Viele zu dieser Art von Arbeit haben, sollte sich vollkommen bestätigen. Unzuverlässigkeit bis hin zum Anpöbeln unseres Kunden via E-Mail war das Einzige, vorauf ich mich verlassen konnte.

Sie war sogar bereits soweit in die Prozesse integriert, als sie das Vertragsverhältnis nach einigen Ermahnungen verließ, hatten wir arge Schwierigkeiten die Arbeit, die sie tat, aufzufangen. Sie war also von Nutzen. Gleichzeit hat sie Schaden verursacht. Das ist nicht die erwartbare Arbeitsmoral. Fehler können passieren, dennoch sollten angebotene Dienste bei Buchung auch die gestellten Anforderungen erfüllen.

3. Texter

Mit etlichen Textern habe ich zusammengearbeitet. 800 Wörter lange Artikel in einer Range von 100€ bis 500€. Ein Artikel, der mit wirklich brauchbar für diesen Blog hier erschien, war nicht dabei. Der Schreiber oder die Schreiberin war stets bemüht sozusagen. Auch da war es wieder: Die Vorstellung alle Arten an Themengebieten anbieten zu können, dann aber festzustellen (und nicht selten erst nach der Beauftragung), dass das Wissen nicht ausreicht. Dazu kommt die Uneinsichtigkeit. Ein klärendes Gespräch wäre okay mit der Ansage, für welche Themen der Freelancer ansonsten geeignet ist. Doch stattdessen wird der Artikel dennoch abgeliefert. Irgendwie.

4. Supertext

Die Plattform Supertext fand ich bis vor ein paar Wochen enorm interessant. Auf der Website des Anbieter findet man ein umfangreiches Userinterface, in dem Textart, Textlänge, Branche etc. definiert werden kann. Allerdings nur wieder theoretisch. Als ich mich anmeldete um den Dienst in Anspruch zu nehmen, musste ich erstmal durch ein persönliches Onboardinggespräch mit einer Mitarbeiterin. Es musste auch unbedingt via Telefon sein. Für mich führt das den Zweck einer solchen Dienstleistung ad absurdum. Denn muss ich jeden Artikel langwierig besprechen, kann ich ihn in der Zeit auch selbst schreiben.

5. Fiverr

Wer es nicht kennt: Fiverr ist ein Marktplatz, auf dem Freelancer Aufgabenpakete anbieten. Ursprünglich zu einem üblichen Preis von fünf Dollar. Daher der Name. Heute ist das anders, auf der Welt herrschen unterschiedliche Lohnniveaus – soviel ist klar.

Auf mich zumindest machte Fiverr zudem immer den Eindruck, man können Dienstleistungen in Pkateform dort einfach buchen. So einfach wie man einen Hotelaufenthalt bucht oder ein Produkt bei Amazon kauft. Doch das ist nicht so. Im Prinzip ist der „Kaufen“-Button auf den Angebotsseiten nutzlos. Bei rund 20 Aufträgen mit Fiverr habe ich bei 18 (ich habe es im Verlauf geprüft) die Reaktion bekommen, dass zuerst die Anfrage besprochen werden soll, bevor ein Auftrag. Egal ob deutscher, indischer, afrikanischer oder amerikanischer Verkäufer.

Also wieder das Gleiche wie bei Suprtext.

Mehrere Keywordanalysen und -recherchen wollte ich dort in Auftrag geben. Ich habe Worddokumente zugesendet bekommen, die mein gesamtes Geschäftsmodell, Konkurrentenseiten und Basiskeywords abgefragt haben und dennoch wurden meine Aufträge abgelehnt, aufgrund mangelnder Informationen.

Gegenargument zu ausführliche Briefings sind wichtig

Es gibt natürlich Situationen, in denen ausführliche Briefing für Auftragnehmer wichtig sind. Wenn ich eine Corporate Identity oder ein neues Webdesign beauftrage. Wenn ich die Unternehmensziele überdenke und den Jahresabschluss mache. Je ganzheitlicher eine Arbeit kontrolliert werden muss, desto detailierter muss das Briefing des Freelancers oder des Mitarbeiters ausfallen.

Genau deshalb sind diese Dinge nicht geeignet, um sie zu delegieren. Und wenn ein Entscheider der Meinung ist, er müsse bei der Beauftragung letztlich alle Keywords einer Keywordsrecherche selbst vorgeben, dann fällt auch eine Keywordrecherche in diesen Bereich. Der Grund dafür ist allerdings nicht die Beschaffenheit der Aufgabe, sondern der Kontrollbedarf des Auftragsgebers. So wird jede Aufgabe undelegierbar und das ist ein Anfängerfehler bei Gründern und Selbstständigen, frischen Chefs: Micromanagement.

Als Unternehmer will ich Aufgaben abgeben. Ich will nur die Details vorgeben, die kritisch sind. Ansonsten hat der Freelancer seinen Gestaltungspielraum. In allen Dimensionen, die nicht vorgegeben sind. Genau darum ging es dem Freelancer doch, oder nicht?

Viele Freelancer sind nicht reif für das Freelancertum (insbesondere die sogenannten virtuellen Assistentinnen): Sie suchen feste Vorgaben, wo sie Freiheit bekämen und wollen Freiheit, wo sie sich an Vorgaben halten sollten.

Erklärungsversuch

Das ist natürlich extreme Spekulation. Ich habe ein paar sinnvolle Erklärungsversuche. Das Buch von Timothy Ferris „Die 4-Stunden-Woche“ konnte ich nicht zuendelesen. Zu dreist die Idee, man müsse sich seine „Kunden erziehen“ und so ausdünnen, dass nur noch die übrigbleiben, die sozusagen stubenrein sind. Also möglichst wenig auf ihr Recht pochen.

Ich gebe Jessica Fichtel vom Blog bileico.com mit ihrem Artikel („7 Kunden aus der Hölle, die jeder Freelancer kennt„) natürlich recht. Doch ihre Punkte haben immer auch eine Rückseite. Sprich: „Können wir nochmal über den Preis sprechen?“ ist nicht das Problem – Wir müssen sogar über den Preis sprechen! Die Frage ist: Wie bemessen wir einen fairen Preis? Wenn ein studierter Softwareentwickler im Schnitt 65€ in der Stunde zurecht verdient, ein ungelernte virtuelle Assistentin für Keywordrecherche bei 45€ in der Stunde aber bereits beleidigt ist. Auch das Argument „dann könnte ich es auch selber machen“ ist nunmal gerechtfertigt, wenn es wahr ist: Muss der Auftraggeber zwei Stunden aufwenden um einen Artikel schreiben zu lassen, ist es wirtschaftlicher es selbst zu tun.

Das Wirtschaftlichkeitsargument ist ein interessantes Thema in diesem Zusammenhang: Es ist doch kindisch darauf soetwas wie „Es geht nicht alles immer nur ums Geld“ bzw. um Gewinnmaximierung bzw. um Wirtschaftlichkeit. Das stimmt: Im Privatleben. In Geschäftsbeziehungen geht es genau um Konsten und Nutzen. Selbst wenn es um Spenden geht.

Schlüsse, die ich daraus ziehe

Freelancer zu finden, vor allem in diesen Allerweltsbereichen wie Texten, Assistenz, Suchmaschinenoptimierung, Rechnungswesen usw. ist ein Schmerz. Ein unglaublicher Aufwand, denn die meisten haben trotz ihrer mäßigen Arbeitsleistung volle Auftragsbücher (interessanterweise). In der Briefingkommunikation stellt sich oft heraus, dass der Freelancer nicht geeignet ist und oft sind Arbeitsergebnisse unbrauchbar.

Für mich habe ich drei Möglichkeiten, die ich versuchen werde. Es muss doch möglich sein, unkompliziert an gute Freelancer zu kommen. Upwork habe ich noch nicht probiert, das werde ich als nächstes tun. Zweitens würde ich gerne unseren bereits vorhanden Pool (oder Netzwerk) an Freelancern nutzen, um Aufgaben einfach in diesen Pool zu geben. Wer Interesse an der Aufgabe hat, kann sie sich nehmen (das geht auch in Richtung unseres Projektes Humanoid („Statt Freelancersuche, Ergebnisse erhalten“ – Könnte das Motto sein). Als dritte Möglichkeit werden es dann doch wieder Agenturen sein, die ich beauftrage, die ihre Freelancer in meinem Auftrag steuern. Das ist dann offensichtlich der Preis, den ich und die Freelancer zu zahlen haben.

Schade. Habt ihr Tipps? Wie löst ihr diese Problematik für euch?

Weiterer Artikel zum Thema: „So wirst du ein Lieblingsfreelancer„.

Beitragsbild: Google-Logo als 3D-Objekt

Wie Sie Synonyme für SEO verwenden sollten oder nicht verwenden sollten

Schreibe eine Antwort

Wenn Sie im Bereich SEO arbeiten oder gerade lernen, haben Sie wahrscheinlich schon einmal von Synonymen gehört:

Jemand hat Ihnen gesagt, dass Sie für SEO Synonyme zu Ihrer Website hinzufügen müssen.
Ein Plugin auf Ihrer WordPress-Website empfahl Synonyme für beste SEO-Ergebnisse.
Sie haben einen Hinweis auf diesen Artikel gesehen und waren neugierig, wie Synonyme Ihre SEO verbessern können.
Sie haben widersprüchliche Artikel über Synonyme gelesen und wissen nicht, was wahr ist.

Was auch immer Sie zu diesem Artikel geführt hat, Sie können eine fundierte Entscheidung in dieser verwirrenden Welt der Synonyme für SEO treffen.

Warum raten Ihnen die meisten SEOs, Synonyme zu verwenden? Die meisten SEOs werden Ihnen sagen, dass Sie in Ihren Inhalten Synonyme verwenden sollten, weil Google dies vorschreibt oder weil es eine gängige SEO-Best Practice ist. Die wenigsten wissen jedoch, wie es zur Verwendung von Synonymen gekommen ist (und kennen auch nicht die Geschichte).

Im Jahr 2010 schrieb Google in seinem offiziellen Blogbeitrag mit dem Titel „Helping Computers Understand Language“, dass:

"Das Ziel einer Suchmaschine ist es, die besten Ergebnisse für Ihre Suche zu liefern, und das Verstehen von Sprache ist entscheidend, um die besten Ergebnisse zu liefern. Ein wichtiger Teil davon ist unser System zum Verstehen von Synonymen."

Im September 2018 twitterte der Google-Suchbeauftragte Danny Sullivan:

"Dies ist ein Rückblick auf eine große Veränderung in der Suche, die aber weiterhin wichtig ist: das Verständnis von Synonymen. Wie Menschen suchen, unterscheidet sich oft von den Informationen, über die Menschen Lösungen schreiben."

Dies hat die Branche noch mehr in Aufruhr versetzt, was die Optimierung von Websites mit Synonymen angeht.

Wie ich in meinem kürzlich erschienenen Artikel über neuronales Matching erwähnt habe, werden SEO-Profis „… Ihnen sagen, dass Sie einfach Synonyme hinzufügen sollen, aber es geht nicht darum, einfach nur Synonyme oder Adjektive zu Ihrem Inhalt hinzuzufügen.“
Sollten Sie Synonyme für SEO verwenden?

Die einfache Antwort auf die Frage, ob Sie Synonyme für die Suchmaschinenoptimierung verwenden sollten, ist ein „Ja“, allerdings sollte diese Strategie mit Vorsicht behandelt werden.

Verwenden Sie Synonyme nur dann und dort, wo sie mit der natürlichen Sprache der Website und/oder Seite übereinstimmen.

Im September 2019 erwähnte John Mueller von Google in einem Hangout Q&A:

"Sie können sich Situationen vorstellen, in denen Sie vielleicht ein pharmazeutisches Produkt haben, das einen ausgefallenen medizinischen Namen hat und auch eine Art allgemeinen umgangssprachlichen Namen hat. Die Nutzer suchen vielleicht nach diesem einfacheren Namen, weil sie von ihren Freunden davon gehört haben, und wenn Sie auf Ihren Seiten nur den ausgefallenen medizinischen Namen verwenden, werden Sie Probleme haben, für diese Begriffe zu ranken.

Unabhängig davon, ob Sie Markenregeln oder Richtlinien haben, die besagen, dass Sie nur diese Art von langen medizinischen Namen verwenden sollten, wenn Sie nicht die Wörter verwenden, mit denen die Leute nach Ihren Seiten suchen, dann wird es schwieriger sein, für diese Begriffe zu ranken. Das ist nicht unmöglich, das können wir im Fall des - oder nicht, das ist leicht zu verstehen. Sogar im Fall eines langen medizinischen Namens im Vergleich zu einem umgangssprachlichen Namen können wir versuchen, das herauszufinden. Wenn Sie aber nicht erwähnen, wonach die Leute tatsächlich suchen, dann werden Sie es schwer haben. Wenn Sie also Inhalte für Nutzer schreiben und wissen, dass sie auf eine bestimmte Art und Weise suchen, dann versuchen Sie, das zu berücksichtigen."

LSI-Schlüsselwörter

LSI, oder Latent Semantic Indexing, ist eine Technik zur Verarbeitung natürlicher Sprache, die in den 1980er Jahren entwickelt wurde. „LSI-Schlüsselwörter“ sind Wörter und Phrasen, die semantisch mit einem Thema verbunden sind.

Viele SEOs werfen LSI-Keywords mit Synonymen in einen Topf, wenn es um die Optimierung einer Website geht.

Sie gehen davon aus, dass, wenn Sie Ihre Website für „Autos“ optimieren, das Wort „Automobile“ und „Fahrzeuge“ in Verbindung mit „Getriebe“, „Motor“, „Bremsen“, „Lenkung“ und anderen autoverwandten Begriffen verwendet werden sollte.

Es ist sinnvoll, dass Google LSI verwendet, twitterte John Mueller:

Alternativ verwendet Google neuronales Matching, d.h. maschinelles Lernen verschiedener Signale, um festzustellen, ob eine Seite für die Suchabsicht des Nutzers relevant ist.

Ein Beispiel: Ein Nutzer klickt auf ein Ergebnis und kommt schnell zurück, um ein anderes Ergebnis anzuklicken.

Wenn eine große Anzahl von Nutzern auf denselben Link klickt und dann zurückkommt, um ein anderes Ergebnis auszuprobieren, zeigt dies Google, dass das Ergebnis nicht den Erwartungen entspricht.

Das zweite Ergebnis, auf das die Nutzer klicken und nicht mehr zurückkommen, wird dann höher eingestuft.

Was sind semantisch verwandte Schlüsselwörter?

Die Semantik ist ein Teilgebiet der Linguistik, das sich mit der Ableitung von Bedeutungen aus einer Reihe von Wörtern befasst.

Semantisch verwandte Schlüsselwörter sind Wörter oder Phrasen, die in einer konzeptionellen Beziehung zueinander stehen und eine zusammenhängende Geschichte erzählen.

SEOs glauben, dass mehr semantisch verwandte Schlüsselwörter bedeuten, dass Ihre Webseiten mehr kontextuellen Hintergrund zu einem Thema bieten und daher in den Suchergebnissen besser abschneiden können.

Die Theorie besagt, dass Google durch die Verwendung von Synonymen und anderen themenverwandten Wörtern in der Lage ist, Verbindungen zwischen den semantisch verwandten Begriffen herzustellen und die Absicht des Nutzers bestmöglich zu erfüllen.
Was Synonyme für SEO bedeuten

Die Idee, dass Sie die Häufigkeit der Verwendung von Synonymen mit Ihren Schwerpunkt-Keywords formulieren sollten, ist eine veraltete SEO-Strategie.

Die Verwendung von Synonymen und semantisch verwandten Schlüsselwörtern sollte sich ganz natürlich in den Fluss Ihrer Website-Inhalte einfügen.

Google nutzt die Signale der Nutzer selbst mehr als die Wörter auf der Seite zu bewerten.

Ein Beispiel: Ein Nutzer sucht nach „Hund, der unberechenbar herumläuft“ oder „Hund, der unberechenbar herumspringt“. Obwohl sie das Gleiche bedeuten, werden sie als unterschiedliche Ergebnisse behandelt, obwohl beide Ergebnisse „Zoomies“ erklären.

Hund, der wild herumrennt
Hund, der eratisch herumspringt

Wenn Sie sich die Ergebnisse für „rennen“ ansehen, ist der Text einfach, mit nur 3 Erwähnungen von rennen und 13 Erwähnungen von „zoomies“ mit einer Erwähnung des exakten Ausdrucks „dog running around erratically“.

Das Ergebnis für „darting“ enthält 6 Erwähnungen von „running“ und 91 Erwähnungen von „zoomies“, ohne dass der genaue Ausdruck oder das Wort „darting“ erwähnt wird, und zusätzlich mehrere Fragen und Antwortabschnitte zum Thema.

Darüber hinaus weist das Ergebnis „Dart“ 44 Links auf, die auf die Seite verweisen, wobei 80 % dieser Links Themen rund um „Zoomies“ beinhalten, und die URL-Struktur befindet sich direkt unter der Hauptdomain.

Im Gegensatz dazu hat das Ergebnis „rennen“ keine Backlinks und die URL-Struktur ist 4 Ebenen von der Hauptdomain entfernt, aber das Ergebnis „rennen“ rangiert auch für „Hund rennt unberechenbar herum“ (obwohl „rennen“ nicht erwähnt wird):

Da das Ergebnis „darting“ die Seite mit dem Schlüsselwort „zoomies“ und so vielen Backlinks vollstopft, könnte das Ergebnis für Variationen des Begriffs auftauchen.

Durch die Überoptimierung der Seite hat die Website sich selbst mehr geschadet als geholfen.

Die Lehre daraus ist, den Inhalt einfach zu halten, Synonyme nur dann zu verwenden, wenn sie sinnvoll sind, und die Website und ihre Seiten nicht übermäßig zu optimieren.
Wann man Synonyme für SEO verwenden sollte

Verwenden Sie Synonyme nur, wenn es Sinn macht. Wenn die Daten zeigen, dass die Nutzer tatsächlich nach Begriffen suchen, die mit Ihrem Schlüsselbegriff verwandt sind, dann ist es sinnvoll, sie einzubeziehen.

Versuchen Sie nicht, Ihren Inhalt mit Synonymen vollzustopfen, nur um ein besseres Ranking zu erreichen. Bei zu vielen Synonymen oder überoptimierten Inhalten wird Google den Schwerpunktbegriff höchstwahrscheinlich nicht aufnehmen.

Ich habe zum Beispiel eine Testseite entwickelt, um Ergebnisse für Suchanfragen zum Thema „in meiner Nähe“ zu erhalten.

Die Domäne der Website ist „nearyouhub.com“, die „in Ihrer Nähe“, „in der Nähe“, „in der Nähe“ und mehr erwähnt, ohne sich stark auf „in meiner Nähe“ zu konzentrieren.

Die Website wurde vor 4 Monaten ins Leben gerufen und verzeichnet seither steigende Zugriffszahlen für die Begriffe „near me“:

Wie man Synonyme für SEO verwenden sollte oder nicht sollte

Die Idee hinter dem Test ist, dass die Nutzer nach „in meiner Nähe“ suchen, aber die Sprache auf der Website macht keinen Sinn, „in meiner Nähe“ zu sagen, da die Website FÜR den Nutzer spricht.

Wann und warum Sie keine Synonyme für SEO verwenden sollten

Wenn Ihr Thema klar ist und es keine Variationen gibt, die von den Nutzern verwendet werden könnten, um das Gesuchte zu finden, dann sollten Sie auf Synonyme verzichten.

Für Wörter wie „Tier“, „Wald“, „Sand“, „Wasser“, „Salz“ und viele andere Wörter, die auch andere Bedeutungen haben können, gibt es möglicherweise keine Alternativen, die das Gleiche bedeuten.

Ihre Marke ist ein Beispiel dafür, dass Sie sich an Ihren Schlüsselbegriff halten und nicht versuchen sollten, Synonyme zu verwenden. Ich habe zum Beispiel vor einigen Jahren mit Hint Water zusammengearbeitet, um deren Website zu optimieren. Es gab Gespräche darüber, wie der Blog Wasser auf kreativere Weise erwähnen könnte.

Wir konzentrierten uns auf die Themen Gesundheit, Ernährung und aromatisiertes Wasser, wenn wir über das Produkt sprachen. Es gab keine alternativen Schlüsselwörter zu „Wasser“ oder dem Markennamen „Hint“.

Fazit

Viele Tools und Fachleute werden Ihnen die Verwendung von Synonymen nahelegen, und manchmal ist diese Strategie auch sinnvoll. Aber verwenden Sie keine Synonyme, um Ihre Platzierung zu verbessern, wenn sie keinen Sinn ergeben. Konzentrieren Sie sich stattdessen auf beschreibende Wörter und halten Sie Ihre Inhalte einfach, leicht verständlich und für den Nutzer zugänglich.

Artikelbild: FIRE-Bewegung - Frugalisten Ruhestand mit 40

FIRE: Was machen moderne Frugalisten?

Schreibe eine Antwort

Das traditionelle und ursprüngliche Ziel der FIRE-Bewegung besteht darin, das 25-fache des gewünschten Einkommens für den Ruhestand zu sparen. FIRE steht für Finacial Independence Retire Early. Sobald sie dieses Ziel erreicht haben, können sie in den Ruhestand gehen, ohne arbeiten zu müssen und mehr Geld in ihren Rentenfonds einzahlen.

Wenn Sie in diesem Szenario Ihren Vollzeitjob aufgeben, haben Sie genug Ersparnisse für den Ruhestand, um sich für ein paar weitere Jahre einen schönen Notgroschen aufzubauen, ohne das Geld aufstocken zu müssen. Vielleicht können Sie Ihren Vollzeitjob aufgeben und in Teilzeit arbeiten, um Ihre Altersvorsorge aufzustocken. Anstatt Ihre Arbeit aufzugeben, könnten Sie in Teilzeit arbeiten, eine lukrative Traumkarriere verfolgen oder freiberufliche Projekte annehmen, um die grundlegenden Lebenshaltungskosten zu decken und gleichzeitig Ihre langfristigen Rentenersparnisse über das traditionelle Rentenalter hinaus wachsen zu lassen.

Unabhängig davon, wie sehr Sie Ihren Lebensstil einschränken, benötigen Sie ein hohes Einkommen (im sechsstelligen Bereich), um bis zu Ihrem 40. Geburtstag genug für den Ruhestand zu sparen.

Eine der wichtigsten Komponenten der FIRE-Bewegung ist es, 50 % oder mehr Ihres Einkommens zu sparen, um Ihren Ruhestand zu beschleunigen. Manche Menschen sparen einen großen Teil ihres Einkommens für den Ruhestand, aber das sollte nicht der einzige Ansatz sein, den Sie verfolgen.

Das ultimative Ziel der FIRE-Bewegung ist es, vorzeitig in den Ruhestand zu gehen und die Ersparnisse, das Einkommen und die Investitionen zur Deckung der Lebenshaltungskosten zu verwenden. Bei der FIRE-Bewegung geht es darum, aktuelle Opfer zu bringen und den Lebensstil einzuschränken, damit man die langfristigen Vorteile des Vorruhestands genießen kann.

In der Hoffnung, bereits in jungen Jahren finanzielle Unabhängigkeit zu erlangen und diese für den Rest ihres Lebens, insbesondere im Ruhestand, aufrechtzuerhalten, sparen Feuerwehrinvestoren so viel wie möglich von ihrem Einkommen während ihrer Arbeitsjahre. Als Faustregel begründen Feuerwehrleute ihr Ziel, das Zweieinhalbfache ihrer Ausgaben zu sparen, als sichere Auszahlungsrate für den Ruhestand, weil sie ihr Geld nicht mit 4 % aus einem einzigen Prinzip überleben wollen.

Feuerwehrleute in den USA und in ihren 20er, 30er und 40er Jahren sparen in der Regel 70 % ihres Einkommens, um das 2,5-Fache ihrer jährlichen Lebenshaltungskosten zu decken. Im Vorruhestand könnten sie bis zu 4 % pro Jahr aus ihrem Nest nehmen, um komfortabel zu leben, je nach Entwicklung der Aktienmärkte und dem Zustand ihrer Anlagen. Wer sparsam lebt, so viel wie möglich spart und Geld investiert, um mit 30 in Rente gehen zu können, kann vielleicht 50 % seines Einkommens sparen, um vorzeitig in den Ruhestand zu gehen, aber das ist nicht die einzige Möglichkeit, die Bewegung zu betrachten.

„Lean Fire“ bezieht sich auf die Fähigkeit, mit einem geringen Alterseinkommen in den Ruhestand zu gehen, mit begrenzten Lebenshaltungskosten, die einen sparsamen Lebensstil im Ruhestand erfordern. Am anderen Ende des Lean Fire steht das Grease Fire, das sich auf die Fähigkeit bezieht, mit einem beträchtlichen Vermögen und einem passiven Einkommen in den Ruhestand zu gehen, ohne sich um die Lebenshaltungskosten im Ruhestand zu sorgen. Dies gilt auch für Menschen, die einen traditionelleren Lebensstil pflegen und mehr sparen als der durchschnittliche Rentenanleger.

„Fat Fire“ hingegen ist für Menschen mit geringem Einkommen gedacht, die ihren luxuriösen Lebensstil auch im Ruhestand beibehalten wollen, so dass sie mehr Zeit mit Sparen verbringen können. Die Option Barista Fire basiert auf einer Kombination aus passivem Einkommen, das Ihre Ersparnisse speist, und aktivem Einkommen aus einem Teilzeitjob.

Eines der Dinge, die Menschen davon abhalten, an FIRE (Financial Independence and Retirement) teilzunehmen, ist die Angst, dass sie nach ein paar Jahren keinen neuen Job mehr bekommen, wenn sie ihre Meinung ändern. Für diejenigen, die dem Fat Fire folgen, ist bekannt, dass es länger dauert, einen besser bezahlten Beruf zu wählen, um ihre größeren Sparziele zu erreichen. Für jemanden, der die Feuerwehr abonniert hat, besteht das Ziel nicht darin, in Rente zu gehen, sondern einen Punkt zu erreichen, an dem er keinen regulären Job mehr braucht, um die Rechnungen zu bezahlen.

Die Befürworter von FIRE (Financial Independence Retirement Early) planen, vor dem traditionellen Rentenalter von 65 Jahren in den Ruhestand zu gehen und 70 % ihres Einkommens für Ersparnisse auszugeben, während sie noch im Berufsleben stehen. Diejenigen, die nicht an Pfennigen über dem Durchschnitt interessiert sind, werden vorzeitig in Rente gehen und ihr Einkommen entsprechend erhöhen. Anstatt 70 % ihres Jahreseinkommens für die finanzielle Unabhängigkeit zu sparen und vorzeitig in den Ruhestand zu gehen, wollen die Befürworter von FIRE früher in den Ruhestand gehen und von kleineren Entnahmen aus den angesammelten Mitteln leben.

Financial Independence Retire Early (FIRE) ist eine Bewegung, die sich einem Programm extremer Einsparungen und Investitionen verschrieben hat, das es den Befürwortern ermöglicht, früher in den Ruhestand zu gehen, als es herkömmliche Budgets erlauben. FIRE zeichnet sich durch das Prinzip der extremen Sparsamkeit und Wirtschaftlichkeit aus, um ein passives Einkommen zur Finanzierung des Vorruhestands zu erzielen.

Der vorzeitige Ruhestand ist das erklärte Ziel der FIRE-Bewegung, und das bedeutet, eine klare Vorstellung davon zu haben, wo der Rentner leben muss, wenn sein Arbeitseinkommen wegfällt. Alle profitieren von den Grundsätzen der FIRE-Bewegung – Planung für die Zukunft, vernünftige Ausgaben, Sparen und wertvolle Lehren, die man ziehen kann, ob man nun vorzeitig in Rente gehen will oder nicht. Obwohl jeder Ansatz für Feuerwehrleute einzigartig ist, gibt es einige Grundsätze, von denen viele in der Vorruhestandsbewegung sagen, dass sie die Wartezeit auf den Ruhestand von Jahrzehnten auf Jahre verkürzen können.

Ob Sie vorzeitig in den Ruhestand gehen können, hängt von Ihrem Einkommen ab: wie viel Ersparnisse und Investitionen Sie haben, wie viel von Ihrem Einkommen Sie sparen können, in welchem Alter Sie in den Ruhestand gehen wollen und wie viel Sie im Ruhestand zum Leben brauchen. Ihr Ziel sollte es sein, so viel zu sparen, dass Sie genau wissen, wie viel Sie brauchen und welche Art von Rente Sie wünschen, was sich auf die Höhe Ihrer Sparziele auswirkt.

Artikelbild: Zeigt emotionales Teammitglied

Fehlerkultur im Team: So kritisiert man richtig

Schreibe eine Antwort

Wenn Sie jemals in einem Unternehmensteam gearbeitet haben, wissen Sie, dass die meisten Mitarbeiter eine Meinung haben. Ein kluger Umgang mit konstruktiver Kritik ermöglicht es einem Teamleiter, den Beitrag aller Mitarbeiter am Arbeitsplatz zu maximieren. Menschen, die keine konstruktive Kritik annehmen, ignorieren kritische Informationen, die ihr Wachstum und ihre Entwicklung fördern können. Wenn man es versäumt, Grundregeln für das Geben und Empfangen von Feedback in einem Team aufzustellen, kann dies zu Verstimmungen, anhaltenden Konflikten und geringerer Produktivität führen.

Einzelnes Thema

Beschränken Sie sich jeweils auf ein Thema, wenn Sie Feedback geben müssen. Gönnen Sie sich etwas Zeit, um zu formulieren, was Sie Ihrer Mitarbeiterin sagen wollen, bevor Sie Einzelheiten über ihre Leistung mitteilen. Bieten Sie Ihren Rat in objektiver Weise an. Vermeiden Sie es, Ihre Autorität geltend zu machen oder Ihre persönliche Meinung einzubringen. Auch wenn Sie vielleicht versucht sind, auf die Fehler einer anderen Person hinzuweisen, um Ihre eigene Karriere voranzutreiben, erkennt der kluge Mitarbeiter, dass es normalerweise besser ist, zu kooperieren und andere zu unterstützen.

Akzeptanz

Erkennen Sie an, dass Ihre Arbeit analysiert wird und nicht Sie persönlich, wenn Sie diejenige sind, die das konstruktive Feedback erhält. Nehmen Sie eine Kritik an Ihrer Arbeit nicht als Ausdruck Ihrer langfristigen Fähigkeit, im Job erfolgreich zu sein. Das Ziel eines konstruktiven Beitrags ist es, die Arbeit zu verbessern. Ein kollaboratives Umfeld fördert den Austausch und die kontinuierliche Verbesserung. Vermeiden Sie es, sich defensiv zu fühlen, indem Sie die Verantwortung für Ihr Verhalten übernehmen und Maßnahmen ergreifen, wenn Sie können. Sie können sich zwangsläufig auf die negativen Aspekte des Feedbacks konzentrieren und sich angegriffen fühlen, aber versuchen Sie, gemeinsam an der Lösung von Problemen zum Wohle des Teams zu arbeiten. Wenn Sie beständiges Feedback aus verschiedenen Quellen erhalten, wissen Sie, dass Sie etwas haben, woran Sie in Zukunft arbeiten können.

Dokumentation

Sowohl Arbeitnehmer als auch Arbeitgeber müssen die geäußerte und erhaltene konstruktive Kritik dokumentieren. Mitarbeiter sollten Aufzeichnungen über jedes Feedback führen, das sie für ungerechtfertigt halten. Schriftliche Korrespondenz dient als Protokoll. Führen Sie zum Beispiel ein Tagebuch über den mündlichen Austausch und Kopien von E-Mails oder Berichten, die die Leistung in einem schlechten Licht darstellen. Weder ein Arbeitnehmer noch ein Arbeitgeber sollte versuchen, sich auf unprofessionelle Weise an einem Kontrahenten zu rächen.

Verbesserung

Konstruktive Kritik an der Teamleistung am Arbeitsplatz ermöglicht es den Mitarbeitern zu erkennen, dass sie nicht perfekt sind. Vergangene Teamkonflikte sollten die aktuelle Projektarbeit nicht beeinträchtigen. Wenn nötig, vereinbaren Sie ein Treffen, um die Situation zu klären. Jeder Mensch macht Fehler. Um die Teamleistung zu maximieren, sollten Sie jeden Mitarbeiter dazu ermutigen, die Verantwortung für seine Arbeit zu übernehmen, die Ergebnisse doppelt zu überprüfen und sich zu vergewissern, dass er die beste Arbeit leistet, bevor er sie abgibt. Dadurch werden Flüchtigkeitsfehler, dumme Fehler und peinliche Probleme vermieden. Durch die Schaffung eines Umfelds, in dem jeder erwartet, Feedback zu erhalten, schafft ein Teamleiter einen Arbeitsplatz, der übermäßig kritische Kommentare auf ein Minimum reduziert und sich auf kontinuierliche Verbesserungen konzentriert.

GitHub Copilot: Eine leistungsfähige, umstrittene Autovervollständigung für Entwickler

Schreibe eine Antwort

Aus dem Englischen übersetzt von Darryl K. Taft. (Quelle: thenewstack.io)

Ich beschäftige mich schon seit langem mit der Anwendungsentwicklung und habe viele Durchbrüche erlebt. Einige fallen mir mehr ins Auge als andere, und Copilot von GitHub ist einer dieser Hingucker.

GitHub bezeichnet Copilot als seinen KI-Begleiter für das Pair-Programming für Entwickler.

Die Technologie ist wirklich vielversprechend. „GitHub Copilot zieht Kontext aus dem Code, an dem Sie arbeiten, und schlägt ganze Zeilen oder Funktionen vor“, erklärt GitHub-CEO Nat Friedman in einem Blogbeitrag zur Einführung der Technologie.

Copilot hilft Entwicklern, schnell alternative Wege zur Problemlösung zu finden, Tests zu schreiben und neue APIs zu erforschen, ohne mühsam auf Seiten wie Stack Overflow und im Internet nach Antworten suchen zu müssen, so Friedman. Und da es auf maschinellem Lernen basiert, lernt es bei der Benutzung. „Während Sie tippen, passt es sich an die Art und Weise an, wie Sie Ihren Code schreiben – damit Sie Ihre Arbeit schneller erledigen können“, sagte er.

Die Technologie befindet sich derzeit in der technischen Vorabversion und wird von den Nutzern innerhalb und außerhalb von Microsoft/GitHub sehr positiv bewertet, aber auch kritisiert.

„Ich bin beeindruckt davon, wie GitHub Copilot genau zu wissen scheint, was ich als nächstes eingeben möchte“, sagte Feross Aboukhadijeh, Gründer von Socket, einem Hersteller von Datenschutz- und Sicherheitssoftware, in einer Stellungnahme. „GitHub Copilot ist besonders hilfreich bei der Arbeit an React-Komponenten, wo es unheimlich genaue Vorhersagen macht. GitHub Copilot ist zu einem unverzichtbaren Teil meines Werkzeuggürtels für Programmierer geworden.“

Alex Polozov, ein leitender Forscher bei Microsoft Research, ist zwar nicht sonderlich überparteilich, twitterte aber: „Ich übertreibe nicht, Copilot wird zu den Top-3-Tech-Entwicklungen der 2020er Jahre gehören.“

GitHub Copilot ist ein Produkt der Partnerschaft zwischen Microsoft und dem KI-Forschungs- und Einsatzunternehmen OpenAI, in das Microsoft vor zwei Jahren 1 Milliarde Dollar investiert hat.

Friedman erklärte, dass „GitHub Copilot von OpenAI Codex angetrieben wird, einem neuen KI-System, das von OpenAI entwickelt wurde.“

OpenAI Codex verfügt über ein umfassendes Wissen darüber, wie Menschen Code verwenden, und ist bei der Codegenerierung wesentlich leistungsfähiger als GPT-3, unter anderem, weil es auf einem Datensatz trainiert wurde, der eine viel größere Konzentration von öffentlichem Quellcode enthält, erklärte Friedman.

Einige Leute scheinen besorgt zu sein, dass es Code generiert, der mit Code identisch ist, der unter Open-Source-Lizenzen generiert wurde, die keine abgeleiteten Werke zulassen, und der dann von einem Entwickler unwissentlich verwendet wird.

GitHub lehnte es ab, einen Sprecher für diese Nachricht zu interviewen und verwies mich auf die recht ausführliche FAQ der technischen Vorschau. Auf meine Frage nach den Datenquellen, die Copilot verwenden würde, antwortete GitHub beispielsweise wie folgt: „Es wurde auf eine Auswahl von englischem Sprach- und Quellcode aus öffentlich zugänglichen Quellen trainiert, einschließlich (aber nicht beschränkt auf) Code in öffentlichen Repositories auf GitHub.“

But which ones?

„Mit Sicherheit verwenden sie die GitHub-Repos. Und auf jeden Fall die öffentlichen“, sagt Ronald Schmelzer, Analyst bei Cognilytica, das sich auf KI-Forschung und -Analyse spezialisiert hat. „Die Frage ist natürlich, ob sie auch die privaten GitHub-Repos nutzen. Und mit oder ohne Zustimmung der Nutzer? Weitere Quellen könnten vielleicht Stack Overflow und andere Orte sein, an denen Menschen Code zur Kommentierung veröffentlichen. Aber das ist von zweifelhafter Natur, was die Qualität angeht.“

Da Copilot auf öffentlich verfügbarem Quellcode und natürlicher Sprache trainiert wurde, versteht es außerdem sowohl Programmier- als auch menschliche Sprachen. Dies ermöglicht es Entwicklern, eine Aufgabe auf Englisch zu beschreiben, und GitHub Copilot liefert dann den entsprechenden Code, so das Unternehmen.
Unterstützt mehrere Sprachen

Ein attraktives Merkmal von GitHub Copilot ist, dass es mit einer breiten Palette von Frameworks und Sprachen funktioniert, aber diese technische Vorschau funktioniert besonders gut für Python, JavaScript, TypeScript, Ruby und Go, so Friedman.

Und laut der technischen Vorschau-Seite: GitHub Copilot ist derzeit nur als Visual Studio Code-Erweiterung verfügbar. Es funktioniert überall dort, wo Visual Studio Code funktioniert – auf Ihrem Rechner oder in der Cloud auf GitHub Codespaces. Und es ist schnell genug, um es während der Eingabe zu verwenden.

„Copilot sieht wie ein potenziell fantastisches Lernwerkzeug aus – für Entwickler aller Fähigkeiten“, sagte James Governor, ein Analyst bei RedMonk. „Es kann Einstiegshürden beseitigen. Es kann beim Erlernen neuer Sprachen helfen und für Leute, die an polyglotten Codebasen arbeiten. Es setzt wohl das reiche Erbe von GitHub als erstklassiges Lernwerkzeug fort. Es ist noch zu früh, aber KI-gestützte Programmierung wird sich durchsetzen, und wo könnte man diese Erfahrung besser machen als auf GitHub?“
Ja, aber kann es skalieren?

Einige Beobachter sehen Copilot als nützlich für einfache Projekte, aber vielleicht noch nicht reif für die erste Zeit.

„Es ist eine sehr interessante Idee und sollte bei einfachen Beispielen gut funktionieren, aber ich bin gespannt, wie gut es bei komplexen Code-Problemen funktionieren wird“, sagt Eric Newcomer, Chief Technology Officer von Enterprise Infrastructure Software

Artikelbild zeigt Entscheidungsbaum für No-Code oder Low-Code-Anwendungen

No-Code: Apps ohne Entwicklungsteam

Schreibe eine Antwort

Die Idee, dass wir nun alle Projektleiter mit No-Code-Werkzeugen ausstatten und statt Excel-Listen mit den Mitarbeitern zu pflegen, gleich Apps generieren, optimiert generiert für Dateneingabe, Statusrückmeldungen, Arbeitsnachweise, you name it, bereit für den Produktivbetrieb, muss leider ein Wunsch bleiben.

Realistisch ist: Durch No-Code und Low-Code rücken die fachlichen und nicht-funktionalen Anforderungen näher an die Umsetzung. Die Umsetzung kann effektiver agieren. Für wenig exotische bzw. wenig innovative Geschäftsprozesse werden nicht mehr unbedingt spezielle Programmierer benötigt. Sodass Informationen durch die Organisation hinweg schneller und zuverlässig auflaufen und gesammelt werden können.

Besonders Prozessverantwortliche in Projekten oder Abteilung einer Organisation durften häufiger das Bedürfnis haben, Abläufe direkter beeinflussen zu können, als ständig durch alle Phasen der Softwareentwicklung zu müssen. Ein Exceldokument hier, ein Abrechnungsbogen da und zu dem spezielle Anforderungen vom Kunden. Für diese Prozesse gleich eine Entwicklermannschaft zu beauftragen, ist mindestens aufwändig und immernoch keine schneller Prozess. In den wenigsten Fällen ist es überhaupt finanziell sinnvoll. Schön wäre es, wenn nichttechnisches Personal die Workflows zusammenklicken könnten, oder?

Dieses Versprechen macht uns Low-Code und No-Code.

Den Wunsch, dieses lästige „Programmieren“ klickbar zu machen und damit die Möglichkeiten, die Programmierern im Allgemeinen vorbehalten sind, allen zugänglich zu machen, gibt es schon seit je her. Und gute Entwickler arbeiten auch selbst daran, sich selbst überflüssig zu machen. Seit der Nutzen von Software für Unternehmen oder Privatpersonen klar wurde, ist das praktisch so.

Den Entwickler herausrationalisieren

Gleich zu Beginn von Internet und Hypertextdokumenten (HTML) gab es im Officepaket von Microsoft das zweifelhaft berühmt gewordeme „Frontpage“. Die Idee war damals schon klar: Lasst und das lästige Programmieren aus der Gleichung kürzen, damit jeder Webseiten bauen kann. Das hat nicht funktioniert, zu komplex die Aufgabe. Mit Internetdiensten, die den Desktopnanwendungen in Funktion und Bedienung immer ähnlicher wurden (heute Progressive Webapps, abgekürzt PWA), war schnell klar: Das ist kein Problem, was man durch Ziehen und Klicken lösen kann.

Die Software „WordPress“ füllt diese Lücke seit Jahrzehnten bestmöglich aus, was ihr Beliebtheitsgrade widerspiegelt. Kleine- und mittlere Unternehmen klicken sich aus unzähligen Plugins ihre Webprojekte zusammen. Längst nicht nur einfach Internetseiten, sondern rudimäntare Plattformen, Communities, Webshops, Terminabspracheformulare, Feedbackfunktionen und andere Webapplikation (ich denke, man darf sie so nennen) werden da zusammen geklickt. Sicherlich bereits die Anfänge von Low-Code und No-Code.

Ein Spaß ist das meistens jedoch auch nicht und längst vermisst der Enduser bei den Ergebnissen eine gewisse Beständigkeit, Robustheit und Sauberkeit. Die Eingabemasken zu Erstellung der Applikation enthalten jetzt natürlich die Komplexität, mit der normalerweise die Programmierer in ihrem Code umgehen müssen. Jetzt werden unzählige Entscheidungsbäume, Automatisierungsregeln, Datentypen und sonstige komplexe Aufgaben eben über eine entsprechende komplexe Eingabemaske gelöst.

Der klare Vorteil ist schonmal, dass nun keine eigene Sprache gelernt werden muss. Es ist also möglich, so zu gewünschten Ergebnissen zu kommen. Man wird weniger auf Softwareingenieure angewiesen sein. Irgendjemand – muss weiterhin sagen, wie das Zusammenspiel von verschiedenen Anwendungen ablaufen soll, worauf es beim Komponieren von Anwendungen ankommt, wo die Anwendungen im Gesamtunternehmen, im Gesamtprojekt einzuodnen sind. Doch sie werden nicht mehr ständig für die gesamten Phasen der Anwendungsentwicklung benötigt.

Interessant ist dieser Trend auf jeden Fall. Das größte Problem, was wir an unnötigen Overhead derzeit noch haben, ist, dass viele Prozesse von den Entwickler wieder und wieder neu entwickelt werden. Diese Arbeitszeitverschwendung könnte durch Low-Code und No-Code bald der Vergangenheit angehören. Denn komplizierte Datenbankgestaltungen könnten tatsächlich der Vergangenehit angehören.

Ingesamt kann also der Einsatz von No-Code dazu führen, dass ein Entwicklerteam innerhalb eines Projektes oder Unternehmens effizienter und schlanker wird. Auch wird es möglich, dass juniorigere Kollegen robustere Ergebnisse erzielen, da sie durch den No-Code-Ansatz nicht anders können, als bereits reife Arbeiten wiederzuverwenden und das Rad daher nicht immer wieder neu erfinden (wie sie es sonst tendenziell tun).