Wie man aus der Ferne arbeitet und trotzdem der Beste ist

Veröffentlicht: 2022-03-11

Ryan Wilcox ist seit fast 10 Jahren als Remote-Mitarbeiter erfolgreich und arbeitet jetzt sowohl als Berater als auch als Entwickler für Unternehmen auf der ganzen Welt, sowohl als Toptal-Ingenieur als auch als Gründer seiner eigenen Firma. Derzeit arbeitet er Vollzeit für Fanzter, ein Unternehmen für Web- und iOS-Produkte.

Der Werkzeuggürtel des Telearbeiters

Der Start eines neuen Remote- oder Home-Work-Auftritts, sei es ein Vertragsprojekt oder ein Vollzeitjob, kann ein wenig einschüchternd sein, wenn Sie es gewohnt sind, Tag für Tag in ein Büro zu gehen.

Aber diese Art der Beschäftigung erfreut sich wachsender Beliebtheit, und einige sehr bemerkenswerte Unternehmen unterstützen sie.

Ich arbeite seit Jahren erfolgreich remote mit diesen Tools an Projekten unterschiedlicher Größenordnung und Dauer. Mit diesem Beitrag hoffe ich, einige der besten Praktiken aufzuzählen, die ich für die Arbeit in einer Vielzahl von Situationen aufgegriffen habe. Der Leitfaden für Remote- und Heimarbeit hier reicht von spezifischen Empfehlungen für Software und Hardware bis hin zu Tipps, wie Sie die Fristen Ihres Teams einhalten können.

Das Remote- oder Home Office-Setup

Ich kann gar nicht genug betonen, wie wichtig die richtige Büroeinrichtung ist. Es wird Sie sowohl produktiver machen als auch professioneller erscheinen lassen. Beispielsweise ist ein Headset entscheidend, um Echos bei Online-Gesprächen zu vermeiden; Kleine Dinge wie diese machen einen großen Unterschied, wenn Sie als Remote arbeiten.

Hier sind einige Tools für die Remote-Arbeit, die ich in meinem eigenen Home Office für unerlässlich halte:

  • Kopfhörer . Ich mag besonders kabelgebundene Headsets sehr, weil ihnen in kritischen Zeiten nicht der Akku ausgeht. Sie werden es viel tragen, also stellen Sie sicher, dass Sie etwas Bequemes haben. Ich habe zwei iMicro-Headsets: eines für meinen Schreibtisch und eines, das ich in meine Laptoptasche packe. Als Laptop-Taschen-Headset hat es zwei großartige Eigenschaften: Da es über USB mit Strom versorgt wird, muss ich mich nicht darum kümmern, die Batterien aufgeladen zu halten, und es ist sehr günstig zu ersetzen, wenn es in meiner Tasche kaputt geht. Eigentlich finde ich dieses spezielle Headset für lange Telefonkonferenzen etwas unbequem; Wenn Sie viele davon machen, dann empfehle ich das Corsair Vengeance 2000: ein komfortables, kabelloses Headset mit Akkufunktion, mit dem Sie den ganzen Tag arbeiten können. (Übrigens: keines davon sind Referral-Links.)
  • Ruhiger Ort zum Nachdenken , mit einer Tür, die sich schließt – besonders, wenn Sie mit anderen Menschen zusammenleben und besonders , wenn Sie eine Familie haben.
  • Stabile Internetverbindung oder gute Backup-Verbindung. Zum Beispiel habe ich DSL und habe Tethering auf meinem Telefon eingerichtet, wenn das DSL ausfällt. Wenn Sie ständig Skype-Probleme haben oder Anrufe abbrechen, werden Sie in den Augen anderer, die möglicherweise versuchen, mehrere entfernte Mitarbeiter zu verwalten, sowohl weniger zuverlässig als auch weniger professionell.
  • Skypen . Dies ist gut für Ad-hoc-Konferenzgespräche, Instant Messaging mit Kunden oder sogar das Erstellen von Chatrooms mit geringer Zeremonie.
  • SkypeOut , mit dem Sie Anrufe von Ihrem Telefon zu Skype-Kontakten entgegennehmen und tätigen können. Dies ist großartig, besonders wenn Sie nicht an Ihrem Computer sind und (Sie haben sich verrechnet, der Kunde hat einen Notfall usw.).
  • Wasserkocher . Manchmal möchte ich heißen Kaffee, aber ich möchte meinen Fluss nicht stören, um etwas zu bekommen.
  • Gallone Krug Wasser . Für den Wasserkocher oder zum Trinken. Für lange Programmiersitzungen oder lange Telefonkonferenzen.

