שתי הצעות על השולחן, לאותו תפקיד. אחת נמוכה בהרבה מהשנייה, והתקציב לחוץ. הבחירה נראית מובנת מאליה, עד שאחרי שלושה חודשים ה-CTO מבלה חצי מהשבוע בקריאת Pull Requests ובהסבר חוזר של מה צריך לבנות.
המחיר החודשי של מפתח הוא רק שורה אחת בעלות האמיתית. השאר מתגלה מאוחר יותר, ורובו עולה בזמן של האנשים היקרים ביותר אצלכם.
מה באמת נכנס לעלות
כדאי לחשוב על שלוש שכבות. הראשונה היא המחיר שמופיע בהצעה. השנייה היא הזמן שהצוות שלכם משקיע בלהכווין, לבדוק ולתקן. השלישית היא מה שקורה למוצר: באגים שמגיעים ללקוחות, קוד שקשה להרחיב, ופיצ'רים שמתעכבים.
מפתח זול מדי נוטה להעמיס על השכבה השנייה. הוא צריך הסבר מפורט לכל משימה, מחזיר קוד שלא עומד בסטנדרט, ולא מזהה לבד בעיות שמפתח מנוסה היה עוצר לפניהן. התוצאה היא שמישהו אצלכם הופך למנהל משימות במשרה מלאה, והעלות הזאת לא מופיעה בשום חשבונית.
ניסיון משתלם בדיוק איפה שקשה למדוד
ההבדל בין מפתח עם ניסיון נרחב למי שבתחילת הדרך לא נמצא במהירות ההקלדה. הוא נמצא בשיקול הדעת: מה לא לבנות, איפה כדאי לשים בדיקה, איזה שינוי קטן היום חוסך שבוע בעוד חצי שנה.
לכן אנחנו לא מגייסים מפתחים עם פחות מחמש שנות ניסיון. זו החלטה תפעולית: מפתח כזה צריך פחות ניהול ומחזיר יותר ערך מהשבוע הראשון. החיסכון שלנו מול גיוס מקומי, 25% עד 40%, מגיע ממיקום העבודה ולא מהורדת רמה.
הפער בין מפתח מנוסה למפתח זול מורגש בעיקר בשוטף. הוא מורגש בכמה פעמים צריך להסביר משימה, בכמה באגים חוזרים מהבדיקות, ובכמה זמן המנהל שלכם משקיע בתיקונים במקום בתכנון. החשבון הזה לא מופיע בהצעת המחיר, אבל הוא קובע את העלות האמיתית.
איך בודקים איכות לפני שמתחייבים
המסמך עם הקורות חיים אומר מעט. מה שעובד יותר:
- שיחה טכנית על החלטות, לא על הגדרות. בקשו מהמועמד לספר על מערכת שבנה ועל משהו שהיה עושה אחרת. מי שבנה באמת יודע לפרט, ומי שלא נשמע כללי.
- סקירת קוד אמיתי. קטע קוד שכתב, או משימה קצרה. שימו לב לשמות, לטיפול בשגיאות, ולשאלה אם הקוד קל לקריאה לאדם אחר.
- משימה עמומה בכוונה. תנו הגדרה חסרה וראו אם הוא שואל או מנחש. מפתח טוב מזהה חוסר ושואל.
- שאלה על כישלון. מה שבר בפרודקשן, ומה שינה אחר כך בדרך עבודה. מועמד שאין לו תשובה כנה כנראה לא עבד מספיק בסביבה אמיתית.
אצלנו כל מועמד עובר שני ראיונות, אחד של HR ואחד טכני, ורק מי שעבר אותם מגיע ללקוח לראיון. כך הזמן שלכם מתמקד במועמדים שכבר סוננו.
המחיר צריך להיות ברור ויציב
הצעה זולה במיוחד נראית לפעמים כך כי חלקים נשארו מחוץ למחיר: ציוד, ניהול, ימי חופשה, שעות נוספות. לפני החתימה שאלו מה כלול ומה לא, והשוו שורה מול שורה.
אנחנו עובדים עם מחיר חודשי סופי לעובד במשרה מלאה, הכול כלול. מה שלא נכלל הוא ציוד מיוחד ושירות מנהל מישראל, ואת שני אלה אנחנו אומרים מראש. מחיר שאפשר לחזות הוא חלק מהאיכות, כי הוא מאפשר לתקצב.
איך מחשבים את זה בפועל
כדי לא להתבלבל, בנו טבלה פשוטה לכל הצעה. בעמודה הראשונה המחיר החודשי המלא, כולל מה שנוסף מחוץ להצעה. בשנייה הערכה כמה שעות בשבוע ינהל אצלכם מי שיעבוד איתו: סקירות קוד, הסברים, פגישות. בשלישית הערכה כמה מהקוד יצטרך לחזור לתיקון.
את שתי ההערכות האחרונות קשה לדעת מראש, ולכן הן נבדקות בתקופת הניסיון ולא בדיון. אחרי חודש יש לכם נתונים אמיתיים, וההחלטה פשוטה יותר. שימו לב במיוחד לשעות של האנשים הבכירים שלכם: שעה של CTO שהולכת על הסברים חוזרים היא שעה שלא הלכה על ארכיטקטורה.
בדקו את ההתאמה לפני שמשקיעים חצי שנה
גם מפתח מצוין עלול לא להתאים לצוות או לסגנון העבודה שלכם. הדרך הזולה לברר היא תקופת ניסיון אמיתית עם משימות אמיתיות, לא עוד סבב ראיונות.
החודש הראשון אצלנו הוא חודש ניסיון בתשלום. הוא נועד בדיוק לזה: לראות איך המפתח משתלב, איך הוא מתקשר ומה רמת הקוד. כדאי לקבוע מראש מה הקריטריונים להצלחה, למשל כמה Pull Requests נסגרו בלי סבב תיקונים שני, ואם נשאלו שאלות מתאימות. על סימנים מוקדמים נוספים כתבנו במאמר חמישה סימנים בחודש הראשון שהפרויקט בדרך הנכונה.
שאלות לשאול כל ספק לפני החתימה
- מי בפועל יעבוד בצוות שלכם, ואפשר לראיין אותו?
- איך נבדק הניסיון שלו, ומי עשה את הבדיקה?
- מה כלול במחיר החודשי ומה לא?
- אילו שעות עבודה יתאימו לצוות שלכם?
- מה קורה עם הקוד והמידע שלכם, ומי חותם על סודיות?
- איך נראה החודש הראשון ומה קורה אם זה לא מתאים?
ספק שמתקשה לענות על שאלות כאלה בצורה ישירה מראה לכם איך ייראה השוטף. הנוחות בשאלות האלה שווה יותר מכל מצגת.
אצלנו המפתח מועסק על ידי החברה שלנו בפיליפינים, ואם הלקוח מבקש הוא גם חותם על NDA. שעות העבודה מותאמות ללקוח.
מה קורה כשמוותרים על הבדיקה
דילוג על בדיקות קורה בדרך כלל בגלל לחץ זמן: צריך מפתח מחר, ומקבלים את הראשון שזמין. הבעיה היא שהתוצאה מורגשת רק אחרי שבועות, כשכבר השקעתם בהכשרה ובהקשר. אז כל תיקון בכיוון עולה יותר, כי איבדתם זמן וגם מומנטום.
הפתרון איננו האטה אלא תהליך מסודר שמזיז את הבדיקות לפני ההתחייבות. כשהמועמדים כבר סוננו ומגיעים אליכם רק מי שעבר, אפשר לקבל החלטה מהר ועדיין לדעת על מה היא מתבססת. מבחינתנו, זמן מהבקשה למפתח הראשון הוא בדרך כלל בין שבועיים לארבעה, ולפעמים מספר ימים.
מתי כן מתאים לבחור את האפשרות הזולה
יש מקרים שבהם זה הגיוני: משימה מוגדרת וסגורה, בלי תלות בקוד קיים, שאפשר לבדוק בקלות. סקריפט חד-פעמי, דף סטטי, המרת נתונים עם אימות ברור. במקרים כאלה עלות הניהול נמוכה והסיכון קטן.
ברגע שמדובר במוצר שיחיה שנים, בקוד שיגדל, או במערכת שנוגעת בכסף ובמידע רגיש, מחיר נמוך הופך להימור. שם כדאי לשלם על שיקול דעת.
השורה התחתונה
השוו הצעות לפי עלות כוללת: כמה זמן ניהול והסברים צריך מפתח, כמה תיקונים יחזרו אליכם, ואיזה סיכון נוצר למוצר. בדקו איכות בקוד ובשיחה על החלטות, ובחנו התאמה בתקופת ניסיון עם משימות אמיתיות.
אם אתם רוצים מפתחים מנוסים שמשתלבים בצוות שלכם ומנוהלים על ידכם, מסלול הרחבת הצוות הוא נקודת ההתחלה.
