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