Thread by @EtiNoked

אז השבוע בקפה וקוד {☕️,💻} דיברנו על תקשורת. כמיטב המסורת - סיכום קצר של מה שנאמר שם...
מתחילים:

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

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

לפעמים אין ברירה ורק צד אחד צריך להיענות לדרישות של הצד השני.
רינה הוסיפה וסיפרה שככל שהיא ירדה ב-stack לכיוון פיתוח פלטפורמה ועכשיו Dev Infra, זה שהיא עוד זוכרת איך זה להיות מפתחת מוצר ואת הpain points עוזר לה לתת שירות יותר טוב למפתחים אחרים.
>>

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

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

@omervk דיבר על מערכות יחסים בין engineering ל-product עם דוגמאות טובות יותר ופחות והדגיש שהכלי הכי יעיל הוא תיאום ציפיות - לשבת ביחד ולשתף איך אתם רואים את מערכת היחסים ושגם הצד השני יעשה את אותו הדבר.
>>

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

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

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

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

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

@dochdl דיברה על הבדלי אישיות של אנשים, ועל איך אפשר למנף מבחני אשיות כמו mtbi ו-insights כדי להבין מי עומד מולנו, מה דרך העבודה הטובה ביותר מולם ואיך להמנע מקונפליקטים.
>>

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

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

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

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

כרגיל - הערות, בקשות - בדיאם או פה 🤘

@threadreaderapp unroll