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

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

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

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

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

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

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

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

the.co.ils שמחים להכריז על TWS2010, האירוע השנתי של הבלוג אשר יערך ב-18.10.2010 ב-Arca בנמל ת"א. האירוע, בו ייבחרו עשרת הסטרטאפים המבטיחים של ישראל, הוא האירוע הישראלי השנתי הגדול ביותר בתחום האינטרנט.

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

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

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

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

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

ניהול פיתוח

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

ניהול טכנולוגי

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

ניהול פרוייקט

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

אפיון מוצר

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

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

אפיון טכנולוגי

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

ניהול בסיס נתונים

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

פיתוח "צד שרת"

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

עיצוב

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

HTML/CSS

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

פיתוח ממשק משתמש

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

פיתוח "מתמחה"

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

QA

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

אז מה עושים עם כל זה?

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

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

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

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

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

היתרונות בשימוש בפרוטוקול מדריד משמעותיים:

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

אולם, קיימים גם חסרונות. העיקרים שבהם:

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

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

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

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

סטארט-אפים קמים ונופלים על הפיתוח

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

"הפיתוח אינו הבעיה"

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

אין פיתוח ללא מנהל פיתוח

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

אין פתרונות פשוטים

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

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

בקיצור

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