Der Machtwechsel ist mit Schwierigkeiten verbunden. Unterschiedliche Teams haben unterschiedliche Werte, unterschiedliche Erfahrungen, unterschiedliche Fachkenntnisse, unterschiedliche Prioritäten, und das führt zu unterschiedlichen Werkzeugen und unterschiedlichen Methoden. Es ist verlockend, sich Webdesign als einen End-to-End-Prozess vorzustellen, der mit der Recherche beginnt und mit den Kennzahlen endet. Die Realität ist, dass die meisten Designer und Entwickler Projekte im Laufe eines laufenden Prozesses einbinden. Das stellt uns vor eine schwierige Entscheidung: Versuchen wir, die Erwartungen des Kunden mit unserem eigenen Toolset zu erfüllen, oder passen wir uns den Tools und Prozessen an, die bereits vorhanden sind? Für alle, die ein Webprojekt von einem anderen Designer/Entwickler/einer anderen Agentur (D/D/A) übernehmen, gibt es hier einen praktischen Leitfaden, der Ihnen hilft, den Übergang erfolgreich zu gestalten.
Schritt 1: Finden Sie heraus, was schief gelaufen ist
In 99,99 % der Fälle ist in der vorherigen Kunden-D/D/A-Beziehung etwas kaputt gegangen. Nach meiner Erfahrung geht es fast nie um Geld. Die meisten Kunden sind bereit, über dem marktüblichen Basiszinssatz zu zahlen, wenn sie glauben, eine gute Rendite für ihre Investition zu erzielen. Ein Kunde, der Ihnen sagt, dass das vorherige D/D/A einfach zu teuer sei, rechnet mit Verhandlungen dein Gebühren.
[pullquote]Zufriedene Kunden kaufen nicht herum[/pullquote]
Gelegentlich kommt es vor, dass ein freiberuflicher Designer von einer Agentur angeworben wurde und nicht mehr verfügbar ist. Gelegentlich wächst das Unternehmen aus einem D/D/A heraus und dringt in Bereiche vor, die das D/D/A nicht unterstützt. Aber solche Situationen kommen selten vor, zufriedene Kunden – selbst mäßig zufriedene Kunden – schauen sich nicht um. Wenn sie mit Ihnen sprechen, hat sie etwas dazu motiviert. Es kommt erschreckend häufig vor, dass ein D/D/A einfach unerkannt bleibt. Am häufigsten kommt es am unteren Ende des Marktes vor, wo es weniger wahrscheinlich ist, dass die Geldsummen, um die es geht, einen Rechtsstreit auslösen. Häufig wird ein unzuverlässiger D/D/A einen Kunden zugunsten einer besseren, neueren Gelegenheit abwerben. Manchmal stellt der Kunde einen neuen Manager ein, und der neue Manager bringt veränderte Erwartungen mit sich, die der vorherige D/D/A nicht erfüllen kann. Am häufigsten hat der vorherige D/D/A den Ball zu oft fallen lassen – Fehler passieren, und vernünftige Kunden werden sie tolerieren, vorausgesetzt, sie werden umgehend korrigiert, aber jeder hat seine Grenzen. Die meisten Kunden erklären Ihnen gerne, was in der vorherigen Beziehung schief gelaufen ist. Es wird zwangsläufig eine einseitige Erklärung sein, aber sie wird Ihnen helfen, die Erwartungen des Kunden zu verstehen. Seien Sie äußerst vorsichtig gegenüber einem Kunden, der nicht weiß, was schief gelaufen ist. Seien Sie noch vorsichtiger gegenüber einem Kunden, der davon spricht, sein Outsourcing zu „verbessern“ – er versucht, Ihnen zu schmeicheln. In diesen Fällen kann es durchaus sein, dass der Kunde etwas verheimlicht – etwa, dass er Rechnungen nicht bezahlt. Denken Sie daran: Irgendwann war der vorherige D/D/A neu und freute sich über den neuen Kunden, war optimistisch in Bezug auf das Projekt und es endete nicht gut. Der beste Weg, Fehler nicht zu wiederholen, besteht darin, aus ihnen zu lernen. Dazu muss man wissen, um welche Fehler es sich handelt.
Schritt 2: Führen Sie ein umfassendes Audit durch
Wir sind oft so sehr darauf bedacht, einen neuen Auftrag zu bekommen, dass wir uns beeilen, den Kunden auf der gepunkteten Linie unterschreiben zu lassen, in der Erwartung, später etwaige Probleme lösen zu können. Als Profi ist es unerlässlich, dass Sie Ihre Versprechen halten. Bevor Sie solche Versprechungen machen, nehmen Sie sich die Zeit, das Projekt und das damit verbundene Geschäft zu verstehen. Wenn ein Kunde genug investiert hat, um einen Vertrag mit Ihnen zu unterzeichnen, wird er nichts dagegen haben, dass Sie zuerst eine Due-Diligence-Prüfung durchführen.
Besteht noch eine Beziehung zum vorherigen Designer/Entwickler/der vorherigen Agentur?
Kunden haben selten einen vollständigen Überblick über ihr Projekt – sie sind keine Webprofis, denn wenn sie es wären, würden sie ihre eigenen Websites erstellen. Ihre beste Informationsquelle ist das vorherige D/D/A. Bevor Sie den vorherigen D/D/A-Kontakt mit Ihrem Kunden aufnehmen; Möglicherweise wissen sie noch nicht, dass sie ersetzt werden. Wenn Ihr Kunde damit einverstanden ist, wenden Sie sich an ihn. Wenn Sie mit dem vorherigen D/D/A sprechen, achten Sie darauf, dass Sie ihm Geld aus der Tasche ziehen. Sicherlich kann Ihnen der bisherige D/D/A sagen, wohin Sie gehen sollen, er mag Sie auch völlig ignorieren, aber die meisten werden pragmatisch sein, wenn es darum geht, ein Projekt zu übergeben, und sei es nur, um sicherzustellen, dass die endgültige Rechnung an ihren jetzigen Ex-Kunden pünktlich bezahlt wird. Jede Site hat ihre Eigenheiten. Wenn Sie eine freundschaftliche Beziehung zum vorherigen D/D/A aufbauen können, wird der Übergang wesentlich weniger holprig sein.
Wer kontrolliert den/die Domainnamen?
Meiner Meinung nach sollten die Domänennamen eines Unternehmens immer im Besitz des Unternehmens sein. Es handelt sich um ein so wichtiges Geschäftsvermögen, dass es ebenso sorgfältig gehütet werden sollte wie die Bankkonten des Unternehmens. Leider gibt es Unternehmen, die alles rund um das Web auslagern. Wenn der Bruch mit dem vorherigen D/D/A schwerwiegend ist, könnte die Sicherung des Domainnamens problematisch sein. Es ist nicht Ihre Aufgabe, den Domainnamen zu sichern – Sie haben keinen Einfluss, sondern der Kunde. Es ist Ihre Aufgabe, dem Kunden zu vermitteln, wie geschäftskritisch der/die Domainnamen ist/sind.
Wer kontrolliert das Hosting?
Die Hosting-Arrangements variieren von Projekt zu Projekt. Es ist weder ungewöhnlich noch unvernünftig, dass der vorherige D/D/A die Website des Kunden in seinem eigenen Bereich hostet. Wenn dies der Fall ist, müssen Sie darauf vorbereitet sein, es schnell entweder auf Ihren eigenen Server oder einen dedizierten Bereich zu migrieren. Wenn Sie in einen neuen Bereich migrieren, achten Sie besonders auf die E-Mail-Bereitstellung. Die Übernahme eines Projekts bedeutet in der Regel die Übernahme eines Live-Projekts, und damit sind in der Regel auch E-Mail-Konten gemeint. In jedem Fall benötigen Sie vollen Zugriff auf den Hosting-Bereich. Sie benötigen auf jeden Fall einen FTP-Zugang, wahrscheinlich benötigen Sie einen SSH-Zugang. Überprüfen Sie zusätzlich zum Hosting, ob die Website Ihres Kunden ein CDN verwendet, und wenn ja, wer die Kontrolle darüber hat.
Backend-Quellcode
Sobald Sie FTP-Zugriff auf den Hosting-Server haben, können Sie wahrscheinlich den gesamten Backend-Code vom Server abrufen. Der Vorteil des Abrufens des Codes vom Server – im Gegensatz zum Akzeptieren von Dateien vom vorherigen D/D/A – besteht darin, dass Sie absolut sicher sein können, dass Sie den aktuellen (funktionierenden) Code erhalten. Wenn der Kunde mit der vorherigen D/D/A gebrochen hat, weil er eine bestimmte Aufgabe nicht erfüllen konnte, möchten Sie nicht mit Dateien arbeiten, die teilweise geändert wurden.
Neuinstallationen
Wenn Sie mit etwas wie einem CMS arbeiten, ist es oft eine gute Idee, eine Neuinstallation auf Ihrem Server durchzuführen und dann alle Vorlagen und Plugins zu kopieren und die Datenbank zu migrieren.
Frontend-Quellcode
Wenn es um die Beschaffung von Quellcode geht, ist Frontend-Code weitaus problematischer als Backend-Code.
[pullquote]Frontend-Code ist weitaus problematischer als Backend[/pullquote]
Wenn das vorherige D/D/A auch nur halbwegs kompetent ist, werden CSS und JavaScript auf dem Webspace minimiert. Minimiertes CSS ist nicht allzu problematisch und kann ziemlich einfach deminimiert werden, aber Sie möchten nicht die Auswahl einer minimierten JavaScript-Datei aufheben – ich hatte einmal ein Projekt, bei dem ein Entwickler seinen eigenen Code in derselben Datei mit all seinen Abhängigkeiten minimiert hatte. einschließlich Vue und jQuery [yes, I know]. Der Umgang mit Frontend-Quellcode kann eine zusätzliche Dimension erhalten, wenn Sie feststellen, dass die vorherigen D/D/A-Techniken verwendet wurden, die Sie nicht nutzen – die Verwendung von Less anstelle von Sass oder das Schreiben von Skripten in TypeScript.
Entminifizierung von CSS und JavaScript
Unminifying (oder verschönerndoder verschönernd)-Code ist einigermaßen einfach. Es gibt Online-Tools, die dabei helfen können, unter anderem Aufheben, Online-CSS-Unminifier, FreeFormatter, JS Minify Unminify, und mehr. Sie finden auch zahlreiche Erweiterungen für Code-Editoren, darunter HTML-CSS-JS verschönern für Sublime Text und Atom-Verschönern für Atom. Sie werden feststellen, dass einige Editoren über diese integrierte Funktionalität verfügen. Eine Warnung: Durch die Codeverschönerung werden Kommentare nicht wiederhergestellt und im Fall von JavaScript werden Variablennamen nicht entschlüsselt. Verschönernder Code ist kein Ersatz für eine Kopie des ursprünglichen, nicht verkleinerten Quellcodes.
Notfallmaßnahmen
Wenn das Aufheben der Verkleinerung des Quellcodes aus irgendeinem Grund nicht möglich ist oder, was wahrscheinlicher ist, das nicht verkleinerte JavaScript immer noch wie verkleinerter Code aussieht – wenn auch gut formatierter verkleinerter Code –, besteht Ihr letzter Ausweg darin, den Code zu importieren und ihn bei Bedarf zu überschreiben. Das erste, was Sie in diesem Fall tun müssen, ist, Ihrem Kunden die Situation zu erklären. Stellen Sie sicher, dass ihnen klar ist, dass es sich um einen temporären Patch handelt, den Sie ausbügeln, während Sie Teile des Projekts neu erstellen. Kopieren Sie dann den alten minimierten Code und fügen Sie ihn in ein neues Projekt-Setup ein. Für CSS bedeutet das wahrscheinlich das Erstellen eines Legacy.scss Datei, einschließlich des alten CSS, und importieren Sie sie in Ihr eigenes Sass. Erstellen Sie für JavaScript eine Legacy.js Datei, fügen Sie alle alten JS hinzu und importieren Sie diese. Dies führt dazu, dass Sie am Ende möglicherweise einen viel größeren Satz an Dateien verwenden, als nötig ist !wichtig in Ihren Stilerklärungen [yuck], und Sie werden viele Lighthouse-Warnungen über überschüssigen Code auslösen. Für den wahrscheinlichen Fall, dass Ihr Kunde jedoch eine lange Liste von Änderungen hat, die er gestern live bringen wollte, erhalten Sie mit diesem schmutzigen Hack eine funktionierende Website, die Sie dann im Laufe der Zeit Stück für Stück neu erstellen können.
Vermögenswerte
Unter Assets versteht man normalerweise Bilder, und Bilder können normalerweise per FTP abgerufen werden. Gelegentlich – obwohl Bilddateien jetzt seltener Text enthalten – benötigen Sie die Quelldateien, um Änderungen an Bildern vorzunehmen. Ob der Kunde sie hat oder nicht oder ob der vorherige D/D/A sie herausgibt, hängt weitgehend von der Vereinbarung zwischen dem Kunden und dem vorherigen D/D/A ab. Die meisten Unternehmen sind sich der Bedeutung von Markenwerten einigermaßen bewusst, daher werden Sie wahrscheinlich feststellen, dass sie zumindest eine Kopie ihres Logos haben; Ob es sich um ein SVG oder ein JPG handelt, ist eine ganz andere Sache. Machen Sie ihnen klar, wie wichtig es für Sie ist, diese Dateien zu finden.
Code Dritter
Es kommt selten vor, dass man ein Projekt erhält, das nicht auf Code von Drittanbietern basiert. Dieser Code von Drittanbietern ist wahrscheinlich mit dem benutzerdefinierten Quellcode verknüpft und es ist eine zeitaufwändige Aufgabe, ihn zu entfernen. Es ist sehr wahrscheinlich, dass die vorherige D/D/A eine Bibliothek oder ein Framework verwendet hat, und angesichts der zunehmenden Anzahl davon ist es sogar noch wahrscheinlicher, dass die verwendete Bibliothek oder das verwendete Framework nicht die von Ihnen bevorzugte ist. Ob Sie sich dafür entscheiden, den Code zu entfernen und die vorherigen D/D/A-Abhängigkeiten nach Ihren eigenen Wünschen auszutauschen (normalerweise schneller auf lange Sicht), oder ob Sie sich dafür entscheiden, mit dem zu arbeiten, was Ihnen gegeben wird (normalerweise schneller auf kurze Sicht). ) liegt ganz bei Ihnen. Meiner Erfahrung nach ist es kein Problem, sich eine andere CSS-Bibliothek anzuschaffen; Der Wechsel von einem JavaScript-Framework zu einem anderen ist eine wesentlich größere Aufgabe, die nicht nur die Syntax, sondern auch Kernkonzepte betrifft.
Vorsicht vor Build-Umgebungen
Jeder hat seine eigene Art, Dinge zu tun. Einige D/D/As unterstützen Build-Umgebungen, andere nicht. Einige Build-Umgebungen sind einfach zu verwenden, andere nicht. Einige Build-Umgebungen sind an Ihren Prozess anpassbar, andere nicht.
[pullquote]Im Gegensatz zur Einführung einer Bibliothek oder sogar eines Frameworks ist die Einführung eines neuen Build-Prozesses selten eine gute Idee[/pullquote]
Es gibt zahlreiche Build-Umgebungen – Gulp, Grunt und Webpack sind alle beliebt – und D/D/As auch fast Sie sind von ihnen genauso überzeugt wie von CMS. Anstelle von Rohdateien ist es nicht ungewöhnlich, dass der vorherige D/D/A Sie auffordert, „einfach diesen und jenen CLI-Befehl auszuführen“, um Ihre lokale Umgebung mit ihrer abzugleichen. Im Gegensatz zur Einführung einer Bibliothek oder sogar eines Frameworks ist die Einführung eines neuen Build-Prozesses selten eine gute Idee, da Sie sich vom Experten zum Anfänger degradieren und das zu einer Zeit, in der Sie das Vertrauen Ihres neuen Kunden noch nicht gewonnen haben. Steh deinen Mann. Ihr Ansatz ist gescheitert, deshalb wurden Sie eingezogen. Das tun Sie.
Wer ist lizenziert?
Jeder bezahlte Drittteilcode wird lizenziert. Überprüfen Sie immer, wer über diese Lizenzen verfügt. Für Updates, Fehlerbehebungen und in manchen Fällen auch für den Support sind gültige Lizenzen nicht nur gesetzlich vorgeschrieben, sondern in der Regel auch erforderlich. Zu den häufigsten Fallstricken gehören: Schriftartenlizenzen (die unter dem Creative Cloud-, Fontstand-, Monotype- usw.-Konto des vorherigen D/D/A lizenziert werden können); Stock-Bildlizenzen (die möglicherweise nur für die Nutzung durch den vorherigen D/D/A lizenziert werden); und Plugins (die häufig in Paketen an D/D/As massenhaft lizenziert werden). Es kommt deprimierend häufig vor, dass Kunden nicht lizenzierte Vermögenswerte nutzen. Mehr als einmal musste ich einem Kunden die möglichen Folgen der Verwendung von Raubkopien von Schriftarten erklären. Glücklicherweise kommt es immer häufiger vor, dass Drittanbieter einer bestimmten Domain eine Lizenz zuordnen, was bedeutet, dass Sie die Lizenz möglicherweise im Namen Ihres Kunden beanspruchen können. Große Anbieter wie CMS- und E-Commerce-Lösungen haben häufig die Möglichkeit, dass der vorherige Entwickler eine Lizenz freigibt und Sie diese beanspruchen können. Wenn Sie sich im Falle einer Lizenzierung nicht sicher sind, scheuen Sie sich nicht, sich an den Drittanbieter zu wenden und bei ihm nachzufragen, ob Ihr Kunde lizenziert ist, sobald er die Verbindung zu seinem vorherigen D/D/A abbricht. Das Einzige, was eine Kundenbeziehung schneller ruinieren kann, als ihnen zu sagen, dass sie eine Lizenz kaufen müssen, von der sie dachten, sie hätten sie bereits bezahlt, ist, ihnen mitzuteilen, dass sie wegen Urheberrechtsverletzung verklagt werden. Schützen Sie Ihren Kunden und sich selbst, indem Sie sicherstellen, dass alles ordnungsgemäß lizenziert ist. Wenn Sie vom vorherigen D/D/A etwas in dieser Hinsicht schriftlich erhalten können, tun Sie es.
Wer verfügt über die Forschung und Analyse?
Einer der Hauptvorteile der Übernahme eines Standorts im Gegensatz zum Aufbau von Grund auf besteht darin, dass Sie über einen messbaren Satz standortspezifischer Daten verfügen, die Sie bei Ihrer Entscheidungsfindung unterstützen. Dies gilt nur, wenn Sie über die Daten verfügen. Bitten Sie daher darum, zum Analysekonto des Kunden hinzugefügt zu werden. Es besteht eine hohe Wahrscheinlichkeit, dass die vom vorherigen D/D/A durchgeführte Designforschung vom vorherigen D/D/A als internes Dokument und nicht als Ergebnis betrachtet wird. Erkundigen Sie sich bei Ihrem Kunden: Wenn er die Recherche bezahlt hat (ist das auf einer Rechnung angegeben?), dann hat er Anspruch auf eine Kopie.
Wir haben auch einen Blog…
Kunden neigen dazu, den Begriff „Website“ als Sammelbegriff für alles Digitale zu verwenden. Wenn Sie die Verantwortung für eine Website übernehmen, wird von Ihnen fast immer erwartet, dass Sie auch die Verantwortung für alle digitalen Dienste übernehmen, die der Kunde nutzt. Das bedeutet Newsletter-Dienste wie Mailchimp, Kundendienstkonten wie Intercom und WordPress-Blogs mit 227.000 Seiten, die sie im ersten Briefing vergessen haben zu erwähnen. Wiederholen Sie das Ganze Schritt 2 für jede zusätzliche App, Microsite, jedes Blog und alles andere, was der Kunde hat, es sei denn, der Kunde weist Sie ausdrücklich darauf hin, dies nicht zu tun.
Schritt 3: Der Punkt, an dem es kein Zurück mehr gibt
Bisher haben Sie den Kunden nicht gebeten, auf der gepunkteten Linie zu unterschreiben. Dieser gesamte Prozess ist Teil Ihrer Sorgfaltspflicht. Durch die Überprüfung dieser Dinge können Sie unvorhergesehene Probleme und potenzielle Kosten erkennen. Sind Sie an einen obskuren Build-Prozess gebunden? Müssen Sie das CMS neu lizenzieren? Müssen Sie alle Site-Assets neu erstellen?
[pullquote]Einige dieser Gespräche sind schwer zu führen, aber jetzt ist die Zeit dafür gekommen[/pullquote]
Wenn Zweifel bestehen, dass das Projekt komplexer ist als erwartet, führen Sie ein ehrliches Gespräch mit Ihrem Kunden – er wird Ihre Transparenz zu schätzen wissen und es zu schätzen wissen, dass Sie auf dem Laufenden gehalten werden. Jeder Kunde, der keinen Wert darauf legt, ein klares Bild davon zu haben, wofür er Sie bezahlt, ist kein Kunde, den Sie wollen. Einige dieser Gespräche sind schwer zu führen, aber der richtige Zeitpunkt dafür ist jetzt und nicht erst in drei Monaten. Dies ist der Punkt, an dem es kein Zurück mehr gibt. Von diesem Punkt an sind alle Probleme nicht mehr die vorherigen D/D/As, sondern Ihre.
Ändern Sie die Passwörter
Ändern Sie für jeden Dienst, den Sie nutzen, vom Newsletter-Login über das CMS-Login bis hin zu den FTP-Details, das Passwort. (Stellen Sie sicher, dass Sie den Kunden benachrichtigen.)
Richten Sie eine Staging-Site ein
Sie benötigen eine Staging-Site, damit Ihr neuer Kunde eine Vorschau der von Ihnen für ihn geleisteten Arbeit sehen kann. Richten Sie die Staging-Site sofort ein, bevor Sie Änderungen am Code vornehmen. Auf diese Weise erkennen Sie frühzeitig, ob Dateien fehlen oder Probleme mit den Dateien, die Sie haben, auftreten.
Ein Projekt erfolgreich umstellen
Wenn ein Kunde eine Website von Grund auf in Auftrag gibt, ist er voller Erwartungen. Die Tatsache, dass sie ihr vorheriges D/D/A verlassen und Sie aufsuchen, zeigt, dass ihre Erfahrung hinter ihren Hoffnungen zurückblieb. Sie haben jetzt einen Kunden mit realistischen – vielleicht sogar pessimistischen – Erwartungen. Sie haben einen Maßstab, an dem Ihre Arbeit objektiv gemessen werden kann. Wenn Probleme auftreten, was immer der Fall sein wird, versuchen Sie niemals, die Schuld dem vorherigen D/D/A zuzuschieben; Es war Ihre Aufgabe, den Stand der Dinge zu beurteilen, bevor Sie mit der Arbeit begannen. Wenn es ein Problem mit Altbeständen gibt, sollten Sie Ihren Kunden frühzeitig darauf aufmerksam gemacht haben. Wenn Sie aus den Fehlern der vorherigen D/D/A lernen, werden Sie das Projekt so schnell nicht an jemand anderen weitergeben.
Ausgewähltes Bild über Unsplash.