Eine Darstellung einer idealen Remote- oder Home-Office-Einrichtung.

Einige davon klingen offensichtlich, aber Sie wären überrascht, wie viele Fernbedienungen hier nicht alle Kriterien erfüllen. Als Entwickler brauchen wir einen ruhigen Ort zum Nachdenken, ohne Unterbrechungen. Und als Remote-Mitarbeiter brauchen wir einen ruhigen Ort, an dem wir Konferenzgespräche, Meetings, Pair-Programming-Sitzungen usw. ohne Unterbrechung abhalten können. Nur auf der Couch zu arbeiten, ist wahrscheinlich keine gute langfristige Lösung für Remote-Work.

Software-Tools

Es gibt eine Reihe guter Softwaretools, die Ihre typische Entwicklungsumgebung ergänzen und Ihnen helfen, die Herausforderungen im Zusammenhang mit der Remote-Arbeit zu meistern. Hier sind ein paar, die mir wirklich gefallen:

  • AwayFind , das sich gut für dringende E-Mails eignet, insbesondere für Last-Minute-Nachrichten von einem Besprechungsteilnehmer, da es seine Nachrichten per SMS an Sie weiterleitet.
  • Zeitzonenkonverter für die Zusammenarbeit mit Kunden und Kollegen auf der ganzen Welt. Ich mag die Weltzeituhr von Time And Date, Every Time Zone, World Time Buddy oder The Time Now für eine zugänglichere Version für Sehbehinderte.
  • Chat/IRC-Räume für alle im Team. Dies könnte formell (z. B. ein Lagerfeuerraum) oder einfach ein Skype-Chatroom (im Keep It Simple, Silly)-Stil sein.
  • Bugtracker – das verdient einen eigenen Abschnitt, siehe unten.

Bestätigen Sie bei der Planung von Meetings immer beide Zeitzonen. Und wenn Sie eine Einladung erhalten, sollten Sie immer rückwärts rechnen und darauf achten, dass Sie auf die gleichen Zahlen kommen. Wenn das Meeting mehrere Zeitzonen umfasst, möchte ich auch die UTC-Zeit angeben. Da jeder seinen Offset von UTC kennen sollte, ist dies eine weitere Überprüfung, um sicherzustellen, dass alle auf derselben Seite sind.

Ich war vor ein paar Jahren in einem recht großen Rails-Team. Mehrere Teammitglieder arbeiteten zumindest zeitweise aus der Ferne, und die Teamkultur war, dass viel Arbeit abends erledigt wurde. Ich schlug vor, über den damaligen offiziellen Teamleiter einen Chatroom einzurichten und auf Campfire oder einen anderen kostenpflichtigen Chatdienst hinzuweisen. Mehrere Wochen vergingen, ohne dass etwas unternommen wurde, und ich beschloss, einen Skype-Chatroom nur mit den Entwicklern einzurichten, um meine Theorie zu testen, dass ein Chatroom eine Bereicherung für das Team wäre. Dieses Experiment erwies sich als sehr erfolgreich – so erfolgreich, dass wir einfach weiterhin den Skype-Chat anstelle einer anderen Lösung verwendeten. Dieser Skype-Chatroom war noch in Gebrauch, als ich das Projekt fast ein Jahr später verließ. Manchmal kann einfach die beste Option sein.

Später, während einer kritischen Frist für dasselbe Projekt, richteten wir einen Skype-Chatroom ein, an dem die Entwickler, Business-Analysten, die Projektmanager und der Kunde teilnahmen, sodass Fragen schnell von der allgemeinen Gruppe angesprochen werden konnten. Obwohl nicht so aktiv wie der Chatroom nur für Entwickler, funktionierte er dennoch sehr gut. Skype-Chats können durch einige Gruppenchat-Befehle moderiert und gesteuert werden, Chat-Rollen festlegen und Zugriffsberechtigungen festlegen, wodurch Sie den Chatroom wirklich an Ihren Anwendungsfall anpassen können. Selbst ein so einfaches Setup kann die Remote-Produktivität verbessern.

Best Practices für Remote-Arbeit: Fehlerverfolgung

Ich möchte drei Dinge von einem Bug-Tracker wissen, den ich verwende:

  • Woran arbeite ich gerade?
  • Was habe ich für die nächste Version dieser Software auf meinem Teller?
  • Was sind die Leistungen des gesamten Teams für diese Version der Software?

