פוסטים מתוייגים פרויקטים
תע"ר – מתודולגיה לניהול פרויקט
פורסם על ידי גיל פרוינד תחת ניהול בתאריך 1 בדצמבר 2008
איש מכירות הסביר לי כי החברה שהוא מייצג היא אמריקאית, וחברות אמריקאיות לוקחות את ניסיונן ומיצרות ממנו מתודולגיות עבודה. הרעיון נשא חן בעיני, והחלטתי לפרסם מתודולוגית עבודה לניהול פרויקטים שנתקלתי בה לא מעט פעמים, אם אינני סבור שגובשה בצורה מסודרת. קבלו את תע"ר.
תע"ר – ראשי תיבות1 לתרנגולת ערופת ראש2. מתודולוגיה מונחית מבחן תוצאה להתמודדות עם מצב משבר בפרויקט.
הצורך בתע"ר נובע מהעובדה כי הטלת אחריות פשוטה לגורם אחר בארגון או מחוצה לו היא פאסה, נלעסה עד דק3, ואינה מעניקה למשתמש בה תועלת. במקרה הטוב, היא מונעת מהמשתמש נזק. זאת היות והטלת אחריות פשוטה היא תהליך פסיבי וראקטיבי.
כיצד פועלת מתודולוגית תע"ר:
במצב של משבר בפרויקט4, אין לבוא בטענות אל הגורם האחראי האמיתי של המשבר בצורה ישירה5. יש להאשים את כולם.
דא עקא, שלא ניתן להאשים את כולם. כך כאן טמון היופי האמיתי של תע"ר. יש לגייס כל מי שאיננו בעמדת מואשם לסייע בפתרון הבעיה.
דוגמה פשוטה:
מכונת הקפה לא עובדת. יש לבוא בטענות אל:
לאחר מטח הטענות הראשון יש לירות את מטח הטענות השני:
כטת מגייסים את יחידות העתודה ששמרנו.
חשוב מאוד, בכל שלב, להפנות את הטענות לגורם שמעורבותו בפרויקט נמוכה ככל האפשר. במידה והדבר אינו מסתייע, ניתן לנקוט מסלול חליפי ולפנות למנהל, כפיף או מקביל. כך ניתן לקבל אפקט שימושי של טלפון שבור.
לא פחות חשוב, לקיים את השלב השני בקול רם, ולערב כמה שיותר גורמים בארגון. עם זאת יש להקפיד לדווח לכל גורם בארגון בנפרד.
התוצאות מרשימות. ספקי המשנה, כמו גם הגורמים המעורבים בארגון, יהיו מתוחים וחשדנים המטענות המופנות אליהם. חלקם ינסו להסביר, חלקם ינסו להתחמק. בכל מקרה הארגון יראה כי משתמש התע"ר צדק. בתוך הארגון, מחלקות אליהן מופנות טענות, או שמהן מבקשים עזרה, ישקיעו זמן ומשאבים להבין מה בכלל הבעיה, או בלפשר בין מחלקות הניצות זו בזו.
תע"ר איננה מתודולוגיה טריוויאלית, והיא דורשת הכנה מראש:
חשוב לזכור שתמיד יהיו גורמים, בארגון או מחוצה לו, שינסו לטרפד את השימוש במתודולוגיה תע"ר. השיטות עלולות להיות מתודולוגיות – כמו ניהול סיכונים, בדיקות ישימות או בקרת איכות רחמנה ליצלן. כמו כן עלולים להשתמש בשיטות מכניות זולות של סיכומי פגישות, רשימת מטלות או שיקוץ הגנט.
נגד השיטות המתודולגיות קל להתמודד, הן יקרות, גוזלות זמן ולא נותנות מידע שאנו כבר יודעים.
למרבית ההפתעה, עם נגד השיטות המכניות לא קשה להתמודד. הזכרון הפרטי שלנו תמיד יהיה טוב יותר מסיכומי פגישות שנערכות אי אז לפני זמן. עובדה, התחזית האורווליאנית של 1984 לא התקיימה…
שווה ז….
פורסם על ידי גיל פרוינד תחת משולחן היועץ, משולחן המנמ"ר בתאריך 25 בנובמבר 2008
למה גסות הרוח? בעיקר כאשר אני רוצה להפנות למאמר מצוין בכלכליסט.
הסיבה היא הנימוק שנתן לי בעל חברה למדיניות התמחור שלו, ומדוע הוא פיטר את המנכ"ל שלו.
אם אני מחייב כזונה, משלמים לי כמו לזונה ומתיחסים אלי כאל זונה.
אם אני מחייב כנערת ליווי, אני עושה את אותו דבר, רק משלמים לי יותר ונותנים לי מעט יותר כבוד.
בסופו של יום אני עושה את אותו דבר.
החברה, מהכרותי עמה, נותנת שרות ברמה גבוהה יותר ממרבית המתחרים שלה. עם זאת, המנכ"ל היה נואש למכור פרויקטים, עד כדי מתן הצעות במחירי עלות, או אף בהפסד. הפחד שלו מהפסד של פרויקטים למתחרים גרם לחברה להראות נואשת.
ישבתי משני צידי השולחן, כלקוח וכנותן שרות. פחד וחוסר בטחון של צד אחר, בעיקר מצד נותן השרות, גורם לצד השני להריח דם. התוצאה היא רעה לשני הצדדים, היות ואז נגמר המשא ומתן. יש התמקחות או התנתקות.
בהתמקחות, רק הכסף משחק, והמשחק הוא "איך לדפוק את הצד השני". בהתנתקות, אין המשך, לפחות לאחד הצדדים.
לצאת לעולם
פורסם על ידי גיל פרוינד תחת משולחן היועץ בתאריך 18 ביוני 2008
אחרי כמעט 20 שנה כעצמאי, הפכתי לשכיר. זהו תהליך הפוך לתהליך העובר על לא מעט אחרים. ולעיתים אני נשאל על המעבר משכיר לעצמאי1.
לפני כחמש שנים מילאתי שאלון הבוחן את יכולתי להיות עצמאי. כמובן שנכשלתי בגדול…
היתרונות בעצמאות:
חסרונות
כמה אבחנות:
קוד פתוח כנייר הלקמוס
פורסם על ידי גיל פרוינד תחת מערכות מידע בתאריך 2 באוקטובר 2007
כאשר אני מגלה אתר חדש, אני פותח אותו בשועל האש. כאשר אני בוחן מערכת העובדת עם מסמכים, אני מנסה אותה מול OpenOffice.
ישנם עוד דפדפנים וישנן עוד חבילות משרדיות. המטרה שלי איננה לבדוק תאימות של התכנה לכל סביבה אפשרית, אלא את נכונות המפתח להתמודד מול סביבה משתנה וצרכים משתנים. אני חסיד של מערכות הבנויות לפי סטנדרטים פתוחים. ומערכות קוד פתוח נוטות יותר לכוון זה.
הנטיה של מפתחי קוד פתוח לסטנדרטים פתוחים איננה רק אידאולוגית, אלא גם טכנית. פרויקטים רבים הם קטנים או מורכבים מקהל של מפתחים המפוזרים גאוגרפית ובין חברות שונות. שמירה על סטנדרטים מבטיחה שיתוף פעולה בתוך הפרויקט ובין פרויקטים.
הדבקות בסטנדרטים פתוחים יכולה להיות דראקונית לא פחות מדבקות בטכנולוגיות קנייניות. הראיה היא בקושי להתמודד עם דואר זבל תוך שמירה על פרוטוקול SMTP המשמש למשלוח דואר מקדמת דנא.
סטנדרטים פתוחים יכולים גם לקום מסביבות קנייניות. מבנה ה-PDF של Adobe הוא דוגמה מצויינת לכך. כיום ניתן לייצר ולקרוא קבצי PDF ללא כל שימוש בכלים מבית היוצר של Adobe.
מה הערך המוסף למשתמש. בקצרה: אריכות ימים. סטנדרטים מאריכים ימים יותר מטכנולוגיה. שינויים בסטנדרטים מלווים בתהליך ביקורת חיצוני מקיף יותר, ועל פי רב כוללים תיעוד רב יותר של ההבדלים והשינויים.
אין זה מפתיע, אם כן, שפרויקטים של מעבר אל ומ-MS-SQL, ושידרוגי גרסאות בסביבה זו הם מהירים ובעלי פחות נטיה לכשלים מפרויקטים דומים על סביבת MS-Access. שניהם מוצרים מבית תוכנה קינייני וסגור, אך MS-SQL הוא מוצר התואם לסטנדרטים של ANSI-SQL, ו-MS-Access לא.
כמובן, התמונה לא תמיד פשוטה כל כך. לשועל האש ול-Internet Explorer (כמו גם לדפדפנים אחרים) יש נטיה לפרש תגיות סטנדרטיות בצורות שונות, כך שהיישום הוא לא פחות חשוב מהסטנדרט.
-
עוד אני
ידע
פרסומות
