شفاف‌سازی کار و تهیه‌ی فهرست الزامات

فهرست الزامات چیست؟

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

برنامه‌ریزی محصول و فهرست الزامات

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

نقطه‌ی شروع مرحله‌ی شفاف‌سازی

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

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

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

محتویات فهرست الزامات چیست؟

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

همچنین گاهی در فهرست، راهکارهایی برای الزامات پیشنهاد می‌کنند. این کار  اشتباه نیست و اتفاقاً به توضیح بهتر مسأله‌ی طراحی کمک می‌کند، اما همانطور که در درس برنامه‌ریزی محصول گفتیم، راهکارها نباید مطلق و دقیق باشند (Solution-Specific) بلکه باید در حد یک کلیّت نه چندان دقیق (Solution-Neutral) بیان شوند تا برای طراحان، دیوارهای زائدِ ذهنی به وجود نیاید. (البته به صورت کلّی درج راهکارها در فهرست الزامات ضروری نیست)

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

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

ملاحظات مهم برای تنظیم فهرست الزامات

الزامات باید کاملاً شفاف، دقیق و به زبان مهندسی باشند و تا حدّ امکان با متغیرهای کمّی توصیف شوند. مثلاً برای قطب‌نمای کوهنوردی، به جای نوشتن (مقاومت در دمای زیر صفر) باید نوشته شود (کارکرد مناسب از دمای منفی ۲۵ درجه سلسیوس تا ۶۵ درجه‌ی سانتیگراد) یا به جای (وزن کم) باید نوشته شود (وزن محصول کمتر از صد گرم باشد).

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

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

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

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

مطالب این درس به پایان نرسیده است و ادامه‌ی آن (شامل مباحثی مثل محتویات فهرست الزامات و شناسایی الزامات) فقط به مشترکین ویژه نمایش داده می‌شود.