כל צוותי ההנדסה סומכים על סוג כלשהו של כלי רישום כדי לתקשר מידע חשוב על המוצר עם העמיתים שלהם. צוותים קטנים שמתחילים, זה יכול להיות פשוט כמו מסמך גוגל, ובשביל צוותים גדולים עם מוצרים מורכבים, זה יכול להיות ויקי היררכי. תלוי איך החברה שלהם מסודרת, צוותים אחרים (כמו משאבי אנוש או שיווק) עשויים גם להשתמש בויקי הזה, או שיש להם אזורים אחרים בהם הם מאחסנים את המידע של הצוות שלהם.
כאשר מצטרפים לצוות הנדסה חדש (פנימית או חיצונית), תהליך ההכשרה הוא קריטי לקבוע כמה מהר עמית חדש מרגיש מוכן לתרום. מהגדרת סביבת הקוד שלהם ועד לקרוא תיעוד תכונה, יש הרבה מה שצריך כדי להיות מוכן ולקחת על עצמם עבודה חדשה.
עבור רבים מצוותי ההנדסה, תהליך ההכשרה מסתיים להיות מעיק עבור עמית אחר, שהוקצה להיות ״חבר״ של העובד החדש ויכול להדריך אותם במידע הזה בזמן אמת. אבל על ידי מתן לצוות שלהם כרטיסים מעודכנים, מאושרים על ידי מומחה ב-Guru, המנהיגים ההנדסיים של RS21 נותנים למגייסים החדשים גמישות להשתלבות בקצב שלהם. זה מאפשר להם לחסוך זמן עם “חבר” ההכשרה שלהם לצורך חיזוק הקשרים הבינאישיים או שאלותOutstanding .
כאשר מהנדס חדש מצטרף לצוות של RS21, הם נכנסים ל-Guru כדי להתחיל לעבוד עם החומרי ההכשרה שלהם. הם יסתכלו על לוח “מידע על הצוות” שבו הם יכולים להכיר את העמיתים שלהם, להשתמש בכרטיסי תשתית כדי להגדיר את הסביבות שלהם נכון ולקרוא את הסטנדרטים לקידוד של הצוות שלהם כדי להבין איך לשתף פעולה בצורה הטובה ביותר עם העמיתים החדשים שלהם.
באופן דומה, ב-Guru, כאשר מהנדס מצטרף או עובר לצוות חדש, ההכשרה שלהם מתבצעת ב-Guru. הם ישתמשו בכרטיסים של סיפור חיים כדי להכיר את העמיתים שלהם, לראות מדריכים על איך הם צריכים לצפות לעבוד יחד ולדפדף באוסף של הצוות החדש שלהם ב-Guru כדי להכיר את תכונות המוצר ואת התחומים להם הם אחראים כעת.
שיטות עבודה מומלצות וסטנדרטים לצוות
כשהצוות כולו משולב, משאבים מתמשכים, כמו סטנדרטים לקידוד ושיטות עבודה מומלצות לתיעוד, גם יש להם מקום ב-Guru. כשזה מתועד בצורה נגישה תוך כדי זרימות העבודה שלהם, זה מקל על מהנדסים לשתף פעולה ביעילות עם שאר הצוות שלהם ושאר החברה. זה גם מונע מהם להזדקק לזכור כל מדיניות או הליכי עבודה או גרוע מכך, לסמן ולהתבסס על מסמכים מיושנים.
אוסף ההנדסה של RS21 ב-Guru כולל לוח המוקדש להנחיות תהליך, כולל כרטיסים עם הוראות למיזוג קוד, יצירת סקריפט bash, בקשה לסקירת קוד ועוד. יש להם גם לוחות המוקדשים לסגנון התחביר שצוותם הסכים עליו, הוראות התקנה של AWS, מידע על מנהל המערכת ועוד. כדי להעביר שורות קוד שנעשה בהן שימוש תדיר זמינות להעתקה ולהדבקה קלה בכרטיסי Guru.
מלבד הכרטיסים הספציפיים להנדסה האלה, Guru הוא גם מקום מצוין עבור מהנדסים לגשת לשיטות עבודה מומלצות בין-פונקציונליות והנחיות להליכי צוות אינטר. לדוגמה, צוות RS21 עורך דיונים אסינכרוניים בעזרת Guru כדי לתת לחברי הצוות יותר זמן להגיב בכוונה, ולתת לכולם פלטפורמה שווה והוגנת לתרום. הוראות כיצד להקים ולנטר את הדיונים הללו נשמרות בתבנית Guru, כך שכל אחד יכול להתחיל אחד בקלות כשצריך.
ב-Guru, אנחנו מגייסים צוותים מחוץ לארגון הפיתוח שלנו כדי לסייע בתהליך בקרת האיכות (QA) שלנו. עם דעות מגוונות יותר, אנחנו מסוגלים טוב יותר לזהות בעיות, לחקור אתגרים פוטנציאליים של לקוחות ולמנוע זאת לפני השחרור. אבל תהליך טכני כמו QA דורש הוראות מתועדות והליכים כאשר מעורבים צוותים בין-פונקציונליים. לפני שמתחילים QA עבור תכונה חדשה, מנהיג צוות ההנדסה ישתמש בתבנית תהליך ה-QA כדי ליצור מרכז מידע לכל מה שהצוות שלנו והבעלי עניין זקוקים לו עבור QA מקצה לקצה. כאשר אנחנו מוכנים להתחיל QA, הם ישלחו זאת כהודעה לצוות ולבעלי העניין, ויכללו את תאריכי QA הפעילים במסר.
תכנון פרויקט ותיעוד פיתוח
כשהפרויקט החדש מתחיל, יש הרבה תיעוד שמלווה כדי להבטיח שכולם יהיו עם ההקשר המלא שהם צריכים כדי לשחק את תפקידם. לאחר פגישת השקה, המהנדסים סומכים על מסמכי דרישות מהצוותים המוצריים, העיצובים הפונקציונליים הכי עדכניים מהצוות UX שלהם, עותק מהצוות שיווק או כתיבה שלהם, ועוד.
וכמובן, הם יזדקקו לעיתים קרובות להתייחס לכל תיעוד טכני שמשפיע על התכונה שהם עובדים עליה, או שהם צריכים לעדכן מאוחר יותר במהלך הפיתוח.
ב-Guru, אנחנו עוקבים אחר המשאבים השונים הנדרשים לפיתוח מוצר בכרטיס משאבים של פרויקטים פעילים, שכולו בניהול המהנדס של כל פרויקט. הכרטיסים האלה הם המשאב המועדף של צוות ההנדסה מדי בשלבים הראשוניים של מחזור חיי פיתוח המוצר, ומעדכנים כדי לשקף כל שינוי במהלך התהליך.
כשאת תהליך הפיתוח מתקדם, שיתוף הפעולה בין ההנדסה לעיצוב צריך להישמר בקצב. אבל בשל תכונת העבודה הפנימית והמרוחקת, מעצבים ומהנדסים לא תמיד יכולים להתקשר בזום כדי לדבר על בעיות או משוב. כדי להבטיח שהם עוקבים אחרי הפרוטוקול הפנימי שלנו להנחיית משוב עיצוב, צוות ההנדסה שלנו משתמש בתהליך משוב עיצוב לשינויים בממשק המתועד ב-Guru.
תיעוד חסין לעתיד
תיעוד היה תמיד והוא תמיד יהיה חלק הכרחי מעבודתו של מהנדס. אבל מה שבעבר עורר גניחות כואבות ונשמות זועקות יכול להתרחש באופן פשוט וטבעי במהלך היום-יום של המהנדסים כאשר הוא מובא ישירות לזרימות העבודה שלהם. ההרחבה של דפדפן Guru מביאה את התיעוד ממש למקומות שמהנדסים צריכים את זה, במקום להכריח אותם לעבור הקשר כדי לגשת אליו, וכרטיסים קצרים, מאושרים על ידי מומחה, מקלים על הלחץ מהמאמרים הארוכים של פעם שהיו כאב לכתוב ואפילו יותר קשה לשמור. אז למה להכביד על חובות טכניות עם תיעוד מיושן כשאפשר בקלות לחסום את זה לעתיד עכשיו? התחילו היום בחינם.
כל צוותי ההנדסה סומכים על סוג כלשהו של כלי רישום כדי לתקשר מידע חשוב על המוצר עם העמיתים שלהם. צוותים קטנים שמתחילים, זה יכול להיות פשוט כמו מסמך גוגל, ובשביל צוותים גדולים עם מוצרים מורכבים, זה יכול להיות ויקי היררכי. תלוי איך החברה שלהם מסודרת, צוותים אחרים (כמו משאבי אנוש או שיווק) עשויים גם להשתמש בויקי הזה, או שיש להם אזורים אחרים בהם הם מאחסנים את המידע של הצוות שלהם.
כאשר מצטרפים לצוות הנדסה חדש (פנימית או חיצונית), תהליך ההכשרה הוא קריטי לקבוע כמה מהר עמית חדש מרגיש מוכן לתרום. מהגדרת סביבת הקוד שלהם ועד לקרוא תיעוד תכונה, יש הרבה מה שצריך כדי להיות מוכן ולקחת על עצמם עבודה חדשה.
עבור רבים מצוותי ההנדסה, תהליך ההכשרה מסתיים להיות מעיק עבור עמית אחר, שהוקצה להיות ״חבר״ של העובד החדש ויכול להדריך אותם במידע הזה בזמן אמת. אבל על ידי מתן לצוות שלהם כרטיסים מעודכנים, מאושרים על ידי מומחה ב-Guru, המנהיגים ההנדסיים של RS21 נותנים למגייסים החדשים גמישות להשתלבות בקצב שלהם. זה מאפשר להם לחסוך זמן עם “חבר” ההכשרה שלהם לצורך חיזוק הקשרים הבינאישיים או שאלותOutstanding .
כאשר מהנדס חדש מצטרף לצוות של RS21, הם נכנסים ל-Guru כדי להתחיל לעבוד עם החומרי ההכשרה שלהם. הם יסתכלו על לוח “מידע על הצוות” שבו הם יכולים להכיר את העמיתים שלהם, להשתמש בכרטיסי תשתית כדי להגדיר את הסביבות שלהם נכון ולקרוא את הסטנדרטים לקידוד של הצוות שלהם כדי להבין איך לשתף פעולה בצורה הטובה ביותר עם העמיתים החדשים שלהם.
באופן דומה, ב-Guru, כאשר מהנדס מצטרף או עובר לצוות חדש, ההכשרה שלהם מתבצעת ב-Guru. הם ישתמשו בכרטיסים של סיפור חיים כדי להכיר את העמיתים שלהם, לראות מדריכים על איך הם צריכים לצפות לעבוד יחד ולדפדף באוסף של הצוות החדש שלהם ב-Guru כדי להכיר את תכונות המוצר ואת התחומים להם הם אחראים כעת.
שיטות עבודה מומלצות וסטנדרטים לצוות
כשהצוות כולו משולב, משאבים מתמשכים, כמו סטנדרטים לקידוד ושיטות עבודה מומלצות לתיעוד, גם יש להם מקום ב-Guru. כשזה מתועד בצורה נגישה תוך כדי זרימות העבודה שלהם, זה מקל על מהנדסים לשתף פעולה ביעילות עם שאר הצוות שלהם ושאר החברה. זה גם מונע מהם להזדקק לזכור כל מדיניות או הליכי עבודה או גרוע מכך, לסמן ולהתבסס על מסמכים מיושנים.
אוסף ההנדסה של RS21 ב-Guru כולל לוח המוקדש להנחיות תהליך, כולל כרטיסים עם הוראות למיזוג קוד, יצירת סקריפט bash, בקשה לסקירת קוד ועוד. יש להם גם לוחות המוקדשים לסגנון התחביר שצוותם הסכים עליו, הוראות התקנה של AWS, מידע על מנהל המערכת ועוד. כדי להעביר שורות קוד שנעשה בהן שימוש תדיר זמינות להעתקה ולהדבקה קלה בכרטיסי Guru.
מלבד הכרטיסים הספציפיים להנדסה האלה, Guru הוא גם מקום מצוין עבור מהנדסים לגשת לשיטות עבודה מומלצות בין-פונקציונליות והנחיות להליכי צוות אינטר. לדוגמה, צוות RS21 עורך דיונים אסינכרוניים בעזרת Guru כדי לתת לחברי הצוות יותר זמן להגיב בכוונה, ולתת לכולם פלטפורמה שווה והוגנת לתרום. הוראות כיצד להקים ולנטר את הדיונים הללו נשמרות בתבנית Guru, כך שכל אחד יכול להתחיל אחד בקלות כשצריך.
ב-Guru, אנחנו מגייסים צוותים מחוץ לארגון הפיתוח שלנו כדי לסייע בתהליך בקרת האיכות (QA) שלנו. עם דעות מגוונות יותר, אנחנו מסוגלים טוב יותר לזהות בעיות, לחקור אתגרים פוטנציאליים של לקוחות ולמנוע זאת לפני השחרור. אבל תהליך טכני כמו QA דורש הוראות מתועדות והליכים כאשר מעורבים צוותים בין-פונקציונליים. לפני שמתחילים QA עבור תכונה חדשה, מנהיג צוות ההנדסה ישתמש בתבנית תהליך ה-QA כדי ליצור מרכז מידע לכל מה שהצוות שלנו והבעלי עניין זקוקים לו עבור QA מקצה לקצה. כאשר אנחנו מוכנים להתחיל QA, הם ישלחו זאת כהודעה לצוות ולבעלי העניין, ויכללו את תאריכי QA הפעילים במסר.
תכנון פרויקט ותיעוד פיתוח
כשהפרויקט החדש מתחיל, יש הרבה תיעוד שמלווה כדי להבטיח שכולם יהיו עם ההקשר המלא שהם צריכים כדי לשחק את תפקידם. לאחר פגישת השקה, המהנדסים סומכים על מסמכי דרישות מהצוותים המוצריים, העיצובים הפונקציונליים הכי עדכניים מהצוות UX שלהם, עותק מהצוות שיווק או כתיבה שלהם, ועוד.
וכמובן, הם יזדקקו לעיתים קרובות להתייחס לכל תיעוד טכני שמשפיע על התכונה שהם עובדים עליה, או שהם צריכים לעדכן מאוחר יותר במהלך הפיתוח.
ב-Guru, אנחנו עוקבים אחר המשאבים השונים הנדרשים לפיתוח מוצר בכרטיס משאבים של פרויקטים פעילים, שכולו בניהול המהנדס של כל פרויקט. הכרטיסים האלה הם המשאב המועדף של צוות ההנדסה מדי בשלבים הראשוניים של מחזור חיי פיתוח המוצר, ומעדכנים כדי לשקף כל שינוי במהלך התהליך.
כשאת תהליך הפיתוח מתקדם, שיתוף הפעולה בין ההנדסה לעיצוב צריך להישמר בקצב. אבל בשל תכונת העבודה הפנימית והמרוחקת, מעצבים ומהנדסים לא תמיד יכולים להתקשר בזום כדי לדבר על בעיות או משוב. כדי להבטיח שהם עוקבים אחרי הפרוטוקול הפנימי שלנו להנחיית משוב עיצוב, צוות ההנדסה שלנו משתמש בתהליך משוב עיצוב לשינויים בממשק המתועד ב-Guru.
תיעוד חסין לעתיד
תיעוד היה תמיד והוא תמיד יהיה חלק הכרחי מעבודתו של מהנדס. אבל מה שבעבר עורר גניחות כואבות ונשמות זועקות יכול להתרחש באופן פשוט וטבעי במהלך היום-יום של המהנדסים כאשר הוא מובא ישירות לזרימות העבודה שלהם. ההרחבה של דפדפן Guru מביאה את התיעוד ממש למקומות שמהנדסים צריכים את זה, במקום להכריח אותם לעבור הקשר כדי לגשת אליו, וכרטיסים קצרים, מאושרים על ידי מומחה, מקלים על הלחץ מהמאמרים הארוכים של פעם שהיו כאב לכתוב ואפילו יותר קשה לשמור. אז למה להכביד על חובות טכניות עם תיעוד מיושן כשאפשר בקלות לחסום את זה לעתיד עכשיו? התחילו היום בחינם.
חוויית הפלטפורמה של Guru מהלך ראשון – קח את סיור המוצר האינטראקטיבי שלנו
.webp)
