شش افسانه‌ی توسعه‌ی محصول -- باورهایی که باعث تأخیر می‌شوند،کیفیت را پایین آورده و هزینه‌ها بالا می‌برند.

شش افسانه‌ی توسعه‌ی محصول

باورهایی که باعث تأخیر می‌شوند،کیفیت را پایین آورده و هزینه‌ها بالا می‌برند.

تاریخ انتشار : می  2012

منتشر شده در مجله کسب‌و‌کار هاروارد

بیشتر مدیران توسعه محصول همیشه در تلاش‌اند که پروژه‌ها را در زمان و بودجه‌ی مشخص به اتمام برسانند.البته آن‌ها هیچ‌گاه منابع کافی را برای این کار در اختیار ندارند و روسایشان برنامه‌ی زمانی مشخصی را از آنان مطالبه می‌کنند.بنابراین، مدیران به گروه زیردستشان فشار می‌آورند تا بیشتر صرفه‌جویی کنند،برنامه‌های دقیق‌تری را تنظیم کنند و انحراف از زمان‌بندی و اسراف‌ها را کمینه کنند اما چنین رویکردی که ممکن است در کارخانه‌هایی با عملکرد پایین به‌خوبی جواب دهد،ممکن است به تلاش‌های تکوین و تولید کالا آسیب برساند.

بسیاری از شرکت‌ها با توسعه محصول،همچون تولید آن رفتار می‌کنند اما این دو عمیقاً با هم متفاوت‌اند.در دنیای تولید اشیای فیزیکی،کارها تکراری بوده، فعالیت‌ها  قابل پیش‌بینی هستند و اشیای تولیدشده در هر زمان فقط می‌توانند در یک مکان باشند.در توسعه محصول،بسیاری از کارها منحصربه‌فردند احتیاجات پروژه دائماً تغییر می‌کند و محصول(تا حدی به لطف استفاده گسترده از طراحی و شبیه‌سازی پیشرفته به کمک کامپیوتر و تلفیق نرم‌افزار با محصولات فیزیکی) اطلاعاتی است که می‌تواند در مقاطع مختلف (هم‌زمان در چند مکان باشد)وجود داشته باشد.

ندیدن این تفاوت‌های بسیار مهم،موجب باورهای اشتباه متعددی شده است که به برنامه‌ریزی، اجرا و ارزیابی پروژه‌های توسعه محصول لطمه می‌زنند.ما برای مطالعه شرکت‌ها و ارائه مشاوره به آن‌ها درزمینه‌ی توسعه محصول،بیش از ۵۰ سال صرف کرده‌ایم و با این تصورات اشتباه(و تصورات اشتباه دیگری که به دلایل متفاوت بروز می‌کنند)در طیف گسترده‌ای از صنایع شامل نیمه‌هادی‌ها، اتومبیل‌ها،لوازم مصرفی الکترونیکی،دستگاه‌های پزشکی،نرم‌افزارها و خدمات مالی مواجه شده‌ایم. ما در این مقاله این تصورات اشتباه را معرفی و راه‌هایی برای غلبه بر مشکلاتی که می‌آفرینند، پیشنهاد می‌کنیم.

خلاصه فصل 

بسیاری از شرکت‌ها با توسعه محصول مانند تولید برخورد می‌کنند.سعی در کنترل هزینه‌ها و بهبود کیفیت با اعمال فنون خطا-صفر و کارایی محور،دارند.درحالی‌که این روش ممکن است عملکرد کارخانه‌ها را ارتقا دهد اما توسعه‌ی محصول را متوقف می‌سازد چراکه فرآیند طراحی محصولات به‌طور کامل با فرآیند تولید آن‌ها تفاوت دارد.ناتوانی مدیران در شناسایی این تفاوت‌ها، به تصورات اشتباهی منجر می‌شود که تلاش‌ها برای توسعه محصول را با مشکل مواجه می‌سازد.

در این مقاله نویسندگان(یکی استاد دانشکده‌ی مدیریت هاروارد و دیگری مشاور کسب‌وکار)این تصورات غلط را آشکار ساخته و شش افسانه‌ی متداول و خطرناک را بررسی می‌کنند:

1-  بهره‌برداری بالا از منابع،موجب بهبود عملکرد می‌شود.

2- پردازش کار در دسته‌های بزرگ،باعث بهبود اقتصادی فرایند توسعه می‌شود.

3- طرح توسعه‌ی شرکت عالی است.باید فقط از آن پیروی شود.

4- هر چه پروژه‌ها زودتر شروع شود،زودتر نیز پایان می‌یابد.

5- هر چه محصول قابلیت‌های بیشتری داشته باشد،مشتریان بیشتر از آن استقبال می‌کنند.

     6- پروژه‌ها،درصورتی‌که گروه‌ها در اولین تلاش آن‌ها را تکمیل کنند،با موفقیت بیشتری روبه‌رو می‌شوند.

نویسندگان، تأثیرات منفی این اصول را هنگام اعمال به توسعه‌ی محصول تشریح کرده و راهنمایی‌هایی کاربردی،برای برطرف کردن آن‌ها عرضه می‌کنند.همچنین خوانندگان را در به‌کارگیری ابزار بصری حفظ پروژه‌ها در مسیر صحیح هدایت می‌کنند.

افسانه ۱ : بهره‌برداری بالا از منابع،موجب بهبود عملکرد می‌شود.

