تحویل‌شدنی‌های بسیاری از پروژه‌ها به اندازه‌ای پرشمارند که اگر در فهرستی ساده و تک‌سطحی قرار داده شوند فهرست آنقدر بلند می‌شود که قابل استفاده نخواهد بود. راهکار معمول در چنین مواقعی، دسته‌بندی کردن آیتم‌های فهرست است و برای تحویل‌شدنی‌ها نیز می‌توان چنین کاری کرد. به‌جای یک سطح دسته‌بندی هم می‌توانید چندین سطح داشت که اصلاحا سلسله‌مراتبی نامیده می‌شود.
بسیاری از متدولوژی‌های مدیریت پروژه استفاده از دسته‌بندی‌های سلسله مراتبی را پیشنهاد می‌کنند. در چنین دسته‌بندی‌هایی محصول اصلی پروژه به چند تحویل‌شدنی کلان تقسیم می‌شود، هرکدام از آن‌ها به چند تحویل‌شدنی کوچک‌تر و روند به همین ترتیب ادامه پیدا می‌کند تا به جزئی‌ترین تحویل‌شدنی‌ها برسیم.
این دسته‌بندی‌های سلسله‌مراتبی نام‌های مختلفی دارند:
بیشتر منابع: ساختار شکست کار (work breakdown structure)
به‌کارگیری چنین ساختارهایی بسیار کارآمد است، ولی بازهم باید توجه داشته باشید که لیست‌های تک سطحی برای پروژه‌های بسیار کوچک کافی و مناسب‌تر هستند. از این رو، در متدولوژی micro.P3.express، که نسخه ویژه‌ای از P3.express برای پروژه‌های بسیار کوچک است، وجود نقشه تحویل‌شدنی‌ها الزامی نیست.
در هر زمان شماری تحویل‌شدنی نیمه‌کاره در پروژه وجود دارد. برخی پروژه‌ها حساسیتی به خرج نمی‌دهند و تحویل‌شدنی‌های پرشماری را به‌موازت هم پیش می‌برند که باعث افت بهره‌وری کلی پروژه می‌شود.
محدود کردن کار نیمه‌کاره یکی از اصل‌های زیربنایی در تولید Lean است، که تاثیر بزرگی هم در پروژه‌های چابک گذاشته است. با این‌همه، کاربرد آن محدود به پروژه‌های چابک نیست و در همه پروژه‌ها باید به آن توجه داشت.
یکی از مسایل اصلی درباره افزایش بیش از اندازه شمار کارهای موازی این است که وقتی چنین فرهنگی در پروژه وجود داشته باشد، هرگاه اعضای تیم در ساخت تحویل‌شدنی‌ای به دشواری بر بخورند به‌جای گره‌گشایی به سراغ انجام تحویل‌شدنی دیگری می‌روند که خروجی کارشان به ظاهر بالاتر باشد. هرچه بیشتر از زمان بروز دشواری بگذرد، حلش سخت‌تر می‌شود و از این رو چنین روندی مناسب نیست. همیشه به یاد داشته باشید که هدف زودتر آغاز کردن کارها نیست، بلکه زودتر به پایان رساندن آن‌هاست.
برخی از متدولوژی‌ها عناصری دارند که تیم پروژه را تشویق می‌کند که تحویل‌شدنی‌های نیمه‌کاره را به سرانجام برسانند و پس از آن دست به کار تحویل‌شدنی‌های تازه بشوند. چنین عنصری را می‌توان به روندی ضمنی برای دریافت تایید نیز متصل کرد که خود مانع بروز بسیاری از دشواری‌های زمان تحویل نهایی می‌شود و در بخش گذشته بررسی شد. اگر متدولوژیتان چنین جنبه‌ای را …
گاهی شناسایی ذی‌نفعان کار ساده‌ای نیست. نمونه‌اش پناهگاه کوهستانیست که پیش از این طرح شده بود.
باید در آغاز کار زمان کافی صرف شناسایی ذی‌نفعان کلیدی کرد، زیرا برخی از ذی‌نفعان، مانند قانون‌گذاران، چنان تاثیرهای کلانی بر پروژه می‌گذارند که ممکن است توجیه‌پذیری آن را از بین ببرند. اگر این ذی‌نفعان در آغاز کار شناسایی شوند، شاید متوجه شوید که بهتر است زمان و هزینه‌ای صرف پروژه نشده، لغو شود.
گذشته از شناسایی نخستین، باید دایما در هنگام اجرای پروژه نیز به فکر شناسایی ذی‌نفعان تازه باشید، زیرا
شاید برخی از ذی‌نفعان را از قلم انداخته باشید، و
شاید تغییرهایی در محیط پروژه به وجود آمده، ذی‌نفعان تازه‌ای به وجود آورده باشد.
مانند بسیاری دیگر از حوزه‌های مدیریت پروژه، بهتر است به اسناد پروژه‌های همانند که در گذشته اجرا کرده‌اید نیز مراجعه کنید تا ببینید چه کسانی بر آن اثر گذاشته‌اند. اینگونه می‌توانید ذی‌نفعان بیشتری شناسایی کنید که شاید بدون آن از قلم بیفتند. این مسئله یکی از دلایل فراوانیست که بر لزوم مستندسازی و بایگانی مناسب اسناد پروژه‌ها پافشاری می‌کنیم.
متدولوژی خود را بررسی کنید تا ببینید که روندی که برای شناسایی ذی‌نفعان دارد برای شرایط پروژه‌تان مناسب است یا نه، و اگر لازم است، فعالیت‌های ساخت‌یافته‌تری برای این منظور به آن بیفزایید.
نخستین گام مدیریت ریسک، شناسایی ریسک‌هاست. باید در آغاز پروژه کارگاه‌هایی برگزار کرد و با کمک اعضای تیم پروژه به عدم‌قطعیت‌ها اندیشید. با این همه، هرچه هم که در آغاز کار زمان صرف شناسایی ریسک‌ها کنیم، باز هم مواردی شناسایی نشده باقی می‌مانند و فقط هنگامی که به آن‌ها نزدیک‌تر شویم از آن‌ها آگاه می‌شویم. گاهی هم ریسک‌های تازه‌ای به دلیل تغییر شرایط محیطی به وجود می‌آیند. از این رو، لازم است که روند شناسایی ریسک‌ها دایما تکرار شود.
یک راه خوب این است که بخش کوچکی برای شناسایی ریسک‌های تازه به انتهای بیشتر جلسه‌ها و کارگاه‌ها بیفزایید.
در P3.express مجموعه فعالیت‌هایی برای آغازش پروژه و پایان پروژه وجود دارد. در میان این دو، چرخه‌هایی ماهانه برای انجام کار پروژه وجود دارد، با گروه فعالیت‌هایی برای آغازش ماهانه و پایان ماهانه. درون چرخه‌های ماهانه نیز فعالیت‌هایی برای مدیریت هفتگی و مدیریت روزانه وجود دارد. پس از پایان پروژه شماری فعالیت مدیریت پساپروژه برای ارزیابی منافع پروژه و طراحی اقدام‌های تازه وجود دارد.
برای آغازش پروژه باید اعضای کلیدی تیم منصوب و به کمک آن‌ها برنامه‌ای کلان آماده شود. برنامه برای حامی پروژه فرستاده می‌شود تا درباره اجرا کردن یا نکردن پروژه تصمیم بگیرد.
ترجیح بر این است که برنامه نخستین کلان باشد و سپس در هر آغازش ماهانه بازبینی شده، برای ماه پیش رو تفصیلی شود. اطلاعات بازبینی و تفصیلی شده در پایان آغازش ماهانه برای حامی پروژه فرستاده می‌شوند تا درباره ادامه دادن یا متوقف کردن پروژه تصمیم بگیرد.
در طول ماه بر روی محصول پروژه کار می‌کنیم و هر هفته پیشرفت آن را ارزیابی کرده، به انحراف‌ها واکنش نشان می‌دهیم. فعالیت‌هایی روزانه نیز برای تایید تحویل‌شدنی‌های کامل شده و پیگیری اقلام قابل‌پیگیری (ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها) وجود دارد.
در زمان پایان ماهانه، رضایت ذی‌نفعان را ارزیابی کرده، بر آن پایه برنامه‌هایی برای بهبود پروژه در ماه بعد طراحی می‌کنیم. …
وقتی ایده پروژه‌ای شکل می‌گیرد و به نظر جالب می‌رسد و پیش از آن‌که تصمیم نهایی درباره آن گرفته شود، فرآیند راه‌اندازی پروژه اجرا می‌شود. در این فرآیند برخی اعضای کلیدی تیم منصوب می‌شوند و همراه هم اطلاعاتی کلان گردآوری می‌کنند که در پایان در سندی با نام خلاصه پروژه (project brief) ذخیره خواهند شد. این سند اطلاعاتی تقریبی درباره توجیه‌پذیری پروژه و شیوه اجرای مناسب آن دارد.
مدیر ارشد و سایر افراد تصمیم‌گیرنده بر پایه اطلاعات گردآوری شده تصمیم می‌گیرند که پروژه ارزش بررسی دقیق‌تر دارد یا خیر. اگر داشته باشد، فرآیند آغازش پروژه اجرا می‌شود.
در آغازش پروژه برنامه کلان آماده می‌شود و بر آن پایه می‌توان توجیه‌پذیری پروژه را با اطمینان بیشتر برآورد کرد. این اطلاعات در سندی با نام سند آغازش پروژه (project initiation documentation) ذخیره می‌شود. این سند نیز در اختیار مدیر ارشد و سایر تصمیم‌گیرندگان گذاشته می‌شود که تصمیم نهایی را برای آغاز کردن یا نکردن کار اجرایی پروژه بگیرند.
همان‌گونه که می‌بینید، پروژه در دو مرحله ارزیابی می‌شود. در مرحله نخست به‌سرعت و با صرف توان محدود آن را بررسی می‌کنیم تا پروژه‌هایی که اصلا توجیه‌پذیر نیستند حذف شوند. در مرحله دوم، با صرف زمان و انرژی بیشتر، پروژه را به دقت بررسی می‌کنیم و بر آن پایه تصمیم نهایی را می‌گیریم.
برخلاف بیشتر سیستم‌ها، اسکرام آغازش و پایانی رسمی و ساخت‌یافته تعریف نکرده است و فقط بر روند مناسب برای زمان اجرای پروژه تمرکز دارد. دلیل این مسئله این است که اسکرام برآن نیست که همه جنبه‌های مدیریت پروژه را پوشش دهد.
در آغاز پروژه، مالک محصول با ذی‌نفعان گفتگو می‌کند و فهرستی ساده و نخستین از قابلیت‌های مدنظرشان فراهم می‌کند. فهرست محصول (product backlog) به هیچ وجه کامل نیست و در طول اجرای پروژه دستخوش دگرگونی‌های فراوانی خواهد شد.
مالک محصول هم مسئول تدوین آیتم‌های فهرست است و هم مرتب کردن آن‌ها بر پایه ارزششان. آیتم‌های باارزش‌تر و مهم‌تر در بالای فهرست قرار می‌گیرند.
اسکرام نیز مانند پرینس۲ و P3.express چرخه‌ایست و چرخه‌هایش Sprint نام دارند. این چرخه‌ها مدت‌زمان ثابتی دارند و همیشه در زمان معین پایان می‌پذیرند، حتی اگر کار چرخه کامل نشده باشد. تعیین مدت‌زمان چرخه‌ها بر دوش تیم است، ولی این مدت نباید بیشتر از یک ماه باشد. برای مدت‌زمان چرخه‌ها هر بار تصمیم‌گیری نمی‌کنیم، بلکه همه چرخه‌ها را با مدت یکسان اجرا می‌کنیم، مگر این‌که پس از مدتی متوجه شویم که مدت تعیین شده برای نوع پروژه مناسب نیست و بهتر است آن را برای چرخه‌های بعد اصلاح کنیم.
هر چرخه با جلسه‌ای حداکثر ۸ ساعته برای برنامه‌ریزی چرخه آغاز می‌شود. اعضای تیم گرد هم می‌آیند و درباره آیتم‌هایی که در بالای فهرست قرار دارند …
کار در DSDM با فاز پیشاپروژه آغاز می‌شود. در این فاز توجیه‌پذیری پروژه را به‌کوتاهی بررسی و نتیجه را همراه با اطلاعات تکمیلی در سندی با نام terms of reference ذخیره می‌کنیم. تصمیم‌گیرندگان با کمک این اطلاعات فرمان توقف کار یا اجرای فاز بعدی را می‌دهند.
فاز بعدی، توجیه‌پذیری است. در این فاز زمان بیشتری صرف شناسایی پروژه و جنبه‌های کسب و کار، فنی، و مدیریتی آن می‌کنیم. اطلاعات گردآوری شده در سند ارزیابی توجیه‌پذیری ذخیره می‌شوند و برای تصمیم‌گیرندگان فرستاده می‌شوند تا فرمان توقف پروژه یا اجرای فاز بعد را بدهند.
فاز سوم شالوده است. در این فاز برنامه کلان پروژه را آماده می‌کنیم که شالوده پروژه به شمار خواهد رفت. بر پایه برنامه کلان می‌توان درک بهتری از توجیه‌پذیری آن نیز پیدا کرد و همه این اطلاعات در قالب سندی با نام چکیده شالوده در اختیار تصمیم‌گیرندگان قرار می‌گیرد.
اگر پروژه توجیه‌پذیر باشد، آن را در فازی تکرار شونده با نام توسعه تکاملی اجرا خواهیم کرد. در هر چرخه این فاز نسخه تازه‌ای از محصول پروژه آماده می‌شود و مانند همه پروژه‌های چابک برای گردآوری بازخورد و روشن کردن مسیر پیش رو به کار می‌رود.
فاز دیگر، انتشار است. این فاز را می‌توان پس از هر چرخه توسعه تکاملی یا با بسامدی کمتر تکرار کرد. در هر تکرار، تازه‌ترین نسخه نرم‌افزار در اختیار کاربران نهایی قرار می‌گیرد.
اختصاصی‌سازی سیستم بحثی کمابیش طولانیست و در فصل چهارم با تفصیل بیشتری به آن خواهیم پرداخت. اکنون بر موضوع دیگری تمرکز می‌کنیم: فرآیند و روش اختصاصی‌سازی.
در پم‌باک ۷ روشی دومرحله‌ای برای اختصاصی‌سازی پیشنهاد کرده‌ایم:
پروژه‌هایی که در یک سازمان اجرا می‌شوند همانندی‌های فراوانی دارند. از این رو، به‌جای این‌که هربار متدولوژی مدیریت پروژه را درون پروژه اختصاصی کنید، بهتر است که یک‌بار آن را کلان و نیمه‌کاره در سطح سازمان و برای جنبه‌های مشترک پروژه‌ها اختصاصی‌سازی کنید. اگر نیاز باشد می‌توانید بیشتر از یک حالت نیمه اختصاصی‌سازی شده در سطح سازمان داشته باشید تا انواع مختلفی از پروژه را پشتیبانی کنند.
هرچه هم که پروژه‌های سازمان همانند باشند، باز هم دقیقا یکسان نیستند و باید حدی از اختصاصی‌سازی درون پروژه انجام شود. از این رو، اختصاصی‌سازی سازمانی نیمه‌کاره است و قسمت دوم آن جداگانه در هر پروژه انجام می‌شود.
برای نخستین مرحله اختصاصی‌سازی نیاز به مرکزی در سازمان دارید. این مرکز را می‌توان مرکز تعالی (center of excellence) نامید. بسیاری علاقه وافر به عبارت PMO دارند (مخفف project management office یا عبارت‌های دیگر). اگر سازمان PMO داشته باشد، مدیریت نخستین مرحله اختصاصی‌سازی می‌تواند از وظایف اصلی آن به شمار برود.
پم‌باک و سایر استانداردهای PMI با روندی مطابق با آنچه برای تدوین استانداردها در موسسه استاندارد آمریکا (ANSI) تعریف شده مدیریت می‌شوند. در ویرایش‌های نخستین تلاش بر این بود که این روند تا جای ممکن با آنچه موسسه بین‌المللی استانداردسازی (ISO) انتظار دارد نیز همخوان باشد، ولی متاسفانه این توجه در سال‌های اخیر کمتر شده است.
متاسفانه PMI در عمل موسسه‌ای بین‌المللی نیست، بلکه موسسه‌ایست آمریکایی که بیشتر نقاط جهان فعال و شناخته‌شده است. این مسئله از سوی بسیاری کمبودی زیربنایی به شمار می‌رود.
تیم تالیف پم‌باک دوازده عضو داشت و من هم یکی از این افراد بودم. اعضای تیم از نقاط مختلف جهان و با پس‌زمینه‌ها و مهارت‌های گوناگون انتخاب شده بودند و تدوین استاندارد را بردوش داشتند. تیمی هم برای رهبری پروژه وجود داشت که مسئول هماهنگی‌ها، نظارت بر مطابقت کارها با الزامات موسسه و همانند آن بود.
گروهی حدودا هفتاد نفره مسئولیت مرور خروجی‌های تیم تالیف را در زمان کار داشت. در پایان، پیش‌نویسی از محتوا در اختیار عموم قرار گرفت و حدود ششصد نفر دیدگاه‌هایشان را در اختیارمان قرار دادند. دیدگاه‌ها گونه‌ای میان اعضای تیم تالیف بخش شد که هر دیدگاه را دو نفر مستقل از هم بررسی کنند و درباره آن تصمیم بگیرند. اگر تصمیم آن دو عضو یکسان نمی‌بود، نفر سومی هم دیدگاه را بررسی می‌کرد و بر پایه رای اکثریت در میان این سه …
باوجود استدلال‌های بخش پیش، چه‌بسا هنوز هم احساس بهتری درباره بازی نخست داشته باشید که طبیعیست و ترس از دست دادن (loss aversion) نام دارد. بار احساسی از دست دادن بیشتر از به دست آوردن است. این نسبت در فرهنگ‌ها و افراد مختلف یکسان نیست، ولی این مقدار برای بسیاری افراد حدود دو و نیم است. در نمونه پیشین، امید ریاضی گزینه دوم دو برابر گزینه نخست بود که کمتر از آستانه دو و نیم برابر است و از این رو، بسیاری از افراد گزینه نخست را ترجیح می‌دهند.
ترس از دست دادن گرایشی طبیعیست که در همه ما وجود دارد. این گرایش به شکل تکاملی در اجدادمان که در جنگل و غار زندگی می‌کردند و جانشان دایما درخطر بود شکل گرفته است و در دنیای امروزی کاربرد کمتری دارد. این گرایش یکی از فریب‌های ذهنی (cognitive bias) است. موارد زیر نمونه‌های دیگری از فریب‌های ذهنی‌اند:
گاهی هنگامی که ایده‌ای داریم و درستی آن را ارزیابی می‌کنیم، ناخودآگاه تنها شواهد تایید کننده را می‌بینیم (confirmation bias).
گاهی کارهایی که آغاز کرده‌ایم توجیه‌پذیری خود را از دست می‌دهند، ولی به دلیل هزینه یا کوششی که پیشتر برایشان کرده‌ایم ادامه‌شان می‌دهیم تا به پایان برسند، با این‌که این کار فقط باعث اتلاف هزینه و توان بیشتر می‌شود (sunk cost effect).
گاهی افراد و شرایط را فقط بر پایه کلیشه‌هایی که درباره‌شان وجود دارد قضاوت می‌کنیم …
محصول این دو لایه را می‌توان به ترتیب برنامه و متابرنامه نامید. برای نمونه، برنامه ریسک فهرستی از ریسک‌های شناسایی شده و واکنش‌هاییست که برایشان طراحی کرده‌اید. این برنامه می‌تواند در صفحه‌گسترده‌ای در اکسل و نرم‌افزارهای همانند آن باشد و فهرست ریسک (risk register) نامیده شود. از سوی دیگر، متابرنامه ریسک سندیست که شیوه مدیریت ریسک را توضیح می‌دهد: تکنیک‌هایی که استفاده می‌کنید، جریان کار، اسناد، و …
هر متدولوژی شیوه مدیریت هرکدام از حوزه‌ها را توضیح می‌دهد و اینگونه بخشی از متابرنامه‌ها در متدولوژی وجود دارد، ولی همه جنبه‌ها را نمی‌توان در متدولوژی لحاظ کرد و از این رو گاهی پیشنهاد می‌شود که برای هر حوزه متابرنامه‌ای نیز بسازید.
معمولا متدولوژی‌هایی مانند پرینس۲، که نیاز به اختصاصی‌سازی نخستین دارند، ساخت متابرنامه‌ها را نیز پیشنهاد می‌کنند، ولی آن‌هایی که مانند P3.express نیاز به اختصاصی‌سازی نخستین ندارند چنین پیشنهادی نیز نمی‌کنند. با این‌همه، حتی در مورد دوم هم اگر حوزه‌ای وجود دارد که حساسیت‌های ویژه‌ای در پروژه دارد، بهتر است برایش در آغاز متابرنامه آماده کنید. برای نمونه، اگر تدارکات پروژه چالش‌برانگیز است، شیوه برنامه‌ریزی، ارزیابی و کنترل آن را تعیین کرده، در سندی با …
اگر سیستم مدیریت پروژه خود را شکل دهید و سپس به این بیندیشید که چگونه می‌توان عناصری برای مدیریت کیفیت به آن افزود، احتمالا چندان موفق نخواهید بود. مدیریت کیفیت باید عنصری یکپارچه در سیستم بوده، از آغاز در شکل‌دهی آن لحاظ شده باشد.
منابع ساخت‌یافته درباره مدیریت پروژه را به دو دسته می‌توان تقسیم کرد:
متدولوژی‌ها راه مناسب را در پروژه نشان می‌دهند.
راهنماها به شما کمک می‌کنند که متدولوژی خود را کارآتر کنید.
نخستین عنصری که نیاز دارید متدولوژی است. پس از استقرار متدولوژی مناسب، می‌توانید از راهنماها برای افزایش کارآیی سیستم کمک بگیرید.
پم‌باک راهنماست و نه متدولوژی. همواره کسان زیادی کوشش کرده‌اند که آن را به‌شکل یک متدولوژی به کار ببرند و هیچ‌گاه نیز موفق نبوده‌اند. این مسئله چنان حاد بود که توضیحی به مقدمه ویرایش‌های پیشین افزوده شد و متدولوژی نبودن پم‌باک و لزوم بهره‌مندی از یک متدولوژی در کنار آن را توضیح داد. بااین‌همه، رویکرد فرآیند محور پم‌باک همچنان سوتفاهم ایجاد می‌کرد و کماکان کسان زیادی آن را با یک متدولوژی اشتباه می‌گرفتند. یکی از اهداف تدوین نسخه هفتم این بود که به‌گونه‌ای زیربنایی جلوی این اشتباه گرفته شود و گمان می‌کنم در این کار موفق بوده‌ایم! ساختار اصل محور نسخه هفتم را دیگر نمی‌توان با متدولوژی اشتباه گرفت.
پم‌باک به دو شکل می‌تواند به شما کمک کند:
اصل‌ها کمک می‌کنند که تعبیر و تفسیر بهتری از متدولوژی‌های مدیریت پروژه داشته باشید.
حوزه‌های عملکردی کمک می‌کنند که متدولوژی خود را کارآتر کنید.
از این رو، در ادامه کتاب این سه فصل اصلی وجود دارد:
دو راه کلی برای ساخت محصول پروژه وجود دارد، متعین (predictive) و تطبیقی (adaptive):
در روش متعین، در آغاز پروژه به همه جنبه‌ها می‌اندیشیم، محصول را به‌دقت طراحی می‌کنیم و سپس آن را می‌سازیم. پروژه‌ای برای ساخت و فرستادن یک مریخ‌نورد را در نظر بگیرید. مریخ‌نورد باید در محیطی کاملا متفاوت با محیط عادی ما کار کند، با گرانش، نوع اتمسفر و بسیاری از شاخص‌هایی که مانند زمین نیستند. چنین پروژه‌ای بسیار پرهزینه هم هست و نمی‌توان با آزمایش و خطای فراوان به نتیجه رسید، بلکه باید با بهره‌مندی بهینه از دانش موجود پیش‌بینی همه مسایل را در آغاز کرد و سپس محصول را ساخت. به‌عنوان نمونه‌ای ساده‌تر، ساخت یک پل را در نظر بگیرید: چنین محصولی هم باید به شکل متعین ساخته شود.
در برخی پروژه‌ها که به شدت وابسته به برداشت و سلیقه مشتری هستند نمی‌توان محصول مناسب را پیش‌بینی کرد، چون رفتار انسان‌ها پیش‌بینی‌ناپذیرند. از این رو، به‌جای شیوه متعین از شیوه تطبیقی استفاده می‌کنیم. در این شیوه به‌جای این‌که همه‌چیز را در آغاز طراحی کنیم و سپس بسازیم، ترتیبی فراهم می‌کنیم که بتوان بخشی کوچک و در عین حال معنادار از محصول را ساخت و به کاربران نهایی یا گزیده‌هایی از آن‌ها ارائه کرد و از رفتار و برخوردشان بازخورد گرفت. با کمک آن بازخورد حدس می‌زنیم که بهترین گام بعدی برای محصول چیست و با آن دانش نسخه بعدی را می‌سازیم. …