مقالات تجربه کاربری - توسعهٔ تکرارشونده
توسعهٔ تکرارشونده
توسعهٔ تکرارشونده 
توسعهٔ تکرارشونده (Iterative Development) چیست؟
💡 این متن «بازنویسی آزاد» است: ایدهها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثالهای تازه بازگو شدهاند و ترجمهٔ کلمهبهکلمه نیست. بخشهای افزودهٔ مترجم در جعبهٔ منبع مشخص شدهاند.
سختترین بخش توسعهٔ تکرارشونده، شروعکردن نیست. تصمیمگرفتن دربارهٔ اینکه کِی تمامش کنید است.
تعریف
توسعهٔ تکرارشونده در طراحی تجربه، بر «بهبود پیوسته و اصول طراحی کاربرمحور» استوار است — و تیم «طرحها را در چرخههایی میسازد، میآزماید و پالایش میکند.»
و طراح از بازخورد کاربر یاد میگیرد و در طول فرایند بهبودهای افزایشی میدهد.
و کلمهٔ کلیدی «چرخه» است، نه «تکرار». تکرار یعنی دوباره انجامدادن؛ چرخه یعنی دوباره انجامدادن با چیزی که یاد گرفتهاید.
و بدون آن یادگیری، چیزی که دارید تکرار نیست — دور زدن است.
چرخهٔ چهارمرحلهای
یک: برنامه و پژوهش. تیم برنامهریزی میکند و نیازمندیها و زمانبندی را نقشه میکند. و پژوهش تجربه شامل نظرسنجی، گروه کانونی و مصاحبه است، برای فهم رفتار و نیاز و نقطهدرد کاربر در بافت واقعی استفادهاش.
دو: طراحی و نمونه. بعد از پژوهش، طراح معماری اطلاعات و طرح رابط را با طرحزنی، وایرفریم و نمونه میسازد.
و شرطش این است: نمونهٔ اولیه باید کموفادار باشد، قابلیتهای هسته و تعاملهای پایه را نشان دهد، و روی سه اولویت اول کاربر تمرکز کند.
سه: آزمون و بازخورد. آزمون کاربردپذیری اینجا حیاتی است. طراح از کاربر میخواهد کارهایی را انجام دهد و او را تماشا میکند — و نرخ موفقیت، نرخ خطا و زمان انجام کار را دنبال میکند.
چهار: پالایش و تکرار. تیم نمونه را بر پایهٔ بازخورد پالایش میکند، چالشهای کاربردپذیری را حل، و راهحل را به سمت محصول کمینهٔ ماندگار میبرد. و این مرحله شامل ارزیابی ذینفعان و برنامهٔ تنظیم هم هست.
و شرط مرحلهٔ دوم — کموفاداری و سه اولویت — چیزی است که بیشتر تیمها از آن رد میشوند.
و هزینهاش این است: نمونهٔ پرجزئیات، بازخورد را از «این کار نمیکند» به «این رنگ را دوست ندارم» تغییر میدهد.
ده فایده
- - تمرکز کاربرمحور — رفتار واقعی کاربر را در مرکز فرایند میگذارد.
- - بهبود پیوسته — طراحی را ادامهدار میبیند، نه یکبارمصرف.
- - انعطاف و تطبیقپذیری — تغییر را حتی در مرحلههای دیر هم جا میدهد.
- - محیط همکارانه — همراستایی تیم روی نیاز کاربر را تضمین میکند.
- - تجربهٔ بهتر — محصولی میسازد که انتظار کاربر را برآورده کند.
- - کاهش ریسک — تشخیص زودهنگام مسئله، منابع را نگه میدارد و از شکست گران جلوگیری میکند.
- - فرصت نوآوری — سرشت چرخهای، کاوش راهحلهای تازه را ممکن میکند.
- - دید بهتر ذینفعان — پیشرفت را شفاف میرساند.
- - اولویت یادگیری — بینش عمیقتری دربارهٔ رفتار و انتظار کاربر میسازد.
- - و انتشار سریع محصول کمینه — ورود به بازار با راهحل «بهاندازهٔ کافی خوب»، برای پالایش تکرارشونده.
و فایدهٔ هشتم — دید ذینفعان — همان چیزی است که این روش را در سازمان زنده نگه میدارد.
و دلیلش این است که مدیری که هر دو هفته چیزی میبیند، صبورتر از مدیری است که شش ماه چیزی نمیبیند.
پنج مشکل و راهحلشان
- - مقاومت ذینفعان → دربارهٔ فایدهها آموزش دهید و مطالعهٔ موردی نشان دهید.
- - محدودیت زمان → قابلیتهای حیاتی را در اولویت بگذارید و تکرارهای اول را متمرکز کنید.
- - ناهمگونی طراحی → سامانهٔ طراحی یا راهنمای سبک به کار ببرید.
- - سرریز بازخورد → بازخورد را نقادانه و در بافت هدف پروژه بسنجید.
- - و تکرار بیش از حد → یادتان باشد که «کامل، دشمن خوب است.»
و مشکل سوم پیامد ساختاری این روش است، نه یک اشتباه اجرایی.
و دلیلش این است که هر تکرار، تصمیمهای تازهای میگیرد — و پنج تکرار بیسامانهٔ طراحی، پنج زبان بصری میسازد.
در برابر آبشاری و چابک
در برابر مدل آبشاری: آبشاری فرایندی خطی و گامبهگام است که هر مرحله پیش از شروع مرحلهٔ بعد کامل میشود.
و توسعهٔ تکرارشونده انعطافپذیر است، سریع با تغییر تطبیق مییابد، و با بازخورد پیوسته ریسک شکست را کم میکند.
در برابر روشهای چابک: هر دو بر چرخه و تحویل افزایشی تأکید دارند.
و تفاوتشان این است: چابک چارچوب گستردهتری با رویههای مشخص (اسکرام، کانبان) است و بر همکاری و پاسخ سریع به تغییر تأکید میکند.
و توسعهٔ تکرارشونده مشخصاً بر تکرار چرخهٔ طراحی-آزمون-پالایش تمرکز دارد — و در واقع جزئی هستهای درون چارچوبهای چابک است.
و اگر بخواهم فشردهاش کنم: چابک دربارهٔ نحوهٔ سازماندهی تیم است، و توسعهٔ تکرارشونده دربارهٔ نحوهٔ رسیدن به دانش.
طول هر تکرار
و تکرارها معمولاً یک تا چهار هفته طول میکشند.
و چرخهٔ کوتاهتر (یک تا دو هفته) انعطاف میدهد، و چرخهٔ بلندتر (تا چهار هفته) کارهای پیچیده را جا میدهد.
و طولش باید میان پیشرفت پیوسته و فرصت ارزیابی منظم توازن بسازد.
دو نمونه
ویکیپدیا — محتوای تولیدشده بهدست کاربر که با تکرار جامعه و مرور سرویراستارانه پیوسته بهتر میشود، و به سمت ارزش بهینه پیش میرود.
سامانههای حقوق عرفی — رویهٔ قضایی، پالایش تکرارشونده میسازد؛ و هر تصمیم پیش از اجرا به تأیید مرجع بالاتری نیاز دارد.
و نمونهٔ دوم غافلگیرکننده است و دقیق. حقوق عرفی، نمونهٔ قدیمیترین سامانهٔ تکرارشوندهٔ ثبتشده است — و همان مسئلهای را دارد که تیمهای طراحی دارند: ناهمگونی.
شش بهترینروش
یک: جریان کار تکرارشونده بسازید. پژوهش کاربر را زود یکپارچه کنید، و پروژههای کوچکتر با دامنهٔ تعریفشده بسازید.
دو: چرخهٔ مؤثر را دنبال کنید. پژوهش ← طراحی ← آزمون ← پالایش ← تکرار.
سه: ابزار مناسب انتخاب کنید. ابزار پژوهش، وایرفریم، نمونهسازی و همکاری — و کنترل نسخه را پیاده کنید.
چهار: یکدستی را حفظ کنید. سامانهٔ طراحی را در طول تکرارها اعمال کنید.
پنج: بازخورد را متوازن کنید. ورودی کاربر را نقادانه و در بافت گستردهتر پروژه بسنجید.
شش: بدانید کِی متوقف شوید. وقتی هدفها برآورده شدند، منابع تمام شد، یا بازده نزولی پیدا شد.
و روش ششم سختترینشان است، و در بخش بعد به آن برمیگردم.
در نمونهکار
و منبع فهرست بلندی میدهد از چیزهایی که نشاندادن این روش در نمونهکار آشکار میکند.
حل مسئله و تفکر نقادانه · تحول طرح از مفهوم تا پالایش · تعهد به کاربرمحوری · مهارت پژوهش و آزمون · و همکاری میانتخصصی.
و همچنین: دقت به جزئیات · استدلال شفاف طراحی · تطبیقپذیری با نیازمندی متغیر · توان مدیریت پروژه · و اعتمادپذیری حرفهای.
مرجع تاریخی
و کتاب «توسعهٔ چابک و تکرارشونده: راهنمای مدیر» از کریگ لارمن در ۲۰۰۴ بر این حوزه اثر گذاشت.
و کارش ارائهٔ پژوهش شواهدمحوری بود که نشان میداد روشهای تکرارشونده ریسک شکست را نسبت به مدلهای سنتی کم میکنند.
و اسکرام، برنامهنویسی مفرط، ایوو و فرایند یکپارچه را پوشش میداد.
و رید هافمن، همبنیانگذار لینکدین، فلسفهٔ این رویکرد را در یک جمله گفته است: «اگر از نسخهٔ اول محصولتان خجالت نمیکشید، دیر منتشرش کردهاید.»
کِی متوقف شوید
این بخش افزودهٔ من است، چون منبع سه شرط توقف میدهد که دوتایشان بیرونیاند و بیفایده.
یعنی «منابع تمام شد» تصمیم نیست، اتفاق است. و «هدفها برآورده شدند» فقط وقتی کار میکند که هدفها از اول عددی بوده باشند.
و شرط سوم — بازده نزولی — تنها شرط واقعی است. و سه نشانهٔ عملی دارد.
یک: بازخورد تکرار میشود. وقتی تکرار سوم همان مسئلههای تکرار دوم را پیدا میکند، دیگر چیزی برای یادگرفتن نمانده.
دو: تغییرها دربارهٔ سلیقهاند، نه کارکرد. وقتی بحث از «کاربر گیج میشود» به «این بهتر به نظر میرسد» رفت، چرخهٔ یادگیری تمام شده.
سه: سنجهها تخت شدهاند. نرخ موفقیت و زمان انجام کار، دو تکرار پشت سر هم تغییر معناداری نکردهاند.
و قاعدهٔ کلیاش این است: تکرار برای یادگرفتن است، نه برای بهترکردن.
و وقتی چرخه دیگر چیزی یاد نمیدهد، ادامهدادنش پالایش است و میشود بعداً انجامش داد — یا همانطور که منبع میگوید، «کامل، دشمن خوب است.»
در بافت فارسی
یک: مقاومت ذینفعان اینجا شکل دیگری دارد. مسئله نپذیرفتن روش نیست؛ انتظار قطعیت است.
و در فرهنگ سازمانیای که «تا کِی تمام میشود؟» پرسش اول است، گفتن «بستگی دارد به چیزی که یاد بگیریم» جواب قابل قبولی نیست.
و راه عملیاش این است که تعداد تکرارها را از اول ثابت کنید، نه نتیجهشان. «سه تکرار دوهفتهای» یک تعهد است؛ «تا وقتی خوب شود» نیست.
دو: چرخهٔ یکهفتهای اینجا خیلی وقتها ممکن نیست. پیداکردن پنج کاربر برای آزمون، خودش چند روز میبرد.
و راهحلش ساختن یک حوضچهٔ کاربر ثابت است — ده نفر که بشود هر بار سراغشان رفت، حتی به قیمت کمی سوگیری.
سه: «محصول کمینهٔ ماندگار» اینجا سختتر پذیرفته میشود. کاربری که به محصولهای نیمهکاره عادت کرده، به نسخهٔ اول ناقص بدبین است.
و نتیجهٔ عملیاش این است که باید کمتر قابلیت را کاملتر منتشر کنید، نه قابلیتهای بیشتر را ناقصتر. جملهٔ هافمن اینجا نصف کار میکند.
چهار: کنترل نسخه، اینجا بیشتر لازم است. در تیمهایی با جابهجایی نیرو، تصمیمهای تکرارهای قبلی زودتر گم میشوند.
و همان دفتر تصمیمهایی که در افزایشگرایی گفتم، اینجا ارزانترین بیمه است: هر تکرار، یک خط دربارهٔ اینکه چه یاد گرفتیم.
جمعبندی
- - توسعهٔ تکرارشونده یعنی ساختن و آزمودن و پالایش طرح در چرخهها، با یادگیری از بازخورد کاربر
- - و کلمهٔ کلیدی «چرخه» است نه «تکرار» — بدون یادگیری، آنچه دارید دور زدن است
- - چرخهٔ چهارمرحلهای: برنامه و پژوهش · طراحی و نمونه · آزمون و بازخورد · پالایش و تکرار
- - و شرط مرحلهٔ دوم کموفاداری و سه اولویت است — چون نمونهٔ پرجزئیات بازخورد را از کارکرد به سلیقه میبرد
- - ده فایده — و دید ذینفعان همان چیزی است که این روش را در سازمان زنده نگه میدارد
- - پنج مشکل: مقاومت ذینفعان · محدودیت زمان · ناهمگونی طراحی · سرریز بازخورد · تکرار بیش از حد
- - و ناهمگونی، پیامد ساختاری این روش است: پنج تکرار بیسامانهٔ طراحی، پنج زبان بصری میسازد
- - در برابر آبشاری: انعطاف در برابر خطیبودن · در برابر چابک: جزئی هستهای درون آن است
- - چابک دربارهٔ نحوهٔ سازماندهی تیم است، و توسعهٔ تکرارشونده دربارهٔ نحوهٔ رسیدن به دانش
- - طول هر تکرار یک تا چهار هفته — کوتاهتر انعطاف میدهد و بلندتر کار پیچیده را جا
- - نمونهها: ویکیپدیا · و سامانههای حقوق عرفی، قدیمیترین سامانهٔ تکرارشوندهٔ ثبتشده
- - لارمن ۲۰۰۴ · و هافمن: «اگر از نسخهٔ اول محصولتان خجالت نمیکشید، دیر منتشرش کردهاید»
- - کِی متوقف شوید: بازخورد تکرار شد · بحث به سلیقه رفت · سنجهها تخت شدند — چون تکرار برای یادگرفتن است، نه بهترکردن
- - و در فارسی: تعداد تکرارها را ثابت کنید نه نتیجه · حوضچهٔ کاربر ثابت بسازید · کمتر قابلیت را کاملتر منتشر کنید · و هر تکرار یک خط بنویسید
منبع
این نوشته «بازنویسی آزاد» است از مطلب What is Iterative Development? در وبسایت بنیاد طراحی تعامل (Interaction Design Foundation — IxDF؛ بدون نام نویسندهٔ مشخص). مفاهیم پایه — تعریف توسعهٔ تکرارشونده در طراحی تجربه و نقلقولهایش دربارهٔ بهبود پیوسته و اصول طراحی کاربرمحور و ساختن و آزمودن و پالایش طرح در چرخهها، و یادگیری از بازخورد کاربر و بهبودهای افزایشی؛ هر چهار مرحلهٔ چرخه یعنی برنامه و پژوهش با نظرسنجی و گروه کانونی و مصاحبه و فهم بافت واقعی استفاده، طراحی و نمونه با معماری اطلاعات و طرحزنی و وایرفریم و شرط کموفاداری و تمرکز بر سه اولویت اول، آزمون و بازخورد با تماشای کاربر و پیگیری نرخ موفقیت و نرخ خطا و زمان انجام کار، و پالایش و تکرار با حرکت به سمت محصول کمینهٔ ماندگار و ارزیابی ذینفعان؛ هر ده فایده؛ هر پنج مشکل با راهحلشان و نقلقول «کامل، دشمن خوب است»؛ مقایسه با مدل آبشاری و خطیبودنش و مقایسه با چابک و تفاوت چارچوب گسترده و رویههای اسکرام و کانبان و جزء هستهای بودن توسعهٔ تکرارشونده درون چابک؛ طول یک تا چهار هفتهٔ تکرارها و مزیت چرخهٔ کوتاهتر و بلندتر؛ دو نمونهٔ ویکیپدیا و سامانههای حقوق عرفی؛ هر شش بهترینروش؛ فهرست کامل چیزهایی که نشاندادن این روش در نمونهکار آشکار میکند؛ کتاب «توسعهٔ چابک و تکرارشونده: راهنمای مدیر» کریگ لارمن در ۲۰۰۴ و پژوهش شواهدمحورش و پوشش اسکرام و برنامهنویسی مفرط و ایوو و فرایند یکپارچه؛ و نقلقول رید هافمن همبنیانگذار لینکدین — از این منبع گرفته شده. متن فارسی، ساختار بخشها و همهٔ تحلیلها کاملاً مستقل نوشته شدهاند.
متن مطلب اصلی تحت هیچ لایسنس بازی منتشر نشده است؛ به همین دلیل اینجا ترجمهٔ کلمهبهکلمه ارائه نشده و متن کامل انگلیسی (بههمراه همهٔ منابع مرتبط) در لینک زیر در دسترس است.
بخشهای افزودهٔ مترجم: صورتبندی آغازین دربارهٔ سختبودن تصمیم توقف؛ تفکیک «چرخه» از «تکرار» و گزارهٔ اینکه بدون یادگیری آنچه دارید دور زدن است؛ تحلیل شرط کموفاداری مرحلهٔ دوم و هزینهٔ رد شدن از آن یعنی تغییر بازخورد از کارکرد به سلیقه؛ برجستهکردن فایدهٔ دید ذینفعان بهعنوان عامل بقای روش در سازمان و دلیلش دربارهٔ صبر مدیر؛ تشخیص ناهمگونی طراحی بهعنوان پیامد ساختاری روش نه اشتباه اجرایی و گزارهٔ پنج تکرار و پنج زبان بصری؛ فشردهسازی تفاوت چابک و توسعهٔ تکرارشونده به «سازماندهی تیم» در برابر «رسیدن به دانش»؛ تحلیل نمونهٔ حقوق عرفی بهعنوان قدیمیترین سامانهٔ تکرارشوندهٔ ثبتشده و اشتراک مسئلهٔ ناهمگونیاش با تیمهای طراحی؛ کل بخش «کِی متوقف شوید» شامل نقد دو شرط بیرونی منبع، تشخیص بازده نزولی بهعنوان تنها شرط واقعی، سه نشانهٔ عملیاش یعنی تکرار بازخورد و رفتن بحث به سلیقه و تختشدن سنجهها، و قاعدهٔ «تکرار برای یادگرفتن است، نه برای بهترکردن»؛ و کل بخش بافت فارسی شامل شکل متفاوت مقاومت ذینفعان یعنی انتظار قطعیت و راهحل ثابتکردن تعداد تکرارها بهجای نتیجه، ناممکنبودن چرخهٔ یکهفتهای و راهحل حوضچهٔ کاربر ثابت با پذیرش کمی سوگیری، سختتر پذیرفتهشدن محصول کمینه و توصیهٔ انتشار قابلیت کمتر با کاملتری بیشتر، و لزوم بیشتر کنترل نسخه در تیمهای پرجابهجایی و پیشنهاد یک خط یادگیری برای هر تکرار
تصاویر: هیچ تصویری از مطلب اصلی بازتولید نشده است. هر سه نمودار این صفحه طراحی مستقل مترجم است.
مشاهدهٔ مطلب اصلی
مترجم: سپنتا پویا
طراح ارشد محصول. مقالات تخصصی UI/UX را با حفظ ساختار و لحن نسخهٔ اصلی به فارسی برمیگردانم.
دربارهٔ من