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

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

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

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

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

1. תקשר בבהירות

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

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

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

2. שאפו לפשטות

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

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

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

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

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

3. שקול מורכבות

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

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

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

"המורכבות הבסיסית של רעיון קיימת ללא קשר להכרה שלנו בו", אומר ג'ונסטון.

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

4. הכר את האילוצים שלך

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

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

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

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

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

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