מיקרופוסט: שינויים גדולים

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

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

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

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

ככה כעסתי אתמול בעבודה.

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

מיקרופוסט: אוסף סטריפים בנושאים די קרובים שעשוי לשעשע את מי שלשמחתו או לרוע מזלו הזדמן לו לעבוד עם מתכנתים ומנהלי IT במידה כזו או אחרת

הספר הזה, שהוא אוסף של סטריפים מהקומיקס הזה (או שאולי זה חומר חדש לחלוטין? אני לא יודעת) – נורא מצחיק!

וגם – מאיפה הקרצתי את שם הפוסט?

אין כאן לולאה

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

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

אין כאן לולאה

אבל זה צעצוע מחשבה, אז נתון לנו שהבעיה פתירה גם בלי צ'יטים. ולמה היא פתירה? זה פשוט – אינטואיטיבית, אפשר להגיד שהחוט והמסגרת לא מהווים שתי לולאות סגורות ששלובות זו בזו. כיוון שברור לנו שהחוט הוא לולאה סגורה, הרי שמסגרת העץ היא צורה "פתוחה" שמאפשרת לחלץ ממנה את החוט^[1]. מה הכוונה? אם נדמיין שהמסגרת לא היתה עשוייה מעץ, אלא מחומר רך כמו חוט או בד, היינו יכולים לנתק את הלולאות זו מזו ולקבל את המבנה הבאה:

טוב, בערך.

עם כזו חידה אני חושבת שאני יכולה להסתדר.

אז למה יש כאן אתגר?

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

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

היינו מעבירים את חלק החוט המסומן בחץ אדום קטן לאורך הקו המקווקו ומחלצים את החוט. עכשיו יש לנו ביד אלגוריתם^[2] קטן שיודע להעביר חוט מצד אחד של לולאה שתקוע לה צ'ופצ'יק באמצע, לצד השני שלה:

• העבר חוט מצד אחד לצד שני של הלולאה (A -> E)
  • העבר חוט מצד אחד לצד השני של הצ'ופצ'יק מתחת ללולאה (B -> C)
  • העבר חוט מצד אחד לצד השני של הצ'ופצ'יק מעל הלולאה (D -> E)

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

בעיה בתוך בעיה בתוך בעיה בתוך…

ההגדרה הוויקיפדית לרקורסיה היא:

רֵקוּרְסִיָּה (בעברית: נסיגה) היא תופעה שכל מופע שלה מכיל מופע נוסף שלה, כך שהיא מתרחשת ומשתקפת בשלמותה בתוך עצמה שוב ושוב.

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

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

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

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

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

אז איך הרעיון של רקורסיה עוזר לנו?

אם נחזור לבעיה שעל הפרק נשים לב שהיא בנויה בצורה רקורסיבית גם כן – בתוך הלולאה הראשונה תקועה לולאה נוספת, שבתוכה תקועה לולאה נוספת שבתוכה… עד לסף העצירה – בלולאה האחרונה תקוע צ'ופצ'יק ולא לולאה. אנחנו גם יודעים איך לפתור את החידה כשהיא "קטנה מספיק", כלומר – בנויה רק מלולאה וצ'ופצ'יק^[3].

עכשיו נעיף מבט קרוב יותר בצעצוע (קליק לתמונה בגודל סביר).

אנחנו כבר יודעים שכדי לחלץ את החוט, אנחנו צריכים להעביר אותו מ A.2 לA.1, וכבר הבנו שבשביל זה צריך קודם כל להעביר אותו מ B.1 ל B.2. אבל בעצם, אם נדמיין שהלולאה הראשונה הוסרה באורח פלא ממקומה (נגיד, באמצעות הקסם "הכאה בפטיש" דרגה 8), נראה שהבעיה של העברת החוט מ B.1 ל B.2 זהה במהות שלה להעברת החוט מ A.2 ל A.1, רק שהפעם הצעצוע בנוי משלוש לולאות ולא ארבע, ואנחנו צריכים להעביר את החוט בכיוון ההפוך לזה המקורי.

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

