הקמת פרוייקט

בפעם הבאה שאתם חושבים שהפרוייקט מתעכב מעבר למה שחשבתם, תקחו בחשבון שלבנות טויוטה לוקח 13 שעות ורולס רויס חצי שנה…

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

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

הטכנולוגיות

איזה טכנולוגיה לבחור בשביל הפרוייקט?

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

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

1. זמן פתוח מהיר יותר.

2. מהירות ריצה גבוהה יותר.

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

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

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

הרעיון, הצוות

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

55d0a9b11df41c06ac462b1e
מנהלי פרוייקטים והתפיסה שלהם על בניית המוצר.

תאום ציפיות

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

אפיון.

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

בנה את הדברים נכון מהיום הראשון.

איכות, היא לא מילה גסה.
איכות, היא לא מילה גסה.

הדטה בייס:

בניית הדטה בייס היא הבסיס אבל היא לא אומרת לנו שום דבר על ה UI, אך אם הדטה בייס בנוי לא נכון אנחנו נאבד זמן מאוד יקר בשינוי פיתוח כי הדטה בייס הוא הבלו-פרינט שלנו והשינוי שלו במהלך הפיתוח שקול לשינוי מבנה החדרים בדירה לאחר שסיימו לסייד אותה. סוג הדטה בייס תלוי בסוג הפרוייקט, זה בסדר גמור גם להיות תלויים בידע שאנשים מסוימים מביאים למערכת, שוב ניתן יהיה לשנות את הדטה בייס ולעבור מ SQL SERVER ל MONGO  וכו, אבל תמיד יהיה נחמד לקבל את ההחלטה שתשאר איתנו לאורך זמן רב, אם מדובר בדטה בייס ריאלציוני או משהו אחר, כדאי להתייעץ גם אם אנשי מקצוע, לרוב SQL SERVER יספיק, אבל בפרוייקטים שמצריכים דטה ענק ומהירות שליפה גבוהה יש פתרונות אחרים, בין עם מדובר בתשתיות DB של אמזון, מונגו, או מערכות אחרות.

UI – UX

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

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

לעשות את הדברים פשוט, זה הרבה יותר מסובך ממה שחושבים
לעשות את הדברים פשוט, זה הרבה יותר מסובך ממה שחושבים

תשתית SERVER CLIENT

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

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

א. MODEL

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

ב. BLL

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

ג. SERVICES

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

ד. אתר האינטרנט. SITE

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

ה. ADMIN

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

אפליקציות

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

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

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

ענן או שרת ייעודי

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

Growth Hacking

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

MARKETING

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

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

הדרך להצלחה רצופה קשיים..

הנתיב להצלחה מסובך יותר ממה שאנשים חושבים
הנתיב להצלחה מסובך יותר ממה שאנשים חושבים

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

שינוי צריך להגיע ממקום נקי
שינוי צריך להגיע ממקום נקי

וזכרו תמיד לעבוד עם מקצוענים, דברים זולים עולים ביוקר…

קחו רק מקצוענים, זה אולי נראה שהם עולים יותר.
תמיד יהיה מישהו זול יותר

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

שאלות ופניות ניתן לקבל דרך דף צור קשר