למה צוות הנדסה סניורי מנצח סוכנות כוח אדם של 100 איש בבנייה של 0→1

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

אז כשמישהו שואל אותי, "לשכור סוכנות של 50 איש או צוות סניורי של 5 אנשים?" — למוצר בשלב מוקדם, התשובה הכנה היא: זה תלוי במה שאתה באמת מנסה לעשות. ברוב המקרים, בבנייה מסוג 0→1, זה הצוות הסניורי הקטן. אבל לא כי קטן זה טוב מיסודו. אלא בגלל איך עבודת מוצר צוברת תאוצה — או לא.

ההנחה הסמויה בתוך "יותר ידיים = יותר מהר"

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

0→1 זה החלטות. האם הפיצ'ר הזה צריך בכלל להתקיים? איך קוראים לו? איפה ה-API יושב? מי בעלים על סכימת מסד הנתונים? מה תוכנית ה-rollback? כל אחת מהשאלות האלה היא פיצול בדרך, ומהנדס סניורי עונה על עשר כאלה ביום, לרוב בלי אפילו לשים לב. מהנדס ג'וניורי בסוכנות עונה על אפס — הוא מחכה שמישהו יגיד לו לאיזה כיוון לפנות.

וזה החשבון המלוכלך: כל החלטה שלא מתקבלת עולה לך יום של זמן מחזור. תכפיל את זה בעשרים שאלות פתוחות בשבוע ותתחיל להבין למה staff augmentation מרגיש כמו לרוץ בחול רטוב.

מה צוות סניורי באמת עושה ביום הראשון

כשאנחנו מתחילים בנייה, שלושת הימים הראשונים הם לא "להקים ריפו". הם:

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

עד היום החמישי, המייסד לחץ על משהו שחי על דומיין אמיתי. עד היום ה-15, משתמשים אמיתיים עונים על שאלות אמיתיות בתוכו. עד היום ה-30, החיוב חי.

איפה סוכנויות כוח אדם באמת מנצחות

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

1. כבר יש לך product-market fit ואתה צריך כושר ביצוע. אם סגרת את המפרט, הארכיטקטורה קבועה, ואתה רק צריך להוציא פיצ'רים במשך שישה חודשים — staff augmentation זה בסדר גמור.

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

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

שים לב לחוט המשותף: *אתה כבר יודע מה אתה רוצה*. ככל שאתה רחוק יותר מוודאות לגבי המוצר, staff augmentation מתפקד יותר גרוע.

הכלכלה האכזרית

בוא נעשה את החשבון על תרחיש אמיתי. יש לך $250K כדי להביא מוצר ל-PMF תוך 6 חודשים.

אופציה A — סוכנות כוח אדם, שמונה מהנדסים ב-$85/hr.

$85 × 160h × 8 = $108,800 לחודש. אחרי חודשיים, נגמר לך הכסף. יש לך לוח Jira עם 240 טיקטים סגורים ומוצר שלא ממש עובד מקצה לקצה כי אף אחד לא היה בעלים של שכבת האינטגרציה.

אופציה B — צוות סניורי של ארבעה, בתעריף ממוצע של $140/hr.

$140 × 160h × 4 = $89,600 לחודש. אתה מקבל שלושה חודשים ב-$268,800 — קצת מעל התקציב, אבל בר-ניהול. התוצר: מוצר חי עם משתמשים משלמים, חיוב משולב, שלושה שבועות של לולאות משוב מוטמעות, והחלטות ארכיטקטורה שיחזיקו מעמד שנתיים.

הצוות הסניורי יקר יותר לשעה וזול יותר לתוצאה.

איך באמת קונים הנדסה סניורית

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

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

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

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

4. שיהיה לך הסכם עבודה כתוב. קוד ב-repo שלך מהיום הראשון. CI/CD על החשבונות שלך. בלי "נעביר לך את זה בסוף".

5. תקבע kill switch. החודש הראשון הוא הניסיון. אם הצוות לא מוציא תוצרים עד השבוע הרביעי, שניכם צריכים ללכת.

היתרון הלא-מובן מאליו שאף אחד לא מזכיר

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

סיכום — החלק הלא נוח

כל הפוסט הזה מוטה. אני מנהל צוות הנדסה סניורי. אנחנו גובים בהתאם. ברור שאני חושב שאנחנו התשובה הנכונה לבניית מוצר מסוג 0→1.

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

פורסם במקור ב-mktrl.dev/blog.