אם אתם רוצים לתרגל קצת "ריצה יבשה" (או שאתם סתם מזוכיסטים), אתם יכולים לנסות להריץ את האלגוריתם שלנו על דף ניר, כפי שעשינו עבור לולאה וצ'ופצ'יק. בכל שלב כתבו מאיזו נקודה לאיזו נקודה אתם מעוניינים להעביר את החוט. בשלב הבא, כתבו את צמד הנקודות הבא שצריך לעבור דרכן בהיסט של רמה אחת פנימה וחוזר חלילה – עד שתגיעו לשתי נקודות שהמעבר בינהן הוא טריוויאלי (E.1 ו E.2). כשהשלמתם מעבר בין שתי נקודות, בדקו מה צמד הנקודות הבא שצריך להעביר דרכו את החוט כדי להשלים את הרמה הקודמת.

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

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

-=-

^[1] וכאן שאלה מעניינת – איך מפרמלים את הרעיון האינטואיטיבי ששתי צורות מורכבות הן לולאות שלובות ובונים אלגוריתם לגילוי צורות כאלה?
^[2] סדרת צעדים
^[3] הערה קטנה לקפדנים – למעשה, לולאה שתקוע בתוכה צ'ופצ'יק מייצגת שני שלבים ברקורסיה והבעיה הפשוטה ביותר היא צ'ופצ'יק בודד, אבל עזבו אתכם – אם לא שמתם לב, זה לא פוסט פורמלי במיוחד.

השעות הלא קטנות בכלל

פוסט זה התפתח באופן אורגני יחסית מתגובה לתגובה הזו של מהגג.

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

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

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

Nine Hours Per Day Ought to be Enough for Anybody!
הגישה הזו מושתת על רעיון פשוט – אם אתה צריך לבלות יותר מיום עבודה של 9 שעות במשרד כדי לסיים את המשימות שלך, משהו שבור. במקרה כזה יש שתי אפשרויות: או שאתה ממש גרוע במה שאתה עושה, או שיש בעיה בניהול העבודה. סביר להניח שאתה לא גרוע במה שאתה עושה, כי רובנו (לא נעים להודות), ממוצעים^[1], לכן אני נוטה לחשוב שזו בעיה ניהולית. בעיה כזו יכולה להיות מחסור בכח אדם, ואז זו לא אמורה להיות בעיה שלך, בעיה בניהול המשימות, ואז זו גם לא אמורה להיות הבעיה שלך, או בעיה של נורמות התנהגות במקום העבודה, ואז אין סיבה שתסכים שזו תהיה הבעיה שלך.

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

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

תיעדוף משימות הוא לא מותרות
כשאני מקבלת משימות אני מעריכה אותן בהתאם ללוז שחתמתי עליו – 9 שעות עבודה. אם אני חושבת שהן לא יסתיימו במסגרת הזמן שהמנהלים שלי בנו עליה, אני מתריעה ואומרת להם לתעדף^[2].
למה זה חשוב?
בסופו של דבר, ניהול סביר מתבסס על יכולת להעריך את זמן הביצוע של משימות שונות, ועל היכולת לתעדף את המשימות במסגרת מערכת השיקולים של החברה על הצד הטוב ביותר, מתוך הכרה במגבלות הזמן של העובד. אם העובד נדרש לעשות שעות נוספות, זה אומר שהערכת הזמנים היתה לקויה, או שסירבו להחליט אילו משימות חשובות יותר ואילו פחות וניסו לדחוס יותר משימות ממה שריאלי, מתוך ההבנה שהשעות הנוספות של העובד הן משאב זמין. אם אתה מעריך את המשימות, הסיכוי שהן יוערכו בצורה לא סבירה קטן (ואם מעריכים אותן בשבילך, זו לא בושה להגיד שההערכה לא הגיונית), ואם אתה מציג לבוס שלך את מצב העניינים שיש גבול לכמות הדברים שאפשר להספיק לעשות בשבוע נתון, הוא חייב להשקיע את הזמן הנוסף הזה בתיעדוף במקום לעגל פינות על חשבונך.

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

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

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

