אחרי שדיברנו על כיצד לעשות ארכיטקטורת תוכנה בצורה טובה יותר, הגיע הזמן לפתוח את הקלפים ולראות איך אנחנו מביאים תוצר עובד שמתאים לארגון שאנחנו עובדים בו.
אמנם דיברנו כבר בעבר על כלי הפיתוח הנכונים, איך מגייסים את אנשי הפיתוח הנכונים ואיך מכשירים מהנדסי תוכנה, אבל הפעם נדבר על תרבות ארגונית, צרכים עסקיים ואיך זה מתחבר לקוד שאנחנו כותבים.
מיתוס מספר 1: כל פרויקטי התוכנה נכשלים
לא כל הפרויקטים נכשלים. אבל סטטסיטקות מעודכנות של Standish Group מצביעות ש - 95% מהפרויקטים שנמשכים מעל שנתיים נכשלים! אלו כמובן החדשות הרעות. החדשות הטובות הן שאם נבין למה יש 5% שמצליחים, נוכל לבצע את הדברים הנכונים גם אצלנו. לשם כך נצטרך לשבור כמה מיתוסים.
מיתוס מספר 2: פרויקטים נכשלים כי אין להם מספיק משאבים
הוספת שולי בטחון לפרויקט והגדלת רמות הניהול (שמתרגמות בסופו של דבר לדיוני סטטוס בני שעתיים שבהם חצי מהאנשים המשתתפים לא רלוונטיים), תגרומנה באופן פרדוקסאלי להגדלת הפרויקט ולפי הגרף לעלייה בסיכוי לכשלון. אם נעיף מבט נוסף בגרף נראה שפרויקטים קצרים מגיעים ל - 60% הצלחה, ולכן הפתרון לעיתים יהיה להקטין את הפרויקט: הקטנת תכולה, הקטנת זמנים, פישוט ארכיטקטורת התוכנה וקיצור יעדים.
מיתוס מספר 3: יש רק שיטת ניהול פרויקטים אחת והיא עובדת לכל פרויקטי התוכנה
בקורסי ניהול פרויקטים מתרכזים בעיקר בשימוש בגאנט וניהול פרויקטים בשיטה הקלאסית Waterfall. בשנים האחרונות החלו להופיע מספר שיטות חדשות שמביאות מענה לצרכים עסקיים שונים של חברות. הראשונה בהן היא מתודולוגיית ה - Agile המתמקדת בעבודה עסקית בסבבים קצרים יותר, תוך שימוש בהיזון חוזר מהסביבה (אנחנו נעסוק בה בפוסטים הבאים, אבל בינתיים מומלץ שתעיפו מבט בבלוג המצויין של אלעד סופר שעורך גם את מפגשי ה - Agile practitioners IL). מתוך מתודולוגיה זו צמחה שיטת ה - SCRUM שדוגלת בשחרור גרסאות עובדות מדי 2-5 שבועות. שיטה חדשה עוד יותר שהופיעה רק בשנתיים האחרונות היא ה - Continuous Deployment. שיטה זו מוטמעת כבר במספר חברות בישראל ודוגלת בשחרור גרסאות לייצור מסביב לשעון (או בעברית פשוטה יותר עשרות גרסאות חדשות בייצור מדי יום). השיטה הזאת מתאימה בעיקר לגופי תוכנה שמספקים שירות ללקוחות פנימיים או חיצוניים וגם בה נדון בשבועות הקרובים.
מיתוס מספר 4: אני מנהל פיתוח בסטארט אפ, השיטה הזאת לא מתאימה לי, היא מתאימה רק לחברות גדולות!
אז זהו, שלא כל החברות זהות, גם אם מספר העובדים בהן דומה ואפילו אם הן עוסקות באותו ענף. ההחלטה על שיטת ניהול פרויקטי התוכנה צריכה להלקח על בסיס מאפייני הארגון, צוואר הבקבוק הארגוני שלו והתרבות הארגונית. אם הכוונה שלך במילה סטארט אפ היא "חברה ללא הררכיה מסודרת עם רמת הגדרת מוצר נמוכה, חוסר ודאות לצרכי המשתמשים ותרבות ארגונית שמבוססת על ניצול הזדמנויות" אז ככל הנראה החסם שלכם בארגון הוא השוק וההיזון החוזר ממנו. אמנם תיאור זה מאפיין ארגונים של 3 אנשים שייסדו את החברה לפני חודש עם מושג מועט לגבי השוק, אבל הוא גם מאפיין חברות גדולות בהרבה (דוגמה טובה לכך תמצאו בפוסט על השלבים הראשונים בפיתוח מוצר ב - Google).
Posts
0 comments:
Post a Comment