چطور خواسته‌های خود را به برنامه نویس منتقل کنیم؟

انتشار در ۱۰ خرداد ۱۴۰۵
مدیریت پروژه وب
چطور خواسته‌های خود را به برنامه نویس منتقل کنیم؟

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

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

در این مطلب چند تکنیک عملی یاد می‌دهیم که بدون نیاز به دانستن کدنویسی، بتوانید دقیقاً بگویید چه سایتی می‌خواهید.



۱. از الگوی «چه کسی، چه کاری، کجا» استفاده کنید

به جای گفتن «یه سایت خبری می‌خواهم»، بگویید:

«مدیران فروشگاه‌های آنلاین (چه کسی) بتوانند جدیدترین تخفیف‌ها را (چه کاری) در صفحه اول سایت (کجا) ببینند و با یک کلیک گزارش فروش هفتگی خود را دریافت کنند.»

این سه ضلع مثلث، نود درصد ابهام را از بین می‌برد.



۲. حتماً از مثال واقعی استفاده کنید

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

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



۳. اولویت‌بندی کنید: «الزامی»، «مهم» و «دلخواه»

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

یک برگه بردارید و سه ستون بکشید:

· الزامی (Must have): بدون اینها سایت شما اصلاً کار نمی‌کند. مثلاً فرم تماس یا صفحه پرداخت اینترنتی.
· مهم (Nice to have): دوست دارید باشید، اما اگر نباشد دنیا به آخر نمی‌رسد. مثلاً بخش نظرات کاربران.
· دلخواه (Optional): اگر وقت و بودجه ماند. مثلاً امکان اتصال به اینستاگرام.

این برگه را به توسعه‌دهنده بدهید. او بر اساس بودجه و زمان، به شما می‌گوید چه انتظاری داشته باشید.



۴. زبان «خانه‌سازی» را یاد بگیرید (بدون کدنویسی)

نیازی نیست کد بلد باشید، ولی خوب است بدونید برنامه‌نویس‌ها چه چیزهایی را «خانه» و چه چیزهایی را «دکوراسیون» می‌دانند. اینجا را بخوانید:

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

اگر اواسط کار بگویید «بیایید به جای فروشگاه، سایت رزرو هتل بسازیم»، یعنی دارید فونداسیون خانه را عوض می‌کنید. اگر بگویید «بیایید رنگ دکمه خرید را سبز کنیم»، یک تغییر ظاهری ساده است.



۵. داستان کاربر (User Story) بنویسید، نه دستور فنی

بدترین روش ارتباط فنی: «برو یک تابع بنویس که متد GET رو به فلان API بزنه و داده رو توی state ری‌اکت بریزه و بعد با map نمایش بده».

روش درست: یک داستان کوتاه بنویسید.

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

این داستان را به برنامه‌نویس بدهید. او خودش می‌داند برای پیاده‌سازی این سناریو به چه کد و تابعی نیاز دارد.



۶. از «فلوچارتی» حرف بزنید، نه «کدنویسی»

خیلی از برنامه‌نویس‌ها از دیدن یک فلوچارت دستی خوشحال می‌شوند. نیازی نیست با نرم‌افزار خاصی رسم کنید. یک کاغذ بردارید و چند تا مربع و فلش بکشید.

مثلاً:
[صفحه اصلی] → [کلیک روی دکمه خرید] → [انتقال به سبد خرید] → [وارد کردن آدرس] → [پرداخت] → [پیام موفقیت]

باور کنید این فلوچارت ساده، بیشتر از ده جلسه صحبت فنی ارزش دارد.



۷. حتماً یک نفر را به عنوان «نماینده فنی» انتخاب کنید

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

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



۸. حواستان به «شکاف تخصصی» باشد

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

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



۹. برای «تغییر نظر دادن» هم برنامه داشته باشید

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

این شفافیت جلوی بسیاری از سوتفاهم‌ها را می‌گیرد.



۱۰. در نهایت: «سند خواسته‌ها» را تحویل بگیرید

بعد از چند جلسه صحبت، از برنامه‌نویس بخواهید یک سند ساده (حتی دو صفحه‌ای) بنویسد که در آن نوشته باشد:

· «بر اساس صحبت‌های ما، این کارها انجام می‌شود: …»
· «و این کارها انجام نمی‌شود: …»

اگر شما این سند را تأیید کنید، دیگر جای ابهامی نمی‌ماند. روز تحویل، بر اساس همین سند می‌توانید بگویید «فلان قابلیت را گفتیم نباشد، چرا هست؟» یا «فلان قابلیت را گفتیم باشد، چرا نیست؟».



جمع‌بندی

شما برای سفارش یک پیتزای خوب، نیازی نیست طرز تهیه خمیر و سس را بلد باشید. همین که بگویید «پیتزای مخلوط، خمیر نازک، سس اضافه، بدون قارچ» کافی است. طراحی سایت هم دقیقاً به همین شفافیت نیاز دارد.

این ۱۰ تکنیک را امتحان کنید. ضمانت می‌کنم که هم شما آرامش بیشتری خواهید داشت و هم برنامه‌نویس شما، دقیقاً همان چیزی را تحویل می‌دهد که در ذهن دارید.



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