יום שישי, 15 ביולי 2011

העבודה מול חברות off-shore בהודו - לא פתרון קסם


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

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


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

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

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

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

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

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

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

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

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

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

יום שבת, 2 ביולי 2011

מעקרונות קבוצת אג'ייל: נכונות לשינוי

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

רשומות פופולריות