Yalın ve Çevik Tıbbi Cihaz Ürün Geliştirme Rehberi

Tıbbi cihaz ve ekipman endüstrisindeki geliştirme programlarının başarısı, neredeyse her zaman, iç veya dış kaynak yaratma çabalarıyla örtüşen teknik kilometre taşlarına ulaşmaya bağlıdır.

Özellikle programın başlarında, teknik kilometre taşlarına maliyet açısından duyarlı bir şekilde ve zamanında ulaşmak çok önemlidir. Bu, sonunda bir programın ayakları olup olmadığını veya sonlandırılacağını belirleyecektir.

Peki, bu ilk kritik kilometre taşları neye benziyor? Ve aşırı harcama yapmadan bu dönüm noktalarına olabildiğince hızlı ulaşmak için ne yapabiliriz? Aşağıda, yalın ve çevik ürün geliştirme programları yürütmek için dört husus sunuyorum.

1. Bir yıldız oyuncu mu yoksa kolaylaştırıcı mı tasarlıyorsunuz?

Herhangi bir geliştirme programındaki ilk önemli kilometre taşlarından biri, ilk çalışan prototipin oluşturulmasıdır. Erken çalışan prototiplerle uygulamalı testin asıl amacı, teknik fizibiliteye (veya "İlke Kanıtı") ulaşmaktır. Bu, teknik ekibin ürün konseptinin altında yatan teknolojinin gerekli performansı sağladığını güvenle söyleyebildiği andır.

Çalışan bir prototipi olabildiğince hızlı ve uygun maliyetli geliştirmek için kendinize sormanız gereken ilk soru, yıldız oyuncuyu mu yoksa kolaylaştırıcıyı mı tasarladığınızdır? Bir yıldız oyuncu, tasarımının ürün performansını doğrudan etkilediği bir üründür. Yıldız oyuncular olarak kabul edilen ürünlere örnek olarak suni diz veya ameliyat sırasında insanların nefes almasını sağlayan vantilatör verilebilir.

Aksine, kolaylaştırıcı bir ürün tasarlamak, "gerçek" yıldız oyuncunun işini yapmasını sağlayan ekipman veya araç tasarlamayı içerir. Bu tür ürünlerin örnekleri, bir teşhis aleti (bir teşhis çıktısı oluşturmak için bir tahlili kolaylaştıran) veya bir biyoreaktördür (bir biyofarmasötiğin üretimini kolaylaştıran).

Bir yıldız oyuncu ürününün (tasarımının performansıyla doğrudan bağlantılı olduğu) çalışan bir prototipini yapmak için, öncelikle istenen ürünün biçim faktörünü ve gereksinimlerini anlamamız gerekir. Prototipin ürün performansı hakkında anlamlı veriler üretebilmesi için tasarım ve form faktörünün nihai tasarımı temsil etmesini sağlamak için bu bilgilere ihtiyacımız var.

Bu nedenle, bir yıldız oyuncu ürünü için bir program genellikle ürün gereksinimlerini/özelliklerini keşfetmek, kullanılabilirlik analizi ve önemli kanaat önderleriyle yapılan görüşmelerle başlar. Ancak bu bilgiler toplandıktan sonra ilk çalışan prototip oluşturulabilir.

Bunun tersine, kolaylaştırıcı bir ürün için, "gerçek" yıldız oyuncunun performansını test etmek için nihai form faktörü gerekli değildir. Örneğin, kullanıma hazır (özel olmayan) bileşenler kullanılarak oluşturulan ham bir devre tahtası sistemi aşağıdaki gibi soruları yanıtlamak için kullanılabilir: tahlilim doğru teşhis çıktısı veriyor mu? Veya ilacım yeterli miktarda ve kalitede mi?

Başlangıçta, ürün gereksinimlerini keşfetme alıştırması, kullanılabilirlik analizi ve kilit fikir liderleriyle görüşmeler en aza indirilir. Yalnızca performansla ilgili metriklerin (örn. duyarlılık, özgüllük, aktif biyofarmasötiklerin miktarı, vb.) önceden tanımlanması gerekir.

İlk prototip bileşenleri önceden tanımlanmış ürün performansına ulaşabildiği sürece, ilk çalışan prototip, daha sonraki tasarım yinelemelerinde bazı kritik bileşenlerin değiştirilmesi gerekse bile, ilk uygulamalı test sonuçlarını sunarak muazzam bir değer sağlayacaktır.

