رفتن به محتوای اصلی

در تمام مراحل پروژه می‌دانید چه چیزی در حال طراحی و توسعه است.

پروژه را به مرحله‌ها و خروجی‌های مشخص تقسیم می‌کنیم تا روند کار فقط در گزارش‌های کلی خلاصه نشود. در بازه‌های توافق‌شده، نتیجهٔ قابل بررسی، وضعیت کارهای انجام‌شده، تصمیم‌های باز و موانع احتمالی را با شما در میان می‌گذاریم. به این ترتیب، پیش از رسیدن به پایان پروژه فرصت دارید خروجی‌ها را ببینید، بازخورد بدهید و دربارهٔ قدم بعدی آگاهانه تصمیم بگیرید.

جزئیات این فرآیند متناسب با اندازه و نوع هر پروژه تنظیم می‌شود. یک وب‌سایت شرکتی، اپلیکیشن موبایل یا سامانهٔ سازمانی ممکن است زمان‌بندی و خروجی‌های متفاوتی داشته باشند، اما اصل ثابت همکاری، شفاف بودن محدوده، مسئولیت‌ها، تصمیم‌ها و وضعیت پیشرفت است.

همکاری تیمی، بررسی طراحی و تأیید مرحله‌های پروژه

مسیر اجرای پروژه

چهار مرحلهٔ مشخص، از شناخت مسئله تا انتشار و ادامهٔ توسعه

هر مرحله هدف، خروجی و نقطهٔ تصمیم مشخصی دارد. عبور از یک مرحله به مرحلهٔ بعد پس از بررسی نتیجه و تأیید موارد لازم انجام می‌شود. این ساختار کمک می‌کند ابهام‌ها زودتر شناسایی شوند و تغییرهای مهم پیش از آنکه هزینه و زمان زیادی مصرف کنند، مورد گفت‌وگو قرار گیرند.

ابتدا مسئله، کاربران و هدف پروژه را می‌شناسیم

دربارهٔ کسب‌وکار، کاربران، فرآیند فعلی، مشکلات موجود و نتیجه‌ای که از محصول انتظار دارید گفت‌وگو می‌کنیم. در صورت نیاز، دیدگاه افراد اصلی درگیر با محصول نیز بررسی می‌شود تا تصمیم‌ها فقط بر اساس حدس یا خواسته‌های پراکنده گرفته نشوند. در پایان این مرحله باید تعریف مشترکی از مسئله، کاربران هدف، اولویت‌ها، محدودیت‌ها و معیارهای اولیهٔ موفقیت داشته باشیم.

اگر پروژه هنوز ابهام زیادی داشته باشد، ممکن است این مرحله به‌صورت یک فاز مستقل انجام شود. هدف آن تهیهٔ یک برآورد قابل اتکا و کاهش ریسک شروع توسعه با نیازهای نامشخص است.

شناخت کاربران و پیدا کردن مسئلهٔ اصلی
  • خروجی: تعریف مسئله، کاربران و نتیجهٔ مورد انتظار
  • خروجی: محدوده و اولویت‌های نسخهٔ اول
  • تصمیم: تأیید مسیر، اصلاح محدوده یا ادامهٔ بررسی

پیش از توسعه، ساختار و تجربهٔ اصلی محصول را بررسی می‌کنیم

جریان‌های اصلی کاربر، ساختار اطلاعات، صفحه‌های مهم و نحوهٔ انجام کارهای اصلی محصول طراحی می‌شوند. بسته به نوع پروژه، این خروجی می‌تواند شامل وایرفریم، نمونهٔ اولیهٔ قابل کلیک، طراحی رابط کاربری یا طرح معماری فنی باشد. بررسی و اصلاح تصمیم‌های اصلی در این مرحله معمولاً ساده‌تر و کم‌هزینه‌تر از تغییر آن‌ها پس از توسعهٔ کامل است.

نمونهٔ اولیه الزاماً محصول نهایی یا کد قابل انتشار نیست. هدف آن این است که پیش از شروع توسعه، برداشت مشترکی از تجربهٔ کاربر، محدودهٔ امکانات و راه‌حل فنی ایجاد شود.

دیدن و امتحان کردن طرح، پیش از کدنویسی
  • خروجی: جریان‌های کاربر و نمونهٔ اولیهٔ بخش‌های اصلی
  • خروجی: طرح فنی، ساختار داده و نیازهای زیرساختی
  • تصمیم: تأیید طراحی و محدوده برای شروع توسعه

محصول را مرحله‌به‌مرحله می‌سازیم و در بازه‌های مشخص ارائه می‌دهیم

