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

مدیریت پروژه (Project Management) در طراحی چیست؟

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

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

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

مدیریت پروژه در طراحی چیست؟

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

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

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

مسئولیت‌ها و مهارت‌ها

منبع نُه مسئولیت برای مدیر پروژهٔ تجربهٔ کاربری برمی‌شمارد. من آن‌ها را در سه دسته گذاشته‌ام.

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

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

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

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

مثلث آهنین

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

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

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

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

چرا تخمین کار طراحی سخت است

این بخش هم افزودهٔ من است، و برمی‌گردد به داستان ابتدای مقاله.

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

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

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

روش‌ها

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

چابک. متخصص تجربهٔ کاربری را داخل تیم چابک می‌نشاند و کار را در اسپرینت‌های کوتاه با پژوهش درون‌ساخته جلو می‌برد. اسکرام و تختهٔ کانبان ساختارهای رایج آن‌اند.

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

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

پنج دام رایج

منبع پنج دامی را نام می‌برد که پروژه‌های طراحی بیشتر در آن‌ها می‌افتند. من برای هر کدام یک نشانهٔ هشدار هم اضافه کرده‌ام.

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

شکاف ارتباطی. هماهنگی ضعیف میان تیم و ذی‌نفعان. نشانهٔ هشدار: ذی‌نفعی که در جلسهٔ بازبینی نهایی برای اولین بار طرح را می‌بیند.

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

همراهی کم ذی‌نفعان. ذی‌نفعی که از ابتدا درگیر نشده، در انتها مانع می‌شود. نشانهٔ هشدار: تأییدهایی که فقط با ایمیل و بدون دیدن طرح داده می‌شوند.

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

در بافت فارسی

چند نکته برای پروژه‌های طراحی در ایران.

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

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

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

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

پنج: «فردا تمام می‌شود» تخمین نیست. خوش‌بینی در تخمین همه‌جا هست، ولی در فرهنگی که «نه» گفتن سخت است، بیشتر دیده می‌شود. تخمین را با بازه بدهید، مثلاً بین سه تا شش روز، و دلیل هر دو سر بازه را بگویید.

جمع‌بندی

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

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

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