اغلب پروژههایی که در میانه راه متوقف میشوند یا مسیرشان کاملاً عوض میشود، یک نقطه شروع مشترک دارند: تیم مستقیم وارد کدنویسی شده، بدون اینکه پیش از آن بهاندازه کافی روی محدوده محصول، معماری و ریسکهای فنی فکر کرده باشد. مشکل معمولاً از بیکفایتی توسعهدهندهها نیست؛ از تصمیماتی است که خیلی زود و با اطلاعات ناقص گرفته شدهاند. اگر میخواهید عمیقتر ببینید این نوع تصمیمات چطور به شکست پروژه ختم میشوند، در چرا بیشتر پروژههای نرمافزاری شکست میخورند؟ این موضوع را از زاویه یک تیم توسعه بررسی کردهایم.
مرحله Discovery دقیقاً برای همین وجود دارد: قبل از اینکه اولین خط کد نوشته شود، سؤالهای مهم پرسیده و پاسخ داده شوند.
Discovery دقیقاً چه کاری انجام میدهد؟
Discovery مرحلهای است که در آن، پیش از شروع توسعه، محدوده محصول، معماری فنی، ریسکها و نیازهای واقعی کاربر بررسی و مستند میشوند. خروجی آن یک سند ثابت و بیفایده نیست؛ مجموعهای از تصمیمات مشخص است که مسیر فنی و کسبوکاری پروژه را تعیین میکند: چه چیزی ساخته میشود، با چه معماریای، با چه اولویتی، و با چه ریسکهایی.
در عمل، این مرحله شامل تحلیل نیازمندیها، بررسی امکانپذیری فنی (Technical Feasibility)، تعریف محدوده نسخه اول محصول، و شناسایی نقاطی است که تصمیم اشتباه در آنها بیشترین آسیب را به پروژه میزند.
چرا غیبت Discovery فقط «تأخیر» ایجاد نمیکند
تصور رایج این است که رد کردن Discovery فقط باعث میشود پروژه کمی دیرتر یا با کمی هزینه اضافه تمام شود. اما مسئله اصلی جای دیگری است: بدون تحلیل اولیه، تصمیمات معماری در همان روزهای اول و با کمترین اطلاعات گرفته میشوند.
انتخاب استک فناوری، ساختار پایگاه داده، و معماری کلی سیستم، تصمیماتی هستند که تغییر آنها در میانه پروژه بسیار گرانتر از گرفتن درست آنها در ابتدا است. یک تصمیم اشتباه در روز اول، معمولاً در ماه سوم یا چهارم به شکل بازطراحی، بازنویسی بخشهای مهم، یا محدودیتهایی ظاهر میشود که از ابتدا قابل پیشبینی بودند.
هزینه واقعی نبود Discovery، در فاز برنامهریزی دیده نمیشود؛ در فازهای بعدی پروژه، به شکل بازطراحی و تصمیمات اصلاحی خودش را نشان میدهد.
چه تصمیماتی در Discovery گرفته میشوند؟
Discovery خوب، به چهار سؤال اصلی پاسخ روشن میدهد. اگر پاسخ هرکدام از اینها نامشخص باشد، ریسک پروژه از همان ابتدا بالا میرود.
- محصول دقیقاً چه مسئلهای را برای چه کاربری حل میکند؟
- نسخه اول (MVP) شامل چه ویژگیهایی است و چه چیزی عمداً کنار گذاشته میشود؟
- معماری فنی پیشنهادی با چه محدودیتها و مقیاسپذیریای طراحی میشود؟
- کدام ریسکهای فنی یا کسبوکاری بیشترین احتمال شکست پروژه را دارند؟
تفاوت اصلی یک Discovery خوب با یک جلسه معرفی ایده، همین دقت در پاسخهاست. جلسه معرفی ایده معمولاً با «چه چیزی میخواهیم بسازیم» تمام میشود؛ Discovery با «چطور میسازیم و چرا اینطور» ادامه پیدا میکند.
آیا هر پروژهای به Discovery جداگانه نیاز دارد؟
نه هر پروژهای. اگر محصول ساده باشد، الگوی مشابهی قبلاً ساخته شده باشد، یا تیم تجربه مستقیم و روشنی از همان نوع پروژه داشته باشد، یک Discovery رسمی و طولانی لازم نیست.
اما هرچه محصول پیچیدهتر، ذینفعان بیشتر، یا نیازمندیها مبهمتر باشند، نبود Discovery ریسک بیشتری ایجاد میکند. جدول زیر تفاوت این دو حالت را نشان میدهد.
| ویژگی پروژه | نیاز به Discovery رسمی |
|---|---|
| محصول ساده با الگوی شناختهشده | کم |
| محصول جدید با نیازمندی مبهم | زیاد |
| چند ذینفع با اهداف متفاوت | زیاد |
| معماری با نیاز به مقیاسپذیری بالا | زیاد |
چرا این موضوع برای معماری فنی محصول مهم است
یکی از نقاطی که کمتر دربارهاش صحبت میشود، رابطه مستقیم بین کیفیت Discovery و کیفیت معماری فنی است. تصمیماتی مثل انتخاب بین یک اپلیکیشن وب معمولی یا یک PWA، یا انتخاب معماری برای مقیاسپذیری آینده، بدون شناخت دقیق از کاربر نهایی و بار واقعی سیستم، معمولاً یا محافظهکارانهتر از حد لازم گرفته میشوند یا برعکس، پیچیدهتر از نیاز واقعی پروژه. بخش زیادی از این شناخت، همان چیزی است که در طراحی تجربه کاربری هم اهمیت دارد؛ در اهمیت UX در کسبوکار اینترنتی توضیح دادهایم چرا شناخت کاربر واقعی، نقطه شروع تصمیمات درست است.
نتیجه هر دو حالت یکسان است: هزینهای که یا در ابتدا اضافه پرداخت شده، یا در آینده برای جبران کمبود، دوباره پرداخت میشود. Discovery دقیقاً همین فاصله بین «آنچه فکر میکنیم لازم است» و «آنچه واقعاً لازم است» را کم میکند.
یک چارچوب ساده برای تصمیمگیری
قبل از شروع پروژه، این سه سؤال میتواند مشخص کند که آیا Discovery جداگانه لازم است یا میتوان مستقیم به توسعه رفت.
- آیا نیازمندیها روشن و مستند هستند؟ اگر پاسخ به این سؤال بله نیست، Discovery برای شفافسازی محدوده ضروری است.
- آیا معماری فنی پیشنهادی قبلاً در پروژهای مشابه امتحان شده؟ اگر نه، بررسی امکانپذیری فنی میتواند از تصمیمات پرهزینه بعدی جلوگیری کند.
- آیا ذینفعان پروژه روی هدف نهایی توافق کامل دارند؟ اگر جواب منفی است، ادامه پروژه بدون همراستایی، احتمال تغییر مسیر در میانه راه را بالا میبرد.
جمعبندی
Discovery یک مرحله تشریفاتی قبل از شروع «کار اصلی» نیست؛ خودش بخشی از کار اصلی است. تصمیماتی که در این مرحله گرفته میشوند، همان تصمیماتی هستند که بعداً معماری، هزینه و سرعت توسعه محصول را تعیین میکنند. رد کردن این مرحله برای صرفهجویی در زمان، در بسیاری از موارد، فقط هزینه را به فازی دیرتر و گرانتر منتقل میکند.
تیم Binary Band در طراحی و توسعه محصولات دیجیتال، Discovery را بخشی از فرآیند فنی میداند، نه یک مرحله جداگانه مدیریتی؛ اگر روی یک پروژه جدید تصمیمگیری میکنید، میتوانید سؤالات رایج درباره فرآیند کار را هم ببینید.