توسعه بر اساس اولویت‌ها و مرحله‌های توافق‌شده انجام می‌شود. در بازه‌های مشخص، بخش‌های آماده یا نسخهٔ قابل بررسی محصول ارائه می‌شوند تا وضعیت واقعی کار مشخص باشد و بازخوردها پیش از انباشته شدن تغییرات دریافت شوند. هم‌زمان با توسعه، آزمایش‌های لازم، رفع خطا و مستندسازی فنی یا اجرایی نیز متناسب با پروژه انجام می‌شود.

بازخوردهایی که در محدودهٔ تأییدشده قرار دارند در مسیر اجرای همان مرحله بررسی می‌شوند. درخواست‌هایی که امکانات، منطق یا دامنهٔ پروژه را تغییر می‌دهند، پیش از اجرا از نظر اثر بر زمان، هزینه و وابستگی‌های فنی ارزیابی و پس از توافق به برنامه اضافه می‌شوند.

ساخت، آزمایش و ارائهٔ نسخه‌های قابل بررسی
  • خروجی: نسخه‌ها یا بخش‌های قابل بررسی در هر مرحله
  • خروجی: آزمایش، رفع خطا و مستندات موردنیاز
  • تصمیم: تأیید آمادگی برای انتشار یا ادامهٔ اصلاحات

محصول را منتشر می‌کنیم، تحویل می‌دهیم و برای ادامه برنامه می‌سازیم

پس از تأیید نسخهٔ آماده، انتشار یا استقرار محصول طبق برنامه انجام می‌شود. اطلاعات و دسترسی‌های لازم تحویل داده می‌شوند و در صورت نیاز، آموزش استفاده یا مدیریت محصول برای اعضای مرتبط تیم شما برگزار می‌شود. وضعیت محصول در دورهٔ ابتدایی انتشار بررسی می‌شود و رفع خطا، نگهداری و توسعهٔ نسخه‌های بعدی بر اساس شرایط توافق‌شده ادامه پیدا می‌کند.

محدوده و مدت پشتیبانی پس از انتشار، زمان پاسخ‌گویی، نگهداری زیرساخت و توسعهٔ امکانات جدید در پیشنهاد یا قرارداد هر پروژه مشخص می‌شوند. توسعهٔ نسخهٔ بعدی بهتر است بر اساس بازخورد کاربران، داده‌های استفاده و اولویت‌های واقعی کسب‌وکار برنامه‌ریزی شود.

انتشار محصول و همراهی در قدم‌های بعدی
  • خروجی: نسخهٔ قابل انتشار یا استقرار در محیط اصلی
  • خروجی: تحویل، آموزش و مستندات توافق‌شده
  • تصمیم: برنامهٔ پشتیبانی، نگهداری و نسخه‌های بعدی

ارتباط و گزارش‌دهی

گزارش پیشرفت باید قابل بررسی باشد، نه فقط یک جملهٔ کلی.

زمان‌بندی ارتباط و ارائهٔ خروجی‌ها در آغاز پروژه مشخص می‌شود. گزارش‌ها تا حد امکان کوتاه، روشن و مبتنی بر نتیجهٔ قابل مشاهده هستند. تصمیم‌های مهم، تغییرهای محدوده، موانع و مواردی که بر زمان یا هزینه اثر می‌گذارند به‌صورت مکتوب ثبت می‌شوند تا برداشت متفاوتی میان طرفین باقی نماند.

پیشرفت منظم پروژه به دریافت به‌موقع اطلاعات، دسترسی‌ها، محتوا، تأییدها و بازخوردهای لازم نیز وابسته است. اگر تصمیم یا ورودی مهمی از سوی کارفرما با تأخیر ارائه شود، اثر آن بر برنامهٔ پروژه به‌صورت شفاف اعلام خواهد شد.

نتیجه را امتحان می‌کنید

در زمان‌های توافق‌شده، بخش آماده یا نمونهٔ اولیه را در اختیارتان می‌گذاریم تا بررسی کنید و نظر بدهید.

از وضعیت کار خبر دارید

می‌گوییم چه کارهایی انجام شده، چه چیزی در دست ساخت است و برای ادامه به چه تصمیمی نیاز داریم.

قبل از تغییر هماهنگ می‌کنیم

اگر پیشنهادی زمان یا هزینه را تغییر بدهد، دلیل و گزینه‌های آن را قبل از اجرا با شما در میان می‌گذاریم.

مدیریت تغییرات

تغییر طبیعی است؛ مهم این است که پیش از اجرا، اثر آن روشن باشد.

در طول پروژه ممکن است نیاز تازه‌ای مشخص شود یا اولویت‌های کسب‌وکار تغییر کنند. درخواست جدید ابتدا از نظر ضرورت، وابستگی فنی و اثر آن بر محدودهٔ توافق‌شده بررسی می‌شود. اگر تغییر از محدودهٔ فعلی خارج باشد، برآورد و برنامهٔ آن پیش از اجرا با شما هماهنگ خواهد شد.

اصلاح بخش توافق‌شده