ما هم در کار تحقیقات و هم در کار مشاوره،متوجه شدیم که اکثریت بزرگی از شرکت‌ها تمامی تلاش خود را می‌کنند تا به‌طور کامل از منابع توسعه محصول خود استفاده کنند.یکی از ما(دونالد) به کمک پیمایش‌هایی که در دوره‌های مدیریت اجرایی در انستیتو تکنولوژی کالیفرنیا انجام داد، متوجه شد که مدیر معمولی توسعه محصول،بهره‌برداری از ظرفیت را در حد بالاتر از ۹۸ نگه می‌دارد.منطق این کار بدیهی و روشن به نظر می‌رسد،پروژه‌ها هنگامی‌که افراد ۱۰۰%وقت خود را کار نمی‌کنند، طولانی‌تر می‌شود،ازاین‌رو، سازمان توسعه‌ای که پرکار است سریع‌تر و کارآمدتر از سازمانی است که در بهره‌برداری از افرادش خوب عمل نمی‌کند.

اما این منطق در عمل درست از آب درنیامد.ما شاهد بودیم هنگامی‌که مدیران به‌طور کامل وقت کارکنان توسعه محصول خود را پر کردند،صرف‌نظر از میزان مهارت این مدیران،سرعت کارایی و کیفیت کار به ناگزیر پایین آمد.بهره‌برداری بالا عوارض جانبی منفی دارد که مدیران به سه دلیل آن‌ها را دست‌کم می‌گیرند.

• آن‌ها ماهیت متغیر کار توسعه را در نظر نمی‌گیرند.

بسیاری از جنبه‌های توسعه‌ی محصول قابل پیش‌بینی نیستند.چه زمانی پروژه‌ها مطرح خواهند شد؟ به کدام کارهای مجزا نیاز دارند و چه قدر طول می‌کشد که کارمندانی که هرگز درگذشته این‌گونه کارها را انجام نداده بودند،بر آن‌ها مسلط شوند؟درواقع شرکت‌ها بیش از همه با فرایندهای تکراری نظیر تولید و پردازش عملیات مالی آشنا هستند که ماهیت متغیر ندارند و غافلگیری‌هایش بسیار معدود است.چنین فرایندهایی با افزایش بهره‌برداری از منابع،رفتاری به‌قاعده از خود نشان می‌دهند.۵٪ به کار اضافه کنید،برای انجام دادن آن ۵٪ وقت بیشتر نیاز دارید.

فرآیندهاباتغییرپذیری بالا،رفتارهای بسیار متفاوتی دارند.با افزایش بهره‌گیری،تاخيرات به‌طور چشمگیر افزایش می‌یابند. در اینجا اگر ۵٪ به کار اضافه کنید،انجام دادن آن ممکن است ۱۰۰٪ بیشتر زمان ببرد.بااین‌حال افراد کمی این تأثیر را درک می‌کنند.در تجربه‌ای که ما با صدها گروه توسعه‌ی محصول داشتیم،متوجه شده‌ایم که بیشتر آن‌ها به‌طور چشمگیری تعهدات بیش‌ازحد دارند.برخی سازمان‌هایی که ما با آن‌ها کار می‌کردیم،برای تکمیل همه‌ی پروژه‌ها در زمان و بودجه‌ی مقرر، به ٥٠% منابع بیشتر نیاز داشتند.

این درست است که مقداری از تغییرپذیری ناشی از فقدان نظم است و این‌که برخی کارهای توسعه محصول(نظیر طراحی اجزاء برای نمونۀ اصلی یک هواپیما یا انجام دادن آزمایش‌های بالینی)بیشتر، کارهای تکراری را شامل می‌شود اما حتی اگر برخی از کارها قابل پیش‌بینی باشند،در صورت ترکیب با کارهای غیرقابل‌پیش‌بینی،شاهد مشکلات ناشی از ایجاد صف برای وظایف خواهید بود.

• آن‌ها درک نمی‌کنند که صف‌ها چه تأثیری بر عملکرد اقتصادی می‌گذارند.

بهره‌گیری زیاد از منابع به‌ناچار صفی از پروژه‌ها را ایجاد می‌کند.هنگامی‌که کارهای نیمه‌تمام، منتظر ظرفیت در دسترس بمانند،مدت‌زمان پروژه افزایش می‌یابد،صف‌ها همچنین بازخوردها را به تأخیر انداخته و باعث می‌شوند که توسعه‌دهندگان،مسیرهای ناکارا و طولانی‌تری را طی کنند. این امر موجب بروز مشکل در سازگاری شرکت‌ها با نیازهای در حال رشد بازار و شناسایی       ضعف‌های محصول پیش از دیر شدن می‌شود.ازقضا، ایــن مشکلات همان مشکلاتی‌اند که مدیران فکر می‌کنند با بهره‌گیری زیاد می‌توانند از آن‌ها پرهیز کنند.

حتی هنگامی‌که مدیران می‌دانند با کارشان،صف ایجاد می‌کنند به‌ندرت متوجه هزینه‌ی اقتصادی آن می‌شوند.ما متوجه شده‌ایم که باوجود امکان اندازه‌گیری کمی هزینه‌ها،بیشتر شرکت‌ها آن را محاسبه نمی‌کنند.مدیران باید هزینه‌ی صف‌ها را با هزینه‌ی ظرفیت استفاده‌نشده،مقایسه کنند تا تعادل را برقرار سازند.

• در توسعه‌ی محصول،تعداد کارهای در جریان معمولاً غیرقابل مشاهده است.

صف‌های تولیدی از چیزهای فیزیکی تشکیل می‌شوند و هنگامی‌که موجودی کارخانه دو برابر می‌شود کاملاً به چشم می‌آید.در توسعه محصول وضع این‌طور نیست.موجودی در اینجا به‌طور عمده از اطلاعاتی مانند اسناد طراحی،رویه‌های آزمایش و نتایج آن‌ها و دستورالعمل ساخت نمونه‌ها، تشکیل شده است.بنابراین هنگامی‌که موجودی در یک فرایند مهندسی دو برابر می‌شود،هیچ‌گونه نشانه‌ی فیزیکی از خود باقی نمی‌گذارد.گذشته از این،ازآنجایی‌که استانداردهای حسابداری این الزام را به وجود می‌آورد که بیشتر موجودی تحقیق و توسعه(R&D) را باارزش صفر نشان دهند، صورتحساب‌های مالی هیچ‌گونه شواهدی از وجود مازاد موجودی در توسعه محصول نشان نمی‌دهند.