Jedes davon hat einen Zweck.

Erstens: „Woran arbeite ich gerade?“: Wenn Sie in einem traditionellen Büro arbeiten, haben Sie Hintergrundgespräche – dies gibt Ihnen eine allgemeine Vorstellung davon, was alle anderen tun. Eine explizite Markierung im Bug-Tracker-System mit der Aufschrift „Ja, ich arbeite gerade aktiv daran“, kann ein ähnliches Muster und Gefühl für Remote-Arbeit einführen.

Zweitens: „Was habe ich für die nächste Veröffentlichung auf meinem Teller?“ bedeutet „Für welche Fehler bin ich verantwortlich“ oder „Welche Fehler behandle ich“. Sicherlich gibt es in jedem Team ein Hin und Her, aber es ist auch gut zu wissen, wen man fragen muss, wenn man sich einen Bug schnappen möchte oder Hilfe bei der Finalisierung seiner Bugs für die Veröffentlichung benötigt.

Es ist auch möglich, dass Ihr Team überhaupt nicht so arbeitet: Ihr Arbeitsablauf könnte beispielsweise so aussehen, dass jedem Entwickler zu Beginn nur ein Fehler zugewiesen wird und er den nicht zugewiesenen Stapel abholt, wenn sein einziger Fehler erledigt ist. Auch das kann produktiv sein.

Die „nächste Version der Software“ muss nichts Großes sein – ich war in Teams, in denen die „nächste Version“ bedeutete: „In 3 Tagen veröffentlichen wir einen neuen Alpha-Build für den Kunden “. Aber es ist immer noch gut für alle zu wissen, was in dieser neuen Version auf uns zukommt. Vor allem, wenn Sie nicht zugewiesene Tickets abholen, wenn Ihr aktuelles Ticket vollständig ist.

Ich habe am Ende des Beitrags einige Empfehlungen für bestimmte Bug-Tracker eingefügt.

Best Practices für Remote-Arbeit: Teamkommunikation

Für einige ist die Teamkommunikation der einschüchterndste Teil der Arbeit aus der Ferne oder von zu Hause aus. Aber das wird nur ein Problem sein, wenn Sie es zulassen .

Wenn Sie in einem Büro auf dem Weg zu Ihrem Platz an allen vorbeischlendern, gibt es ein bisschen Geplänkel, Leute sagen „Hallo“. Ihre Kollegen wissen, dass Sie bei der Arbeit sind, weil sie Sie dort drüben an Ihrem Schreibtisch bei der Arbeit sehen.

Remote-Mitarbeiter müssen etwas expliziter sein – niemand weiß, dass Sie arbeiten, es sei denn, Sie sagen es ihnen . Aber wenn Sie die richtigen Kommunikationspraktiken etablieren, sind Ihre Kollegen auf Knopfdruck verfügbar, anstatt durch das Büro zu schlendern, den Aufzug hinunter zu gehen usw.

Diese Tipps gelten eher für einen remote verwalteten Mitarbeiter als Teil eines größeren Teams, können aber nützlich sein, wenn Sie nur der einzige Entwickler sind.

Machen Sie Ihre Präsenz spürbar: Gehen Sie nicht unsichtbar

Ich habe einige dieser Ideen aus der Folge 48 des Wide Teams Podcast aufgegriffen.

Gehen Sie zu Beginn des Tages ins IRC (oder was auch immer Ihr Team verwendet) und sagen Sie „Hallo“ , chatten Sie darüber, wie die Tage der Leute verlaufen usw. usw. Auch wenn das bedeutet, ins IRC zu gehen und nach Kindern, Wochenenden, Sportteams oder Wochenend-Hacking. Wenn die Leute wissen, dass Sie gerade zu Hause fleißig arbeiten, werden Sie nicht unsichtbar. Bauen Sie eine Beziehung auf und lassen Sie die Leute wissen, dass Sie da sind .

Chatten Sie mit Leuten im Chat und stellen Sie sicher, dass Sie mit Ihren Kollegen in Kontakt bleiben. Dies ist anders, als wenn Sie im Café auf Leute treffen usw. usw. Sie müssen sich explizit melden und in Kontakt bleiben, damit die Leute bereit sind, wenn Sie Code schreiben oder Hilfe benötigen.

'Starttag', 'Mittagszeit' und 'Komm zurück' Nachrichten