נקודה אחרונה וחשובה
בארגונים שבהם הנורמה היא הישארות עד מאוחר (בתור סוג של "אחוות לוחמים"), הגישה שלי עשויה ליצור חיכוכים עם שאר חברי הצוות וההנהלה. על זה אני אענה באנקדוטה:
יצא לי לבלות שנתיים במוסד צבאי בו הנורמה היתה עבודה מ 7:00 בבוקר עד 11:00 בלילה (וזה רק כי ירד נוהל ממפקדי היחידה שאסור להשאר לעבוד עד 1:00 או 2:00 ולישון במשרד, מה שהיה מקובל קודם לכן). במהלך תקופה קצרה בה היתה לי פחות עבודה (יחסית) יכולתי להרשות לעצמי לצאת כל יום בסביבות 20:00 – 21:00. אחרי כמה ימים של יציאה בשעות "שערוריתיות" שכאלה המפקד שלי לקח אותי לשיחה וביקש ממני להפסיק לצאת מוקדם כי זה לא נראה טוב כלפי שאר החיילים שצריכים להישאר עד מאוחר.
ברגע הזה משהו בי נשבר. עד אותה נקודה הקרבתי כל מה שהיה לי בשביל העבודה שם – לא ראיתי את החברים שלי, לא ראיתי את המשפחה שלי, הייתי עובדת בסופי שבוע וחגים, ישנתי בממוצע 4 שעות בלילה וחופשים הייתי לוקחת כדי להספיק להשלים משימות על הצד הטוב ביותר. אבל ברגע שבו יכולתי להרשות לעצמי "לשחרר" מעט נדרשתי לא לעשות את זה בשם איזו תרבות ארגונית של סולידריות מחורבנת (הוא אפילו לא רצה לתת לי עוד משימות! פשוט שאני אשאר שם כדי שאני לא אוריד את המוראל!)
אז הבנתי שיש גבול לקורבנות שאני מוכנה להקריב ולכמות החרא שאני מוכנה לאכול. יש לי גבולות, ואפילו המעסיקים שלי נדרשים לכבד אותם.

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