مقابله با مشکلی که نمی‌توانید ببینید یا اندازه بگیرید،بسیار دشوار است.یک شرکت بزرگ دارویی را در نظر بگیرید.چند سال قبل رئیس جدید بخش کشفیات دارویی،با معضلی مدیریتی مواجه شد.او نظیر دیگر مدیران اجرایی ارشد که سازمان‌های بزرگ تحقیق و توسعه را اداره می‌کنند،درصدد بود راه‌هایی برای تقویت نوآوری دانشمندانش پیدا کند.او از آن‌ها خواست که با ترکیبات شیمیایی جدید آزمایش‌های بیشتری انجام دهند تا داروهای آینده دار جدید به وجود آورند و هم‌زمان هر چه سریع‌تر گزینه‌های دلسردکننده را از گردونه تحقیق کنار بگذارند اما آزمایش با موجودات زنده بر عهده‌ی واحد آزمایش با حیوانات بود که تحت کنترل او قرار نداشت و به‌صورت یک مرکز هزینه‌بر اداره می‌شد.ارزیابی واحد آزمایش،بر اساس اثربخشی استفاده از منابع آزمایش بود(که به طبع به بهره‌گیری بالا منجر می‌شد)،درنتیجه دانشمندانی که روی کشف دارو کار می‌کردند مجبور بودند سه یا چهار ماه منتظر شوند تا نتایج آزمایش‌هایی که انجام دادنشان کمی بیشتر از یک هفته طول می‌کشد،مشخص شود.سازمان آزمایش که به‌اصطلاح خوب مدیریت می‌شد،مانع از پیشرفت کار واحد اکتشاف بود.

راه‌حل آشکار برای چنین مشکلاتی،تأمین سپر ظرفیتی در فرایندهایی است که بسیار متغیرند. برخی شرکت‌ها دیرزمانی است که این موضوع را دریافته‌اند.3M دهه‌هاست که برنامه‌ریزی برای توسعه‌دهندگان محصول را با در نظر گرفتن85درصد از ظرفیتشان انجام داده است.گوگل نیز به زمان ۲۰ شهرت دارد.به مهندسان اجازه می‌دهد یک روز در هفته را روی هر کاری که دلشان می‌خواهد کار کنند(روشی که معنایش این است که اگر پروژه‌ای از برنامه عقب بماند،ظرفیت اضافی برای رسیدگی به آن وجود دارد) اما در تجربه ما پیاده کردن این نوع راه‌حل بسیار دشوار است.همان‌طور که خواهیم دید،معدودی سازمان می‌توانند در برابر وسوسه استفاده از آخرین ذرات ظرفیت موجود مقاومت کنند.مدیران هنگامی‌که با وقت اضافی روبه‌رو می‌شوند به‌صورت غیرارادی کار بیشتری را در دستور کار قرار می‌دهند.

بااین‌حال راه‌حل‌های عملی و مناسب دیگری هم وجود دارد.

بهره‌گیری بالا به تأخیر منجر می‌شود.

این منحنی با استفاده از تئوری صف محاسبه‌شده است که مطالعه ریاضی پروژه‌هایی است که در انتظار پردازش به سر می‌برند.این منحنی نشان می‌دهد که در فرایندهای متغیر،میزان زمانی که پروژه‌ها در انتظار می‌مانند تا روی آن‌ها کار شود با افزایش بهره‌برداری از منابع به‌شدت افزایش می‌یابد.هرچند این منحنی،بسته به کار پروژه اندکی تغییر می‌کند اما همیشه هنگامی‌که نرخ بهره‌برداری به ۱۰۰٪ نزدیک می‌شود، به‌شدت به سمت بالا متمایل می‌شود

• تغییر سیستم‌های کنترل مدیریت

این کار برای شرکت داروسازی ممکن است مستلزم برداشتن گام‌هایی برای همسو کردن اهداف واحد آزمایش حیوانات با اهداف واحد کشف باشد.برای نمونه شرکت می‌تواند به‌جای بهره‌برداری از منابع،به واحد آزمایش برای ارائه‌ی پاسخ‌های فوری(اندازه‌گیری فاصله‌ی زمانی دریافت درخواست تا انجام آزمایش)پاداش بدهد.

• افزایش ظرفیت به‌صورت انتخابی

اضافه کردن منابع به حوزه‌هایی که در آن‌ها نرخ بهره‌برداری ۷۰٪ یا بیشتر است،می‌تواند به میزان قابل‌توجهی زمان انتظار را کم کند.اگر شرکت داروسازی این کار را در واحد آزمایش انجام می‌داد

بسیار سریع‌تر می‌توانست درباره ترکیبات شیمیایی جدید بازخورد دریافت کند.در محیط‌هایی که در آن‌ها آزمایش با مدل‌سازی کامپیوتری و شبیه‌سازی انجام می‌گیرد،افزایش ظرفیت اغلب نسبتاً کم‌هزینه تمام می‌شود زیرا صرفاً به خرید تجهیزات کامپیوتری و مجوزهای نرم‌افزاری بیشتر نیاز دارد.

• محدود کردن تعداد پروژه‌های فعال

اگر شرکت دارویی نمی‌تواند ظرفیت واحد آزمایش را افزایش دهد،می‌تواند با کاستن از تعداد   پروژه‌های فعالی که به دنبال کشف ترکیبات شیمیایی جدید هستند،نرخ بهره‌برداری را پایین بیاورد.برقراری محدودیت قوی بر آنچه در صف توسعه‌ی محصول می‌گذرد،اغلب به تمرکز بیشتر و اولویت‌های روشن‌تر منجر می‌شود.