Sie sollten nicht nur Ihre Anwesenheit bemerkbar machen, sondern auch Ihre Remote-Teamkollegen wissen lassen, wenn Sie nicht arbeiten. Genau wie in einem traditionellen Büro möchten Sie nicht für den Rest des Tages verschwinden und Ihre Kollegen hängen lassen.

Wenn Sie in einem Team mit mehreren anderen Entwicklern sind oder Remote-Mitarbeiter verwalten, ist es sinnvoll, zu Beginn Ihres Arbeitstages einzuchecken. Ein einfaches „Guten Morgen zusammen“, um die Leute wissen zu lassen, dass Sie bereit sind, mit der Arbeit an dem Projekt zu beginnen, und nicht mehr zu Hause oder im Bett.

Das Versenden von „Bin in 1 Stunde zurück“-Nachrichten für Mittags- oder Arbeitspausen während des Tages ist auch nett. Fernarbeit ist für viele Dinge großartig, aber ein besorgniserregendes Szenario ist, dass Sie Ihrem Kollegen eine Frage stellen und keine Antwort erhalten. Reagieren sie nicht, weil sie 30 Minuten weg sind? Oder weil sie tief in der Zone sind und dem Chat nicht zuhören? Vielleicht in einem Meeting? „Be back in…“-Nachrichten können diese Bedenken zerstreuen und den Arbeitsablauf glätten.

Wenn Sie mit dem Nachmittag fertig sind, lassen Sie die Leute wissen, wann Sie zurück sind. Vielleicht heißt es „Bis morgen früh“ oder „Komm heute Abend später wieder, um [x] fertig zu machen“. Aber wie die „Zurück in 1 Stunde“-Nachrichten setzen sie eine bestimmte Erwartung, an die sich Ihr Team anpassen kann.

Es gibt ein interessantes Startup namens Sqwiggle, das einige dieser Probleme lösen könnte (obwohl ich es selbst noch nicht ausprobiert habe). Zusätzlich dazu, dass alle paar Sekunden ein Foto von Ihnen gemacht wird, können Teammitglieder auch auf Ihr Bild klicken, um Video-/Audio-Chats zu starten, sowie eine Text-Chat-Komponente bereitstellen. Die Idee hinter dem Bild ist, auf einen Blick zu sehen, ob Sie an Ihrem Computer sitzen oder nicht. (Es gibt nichts Schlimmeres, als zu versuchen, online mit jemandem zu chatten und nicht schnell eine Antwort zu erhalten. Ist die Person mit etwas anderem beschäftigt? Tief in der Zone? Siehst du die Chat-Benachrichtigung nicht? Gerade im Badezimmer?). Ich habe in Episode 83 des Wide Teams Podcast von Sqwiggle gehört.

Über Projekte, in denen Sie die Best Practices einrichten können

Freiberufliche Gigs sind immer anders. (Das ist Teil des Reizes!) Manchmal werden Sie nur als Verstärkung in ein bestehendes Entwicklerteam aufgenommen. Vielleicht ist dieses Team schon seit einiger Zeit zusammen und hat in diesem Fall bereits Kommunikationspraktiken etabliert.

Andererseits sind Sie manchmal der einzige Entwickler im Projekt und arbeiten mit einem nicht technischen Kunden zusammen. Sie können Ihre eigenen Best Practices für die Softwareentwicklung einrichten und eine gewisse Kontrolle darüber haben, wie der Vorgang ausgeführt wird. Im Folgenden finden Sie einige Best Practices aus meiner etwa jahrzehntelangen Erfahrung in der Remote-Arbeit. Meistens sind diese auf halbwöchige (20 Stunden/Woche) oder ganze Wochenpläne (40 Stunden/Woche) ausgerichtet.

Standup-Meetings

Es spricht einiges dafür, Standup-Meetings abzuhalten, um über den Stand des Projekts zu sprechen. Diese sind in traditionellen Büros weit verbreitet, aber es gibt keinen Grund, warum sie für das Remote-Team nicht produktiv sein können: Sie sind nur eine weitere Möglichkeit, die Kommunikation zwischen den beiden Parteien zu erzwingen: Kunde und Entwickler.

Bei einem traditionellen Stehmeeting wird gefragt, woran Sie gestern gearbeitet haben, woran Sie heute arbeiten werden und ob es Hindernisse gibt. Dieses Format kann angesichts der Größe Ihres Teams funktionieren oder auch nicht: Wenn es sich um ein einzelnes Entwicklerprojekt handelt, machen diese eigentlichen Fragen keinen Sinn.