Tüm ürünler "yıldız oyuncu" veya "kolaylaştırıcı" kategorilerine kolayca sığamaz. Örneğin, özel bir ilaç dağıtım cihazını kategorize etmek gerçekten karmaşıklığına bağlıdır. İlaç verme cihazı, başka türlü uygulanamayacak bir terapiyi mümkün kılıyorsa (örneğin, beynin şu anda erişilemeyen belirli bir bölümüne bir ilaç vererek), cihaz bir yıldız oyuncu olarak kabul edilebilir.

Oysa ilaç verme cihazı, önceden var olan bir tedaviye daha uygun maliyetli bir çözüm sağlıyorsa, ürün bir kolaylaştırıcı olarak kabul edilebilir.

Kısacası, hemen hemen her geliştirme programı, çalışan prototipler oluşturarak ve test ederek teknik fizibiliteyi mümkün olan en kısa sürede ve ucuza gerçekleştirmeyi amaçlayacaktır. Yıldız oyuncu ürünleri için, anlamlı çalışan bir prototip oluşturmak için daha fazla ürün tanımı gerektiğinden, bu önemli dönüm noktasına ulaşmak genellikle daha uzun sürer (ve daha maliyetlidir).

Kolaylaştırıcı ürünler için, tasarım ve form faktörünün büyük bir kısmı daha sonra değiştirilebildiğinden, arka planda ürün gereksinimlerini ve özelliklerini ele alırken çalışan bir prototip oluşturmaya hemen başlayabilirsiniz.

Şekil 1. Her iki program da mümkün olan en hızlı şekilde "İlke Kanıtı"na doğru çalışır. Bununla birlikte, başlangıçta, bir Yıldız Oyuncu ürünü için bir geliştirme programı, performansı test etmek ve teknik fizibilite elde etmek için doğrudan bir prototip oluşturmaya atlayan bir Kolaylaştırıcı ürün programından daha çok ürün tanımına odaklanır.

2. Tasarla – test et – tasarla – test et – tasarla – test….. dur.

İlk prototip her zaman teknik fizibilite elde etme amacıyla tasarlansa da, ilk prototip nadiren tüm hedefleri tutturur. Birden çok yineleme gerekebilir. Bu nedenle, yalın ve çevik ürün geliştirme programlarının özünde hızlı tasarım yinelemeleri, test etme, öğrenme ve öğrendiklerini bir sonraki yinelemeye dahil etme döngüleri vardır.

Bu süre zarfında gerekli olmayan tüm geliştirme faaliyetlerini minimumda tutmak, ekibin odaklanmasına yardımcı olur ve geliştirmeyi hızlandırır. Bu aşamada, daha sıkı kalite sistemlerinin empedansı olmaksızın, iyileştirilmiş performans için prototip yapılarında ince ayar ve yeniden amaç belirleme serbestçe yapılmalıdır.

Açık olmak gerekirse, bu titiz kalite sistemleri programın sonraki aşamalarında kritik öneme sahiptir, ancak belgelerin programın başlarında "hafif" tutulması, geliştirmeyi hızlandırmaya yardımcı olur.

Hızlı yinelemeler, yalın ve çevik erken ürün geliştirme için önemlidir. Ancak yinelemeyi ne zaman durduracağınızı ve başarıyı kutlayacağınızı bilmek de öyle. “Daha fazla iyileştirmenin daha iyi bir ürün yapacağına” inanmayan bir teknik ekiple henüz tanışmadım. Ve öyle yapmalılar! Mümkün olan en iyi tasarım çözümü için çabalamak onların işidir.

Bu nedenle, önceden tanımlanmış performans metriklerine ulaşma hedefi (örn. x miktarda analitin saptanması veya numunenin x süre boyunca stabil kalması vb.) en baştan açıkça belirtilmeli ve süreç boyunca tekrarlanmalıdır. proje.

İstenilen performansa ulaşıldığında teknik fizibilite sağlanmış demektir. Bu, programın tasarımın bir sonraki aşamasına (daha rafine bir prototip oluşturmayı içeren) geçeceği anlamına gelir.

Bu aynı zamanda prototip mimarisini özetleyen daha ayrıntılı belgeler oluşturmaya başlamak ve ürün gereksinimlerini sağlamlaştırmaya başlamak için doğru an. Bu dokümantasyon, programın ilerleyen zamanlarına kadar (tasarım kontrolünün dışında) nispeten akıcı kalır.

Bu bilgilerin belgelenmesi, iç ve dış iletişime, ek ekip üyelerinin işe alınmasına ve işin o noktaya kadar korunmasına yardımcı olur.

