הרעיון פשוט: צרו מצגת חיובית של 5-10 דקות*** על אופן פעולת התהליך, ושלבו אותו בהדרכת הניהול של החברה שלנו. היינו משתמשים באותו החומר גם בתחילת הפרויקט. אנחנו רוצים להציב ציפיות סבירות להם ולנו כדי לשפר פרויקטים עתידיים. דברים כמו:
- פרויקטים חוזרים
- לעתים קרובות נדרשת חשיבה על הדרישות 4-7 פעמים לפני שדרישות סופיות טובות יסתדרו.
- אנחנו לא מצפים שהם יהיו מושלמים בפעם הראשונה
- אנו מערבים משתמשים עסקיים בשלב מוקדם של התהליך כך שיהיה מספיק זמן וללא לחץ להיות מושלם בניסיון הראשון.
- אלו הן שיחות ושיחות טלפון קצרות, שימושיות, נטולות ז'רגון. לא 4-7 פגישות משעממות של שעה
ברור שזה כדי למנוע בעיות נפוצות כמו:
- משתמשים עסקיים חוששים מתהליך מתן הדרישות כי הם חוששים מהז'רגון הטכני, חוששים שהם יתקעו בפגישות לנצח, ולא יודעים למה לצפות
- משתמשים עסקיים חושבים שהם יכולים פשוט לתת דרישה מעורפלת של 2 משפטים ולגרום לנו להשיג את זה בצורה קסומה ללא כל מחשבה נוספת מצידם
- מפתחים מתבכיינים כל הזמן על "הם שינו את הדרישות! למה הם לא נותנים לנו דרישות מושלמות שהם לעולם לא ישתנו???"
השאלות שלי אליכם: האם ראיתם את זה ניסה? אילו נקודות היו המועילות ביותר לחלוק עם משתמשים עסקיים כדי להכניס אותם למחשבה חיובית לגבי דרישות עסקיות? יש שיעורי "אל תעשה את זה ככה"?
*** אנחנו מאוד מבינים שזו תצטרך להיות מצגת חיובית שמתמקדת בעזרה והעצמתם, ולא יכולה להיות הרצאה-ככה-אנחנו-רוצים-שתעשה-עבורנו.
הדבר שאני מוצא את עצמי מלחיץ הכי הרבה הוא: ספר לי מה הבעיה שאתה מנסה לפתור ולמה, לא הפתרון שלך לה.
זה צריך להיות משהו שנלמד מהגן, שוב ושוב בכל רמה חינוכית. כל אחד טועה בזה על בסיס תדיר. "איך הולך לי איקס שלדעתי יפתור את הבעיה האמיתית שלי?"וולינבל אמר:הדבר שאני מוצא את עצמי מלחיץ הכי הרבה הוא: ספר לי מה הבעיה שאתה מנסה לפתור ולמה, לא הפתרון שלך לה.
לחץ להרחבה...
ובכן, מה שלך בעיה בפועל? ברגע שאדע את זה, אוכל לעזור לך להבין גם האם X אכן יפתור את הבעיה וגם האם ניתן ליישם אותה בצורה סבירה ואז להתייחס כיצד לעשות זאת.
זה גם עוזר לטפל בבעיה של העובדה שרוב האנשים אפילו לא באמת יודעים מה הבעיה האמיתית שלהם מלכתחילה.
לעתים קרובות הם פותרים את הבעיה הלא נכונה, וכשהם מציעים פתרון, זה לעתים קרובות הפתרון השגוי נוסף על הבעיה הלא נכונה.פלדין אמר:זה גם עוזר לטפל בבעיה של העובדה שרוב האנשים אפילו לא באמת יודעים מה הבעיה האמיתית שלהם מלכתחילה.
לחץ להרחבה...
אבל, לעתים קרובות הם מאוד גאים בכך ש"פתרו" את הבעיה בראש שלהם, ולפעמים זה דורש זהירות שיחה כדי לא לעצבן אותם כשאתה עובד בחזרה לפתרון מתאים יותר שזה בכלל לא מה שהם ביקשו ל.
כל הזמן. זה לא עובד.svdsinner אמר:השאלות שלי אליכם: האם ראיתם את זה ניסה? אילו נקודות היו המועילות ביותר לחלוק עם משתמשים עסקיים כדי להכניס אותם למחשבה חיובית לגבי דרישות עסקיות? יש שיעורי "אל תעשה את זה ככה"?
לחץ להרחבה...
איפשהו בתהליך, אתה צריך אנליסט עסקי. זה יכול להיות איש העסקים, המפתח או אדם שלישי לחלוטין. אבל זה דורש מיומנות תרגום שהיא שונה ממיומנות העשייה העסקית וממיומנות כתיבת הקוד.
ההצעה הטובה ביותר שראיתי כאן היא לגרום לאנשים לתאר בעיות, לא פתרונות. אם אתה יכול להשיג את זה במקום, אתה תהיה הרבה לפני המשחק.
אני אגיד, מצגת היא לחלוטין לא הדרך הנכונה לעשות זאת. התמודד עם זה בנפרד.
את רוב הקריירה שלי ביליתי ברפואה, ואני גורם לרוב המפתחים ותפקידי המוצר לבלות זמן מה במשרדי הרפואה. אתה צריך לדעת איך זה באמת, ומה באמת קורה. מטופלים שמגיעים לדלפק הקבלה בזמן שאתה בהמתנה עם חברת ביטוח, קווים אחרים מצלצלים בזמן שאתה עדיין בהמתנה, אנשים שיוצאים מאחור לשאול שאלות קידוד וכו'. התוכנה בהקשר הזה צריכה להיות מסוגלת להחליף הקשרים בקלות מבלי לאבד עבודה שלא נשמרה ומבלי להשאיר אותך עם מערך של חלונות שהשארת פתוחים ולא זוכר למה. למסך מודאלי עם אפשרויות שמירה או ביטול בלבד אין הבנה בעולם שלו, אבל זה נפוץ באופן מפתיע בתוכנות זמינות המיועדות לשימוש מסוג זה. כל מיני רשומות נכונות רק חלקית מכיוון שהם נאלצו לשמור ולסגור לבצע את ההפרעה משימה, והם שוב נקטעו ולא חזרו למקור, אז ככה זה נשאר בפעם האחרונה, למרות שזה לא ימין.
הו, הייתי שם הרבה פעמים. וכתוצאה מכך אני לא יכול להגיד להם אם מה שהם ביקשו מאיתנו לעצב הולך לעבוד עבורם. אבל הם התנדבו לקבל את הבעיה הזו, אז...curih אמר:כיף במיוחד בעולם ההגנה שבו התגובה היא לעתים קרובות "אנחנו לא יכולים להגיד לך"
לחץ להרחבה...
אבל הם לא מתסכלים אותי כמו אנשים שפשוט לא מוכנים לבזבז את המשאבים כדי לעשות דברים כמו שצריך דרך שתהיה קטנה, זולה, יעילה ואמינה מכיוון שהם כבר הוכיחו דרך שאינה אחת מאלה דברים.
באמת, כל פרויקט יכול להיות שונה, אז אני לא חושב שאפשר להגדיר גישה מתאימה לכולם לניהול פרויקטים. כמו כן, אם אתה מספק דברים בקטנה עובד נתחים, אתה מפחית את הסיכונים ו... בכנות, לא כל "לקוח" מיומן בתיאור מה שהם רוצים על פיסת נייר ריקה - אבל הם טובים בלהסתכל על משהו ולהגיד לך מה צריך לשנות.
אני מוצא את "פורמט Connextra" (כ
... באמת, IMHO, אתה צריך אדם שיכול להיות בעל מוצר טוב - מכיר את העסק, אינו אידיוט ויכול לתקשר. ולאדם הזה יש "כוח"/"מכובדות" לקבל החלטות. אם אינך מוצא אדם כזה, מצא את מי שבעל הכוח ישמח להאציל לו. אחרת, הוא דפוק.
(ותן לי לחזור ולהדגיש. לאדם זה אין כל סמכות בהחלטות ביצוע. אדם זה יכול לדבר, אבל האנשים שכותבים את הקוד מקבלים את החלטות היישום. בעל המוצר מחליט מה צריך לעשות; צוות הפיתוח עושה את הדברים בדרך שהם חושבים שהם צריכים לעשות את זה.)
בתור התחלה ל-PO יש, כנציג של הארגון הגדול יותר, כוח קבלת החלטות כדי לממש את היעדים הרחבים יותר שניתנו להם.
תואר ראשון שמדבר עם בעל עניין יכול לחשוב "זה רעיון ממש טוב", או "בזמן שאני מבין מה בעל העניין רוצה להשיג, אני לא חושב שזה מתאים למה החברה שואפת להשיג את הפרויקט הזה", או "זה היה רעיון נחמד, אבל בהתבסס על הערכות נקודת סיפור אני לא חושב שזה שווה את העלות", אבל הם לא מצליחים לעשות את הַחְלָטָה.
ה-PO, לעומת זאת, זוכה לקבל החלטות מסוג זה; למען האמת, אם הם לא עושים את זה באופן קבוע, הם גם א) לא עושים את העבודה שלהם כמו שצריך ו/או ב) אתה עושה Scrumbut/משהו אחר שמתחפש ל-Scrum
תפקיד המתרגם מבאס ומוביל לכל מיני בזבוז זמן ובעיות. אתה מסיים עם פי שניים את השיחות בתוספת אובדן מידע.
תוכנה ברבים מהתחומים האלה משקפת את זה.KD5MDK אמר:השגת לידים שמבינים במכירה לטלקום ענק, חוק המס הברזילאי, ביטוח בתחומי שיפוט שונים ותקנות פרטיות מחוץ ל-GDPR היא מאתגרת ביותר. אנו נאלצים לפנות לעסק כדי להגדיר דרישות.
לחץ להרחבה...
יש מקום לתפקיד BA, אבל גם במקומות שבהם הם נחוצים, הלידים שלך צריכים להיות בשיחות האלה. יותר מדי מידע הולך לאיבוד אחרת. לא משנה כמה תכתוב במפרט.