תסמונת דור ה-Y

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

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

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

זה מתחיל מלמטה

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

אני חושב שהכי אפקטיבי לדבר על ההשקעה הכספית בגיוס: לעיתים, כך נוכחנו לדעת, חיי המדף של מפתח בן דור ה-Y גם ככה קצרים ואתה יכול למצוא את עצמך מפסיד פעמיים בשנה שווי משכורות ניכר על שילוב עובדים. אם גייסת שני עובדים לאותה משרה, על אותה עמדה, בעצם השקעת פעמיים. ואם כל הכשרה של עובד עולה 4 חודשי משכורת (לכל מפתח לוקחים 3 חודשים כדי שייכנס לקצב, ועל זה מוסיפים עוד חודש בסך הכל שמשקיעים בהכשרה שלו. הווה אומר ב-3 החודשים הראשונים 180 שעות. 60 שעות לחודש שהם בערך שני ימים בשבוע, 40% מהזמן) בעבור תפוקה מינימלית, הרי שעבור 2 עובדים שגויסו שווים יותר מחצי שנה של משכורות. אם משכורת חודש היא 10000$, הרי שכמעט 75000$ הושקעו כשהפרודוקטיביות המצרפית של שני המפתחים שווה אולי לתפוקה של מפתח סניור ותיק אחד בחודשיים.

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

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

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

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

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

האפקט ההרסני של חוק פרקינסון על סקראם

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

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

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

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

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

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

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

כמו תוכי

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

טסט קייס: צוות שבו אף אחד לא יודע גיט יותר מהפקודות הבסיסיות של commit, pull, push. ואז יש קומיט שגוי, וצריך לעשות revert, ואף אחד לא יודע מתי צריך לעשות rebase כי יש כלל ברזל שלעולם לא עושים ריבייס. או חמור מזה: יש הוראה מלמעלה שעל פיה אף אחד לא עושה merge, חייבים לעשות pull request כדי שרק אדם אחד ימרג'ג' את הקוד. והאדם הזה לא יודע את המשמעות של rebase. ואז יש קונפליקט, והוא תקוע, ומסתכל בסטאק אוברפלואו ומסתמך על המלצות שקיבלו לייקים ופועל לפיהן בלי לדעת באמת מה הוא עושה ואיך יימנע ממקרים כאלה בעתיד.

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

תסמונת הפרה החולבת

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

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

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

Anti-Patterns

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

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

Fake Scrum

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

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

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

הבעייתיות של וורדפרס

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

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

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

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

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

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

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

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

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