• آسان‌تر کردن مشاهده موجودی کار در جریان

یک روش آن است که از تابلوهای نمایش کنترل پروژه استفاده شود.این تابلوها می‌توانند اشکال مختلف داشته باشند اما موضوع محوری در آن‌ها داشتن نوعی علامت فیزیکی،مانند کاغذ یادداشتی است که نماینده‌ی کار توسعه است(به تابلوی کنترل کار در جریان مراجعه کنید). تابلوی کنترل باید وضعیت هر یک از بخش‌های پروژه را نشان داده و باید در مرکز فرایند مدیریتی تیم قرار داشته باشد.تیم ها می‌توانند هرروز جلسه‌ای ۱۵ دقیقه‌ای در اطراف این تابلوها داشته باشند و فعالیت‌ها را هماهنگ کرده و حرکت به سمت هدف را حفظ کنند.

افسانه ۲: پردازش کار در دسته‌های بزرگ،باعث بهبود اقتصادی فرایند توسعه می‌شود.

دومین عامل ایجاد صف در توسعه‌ی محصول،اندازه‌ی دسته کار می‌باشد.بیایید فرض کنیم که محصول جدید از ۲۰۰ عنصر تشکیل شده باشد.شما می‌توانید تصمیم بگیرید کلیۀ این ۲۰۰ عنصر را پیش از آنکه آن‌ها را آزمایش کنید،طراحی کنید.اما اگر فقط 20 عنصر را پیش از شروع آزمایش، طراحی کرده و بسازید،اندازه‌ی دسته90%کوچک‌تر خواهد شد.این کار تأثیر زیادی بر زمان انتظار خواهد داشت زیرا میانگین انتظار در یک فرایند تناسب مستقیمی با اندازه دسته آن دارد.

کاهش اندازه دسته‌ها یکی از اصول بسیار مهم تولید ناب است.دسته‌های کوچک به تولیدکنندگان اجازه می‌دهند کار در جریان را بخش‌بندی کنند و به بازخوردها شتاب دهند.کاری که به‌نوبه‌ی خود چرخه‌های زمانی،کیفیت و کارایی را بهتر می‌کند.دسته‌های کوچک سودمندی بیشتری در توسعه محصول دارند اما معدودی از توسعه‌دهندگان قدرت این روش را درک می‌کنند.

یکی از دلایل ماهیت جریان کار است.چراکه اطلاعاتی که تولید می‌کنند و اندازه دسته‌ها را نمی‌بینند.دوم،به نظر می‌رسد که توسعه‌دهندگان گرایشی درونی به استفاده از دسته‌های بزرگ دارند.احتمالاً به این دلیل که به‌اشتباه بر این باورند که دسته‌های بزرگ باعث صرفه‌جویی ناشی از مقیاس می‌شوند.

در فرایندی که به‌خوبی مدیریت‌شده باشد،اندازه‌ی دسته میان هزینه‌های مبادله و نگهداری تعادل برقرار می‌کند(چگونه اندازۀ بهینۀ دسته را پیدا کنیم را مطالعه کنید).این کار مشابه خرید تخم‌مرغ از فروشگاه است.اگر در یک مراجعه به‌اندازه‌ی مصرف ۱۲ ماه خود تخم‌مرغ بخرید،هزینه تراکنش خود را پایین آورده‌اید بااین‌حال بیشتر تخم‌مرغ‌ها خراب خواهند شد و هزینه‌ی نگهداری شما بالا می‌رود اما اگر در هر بار مراجعه به‌اندازه مصرف یک روز خود تخم‌مرغ بخرید،میزان خراب شدن تخم‌مرغ‌ها پایین خواهد بود اما هزینه‌های تراکنش بالا خواهد رفت.بنابراین شما بایدتعادلی میان این دو برقرار سازید.

شرکت‌هایی که این مفهوم را درک کرده‌اند از پیشرفت‌های فناوری اطلاعات برای کاهش اندازه‌ی دسته استفاده کرده و اغلب نتایج درخور توجهی به دست می‌آورند.برخی شرکت‌های نرم‌افزاری که پیش‌ازاین دسته‌های بزرگ کد را هر ۹۰ روز یک‌بار می‌آزمودند،اکنون چند بار در روز دسته‌های کوچک‌تری را آزمایش می‌کنند.تولیدکننده‌ی دستگاه‌های جانبی رایانه که با گروه نرم‌افزاری خود از رویکرد مشابهی استفاده می‌کرد،زمان چرخه‌ی آزمون نرم‌افزار را ٩٥% (از ٤٨ ماه به2.5 ماه)کاهش داد که باعث افزایش ۲۲۰درصدی اثربخشی و کاهش ۳۳درصدی عیوب شد.صرفه‌جویی در هزینه‌ها دو برابر میزانی بود که شرکت انتظار داشت.هرچند این نتایج استثنایی بودند اما ما متوجه شده‌ایم که کاهش اندازه‌ی دسته،اغلـب به‌طور چشمگیری به پروژه‌های توسعه بهبود می‌بخشد.همچنین ابزارهای مدل‌سازی و شبیه‌سازی رایانه‌ای به میزان چشمگیری اندازه‌ی  بهینه‌ی دسته‌ی آزمایش را در شرکت‌های تولیدکننده‌ی محصولات فیزیکی،کاهش داده است.

نحوه‌ی تشخیص اندازه‌ی بهینه‌ی دسته

