איך בונים סטארטאפ ביטחוני בישראל

איך כדאי לסטארטאפ ביטחוני בישראל לתכנן את התוכנה שלו?

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

מתחילים מהבעיה, לא מהפלטפורמה

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

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

ראו גם מה EZ Dev מספקת.

שבע החלטות תוכנה שכדאי לקבל מוקדם

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

הופכים ידע מבצעי לגבולות ברורים למוצר

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

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

ראו גם מוצרים שאנחנו בונים ומפעילים.

תכננו את התוכנה לפי תנאי ההטמעה

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

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

ראו גם שירותי פיתוח התוכנה שלנו.

בחרו מה לבנות קודם לפי מה שצריך ללמוד

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

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

דרך מעשית לגיבוש תוכנית התוכנה

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

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

שלבו את המומחיות המתאימה בהחלטות

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

ראו גם דברו עם EZ Dev.

עיקרי הדברים

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

שאלות נפוצות

האם סטארטאפ ביטחוני צריך להתחיל בהוכחת היתכנות או ב־MVP?

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

מה מייסדים צריכים לתעד לפני פיתוח תוכנה?

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

מתי כדאי למייסד לשלב שותף לפיתוח תוכנה?

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