יעוץ טכנולוגי לסטארטפים

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

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

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

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

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

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

---

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

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

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

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

 מסמכי התכנון הם גם הבסיס להערכה ראשונית של האתגר הטכנולוגי והמאמץ הפיתוחי. באמצעותם ניתן לתת הערכה ראשונית של זמני פיתוח, לאבחן את שלבי המוצר השונים (שהרי לא מפתחים בכל בפעם אחת) ולקבוע את תמהיל התכונות שיכללו בגרסה הראשונית אותה אנו מכנים “מוצר בר-קיימא מינימלי” או באנגלית MVP  –  minimum viable product.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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