ניהול דרישות – Requirements Management הוא מהיסודות החשובים של ניהול תוכנה ומערכות IT. אין כמעט פרויקט או תהליך פיתוח של מוצר שלא מתחיל (צריך להתחיל!) בהגדרה ברורה של הדרישות מהמערכת, ברמה זו או אחרת. אין כמעט פרויקט או תהליך פיתוח של מוצר שלא צריך לוודא, במהלך הפיתוח והבדיקות, שהדרישות מהמערכת אכן ייושמו, ברמה זו או אחרת. ניהול דרישות הוא הממשק המרכזי בין משתמשי הקצה ומומחי היישום ובין יחידת IT, בין הלקוח ובין הספק, בין האפיון לפיתוח, בין המהדורה הנוכחית ומהדורות עתידיות. עקיבות הדרישות (Requirements Traceability), מלווה במנגנון ניהול תצורה ושינויים, היא דרישת על מרכזית בניהול הפרויקט ובניית המערכת.
במאמר זה ננסה להראות שהגדרה ברורה של סוגי הדרישות והבחנה ביניהן, כולל הקפדה על שמות ברורים שאנו מציעים: דרישות-על (תע"ש), דרישות מערכת ודרישות שוטפות, הן הבסיס לתווית הקשרים הנכונים ביניהן.
MOSS הוא פלטפורמה למימוש פורטל ארגוני. במוקדם או מאוחר, כל ארגון קטן כגדול נאלץ להתמודד עם סוגיות של שיתוף והפצת מידע, קטלוג ואחזור מידע, כגון: רשימות ניהול, מסמכי עבודה, נהלים ועוד. החבילה הבסיסית (הפלטפורמה) של מערכת MOSS, כפי שהיא Out of the box, מספקת מגוון יכולות מובנות לניהול תוכן ולניהול תהליכים עסקיים. הבנה של "גבולות הגזרה" של החבילה, ומה ניתן לממש ביישומי פורטל, היא תנאי חשוב לייזום נכון של הפרויקט, לניהולו לאורך מחזור חיי המערכת, כולל שינויים וצרכים חדשים.
השאלות בפניהן ניצב מנהל המחשוב הן שאלות מתודולוגיות ועסקיות, לצד שאלות טכנולוגיות. הדרך הטובה ביותר לענות על שאלות אלה היא בעזרת דוגמאות שונות למימושים בעזרת MOSS: MOSS כאתר תוכן, MOSS כמערכת מידע ועוד.
תכנית עבודה שנתית היא המכשיר המרכזי של יחידת IT לתכנון וניהול שוטף של הפעילות הכוללת של היחידה: הקצאת משימות לעובדים, תחזוקת מערכות וניהול פרויקטי פיתוח - במטרה לענות על דרישות המשתמשים והתהליכים העסקיים של הארגון (האם).
מטרת מאמר זה היא "לעשות סדר" בנושא, לפרק אותו למרכיביו הבסיסיים ובכך להתוות "מפת דרכים" לארגון: איך ליישם תכנית עבודה שנתית, צעד אחר צעד ואיפה אולי לעצור ולהחליט ש"עד כאן". גם ארגונים שכבר מיישמים תע"ש ברמה זו או אחרת, יוכלו להיעזר במאמר זה, לבחון בעזרתו את "המצב הקיים" ולהתוות את הצעד הבא.
האם הדיונים שלנו הם תכנון? תכנון נכון ואפקטיבי? אם כן, אז אולי אנחנו משקיעים פחות מדי בדיונים! אם לא, אז אולי באמת כדאי לחסוך אותם, או לחפש אלטרנטיבות.
את השאלה האסטרטגית המרכזית הזו ישאל כל אחד את עצמו. אנחנו מבקשים, במאמר זה, לתקוף את הנושא מההיבט הטקטי והמעשי. מי וכיצד מחליט שיש צורך בדיון, איך הדיון מתנהל? איך מזמנים פגישה? איך מוודאים שתוצאותיה מוזנות לתכניות העבודה? נחזור כאן על דברים בסיסיים שכולנו מכירים רק אולי לא תמיד מקפידים לקיים; ואולי גם נחדש כמה דברים.
מיקרו-משימות, או מיקרו-תוצרים (Micro-deliverables), מאפשרים לאמוד ביעילות את בריאות הפרויקט. פול גלן מציע ארבע כללים פשוטים שיש לנהוג על פיהם כאשר מתכננים ומשתמשים במיקרו-תוצרים.
לארגונים אין מושג כמה באמת עולה להם הפלט והם מבזבזים מיליוני שקלים בכל שנה. כדאי שיטפלו בזה לפני שהם למשל מפטרים עובדים...
תהליך מחשוב מורכב משלושה תהליכים פשוטים: קלט, עיבוד ופלט. הגיע הזמן לטפל נכון בכל הפלט ולא רק בקצה הקרחון שלו – ההוצאות על המתכלים.
"תחקורים" הוא נושא שמעורר עניין רב ו"תופס כותרות" חדשים לבקרים, הן בציבור הרחב והן בקהילייה המקצועית. מאמר זה מתמקד בהגדרה של סוגי ה"תחקורים" השונים ומחלקם לשתי קבוצות עיקריות: תחקורים בסיסיים ותחקורים משולבים (מורכבים) הבנויים ע"ג התחקורים הבסיסיים. המאמר מתמקד, כאמור, בהגדרת סוגי התחקור, אך מפנה גם למקורות מידע נוספים המפרטים איך בדיוק יש לבצע כל סוג של תחקור.
MethodPLC היא מתודולוגיה למימוש מתודולוגיות ותהליכי מחזור חיים בארגון, כאשר בבסיסה נמצא"משולש הזהב". שלושת קודקודי המשולש הם: מתודולוגיה, תיקיית (פורטל) הפרויקט, מידע ניהולי.
מפת"ח, כמו כל מתודולוגיה אחרת, איננו מוצר בר-חלוף, סטארט-אפ שהיום הוא פה ומחר איננו. מפת"ח שייך לכל אותם כלים ושיטות שמטרתם לשפר בעקשנות ולאורך זמן את הנושא הסבוך של ניהול פרויקטים והנדסת תוכנה. למפת"ח יש אורך נשימה והוא רץ למרחקים ארוכים. מפת"ח הולך ומשתכלל כל הזמן הן בתכנים והן בצורה ובשימושיות והוא איתנו כאן לעוד שנים רבות.
השילוב בין ITIL, שהוא מסגרת מתודולוגית לניהול תשתיות מחשוב ושירות, ובין מפת"ח, שהוא מתודולוגיה לפיתוח ותחזוקה של מערכות ממוחשבות, שורשיו עוד בשנות ה- 90 בהם פותח נוהל מפת"ח ע"י מתודה עבור ממשלת ישראל, משרד האוצר.
