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