מדיטק (השם האמיתי שמור במערכת) הייתה חברה צעירה ונלהבת בתחום המכשור הרפואי. המוצר הראשון שלה היה מוניטור לניטור מדדים רפואיים, כזה שיאפשר מעקב רציף אחר חולים בבתי חולים ואפילו בבית. עם ההשקעה הראשונית בכיס והתרגשות באוויר, הצוות לא בזבז זמן ומיד קפץ לעבודה. הם רצו להיות הראשונים בשוק, לספק פתרון מתקדם לרופאים ולמטופלים, ולשנות את עולם המוניטורים הרפואיים.
אבל כשהם יצאו לדרך, משהו היה חסר.
בלי כיוון ברור – רק ריצה קדימה
בימים הראשונים של הפיתוח, צוות המהנדסים התכנס בחדר הישיבות, והאווירה הייתה מחשמלת. "אנחנו בונים מוניטור רפואי חדשני!" הכריז המנכ"ל. "זה יהיה קטן יותר, מדויק יותר, ועם חיבור רציף לאפליקציה שתעבוד גם בבית החולה!"
כולם הנהנו בהתלהבות, אבל אף אחד לא עצר לשאול: מה זה אומר בדיוק? איזה מדדים הוא ימדוד? האם הוא מיועד לשימוש ביתי, או רק בבתי חולים? האם נדרשת התאמה לרגולציה מחמירה יותר? איך תיראה חוויית המשתמש?
הצוות לא התעכב על שאלות והעבודה התחילה מייד.
מהנדסי החומרה התחילו לתכנן את המבנה הפיזי של המוניטור, מפתחים כתבו שורות קוד, והמעצבים עבדו על ממשק המשתמש. רק כשהגיע השלב להכניס את המוניטור לבדיקות, התברר שמשהו לא מסתדר.
המכשיר היה קטן ואלגנטי – אבל לא מדד את כל הפרמטרים שהרופאים ציפו לו. האפליקציה הייתה נוחה, אבל לא עמדה בדרישות אבטחת המידע. והכי גרוע? המכשיר בכלל לא היה מותאם לתקינה של מכשור רפואי ביתי, מה שהפך את כל הרעיון לבלתי אפשרי במסלול הרגולטורי שהם תכננו.
בשלב הזה, היה צריך לעצור הכל ולחזור אחורה – תהליך שעלול היה לקחת חודשים רבים ולעלות הרבה כסף. התשובה הנכונה הייתה להתחיל הפוך – לא לרוץ מיד לקוד ולחומרה, אלא קודם כל להבין מה רוצים לבנות.
מחקר שוק מקדים היה מגלה מהר מאוד שרופאים רוצים יכולת ניטור בבית החולה, אבל שזה דורש עמידה בתקינה מחמירה יותר.
הגדרת מפרט מוצר ברור הייתה מאפשרת למהנדסים לתכנן את המכשיר נכון מההתחלה, במקום לשנות אותו חמש פעמים בדרך.
מעורבות רגולטורית מוקדמת הייתה מונעת את ההפתעה המאוחרת כשהתברר שהמכשיר לא עומד בדרישות.
אבל את זה, במדיטק הבינו רק בדיעבד.
מנהיגות חסרה – כשכולם אחראים, אף אחד לא אחראי
אחרי שעיכבו את הפרויקט כדי להגדיר מחדש את המוצר, במדיטק סוף-סוף התחילו לנוע בכיוון ברור. הם קבעו שהמוניטור שלהם יתמקד בניטור מדדים קריטיים לשימוש גם בבתי חולים וגם בבית החולה, ודאגו שהוא יתאים לרגולציה הנכונה. אבל למרות שהתכנון סוף-סוף התבהר, קבלת ההחלטות נותרה בעיה קשה.
בכל ישיבת צוות, הרעיונות עפו לכל הכיוונים, אבל אף אחד לא ידע מי באמת מחליט. המנכ"ל היה אדם כריזמטי עם חזון ברור, אבל הוא לא הכיר לעומק את עולם המכשור הרפואי. ה-CTO היה שקוע כולו בפרטים הקטנים של החומרה והתוכנה, אבל לא ראה את התמונה הכוללת. מנהלת הרגולציה הזהירה אותם מהדרישות המחמירות שהם צריכים לעמוד בהן, אבל לא הייתה לה סמכות לקבוע אילו פשרות אפשריות.
וכך, הפרויקט התנהל כמו ספינה ללא קברניט.
המהנדסים היו בטוחים שהרגולציה תסתדר בהמשך. צוות הרגולציה הניח שהפיתוח הטכנולוגי ייקח בחשבון את כל ההנחיות. המנכ"ל חשב שהכול מתקדם מצוין – עד שהגיעו לשלב הבדיקות, וגילו שכל צוות עבד לפי פרשנות משלו למה שהמוצר צריך להיות. ולעשות. היו חלקים במכשיר שלא תאמו את התקנים ופונקציות באפליקציה שלא עמדו בדרישות אבטחת מידע.
כשהכול קורס – מי מחזיק בהגה?
פתאום היה ברור שאין גורם אחד שאחראי לכל המערכת. לא היה מי שיבדוק שהכל משתלב כמו שצריך – שהפיתוח תואם לרגולציה, שהחומרה מתאימה לשימושים שהוגדרו, ושכלל הממשקים עובדים יחד בצורה חלקה.
איך נכון היה לעבוד?
- למנות מנהל פרויקט ייעודי עם סמכות ברורה. מישהו שמבין את כל התחומים: רגולציה, הנדסה, ניהול מוצר ושוק.
- לבנות צוות ליבה שמתכנס בקביעות לקבלת החלטות אסטרטגיות, כך שכל שינוי ישוקלל מכל ההיבטים שלו, ולא רק מנקודת מבט של מחלקה אחת.
- להשתמש בגישת "Single Point of Truth" שמבטיח שמסמך אחד מרכזי (ולא דיונים בוואטסאפ) יהווה את המקור הרשמי לכל ההחלטות.
אבל במדיטק הבינו את זה רק כשהם כבר היו עמוק בתוך הבעיה.
זמן זה כסף – במיוחד כשמתכננים אותו לא נכון
בשלב הזה, במדיטק הבינו שהם צריכים סדר בפרויקט. הם מינו סוף-סוף מנהל פרויקט אחראי, יצרו מסמך דרישות מסודר, ודאגו שכל המחלקות יהיו מתואמות. זה היה נראה כאילו הם סוף-סוף מתקדמים בכיוון הנכון.
אבל אז התחיל מרוץ נגד השעון.
המנכ"ל היה לחוץ להציג אב-טיפוס למשקיעים, ושכנע את הצוות שאפשר לדחוף את לוח הזמנים קדימה. "יש לנו כבר את רוב הרכיבים," הוא אמר, "מה כבר יכול להשתבש?"
מהנדסי הפיתוח היו פחות אופטימיים. "אנחנו צריכים לבדוק את התאימות החשמלית (EMC), לעשות ולידציה קלינית, לסגור את עיצוב המכשיר, ואז גם להגיש לאישור רגולטורי," אמר אחד מהם. "זה לא משהו שאפשר לסיים בשלושה חודשים."
אבל במרדף אחרי השקת המוצר בזמן, ההנהלה החליטה לקצר תהליכים. תכנון הבדיקות נדחק לאחר כך, האינטגרציה בין החומרה לתוכנה לא קיבלה מספיק זמן, והם קיוו שהרגולציה תהיה "פשוט עניין של ניירת".
שלושה חודשים אחר כך, הגיע הרגע הגורלי.
המוצר היה מוכן, לכאורה. הוא נראה טוב, עבד כמו שצריך – עד שהגיע לשלב הבדיקות. שם, במדיטק גילו מה קורה כשלא מתכננים מספיק זמן מראש:
- החיישנים יצרו הפרעות אלקטרומגנטיות שלא תאמו את תקני ה-EMC.
- האלגוריתם של המדידה לא היה אמין מספיק, והראה נתונים לא מדויקים בניסויים.
- הרגולציה לא הייתה "עניין של ניירת" – התברר שיש סעיפים קריטיים שדרשו שינויים מהותיים במכשיר.
כל זה גרם לעצירת הפרויקט ליותר מחצי שנה.
איך היה צריך לתכנן את הזמן נכון?
- לתכנן מראש מרווחי ביטחון – פרויקטים טכנולוגיים תמיד נתקלים בבעיות בלתי צפויות. לוח זמנים ריאלי חייב לקחת את זה בחשבון.
- להגדיר נקודות עצירה לפרויקט (Phase-Gate Reviews). כל שלב צריך להיבחן לעומק לפני שעוברים לשלב הבא, במקום לדחוף קדימה ולהתמודד עם בעיות בדיעבד.
- לא להניח שהרגולציה היא "עניין של ניירת", אלא לוודא התאמה רגולטורית מהיום הראשון של הפיתוח.
במדיטק, למדו את הלקח בדרך הקשה. ההשקה שתוכננה לרבעון הראשון של השנה נדחתה לרבעון האחרון – כי מה שלא מתכננים נכון בהתחלה, גובה מחיר בסוף.
כשמנסים לעשות הכול בבת אחת – בסוף לא עושים כלום כמו שצריך.
אחרי שעיכבו את הפרויקט בגלל בעיות בזמנים ורגולציה, במדיטק היו נחושים לפצות על הזמן האבוד. הם הגיעו למסקנה שאם יעבדו על הכול במקביל – הפיתוח, הבדיקות, הייצור והאישורים הרגולטוריים – הם יוכלו לסגור את הפער ולשחרר את המוניטור שלהם כמה שיותר מהר.
כך יצא שכל המחלקות התחילו לרוץ קדימה במקביל. המהנדסים עבדו על גרסת החומרה החדשה, צוות התוכנה המשיך לפתח את האפליקציה, מחלקת הרגולציה התחילה להכין את המסמכים להגשה, וגורמים חיצוניים החלו לייצר את הרכיבים. מה כבר יכול להשתבש?
מסתבר שכמעט הכול.
התוכנה התקדמה מהר יותר מהחומרה, והאלגוריתם שפיתחו לא התאים לחיישנים החדשים, מה שדרש שכתוב מחדש של הקוד.
הייצור התחיל לפני שהסתיימו כל הבדיקות, ובשלב מאוחר התגלו שינויים קריטיים במעגלים החשמליים, מה שהפך חלקים שלמים לבלתי שמישים.
הצוות הרגולטורי הגיש בקשה לאישור לפני שכל מסמכי הבדיקות הושלמו – מה שהוביל לדחייה מיידית מצד ה-FDA.
בסופו של דבר, במקום לצמצם את הזמן, הם רק הוסיפו לעצמם כאב ראש ועיכובים נוספים.
איך נכון היה לעבוד?
- לבצע שלבים בצורה מחושבת – שלב אחרי שלב. במקום לרוץ על כל החזיתות, היה עדיף להבטיח שהחומרה סופית לפני שמפתחים לה תוכנה, לוודא שהתוכנה עובדת לפני שבונים ייצור סדרתי, ולסיים את הבדיקות לפני שניגשים לרגולציה.
- לייצר אב-טיפוס ולבדוק אותו לפני קפיצה לייצור. כך היו יכולים לאתר בעיות בזמן ולמנוע זריקה של מאות רכיבים לפח.
- לשמור על תיאום בין המחלקות. מפגשי סנכרון שבועיים היו יכולים למנוע הרבה בלבול ועבודה כפולה.
במדיטק הבינו באיחור שריצה על כל החזיתות לא מביאה לתוצאה טובה – אלא רק להפסדים וזמן מבוזבז.
לדחות את המשימות הקשות – רק גורם להן להיות גרועות יותר
הבעיה הגדולה ביותר של המוניטור של מדיטק הייתה הדיוק במדידה. השוק היה מלא במוניטורים דומים, ורופאים רצו לוודא שהנתונים של המוצר החדש אמינים ומדויקים. כבר בשלבי הפיתוח המוקדמים התעוררו ספקות אם האלגוריתם של מדיטק באמת מספק את הדיוק שנדרש, אבל במקום לעצור ולבדוק את זה לעומק – הצוות בחר להתמקד קודם ב"משימות הקלות" כמו עיצוב האפליקציה והאינטגרציה עם המערכת.
התקווה הייתה ש"נטפל בזה בהמשך".
כשהמוצר היה מוכן לשלב הבדיקות הרשמיות, הספקות התבררו כמוצדקים – המוניטור לא עמד בדרישות הדיוק, במיוחד בחולים עם מצבים רפואיים מסוימים. כל הפיתוח היה תלוי בבעיה הזאת, ועכשיו כבר היה מאוחר מדי לתקן את זה בלי לשכתב חלקים נרחבים מהמוצר.
איך נכון היה לעבוד?
- לטפל קודם בבעיות הגדולות והקשות. במקום לדחות אותן, היה עדיף להתמודד איתן בשלב מוקדם, כשהשינויים עוד אפשריים.
- להפעיל גישת "Fail Fast" – לבדוק מהר ככל האפשר את ההיבטים הקריטיים ביותר של המוצר, כדי לא לגלות בעיות רק בסוף.
- לשלב מומחים כבר בהתחלה. פיזיקאים ומהנדסי אותות היו יכולים לזהות את הבעיה מוקדם יותר ולמנוע חודשים של בזבוז זמן.
במדיטק למדו בדרך הקשה שדחיית בעיות לא גורמת להן להיעלם – רק מגדילה את הנזק כשצריך להתמודד איתן לבסוף.
שינויי דרישות בלתי פוסקים – כשהמוצר אף פעם לא "מוכן"
ככל שהפיתוח התקדם, ההנהלה של מדיטק המשיכה להוסיף שינויים. "בואו נוסיף גם ניטור לחץ דם!" הציע אחד המשקיעים. "מה עם חיבור ל-Apple Health?" שאל יועץ אחר. "אם זה עובד עם בלוטות', אולי נוסיף גם גרסה עם Wi-Fi?"
וכל שינוי כזה נראה קטן – עד שמסתכלים על התמונה הכוללת.
בשלב מסוים, צוות הפיתוח הבין שהם בעצם רודפים אחרי מטרה נעה. כל פעם שהיו בטוחים שהמוצר סופי, הגיע שינוי נוסף. כל פעם שהיו מוכנים להתחיל בדיקות, נוסף רכיב חדש. הפרויקט הפך לאין-סופי.
איך נכון היה לעבוד?
- הגדרת מפרט מוצר סופי כבר בהתחלה – ולהיצמד אליו. אפשר לחשוב על שדרוגים לגרסאות עתידיות, אבל לא לשנות את המפרט של המוצר הנוכחי שוב ושוב.
- להשתמש במנגנון "Design Freeze" – נקודות מוגדרות בזמן שבהן אסור להוסיף יותר שינויים משמעותיים.
- לנהל את המשקיעים ולא לתת להם לנהל את המוצר. שינויים צריכים להיות מונעים מצרכים אמיתיים של הלקוחות והמשתמשים – לא מ"מה שנראה טוב בפיץ' למשקיעים".
כשאין פיקוח – הכל מתפרק בסוף
אחת הטעויות האחרונות של מדיטק הייתה להניח שהמהנדסים יוכלו לעבוד באופן חופשי בלי פיקוח הדוק מדי. הצוות היה מנוסה, חכם וחדשני – אז למה לא לתת להם להוביל את הדרך בעצמם?
רק שבמציאות, בלי בקרה מסודרת, חלק מהתהליכים לא נעשו כמו שצריך.
- מסמכי הבדיקות לא תועדו בצורה שתואמת דרישות רגולטוריות.
- אלגוריתם עיבוד הנתונים היה שונה בגרסאות שונות של הקוד, מה שהוביל לחוסר עקביות.
- ספקים ייצרו רכיבים בלי בדיקות איכות מתאימות, כי לא קיבלו מפרטים ברורים.
- וכשהגיע הזמן להגשת המוצר לאישור, התברר שיש יותר מדי בעיות לא סגורות.
איך נכון היה לעבוד?
- לקיים Design Reviews מסודרים. כל שלב חייב לעבור בקרת איכות קפדנית לפני שממשיכים הלאה.
- להקפיד על תיעוד מלא לא רק כדי לעמוד ברגולציה. זה חשוב כדי לוודא שכל מי שעובד על הפרויקט מבין מה קורה.
- להגדיר סטנדרטים ברורים. כל חלק בפרויקט – מחומרה ועד קוד – חייב להיות מתועד ומבוקר לפי קריטריונים ידועים מראש.
סיכום – איך להימנע מהטעויות של מדיטק
חברת מדיטק למדה את הלקח שלה בדרך הקשה. אחרי עיכובים של יותר משנה, היא נאלצה לעשות חישוב מסלול מחדש, להגדיר גבולות ברורים, ולבצע את הפיתוח בצורה מסודרת.
בסופו של דבר, הם השיקו את המוניטור שלהם – אבל רק אחרי שהבינו שתכנון נכון, מנהיגות חזקה, ניהול זמנים קפדני והימנעות משינויים בלתי נגמרים הם המפתח להצלחה.
פיתוח מכשור רפואי הוא תהליך מאתגר, אבל עם עבודה נכונה, אפשר למנוע טעויות וליצור מוצר שבאמת יגיע לשוק ויעשה שינוי אמיתי.
תגובות
הוסף רשומת תגובה