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