Ihre App hat bereits Nutzer, gespeicherte Daten und Abläufe, auf die sich Menschen verlassen. Wenn Sie einen Entwickler holen, um einen Fehler zu beheben oder eine Funktion hinzuzufügen, gehören diese bestehenden Zusagen zur Arbeit dazu.
Ich beginne damit, das aktuelle System und die gewünschte Änderung zu verstehen. Sie helfen mir mit einem klaren Beispiel, einer Übersicht der beteiligten Dienste und einer Liste dessen, was weiter funktionieren muss. Dieser Leitfaden zeigt, was Sie vorbereiten sollten und was Sie von der Analyse erwarten können.
Beschreiben Sie die Änderung aus Sicht der Nutzer
„Die App ist langsam“ ist ein brauchbarer Anfang. „Auf dem Handy dauert das Öffnen der Bestellseite mehrere Sekunden, wenn ein Kunde viele frühere Bestellungen hat“ gibt uns etwas, das wir untersuchen können. Bei einer neuen Funktion beschreiben Sie, was Nutzer tun können sollen und was sie heute tun können.
Schicken Sie bei einem Fehler die Schritte, die dazu führen, was Sie erwartet haben und was stattdessen passiert ist. Nennen Sie Gerät oder Browser, wenn das eine Rolle spielen könnte. Eine kurze Bildschirmaufnahme hilft oft; entfernen Sie vorher Kundendaten und private Nachrichten.
Sagen Sie mir, wie oft das Problem auftritt, wen es betrifft und ob es eine Umgehung gibt. Ein Fehler im Bestellabschluss, der aktive Kunden trifft, braucht eine andere Reaktion als ein optisches Problem auf einer internen Seite.
Hier ist ein erfundener Fehlerbericht mit genug Details, um mit der Untersuchung zu beginnen:
Auf der Bestellseite „Letzte 30 Tage“ wählen und dann die zweite Ergebnisseite öffnen. Der Datumsfilter wird zurückgesetzt und ältere Bestellungen erscheinen.
Erwartet: Der Datumsfilter bleibt beim Blättern durch die Ergebnisse ausgewählt.
Das passiert jedes Mal in Chrome auf meinem Laptop. Unser Team kann es umgehen, indem es nach der Bestellnummer sucht, aber die Durchsicht der letzten Bestellungen dauert länger.
Geben Sie mir eine Übersicht über das aktuelle System
Sie müssen nicht jedes technische Detail kennen. Beginnen Sie mit dem, was Sie wissen, und sagen Sie mir, wer Fragen zum Rest beantworten kann.
Wo der Code liegt, wem das Repository gehört und welche Version gerade live ist.
Wo die Anwendung läuft und wie Änderungen heute ausgerollt werden.
Die Datenbank, der Dateispeicher und die externen Dienste, die sie nutzt.
Anleitungen zur Einrichtung, automatische Prüfungen oder vorhandene Dokumentation.
Bekannte Probleme, unfertige Arbeit und frühere Versuche, dieses Problem zu lösen.
Ob der bisherige Entwickler oder ein anderes Team für Fragen erreichbar ist.
Wenn Sie eine Staging-Umgebung haben (eine separate Kopie, auf der Änderungen getestet werden, bevor sie Kunden erreichen), sagen Sie mir, wie ich darauf zugreife. Wenn nicht, planen wir eine ein, sobald die Arbeit sie erfordert.
Nennen Sie, was das aktuelle System erhalten muss: bestehende Links, gespeicherte Daten, Nutzerrechte, Integrationen oder App-Versionen, die noch auf den Handys Ihrer Kunden laufen. Solche Dinge übersieht man leicht, wenn es nur um einen neuen Bildschirm geht.
Vergeben Sie Zugänge per Einladung
Behalten Sie die Inhaberschaft an Repository, Hosting, Domain und Zahlungskonten. Laden Sie Entwickler über die Zugriffsverwaltung des jeweiligen Dienstes ein, mit den Rechten, die für die Arbeit nötig sind. Wo der Anbieter es unterstützt, kann eine Analyse mit Lesezugriff und einer Testumgebung beginnen.
Fügen Sie keine Passwörter, produktiven API-Schlüssel, Kundenexporte oder eine komplette Umgebungsdatei in ein Projekt-Briefing ein. Wie benötigte Zugangsdaten separat übergeben werden, vereinbaren wir. Testkonten und Beispieldaten sind zum Nachstellen eines Problems meist nützlicher als uneingeschränkter Zugriff auf echte Kundendaten.
Verstehen Sie die Analyse vor dem Angebot
Bei einer bestehenden Codebasis muss ich prüfen, wie sie läuft, das betroffene Verhalten nachverfolgen und verstehen, welche Teile eine Änderung berühren könnte. Eine scheinbar isolierte Funktion kann Berechtigungen, Abrechnung oder eine Datenbankmigration betreffen.
Umfang und Bedingungen der Analyse vereinbaren wir, bevor sie beginnt. Das schriftliche Ergebnis sollte erklären:
Was untersucht wurde, was sich nachstellen ließ und welche Zugänge oder Informationen noch fehlen.
Die empfohlene Änderung, einschließlich Alternativen, die eine Überlegung wert sind.
Welche bestehenden Funktionen oder Daten betroffen sein könnten.
Wie die Arbeit geprüft, ausgeliefert und bei einem Problem rückgängig gemacht wird.
Was sich jetzt schätzen lässt und was weitere Untersuchung braucht.
Fragen Sie nach einem Grund, bevor neu geschrieben wird
Älterer Code kann seine Aufgabe nach wie vor gut erfüllen. Ein anderes Framework oder die Vorlieben eines neuen Entwicklers sind schwache Gründe, ein funktionierendes System zu ersetzen. Oft ist die richtige Änderung eine gezielte Korrektur, ein fehlender Test oder ein schrittweises Upgrade.
Manchmal ist ein Neubau gerechtfertigt. Fragen Sie, welche Anforderungen das aktuelle System nicht vernünftig erfüllen kann, welche Teile erhalten bleiben könnten und wie der Übergang ablaufen würde. Zum Vergleich gehören auch die Datenübernahme und der Erhalt des bestehenden Verhaltens, nicht nur das Schreiben des neuen Systems.
Vereinbaren Sie, wie Änderungen zu den Nutzern kommen
Vor dem Ausrollen sollten wir wissen, wie die Änderung getestet wird, wer sie prüft und was passiert, wenn etwas schiefgeht. Bei einem Produkt im Live-Betrieb möchte ich einen abgestimmten Release-Plan und einen Weg zurück. Code zurückzusetzen macht eine Datenänderung nicht unbedingt rückgängig, deshalb brauchen Datenbankmigrationen einen eigenen Plan.
Beim Beispiel mit dem Datumsfilter würden wir prüfen, dass die Auswahl beim Blättern erhalten bleibt und die anderen Filter weiterhin richtig funktionieren. Sie sollten dieses Verhalten in einer Vorschau prüfen können, bevor die Korrektur auf die Live-Website geht.
Bei der Übergabe sollten Sie sehen können, was sich geändert hat, wie es geprüft wurde und was noch zu tun ist. Neue Einrichtungsschritte, Konfigurationsänderungen und bekannte Einschränkungen gehören in die Dokumentation.
Was Sie mir zuerst schicken sollten
Das ist das Produkt, und so wird es genutzt: …
Das ist die Funktion oder das Problem, mit einem Beispiel: …
Das muss weiter funktionieren: …
Das weiß ich über Code, Hosting und den bisherigen Entwickler: …
Auswirkung, Priorität und ein eventueller Termin: …
Schicken Sie mir diesen Kontext über dasKontaktformular. Sie müssen nicht das ganze Projekt aufräumen oder technische Dokumentation schreiben, bevor Sie um Hilfe bitten.