تغییر در اندازه‌ی دسته،دو هزینه اصلی را تحت تأثیر قرار می‌دهد:هزینه تراکنش و هزینه نگهداری. با بزرگ شدن اندازه‌ی دسته،سطح میانگین موجودی افزایش می‌یابد که هزینه‌های نگهداری را بالا می‌برد اما هم‌زمان هزینه‌های تراکنش کاهش می‌یابند،زیرا تراکنش‌های کمتری برای برآورده کردن تقاضا،نیاز است.

اندازۀ بهینه‌ی دسته،نقطه‌ای است که در آن هزینه‌ی کل(مجموع هزینه نگهداری و تراکنش)در کمترین حالت خود قرار دارد.هنگامی‌که شرکتی نزدیک به این نقطه فعالیت کند،تغییرات کوچک تأثیر اندکی خواهند داشت.برای مثال،اگر شرکتی در کمتر از ۲۰درصد بالاتر یا پایین‌تر از اندازه‌ی بهینه‌ی دسته کار کند،هزینه‌های کلی کمتر از ۳درصد افزایش می‌یابد.ازاین‌رو حتی تخمین‌های تقریبی(دقیق نباشند)هم به شرکت اجازه‌ی کسب منافع اقتصادی زیادی را می‌دهند.

افسانه 3 : طرح توسعه‌ی شرکت عالی است.باید فقط از آن پیروی شود.

در طول مدت کار مشاوره و پژوهشی حتی با یک پروژه‌ای توسعه‌ی محصول مواجه نشده‌ایم که نیازهایش در طول فرآیند طراحی،ثابت مانده باشند.باوجوداین سازمان‌های زیادی اعتقاد بیش‌ازاندازه ای به برنامه‌های خود دارند.آن‌ها هر انحرافی را به مدیریت و اجرای ضعیف نسبت می‌دهند و برای کمینه ساختن آن‌ها با دقت هر گام را با اهداف و علائم میانی مقایسه می‌کنند.چنین طرز تفکری برای فعالیت‌هایی با تکرار زیاد در فرآیندهای تولیدی ثابت،مناسب است اما در نوآوری محصول که بینش‌های جدید به‌طور روزانه ایجاد می‌شود و شرایط همواره در حال تغییر است، ممکن است به نتایج ضعیف منجر شود.

مطالعه‌ای کلاسیک از حل مشکلات فنی که توماس آلن از دانشگاه MIT انجام داد،ماهیت سیال کار توسعه را نشان می‌دهد.او دریافت که مهندسانی که درحال‌توسعه‌ی یک سیستم فرعی هوافضا بودند،پیش از آنکه بهترین طرح را انتخاب کنند،تعدادی طرح جانشین را تهیه و ارزیابی می‌کردند. آن‌ها با آزمون و اصلاح راه‌حل‌های فنی،ترجیحات خود را پارها تغییر می‌دادند.این کار در پروژه‌های نوآورانه رایج است.آزمـون و تجربه،آنچه کار می‌کند و آنچه نتیجه نمی‌دهد،را آشکار می‌سازد و فرضیات اولیه درزمینه‌ی هزینه و ارزش ممکن است رد شوند.

تعریف نیازهای مشتریان در شروع پروژه‌ای توسعه‌ی محصول،ممکن است مشکل باشد.البته هنگامی‌که به آن فکر می‌کنید،تعجب‌آور نیست چراکه برای مشتریان آسان نیست که به‌طور دقیق ویژگی‌های نیاز خود را برای راه‌حل‌هایی که هنوز وجود ندارند،مشخص کنند.درواقع،آشنایی با ویژگی‌های محصولات موجود،ممکن است در توانایی افراد در بیـان نیـاز بـه محصولی جدید اختلال ایجاد کند.ترجیحات مشتریان نیز ممکن است باعرضه‌ی محصولات جدید به دست رقبا و پیدایش روندهای جدید در طول پروژه‌ای توسعه به‌طور ناگهانی تغییر کنند.

به علت همه‌ی دلایل بیان‌شده پیروی از برنامه‌ی اولیه،هرچقدر هم که مفهوم‌سازی آن عالی باشد و اجرای آن بامهارت انجام شود،ممکن است به فاجعه منجر شود.البته منظور ايـن نیست که به برنامه‌ریزی معتقد نیستیم بلکه توسعه‌ی محصول،مجموعه‌ای از فعالیت‌های پیچیده است که به هماهنگی و توجه دقیق به کوچک‌ترین جزئیات نیاز دارد.اگرچه، برنامه باید به‌صورت فرض اولیه‌ای در نظر گرفته شود که با ظاهر شدن شواهد جديد،تغییر فرضیات اقتصادی و ارزیابی مجدد فرصت، پی‌درپی اصلاح می‌شود

تابلوی کنترل کارهای در جریان

تابلوهای کنترل با نشان دادن مرحله‌ی دقیقی که هر بخش کار در آن قرار دارد،کارهای پنهان را آشکار می‌سازند.در طراحی تابلوها، اغلب گروه‌ها تعداد کارهای هر مرحله را محدود می‌کنند تا از تأخیر جلوگیری شود.این تابلوی ساده دارای ویژگی‌هایی است که احتمال دارد بتوان آن‌ها را در یک پروژه‌ی نرم‌افزاری که دربرگیرنده‌ی تیمی 6تا 10 نفره است،مشاهده کرد.

افسانه 4 : هر چه پروژه زودتر شروع شود،زودتر نیز پایان می‌یابد.

همان‌طور که پیش‌تر بحث کردیم،مدیران از زمان بیکاری نفرت دارند.آن‌ها تمایل دارند از همه‌ی زمان‌های آزاد برای شروع پروژه‌ی جدیدی استفاده کنند.حتی اگر به دلیل اینکه کارمندان باید به پروژه‌های دیگر بازگردند،کار تکمیل نشود بازهم مدیران استدلال می‌کنند که هر کاری که برای پروژه جدید انجام شود،کاری است که بعداً نیازی به انجام آن نیست.چنین تفکری باعث می‌شود شرکت‌ها پروژه‌های بیشتری را آغاز کنند.به‌طوری‌که بیش‌ازحد توانشان است و باعث به هدر رفتن منابع می‌شود.