3. Mümkün olan en çevik ekiple program kilometre taşlarına nasıl ulaşılır?

Daha akıllı insanların daha hızlı ve daha iyi çözümler anlamına geldiğini varsayarsak, genellikle bir programa daha fazla kaynak ayırma eğilimi vardır. Özellikle düzenlemeye tabi sektörlerde (tıbbi cihaz ve ilaç endüstrileri gibi), hakim organizasyonel sistemler, henüz orada olması gerekmeyen ek ekip üyelerini de zorlayabilir.

Ancak daha sonra ihtiyaç duyulan işlev temsilcileri en baştan dahil edilebilir ve bu da büyük bir ek yük ve iletişim yüküne neden olur. Sonuç, bir programı ileriye taşımaya çalışan toplantılarda oturan 20'den fazla kişidir.

Büyük ekip boyutlarına rağmen, bu programların başlatılması genellikle yavaştır. Bu nedenle, bu kulağa mantıksız gelse de, daha küçük, adanmış çok disiplinli ekiplerin daha hızlı hareket edebildiğini ve erken ürün geliştirme sırasında orantısız miktarda yenilik üretebildiğini buldum.

Mükemmel çıktı elde etmek için ekip boyutunu sınırlama kavramı yeni değildir. Amazon'un kurucusu ve eski CEO'su Jeff Bezos, bu olguyu fark etti ve her ekibin iki pizzayla beslenebilecek kadar küçük olması gerektiği kuralını koydu.

"İki pizza kuralı", küçük ekiplerin daha yenilikçi olduğunu ve daha mutlu ekip üyeleri içerdiğini gösteren sayısız araştırma makalesi ve kitap tarafından desteklenmektedir [1, 2, 3].

Şekil 2. İletişim yükü, bu şekilde gösterildiği gibi ekipteki kişi sayısıyla katlanarak artar. Siyah noktalar, bireysel ekip üyelerini temsil eder ve çizgiler, bireyler arasındaki benzersiz bağlantıları temsil eder.

Şekil 2'de ekip boyutunun iletişim yüküyle üstel olarak ilişkili olduğunu görebilirsiniz. Fazladan bir ekip üyesi eklemek çok büyük bir şey gibi görünmeyebilir, ancak aslında önemli ölçüde ek yüke ve yanlış hizalamalara yol açabilir. Özellikle erken ürün geliştirmede, ekip boyutunu en fazla 5 üyeyle sınırlamak, hızlı ve yalın geliştirmeye gerçekten yardımcı olur.

Bu kavramdaki bariz ikilik, tıbbi cihaz geliştirmede çözülmesi gereken problemlerin genellikle uzman becerileri gerektirmesidir. Az sayıda bireyde gerekli tüm becerilerin bulunması son derece nadirdir. Bu nedenle, zorluk, daha derin bilgi/deneyim seviyelerine erişirken çevik ve hızlı bir şekilde çalışabilen küçük bir ekibin nasıl kurulacağıdır.

Ne yazık ki, herkese uyan tek bir ekip yok, ancak en başarılı ekiplerin tasarım sorunlarının sahibi olan birkaç teknik liderden oluştuğunu gördüm. Çoğunlukla, bu teknik liderler, uzun yıllara dayanan deneyime sahip çok yönlü kişilerdir. Uzman olmadıkları alanlarda ne zaman iç veya dış danışma arayacaklarını bilirler.

Bu yapıda teknik lider, sorun tanımını çerçeveler ve danışmadan önce çözüm ortamını planlar.

Danışman (dahili veya harici) çekirdek ekibin bir parçası değildir (dolayısıyla iletişim yükünü sınırlar) ancak yine de önerilen çözümler için uzman bilgisi sağlayabilir. Genellikle teknik liderler ve danışmanlar arasındaki iletişim, tüm ekibin dahil olmadığı küçük toplantılarda gerçekleşir.

Teknik lider, önerilen çözümlerin daha büyük prototip tasarım planlarına uymasını ve nihai olarak prototip mimarisinin önemli bir kısmına sahip olmasını sağlar.

Bu yapıya ek bir fayda, teknik liderlerin teknik zorluklara karşı büyük bir sorumluluk duygusu hissetmeleri ve başarılarını gerçekten kutlayabilmeleri ve sahiplenebilmeleridir.

4. Bir Program Şampiyonu Atayın

