הגדרת תכלית האתר והפונקציונליות הדרושה
לפני שניגשים להתמודד עם שאלה ה"איך", חשוב לברר קודם את ה"מה" – מה התכלית של האתר/המערכת שאנו מעוניינים להקים? אילו יכולות דרושות ומהם ממשקי המשתמש שיידרשו לכך. לשם כך אנו זקוקים לאפיון מסודר ומפורט של האתר בשני היבטים מרכזיים: א. אילו פעולות אני מעוניין לאפשר למשתמשי האתר לבצע ב. אילו פעולות אני מעוניין להיות מסוגל לבצע כמנהל האתר
כיצד נאפשר את הפעולות למשתמש והמנהל
אחרי שהבהרנו מהן הפעולות שהאתר נדרש לתמוך בהן, נרד לרמה הבאה והוא הגדרה ראשונית וסכמתית לגבי השאלה כיצד נציג את המידע/נאפשר את הפעולות למשתמש ואילו סוגי משתמשים אמורים להיות. אילו מסכים יוצגו לגולש, אילו שדות, אילו פעולות הן יאפשרו ובאילו מצבים (ייתכן כתלות במצב ההרשאות שלו כמשתמש במידה וישנן כמה משפחות של משתמשים). לטובת השלב הזה, מומלץ לבחון כמה שיותר אפליקציות/אתרים דומים, אילו אפשרויות הם מציעים למשתמש, מה הבעיות באתר מבחינת נגישות ופונקציונליות וכו'.
אחרי שלב האפיון הראשוני – איך מיישמים?
לאחר שאפיינו את המערכת הדרושה ויכולותיה, אפשר להתחיל לעבור לשלב ה"איך". קיים היום היצע בהיקף מסחרר של פתרונות מסוגים שונים, בעלויות שונות ומשמעויות מסחריות שונות. אם ניקח לדוגמא את נושא הרשתות החברתיות, בעבר פיתוח של רשת חברתית (דוגמת פייסבוק, מקושרים וכיוב'), היה תהליך ארוך ויקר למדי. היום, ניתן למצוא פתרונות מוכנים, זולים וזמינים שמאפשרים לכל אחד לפתוח רשת חברתית בתוך מספר דקות – קחו את Ning לדוגמא (http://www.ning.com/).
כמובן, לכל פתרון מוכן יש את החסרונות שלו, מגבלות שהוא מציב ויכולת מימוש הנכס בעתיד (exit).
שיקולים לגבי מידת ההתבססות על מערכות מוכנות לטובת פיתוח אפליקציה/אתר מ-0
1. מידת ההתאמה - שיקול הראשון הוא מידת ההתאמה של המערכת המוכנה לצרכים – מערכת מוכנה שמספקת מענה ל-90% מהדרישות של האתר, ומידת הפיתוח העצמי או ההתאמה הנדרשת היא בסיסית למדי, יכולה לתת כיוון טוב. ככל שנדרשים לפתח יותר רכיבים/יכולות באופן עצמאי, יורדת האטרקטיביות של המערכת כפתרון, וייתכן שיהיה משתלם יותר לפתח מערכת באופן עצמאי מ-0. במידה ואכן שוקלים ברצינות שימוש במערכת מוכנה, בקשו לצפות ביכולות שהיא מספקת (ממשק אחורי, קדמי, יכולת שינוי וכיוב'). היכולת לדעת מה מקבלים הוא אחד היתרונות המובהקים כאשר פונים לפתרון מוכן או כמעט מוכן. שאלה נוספת היא עד כמה אנו מוכנים להתפשר על יכולות מסוימות שאינן קיימות ולוותר על חלקים מהחזון הראשוני שלנו (ראו פסקה בנושא האפיון לעיל).
2. יכולת תמיכה בשינויים עתידיים והרחבות - כאשר מדובר על אתרים או מערכות מורכבות, בשלבי הפיתוח הראשונים וגם המאוחרים יותר, צפויים שינויים בדרישות מהמערכת ומהמאפיינים שהגדרנו בתחילת הדרך. זהו תהליך טבעי שנובע מקבלת פידבקים מהמשתמשים ותובנות חדשות המצטברות לגבי אילו יכולות חשובות יותר מאחרות. ככל שהמערכת מובנית יותר, כך שינויים עתידיים יהיו קשים יותר לביצוע, לכן במידה ומדובר במערכת שמציעה פונקציונליות ייחודית (בשונה מחנות וירטואלית או פורום לדוגמא, ששם היקף השינויים העתידיים קטן יחסית) חשוב לבחון פתרונות שיהיה ניתן להתאים ולשנות באופן נוח. במידה ובחרנו להתאים מערכת קיימת, חשוב גם לשאול מה מידת הפופולריות שלה ומכמה גורמים נוכל לקבל תמיכה (האם רק מהחברה המפתחת כמו במקרה של מערכת קניינית או ממגוון נותני שירותים עצמאיים כמו במקרה של אפליקציות קוד פתוח?)
3. מטרות ארוכות טווח - מה המודל העסקי של המיזם? האם המודל העסקי של המערכת מבוסס על תנועה של משתמשים, פרסום, רכישת שירותים וכיוב', או האם המטרה הסופית היא מכירה של המערכת ויכולותיה (לדוגמא במסגרת exit). שימוש במערכות מבוססות קוד פתוח יכול להטיל מגבלות קשות על היכולת למכור את הטכנולוגיה של האתר (כיוון שאנו עושים שימוש בקוד שהוא נחלת הכלל). הערת ביניים: צריך להבחין בין מכירת האתר/האפליקציה לאור היכולת הטכנולוגית שלה, לעומת מכירת אתר פעיל ששוויו נגזר מהיקף התעבורה הנכנסת אליו או ההכנסות שלו משירותים הנמכרים באתר. יש לענות על שאלות אלו בתחילת הדרך כדי שלא תתחילו במהלך שלא יאפשר לכם לממש את ההשקעה בנכס המקוון שהקמתם. מערכת שפותחה באופן עצמאי לחלוטין אינה מוגבלת על-ידי רישיון שימוש כלשהם ולכן מקנה את החירות המרבית בעת מכירה.
4. דחיפות - מהי מידת הדחיפות בהעלאת המערכת לאוויר? אם נמצאים בלחץ זמנים וחשוב להגיע לאתר באוויר תוך זמן קצר, מערכות מוכנות יכולות לספק תשובה מהירה, גם אם חלקית. תהליך פיתוח עצמאי הינו בדר"כ ארוך וידרוש יותר קשב מצד הלקוח לאור מגוון השאלות השונות שיכולות לצוץ לאורך התהליך. במערכת מוכנה, על רוב השאלות כבר ניתנה תשובה כלשהי (גם אם היא לא אופטימלית).
5. עלות - שאלת העלות היא שאלה מרכזית ובמקרים של פיתוח אפליקציות, ניתן בקלות להיקלע למצב של זול שעולה ביוקר. ישנן מערכות קוד פתוח מצוינות שמסוגלות לתת מענה הולם ובעלויות נמוכות אולם במקרים אחדים, הפנייה למערכת מוכנה שהעלות הראשונית היא נמוכה יכולה להתברר כטעות קשה, כאשר כבר בשלבים מוקדמים, מגבלות המערכת מחייבות לעבור לתהליך פיתוח עצמאי ומה שנעשה עד אותו שלב למעשה נזרק. תפקיד הגורם המפתח בשלב הראשון הוא להציג את מידת היכולת להתאים ולפתח את המערכת בעתיד ומה העלויות הנגזרות מכך.
פתרונות ביניים
היום קיימים גם פתרונות ביניים שמאפשרים לקצר את זמני הפיתוח. דוגמא לכך הן frameworks כגון Ruby on Rails או Zend Framework. אלו למעשה תשתיות פיתוח הכוללות רכיבים קיימים לביצוע פעולות נפוצות באתרים וכך מקצרות תהליכי פיתוח. חשוב לזכור כי חלק מהפתרונות האלו יכולות להטיל מגבלה על יכולת מכירת המערכת וחשוב לברר את הנקודה הזו לפני שיוצאים לדרך. בכל מקרה, לטובת פיתוח על בסיס פתרונות ביניים, עדיין תידרשו לתכניתנים מנוסים שיוכלו לעשות שימוש במגוון היכולות של הסביבה לקיצור זמני פיתוח.
סיכום
במאמר זה ניסיתי להציג את השאלות המרכזיות שעליכם לשאול את עצמכם ואת חברת הפיתוח במידה והחלטתם לבחון באופן רציני פיתוח אפליקציה לרשת או הקמת אתר מתקדם. פרויקט מוצלח מתחיל בתהליך אפיון מסודר ויסודי שבסיומו הוגדרו עיקר הדרישות מהמערכת. חברות פיתוח שונות עושות שימוש בטכנולוגיות ואפליקציות שונות אולם עליכם לברר מה הפתרון המתאים ביותר עבורכם ושיוכל לאפשר לכם לממש את התכלית באופן ההולם, המשתלם והאפקטיבי ביותר.
