Sehen Sie, wie der Kunde RS21 und Gurus eigene Ingenieurteams Guru nutzen, um ihre Entwicklungsdokumentation zukunftssicher zu machen, einschließlich Prozessen und Vorlagen.
Alle Ingenieurteams sind auf eine Art von Dokumentationswerkzeug angewiesen, um wichtige Produktinformationen mit ihren Kollegen zu kommunizieren. Für kleine Teams, die gerade erst anfangen, kann dies so einfach sein wie ein Google-Dokument, und für größere Teams mit komplexen Produkten könnte dies ein hierarchisches Wiki sein. Abhängig davon, wie das Unternehmen strukturiert ist, können auch andere Teams (wie HR oder Marketing) dieses Wiki nutzen oder andere Bereiche haben, in denen sie die Informationen ihres Teams speichern.
Beim Beitritt zu einem neuen Ingenieurteam (entweder intern oder extern) ist der Einarbeitungsprozess entscheidend dafür, wie schnell ein neuer Kollege sich bereit fühlt, einen Beitrag zu leisten. Von der Einrichtung ihrer Programmierumgebung bis zur Durchsicht der Funktionsdokumentation gibt es viel, was nötig ist, um auf den aktuellen Stand zu kommen und bereit zu sein, neue Arbeiten zu übernehmen.
Für viele Ingenieurteams endet der Einarbeitungsprozess oft mühsam für einen anderen Kollegen, der als "Buddy" des neuen Mitarbeiters benannt wird und sie in Echtzeit durch diese Informationen führt. Aber indem die Führungskräfte von RS21 ihrem Team fachkundig geprüfte, aktuelle Karten in Guru zur Verfügung stellen, geben sie neuen Mitarbeitern die Flexibilität, in ihrem eigenen Tempo einzuarbeiten. Dadurch sparen sie Zeit mit ihrem Einarbeitungs-"Buddy" für den Aufbau interpersoneller Beziehungen oder um herausragende Fragen zu klären.
Wenn ein neuer Ingenieur dem Team von RS21 beitritt, loggt er sich in Guru ein, um mit seinen Einarbeitungsmaterialien zu beginnen. Sie sehen sich ein "Team-Info"-Board an, wo sie ein wenig über ihre Kollegen erfahren können, verwenden Infrastrukturkarten, um ihre Umgebungen korrekt einzurichten, und lesen die Programmierstandards ihres Teams durch, um sich vorzustellen, wie sie am besten mit ihren neuen Kollegen zusammenarbeiten können.
Ähnlich ist es bei Guru, wenn ein Ingenieur einem neuen Team beitritt oder in ein neues Team wechselt, wird die Einarbeitung in Guru durchgeführt. Sie verwenden Lebenslaufkarten, um sich mit ihren Kollegen bekannt zu machen, Leitfäden darüber, wie sie erwarten sollten, zusammenzuarbeiten, und durchsuchen die Sammlung ihres neuen Teams in Guru, um sich mit den Produktmerkmalen und Bereichen vertraut zu machen, für die sie jetzt verantwortlich sind.
Best Practices und Teamstandards
Sobald das gesamte Team eingearbeitet ist, haben auch fortlaufende Ressourcen wie Programmierstandards und Dokumentations-Best Practices ein Zuhause in Guru. Wenn sie auf eine Weise dokumentiert sind, die in ihren Arbeitsabläufen zugänglich ist, erleichtert das den Ingenieuren, produktiv mit dem Rest ihres Teams und dem gesamten Unternehmen zusammenzuarbeiten. Es verhindert auch, dass sie sich an Richtlinien oder Verfahren erinnern müssen oder schlimmer noch, dass sie veraltete Dokumente markieren und darauf angewiesen sind.
Die Ingenieursammlung von RS21 in Guru enthält ein Board, das den Prozessrichtlinien gewidmet ist, einschließlich Karten mit Anweisungen zum Zusammenführen von Code, Erstellen eines Bash-Skripts, Anfordern einer Codeüberprüfung und mehr. Sie haben auch Boards, die dem vereinbarten Programmierstil des Teams, Anweisungen zur AWS-Einrichtung, Informationen zum Systemadministrator und mehr gewidmet sind. Sie haben sogar häufig verwendete Code-Snippets für einfaches Kopieren und Einfügen in Guru-Karten verfügbar.
Neben diesen ingenieurtechnischen Karten ist Guru auch ein großartiger Ort für Ingenieure, um bereichsübergreifende Best Practices und Richtlinien für teamübergreifende Prozesse zuzugreifen. Zum Beispiel führt das Team von RS21 asynchrone Diskussionen mit Guru, um den Teammitgliedern mehr Zeit zu geben, um durchdacht zu antworten, und um allen eine gleichmäßige und faire Plattform zum Beitragen zu bieten. Anleitungen, wie man diese Diskussionen einrichtet und überwacht, werden in einer Guru-Vorlage aufbewahrt, damit jeder sie bei Bedarf einfach erstellen kann.
Bei Guru bitten wir Teams außerhalb unserer Produktentwicklungsorganisation, uns bei unserem Qualitätssicherungsprozess (QA) zu unterstützen. Mit unterschiedlichen Sichtweisen können wir besser Fehler erkennen, mögliche Herausforderungen von Kunden erkunden und sie vor der Veröffentlichung abwehren. Aber ein Prozess wie die QA erfordert dokumentierte Anweisungen und Verfahren, wenn bereichsübergreifende Teams einbezogen werden. Bevor wir mit der QA für ein neues Feature beginnen, verwendet ein Teamleiter der Ingenieure unsere QA-Prozessvorlage, um einen One-Stop-Shop für alles zu erstellen, was unser Team und die Stakeholder für die End-to-End-QA benötigen. Wenn wir bereit sind, die QA zu beginnen, senden sie dies als Ankündigung an das Team und die Stakeholder und fügen die aktiven QA-Daten in die Nachricht ein.
Projektplanung und Entwicklungsdokumentation
Jedes Mal, wenn ein neues Entwicklungsprojekt startet, folgt eine Menge Dokumentation, um sicherzustellen, dass alle den gesamten Kontext haben, den sie benötigen, um ihren Teil zu spielen. Nach einem Kickoff-Meeting sind die Ingenieure auf Anforderungsdokumente von Produktteams, die aktuellsten funktionalen Designs von ihrem UX-Team, Texte von ihrem Marketing- oder Copywriting-Team und mehr angewiesen.
Und natürlich müssen sie häufig auf alle technischen Dokumentationen zugreifen, die das Feature, an dem sie arbeiten, beeinflussen oder die sie später während der Entwicklung aktualisieren müssen.
Bei Guru verfolgen wir die verschiedenen Ressourcen, die für die Produktentwicklung benötigt werden, in einer Aktiven Projektressourcen-Karte, die von dem Ingenieur des jeweiligen Projekts begleitet wird. Diese Karten sind die wertvollste Ressource des Ingenieurteams in den frühen Phasen des Produktentwicklungszyklus und werden ständig aktualisiert, um alle Änderungen widerzuspiegeln.
Im Verlauf des Entwicklungsprozesses muss die Zusammenarbeit zwischen Ingenieurwesen und Design synchronisiert werden. Aber aufgrund der oft asynchronen und entfernten Natur der Arbeit können Designer und Ingenieure nicht immer einen Zoom-Anruf machen, um Probleme oder Feedback zu besprechen. Um sicherzustellen, dass sie unserem vereinbarten internen Protokoll für die Anforderung von Design-Feedback folgen, verwendet unser Ingenieurteam unser Design-Feedback-Workflow für UI-Änderungen, die in Guru dokumentiert sind.
Zukunftssichere Dokumentation
Dokumentation war schon immer und wird immer ein notwendiger Teil der Arbeit eines Ingenieurs sein. Aber was einst schmerzhafte Seufzer und bedrückte Seufzer hervorrief, kann zu einem einfachen, natürlichen Teil ihres täglichen Lebens werden, wenn es direkt in ihren Workflow integriert wird. Gurus Browsererweiterung bringt Dokumentation direkt dahin, wo Ingenieure sie benötigen, anstatt sie zu zwingen, den Kontext zu wechseln, um darauf zuzugreifen, und kurze, von Experten geprüfte Karten nehmen den Druck von den langen Artikeln der Vergangenheit, die mühsam zu schreiben und noch schwerer zu pflegen waren. Warum die technische Schuld mit veralteter Dokumentation vergrößern, wenn man sie jetzt ganz einfach zukunftssicher machen kann? Beginnen Sie noch heute kostenlos.
Alle Ingenieurteams sind auf eine Art von Dokumentationswerkzeug angewiesen, um wichtige Produktinformationen mit ihren Kollegen zu kommunizieren. Für kleine Teams, die gerade erst anfangen, kann dies so einfach sein wie ein Google-Dokument, und für größere Teams mit komplexen Produkten könnte dies ein hierarchisches Wiki sein. Abhängig davon, wie das Unternehmen strukturiert ist, können auch andere Teams (wie HR oder Marketing) dieses Wiki nutzen oder andere Bereiche haben, in denen sie die Informationen ihres Teams speichern.
Beim Beitritt zu einem neuen Ingenieurteam (entweder intern oder extern) ist der Einarbeitungsprozess entscheidend dafür, wie schnell ein neuer Kollege sich bereit fühlt, einen Beitrag zu leisten. Von der Einrichtung ihrer Programmierumgebung bis zur Durchsicht der Funktionsdokumentation gibt es viel, was nötig ist, um auf den aktuellen Stand zu kommen und bereit zu sein, neue Arbeiten zu übernehmen.
Für viele Ingenieurteams endet der Einarbeitungsprozess oft mühsam für einen anderen Kollegen, der als "Buddy" des neuen Mitarbeiters benannt wird und sie in Echtzeit durch diese Informationen führt. Aber indem die Führungskräfte von RS21 ihrem Team fachkundig geprüfte, aktuelle Karten in Guru zur Verfügung stellen, geben sie neuen Mitarbeitern die Flexibilität, in ihrem eigenen Tempo einzuarbeiten. Dadurch sparen sie Zeit mit ihrem Einarbeitungs-"Buddy" für den Aufbau interpersoneller Beziehungen oder um herausragende Fragen zu klären.
Wenn ein neuer Ingenieur dem Team von RS21 beitritt, loggt er sich in Guru ein, um mit seinen Einarbeitungsmaterialien zu beginnen. Sie sehen sich ein "Team-Info"-Board an, wo sie ein wenig über ihre Kollegen erfahren können, verwenden Infrastrukturkarten, um ihre Umgebungen korrekt einzurichten, und lesen die Programmierstandards ihres Teams durch, um sich vorzustellen, wie sie am besten mit ihren neuen Kollegen zusammenarbeiten können.
Ähnlich ist es bei Guru, wenn ein Ingenieur einem neuen Team beitritt oder in ein neues Team wechselt, wird die Einarbeitung in Guru durchgeführt. Sie verwenden Lebenslaufkarten, um sich mit ihren Kollegen bekannt zu machen, Leitfäden darüber, wie sie erwarten sollten, zusammenzuarbeiten, und durchsuchen die Sammlung ihres neuen Teams in Guru, um sich mit den Produktmerkmalen und Bereichen vertraut zu machen, für die sie jetzt verantwortlich sind.
Best Practices und Teamstandards
Sobald das gesamte Team eingearbeitet ist, haben auch fortlaufende Ressourcen wie Programmierstandards und Dokumentations-Best Practices ein Zuhause in Guru. Wenn sie auf eine Weise dokumentiert sind, die in ihren Arbeitsabläufen zugänglich ist, erleichtert das den Ingenieuren, produktiv mit dem Rest ihres Teams und dem gesamten Unternehmen zusammenzuarbeiten. Es verhindert auch, dass sie sich an Richtlinien oder Verfahren erinnern müssen oder schlimmer noch, dass sie veraltete Dokumente markieren und darauf angewiesen sind.
Die Ingenieursammlung von RS21 in Guru enthält ein Board, das den Prozessrichtlinien gewidmet ist, einschließlich Karten mit Anweisungen zum Zusammenführen von Code, Erstellen eines Bash-Skripts, Anfordern einer Codeüberprüfung und mehr. Sie haben auch Boards, die dem vereinbarten Programmierstil des Teams, Anweisungen zur AWS-Einrichtung, Informationen zum Systemadministrator und mehr gewidmet sind. Sie haben sogar häufig verwendete Code-Snippets für einfaches Kopieren und Einfügen in Guru-Karten verfügbar.
Neben diesen ingenieurtechnischen Karten ist Guru auch ein großartiger Ort für Ingenieure, um bereichsübergreifende Best Practices und Richtlinien für teamübergreifende Prozesse zuzugreifen. Zum Beispiel führt das Team von RS21 asynchrone Diskussionen mit Guru, um den Teammitgliedern mehr Zeit zu geben, um durchdacht zu antworten, und um allen eine gleichmäßige und faire Plattform zum Beitragen zu bieten. Anleitungen, wie man diese Diskussionen einrichtet und überwacht, werden in einer Guru-Vorlage aufbewahrt, damit jeder sie bei Bedarf einfach erstellen kann.
Bei Guru bitten wir Teams außerhalb unserer Produktentwicklungsorganisation, uns bei unserem Qualitätssicherungsprozess (QA) zu unterstützen. Mit unterschiedlichen Sichtweisen können wir besser Fehler erkennen, mögliche Herausforderungen von Kunden erkunden und sie vor der Veröffentlichung abwehren. Aber ein Prozess wie die QA erfordert dokumentierte Anweisungen und Verfahren, wenn bereichsübergreifende Teams einbezogen werden. Bevor wir mit der QA für ein neues Feature beginnen, verwendet ein Teamleiter der Ingenieure unsere QA-Prozessvorlage, um einen One-Stop-Shop für alles zu erstellen, was unser Team und die Stakeholder für die End-to-End-QA benötigen. Wenn wir bereit sind, die QA zu beginnen, senden sie dies als Ankündigung an das Team und die Stakeholder und fügen die aktiven QA-Daten in die Nachricht ein.
Projektplanung und Entwicklungsdokumentation
Jedes Mal, wenn ein neues Entwicklungsprojekt startet, folgt eine Menge Dokumentation, um sicherzustellen, dass alle den gesamten Kontext haben, den sie benötigen, um ihren Teil zu spielen. Nach einem Kickoff-Meeting sind die Ingenieure auf Anforderungsdokumente von Produktteams, die aktuellsten funktionalen Designs von ihrem UX-Team, Texte von ihrem Marketing- oder Copywriting-Team und mehr angewiesen.
Und natürlich müssen sie häufig auf alle technischen Dokumentationen zugreifen, die das Feature, an dem sie arbeiten, beeinflussen oder die sie später während der Entwicklung aktualisieren müssen.
Bei Guru verfolgen wir die verschiedenen Ressourcen, die für die Produktentwicklung benötigt werden, in einer Aktiven Projektressourcen-Karte, die von dem Ingenieur des jeweiligen Projekts begleitet wird. Diese Karten sind die wertvollste Ressource des Ingenieurteams in den frühen Phasen des Produktentwicklungszyklus und werden ständig aktualisiert, um alle Änderungen widerzuspiegeln.
Im Verlauf des Entwicklungsprozesses muss die Zusammenarbeit zwischen Ingenieurwesen und Design synchronisiert werden. Aber aufgrund der oft asynchronen und entfernten Natur der Arbeit können Designer und Ingenieure nicht immer einen Zoom-Anruf machen, um Probleme oder Feedback zu besprechen. Um sicherzustellen, dass sie unserem vereinbarten internen Protokoll für die Anforderung von Design-Feedback folgen, verwendet unser Ingenieurteam unser Design-Feedback-Workflow für UI-Änderungen, die in Guru dokumentiert sind.
Zukunftssichere Dokumentation
Dokumentation war schon immer und wird immer ein notwendiger Teil der Arbeit eines Ingenieurs sein. Aber was einst schmerzhafte Seufzer und bedrückte Seufzer hervorrief, kann zu einem einfachen, natürlichen Teil ihres täglichen Lebens werden, wenn es direkt in ihren Workflow integriert wird. Gurus Browsererweiterung bringt Dokumentation direkt dahin, wo Ingenieure sie benötigen, anstatt sie zu zwingen, den Kontext zu wechseln, um darauf zuzugreifen, und kurze, von Experten geprüfte Karten nehmen den Druck von den langen Artikeln der Vergangenheit, die mühsam zu schreiben und noch schwerer zu pflegen waren. Warum die technische Schuld mit veralteter Dokumentation vergrößern, wenn man sie jetzt ganz einfach zukunftssicher machen kann? Beginnen Sie noch heute kostenlos.
Erleben Sie die Leistungsfähigkeit der Guru-Plattform aus erster Hand – machen Sie unsere interaktive Produkttour
.webp)