Teknik liderler, sistem mimarisinin bir kısmına sahiptir, ancak programın başarısına sahip olan bir program şampiyonu da olmalıdır. Bu kişi nihai olarak tüm programdan sorumludur ve doğru kişilerin doğru tasarım çözümleri üzerinde çalışmasını sağlar.

Bir program şampiyonunun birçok unvanı olabilir (örneğin, ürün yöneticisi, program yöneticisi, Ar-Ge direktörü, CSO, CTO vb.), ancak rolleri unvanla tanımlanmaz. Bu, başarılı bir program sonucundan sorumlu hisseden ve yapbozun farklı parçalarına daha bütüncül bir şekilde bakabilen kişidir.

Program şampiyonu ayrıca teknik ekip (daha fazla iyileştirme yapma arzusuyla) ve proje yöneticisi (zamanında ve bütçe dahilinde teslim etme arzusuyla) arasındaki sağlıklı çatışmayı yönetecektir. İnovasyonu, pek çok belirsizliği ve yeni teknolojileri içeren bir geliştirme programı yürütmek, her zaman her iki taraftan da uzlaşma talep eder.

Sonuç olarak, bu çatışmayı etkili bir şekilde yönlendirmek, başarılı bir yalın ve çevik geliştirme ekibi çalıştırmanın temel bir bileşenidir.

Şekil 3. Bir program şampiyonu, teknik ekip, proje yöneticisi ve ürün ekibi/yöneticisi arasında var olan gerekli ve sağlıklı çatışmaları yönlendirir. Bir program şampiyonu, özel bir program yöneticisi, CTO, CSO, Ar-Ge direktörü olabilir veya teknik veya ürün ekibinin bir üyesi olabilir. Bu rol için en önemlisi, çatışmaları tarafsız bir şekilde yönetebilmeleri gerekir.

Program şampiyonunun bir diğer sorumluluğu da teknik ekip ile ürün müdürü arasında uyum sağlamaktır. Ürün yöneticisi, hedef ürün profilinden ve ticari hedeflerin belirlenmesinden sorumludur.

Erken geliştirme programlarında, ürün yöneticisi rolünün kendini işine adamış bir kişi tarafından doldurulmayabileceğini, bunun yerine rolün genellikle birden çok kişi tarafından yerine getirildiğini buldum.

Ürün vizyonunu ve ürün gereksinimlerini yönlendirmek için bu kişilerin uyumlaştırılmasına yardımcı olmak ve teknik ekip ile ürün yönetimi ekibi arasındaki görüşmeyi kolaylaştırmak, beklentileri karşılayan ve bir pazar ihtiyacını karşılayan bir ürün tasarımına ulaşmak için çok önemlidir.

Özet

Özetle, yalın ve çevik bir ürün geliştirme programı oluşturmak, mümkün olan en kısa sürede teknik fizibilite sağlayacak faaliyetlerin tanımlanmasıyla başlar. Prototip yinelemelerini hızlı bir şekilde tasarlayan, inşa eden ve test eden deneyimli teknik liderlerden oluşan küçük, özel bir ekibe sahip olmak, çevik ve uygun maliyetli bir yapı oluşturur.

Son olarak, genel uyuma yardımcı olacak, teknik fizibilitenin gerçekleştirildiği anı çağıran ve teknik ekip, proje yöneticisi ve ürün ekibi/yöneticisi arasında olması gereken sağlıklı çatışmaları yönlendiren bir program şampiyonu atamak çok önemlidir.

1. Steiner ID., 1972. Grup Süreci ve Verimlilik. New York: Akademik Basın.
2. Laughlin PR. ve diğerleri, 2006. Gruplar, harf-sayı problemlerinde en iyi bireylerden daha iyi performans gösteriyor: Grup büyüklüğünün etkileri. Kişilik ve Sosyal Psikoloji Dergisi, 90(4), 644-651.
3. Brett J. ve Wang D., 2020, Yaratıcı Çözümler İstiyorsanız Ekibinizi Küçük Tutun, Bilimsel amerikalı

Resim: Stok Fotoğraf / olivier26

Joris van der Heijden, Bio Services Program Yöneticisidir. Denizyıldızı Medikal. Daha önce, bir hasta başı COVID-19 teşhis testinin geliştirilmesine liderlik ettiği Spartan Bioscience'da Ar-Ge Direktörüydü. Joris, UBC'den bulaşıcı hastalıklar alanında doktorasını aldı.

[Gömülü içerik] 

---

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://starfishmedical.com/blog/a-guide-to-lean-and-agile-medical-device-product-development/