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

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

بریف چیست و چه چیزی نیست

بریف سند فنی نیست. لازم نیست بدانی دیتابیس چیست یا کدام فریم‌ورک بهتر است. نباید هم بنویسی «با فلان تکنولوژی»، مگر دلیل مشخصی داشته باشی؛ انتخاب فنی کار برنامه‌نویس است و اگر از قبل ببندیش، بهترین راه را از خودت دریغ کرده‌ای.

بریف یعنی جواب به سه سؤال ساده: چه مشکلی داری، چه کسی با راه‌حل کار می‌کند، و موفقیت چه شکلی است. بقیهٔ بخش‌ها این سه سؤال را دقیق‌تر می‌کنند.

هفت بخشی که یک بریف خوب دارد

۱. مشکل، نه راه‌حل

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

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

۲. چه کسانی با آن کار می‌کنند

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

۳. معیار موفقیت

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

۴. چه چیزی داخل است و چه چیزی بیرون

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

۵. چه چیزهایی از قبل وجود دارد

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

۶. محدودیت‌ها

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

۷. نمونه‌ها

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

یک مثال ضعیف و یک مثال قوی

این یک مثال فرضی است، فقط برای دیدن تفاوت.

ضعیف: «یک سیستم رزرو آنلاین برای آرایشگاه‌هایم می‌خواهم.»

قوی:

مشکل: سه شعبه داریم و رزرو با تلفن و اینستاگرام انجام می‌شود. گاهی یک وقت دو بار رزرو می‌شود.
کاربرها: مشتری (وقت می‌گیرد و لغو می‌کند)، مسئول هر شعبه (برنامهٔ روز را می‌بیند)، من به‌عنوان مالک (گزارش کل شعبه‌ها).
موفقیت: سه ماه بعد از راه‌اندازی، بیشتر رزروها از صفحهٔ آنلاین بیاید و رزرو تکراری دیگر پیش نیاید.
نسخهٔ اول: انتخاب شعبه و خدمت، دیدن ساعت‌های خالی، رزرو با پیامک تأیید. بعداً: پرداخت آنلاین، باشگاه مشتریان.
موجود است: لیست مشتری‌ها در یک فایل اکسل و پنل پیامک فعلی‌مان.
محدودیت: بودجه هنوز مشخص نیست و تخمین می‌خواهم؛ ترجیحاً قبل از شروع پاییز آماده باشد.

نمونهٔ دوم یک صفحه هم نمی‌شود، ولی برنامه‌نویس می‌تواند همین‌جا بگوید چه سؤال‌هایی مانده، تخمین بدهد و حتی بگوید فلان بخش را ساده‌تر کنید.

اشتباه‌های رایج

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

اگر نمی‌توانی همه‌اش را بنویسی

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

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

بریف پروژهٔ نرم‌افزاری چطور بنویسیم؟ قالبی که برنامه‌نویس واقعاً بتواند رویش کار کند