top of page
Writer's pictureAyelet Melamed

How to develop a quality mindset across the R&D?

Updated: Jul 17, 2023


איכות היא לא רק טסטים, באגים או בקרה לפני שחרור קוד לפרודקשן, אך ברוב הארגונים, כשמדברים על איכות מתכוונים לזה.

מיינדסט של איכות, היא גישה חוצת צוותים שמתפתחת כשההסתכלות על איכות היא מתוך פרספקטיבת הלקו


ח והגדרתו למוצר או שירות איכותיים.

כשזה מתממש, בכל צוות ומחלקה מרגישים שאיכות היא ערך שמקבל ביטוי משמעותי בשיח הארגוני ובפוקוס, מרמת ההנהלה הבכירה ומטה. כשאיכות היא ערך, מדדי איכות הם חלק מהיעדים של כל הצוותים המשתתפים בתהליך הדליברי ובתקשורת עם הלקוחות, ותהליכי שיפור מתמיד גם הם חלק מהתרבות וההתנהלות.


מחקרים הוכיחו שמיינדסט זה הוא אחד ממנועי הצמיחה של הארגון - בהכנסות, בנתח שוק, בשימור לקוחות ובניית מונטין.


 

זאת פרספקטיבה שגם אם לא קיימת בארגון שלכם, תוכלו להשפיע על הדרך לייצר כזאת. בכך שהפוקוס שלכם הוא לא רק על ה- Execution במיקרו, אלא גם על איך זה מתחבר לארגון ולביזנס במאקרו, תפתחו את הקריירה שלכם, תייצרו לעצמכם עניין, אתגר וחשיפה גם מחוץ לארגון הפיתוח.


 

לא בכל ארגון זה פשוט לביצוע, ולהשפיע מחוץ לגבולות הגדרת התפקיד שרגילים אליו זה אתגר, אך זה יהיה לחלוטין שווה את זה אם אתם שואפים להתפתחות מקצועית, ארגונית או ניהולית בתחום שלכם, בארגון שלכם או מחוצה לו.

הנה כמה רעיונות לאיך תוכלו לדחוף לפיתוח מיינדסט כזה מחוץ לארגון ה- QA . כולם נכתבו מניסיוני בפועל כחלק מאסטרטגית האיכות לארגון:


1.תמחישו איך איכות נתפסת בעיניי הלקוח נכון להיום

תוודאו שיש מנגנון שמאפשר לאסוף ולנהל פידבקים מלקוחות ושהפידבקים מגיעים לכל המשתתפים בתהליך הפיתוח והדליברי - מפתחים, בודקים, מנהלי פרוייקטים, פרודקט.

הפידבקים יכולים להגיע דרך מחלקת ה- Customer Success , דרך ה- Support , המוצר עצמו או דרך צוות ייעודי שזה תפקידו. כשהפידבק מהלקוחות מגיע לכל השותפים בתהליך, נראה יותר שאלות לפני ביצוע ושמשתמשים בדאטה הקיים או שמשכללים אותו כדי להבין את ההשפעה של כל שלב בפיתוח על חווית הלקוח.

זה מחבר את כולם למחיר האיכות עד ללקוח ומחדד את השאלה אצלם - למה לקוחות שמים לב?

כשיש לארגון לקוחות, יש דרך לאסוף את המידע - לפנות ללקוחות בשאלות שביעות רצון ספציפיות למוצר ו/או לנתח את התלונות והדיווחים מכל המקורות. אלו למעשה הפידבקים. אם אין מספיק לקוחות, תוכלו לייצר משתמשי ביתא או כמו בדוגמא הבאה - להקים צוות:

לפני מס' שנים עבדתי בסטאראפ שפיתח מערכת חדשה להיתוך מידע עבור רשויות אכיפה כמו משטרה. כיוון שאף אחד בארגון בו עבדתי לא הגיע מרקע של חוקר במשטרה או שב"כ שהיו לקוחות המטרה שלנו, אז לא יכולנו לוודא שמה שפיתחנו אכן עומד בציפיות הלקוח בהיבט איכות וערך.

כמובילת איכות זה היה קריטי לדעת מה אנחנו בעצם בודקים, לכן בניתי צוות של חוקרים לשעבר שעבדו על המערכת לאחר שמידלנו לתוכה דאטה של פרשיות פשע אמיתיות. התובנות שצוות הפרודקט

והנהלת הארגון הפיקו בזכות הפידבקים האלו שינו את פני המוצר.

אם אנחנו רוצים להשפיע על המיינדסט נתחיל מפידבקים שממחישים את רמת האיכות והחוויה הנתפסת היום ובאותם כלים, נמשיך ונמדוד את השיפור.


2. כל מה שקורה בפרודקשן לא נשאר בפרודקשן


תמשיכו עם מה שמעניין את כולם ברמת הארגון - אירועי פרודקשן ואסקלציות מלקוחות.

יש ארגונים שבהם עושים הפקת לקחים, אך לא אוכפים את המסקנות.

