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