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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

فرمت پیشنهادی برای فهرست الزامات

پیش از پرداختن به جزئیاتِ بیشتر فهرست الزامات، بهتر است نمونه‌ای از آن را ببینید و مبنا قرار دهید. فهرست زیر با کمی تغییرات، از کتاب پال و بیتز ترجمه شده است.

دانلود نسخه‌ی کامل فهرست الزامات برای پرینت (PDF)

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

ستون بعدی، همان دوگانه‌ی Demand و Wish است. اگر رعایت یک الزام در هر شرایطی اجباری است، باید روبه‌روی آن در ستون نیاز (Demand) علامت زده شود. در مورد سایر الزامات (موارد غیراجباری)، پیشنهاد شده است که بر اساس میزان اهمیت طبقه‌بندی شوند. در جدول بالا، این الزامات از نظر میزان اهمیت به سه دسته‌ی زیاد و متوسط و کم تقسیم شده‌اند. اگر یک الزام (مثلاً دیجیتال بودن یک وسیله) اجباری نیست، آن وقت باید از نظر میزان اهمیت در ستون مربوطه علامت زده شود، مثلاً دیجیتال بودن را می‌توانیم یک الزام غیراجباری خیلی مهم تعیین کنیم.

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

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

طبقه‌بندی الزامات

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

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

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

الزامات چگونه شناسایی می‌شوند؟

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

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

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

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

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

فهرست جزئی (Partial Requirement list)

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

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

در ادامه، نمونه‌ای از فهرست الزامات که در کتاب اصلی ارائه شده است را به فارسی ترجمه کردیم:

نمونه‌ی انگلیسی فهرست الزامات