Wie oft Sie ein Standup-Meeting abhalten sollten, hängt wirklich von der Teamgröße und -kultur ab. Hier sind jedoch meine Empfehlungen:

  • 1-3 Entwickler: 2 Meetings im Standup-Stil pro Woche
  • 4+ Entwickler: tägliche Standup-Meetings

Bei 1-3 Entwicklern sind diese Fragen meistens selbstverständlich: Sie wissen, was jeder Entwickler tut, weil es einfach ist, seine individuelle Arbeit zu verfolgen, während sie sich durch Tickets pflügen: Jeder weiß, was jeder tut, weil es einfach nicht so viele Leute tun Arbeit.

Bei größeren Remote-Teams sind mehr Teile in Bewegung: Sie möchten sicherstellen, dass niemand jemandem auf die virtuellen Zehen tritt, indem er Arbeit repliziert oder inkompatible Änderungen vornimmt.

Angesichts der wöchentlichen Zahlungsstruktur von Toptal geben zwei Treffen pro Woche dem Kunden genügend Zeit, um Bedenken hinsichtlich des Projekts zu äußern, bevor er sich um einen Wochenpreis betrogen fühlt. Nur ein Treffen pro Woche könnte bedeuten, dass der Kunde mit der Qualität der Arbeit unzufrieden ist und der Entwickler keine Zeit hat, die Ergebnisse anzupassen.

Fortgeschrittene Remote-Teams haben möglicherweise andere Methoden, um alle Beteiligten auf dem gleichen Stand zu halten, ohne ein tatsächliches Meeting zu planen, während sie von zu Hause aus arbeiten. Ich mag es immer noch, mit jemandem zu telefonieren/skype/hängen und auf diese Weise ein Meeting zu haben.

Für kleine Teams funktionieren zwei Standup-Meetings pro Woche sehr gut: Kurskorrekturen sind schnell vorgenommen, aber die Entwickler haben bei jedem Meeting immer noch etwas Wesentliches zu berichten.

Bereitstellen der nächsten Version aus der Ferne

Abhängig von der Größe des Projekts möchte ich, dass die Ergebnisse für kleine (1-2 Entwickler) wöchentlich und für größere (3+ Entwickler) Projekte alle zwei Wochen an den Kunden gesendet werden. Dieser Rhythmus gibt Entwicklern genug Zeit, um beträchtliche Arbeitspakete fertigzustellen, einschließlich einer Benutzeroberfläche (oder einer verbesserten Benutzererfahrung), die der Client sehen kann.

Für technisch nicht versierte Kunden ist die einzige Metrik, anhand derer sie den Fortschritt messen können, das, was sie auf dem Bildschirm sehen.

Es ist wichtig, dass sich Entwickler daran erinnern, dass der Fortschritt, den Sie mit einer Benutzeroberfläche visualisieren können, oft das einzige ist, was für den Kunden zählt, insbesondere bei nicht technischen Kunden. Nicht-technische Kunden interessiert es nicht, dass Sie diese Woche 500 Codezeilen veröffentlicht haben oder dass Sie Schwierigkeiten hatten, mit einem Webdienst zu interagieren. Die einzige Metrik, anhand derer sie den Fortschritt messen können, ist das, was sie auf dem Bildschirm sehen können . Das soll nicht heißen, dass es irrelevant ist, gute Arbeit im Backend zu leisten, sondern dass Sie all diese gute Arbeit in den Augen des Kunden greifbar machen müssen.

Dieses Bild verdeutlicht die Bedeutung von Leistungen, insbesondere in einer Remote-Arbeitssituation.

Twittern

Aus diesem Grund mag ich wöchentliche oder zweiwöchentliche Lieferungen. Alles, was kürzer ist, bringt den Entwickler oft in eine schwierige Lage: Vielleicht stecken sie zwei Tage lang mit Backend-Arbeiten fest und haben keine Zeit, die Benutzeroberfläche fertigzustellen, also haben sie dem Kunden nichts zu zeigen .

Abhängig von der Art des Softwareprojekts werden nicht alle dieser Client-Releases für die Öffentlichkeit freigegeben. Wenn Sie beispielsweise an einem Rails-Projekt arbeiten, möchten Sie möglicherweise genehmigte Änderungen sofort bereitstellen. Auf der anderen Seite können Sie bei einer mobilen App eine Version „1.3a10“ nennen, aber die aktuelle Version ist nur ein Teil des größeren Funktionsumfangs einer neuen Version 1.3 der Software, die später bereitgestellt wird.