این تضعیف کردن منابع کار خطرناکی است.اگر شرکتی پیش از آن‌که منابع کافی برای جلو رفتن در اختیار داشته باشد،پروژه‌ای را آغاز کند،در طول فرایند توسعه رفته‌رفته دچار مشکل می‌شود. این امری مشکل‌آفرین است،زیرا کار توسعه محصول بسیار آسیب‌پذیر است: فرضیات درباره‌ی تکنولوژی‌ها و بازار ممکن است به‌سرعت منسوخ شوند.هرقدر پیشرفت پروژه‌ای کندتر باشد، احتمال آنکه مجبور باشد تغییر جهت و هدف دهد،بیشتر خواهد بود.درواقع یکی از شاخه‌های ارتش متوجه شد که اضافه‌هزینه و زمان‌بندی یک پروژه نسبتِ نمایی(به توان4) با مدت‌زمان پروژه دارد.به‌عبارت‌دیگر،هنگامی‌که زمان‌بندی اصلی پروژه دو برابر شود،اضافه ‌هزینه و زمان‌بندی با ضریب ۱۶ افزایش می‌یابد.

اهمیت کاهش میزان کار در جریان هنگامی آشکار می‌شود که به یکی از فرمول‌های کلاسیک تئوری صف نگاهی بیندازیم:قانون لیتل.

این قانون به‌طور ساده می‌گوید که به‌طور میانگین زمان یک سیکل با اندازه‌ی صف تقسیم‌بر نرخ پردازش،متناسب است.بنابراین اگر در صفی در فروشگاه استارباکس۲۰ نفر جلوتر از شما باشند و متصدی قهوه ظرف یک دقیقه به پنج نفر سرویس بدهد،چهار دقیقه طول می‌کشد تا به شما قهوه بدهد.شما می‌توانید با افزایش سرعت پردازش یا کاهش تعداد کارهایی که در دست انجام است،زمان سیکل را کاهش دهید.در اغلب محیط‌ها، اول  تنها گزینه عملی به شمار می‌رود.

راه‌حل برخی توسعه‌دهندگان محصول،کنترل دقیق سرعت(نرخ)شروع کار است.آن‌ها نرخ شروع کار را با نرخ تکمیل آن تطبیق داده،تعداد پروژه‌های در جریان را به‌دقت مدیریت می‌کنند و اطمینان حاصل می‌کنند که پس از راه‌اندازی پروژه به‌اندازه‌ی کافی کارمند به آن اختصاص داده‌شده و از وسوسه‌ی ربودن منابع از پروژه‌ای در جریان، به‌منظور آغاز پروژه‌های جدید اجتناب می‌کنند.

افسانه 5 : هر چه محصول قابلیت‌های بیشتری داشته باشد،مشتریان بیشتر از آن استقبال می‌کنند.

گروه‌های توسعه‌ی محصول معتقدند که افزودن قابلیت‌ها،برای مشتریان ارزش می‌آفریند و حذف آن‌ها ارزش را از بین می‌برد.این رویکرد، دلیل پیچیدگی محصولات را روشن می‌سازد از کنترل‌های وسایل الکتریکی نمی‌توان استفاده کرد،راه‌اندازی رایانه‌ها ساعت‌ها زمان می‌برد،خودروها آن‌قدر دکمه و دستگیره دارند که شبیه کابین خلبان هواپیما شده‌اند و حتی توسترهای معمولی هم صفحه‌ی نمایش LCD و دفترچه راهنما دارند.

شرکت‌هایی که ایده‌ی هرچه بیشتر بهتر را به چالش می‌کشند،محصولاتی تولید می‌کنند که در عین سادگی،مطلوب هستند.بنگ اند الوفسن،تولیدکننده‌ی دانمارکی محصولات صوتی،تلویزیون و تلفن درک کرده که مشتریان خواهند با اکولایزر،بالانس و دیگر ابزار بازی کنند تا ترکیب بهینه‌ی تنظیمات پخش موسیقی را بیابند.بلندگوهای قدرتمند آن به‌طور خودکار، تنظیمات را انجام می‌دهد تا ترانه‌ای را با حداکثر شباهت به نسخه‌ی اصلی پخش کند.تنها کاری که برای کاربران باقی می‌ماند،تنظیم سطح صدای آن است

مشکل است که شرکت‌ها راضی به پذیرش و اجرای اصل مختصر و مفید بودن شوند چراکه به تلاش بیشتری در دو حیطه از توسعه‌ی محصول نیاز دارد.

تعریف مشکل(مسئله)

تشریح مشکلی که توسعه‌دهندگان سعی در حل آن دارند،بیشتر از دیگر بخش‌های فرایند نوآوری دست‌کم گرفته‌شده و بسیاری از شرکت‌ها زمان کمی به آن اختصاص می‌دهند.اهمیت این مرحله در این است که طی آن گروه‌ها درک روشنی از اهداف خود به دست می‌آورند و فرضیاتی ایجاد می‌کنند که می‌توان آن‌ها را به کمک آزمایش‌ها،آزموده و اصلاح کرد.کیفیت بیان مشکل،مشخص- کننده‌ی توان گروه در تمرکز بر قابلیت‌های جدیدی است که اهمیت به سزایی دارند.

