מדריך לפיתוח מוצרי מכשיר רפואי רזה וזריז

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

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

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

1. האם אתה מעצב שחקן כוכב או מנחה?

אחת מאבני הדרך העיקריות הראשונות בכל תוכנית פיתוח היא יצירת אב הטיפוס העובד הראשון. המטרה האמיתית של בדיקה מעשית עם אבות טיפוס עבודה מוקדמים היא השגת היתכנות טכנית (או "הוכחת העיקרון"). זה הרגע שבו הצוות הטכני יכול לומר בביטחון שהטכנולוגיה הבסיסית לקונספט המוצר מספקת את הביצועים הנדרשים.

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

לעומת זאת, עיצוב מוצר שהוא מנחה כרוך בעיצוב ציוד או כלי עבודה המאפשרים לשחקן הכוכב ה"אמיתי" לבצע את עבודתו. דוגמאות לסוגים אלה של מוצרים הם מכשיר אבחון (המאפשר בדיקה ליצירת פלט אבחוני), או ביו-ריאקטור (המקל על ייצור של ביו-פרמצבטיקה).

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

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

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

בתחילה, התרגיל של חקירת דרישות המוצר, ניתוח שמישות וראיונות עם מובילי דעה מרכזיים מצטמצם למינימום. יש להגדיר מראש רק את המדדים הנוגעים לביצועים (למשל, רגישות, ספציפיות, כמות ביו-פרמצבטיקה פעילות וכו').

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

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

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

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

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

האיור 1. שתי התוכניות פועלות לקראת "הוכחת העיקרון" מהר ככל האפשר. עם זאת, בתחילה, תוכנית פיתוח עבור מוצר Star Player מתמקדת יותר בהגדרת המוצר מאשר תוכנית עבור מוצר מנחה אשר קופץ ישירות ליצירת אב טיפוס לבדיקת ביצועים ולהשגת היתכנות טכנית.

2. עיצוב – מבחן – עיצוב – מבחן – עיצוב – מבחן….. עצור.

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

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

כדי להיות ברור, מערכות האיכות הקפדניות הללו הן קריטיות בשלב מאוחר יותר של התוכנית, אבל שמירה על תיעוד "קל" בשלב מוקדם של התוכנית עוזרת להאיץ את הפיתוח.

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

זו הסיבה שהמטרה של פגיעה במדדי ביצועים מוגדרים מראש (למשל זיהוי של כמות x של אנליט הושגה, או שהדגימה יציבה במשך x פרק זמן וכו') צריכה להיות מפורשת בבירור מההתחלה ולחזור על עצמה לאורך כל הזמן. פּרוֹיֶקט.

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

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

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

3. איך להשיג אבני דרך בתוכנית עם הצוות הכי זריז שאפשר

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

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

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

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

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

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

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

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

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

במבנה זה, המנהיג הטכני ממסגר את הגדרת הבעיה וממפה את נוף הפתרונות לפני הייעוץ.

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

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

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

4. מנה אלוף תכנית

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

אלוף תכנית יכול להיות בעל תארים רבים (למשל מנהל מוצר, מנהל תכנית, מנהל מו"פ, CSO, CTO וכו'), אך תפקידו אינו מוגדר על ידי התואר. זהו מישהו שמרגיש אחראי לתוצאה מוצלחת של התוכנית ומסוגל להסתכל על חלקי הפאזל השונים בצורה הוליסטית יותר.

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

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

האיור 3. אלוף תכנית מנווט קונפליקטים הכרחיים ובריאים הקיימים בין הצוות הטכני, מנהל הפרויקט וצוות/מנהל המוצר. אלוף התוכנית יכול להיות מנהל תוכנית מסור, CTO, CSO, מנהל מו"פ, או שהם יכולים להיות חבר בצוות הטכני או המוצר. הכי חשוב לתפקיד זה, הם צריכים להיות מסוגלים לנווט קונפליקטים ללא משוא פנים.

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

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

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

<br> סיכום

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

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

1. שטיינר תעודת זהות, 1972. תהליך ותפוקה קבוצתית. ניו יורק: עיתונות אקדמית.
2. יחסי ציבור Laughlin. et al., 2006. קבוצות מתפקדות טוב יותר מהאנשים הטובים ביותר בבעיות של אותיות למספרים: השפעות של גודל הקבוצה. כתב העת של אישיות ופסיכולוגיה חברתית, 90(4), 644-651.
3. ברט ג'יי ו-ואנג ד', 2020, אם אתה רוצה פתרונות יצירתיים, שמור על הצוות שלך קטן, סיינטיפיק אמריקן

תמונה: צילום מאגר יכול / olivier26

Joris van der Heijden הוא מנהל תוכנית שירותי ביו ב סטארפיש מדיקל. בעבר הוא היה מנהל מו"פ ב-Spartan Bioscience, שם הוביל את הפיתוח של בדיקת אבחון COVID-19 נקודתית. יוריס קיבל את הדוקטורט שלו במחלות זיהומיות מ-UBC.

[תוכן מוטבע] 

---

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
• מקור: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/