מדריך מעשי לבניית כלים פנימיים לעסק: איך מזהים את התהליך שצריך כלי, למה רוב הכלים הפנימיים ננטשים, מסלול הבנייה מתהליך ידני מבולגן לתוכנה, ואיך שומרים בעלות במקום להוסיף עוד כלי שאף אחד לא מתחזק.
צוותי תפעול, מנהלות משרד, יזמים ועסקים בצמיחה שמריצים תהליך קריטי על צעדים ידניים, הודעות צ׳אט וזיכרון.
- דרך לזהות איזה תהליך ידני באמת צריך כלי
- מסלול בנייה מתהליך מבולגן לתוכנה שאנשים סומכים עליה
- כלי פנימי שבבעלותכם ואפשר לשנות, לא עוד פריט ב-backlog
כל עסק בצמיחה רץ על כמה תהליכים שחיים בשום מקום: אישור שקורה בצ׳אט, העברה שנעקבת בראש של מישהו, סטטוס שכולם שואלים עליו כי הוא לא כתוב בשום מקום. אלה מה שכלים פנימיים בשבילם. הסיבה שכל כך מעטים נבנים היא כבר לא עלות; היא שהם אף פעם לא עלו מעל ה-backlog של הפיתוח. המדריך הזה עוסק בבניית הנכון בעצמכם, כדי שהוא באמת ייבנה.
התהליך שצריך כלי הוא זה שאנשים ממשיכים לשאול זה את זה עליו, זה שהעבודה נתקעת בו בהמתנה להעברה, וזה שמוחזק כרגע בהודעות צ׳אט וזיכרון. אם שאלה חוזרת בצוות שלכם היא גרסה כלשהי של "מה הסטטוס של X?" או "אצל מי Y עכשיו?", השאלה הזו היא האפיון: הכלי קיים כדי להפוך את התשובה לגלויה בלי שאף אחד יצטרך לשאול.
כלים פנימיים לא עוסקים בהחלפת אנשים; הם עוסקים בהסרת מס התיאום שגדל עם הצוות. עסק של חמישה אנשים מתאם בראש. עסק של עשרים שעדיין מתאם בראש מבזבז חלק גדל והולך מכל יום על עדכוני סטטוס, רדיפה אחרי אישורים, והסבר מחדש איפה הדברים עומדים. התקורה הבלתי נראית הזו היא בדיוק מה שכלי פנימי ממוקד מסיר, ולכן הכלי הראשון הנכון מכוון לתהליך שמדמם הכי הרבה זמן לתיאום.
בוחרים לפי כאב, נמדד בכנות. תבזבזו כמה ימים על שימת לב איזה תהליך מייצר הכי הרבה "שאלות מהירות", הכי הרבה העברות שנופלות, הכי הרבה "חשבתי שאתה עושה את זה". המנצח הוא לעתים רחוקות התהליך הכי מורכב; הוא המתואם בתדירות הגבוהה ביותר.
כלים פנימיים נכשלים מסיבות צפויות, ולדעת אותן מראש זה רוב מה ששומר על שלכם בחיים.
כלי פנימי עובד כשלהשתמש בו קל יותר מלא להשתמש בו. לפני שאתם מוסיפים פיצ׳ר, תשאלו אם הוא הופך את הכלי למהיר יותר או איטי יותר לשימוש. רוב הכלים הפנימיים הנטושים מתו מכוונות טובות: שדות שמישהו אולי ירצה, צעדים שהרגישו יסודיים, שכולם הכבידו את המסלול היומי עד שאנשים ירדו ממנו.
המעבר מתהליך-בראש-של-אנשים לכלי עוקב אחר רצף אמין. לדלג על הצעד הראשון זו הסיבה שכל כך הרבה כלים פותרים את הבעיה הלא נכונה.
התהליך הכי גרוע של צוות לוגיסטיקה היה השאלות ציוד: אצל מי איזה מכשיר, ממתי, והאם באיחור, הכל נעקב בערוץ צ׳אט ובזיכרון של אדם אחד. אחרי שבוע של צפייה, זה הפך לארבעה דברים: נכסים, אנשים, השאלות, ומצב הוחזר/באיחור. גרסה ראשונה נתנה לכל אחד להשאיל מכשיר, הראתה את סטטוס כל הצי במסך אחד, וסימנה פריטים באיחור אוטומטית. שאלת ה"אצל מי הסורק?" היומית פשוט נפסקה, כי המסך ענה עליה.
ההבדל בין כלי פנימי שחי לאחד שמת הוא בדרך כלל לא פיצ׳רים; הוא אם הצוות יכול לשמור אותו מתאים למציאות. שני דברים מגנים עליו.
זה איפה שלתאר את התהליך ולקבל כלי שנבנה סביבו מנצח גם תבנית קשיחה וגם סקריפט חד-פעמי ממפתח שממשיך הלאה. מקבלים תוכנה שמעוצבת לתהליך העבודה האמיתי שלכם, שאפשר להמשיך לעצב מחדש ככל שהתהליך מתפתח, בלי להצטרף שוב לתור הפיתוח כל פעם. הכלי נשאר בחיים כי האנשים שמריצים את התהליך יכולים לשמור אותו כן.
מכוונים לתהליך שאנשים ממשיכים לשאול זה את זה עליו ושהעבודה נתקעת בו בהעברות. תבזבזו כמה ימים על שימת לב איזה מייצר הכי הרבה "שאלות מהירות" והעברות שנופלות; התהליך המתואם בתדירות הגבוהה ביותר, לא המורכב ביותר, הוא איפה שכלי מסיר הכי הרבה זמן מבוזבז.
כי הם פותרים גרסה מסודרת של התהליך במקום האמיתי, כי לעדכן אותם איטי מהודעת הצ׳אט שהם החליפו, כי הם לא יכולים להשתנות כשהתהליך משתנה, או כי הם הופכים לסילו נתונים. התיקון הוא לצפות בעבודה האמיתית קודם, להפוך את הכלי למסלול המהיר ביותר, ולהיות מסוגלים לשנות אותו בעצמכם.
רק את המסלול הראשי: ליצור את הרשומה, להעביר אותה בין המצבים האמיתיים שלה, לראות את הסטטוס ולהעביר, פלוס התפקידים שמחליטים מי עושה מה ומי רק צריך לצפות. מוסיפים את החריגים שבאמת ראיתם, לא מדומיינים, ומשאירים כל דבר אחר לאחרי שאנשים משתמשים.
כבר לא, ולבנות בעצמכם יש יתרון אמיתי: תהליכים פנימיים משתנים כל הזמן, אז כלי שאפשר לערוך כשהתהליך זז נשאר שימושי, בעוד אחד שצריך כרטיס פיתוח לכל שינוי סוטה מהמציאות וננטש. תארו את התהליך ושמרו את היכולת לשנות אותו.