שאלה ״דיפלומטית״

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

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

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

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

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

העניין הוא שאני מרגישה במצב של damned if you do and damned if you don't - אם אני מקבלת את גזירת הצוות אני מרגישה פספוס שהרעיון שלי לא מומש כמו שצריך בעיני והתפספס לי לחלוטין, אבל אם אני בוחרת לממש לבדי, אני לא רק מתנהלת בצורה שמאוד מעצבנת אותם, אלא יכולה להתפס בצורה לא טובה ולא כשחקנית צוות על ידי המנהלים מעלינו.

יש דרך לצאת מה״ברוך״ הזה בצורה שבה אני גם מבטאת את הרצונות שלי?
 

choo

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

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

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

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

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

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

BravoMan

Active member
לי דווקא נשמע MVP לגמרי...

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

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

השאלה כמובן מי הם ה-"לקוחות" של הפיצ'רים שקיימים נכון לעכשיו?
הרי אם ההנהלה אהבה את הפיתוח, סימן שזה שימושי למישהו, אז השאלה בסוף היא כמה use case נפרדים יש שהכלי כן מספיק טוב עבורם as is?
 
לי דווקא נשמע MVP לגמרי...

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

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

השאלה כמובן מי הם ה-"לקוחות" של הפיצ'רים שקיימים נכון לעכשיו?
הרי אם ההנהלה אהבה את הפיתוח, סימן שזה שימושי למישהו, אז השאלה בסוף היא כמה use case נפרדים יש שהכלי כן מספיק טוב עבורם as is?
הנקודה היא כרגע אני לא יכולה לחשוב על usecase שבו נוכל להסתמך רק על התייחסויות ישירות בין רשומות כמשהו שיוציא מידע שהוא שלם. אפילו המידע שעורר אצלי את המחשבה שצריך לפתח אקספורט דורש התייחסות יותר מורכבת. זה מאוד מזכיר לי את הדיונים שהיו בחברה שבה עבדתי שבה ביצענו את המעבר משיטת המפל לשיטת האג׳ייל - האם mvp צריך להיות יחידה סגורה מבחינה טכנית, או כזו שגם מביאה ערך ממשי ללקוח? כי פה בהחלט מדובר על יחידה סגורה טכנית, אבל לא שימושית למשתמשי הקצה כמעט בכלל בלי להרחיב אותה.

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

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

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

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

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

BravoMan

Active member
לא בשביל משהו, אבל נשמע לי שאת מנסה לנחש מה הם חושבים, וזה לרוב לא מוביל לשום מקום.

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

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

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

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

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

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

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

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

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

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

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