בינה מלאכותית לניהול פרויקטים

שלושה עובדים, שניים מדומים

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

למה חיזוי נכשל, ומה לעשות במקומו

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

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

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

סיכום פגישות: הגבול שחייב להיות

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

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

שלושה כללים פותרים את זה:

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

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

חיפוש על ההיסטוריה: מה הופך אותו לשימושי

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

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

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

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

לא להחליף את הכלי

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

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

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

איך אני עובד על זה

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

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