שישה טיפים שימושיים בתהליך פיתוח תוכנה

6 טיפים מעשיים ושימושיים בתהליך פיתוח תוכנה – כל תוכנה

program dev shutterstock

מאת אלכסנדר מזיאריק, מייסד-שותף בחברת Round Robin.

מי מכם שניסה לפתח תוכנה, או כל מוצר טכנולוגי, נתקל במוקדם או במאוחר בדילמה מהותית: מהי שיטת הפיתוח המתאימה ביותר למוצר שלי? מספיק חיפוש בסיסי ברשת כדי להבין שיש מספר רב של שיטות לבחור מהן, כל אחת והיתרונות שלה. אז איזו שיטת עבודה מתאימה לכם ביותר­ A​gile?
Waterfall ?Spiral? שפע המידע והאופציות יכולים להיות מאוד מבלבלים.

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

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

1. חפשו מהות

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

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

2. מנו מנהיג

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

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

3. כבדו את הדד-ליין

במידה ודחיתם דד-ליין שנקבע מראש כדי לאפשר לעצמכם הוספה של תכונות לגרסה, צר לי, אבל יריתם לעצמכם ברגל. עכשיו שאולי הלחצתי אתכם קצת, הרשו לי להסביר. תמיד אפשר להוסיף עוד תכונה, עוד מרכיבים שנראים חשובים: “אם נוסיף את זה­ יהיה ממש מגניב, ואיזה יופי אם נוכל לעשות גם את זה…” היכן עובר הגבול? לא תספיקו להגיד ג’ק רובינסון וכבר סטיתם מטיפ מספר 1: המהות.

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

4. זמן זה כסף, אל תבזבזו אותו

סבב פיתוח מוצלח לא צריך להימשך יותר מ- 45 ימי עבודה. הסבב כולל בתוכו את כל השלבים מתהליך האפיון הראשוני (המהות) ועד לשחרור הגרסה הראשונה (ה-­MVP). אני ממליץ לכם על​ סבב פיתוח המורכב מ-­1,000 שעות עבודה שמתחלקות בין 5 מפתחי​ם. נסו גם את השיטה הבאה: כל שעה אותה
מנהל הפרויקט מקדיש לניהול והכוונת המוצר תתורגם ל­-10 שעות פיתוח.

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

5. באגים ­ תמיד יהיו. תתמודדו

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

6. יש מקום לשיפור

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

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

בקיצור

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

תמונה: program dev via shutterstock

כתב אורח

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

הגב

16 תגובות על "שישה טיפים שימושיים בתהליך פיתוח תוכנה"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
HereToTalk
Guest

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

דורון
Guest

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

MrTech
Guest

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

Shepherd
Guest

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

MEAN.st.dev
Guest

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

B.O.
Guest

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

Shax
Guest

תודה רבה על המאמר! מאוד תמציתי וקולע.
MrTech, מה שאתה מתאר נקרא Soft Launch וזה אכן יעיל גם לבדיקות שיווקיות (התכנות קהלי יעד וכד’) וגם לבדיקות של המוצר עצמו.

Oleg
Guest

“גרסה 0.1 לא יכולה להיות
הגרסה המושלמת, אבל היא כן יכולה להביא לכם תוצאות מושלמות”
אפשר דוגמאות?

דור
Guest

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

Splint
Guest

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

Adam
Guest

מצטרף לשאלתו של Oleg. אולי הכוונה לגרסא 1.0? לא ברמה הסמנטית אלא ברמת רמת הגימור של המוצר?

Ophenix
Guest

Good tips

Sven
Guest

תודה! חומר למחשבה.
בעיקר סעיף 4 עם סבבי העבודה המוגדרים לפי שעות.. שווה לנסות.

שלי שץ
Guest

האם אפשר ליישם את שיטת העבודה של agile אם אנחנו צוות קטן של 3 אנשים

Round Robin
Guest

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

KG
Guest

תמציתי וקולע! מצפה בכיליון עיניים לכתבות עתידיות שכאלו.

wpDiscuz

תגיות לכתבה: