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

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

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

רעיונות

מקורות

ישנם 5 מקורות:

1. החבר העיקרי של מפתח מערכות מידע ארגוני הוא לקוח. והלקוח הוא דימוי קולקטיבי של מקבלי החלטות, נותני חסות לפרויקטים, בעלים ומבצעים של תהליכים, מומחי IT פנימיים, משתמשים רגילים ומספר רב של אנשים מתעניינים בדרגות שונות. חשוב לנו שכל אחד מנציגי הלקוח יהיה ספק פוטנציאלי של רעיונות. במקרה הגרוע, אנו מקבלים רק משוב שלילי על בעיות במערכת. במקרה הטוב, יש אדם בצד של הלקוח המהווה מקור קבוע לרעיונות לשיפור, המספק מידע מובנה על צרכי הלקוח.
2. שלנו אנשי מכירות ומנהלי חשבונות הם המקור השני בחשיבותו לרעיונות לשיפור. הם מתקשרים באופן פעיל ונרחב עם נציגי התעשייה ומקבלים פניות ממקור ראשון לגבי פונקציונליות החיוב מלקוחות פוטנציאליים. מוכרים וחשבונות צריכים להיות מודעים לכל השינויים המשמעותיים בפונקציונליות שלהם ולעדכונים האחרונים לתוכנות של מתחרים, ולהיות מסוגלים להצדיק את היתרונות והחסרונות של פתרונות שונים. אלו העובדים שלנו שהם הראשונים שחשו אם יכולות חיוב מסוימות הופכות לסטנדרט דה פקטו, שבלעדיו לא ניתן לראות שהתוכנה שלמה.
3. בעל המוצר - אחד מהמנהלים הבכירים שלנו או מנהל פרויקט מנוסה מאוד. שומרת על יעדים האסטרטגיים של החברה ומתאימה את תוכניות פיתוח המוצר בהתאם להן.
4. אדריכל, אדם שמבין את היכולות והמגבלות של הפתרונות הטכנולוגיים שנבחרו/נעשה בהם שימוש והשפעתם על פיתוח המוצר.
   צוותי פיתוח ובדיקות. אנשים שמעורבים ישירות בפיתוח מוצר.

סיווג בקשות

אנו מקבלים נתונים גולמיים ממקורות - מכתבים, כרטיסים, בקשות מילוליות. את כל
ערעורים מסווגים:

• ייעוץ עם המשמעות "איך עושים את זה?", "איך זה עובד?", "למה זה לא עובד?", "אני לא מבין...". בקשות מסוג זה עוברות לקו תמיכה ברמה 1. אפשר להכשיר את הייעוץ לסוגים אחרים של בקשות.
• תקריות עם המשמעות "לא עובד" ו"שגיאה". מעובד על ידי 2 ו-3 קווי תמיכה. אם יש צורך בתיקונים מהירים ושחרור של תיקון, ניתן להעביר אותם מהתמיכה ישירות לפיתוח. אפשר לסווג אותו מחדש כבקשת שינוי ולשלוח אותו ל-backlog.
• בקשות לשינויים ופיתוח. הם נכנסים לצבר המוצרים, עוקפים את קווי התמיכה. אבל יש הליך עיבוד נפרד עבורם.

יש סטטיסטיקה על בקשות: מיד לאחר השחרור, מספר הבקשות גדל ב-10-15% לזמן קצר. יש גם עליות בבקשות כאשר לקוח חדש עם מספר רב של משתמשים מגיע לשירותי הענן שלנו. אנשים לומדים להשתמש ביכולות תוכנה חדשות, הם צריכים עצות. גם לקוח קטן, כאשר מתחיל לעבוד במערכת, שורף בקלות יותר מ-100 שעות ייעוץ בחודש. לכן, בעת חיבור לקוח חדש, אנו תמיד שומרים זמן להתייעצויות ראשוניות. לעתים קרובות אנו אפילו בוחרים מומחה ספציפי. מחיר השכירות כמובן אינו מכסה את עלויות העבודה הללו, אך עם הזמן המצב מתאזן. תקופת ההסתגלות אורכת בדרך כלל בין חודש ל-1 חודשים, ולאחר מכן מצטמצם באופן משמעותי הצורך בייעוץ.

בעבר השתמשנו בפתרונות שנכתבו בעצמנו לאחסון בקשות. אבל עברנו בהדרגה למוצרי אטלסיאן. ראשית, העברנו פיתוח כדי שיהיה קל יותר לעבוד לפי Agile, ולאחר מכן תמיכה. כעת כל התהליכים הקריטיים חיים ב-Jira SD, בנוסף הם נתמכים על ידי תוספים שונים עבור Jira, בתוספת Confluence. פתרונות בכתב עצמי נותרו רק לתהליכים שאינם קריטיים לפעילות החברה. מסתבר שהמשימות שלנו כעת צולבות וניתן להעביר אותן בין תמיכה לפיתוח מבלי לקפוץ ממערכת אחת לאחרת.

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

עיבוד בקשות לשינוי

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

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

ניהול פונקציונליות המוצר

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

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

סיווג בקשות שינוי וכספים

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

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

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

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

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

דופים

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

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

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

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

מקור: www.habr.com