Подивіться, як клієнт RS21 і команди власних інженерів Guru використовують Guru, щоб підготувати свої документації розробки до майбутнього, включаючи процеси та шаблони.
Усі інженерні команди покладаються на якийсь інструмент документації для спілкування важливої інформації про продукт зі своїми колегами. Для маленьких команд, які тільки починають, це може бути так же просто, як Google Документ, а для більших команд з комплексними продуктами, це може бути ієрархічна вікі. В залежності від структури компанії, інші команди (як HR чи маркетинг) можуть також використовувати цю вікі або мати інші місця, де зберігають інформацію про свою команду.
Коли приєднуєтеся до нової інженерної команди (внутрішньо або зовнішньо), процес адаптації є критично важливим для визначення того, як швидко новий колега відчує готовність внести свій внесок. Від налаштування свого кодувального середовища до перегляду документації функцій, необхідно багато чого, щоб швидко адаптуватися та бути готовим взяти на себе нову роботу.
Для багатьох інженерних команд процес адаптації виявляється обтяжливим для ще одного колеги, який призначений «другом» нового співробітника і буде проводити їх через цю інформацію в реальному часі. Але, надаючи своїй команді експертно перевірені, актуальні картки в Guru, лідери інженерів RS21 дають новим співробітникам гнучкість адаптуватися у власному темпі. Це дозволяє їм зекономити час зі своїм «другом» по адаптації для більшої побудови міжособистісних відносин або обговорення нез'ясованих запитань.
Коли новий інженер приєднується до команди RS21, вони входять у Guru, щоб почати працювати з матеріалами для адаптації. Вони переглянуть «Дошку інформації про команду», де вони можуть дізнатись трохи про своїх колег, використовувати картки інфраструктури для правильного налаштування своїх середовищ і прочитати стандарти кодування своєї команди, щоб зрозуміти, як найкраще співпрацювати зі своїми новими колегами.
Аналогічно, в Guru, коли інженер приєднується до нової команди або переходить до нової команди, їх адаптація відбувається в Guru. Вони використовують картки життєвих історій, щоб познайомитися зі своїми колегами, бачити посібники з очікувань роботи разом і переглядати колекцію своєї нової команди в Guru, щоб ознайомитися з функціями продукту та сферами, за які вони тепер відповідають.
Найкращі практики та стандарти команди
Коли вся команда пройшла адаптацію, постійні ресурси, як стандарти кодування та найкращі практики документації, також мають своє місце в Guru. Коли вони документуються таким чином, що є доступним у їхніх робочих процесах, це полегшує інженерам плідно співпрацювати з рештою команди та рештою компанії. Це також запобігає необхідності запам'ятовувати будь-які політики чи процедури, і, тим гірше, закладати закладки на застарілі документи.
Колекція інженерії RS21 в Guru включає Дошку, присвячену процесу, включаючи картки з інструкціями для злиття коду, створення bash-скриптів, запиту на рецензію коду та інших. Вони також мають Дошки, присвячені узгодженому стилю синтаксису коду команди, інструкціям налаштування AWS, інформації про системного адміністратора та інших. Вони навіть мають часто використовувані фрагменти коду, доступні для простого копіювання та вставлення в картки Guru.
Окрім цих специфічних карток для інженерії, Guru також є чудовим місцем для інженерів отримувати крос-функціональні найкращі практики та вказівки для процесів між командами. Наприклад, команда RS21 проводить асинхронні обговорення, використовуючи Guru, щоб дати членам команди більше часу для обдумування відповідей і щоб усім надати рівну та справедливу платформу для внесення внеску. Інструкції для налаштування та моніторингу цих обговорень зберігаються в шаблоні Guru, щоб будь-хто міг легко створити один, коли це необхідно.
В Guru ми залучаємо команди поза нашою організацією розробки продукту, щоб допомогти з нашим процесом забезпечення якості (QA). З більшою різноманітністю поглядів ми краще можемо виявляти помилки, досліджувати можливі проблеми для споживачів і захищати себе від них до випуску. Але процес, такий як QA, вимагає документованих інструкцій та процедур, коли залучаються міжфункціональні команди. Перед початком QA для нової функції, керівник інженерної команди використовує наш шаблон кваліфікаційного процесу, щоб створити все в одному місці для всіх Ressourcen, які наша команда та учасники потребуватимуть для завершення QA. Коли ми готові розпочати QA, вони відправлять це як анонс до команди та учасників, включивши активні дати QA в повідомлення.
Планування проекту та документація з розробки
Щоразу, коли розпочинається новий проект розробки, за ним слідує безліч документації, щоб забезпечити всім повний контекст, необхідний для виконання їхньої частини. Після стартової наради, інженери покладаються на документи вимог від команд продукту, найсвіжіші функціональні дизайни від їх команди UX, копії з їх команди маркетингу чи копірайтингу та інші.
І, звичайно, їм часто потрібно звертатися до будь-якої технічної документації, яка впливає на функцію, над якою вони працюють, або яку їм потрібно буде оновити пізніше на етапі розробки.
В Guru ми ведемо облік різних ресурсів, необхідних для розробки продукту, в картці активних проектів, яку представляє лідер технологій кожного проекту. Ці картки є основним ресурсом інженерної команди на ранніх етапах циклу розробки продукту і є актуальними, щоб відображати будь-які зміни.
Оскільки процес розробки прогресує, співпраця між інженерією та дизайном повинна залишатися злагодженою. Але через часто асинхронний і віддалений характер роботи, дизайнери та інженери не завжди можуть зідзвонитися через Zoom, щоб обговорити будь-які проблеми чи відгуки. Щоб переконатися, що вони дотримуються узгодженого внутрішнього протоколу для запиту дизайну відгуків, наша інженерна команда використовує наш Відгуки дизайну для змін UI, документовані в Guru.
Документація, готова до майбутнього
Документація завжди була і завжди буде необхідною частиною роботи інженера. Але те, що раніше викликало болісні стогінь та гіркі зітхання, може стати простою, природною частиною їхнього повсякденного життя, коли це безпосередньо інтегроване в їх робочий процес. Розширення браузера Guru приносить документацію прямо до місць, де її потребують інженери, замість того, щоб змушувати їх переключатися, щоб отримати доступ до неї, і короткі, експертно перевірені картки знімають тягар з довгих статей минулого, які було важко написати і ще важче підтримувати. Тож навіщо накопичувати технічний борг застарілою документацією, коли ви можете легко підготувати її до майбутнього прямо зараз? Почніть безкоштовно сьогодні.
Усі інженерні команди покладаються на якийсь інструмент документації для спілкування важливої інформації про продукт зі своїми колегами. Для маленьких команд, які тільки починають, це може бути так же просто, як Google Документ, а для більших команд з комплексними продуктами, це може бути ієрархічна вікі. В залежності від структури компанії, інші команди (як HR чи маркетинг) можуть також використовувати цю вікі або мати інші місця, де зберігають інформацію про свою команду.
Коли приєднуєтеся до нової інженерної команди (внутрішньо або зовнішньо), процес адаптації є критично важливим для визначення того, як швидко новий колега відчує готовність внести свій внесок. Від налаштування свого кодувального середовища до перегляду документації функцій, необхідно багато чого, щоб швидко адаптуватися та бути готовим взяти на себе нову роботу.
Для багатьох інженерних команд процес адаптації виявляється обтяжливим для ще одного колеги, який призначений «другом» нового співробітника і буде проводити їх через цю інформацію в реальному часі. Але, надаючи своїй команді експертно перевірені, актуальні картки в Guru, лідери інженерів RS21 дають новим співробітникам гнучкість адаптуватися у власному темпі. Це дозволяє їм зекономити час зі своїм «другом» по адаптації для більшої побудови міжособистісних відносин або обговорення нез'ясованих запитань.
Коли новий інженер приєднується до команди RS21, вони входять у Guru, щоб почати працювати з матеріалами для адаптації. Вони переглянуть «Дошку інформації про команду», де вони можуть дізнатись трохи про своїх колег, використовувати картки інфраструктури для правильного налаштування своїх середовищ і прочитати стандарти кодування своєї команди, щоб зрозуміти, як найкраще співпрацювати зі своїми новими колегами.
Аналогічно, в Guru, коли інженер приєднується до нової команди або переходить до нової команди, їх адаптація відбувається в Guru. Вони використовують картки життєвих історій, щоб познайомитися зі своїми колегами, бачити посібники з очікувань роботи разом і переглядати колекцію своєї нової команди в Guru, щоб ознайомитися з функціями продукту та сферами, за які вони тепер відповідають.
Найкращі практики та стандарти команди
Коли вся команда пройшла адаптацію, постійні ресурси, як стандарти кодування та найкращі практики документації, також мають своє місце в Guru. Коли вони документуються таким чином, що є доступним у їхніх робочих процесах, це полегшує інженерам плідно співпрацювати з рештою команди та рештою компанії. Це також запобігає необхідності запам'ятовувати будь-які політики чи процедури, і, тим гірше, закладати закладки на застарілі документи.
Колекція інженерії RS21 в Guru включає Дошку, присвячену процесу, включаючи картки з інструкціями для злиття коду, створення bash-скриптів, запиту на рецензію коду та інших. Вони також мають Дошки, присвячені узгодженому стилю синтаксису коду команди, інструкціям налаштування AWS, інформації про системного адміністратора та інших. Вони навіть мають часто використовувані фрагменти коду, доступні для простого копіювання та вставлення в картки Guru.
Окрім цих специфічних карток для інженерії, Guru також є чудовим місцем для інженерів отримувати крос-функціональні найкращі практики та вказівки для процесів між командами. Наприклад, команда RS21 проводить асинхронні обговорення, використовуючи Guru, щоб дати членам команди більше часу для обдумування відповідей і щоб усім надати рівну та справедливу платформу для внесення внеску. Інструкції для налаштування та моніторингу цих обговорень зберігаються в шаблоні Guru, щоб будь-хто міг легко створити один, коли це необхідно.
В Guru ми залучаємо команди поза нашою організацією розробки продукту, щоб допомогти з нашим процесом забезпечення якості (QA). З більшою різноманітністю поглядів ми краще можемо виявляти помилки, досліджувати можливі проблеми для споживачів і захищати себе від них до випуску. Але процес, такий як QA, вимагає документованих інструкцій та процедур, коли залучаються міжфункціональні команди. Перед початком QA для нової функції, керівник інженерної команди використовує наш шаблон кваліфікаційного процесу, щоб створити все в одному місці для всіх Ressourcen, які наша команда та учасники потребуватимуть для завершення QA. Коли ми готові розпочати QA, вони відправлять це як анонс до команди та учасників, включивши активні дати QA в повідомлення.
Планування проекту та документація з розробки
Щоразу, коли розпочинається новий проект розробки, за ним слідує безліч документації, щоб забезпечити всім повний контекст, необхідний для виконання їхньої частини. Після стартової наради, інженери покладаються на документи вимог від команд продукту, найсвіжіші функціональні дизайни від їх команди UX, копії з їх команди маркетингу чи копірайтингу та інші.
І, звичайно, їм часто потрібно звертатися до будь-якої технічної документації, яка впливає на функцію, над якою вони працюють, або яку їм потрібно буде оновити пізніше на етапі розробки.
В Guru ми ведемо облік різних ресурсів, необхідних для розробки продукту, в картці активних проектів, яку представляє лідер технологій кожного проекту. Ці картки є основним ресурсом інженерної команди на ранніх етапах циклу розробки продукту і є актуальними, щоб відображати будь-які зміни.
Оскільки процес розробки прогресує, співпраця між інженерією та дизайном повинна залишатися злагодженою. Але через часто асинхронний і віддалений характер роботи, дизайнери та інженери не завжди можуть зідзвонитися через Zoom, щоб обговорити будь-які проблеми чи відгуки. Щоб переконатися, що вони дотримуються узгодженого внутрішнього протоколу для запиту дизайну відгуків, наша інженерна команда використовує наш Відгуки дизайну для змін UI, документовані в Guru.
Документація, готова до майбутнього
Документація завжди була і завжди буде необхідною частиною роботи інженера. Але те, що раніше викликало болісні стогінь та гіркі зітхання, може стати простою, природною частиною їхнього повсякденного життя, коли це безпосередньо інтегроване в їх робочий процес. Розширення браузера Guru приносить документацію прямо до місць, де її потребують інженери, замість того, щоб змушувати їх переключатися, щоб отримати доступ до неї, і короткі, експертно перевірені картки знімають тягар з довгих статей минулого, які було важко написати і ще важче підтримувати. Тож навіщо накопичувати технічний борг застарілою документацією, коли ви можете легко підготувати її до майбутнього прямо зараз? Почніть безкоштовно сьогодні.
Досвідчіть силу платформи Guru особисто – пройдіть наш інтерактивний тур продуктом
.webp)
