وقتی فقط میدانید «به یک سایت بهتر»، «محتوای بیشتر» یا «یک نیروی متخصص» نیاز دارید، هنوز برای شروع همکاری آماده نیستید؛ اما لازم نیست از همان ابتدا همه جزئیات فنی را بدانید. نقطه شروع، تبدیل مسئله کسبوکار به نتیجهای روشن و سپس نوشتن محدوده و معیار بررسی آن نتیجه است.
در این راهنما، مسیر تبدیل یک نیاز مبهم به Brief پروژه را مرحلهبهمرحله میبینید. در پایان نیز یک قالب قابل تکمیل و چکلیست بازبینی دارید. اگر میخواهید ابتدا مسیر کلی همکاری با متخصص بیرونی را بشناسید، راهنمای برونسپاری پروژه را هم ببینید.
وقتی نیاز کسبوکار هنوز به شرح پروژه تبدیل نشده است
توضیح شفاهی یا چند جمله کلی معمولاً چند پرسش مهم را بیپاسخ میگذارد: مسئله دقیق چیست؟ چه چیزی باید تحویل شود؟ چه مواردی خارج از پروژه است؟ و از کجا بفهمیم کار انجامشده قابل قبول است؟ وقتی پاسخ این پرسشها روشن نباشد، هر متخصص ممکن است برداشت متفاوتی از درخواست شما داشته باشد.
شرح پروژه فقط فهرست فعالیتها نیست. این سند، برداشت مشترک شما و متخصص از مسئله، نتیجه مورد انتظار، محدوده و روش بررسی خروجی را شکل میدهد. در برخی الگوهای رایج بازار، تعریف پروژه اختصاصی با توضیحات و توافق درباره زمان و مبلغ همراه است و شرح پروژه میتواند در بررسی اختلاف درباره تعهدات نقش داشته باشد؛ بنابراین بهتر است اطلاعات مهم را به گفتوگوی شفاهی محدود نکنید.
شرح دقیقتر تصمیمهای بعدی را هم سادهتر میکند: چه نوع تخصصی لازم است، کدام پیشنهاد واقعاً به مسئله شما پاسخ میدهد، چه پرسشهایی باید از متخصص بپرسید و تحویل نهایی را با چه مبنایی بررسی کنید.
گام اول: نتیجهای را که میخواهید تعریف کنید
با فعالیت شروع نکنید؛ با مسئله و نتیجه شروع کنید.
- هدف کسبوکار: این پروژه قرار است کدام مشکل را حل کند یا کدام فرصت را ایجاد کند؟ مثلاً کاهش تماسهای تکراری پشتیبانی، آمادهسازی فروشگاه برای یک محصول جدید یا منظمکردن گزارشهای داخلی.
- خروجی قابل مشاهده: در پایان چه چیزی باید تحویل بگیرید؟ یک صفحه، فایل، داشبورد، فرایند مستند، مجموعه محتوا یا نمونه اولیه؟
- معیار نتیجه: اگر پروژه موفق باشد، چه تغییری در کار شما دیده میشود؟ این معیار میتواند کیفی یا کمی باشد، اما نباید عددی ساختگی به آن نسبت دهید.
- خارج از محدوده: چه کارهایی فعلاً بخشی از پروژه نیستند؟ مشخصکردن این بخش از بزرگشدن ناخواسته دامنه کار جلوگیری میکند.
تفاوت این سه مفهوم را حفظ کنید: «هدف» دلیل انجام پروژه است، «فعالیت» کاری است که متخصص انجام میدهد، و «خروجی» چیزی است که شما دریافت و بررسی میکنید. برای نمونه، هدف میتواند سادهکردن دریافت درخواست مشتری باشد؛ فعالیت، طراحی و پیادهسازی یک فرم؛ و خروجی، فرم قابل استفاده به همراه فایل یا راهنمای مورد توافق.
گام دوم: محدوده، نیازمندیها و معیار پذیرش را بنویسید
حالا نتیجه را به اجزای قابل بررسی تبدیل کنید. بنویسید کدام صفحات، قابلیتها، فایلها، خدمات یا مراحل باید در پروژه وجود داشته باشند. اگر درباره فناوری یا روش اجرا مطمئن نیستید، بهجای تحمیل راهحل، مسئله و محدودیت خود را توضیح دهید و از متخصص بخواهید گزینهها را پیشنهاد کند.
برای جداکردن نیاز ضروری از ترجیح شخصی، هر مورد را در یکی از این سه گروه قرار دهید:
- ضروری: نبود آن، هدف پروژه را بیمعنا یا خروجی را غیرقابل استفاده میکند.
- مطلوب: ارزش ایجاد میکند، اما میتوان پروژه را بدون آن شروع کرد.
- خارج از نسخه فعلی: ایدهای برای مرحله بعد که نباید محدوده فعلی را مبهم کند.
برای هر خروجی، معیار پذیرش بنویسید. معیار پذیرش یعنی روشی روشن برای پاسخ به این سؤال: «چطور بفهمیم خروجی قابل قبول است؟» میتوانید درباره کاملبودن بخشها، سازگاری با فرمت مورد نیاز، رعایت سناریوهای مشخص، تحویل فایلهای منبع یا انجام یک دور بازبینی توافق کنید. معیار باید قابل بررسی باشد، نه عباراتی مانند «خیلی خوب»، «حرفهای» یا «بدون نقص» که برداشتهای متفاوتی ایجاد میکنند.
گام سوم: محدودیتهای زمان، بودجه و منابع را مشخص کنید
اگر مهلت قطعی یا نقطه تحویل مهمی دارید، آن را همراه با دلیل بنویسید؛ برای مثال زمان عرضه، جلسه داخلی یا وابستگی به یک تیم دیگر. اگر تاریخ دقیق ندارید، بهجای وعدهدادن، اولویت زمانی و عوامل مؤثر بر آن را توضیح دهید.
بودجه را میتوانید بهصورت بازه یا برآورد اولیه بیان کنید و روشن کنید که این عدد قطعی نیست و به محدوده و پیشنهاد متخصص وابسته است. از درج عددی که هنوز مبنای مشخصی ندارد خودداری کنید. همچنین مشخص کنید چه چیزهایی از طرف شما فراهم میشود:
- دسترسی به ابزارها، حسابها یا دادهها؛
- نمونههای قبلی، راهنمای برند یا فایلهای مرجع؛
- فردی که پاسخگوی پرسشهای متخصص باشد؛
- وابستگی به تأیید مدیر، مشتری یا تیم فنی دیگر.
اگر قرارداد، مالکیت فایلها، محرمانگی یا مسئولیت هر طرف برایتان مهم است، آن را از ابتدا بهعنوان موضوعی برای توافق ثبت کنید. برای جزئیات این بخش میتوانید راهنمای قرارداد فریلنسری و مالکیت فکری را بخوانید.
قالب آماده برای نوشتن شرح پروژه
قالب زیر را کپی و با اطلاعات خودتان تکمیل کنید. این قالب یک نقطه شروع عملی است، نه استاندارد قطعی برای همه پروژهها.
عنوان پروژه:
مسئله یا نیاز کسبوکار:
- اکنون چه مشکلی وجود دارد؟
- این مشکل چه اثری بر کار، مشتری یا تیم دارد؟
هدف پروژه:
- پس از انجام پروژه چه تغییری میخواهیم ایجاد کنیم؟
خروجیهای قابل تحویل:
- خروجی ۱:
- خروجی ۲:
- فرمت یا اجزای هر خروجی:
محدوده پروژه:
- موارد داخل محدوده:
- موارد خارج از محدوده:
نیازمندیهای ضروری:
- مورد ۱:
- مورد ۲:
موارد مطلوب یا قابل بررسی در مرحله بعد:
- مورد ۱:
معیارهای پذیرش:
- خروجی در صورت وجود این شرایط قابل قبول است:
- روش یا فرد بررسیکننده:
زمانبندی و نقاط تحویل:
- مهلت یا رویداد مهم:
- نقاط تحویل مورد انتظار:
بودجه یا برآورد اولیه:
- بازه یا توضیح محدودیت بودجه:
- موارد وابسته به پیشنهاد متخصص:
منابع و دسترسیهای موجود:
- فایلها، دادهها، حسابها یا افراد مرتبط:
پرسشهای باز:
- چه چیزهایی هنوز نیاز به تصمیم یا پیشنهاد متخصص دارد؟یک نمونه فرضی را در نظر بگیرید: یک فروشگاه کوچک میخواهد درخواستهای همکاری تأمینکنندگان را منظم کند. هدف، کاهش پیگیریهای پراکنده است؛ فعالیت میتواند طراحی یک فرم و گردش بررسی باشد؛ خروجی، فرم، جدول ثبت درخواست و راهنمای استفاده است. معیار پذیرش هم میتواند ثبت کامل اطلاعات مورد نیاز، امکان مشاهده وضعیت هر درخواست و تحویل فایلهای قابل ویرایش باشد. این مثال فرضی است و قیمت یا زمان واقعی یک پروژه را نشان نمیدهد.
پیش از ثبت پروژه، شرحکار را بازبینی کنید
پیش از ارسال Brief، این چکلیست را بررسی کنید:
- آیا یک متخصص مستقل میتواند مسئله و هدف را بدون جلسهای طولانی بفهمد؟
- آیا تفاوت هدف، فعالیت و خروجی را روشن نوشتهاید؟
- آیا خروجیها قابل مشاهده و معیارهای پذیرش قابل بررسی هستند؟
- آیا موارد ضروری را از ترجیحات و ایدههای مرحله بعد جدا کردهاید؟
- آیا موارد خارج از محدوده مشخصاند؟
- آیا مهلت، وابستگیها، منابع و دسترسیهای لازم را گفتهاید؟
- آیا بودجه بهعنوان بازه یا برآورد اولیه، نه واقعیت قطعی، بیان شده است؟
- آیا پرسشهای باز را پنهان نکردهاید؟
پرسشهای متخصصان میتواند نشانه نقص Brief باشد. اگر چند نفر جداگانه درباره مخاطب، فرمت خروجی، اولویت قابلیتها یا روش تأیید سؤالهای مشابه میپرسند، بهجای پاسخدادن جداگانه، همان بخش را در شرح پروژه اصلاح کنید. هدف، حذف همه ابهامها نیست؛ هدف این است که ابهامهای مهم شناخته و قابل گفتوگو باشند.
از شرح پروژه تا دریافت پیشنهادهای مرتبط
پس از آمادهشدن Brief، آن را همراه با اطلاعاتی که سامانه ثبت پروژه درخواست میکند وارد کنید؛ جزئیات دقیق مراحل Kardeed، قابلیت تطبیق، نحوه دریافت پیشنهاد و مسیر تحویل باید پیش از انتشار این صفحه با تیم محصول تأیید شود. در شواهد بازار، الگوهایی مانند ثبت پروژه، دریافت پیشنهاد و بررسی نمونهکار دیده میشود، اما این الگوها را نباید بهعنوان قابلیت قطعی Kardeed معرفی کرد.
در صورت تأیید مسیر محصول، Brief روشن میتواند مبنای گفتوگوی دقیقتر با متخصصان و مقایسه گزینهها باشد؛ چون همه طرفها ابتدا درباره مسئله، خروجی، محدوده و معیار پذیرش صحبت میکنند. برای ادامه مسیر میتوانید مقایسه متخصصان و پیشنهادهای پروژه را بررسی کنید. اگر درباره سازوکار همکاری و اعتماد پرسش دارید، پرداخت امن و حل اختلاف پروژه را ببینید؛ محتوای آن باید فقط بر قابلیتهای تأییدشده تکیه کند.
وقتی شرح پروژهتان آماده شد، قالب Brief پروژه را تکمیل کنید و اطلاعات ناقص را بهصورت پرسش باز نگه دارید. سپس، در صورت تأیید قابلیت و مسیر محصول، میتوانید نیاز پروژهتان را در Kardeed ثبت کنید. ثبت نیاز اولیه نباید به این معنا باشد که پیش از گفتوگو باید همه جزئیات فنی را بدانید؛ مهم این است که مسئله، نتیجه مورد انتظار و محدودیتهای شناختهشده را شفاف بیان کنید.
پس از ارائه قالب و نمونه فرضی، کاربر میتواند اطلاعات پروژه خود را در همان ساختار وارد کند.
شروع تکمیل تعریف نیاز پروژهپس از بازبینی Brief، این اقدام ادامه طبیعی آمادهسازی شرح پروژه است؛ جزئیات مسیر محصول منوط به تأیید قابلیتهاست.
شروع Brief و ثبت پروژه