هنگامی‌که والت دیزنی مشغول برنامه‌ریزی دیزنی لند بود،سعی نکرد ویژگی‌های بیشتری ازآنچه دیگر پارک‌های سرگرمی داشتند به آن اضافه کند(وسایل اسباب‌بازی،انواع رستوران و فضای پارکینگ).او برعکس پرسش بسیار بزرگ‌تری را مطرح کرد،دیزنی لند چگونه می‌تواند تجربه‌ای جادویی در اختیار بازدیدکنندگان قرار دهد؟قطعاً پاسخ به این پرسش یک‌روزه به دست نمی‌آمد بلکه به دست آوردن این پاسخ به تحقیقات دقیق و دشوار،آزمایش مدام و بینش عمیق ازآنچه ازنظر دیزنی و مشتریانش جادویی نامیده می‌شد،نیاز داشت.IDEO و شرکت‌های دیگر فازهایی به این موضوع اختصاص دادند که طی آن،خود را به‌طور کامل درزمینهٔ ای که محصول یا خدمت موردنظر را در آن تجسم کرده‌اند،فرومی‌برند.توسعه‌دهندگان آن‌ها کلیه‌ی متون مربوط به بازارها را مطالعه کرده،با کاربران آتی مصاحبه می‌کنند،محصولات رقیب را بررسی می‌کنند و همه‌ی آنچه آموخته‌اند را به‌صورت تصاویر، مدل‌ها و نمودارها درمی‌آورند.نتیجه‌ی کار،شناخت عمیق از مشتریانی است که آزموده شده،بهبودیافته یا از طریق فرایند تکراری توسعه،کنار گذاشته‌شده‌اند.

تشخیص آنچه باید پنهان یا حذف شود.

اغلب گروه‌ها وسوسه می‌شوند که باعرضه‌ی راه‌حل‌های فنی زیرکانه که همکاران و مدیران خود را خیره می‌سازد،خودنمایی کنند اما اکثر مشتریان، محصولی را ترجیح می‌دهند که بدون زحمت کار کند.از دیدگاه مشتری،بهترین راه‌حل‌ها،مشکلات را به ساده‌ترین شیوه حل می‌کند و زحمتی که توسعه‌دهندگان به آن افتخار می‌کنند را پنهان می‌سازد.

شرکتی که این موضوع را درک کرده اپل است.این شرکت به دلیل ویژگی‌های بسیاری شناخته‌شده است(محصولات نوآورانه،طراحی‌های شیک و بازاریابی زیرکانه)اما شاید بزرگ‌ترین قدرت آن توانایی دسترسی به قلب مسئله است(مقاله‌ی درس‌های واقعی رهبری استیو جابز نوشته ی والتر ایزاکسون چاپ‌شده در نسخه‌ی آوریل مجله را مطالعه کنید).همان‌طور که مرحوم استیو جابز یک‌بار توضیح داد: ((هنگامی‌که شروع به بررسی مشکل می‌کنید به نظر واقعاً ساده می‌آید،شما حقیقتاً پیچیدگی مشکل را درک نمی‌کنید.بنابراین راه‌حل‌های شما نیز همیشه بیش‌ازاندازه ساده هستند.سپس وارد مسئله می‌شوید و متوجه می‌شوید که واقعاً پیچیده است.بنابراین راه‌حل‌های پیچیده به فکرتان می‌رسند.در اینجاست که اغلب افراد متوقف می‌شوند))،اما اپل این‌گونه نیست.اپل بازهم به حرکت ادامه می‌دهد.جابز در این رابطه گفته: ((اشخاص واقعاً بزرگ، به حرکت ادامه خواهنــد داد، دلیل اصلی مشکل را خواهند یافت و راه‌حل زیبا و برازنده‌ای عرضه خواهند کرد.))

تشخیص اینکه کدام ویژگی‌ها باید حذف شوند به‌اندازه‌ی (یا شاید بیشتر از)یافتن ویژگی‌هایی که باید اضافه شوند،مهم است.متأسفانه بسیاری از شرکت‌ها در تلاش برای نوآور بودن بدون آنکه فاکتورهای مهمى مثل ارزش برای مشتریان و سهولت استفاده را در نظر بگیرند،هر قابلیتی را به محصولشان اضافه می‌کنند.اگر چنین شرکت‌هایی برخی از ویژگی‌های برنامه‌ریزی‌شده را حذف کنند،معمولاً به دلیل کاهش هزینه‌ها یا عقب افتادن از زمان‌بندی یا شکست گروه است.

در عوض،مدیران باید بسنجند که آیا حذف هر یک از ویژگی‌های پیشنهادی،ممکن است محصول موردنظر را بهبود بخشیده و به گروه این امکان را بدهد که توجه خود را بر موضوعاتی متمرکز کند که تجربه‌ی کلی مشتری را ارتقا می‌دهد.تشخیص این امر هنگامی ممکن است که با هریک از احتیاجات ادعایی به‌عنوان فرضیه برخورد کنیم و آن‌ها را در قالب آزمایش‌های کوچک و سریع روی  مشتریان بالقوه آزمایش کنیم.

گروه‌های توسعه فرض می‌کنند که محصولاتشان کامل هستند و هیچ قابلیت دیگری ممکن نیست به آن‌ها اضافه کرد.شاید منطق آن‌ها باید معکوس شود:محصولات زمانی به کمال نزدیک‌تر می‌شوند که هیچ قابلیت دیگری را نتوان از آن‌ها حذف کرد.همان‌طور که لئوناردو داوینچی گفته است: ((سادگی نهایت پیشرفت است.))

