יזמות

blank_page

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

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

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

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

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

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