תוודאו שלכל באג משמעותי שקורה בפרודקשן עושים (RCA (Root Cause Analysis ושמפרסמים אותו לרשימת תפוצה הרלוונטית. אם אין מי שיוזם RCA , תובילו אתם. אם אף אחד לא מוודא שהמסקנות אכן יושמו, כדאי שתהיו אתם אלו שמוודאים, ויחד איתכם, לכל אלו, תרתמו את מנהלי הפיתוח.

כדי להפנות את תשומת הלב של הפרודקט והפיתוח לאיכות מעבר לתכולה בכל ספרינט ועמידה בלוחות

זמנים, תוכלו לעשות Zoom-Out דרך אנליזה של הבאגים שהגיעו מפרודקשן לפי פילוחים שרלוונטיים למוצר שלכם כמו לקוחות, איזורים במוצר, גיאוגרפיות וכו'. קחו איתכם מישהו מצוות התמיכה, או ה- Customer success ואם אין שותף, רוצו על זה עם המנהלים שלכם ותגדירו איך תראה התוצאה ומה מחפשים.

אם כמות הלקוחות והטיקטים גבוהה, בחרו יחד כמה לקוחות אסטרטגיים, ותעשו את זה רק עבורם.


התוצאות יעזרו להשפיע על סדרי העדיפויות של הפרודקט והפיתוח ויתרמו לניהול סיכוני גרסא ותכנון בדיקות יעיל. אם תחזקו את הממצאים דרך הפידבקים מהלקוחות, זה יתקף את המסקנות משמעותית.

יש ארגונים שבהם המפתחים והמנהלים שמשחררים קוד לפרודקשן, הם לא אלו שמטפלים באסקלציות מהשטח באזור הקוד שלהם, אלא יש צוות אחר שמנטר את הפרודקשן החל מהרגע שהקוד שוחרר.

רמת החיבור והפוקוס של המפתחים למשמעות של איכות כפי שבאה לידי ביטוי אצל הלקוח, לא תהיה גבוהה בהגדרה.

לכם יש מנדט בתחום ה- QA , השפעה על מה קורה בפיתוח אך לא שליטה על מי יפתור איזו תקלה. התפקיד שלכם הוא לעורר למודעות, להציג את ההשפעות, ליזום פתרונות לשיפור והתייעלות גם אם קבוצה אחרת תממש אותם ובכל שלב - לשתף את המנהלים הישירים/עקיפים ולהראות למה כדאי לעשות את השינוי, ואיך זה יועיל להם. דרך נוספת ויעילה להשפיע היא להגדיר מדד איכות - לכמות אירועי הפרודקשן שמשפיעים על לקוחות.


כשרוצים לייצר מיינדסט חדש צריך לקנפג את הקיים.


3. תרחיבו את הגדרת האיכות מהמוצר ל- Quality of Service ואם רלוונטי גם ל- Quality of Data ותמדדו אותם מנקודת מבטו של הלקוח


מיינדסט כזה מתפתח מחוץ לארגון ה- QA קורה כשאנו עוזרים לממשקים שלנו להתמקד באיכות התהליך או השירות, הנה כמה דוגמאות:

לפני שחרור גרסא (גם אם אתם ב-Continues Delivery):

תגדירו אילו בדיקות הם חלק מה- Definition of Done של כל משימת פיתוח עבור המוצר ואת סט הבדיקות שירוץ לפני שהגרסה מגיעה ל- QA . כדאי להגדיר את שני הנושאים הללו, ביחד עם החברים בצוות פיתוח ולשדרג את התהליך תוך כדי תנועה, בכך גם משתפרת האיכות וגם מצטמצם הפינג-פונג בתקשורת עד לתחילת בדיקות.

אם איכות הדאטה (שלמות, נכונות, סנכרון, מגווןוכו') היא קריטית לפיתוח/בדיקות, תוודאו שיש בדיקות שמוודאות את זה כחלק מה- Pipeline.

אם בכל פעם אתם בודקים עם אותם נתונים את האלגוריתמים/מנועי ה-ML, תוודאו שגם הם איכותיים/מגוונים ומייצגים בכל מס' חודשים.

בזמן שחרור הגרסא:

אם רלוונטי עושים Gradual rollout לגרסאות חדשות, ובכל מקרה מי שפיתח הוא זה שמנטר את ההשפעה על הלקוחות ותומך בתקלות. נוודא כי יש תהליכי התאוששות מהירים במקרה של נפילות, מדידות של Down-Time , כמות Errors וסוגיהם.

לאחר שחרור הגרסא:

נוודא שיש SLA לתיקוני באגים קריטיים, הגדרה ברורה של מי מתקן ומתי פורסים תיקון ושיש מי שמודד/אוכף את ה- SLA הזה כדי לצמצם את הפגיעה באיכות השירות ללקוחות.


“Quality is not an act, it is a habit"


במשך שנים המשפט הזה של אריסטו, היה בחתימת המייל שלי ובכל מצגת שהעברתי. זה היה המשך ישיר של המסרים והפעולות שצלחו כי זה המאמץ היה עקבי אך גם כי כל השינויים קרו בהדרגה, בדיוק כמו שמפתחים הרגל ובכך גם האסטרטגיה התממשה.


אז איך מתחילים?

תבחרו משהו אחד, נקודה אחת מאלו שכתובות כאן או רעיון שעלה לכם בעקבות הקריאה, בכל רבעון ורק בה תתמקדו. בסיום, תלמדו ממנה על עצמכם ועל מה שהצליח ותתקדמו לבאה.


ספרו לי מה ניסיתם, במה התקשיתם, והכי חשוב - מה אתם לוקחים לנסות בארגון שלכם?

המאמר פורסם במגזין עולם הבדיקות בו אני כותבת את הטור שלי בשנה האחרונה " עושים QA לקריירה".

הטור, כמו המאמר, מסתמכים על הניסיון שלי ב-19 השנים האחרונות כמובילת צוותי וקבוצות פיתוח, דאטה ובעיקר QA ועל בסיס הליווי והאימון האישי שאני זוכה להוביל מול עשרות מנהלי איכות ופיתוח שמדלוורים כל יום קוד לעולם.

אם אצלך זה עובד אחרת -שתפו כאן וכולנו נזכה !






1 view0 comments

Comments


bottom of page