افسانه ۶: پروژه‌ها،درصورتی‌که گروه‌ها در اولین تلاش آن‌ها را تکمیل کنند،با موفقیت بیشتری روبه‌رو می‌شوند.

 بسیاری از پروژه‌های توسعه محصول نمی‌توانند به اهداف بودجه‌ای،برنامه‌ی زمان‌بندی و عملکرد فنی خود برسند.بدون شک برنامه‌ریزی ضعیف،فرایندهای انعطاف‌ناپذیر و رهبری ضعیف همگی در این زمینه نقش دارند اما علت دیگری که اغلب نادیده گرفته می‌شود،درخواست مدیران مبنی بر این است که تیم‌هایشان محصول را در همان بار اول بسازند.این‌که از تیم ها بخواهیم در همان حرکت اول به موفقیت دست یابند آن‌ها را به سمت راه‌حل‌هایی که کمترین ریسک را دارند متمایل می‌کند.حتی اگر مشتریان،آن‌ها را بهبود مطلوبی نسبت به آنچه در دسترس است،ندانند.بدتر از این، تیم ها برای دنبال کردن راه‌حل‌های نوآورانه برای مشکلات مشتریان انگیزه‌ای نخواهند داشت.

گروه برای پرهیز از چنین مشکلاتی،باید فرآیند خطی را پیگیری کند که هر مرحله‌ی آن(شناسایی ،طراحی،ساخت،آزمایش،متناسب‌سازی،عرضه به بازار)در درگاه‌های بازبینی با دقت پایش می‌شود، کار مرحله‌ی بعد آغاز نمی‌شود مگر آنکه پروژه از درگاه پیشین عبور کند.با پیشرفت پروژه در مراحل مختلف و نزدیک شدن به انتهای آن،تعهدات چشمگیری پدیدار می‌شوند و هزینه‌ی پاسخگویی به بینش‌های جدید به‌صورت نمایی افزایش پیدا می‌کند.آزمایش‌های موفق در مراحل آخر جشن گرفته می‌شوند و غافلگیری‌ها،هرچقدر هم که باارزش باشند،ضعف و شکست محسوب می‌شوند.متأسفانه چنین فرآیند خطی ممکن است باعث سرریز در پروژه شود(از زمان‌بندی و هزینه فراتر رود)زیرا بازخورد آزمایش‌ها دچار تأخیر شده،گروه‌ها بیش ازآنچه لازم است به ایده‌های بد وفادار می‌مانند و مشکلات تا زمانی که رفع آن‌ها پرهزینه شود،آشکار نمی‌شوند.

اگر افراد با سرعت و فراوانی زیاد،کارها را تکرار کنند و از شکست‌ها درس بگیرند،تحمل اشتباه در دور اول می‌تواند بهترین راهبرد باشد.پیشرفت در فناوری شبیه‌سازی و پیش نمونه‌سازی،عملکرد سریع به این شکل را بسیار آسان‌تر و کم‌هزینه‌تر ساخته است.یافته‌های ما در مطالعه‌ی ۳۹۱ گروه را که مدارهای مجتمع خاص می‌ساختند،در نظر بگیرید.گروه‌هایی که رویکرد تکرارشونده را پیگیری و آزمایش‌ها به‌موقع و زیادی را اجرا می‌کردند،مرتکب خطاهای بیشتری می‌شدند اما چون‌که از فناوری‌های پیش نمونه‌سازی کم‌هزینه استفاده می‌کردند،نسبت به گروه‌هایی که سعی  می‌کردند در دور اول،طراحی درستی داشته باشند،عملکردشان ازنظر زمان و تلاش موردنیاز،برتر بود.گروه‌هایی که با هزینه‌های پیش نمونه‌سازی بالا مواجه بودند،تلاش بیشتری درزمینهٔ ی   تهیه‌ی مشخصات،توسعه و اعتبار سنجی می‌کردند و ازآنجایی‌که فعالیت‌های تکرارشونده‌ی خود را دیرتر انجام می‌دادند(و تعداد تکرار بسیار کمتری داشتند) در کشف مشکلات مهم نیز بـا تأخیر مواجه می‌شدند.

آزمودن ایده‌های متنوع برای پروژه‌های نوآورانه اهمیت بسیاری دارد. البته هنگامی‌که افراد به‌سرعت و به‌طور مکرر آزمایش می‌کنند،بسیاری از مفاهیم جدید با شکست روبه‌رو می‌شوند اما چنین شکست‌های زودهنگامی می‌توانند مطلوب باشد،زیرا به تیم ها این امکان را می‌دهند تا گزینه‌های ضعیف را به‌سرعت حذف کرده و بر راه‌حل‌های نویدبخش متمرکز شوند.یک تست تصادف که نشان می‌دهد طراحی اتومبیل ناامن است،دارویی که معلوم می‌شود سمی است یا میانجی کاربری یک نرم‌افزار که مشتریان را سردرگم می‌کند،مشروط بر این‌که در اوایل فرایند کشف شوند،همگی می‌توانند نتایج مطلوبی به شمار روند.به‌بیان‌دیگر زمانی که منابع اندکی صرف آن‌ها شده است،طراحی‌ها هنوز بسیار انعطاف‌پذیرند و راه‌حل‌های دیگر را می‌توان امتحان کرد.

این خواسته که محصول در همان بار اول درست از کار درآید صرفاً تیم ها را به این امر متمایل می‌کند که توجه خود را بر راه‌حل‌هایی با کمترین ریسک متمرکز کنند.مثال کلاسیک مزایای روش زود شکست بخور،زیاد شکست بخور پیروزی شگفت‌آور تیم نیوزیلند در جام ۱۹۹۵ آمریکاست.این تیم برای آزمایش ایده‌های بهبود طراحی سازه قایق از دو قایق تقریباً یکسان استفاده کرد.یکی را در طول دوره پروژه تغییر دادند و یک قایق، قایق کنترل،بدون تغییر ماند.این تیم هرروز فرضیه‌هایی را در کامپیوتر محلی شبیه‌سازی می‌کرد،آن‌هایی را که به نظر مفید بودند به قایق قابل‌تغییر اعمال می‌کرده و با قایق کنترل مسابقه می‌دادند و نتایج را تحلیل می‌کردند.

راه‌حل‌های کاربردی برای غلبه بر تصورات نادرست