מה כדאי לסטודנט לדעת- קוד פתוח

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

ויקיפדיה:

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

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

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

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

מה

אז מה זה קוד פתוח?

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

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

הקהילה

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

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

אז איך החברה מרוויחה כסף?

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

בסופו של דבר, תוכנות קוד פתוח הם לא משהו נדיר, וניתן למצוא ביניהם את:

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

אז למה עכשיו, כשאני באמצע תואר עמוס, אני צריך לעבוד בחינם אצל חברה אחרת?

אני חושב על ארבעה סיבות עיקריותף מוזמנים לשתף אותנו בעוד סיבות:

  • חשיפה לקוד מקצועי
  • עבודה בצוות
  • השתלבות בקהילה
  • קורות חיים

חשיפה לקוד מקצועי

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

עבודה בצוות

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

השתלבות בקהילה

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

קורות חיים

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

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

איך

אז עשיתי חשק? מעולה! איך מתחילים?

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

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

  • מודעות
  • השתתפות
  • יוזמה

מודעות

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

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

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

השתתפות

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

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

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

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

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

יוזמה

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

יש הרבה פרויקטים זמינים, ואפשר לחפש באינטרנט, לקבל המלצות, להשתמש בקישורים פה למטה ועוד. יש פרויקטים שממש משקיעים בקבלת תורמים חדשים (למשל NodeJS אם אני לא טועה), יש פרויקטים שמסמנים דיונים מסוימים כמתאימים למתחילים (up-for-grabs), ויש פרויקטים שאף אחד כבר לא נוגע בהם (נסו לראות מתי מישהו שינה שם משהו בפעם האחרונה).

קישורים

  • Github הוא האתר הנפוץ ביותר לאחסון, שיתוף ועבודה על פרויקטים בקוד פתוח.
  • רשיונות– אמנם הקוד הוא פתוח, אבל יש רמות שונות של פתיחות. אחרי הכל, אני אשמח לשתף את הקוד שלי, אבל לא כדי שמתחרה שלי ינצל את זה כדי למכור את המוצר שלי בזול יותר. Github מציעים דף נחמד שעוזר לנו לבחור את הרשיון המתאים לנו.
  • up-for-grabs היא תגית נפוצה לדיונים, באגים ופיצ'רים שמתאימים למפתחים שרוצים להיכנס לקוד.
  • המקור היא עמותה ישראלית לקידום קוד פתוח. הם מקיימים מפגשים (Meetup) לקהילה ועוזרים לסטודנטים כמונו (ולא רק) להיכנס לעולם הקוד הפתוח.
  • למה לי קוד פתוח עכשיו– פרק של הפודקאסט המומלץ מפתחים חסרי תרבות על קוד פתוח.
  • איך להתחיל בעולם הקוד הפתוח– פרק של הפודקאסט עושים תוכנה על כניסה לקוד פתוח.

יש לי רעיון לסטארטאפ- התאמת מחשב

אז- יש לי רעיון לסטארטאפ!

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

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

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

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

מודל עסקי

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

(ויקיפדיה)

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

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

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

Lean Canvas

Lean Canvas מהאתר http://www.businessmodel.co.il
Lean Canvas מהאתר http://www.businessmodel.co.il

כל התוכנית העסקית נמצאת בלוח שלמעלה.

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

לפני שנתחיל

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

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

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

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

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

הבעיה

בשלב הראשון נצטרך להגדיר את הבעיה.

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

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

הלקוח:

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

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

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

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

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

הצעת הערך

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

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

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

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

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

האם הצעת הערך שלי עונה על הבעיות של הלקוחות?

הפתרון

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

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

שאלון הדרכתי (כלומר, השאלות יהיו רחבות עם הסברים) על המאפיינים האישיים (עיסוק, תוכנות) ועל דרישות מהמחשב (הסבר מה זה RAM ומה ההשפעה שלו).

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

ייתרון תחרותי

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

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

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

הכסף והעלויות

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

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

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

מדדי הצלחה

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

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

הצלחה היא משתמשים רבים בשירות, ופידבק חיובי על תוצאות המערכת.
נגדיר 50 כניסות לחודש, עם 70% פידבק חיובי על הצעות.

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

ערוצי הפצה

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

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

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

פרסום ברשתות החברתיות, מודעות בחנויות מחשבים, פרסום ממומן.

זהו, עד כאן.

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

קישורים:

מה כדאי לסטודנט לדעת- CI/CD

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

אחרי הפוסטים של טסטים וגיט, הגיע הזמן לשילוב שלהם- תהליכי CI/CD.

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

  • CI: אינטגרציה רציפה (continues integration), כלומר, רציפות של איחוד הקוד המקומי עם הקוד המשותף.
  • CD: מסירה רציפה (continues deployment), כלומר, העברה רציפה של הקוד מסביבת הבדיקות לסביבת השימוש.

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

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

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

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

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

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

CI

השלב הראשון הוא Integration- איחוד של הקוד. השלב הזה מתמקד בפעולות שמסייעות למפתחים לשלב את הקוד שלהם בקוד הכללי ולקבל פידבק מהיר על ההשפעה של השינוי שלהם על שאר הקוד.

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

תהליך הCI מתמקד בבדיקות, ולכן נפגוש אותו כשנעשה Pull Request, והוא יריץ בדיקות קצרות (בדרך כלל build וUnit tests לפחות) כדי לוודא בצורה בסיסית שאין בעיה קריטית בקוד, ושאנחנו יכולים לבצע Merge.

לאחר מכן תהליך CI אחר יריץ בדיקות מלאות יותר, מUnit tests ועד e2e (ר"ת End to end), ואולי גם בדיקות על שרתי טסטים וכד'.

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

CD

תהליך הCD בא אחרי תהליך הCI, ותפקידו הוא להוציא את המוצר ללקוחות. החלוקה לא בהכרח תהיה ברורה, לא בהכרח נשתמש בכלי אחר או בשיטה אחרת לביצוע תהליכי הCD. ההבדל הוא בעיקר מבחינת החברה, מבחינת תשומת הלב שניתן לכל אחד, ובאופן כללי- ההבדל הוא בשביל הנוחות שלנו.

למה אני מתכוון?

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

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

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

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

לקריאה נוספת:

  • ג'נקינס– ג'נקינס היא תוכנת קוד פתוח לביצוע תהליכי CI/CD. ניתן להתקין אותה על כל מחשב (המחשב האישי, שרת החברה, שרת בענן) ולהגדיר פעולות לביצוע.

מושגים לשפה המקצועית:

  • CI: אינטגרציה רציפה (continues integration), כלומר, רציפות של איחוד הקוד המקומי עם הקוד המשותף.
  • CD: מסירה רציפה (continues deployment), כלומר, העברה רציפה של הקוד מסביבת הבדיקות לסביבת השימוש.