Hier kommen die Best Practices für Remote Bug Tracker ins Spiel. Beim Bugtracking weiß der Kunde:

  1. Was hat das Team für diese Leistung auf dem Teller?
  2. Wenn es abgeschlossen ist
  3. Wenn die Arbeit vom Kunden genehmigt wurde.

Der Kunde weiß, was er von dieser Version erwarten kann, und die Entwickler wissen, welche Arbeit vor ihnen liegt.

Wenn Ihr Remote-Team ausgereift genug ist, um Continuous Deployment und/oder Kanban zu verwenden, ist das in Ordnung. Dies sind jedoch beide sehr fortschrittliche Techniken, die eher für Organisationen mit einer starken, entwicklerbasierten Kultur geeignet sind. Die meisten Organisationen, in denen die Entwicklung kundenspezifischer Software als notwendig, aber kostspielig angesehen wird, sind wahrscheinlich für keine dieser Techniken bereit. Warum ist das? Zwei Dinge, die ich gesehen habe, sind, dass der Kunde nicht mit der Anzahl der Änderungen Schritt halten kann, die die Entwickler überprüfen lassen möchten , oder dass sich die Prioritäten zu schnell ändern, als dass die Entwicklung irgendetwas erledigen könnte .

Empfehlungen

Wenn Sie zufällig in ein Team kommen, in dem Sie die Best Practices etablieren, habe ich unten einige Tools für die Verwaltung Ihrer Remote-Arbeit aufgelistet. Denken Sie daran, dass dies nur meine Empfehlungen sind: Sicherlich ist dieser Leitfaden nicht für jeden geeignet; und wenn Ihnen diese Tools nicht gefallen, gibt es wahrscheinlich ein Tool, das Ihren Anforderungen besser entspricht.

  • Planscope.io im wöchentlichen Modus. Dies ist ein Zeit-Tracker + Bug-Tracker + Projektschätzungstool, das Kunden täglich E-Mails sendet, wenn Sie an ihrem Projekt arbeiten, und sie sehen lässt, wie die Dinge in Bezug auf Fortschritt und Budget laufen. Dies ist ideal für Projekte mit einer Größe von 1-4 Entwicklern/Monaten.
  • App Trajectory ist ein Bugtracker für kleine Teams mit Schwerpunkt auf der Schätzung und Aufteilung des Projekts in ein- bis zweiwöchige Abschnitte (Iterationen). App Trajectory kann Ihnen mitteilen, wie viel Arbeit Sie in einer Iteration erledigen und wie viele Iterationen bis alle bekannten Arbeiten abgeschlossen sind. Dies ist großartig für Projekte mit einer Größe von 2-12 Entwicklern/Monaten.
  • Pivotal Tracker ist ein Bug-Tracker-Tool für Kunden mit Schwerpunkt auf agilen Methoden. Dies ist großartig, wenn Sie formale agile Iterationen durchführen oder eine Projektgröße haben, die in Entwickler/Jahren gemessen wird.
  • FlowDock zum Chatten. Flowdock bietet einige Vorteile gegenüber einfachem IRC- oder Skype-Chat: Neben der Integration in beliebte Dienste können Sie Konversationen auch markieren, um später schnell darauf zugreifen zu können. FlowDock führt auch eine Liste von Statusaktivitäten (Code-Checkins usw.), die von allgemeinen Chats getrennt sind. (D. h. in der Weboberfläche befinden sich automatisierte Status-Updates auf der linken Seite, während Chats auf der rechten Seite stehen.)
  • Auch hier eignet sich Campfire auch hervorragend zum Chatten.

Fazit

Der Einstieg in die Remote- oder Heimarbeit kann eine ziemliche Umstellung sein, sowohl für Sie als auch für den Kunden. Ich habe es sehr richtig und sehr falsch gemacht. Aber wenn es richtig läuft, kann es für Kunden oder Arbeitgeber eine hervorragende Möglichkeit sein, das Problem der „Talentkrise“ zu lösen und eine breitere Palette von Möglichkeiten für Entwickler zu schaffen, die außerhalb der großen Technologiezentren oder „Startup“-Zentren leben. Durch die Remote-Zusammenarbeit von Entwicklern mit den richtigen Best Practices vor Ort kann eine ganze Welt der Effizienz gewonnen werden.