منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا با کمک هوش مصنوعی · مهر ۱۴۰۵ · زمان مطالعه: حدود ۹ دقیقه

فرایند توسعهٔ محصول (Product Development Process) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند. ترجمه و بازنویسی این متن با کمک هوش مصنوعی انجام شده است.

از سه عضو یک تیم بپرسید «کار ما از کجا شروع می‌شود؟». مدیر محصول می‌گوید از نقشهٔ راه. طراح می‌گوید از پژوهش کاربر. برنامه‌نویس می‌گوید از تیکتی که در صف اسپرینت است. هر سه راست می‌گویند، و مشکل همین است.

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

فرایند توسعهٔ محصول چیست؟

فرایند توسعهٔ محصول (Product Development Process) روش و ساختار سازمانی‌ای است که اعضای تیم را در کل چرخهٔ ساختن یک محصول راهنمایی می‌کند. به تعریف منبع، این چرخه از پژوهش کاربر شروع می‌شود و از پیاده‌سازی تا انتشار ادامه پیدا می‌کند.

منبع روی یک نکته تأکید دارد. سازمان باید پیش از شروع کار روی فرایند توافق کند، و آن فرایند باید با فرهنگ و مدل کسب‌وکار همان سازمان جور باشد. فرایندی که از شرکت دیگری کپی شده، معمولاً روی کاغذ می‌ماند.

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

چهار شکل رایج

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

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

مرحله‌دروازه. رابرت کوپر، پژوهشگر کانادایی مدیریت نوآوری، این مدل را در دههٔ ۱۹۸۰ معرفی کرد. کار به چند مرحله تقسیم می‌شود و میان هر دو مرحله یک «دروازه» است. در هر دروازه، گروهی از تصمیم‌گیرندگان با معیارهای از پیش تعیین‌شده تصمیم می‌گیرند پروژه ادامه پیدا کند، برگردد یا متوقف شود. این مدل در شرکت‌های بزرگ رایج است، چون جلوی خرج کردن روی ایده‌های ضعیف را می‌گیرد.

چابک و ناب. کار در حلقه‌های کوتاه انجام می‌شود. در هر حلقه، بخش کوچکی ساخته می‌شود، به دست کاربر می‌رسد و از آن یاد گرفته می‌شود. توسعهٔ چابک با بیانیه‌ای در سال ۲۰۰۱ شکل گرفت. «استارتاپ ناب» اریک ریس در سال ۲۰۱۱ همین منطق را به کل کسب‌وکار برد: بساز، بسنج، یاد بگیر. لین یوایکس جای طراحی را در این حلقه‌ها پیدا کرده است.

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

طراحی کجای هر شکل می‌نشیند

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

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

در مرحله‌دروازه، طراحی می‌تواند ابزار تصمیم در دروازه‌ها باشد. نمونهٔ اولیه‌ای که با کاربر آزموده شده، بهتر از هر سندی نشان می‌دهد ایده ارزش ادامه دارد یا نه. طراحی که این را بداند، کارش را برای روز دروازه آماده می‌کند.

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

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

هشت عامل موفقیت

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

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

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

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

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

وقتی فرایند جای کار را می‌گیرد

این بخش افزودهٔ من است. منبع فرایند رسمی را همیشه مفید می‌داند، و پژوهش گونزالس و پالاسیوس هم همین را نشان می‌دهد. ولی فرایند یک خطر شناخته‌شده هم دارد: جای خود کار را بگیرد.

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

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

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

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

در بافت فارسی

چند نکته برای تیم‌هایی که در بازار ایران محصول می‌سازند.

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

دو: «چابک» گاهی یعنی «بی‌برنامه». در بعضی تیم‌ها، واژهٔ چابک توجیهی شده برای اینکه اولویت‌ها هر روز عوض شوند. چابکی واقعی حلقهٔ یادگیری دارد: هر اسپرینت چیزی به دست کاربر می‌رسد و چیزی از آن یاد گرفته می‌شود. اگر این حلقه نیست، تیم فقط عجله می‌کند.

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

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

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

جمع‌بندی

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

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

اگر بخواهم یک پرسش بگذارم: آخرین کاری که تیم شما تحویل داد، دقیقاً از کجا شروع شد، و آیا این همان جایی است که فرایند رسمی‌تان می‌گوید؟