המעסיק שלי הודיע לפני כמה חודשים שכל עובד שעובד שלוש שנים ומעלה זכאי ל-sabbatical — חופשה בתשלום מלא למשך חודש לפי בחירתו. מאחר שאשתי ואני צברנו מספר ניכר של ימי חופשה, החלטנו לצאת למסע של חודשיים לאסיה — יעד שתמיד רצינו לבקר בו. בפוסט הזה אתאר צעד אחר צעד איך יישמתי שיטות מעבודת היומיום שלי כמהנדס תוכנה לפתרון בעיות מהחיים.
עיקרון 1: בסוף משהו תמיד יישבר בפרודקשן
כפי שאומר הפתגם, בסוף תמיד תהיה תקלת פרודקשן. במקרה שלנו, זה קרה מהר יותר ממה שציפינו. רק כמה שעות אחרי שנחתנו בתאילנד, גילינו בעיה גדולה — כרטיס האשראי של אשתי ושלי שניהם פגו ביום שהגענו. זו הייתה הפתעה גדולה עבורנו, כי בבית, ספקי כרטיסי אשראי בדרך כלל מחליפים את הכרטיס לפחות שישה חודשים לפני תאריך התפוגה. אבל כעמידה של כמעט ארבע שנים בגרמניה לימדה אותנו משהו חדש — שם צריך לבקש כרטיס חדש מהבנק (לקח שלמדנו!). למרבה המזל, הבאנו איתנו מזומן לחופשה, אז יכולנו להסתמך על זה.
אז מה עשינו? התחלנו בהערכת היקף הבעיה, קביעת ההשפעה, בחינת פתרונות אפשריים והערכה של מהירות היישום הנדרשת. הדיון הזה התגלה כמאוד שימושי. הגענו למסקנה שאם נשתמש ב-Airbnb להזמנות, נוכל לחסוך את המזומן שיש לנו. בנוסף, הבנו שיש לנו מספיק מזומן לזמן מה, מה שמאפשר לנו להמשיך בחופשה.
פירוט הפתרונות האפשריים לבעיה אפשר לנו:
להבין את היקף הבעיה.
לתפוס את מורכבות הפתרונות הפוטנציאליים.
לבחור את הפתרון/פתרונות שהכי מתאימים לצרכים שלנו.
עיקרון 2: Retro ו-Action Items
כשתכננו את הטיול, אשתי ואני החלטנו להזמין Airbnb לחמישה ימים כדי לאפשר זמן מספיק להתאוששות מג’ט לג ולחקור את העיר. אבל למרות שאכן חווינו ג’ט לג כשלושה-ארבעה ימים, הרגשנו שיכולנו לקצר את השהות. יתרה מזאת, בעוד שהאירוח ב-Airbnb שלנו היה סביר, הוא לא היה יוצא מן הכלל ועלה קצת יותר מדי.
אז מה עשינו? כפי שמרמז הכותרת, ערכנו retro קצר. במהלך הדיון הזה, זיהינו מה עשינו טוב ומה יכולנו לעשות טוב יותר. הסכמנו שהתחייבות עיוורת לשהות ארוכת טווח לא הייתה רעיון טוב. יתרה מזאת, מה אם לא היינו אוהבים את היעד שהתכוונו להגיע אליו? למה להתחייב לתקופה ממושכת שם?
תוצאת ה-retro הזה הייתה action item שיישמנו לאורך כל הטיול. החלטנו לא להזמין שום מקום ליותר משני לילות בתחילה. הגישה הזו נתנה לנו גמישות לשנות מלונות אם לא אהבנו את המקום או אם הרגשנו צורך לעבור ליעד הבא.
הדיון של 10-15 דקות הזה במהלך השבוע הראשון של הטיול שלנו התגלה כבעל ערך עצום מבחינת תכנון מראש ומניעת תסכול מאוחר יותר. זה מה שאני מחשיב השקעה טובה!
עיקרון 3: תמיד תהיה עם מישהו שבודק את העבודה שלך
בשלב מסוים במהלך הטיול, היינו צריכים להזמין טיסה פנים. מצאתי טיסה מתאימה, אם כי לא בתאריך האידיאלי — זו הייתה האפשרות הקרובה ביותר בהתבסס על המיקום שלנו באותו זמן. הזמנו, המתנו שלושה ימים במקום, ועלינו על מסע סירה בן שש שעות. לאכזבתנו, גילינו עם ההגעה שעשיתי טעות והזמנתי את הטיסה לחודש מאוחר יותר.
למרות שהיו סיבות מאחורי הטעות, התוצאה הייתה אותה — מצאנו את עצמנו בשדה התעופה ללא טיסה וללא מטבע מקומי (הטעות השנייה שלנו).
אז מה למדנו? בדומה לפיתוח קוד, שבו חיפוש review לפני merge הוא חיוני, יישמנו את אותה גישה להזמנות מכל סוג (מלונות, טיסות, אוטובוסים וכו’). האחד מאמת שכל הפרטים נכונים. הופתענו ממספר הבעיות הקטנות שמצאנו בהזמנות של כל אחד מאיתנו לאורך הטיול.
עיקרון 4: דרישות משתנות
כשתכננו את הטיול בתחילה, התכוונו לבלות חודש בתאילנד וחודש בפיליפינים. אבל במהלך שהותנו בדרום תאילנד, מצאנו שהחום שם בלתי נסבל. אשתי, שלא אוהבת חום, ואני דנו במצב והחלטנו לחפש יעד קריר יותר. אחרי שיקול דעת מדוקדק, בחרנו לקצר את שהותנו בתאילנד ולהוסיף יעד שלישי לטיול. כך הגענו לווייטנאם!
אז מה למדנו? שום דבר אינו חקוק באבן. מה שנראה בהתחלה כהתאמה טובה יכול להתברר כהתאמה גרועה. תמיד היו פתוחים לשינויים על פי צרכי המשתמש. יכולנו להתעקש על התוכנית המקורית שלנו בטענה שהכל כבר מסודר. אבל על ידי שינוי התוכנית, יצרנו חופשה שהתאימה יותר להעדפות שלנו.
סיכום
יישום פרקטיקות מעולם ההנדסה על בעיות מהחיים יכול להניב יתרונות משמעותיים. הרבה מהבעיות שלנו כבר נפתרו בהקשרים שונים, ואנחנו יכולים ללמוד מהפתרונות האלה כדי לתת מענה לצרכים שלנו.