^[1] וממילא בעיית שעות היא בד"כ בעיה של ארגון שלם ולכן היא לא יכולה להיות סימפטום לחוסר הכשרון של עובד ספציפי.
^[2] ואם אומרים לי שהכל חשוב ושאני אעשה הכל, אני אומרת, בחצי חיוך, שזה אומר שכלום לא חשוב ושכיוון שכך, אני אפתח את מה שכיף לי ומה שיכנס יכנס, ותודה ושלום (זה בד"כ גורם לתיעדוף להופיע באורח פלא).

All Things Technical

פתחתי בלוג חדש (באנגלית) בשביל כל הדברים שהם טכניים מידי בשביל הבלוג הזה(שימור ידע מקצועי) או שאינם מעניינים אף בן אדם נורמלי^[1].

אם זה בכל זאת מעניין אתכם, יש קישור ברשימה משמאל – כרגע יש שם בעיקר רשימות שלי.

^[1] אנשים שלא קוראים ספרות מקצועית לפני השינה להנאתם.

כנגד 4 תכניתנים

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

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

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

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

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

האדיש
האדיש בחר בקריירה בתחום המחשוב כי זו עבודה לגיטימית כמו כל עבודה, והשמועה אומרת ש"יש בזה כסף טוב", אז עד היום הוא מקווה למעוד במקרה על סטארט אפ ש"יעשה את המכה" ויגאול אותו מהגורל שהוא בחר לעצמו. הוא מבלה 9 שעות ביום בעיסוק שהוא לא ממש אוהב ולא ממש טוב בו, והוא יודע את זה, וכל שאיפתו היא לסיים את העבודה מהר ולעשות את הדבר היחיד שהוא באמת משתוקק אליו – לשבת מול הטלויזיה ולחלום על חיים של אנשים אחרים שקמים בבוקר בשביל משהו שהם באמת שמים עליו קצוץ.
האנשים האלה בדרך כלל ישייטו בשקט מתחת לרדאר של ההנהלה בתקווה למשוך עוד יום בו אף אחד לא ישים לב לבינוניות שלהם. אפשר לזהות אותם לפי ה check inים ל source control system שבהם נוספים גידולי קוד חיזריים שמטפלים בקוד שרת מה JavaScript של ה UI בלי שום קשר לכל דבר שמזכיר עיצוב הגיוני של מערכת, מתודות שפותחות חיבורים ל DB בלולאה ושולפות שורה את כל פעם ואבסטרקציות לבדיקת הערך של משתנה בולאני . והם בין הגורמים שאחראים לריקבון האיטי והבלתי נמנע של כל מערכת שהם עובדים עליה.

הנלהב
הנלהב סיים זה עתה בהצטיינות תואר ראשון במדעי המחשב והוא ניגש במרץ לשנות את פני עולם התכנה למרות שהוא לא עבד על מערכת אמיתית מימיו. הוא מגיע לעבודה מלא כרימון ברעיונות חדשים ומבריקים שהוא שהוא שמע עליהם בשיעורי design patterns ומבני נתונים , וכעת הוא נחוש לממש linked list תחת כל מחלקה רעננה. בעיניו הבורקות כל מחלקת utilities קיקיונית לובשת צורה של היררכייה מורכבת עם שני ממשקים לפחות ו factory עשוי ניירוסטה, כרום וניקל נוצץ שמייצר את המופע הבודד שלה במערכת שהוא, כמובן, singleton. האנשים האלה אחראיים ל"סינדרום המערכת הראשונה": עיצוב יתר ברמת פירוט מיקרוסקופית של קטעי קוד שמוטב היה לו היו פשוטים וקוהרנטיים, תוך התעלמות מוחלטת מסוגיות עיצוביות רחבות במערכת והתעקשות קשת עורף לממש כלים קיימים וקטעי קוד שנכתבו בעבר שוב ושוב במו ידיהם.
הבנים הללו הם למעשה לא תכניתנים גרועים באופן חסר תקווה, ותחת יד מרסנת שתכווין את המרץ הבלתי נגמר שלהם לאפיקים מועילים, הם יכולים לפרוח.

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

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

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

** ללא דמי מנוי בכפוף לשימוש יומי בסכום של 99.99 שקלים לפחות ועד לתקרה של 100 שקלים ליום, ובעלות של 10 שקל לדקה עבור כל דקה נוספת לא כולל שימוש ביכולות חיפוש, ציטוט או קריאה בלילות ירח מלא.

פעלולי קוד

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

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

// Maximum of objects that it's REALLY RALLY IMPORTANT not to create too many of!!!1
private static final int HEAVY_OBJECTS_MAX = 100;

// Counter for my objects
private int reallyHeavyObjectsCount = 0;

...

// Make sure we are not creating too many objects
if (++reallyHeavyObjectsCount < HEAVY_OBJECT_MAX) {
	new ReallyHeavyObject();
}

לכאורה הדבר הזה אמור לעבוד.
אמור, אלא אם האפליקציה שלנו רצה מספיק זמן.
בכל פעם שהתנאי הזה רץ, הערך של המשתנה מתקדם. אחרי מספיק ריצות כאלה, הערך שלו יזלוג (נו, איך מתרגמים overflow?) והוא יתאתחל למספר קטן מאד, שכמובן יגרום לכך שבריצות הבאות ניצור כמות לא מבוטלת של האובייקטים הממש כבדים שממש, אבל ממש, בשום פנים ואופן אסור לנו ליצור יותר מידי מהם.
והבעיה עם תכנות כזה היא שמאד קשה להבין מה לא בסדר בקוד הזה ממבט ראשון. אלה באגים מגעילים, חמקמקים, באגים מהסוג שלא משתחזר ושלך תמצא מאיפה הם מגיעים במערכת.
אז ככה מפילים מערכת production שלמישהו נורא חשוב לשמור למעלה, עם 30K+ אובייקטים שלא אמורים להיות יותר ממספר זעום של מופעים שלהם במערכת. למעשה, ככה מפילים מערכת production שכל כך חשוב לשמור למעלה, עד שיש לה שרת גיבוי, אבל זה בסדר, ככה מפילים גם את שרת הגיבוי.

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

לפעמים גם המראה החיצוני חשוב

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

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

Spaghetti Madness

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

public void playWithDick(Pet dick) {
	if (dick.getSpecie() == Pet.DOG) {
		throwBall(dick);
	} else if (dick.getSpecie() == Pet.CAT) {
		waveString(dick);
	} else if (dick.getSpecie() == Pet.IGUANA) {
		// Leave Dick alone, it hates you anyway...
	}
}

אולי היה עדיף לבנות את הקוד בצורה כללית, ולתת לפולימורפיזם לעשות את העבודה?

public void playWithDick(Pet dick) {

	// Let dick decide what it likes to do...
	dick.play();
}

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

public void myUnmaintainablePieceOfCode() {

	// A flag that indicates whatever
	int myFlag = 1;

	if (someCondition) {

		myFlag = 2;

		if (someOtherCondition) {

			myFlag = 3;
		}
	}

	// Lots of complex code

	if (myFlag == 2) {
		myFlag = 4;
	}

	// Some more complex code

	// What flag value did we get?
	if ((myFlag == 1) || (myFlag == 4)){

		// Do something based on flag value
	} else {

		// Do something else
	}
}

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

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

התאומים הסיאמיים (copy&paste)

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

העתקת קוד כזאת בתוך אותו ה Class מעידה בדרך כלל על חלוקה לא נכונה למתודות, והרבה פעמים היא מצוותת לבעיית ifים כזו או אחרת.

מתקפת המתודות המשובטות

מקרה פרטי של הבעיה הוא קוד שחוזר על עצמו בין Classים שונים, לפעמים בשינוי קטן, או בין מתודות שונות של אותו הclass:

public class myCoolClass {

	public void methodThatDoesSomethig() {

		// Bla bla...
	}

	public void methodThatDoesTheSameThingWithATinyDifference() {

		// Bla bla…
		// Yet another bla!
	}
}

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

Obese Class/Method

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

זו היא ה Obese Class.

כל הצעה לשנות את החיה האימתנית מובילה לצווחות אימה מצד חברי הצוות והמנהלים, ובלילות אתם חולמים על היום בו תאזרו אומץ לשלוח את הקובץ אל סל המחזור ולצעוד בslow motion אל עבר השקיעה.

קורבנות אופנה

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

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

מה אתה עושה כשאתה קם בבוקר?

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

כל אחד צריך משהו לקום בשבילו בבוקר.

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

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

אלה הם חלומותיו הצנועים של האיש הטכני.

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

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

אבל לפעמים אני חושבת – אולי זה התפקיד של המנהל להפוך את העבודה של האנשים שלו לקצת יותר מרק עבודה?

מחשבות על אתרים שיווקיים לעסקים

Disclaimer:

אני לא אשת שיווק, אלה המחשבות שלי בלבד ויש לקחת אותן בעירבון מוגבל.

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

מי המבקרים באתר

=============

המבקרים באתר יכולים להיות ממגוון פרופילים:

אנשים שבמקרה קיבלו את הפלאייר שלי ללא התעניינות מוקדמת והסתקרנו

אנשים שזקוקים ללימודי האנגלית לצורך עבודה או לימודים והם בודקים מוסדות לימוד שונים

אנשים שהגיעו מתוך באקראי או מקישורים אחרים (כמה כאלה יש?)

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

מה האופציות שלהם?

==============

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

מה המבקרים רוצים לדעת?

==================

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

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

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

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

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

מה המבקרים צריכים?

===============

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

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

רשימת הקורסים המועברת בבית הספר.

לכל קורס יוקדש דף שיכיל מידע רלוונטי לגביו שאינו משתנה:

תיאור שיווקי קצר של הקורס

למי הוא מיועד ומטרות עיקריות, בקצרה ובנקודות

(האם הקורס מתאים לי? האם הוא מכסה את המטרות שלשמן אני נרשמת?)

דרישות קדם, אם יש

(האם אני יכולה לעמוד בקורס?)

היקף הקורס בשעות

(האם יש לי את הזמן להשקיע בקורס הזה?)

אם קיים סילבוס מפורט לקורס, הייתי מוסיפה קישור אליו בסוף

(איזה אחוז מהחומר שמועבר בקורס אני כבר מכירה?)

לו"ז קורסים

טבלה מסודרת ומפורטת ככל האפשר עם:

שם הקורס שנפתח

(יש את הקורס שאני רוצה?)

תארכי פתיחה וסיום

(זה משתלב עם הנסיעה לברזיל?)

ימים בשבוע ושעות

(איך אני משלבת את זה עם חוג המקרמה שאני לוקחת?)

מיקום מדוייק של הקורס

(אני אספיק להגיע אחרי העבודה בשעות העומס?)

מחיר

(אני צריכה משכנתא בשביל הקורס?)

תנאים והערות

(כמות משתתפים מינימלית, מבצעים)

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

מבצעים והנחות, אם יש

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

Disclaimer:
אני לא אשת שיווק, אלה המחשבות שלי בלבד ויש לקחת אותן בעירבון מוגבל.

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

מי המבקרים באתר

=============

המבקרים באתר יכולים להיות ממגוון פרופילים:

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

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

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

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

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

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

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