بازخورد لازم برای تکمیل همان بخش را بررسی می‌کنیم و طبق روند آن مرحله پیش می‌بریم.

افزودن قابلیت تازه

ابتدا زمان، هزینه و اثر فنی قابلیت جدید را برآورد می‌کنیم و پس از توافق دو طرف، آن را به برنامه اضافه می‌کنیم.

تغییر اولویت کارها

در همکاری منعطف می‌توانیم ترتیب کارهای آینده را تغییر دهیم؛ بعد از اینکه اثرش بر تحویل و زمان‌بندی را روشن کردیم.

مدل همکاری

نوع همکاری باید با میزان شفافیت نیازها و تغییرپذیری پروژه متناسب باشد.

یک مدل قراردادی برای همهٔ پروژه‌ها مناسب نیست. پروژه‌ای با محدودهٔ مشخص می‌تواند بر اساس خروجی‌های توافق‌شده اجرا شود، اما محصولی که نیازهای آن به‌مرور تغییر می‌کنند به ظرفیت مستمر و اولویت‌بندی منعطف نیاز دارد. اگر هنوز اطلاعات کافی برای برآورد وجود ندارد، بهتر است ابتدا فاز شناخت و تعریف پروژه انجام شود.

پروژه با محدودهٔ مشخص

مناسب پروژه‌ای است که نیازها، خروجی‌ها و محدودیت‌های اصلی آن تا حد قابل قبولی مشخص‌اند. محدوده، مرحله‌ها، زمان‌بندی، مبلغ و شرایط تغییرات در پیشنهاد یا قرارداد ثبت می‌شوند.

این مدل برای تغییرهای بزرگ و پی‌درپی مناسب نیست؛ قابلیت‌های خارج از محدوده پس از بررسی و توافق جداگانه به برنامه اضافه می‌شوند.

همکاری مستمر برای محصول در حال رشد

مناسب محصولی است که پس از انتشار به توسعه، نگهداری، تحلیل بازخورد و تغییر اولویت‌ها نیاز دارد. ظرفیت کاری در یک دورهٔ مشخص تعیین می‌شود و کارها بر اساس اولویت‌های مورد توافق برنامه‌ریزی می‌شوند.

در این مدل، ظرفیت و فرآیند اولویت‌بندی مشخص است، اما انجام هم‌زمان همهٔ درخواست‌ها تضمین نمی‌شود؛ مهم‌ترین موارد در هر دوره انتخاب و اجرا می‌شوند.

فاز مستقل شناخت و تعریف پروژه

مناسب زمانی است که ایده یا مسئله وجود دارد، اما کاربران، فرآیندها، امکانات یا محدودهٔ نسخهٔ اول هنوز برای برآورد دقیق روشن نیستند. نتیجهٔ این فاز می‌تواند مبنای تصمیم برای ادامهٔ طراحی و توسعه باشد.

انجام این فاز به معنی الزام برای ادامهٔ توسعه نیست؛ خروجی آن باید به شما کمک کند دربارهٔ مسیر بعدی، بودجه و اولویت‌ها آگاهانه تصمیم بگیرید.

پیش از شروع اجرا

موارد اصلی همکاری پیش از آغاز پروژه مکتوب می‌شوند.

جزئیات هر پروژه متفاوت است، اما پیشنهاد یا قرارداد باید حداقل انتظارهای اصلی دو طرف را روشن کند. متن حقوقی نهایی فقط همان سند امضاشده است و این صفحه توضیح عمومی فرآیند همکاری محسوب می‌شود.

چه چیزی می‌سازیم؟

بخش‌های داخل و خارج پروژه و چیزی که در هر مرحله تحویل می‌گیرید را ثبت می‌کنیم.

چه زمانی تحویل می‌دهیم؟

زمان تقریبی مرحله‌ها و اطلاعات یا تأییدهایی که برای ادامه نیاز داریم را مشخص می‌کنیم.

هزینه و پرداخت چطور است؟

مبلغ، موعد پرداخت‌ها و شرایط تغییر محدوده را در پیشنهاد یا قرارداد می‌نویسیم.

بعد از تحویل چه می‌شود؟

دربارهٔ دسترسی‌ها، آموزش، رفع خطا و محدودهٔ پشتیبانی و نگهداری با هم توافق می‌کنیم.

انتخاب مسیر همکاری

دربارهٔ پروژه‌تان صحبت کنید تا مدل همکاری مناسب را بر اساس شرایط واقعی آن بررسی کنیم.

برای شروع لازم نیست همهٔ جزئیات آماده باشند. توضیح کوتاهی دربارهٔ هدف، کاربران، وضعیت فعلی و محدودیت‌های مهم پروژه ارسال کنید. پس از بررسی اولیه مشخص می‌کنیم آیا پروژه برای برآورد مستقیم آماده است یا بهتر است ابتدا یک فاز شناخت و تعریف انجام شود.