S: "הייתי Tech Lead על feature שהיה committed לQ3. באמצע Sprint 2,
    גיליתי שה-third-party API שעליו הfeature מבוסס לא תומך ב-use case
    שלנו — מגבלה ב-rate limits שלא ידענו עליה."

T: "הייתי צריך לתקשר לPM שה-delivery בסכנה — 3 שבועות לפני deadline,
    כשלPM יש customer commitments שמבוססים על הdate הזה."

A: "לא שלחתי Slack message קצרה. לא שלחתי email שמסביר את הבעיה
    ה-technical. קבעתי 20 דקות עם ה-PM באותו יום.
    
    הגעתי מוכן עם:
    1. ה-problem ב-sentence אחת: 'ה-API לא תומך ביותר מ-100 requests/min,
       אנחנו צריכים 500 לפחות.'
    2. 3 options עם trade-offs:
       — Option A: עוד 4 שבועות לrefactor לasynchornous architecture. Delay.
       — Option B: Launch עם rate limiting — feature עם limitations ל-launch.
       — Option C: Switch ל-different API provider — 2 שבועות investigation + 3 שבועות implementation.
    3. ה-recommendation שלי: Option B — launch עם limitations, תוך commitment
       לremove ה-limitation בQ4.
    
    ה-PM הסתכלה בOptions. שאלה כמה שאלות. אמרה שצריכה לבדוק עם ה-customer."

R: "ה-customer הסכים ל-Option B. Launch קרה ב-time. Feature limitation
    הוסר ב-Q4 כמתוכנן.
    
    ה-PM אמרה לי בsync הבא: 'העריכי שבאת עם options ולא רק עם הבעיה.
    זה עשה הבדל גדול.' מאז, זה הstandard שלי — כשאני מגיע עם problem,
    אני מגיע עם לפחות 2 options."
Communication — תקשורת אפקטיבית

Communication — תקשורת אפקטיבית

Communication — תקשורת אפקטיבית
