بیشتر پروژه‌های دیجیتالی که به بن‌بست می‌رسند، در روز تحویل خراب نمی‌شوند؛ از همان جلسه‌ی اول خراب شروع می‌شوند. جلسه‌ای که در آن مدیر کسب‌وکار با شوق از «یک سایت حرفه‌ای»، «یک اپلیکیشن ساده» یا «یک سیستم که همه‌چیز را یکجا ببینیم» حرف می‌زند، تیم فنی سر تکان می‌دهد و هر دو طرف با این خیال از اتاق بیرون می‌روند که منظور یکدیگر را فهمیده‌اند. چند هفته بعد معلوم می‌شود که هر کدام پروژه‌ی دیگری را در ذهن داشته است.
موضع ما در گرین‌لبز روشن است: اگر نتوانید پیش از شروع همکاری، پروژه را روی دو سه صفحه کاغذ توضیح دهید، هنوز آماده‌ی خرید آن نیستید. این حرف تحقیر کارفرما نیست؛ دفاع از پول و زمان اوست. بریف پروژه همان دو سه صفحه است. سندی کوتاه که می‌گوید چرا این پروژه را می‌خواهید، برای چه کسی، تا کجا و با چه محدودیت‌هایی، و از کجا می‌فهمید که موفق شده است.
در این نوشته توضیح می‌دهیم بریف خوب چه اجزایی دارد، بریف ضعیف دقیقا چگونه هزینه می‌سازد، و در پایان یک قالب عملی می‌گذاریم که می‌توانید همین امروز پر کنید.
بریف پروژه چیست و چه چیزی نیست
بریف پروژه سندی است که مسئله‌ی کسب‌وکار را پیش از راه‌حل فنی روی میز می‌گذارد. مخاطب اصلی آن تیم یا آژانسی است که قرار است پروژه را برآورد و اجرا کند، اما در عمل نخستین سود آن به خود شما می‌رسد؛ چون مجبورتان می‌کند فکرهای پراکنده را به جمله‌های مشخص تبدیل کنید.
بریف چند چیز نیست و خوب است از همین ابتدا تکلیف را روشن کنیم:
- قرارداد نیست. قرارداد بعدا و بر پایه‌ی بریف و پیشنهاد تیم نوشته می‌شود.
- فهرست امکانات نیست. فهرستی از دکمه‌ها و صفحه‌ها بدون هدف، فقط خرید را شلوغ‌تر می‌کند.
- سند نیازمندی‌های نرم‌افزار نیست. سند نیازمندی‌ها (SRS)، سناریوهای کاربری، جزئیات رفتار سیستم و معیارهای پذیرش هر بخش را با دقت فنی ثبت می‌کند و معمولا پس از توافق اولیه و در مرحله‌ی کشف و تحلیل، با همکاری تیم فنی نوشته می‌شود. بریف پیش از آن می‌آید و به پرسش «چرا و چه» پاسخ می‌دهد، نه «دقیقا چگونه».
به بیان ساده، بریف نقشه‌ی مقصد است و SRS نقشه‌ی مسیر. بدون مقصد روشن، دقیق‌ترین نقشه‌ی مسیر هم شما را به جای اشتباه می‌برد.
اجزای یک بریف پروژه که واقعا به کار می‌آید
هر بخش زیر را با یک پرسش ساده سنجیده‌ایم: اگر این بخش خالی بماند، کدام تصمیم در ادامه کور گرفته می‌شود؟
هدف کسب‌وکار: چرا این پروژه، چرا حالا
نخستین سطر بریف نباید «طراحی سایت» یا «ساخت اپلیکیشن» باشد. باید نتیجه‌ای باشد که کسب‌وکار به دنبالش است: کاهش زمان پاسخ‌گویی به مشتری، جمع کردن سفارش‌هایی که امروز در پیام‌رسان‌ها گم می‌شوند، معرفی خدمت تازه به بازاری مشخص، یا جایگزینی فرایندی که دیگر مقیاس‌پذیر نیست.
هدف کسب‌وکار به تیم اجرا اجازه می‌دهد پیشنهاد بدهد، نه فقط سفارش بگیرد. وقتی بدانند چرا چیزی را می‌خواهید، گاهی راه کوتاه‌تر و ارزان‌تری پیدا می‌کنند. و گاهی صادقانه می‌گویند که این پروژه اصلا مسئله‌ی شما را حل نمی‌کند.
بیان مسئله: درد امروز را بدون راه‌حل بنویسید
بیان مسئله یعنی توصیف وضع موجود، بی‌آنکه از ابتدا راه‌حل را در آن جا داده باشید. «ما یک CRM می‌خواهیم» بیان مسئله نیست؛ «پیگیری مشتری‌های بالقوه میان چند نفر پخش است و هیچ‌کس نمی‌داند کدام تماس پاسخ نگرفته» بیان مسئله است.
این تفاوت ظریف به نظر می‌رسد، اما سرنوشت پروژه را عوض می‌کند. وقتی راه‌حل را از پیش دیکته می‌کنید، تیم فنی همان را می‌سازد؛ حتی اگر ابزار مناسب چیز دیگری باشد. راهنمای خدمات دولت بریتانیا درباره‌ی مرحله‌ی کشف دقیقا بر همین اصل تکیه دارد: پیش از ساختن، مسئله و کاربران را بفهمید و حتی آماده باشید که نتیجه بگیرید ساختن لازم نیست.
مخاطب و کاربران: چه کسی با این محصول سروکار دارد
هر پروژه‌ی دیجیتال دست‌کم دو گروه کاربر دارد: کسانی که از بیرون با آن کار می‌کنند، مثل مشتری یا بازدیدکننده، و کسانی که از درون آن را می‌گردانند، مثل کارشناس فروش، اپراتور پشتیبانی یا مدیر محتوا. بریف‌های ضعیف معمولا فقط گروه اول را می‌بینند و روز تحویل معلوم می‌شود که پنل مدیریت برای تیم داخلی قابل استفاده نیست.
در این بخش بنویسید کاربران اصلی چه کسانی‌اند، چه کاری می‌خواهند انجام دهند، از چه دستگاهی استفاده می‌کنند و امروز همان کار را چگونه انجام می‌دهند. لازم نیست پژوهش کاربری مفصلی پیوست کنید؛ همین که تصویر روشنی از آدم‌های واقعی پشت پروژه بدهید، کافی است.
دامنه و خارج از دامنه: مرزها را با صدای بلند بگویید
دامنه‌ی پروژه یعنی آنچه در این همکاری ساخته و تحویل داده می‌شود. اما بخشی که تقریبا همیشه فراموش می‌شود، و به نظر ما مهم‌تر است، فهرست خارج از دامنه است: چیزهایی که آگاهانه در این مرحله کنار گذاشته‌اید.
نوشتن «اپلیکیشن موبایل در این مرحله نیست» یا «انتقال محتوای قدیمی بر عهده‌ی تیم داخلی است» شاید بدیهی به نظر برسد، اما همین جمله‌ها بعدا جلوی بحث‌های فرسایشی را می‌گیرند. آتلسین در راهنمای خود درباره‌ی تعریف دامنه‌ی پروژه هم بر ثبت صریح مرزها و آنچه خارج از کار است تاکید می‌کند. مرزی که نوشته نشده، مرزی است که هر کس به میل خود جابه‌جا می‌کند.
اولویت‌ها: الزامی، مطلوب، بعدا
همه‌ی خواسته‌ها هم‌وزن نیستند، اما در بیشتر بریف‌ها همه با یک لحن نوشته می‌شوند. نتیجه این است که تیم اجرا نمی‌داند اگر زمان یا بودجه تنگ شد، کدام را فدا کند.
پیشنهاد ما یک دسته‌بندی سه‌سطحی ساده است:
- الزامی: بدون آن، پروژه هدف کسب‌وکار را برآورده نمی‌کند و ارزش راه‌اندازی ندارد.
- مطلوب: ارزش واقعی می‌افزاید، اما نبودش در نسخه‌ی اول فاجعه نیست.
- بعدا: ایده‌ی خوبی است که آگاهانه به مرحله‌های بعد سپرده می‌شود.
این دسته‌بندی پیوند مستقیمی با تصمیم میان نسخه‌ی کمینه و محصول کامل دارد؛ موضوعی که در نوشته‌ی MVP بسازیم یا محصول کامل مفصل به آن پرداخته‌ایم. و یک هشدار: ستون «بعدا» اگر صاحب و زمان‌بندی نداشته باشد، به گورستان ایده‌ها تبدیل می‌شود. چرا این اتفاق می‌افتد را در فاز یک تمام شد، پروژه هم تمام شد؟ توضیح داده‌ایم.
محدودیت‌ها: بودجه، زمان، سیستم‌های موجود و یکپارچگی‌ها
بسیاری از کارفرمایان از گفتن بازه‌ی بودجه طفره می‌روند، به این گمان که اگر عدد را بگویند، پیشنهاد قیمت دقیقا به همان سقف می‌رسد. ما این نگرانی را می‌فهمیم، اما نتیجه‌ی پنهان کردن بودجه معمولا بدتر است: یک تیم راه‌حلی سنگین پیشنهاد می‌دهد که هرگز در توانتان نبوده و تیم دیگر نسخه‌ای سبک که مسئله را حل نمی‌کند. بازه‌ی بودجه برای تیم اجرا اطلاعات طراحی است، نه فرصت چانه‌زنی.
در این بخش این موارد را بنویسید:
- بازه‌ی بودجه: یک حداقل و حداکثر واقع‌بینانه، نه یک عدد قطعی.
- زمان‌بندی: آیا تاریخی ثابت وجود دارد که به رویدادی بیرونی گره خورده است، یا زمان انعطاف‌پذیر است؟
- سیستم‌های موجود: سایت فعلی، نرم‌افزار حسابداری، CRM، انبار، درگاه پرداخت یا هر ابزاری که پروژه باید کنارش زندگی کند.
- یکپارچگی‌ها: کدام سیستم‌ها باید با محصول تازه داده رد و بدل کنند، و آیا دسترسی فنی به آنها، مثلا API، وجود دارد؟
- محدودیت‌های دیگر: الزامات حقوقی، میزبانی داخل کشور، زبان‌ها، یا سیاست‌های امنیتی سازمان.
یکپارچگی‌ها همان جایی‌اند که برآوردها بیشتر از همه غافلگیر می‌شوند. سیستمی که «فقط باید به حسابداری وصل شود» گاهی پیچیده‌ترین بخش کل پروژه است.
تصمیم‌گیرنده و فرایند تایید
یکی از گران‌ترین خطاهای پروژه‌های دیجیتال این است که تیم اجرا هفته‌ها با یک نفر کار کند و در روز ارائه، مدیری وارد جلسه شود که تا آن روز چیزی ندیده و همه‌چیز را زیر سوال ببرد.
در بریف بنویسید چه کسی تصمیم نهایی را می‌گیرد، چه کسانی نظر مشورتی دارند، تایید هر مرحله در چه بازه‌ای انجام می‌شود و اگر میان نظرها اختلاف پیش آمد، حرف آخر با کیست. این بخش ادامه‌ی طبیعی بحثی است که در نوشته‌ی پروژه‌ی دیجیتال از امضای قرارداد شروع نمی‌شود مطرح کرده‌ایم: روشن بودن نقش‌ها از روز اول، پیش‌شرط شروع واقعی کار است.
محتوا، دارایی‌ها و مالکیت
چه کسی متن‌ها را می‌نویسد؟ عکس‌ها و ویدئوها از کجا می‌آیند؟ لوگو و راهنمای برند وجود دارد یا باید ساخته شود؟ دامنه، هاست، حساب‌های سرویس‌های بیرونی و کد نهایی به نام چه کسی ثبت می‌شود؟
این پرسش‌ها در جلسه‌ی اول جزئی به نظر می‌رسند و در ماه سوم به گلوگاه تبدیل می‌شوند. کافی است محتوا به‌موقع آماده نباشد تا محصولی که از نظر فنی کامل است، روی زمین بماند و منتشر نشود. بخش مالکیت هم موضوعی حقوقی و حیاتی است که در نوشته‌ی دامنه و هاست به نام شما نیست؟ جداگانه به آن پرداخته‌ایم.
معیار موفقیت و شاخص‌ها
اگر نتوانید بگویید شش ماه پس از راه‌اندازی از کجا می‌فهمید پروژه موفق بوده، دارید پروژه را بر اساس سلیقه داوری می‌کنید، نه نتیجه. معیار موفقیت باید به هدف کسب‌وکار برگردد: تعداد درخواست‌هایی که از مسیر تازه ثبت می‌شود، کاهش کار دستی تیم، زمان لازم برای انجام یک فرایند، یا سهم سفارش‌های آنلاین.
لازم نیست برای همه‌چیز عدد قطعی داشته باشید. گاهی کافی است بنویسید امروز این شاخص را اصلا اندازه نمی‌گیرید و یکی از خروجی‌های پروژه باید امکان اندازه‌گیری آن باشد. همین جمله به تیم اجرا می‌گوید گزارش‌گیری و ثبت رویدادها بخشی از کار است، نه یک افزودنی بعدی.
ریسک‌ها و پرسش‌های باز
بریف صادق، جای ندانسته‌ها را هم باز می‌گذارد. آیا هنوز معلوم نیست سیستم فعلی امکان اتصال دارد؟ آیا تصمیم درباره‌ی بازار هدف قطعی نشده است؟ آیا وابستگی به تامین‌کننده‌ای بیرونی وجود دارد؟
نوشتن ریسک‌ها نشانه‌ی ضعف نیست؛ نشانه‌ی بلوغ است. تیمی که پرسش‌های باز را از ابتدا می‌بیند، می‌تواند برای پاسخ دادن به آنها گام‌های کوتاه و ارزان طراحی کند، به جای آنکه در میانه‌ی پروژه با آنها روبه‌رو شود.
بریف ضعیف دقیقا چگونه هزینه می‌سازد
بریف ضعیف هزینه‌اش را یکجا نمی‌گیرد؛ قسطی و در جاهایی می‌گیرد که کسی آن را به سند اول ربط نمی‌دهد.
برآوردهای غیرقابل مقایسه
وقتی بریفی مبهم را برای چند تیم می‌فرستید، هر کدام ابهام را به شیوه‌ی خود پر می‌کند. یکی کمینه را فرض می‌کند و قیمت پایین می‌دهد، دیگری محتاط است و برای ناشناخته‌ها حاشیه می‌گذارد. شما خیال می‌کنید قیمت‌ها را مقایسه می‌کنید، اما در واقع دارید چند پروژه‌ی متفاوت را با هم می‌سنجید. پیشنهاد ارزان‌تر اغلب فقط پروژه‌ی کوچک‌تری را قیمت داده است. چرا قیمت یک پروژه‌ی دیجیتال در اصل تصمیمی درباره‌ی دامنه است را در نوشته‌ی قیمت‌گذاری پروژه‌ی دیجیتال فقط عدد فروش نیست باز کرده‌ایم.
خزش دامنه
خزش دامنه، یا همان بزرگ شدن تدریجی و کنترل‌نشده‌ی پروژه، تقریبا همیشه از جایی شروع می‌شود که مرز اولیه نوشته نشده بود. هر درخواست تازه به‌تنهایی کوچک و منطقی به نظر می‌رسد: «فقط یک فیلد دیگر»، «فقط یک گزارش ساده». اما وقتی خط مبنایی وجود ندارد، هیچ‌کس نمی‌تواند بگوید این درخواست جزو کار بود یا نه. آتلسین در توضیح خزش دامنه هم نبود تعریف روشن دامنه را از ریشه‌های اصلی آن می‌داند.
نتیجه یکی از این دو است: یا تیم اجرا بی‌صدا کار اضافه انجام می‌دهد و کیفیت بقیه‌ی بخش‌ها افت می‌کند، یا هر درخواست به مذاکره‌ای تلخ بر سر هزینه‌ی اضافه بدل می‌شود. در هر دو حالت رابطه فرسوده می‌شود.
دوباره‌کاری
دوباره‌کاری گران‌ترین شکل هزینه است، چون هم پول را می‌سوزاند و هم زمانی را که دیگر برنمی‌گردد. وقتی کاربران داخلی در بریف دیده نشده‌اند، پنل مدیریت دوباره طراحی می‌شود. وقتی یکپارچگی با سیستم موجود ذکر نشده، معماری در میانه‌ی راه عوض می‌شود. وقتی تصمیم‌گیرنده مشخص نبوده، طرحی که هفته‌ها رویش کار شده با یک جلسه کنار می‌رود.
فاصله‌ی میان تصور و تحویل
و سرانجام، بریف ضعیف همان شکافی را می‌سازد که میان نمونه‌ی نمایشی و محصول واقعی دیده می‌شود. کارفرما در ذهن خود محصولی کامل دیده و تیم اجرا آنچه را ساخته که روی کاغذ آمده بود. هیچ‌کدام دروغ نگفته‌اند؛ فقط هیچ‌کس آن تصور را پیش از شروع کار روی کاغذ نیاورده بود.
چند اشتباه رایج در نوشتن بریف
حتی کارفرمایانی که بریف می‌نویسند، اغلب در یکی از این دام‌ها می‌افتند:
- نوشتن بریف به زبان راه‌حل. بریفی که سراسر از صفحه‌ها و امکانات حرف می‌زند و یک سطر درباره‌ی مسئله ندارد، تیم را به مجری تبدیل می‌کند، نه شریک.
- کپی کردن رقیب. «چیزی شبیه فلان سایت» نقطه‌ی شروع بدی نیست، اما بریف نیست. محصول رقیب برای مسئله‌ی او ساخته شده، نه شما.
- بریف طولانی و بی‌اولویت. سی صفحه سند که همه‌چیزش الزامی است، از یک صفحه‌ی خالی کمکی بیشتر نمی‌کند.
- نوشتن بریف به‌تنهایی. بریفی که فقط مدیرعامل یا فقط واحد فناوری نوشته باشد، معمولا نیمی از واقعیت را جا می‌اندازد. دست‌کم نماینده‌ی کاربران داخلی را در نوشتنش شریک کنید.
- بستن بریف و فراموش کردنش. بریف سند زنده‌ی مرحله‌ی پیش از قرارداد است. پس از گفت‌وگو با تیم اجرا، به‌روزش کنید تا نسخه‌ی نهایی مبنای پیشنهاد و قرارداد شود.
قالب عملی بریف پروژه: چک‌لیستی که امروز می‌توانید پر کنید
قالب زیر را می‌توانید در یک سند ساده کپی کنید. هدف این نیست که هر بخش را مفصل بنویسید؛ هدف این است که هیچ بخشی خالی نماند. اگر پاسخ پرسشی را نمی‌دانید، همین را صریح بنویسید و آن را به بخش پرسش‌های باز منتقل کنید.
۱. زمینه و هدف
- کسب‌وکار ما چه می‌کند و این پروژه در کجای آن قرار می‌گیرد؟
- این پروژه قرار است کدام نتیجه‌ی کسب‌وکار را ممکن کند؟
- چرا همین حالا؟ اگر انجامش ندهیم، چه چیزی از دست می‌رود؟
۲. مسئله و کاربران
- وضع موجود چیست و دقیقا کجایش درد دارد؟
- کاربران بیرونی و درونی چه کسانی‌اند و امروز این کار را چگونه انجام می‌دهند؟
۳. دامنه و اولویت
- آنچه در این مرحله باید تحویل شود، در قالب الزامی، مطلوب و بعدا.
- آنچه آگاهانه خارج از دامنه است.
۴. محدودیت‌ها
- بازه‌ی بودجه، از حداقل تا حداکثر.
- زمان‌بندی و هر تاریخ ثابت بیرونی.
- سیستم‌های موجود و یکپارچگی‌های لازم.
- الزامات حقوقی، امنیتی، میزبانی یا زبانی.
۵. نقش‌ها و تایید
- تصمیم‌گیرنده‌ی نهایی و افراد مشورتی.
- فرایند و بازه‌ی زمانی تایید هر مرحله.
- مسئول تامین محتوا و دارایی‌ها در سمت کارفرما.
۶. مالکیت
- مالکیت کد، طراحی، دامنه، هاست و حساب‌های سرویس‌های بیرونی.
- محتوا و دارایی‌های موجود و آنچه باید تولید شود.
۷. موفقیت
- شاخص‌هایی که با آنها موفقیت را می‌سنجیم.
- وضع فعلی این شاخص‌ها، یا اینکه امروز اندازه‌گیری نمی‌شوند.
۸. ریسک‌ها و پرسش‌های باز
- آنچه هنوز نمی‌دانیم.
- وابستگی‌هایی که خارج از کنترل ماست.
اگر این هشت بخش را پر کرده باشید، در گفت‌وگو با هر تیم اجرایی دست بالا را دارید: پیشنهادها قابل مقایسه می‌شوند، پرسش‌های تیم دقیق‌تر می‌شوند و خیلی زود می‌فهمید کدام تیم مسئله‌ی شما را فهمیده و کدام فقط دنبال بستن قرارداد است.
پس از بریف چه می‌آید
بریف پایان کار نیست؛ آغاز گفت‌وگوی جدی است. تیم اجرای خوب بریف شما را می‌خواند، پرسش می‌پرسد، فرض‌ها را به چالش می‌کشد و گاهی پیشنهاد می‌دهد دامنه کوچک‌تر یا مرحله‌بندی‌شده شود. پس از رسیدن به توافق اولیه، نوبت مرحله‌ی کشف و تحلیل دقیق‌تر است؛ جایی که نیازمندی‌ها با جزئیات فنی، سناریوهای کاربری و معیارهای پذیرش در قالب سند نیازمندی‌ها ثبت می‌شوند. آن سند موضوع جداگانه‌ای است و بدون بریفی محکم، بر زمین سستی بنا می‌شود.
یک محک ساده هم برای سنجش تیم‌ها دارید: تیمی که بریف شما را بی‌هیچ پرسشی می‌پذیرد و بی‌درنگ عدد می‌دهد، یا بریف را نخوانده یا مسئله را جدی نگرفته است.
سخن پایانی
بریف پروژه سندی کوتاه است، اما کوتاه بودنش نباید فریبتان دهد. نوشتن آن یعنی تصمیم‌های سختی را که دیر یا زود باید گرفته شوند، پیش از خرج شدن پول بگیرید: چه می‌خواهیم، چه نمی‌خواهیم، چه چیزی اول است و موفقیت چه شکلی دارد. هر ساعتی که امروز صرف این سند می‌کنید، از هفته‌هایی که بعدا صرف بحث بر سر دامنه، اصلاح برآورد و دوباره‌کاری می‌شود، ارزان‌تر است.
اگر در آستانه‌ی شروع پروژه‌ای دیجیتال هستید و می‌خواهید پیش از هر برآوردی، مسئله و دامنه را با هم روشن کنیم، خدمات گرین‌لبز را ببینید و گفت‌وگو را از همین بریف آغاز کنیم.
