فرض کنید مدیر یک کلینیک هستید. نوبت‌ها گاهی در دفتر ثبت می‌شوند، گاهی در پیام‌رسان و گاهی روی برگه‌ای کنار تلفن. شما می‌دانید این وضعیت باید بهتر شود؛ اما شاید ندانید نرم‌افزار مناسب چه صفحه‌هایی لازم دارد، چه کسی باید به کدام اطلاعات دسترسی داشته باشد یا چه مواردی را باید به شرکت سازنده توضیح بدهید.
همین‌جا ممکن است از هوش مصنوعی کمک بگیرید و در چند ثانیه فهرستی طولانی از امکانات، فناوری‌ها و پیشنهادها تحویل بگیرید. بعضی پیشنهادها مفیدند، اما زیادبودنشان تصمیم را آسان نمی‌کند. وظیفهٔ شما این نیست که از روز اول همه‌چیز را به زبان فنی توضیح دهید؛ وظیفهٔ تیم طراحی هم فقط دریافت یک فهرست و شروع برنامه‌نویسی نیست. نقطهٔ شروع خوب، رسیدن به یک درک مشترک از مسئله و مسیر کار است.
در این راهنما، سفارش نرم‌افزار اختصاصی یا اپلیکیشن را به زبان ساده و با همین مثال فرضی دنبال می‌کنیم. شرایط هر پروژه متفاوت است؛ بنابراین نمونه‌ها برای روشن‌شدن موضوع هستند و جای بررسی کسب‌وکار شما را نمی‌گیرند.
| خلاصه در ۳ دقیقه؛ اگر فقط همین را بخوانید |
|---|
|
۱. پیش از هر چیز، مسئله را تعریف کنید#
بسیاری از مدیران گفتگو را با جمله‌ای مانند «یک اپلیکیشن کامل می‌خواهم» آغاز می‌کنند. این جمله جهت کلی را نشان می‌دهد، اما هنوز مشخص نمی‌کند کدام مشکل باید حل شود. یک پرسش بهتر این است: «چه اتفاقی در کار ما تکرار می‌شود که زمان، پول یا رضایت مشتری را از بین می‌برد؟»
در مثال کلینیک، مشکل می‌تواند این باشد: «وقتی دو نفر هم‌زمان نوبت‌ها را ثبت می‌کنند، گاهی یک ساعت دوبار رزرو می‌شود و پذیرش دیر متوجه تغییرات می‌شود.» حالا می‌توان دربارهٔ دلیل مشکل، تعداد وقوع آن و راه‌حل‌های ممکن گفتگو کرد؛ شاید نرم‌افزار اختصاصی مناسب باشد، شاید یک ابزار آماده کافی باشد یا ابتدا اصلاح فرایند لازم باشد. برای بررسی این گام، راهنمای سیستم‌سازی کسب‌وکار و طراحی فرایندها را بخوانید.
- کار امروز چگونه انجام می‌شود و چه کسانی درگیرند؟
- کجا تأخیر، دوباره‌کاری، خطا یا نارضایتی ایجاد می‌شود؟
- اگر پروژه موفق باشد، چه چیزی قابل مشاهده بهتر می‌شود؟
- کدام محدودیت‌ها را از ابتدا می‌دانیم؛ مانند بودجه، زمان، اطلاعات موجود یا شیوهٔ کار کارکنان؟
برای پاسخ، لازم نیست سند پیچیده‌ای بنویسید. حتی یک صفحه توضیح، چند عکس از فرم‌های بدون اطلاعات شخصی و گفتگوی کوتاه با افرادی که کار را هر روز انجام می‌دهند، شروع خوبی است. در نمونهٔ کلینیک، موفقیت می‌تواند «کاهش نوبت‌های تکراری» باشد؛ برای سنجش آن ابتدا باید وضعیت فعلی ثبت شود.
۲. از هوش مصنوعی کمک بگیرید؛ تصمیم را با شناخت کسب‌وکار بگیرید#
هوش مصنوعی می‌تواند سؤال‌های اولیه پیشنهاد کند، توضیح‌های فنی را ساده کند یا یک فهرست شلوغ را مرتب کند. اما بدون شناخت شیوهٔ کار، محدودیت‌ها و اطلاعات واقعی سازمان شما، ممکن است امکانات غیرضروری، فرض‌های نادرست یا راهکارهایی متناسب با کسب‌وکاری دیگر پیشنهاد دهد. همهٔ پیشنهادها را فرضیه برای بررسی ببینید.
آنچه این روزها در بسیاری از پروژه‌ها می‌بینیم، چنین الگویی است: مدیر، پرسش شرکت طراحی را به هوش مصنوعی می‌دهد؛ پاسخ تولیدشده را بی‌بازبینی برای شرکت می‌فرستد و شرکت هم پاسخ خود را می‌نویسد تا مدیر آن را دوباره به هوش مصنوعی بدهد. در این چرخه در واقع دو ابزار با هم مکاتبه می‌کنند و مدیر تنها نقشِ پیک را بازی می‌کند؛ کسی که باید تصمیم بگیرد، کمتر از همه در جریان محتوای مکالمه است. نتیجه هم قابل پیش‌بینی است: برآوردی بر پایهٔ فهرستی که هیچ‌کس تأیید نکرده، امکاناتی که کاربر واقعی نمی‌خواهد و سرانجام انصراف از پروژه‌ای که از همان ابتدا مشکل درست را هدف نگرفته بود.
اگر یک پاسخ تولیدشده را برای تیم طراحی می‌فرستید، کنار آن بنویسید: «این متن پیشنهاد هوش مصنوعی است. من دربارهٔ سه مورد اول مطمئنم؛ دربارهٔ بقیه نیاز به توضیح و بررسی دارم.» از تیم بخواهید دلیل پذیرش یا کنارگذاشتن هر پیشنهاد را با مثال بیان کند.
اگر پاسخ تیم فنی را نیز با هوش مصنوعی بررسی می‌کنید، نتیجه را به شکل سؤال مشخص برگردانید؛ مثلاً «منظورتان از سطح دسترسی برای پذیرش چیست و چه کسی آن را تعیین می‌کند؟»
نمونهٔ درخواست مفید: «من مدیر یک کلینیک هستم و نوبت‌ها اکنون در دفتر و پیام‌رسان ثبت می‌شوند. قبل از پیشنهاد امکانات، ۱۰ سؤال ساده بپرس تا مشکل و افراد درگیر روشن شود. فرض‌های خودت را جداگانه مشخص کن.» اطلاعات هویتی بیماران، رمزها و داده‌های محرمانه را در این گفتگو وارد نکنید.
در پایان، تصمیم دربارهٔ نیازها باید در گفتگوی مستقیم میان فرد آشنا با کسب‌وکار و تیم طراحی روشن و ثبت شود. هوش مصنوعی به آماده‌شدن سؤال‌ها و فهم گزینه‌ها کمک می‌کند؛ تأیید اولویت‌ها و پذیرش خروجی بر عهدهٔ افراد مسئول پروژه است.
تصمیم‌های پروژه را آدم‌ها می‌گیرند؛ هوش مصنوعی فقط سؤال‌ها را مرتب می‌کند.
۳. فاز صفر چیست و چرا گفتگوی پروژه را روشن‌تر می‌کند؟#
فاز صفر نامی است که در این مقاله برای مرحلهٔ شناخت، تحلیل و طراحی اولیه پیش از تعهد به ساخت کامل به کار می‌بریم. نام و دامنهٔ این مرحله در شرکت‌های مختلف یکسان نیست؛ پیش از شروع، دقیقاً مشخص کنید چه خروجی‌هایی تحویل می‌گیرید، چه کسی آن‌ها را تأیید می‌کند و هزینه و زمان این مرحله چگونه تعیین می‌شود.
هدف این است که پیش از تعیین تمام جزئیات ساخت، تیم و کارفرما بتوانند دربارهٔ یک تصویر مشترک صحبت کنند: چه مسئله‌ای حل می‌شود، چه کسانی از سامانه استفاده می‌کنند، مهم‌ترین مسیرها چیست و نسخهٔ اول چه محدوده‌ای دارد. شناخت نیاز، بررسی روش فعلی و گفتگو با کاربران واقعی از اصول مهم این مرحله‌اند؛ راهنمای شناخت نیاز کاربران در مرحلهٔ کشف نیز بر همین کار تأکید می‌کند.
یک فاز صفر متناسب با اندازهٔ پروژه می‌تواند شامل گفتگوی مدیر و کارکنان، بررسی فرم‌ها، ترسیم فرایندهای اصلی، تهیهٔ وایرفریم چند صفحهٔ کلیدی، تعیین اولویت‌ها و آماده‌کردن مبنایی برای برآورد باشد. لازم نیست همهٔ پروژه‌ها خروجی یکسان داشته باشند؛ مثلاً برای یک ابزار داخلی کوچک ممکن است چند صفحه و یک فرایند اصلی کافی باشد.
زمان این مرحله نیز به همان اندازه وابسته است: برای یک کسب‌وکار متوسط معمولاً از چند جلسهٔ گفتگو تا یکی‌دو هفتهٔ کار متمرکز روی خروجی‌ها جلو می‌رود و برای سامانه‌های سازمانی بزرگ می‌تواند طولانی‌تر شود. عدد دقیق را پیش از شروع، مکتوب و توافق‌شده بگیرید، نه در میانهٔ مسیر.
پیش از شروع این مرحله، دربارهٔ خروجی‌های قابل تحویل توافق کنید. برای نمونه:
- خلاصهٔ مسئله و هدف: قرار است چه چیزی بهتر شود و نتیجه چگونه سنجیده شود؟
- فهرست نقش‌ها و فرایندها: چه کسانی چه کاری انجام می‌دهند و حالت‌های مهم هر مسیر چیست؟
- وایرفریم یا نمونهٔ اولیهٔ توافق‌شده: کدام صفحه‌ها و مسیرها برای بازبینی آماده می‌شوند؟
- محدوده و اولویت‌ها: چه مواردی برای نسخهٔ اول پیشنهاد شده و چه مواردی به بعد موکول می‌شود؟
- سؤال‌های باز و برآورد: چه فرض‌هایی نیاز به بررسی دارند و برآورد زمان و هزینه تا چه اندازه به آن‌ها وابسته است؟
خروجی مطلوب: کارفرما بتواند با زبان خودش توضیح دهد چه کسی از نرم‌افزار استفاده می‌کند، هر مسیر اصلی چه نتیجه‌ای دارد، چه مواردی در نسخهٔ اول قرار گرفته و چه سؤال‌هایی هنوز باز است.
برای دیدن بهتر اثر این مرحله، وضعیت یک پروژه را با و بدون فاز صفر مقایسه کنید:
| موضوع | بدون فاز صفر | با فاز صفر |
|---|---|---|
| شروع پروژه | با فهرست امکانات تولیدشده و کلی‌گویی | با توافق مکتوب بر مسئله، نقش‌ها و مسیرهای اصلی |
| برآورد هزینه و زمان | روی کاغذ دقیق، در عمل بی‌ارتباط با نیاز واقعی | مبتنی بر مسیرهای توافق‌شده و فرض‌های مشخص |
| تصویر مشترک از کار | ندارد؛ اولین دیدن نتیجه، بعد از ساخت است | وایرفریم قابل بازبینی، پیش از نوشتن هر خط کد |
| تغییر در میانهٔ کار | پرهزینه و پرتنش؛ «این را نمی‌خواستم» | ارزان؛ اصلاح طرح به‌جای بازنویسی برنامه |
| نتیجهٔ نهایی | نرم‌افزاری پر از امکانات بلااستفاده | نسخهٔ اول کوچکی که مشکل اصلی را حل می‌کند |
۴. فرایندها را با یک داستان واقعی توضیح دهید#
به‌جای گفتن «سیستم نوبت‌دهی هوشمند باشد»، یک اتفاق مشخص را از آغاز تا پایان تعریف کنید. برای نمونه: «زیباجو برای ویزیت تماس می‌گیرد، پذیرش زمان‌های آزاد را بررسی می‌کند، نوبت را ثبت می‌کند و پس از تأیید، پیام اطلاع‌رسانی ارسال می‌شود.»
حالا دربارهٔ حالت‌های خاص هم صحبت کنید: اگر زمان انتخابی پر بود چه می‌شود؟ اگر مشتری نوبت را تغییر داد چه کسی مطلع می‌شود؟ اگر پیام ارسال نشد، پذیرش از کجا می‌فهمد؟ آیا نوبت بدون پرداخت هم معتبر است؟ پاسخ این سؤال‌ها برای هر کلینیک ممکن است متفاوت باشد؛ تیم نباید از روی یک فهرست عمومی آن‌ها را حدس بزند.
- شروع: درخواست از چه کانالی می‌رسد؟
- مسئول: چه کسی ثبت یا تأیید می‌کند؟
- اطلاعات: چه داده‌ای واقعاً لازم است و از کجا می‌آید؟
- تصمیم: در هر نقطه چه حالت‌های متفاوتی ممکن است پیش بیاید؟
- پایان: نتیجه چیست و چه کسی از آن مطلع می‌شود؟
ابتدا دو یا سه فرایند مهم و پرتکرار را بررسی کنید. بعد از توافق دربارهٔ آن‌ها، سراغ جزئیات دیگر بروید. این ترتیب کمک می‌کند تصمیم‌های اصلی زیر انبوه امکانات فرعی گم نشوند.
۵. وایرفریم چیست و چه چیزی را روشن می‌کند؟#
وایرفریم را می‌توان طرح سادهٔ صفحه‌های نرم‌افزار دانست؛ شبیه نقشهٔ اولیهٔ یک ساختمان. این طرح نشان می‌دهد اطلاعات، دکمه‌ها و بخش‌های اصلی تقریباً کجا قرار می‌گیرند و کاربر از یک صفحه چگونه به صفحهٔ بعد می‌رود. وایرفریم ممکن است روی کاغذ، به شکل تصویر یا به صورت نمونه‌ای قابل کلیک ارائه شود.
برای مثال کلینیک، سه طرح اولیه می‌تواند شامل «فهرست نوبت‌های امروز»، «ثبت نوبت جدید» و «جزئیات یا تغییر نوبت» باشد. مدیر با دیدن آن‌ها می‌تواند سؤال کند: «آیا پذیرش در همین صفحه متوجه می‌شود پزشک مرخصی دارد؟» یا «اگر تلفن بیمار تغییر کند، چه کسی آن را اصلاح می‌کند؟» همین سؤال‌ها پیش از ساخت، به اصلاح مسیر کمک می‌کنند.
وایرفریم به‌تنهایی نشان‌دهندهٔ کارکرد واقعی، امنیت، سرعت یا تکمیل نرم‌افزار نیست. همچنین جزئیاتی مثل رنگ، نوع قلم و هویت بصری معمولاً در طراحی ظاهری دقیق‌تر می‌شوند. برای بررسی مؤثر، از تیم بخواهید یک سناریو را روی طرح اجرا کند و شما نیز آن را با نگاه کاربر واقعی مرور کنید.
سؤال خوب در جلسه: «اگر یکی از کارکنان تازه‌وارد بخواهد این کار را انجام دهد، از کجا شروع می‌کند و در هر مرحله چه چیزی می‌بیند؟»
چند نمونهٔ کاربردی از وایرفریم#
این طرح‌های آموزشی با اطلاعات فرضی آماده شده‌اند تا ببینید یک وایرفریم فارسی چگونه مسیر کاربر و نقش افراد را پیش از ساخت نرم‌افزار روشن می‌کند. این تصاویر نمونهٔ پروژهٔ واقعی مشتریان نیستند.
۱. اپلیکیشن رزرو خدمات
در این نمونه، مراجعه‌کننده ابتدا خدمت را انتخاب می‌کند، سپس زمان موردنظر را برمی‌گزیند و نتیجهٔ درخواست را می‌بیند. در جلسه می‌توان دربارهٔ زمان‌های پر، نحوهٔ تأیید و اطلاع‌رسانی گفت‌وگو کرد. برای انتخاب بستر مناسب این تجربه، مقایسهٔ برنامهٔ وب پیش‌رونده و اپلیکیشن بومی را نیز ببینید.
۲. پنل پیگیری درخواست مشتریان
این طرح به مدیر و تیم فروش کمک می‌کند دربارهٔ اطلاعات موردنیاز هر درخواست، مسئول پیگیری و معنی وضعیت‌ها به توافق برسند؛ برای نمونه، مشخص کنند چه کسی و چه زمانی وضعیت را تغییر می‌دهد.
۳. درخواست و تأیید مرخصی
در این مثال، فرم کارمند و صفحهٔ تصمیم‌گیری مدیر کنار هم دیده می‌شوند. همین دو طرح زمینهٔ گفت‌وگو دربارهٔ نقش‌ها، شرایط رد درخواست و جانشین مدیر را فراهم می‌کنند.
۶. نسخهٔ اول را کوچک و هدفمند انتخاب کنید#
در جلسات ایده‌های زیادی مطرح می‌شود: باشگاه مشتریان، گزارش‌های پیشرفته، اتصال به سامانه‌های دیگر و ده‌ها مورد دیگر. فهرست‌کردن ایده‌ها مفید است، اما ساخت هم‌زمان همهٔ آن‌ها می‌تواند تصمیم و برآورد را دشوار کند. از خود بپرسید: «کدام امکانات برای حل مشکل اصلی ضروری‌اند و کدام‌ها می‌توانند بعداً بررسی شوند؟»
در مثال ما، اگر هدف کاهش نوبت تکراری باشد، نمایش زمان‌های آزاد، ثبت نوبت، امکان تغییر و دسترسی کارکنان پذیرش می‌توانند نامزدهای نسخهٔ اول باشند. گزارش‌های پیچیده یا امکانات تبلیغاتی ممکن است به مرحلهٔ بعد منتقل شوند؛ این فقط یک نمونه است و اولویت واقعی پس از بررسی مجموعه تعیین می‌شود.
برای هر مورد، در یک جدول ساده چهار چیز را بنویسید: نام امکان، مسئله‌ای که حل می‌کند، شخص استفاده‌کننده و دلیل اولویت. موارد نامشخص را با برچسب «نیازمند بررسی» نگه دارید. همچنین توافق کنید چه چیزهایی در نسخهٔ اول نیستند تا بعداً برداشت‌های متفاوت ایجاد نشود.
۷. هزینه و زمان چگونه قابل برآورد می‌شوند؟#
دو نرم‌افزار که ظاهراً هر دو «نوبت‌دهی» دارند، ممکن است از نظر تعداد کاربران، قوانین ثبت نوبت، اتصال به پیامک، گزارش‌ها، سطح دسترسی و نیاز به پشتیبانی کاملاً متفاوت باشند. بنابراین تنها با نام پروژه نمی‌توان هزینه یا زمان قابل اتکا تعیین کرد.
فاز صفر کمک می‌کند برآورد بر پایهٔ مسیرها و امکانات روشن‌تری تهیه شود. با این حال، بعضی سؤال‌ها تا بررسی فنی یا دریافت مستندات سرویس‌های دیگر باز می‌مانند. در پیش‌فاکتور بخواهید فرض‌ها، موارد خارج از محدوده، هزینه‌های جداگانه و میزان اطمینانِ برآورد مشخص شوند.
- محدوده: چه صفحه‌ها، نقش‌ها و فرایندهایی در پیشنهاد آمده‌اند؟
- اتصال‌ها: آیا پیامک، پرداخت، حسابداری یا سرویس دیگری باید متصل شود و دسترسی و مستندات آن موجود است؟
- بستر و کیفیت: استفاده از مرورگر یا اپلیکیشن، تعداد کاربران، دسترس‌پذیری، امنیت و آزمون چه سطحی نیاز دارد؟
- پس از راه‌اندازی: هزینهٔ سرور، دامنه، پیامک، پشتیبانی، نسخه‌های پشتیبان و توسعهٔ بعدی با چه کسی است؟
زمان اجرای فاز صفر و ساخت برای همه یکسان نیست. دربارهٔ زمان جلسه‌ها، زمان لازم برای تصمیم‌گیری مدیر، تحویل اطلاعات و بازبینی‌ها نیز توافق کنید؛ تأخیر در این بخش‌ها می‌تواند برنامهٔ پروژه را تغییر دهد. برای انتخاب میان نرم‌افزار آماده و اختصاصی، تفاوت هزینه، انعطاف‌پذیری و نیازهای کسب‌وکار را هم بررسی کنید. اگر ایدهٔ شما اپلیکیشن موبایل است، راهنمای هزینهٔ ساخت اپلیکیشن و عوامل مؤثر بر آن به بررسی جزئیات برآورد کمک می‌کند.
۸. پیش از قرارداد، خروجی و مسئولیت‌ها را روشن کنید#
قرارداد خوب باید برای هر دو طرف قابل فهم باشد و به خروجی‌های مورد توافق اشاره کند. به جای عبارت کلی «ساخت نرم‌افزار کامل»، معلوم کنید کدام فرایندها، نقش‌ها، صفحه‌های اصلی و اتصال‌ها جزو کار هستند. اگر سند تحلیل و وایرفریم‌ها بخشی از توافق‌اند، نسخهٔ مورد تأیید و روش تغییر آن را مشخص کنید.
دربارهٔ این موارد نیز گفتگو کنید:
- پرداخت‌های مرحله‌ای و شرط هر پرداخت؛
- زمان‌بندی و وابستگی‌ها؛
- معیار پذیرش هر تحویل؛
- روش ثبت و برآورد تغییرات؛
- وضعیت مالکیت و مجوز استفاده از کد و طرح؛
- محل نگهداری اطلاعات و دسترسی‌ها؛
- آموزش، پشتیبانی، رفع خطا و هزینه‌های پس از تحویل.
مفاد حقوقی را متناسب با پروژه با فرد متخصص بررسی کنید.
مثلاً برای قابلیت ثبت نوبت، یک معیار پذیرش روشن می‌تواند این باشد: «پذیرش بتواند زمان آزاد را انتخاب کند و پس از ثبت موفق، نوبت را در فهرست همان روز ببیند.» سپس دربارهٔ حالت هم‌زمانی، خطا و سطح دسترسی هم توافق شود. این معیار به مدیر و تیم کمک می‌کند بدانند چه چیزی را باید بررسی کنند.
۹. ساخت و آزمایش را مرحله‌به‌مرحله دنبال کنید#
بعد از توافق بر محدوده، ساخت می‌تواند در چند تحویل قابل بررسی پیش برود. در هر مرحله مشخص کنید چه چیزی آماده است، چه مواردی هنوز انجام نشده و چه کسی بازخورد را جمع می‌کند. مدیر لازم نیست کد بخواند؛ کافی است سناریوهایی را که پیش‌تر توافق شده‌اند با همراهی کاربران واقعی اجرا کند.
در مثال نوبت‌گیری، از یک کارمند پذیرش بخواهید نوبت نمونه ثبت کند، آن را تغییر دهد و نتیجه را در فهرست روز ببیند. سپس حالت‌هایی مانند انتخاب زمان پر یا واردکردن اطلاعات ناقص را بررسی کنید. با دادهٔ نمونه کار کنید و نتیجهٔ هر آزمون را ثبت کنید: «انجام شد»، «خطا دارد» یا «نیاز به تصمیم دارد».
بازخورد را تا جای ممکن دقیق بنویسید: «در صفحهٔ ثبت نوبت، پس از انتخاب ساعت ۱۰ و زدن ثبت، نوبت در فهرست دیده نشد.» این جمله از «نرم‌افزار مشکل دارد» برای پیگیری مفیدتر است. تغییر ایدهٔ اولیه یا افزودن امکان تازه را هم ثبت کنید تا اثر آن بر هزینه و زمان بررسی و تأیید شود.
۱۰. تحویل، آموزش و ادامهٔ کار را از ابتدا ببینید#
روز تحویل فقط روز نمایش نرم‌افزار نیست. باید معلوم باشد چه چیزی تحویل شده، چگونه از آن استفاده می‌شود و اگر بعداً مشکلی پیش آمد، مسیر ارتباط و پشتیبانی چیست. پیش از پذیرش نهایی، سناریوهای توافق‌شده را مرور کنید و موارد باز را با مسئول و زمان پیگیری ثبت کنید.
فهرست تحویل متناسب با قرارداد می‌تواند شامل دسترسی‌های مدیریتی، مستندات استفاده، آموزش کارکنان، محل استقرار، روش پشتیبان‌گیری و بازیابی، جزئیات سرویس‌های متصل و مدارک مربوط به کد یا مجوزها باشد. دسترسی‌های حساس را از مسیر امن و مطابق توافق تحویل بگیرید؛ اطلاعات واقعی کاربران را فقط با هماهنگی وارد محیط عملیاتی کنید.
برای شروع کار واقعی، مسئول معرفی کاربران، ورود داده‌ها، پاسخ‌گویی به سؤال کارکنان و اعلام مشکلات را تعیین کنید. همچنین مشخص کنید گزارش خطا چگونه ارسال می‌شود و درخواستِ قابلیت جدید چه مسیری برای بررسی و توافق دارد.
۱۱. از همین امروز چه چیزی برای جلسهٔ اول آماده کنیم؟#
برای جلسهٔ اول، لازم نیست فهرست کاملی از صفحه‌ها یا فناوری‌ها داشته باشید. این چند مورد را در یک برگه آماده کنید:
- مسئله: مهم‌ترین مشکلی که می‌خواهید حل کنید، با یک مثال واقعی.
- افراد: کسانی که امروز این کار را انجام می‌دهند و کسانی که بعداً از نرم‌افزار استفاده می‌کنند.
- مسیر فعلی: یک فرایند پرتکرار از شروع تا پایان، همراه با دو حالت استثنایی.
- هدف: پس از راه‌اندازی، چه تغییری را می‌خواهید ببینید و چگونه آن را بررسی می‌کنید؟
- محدودیت‌ها و پرسش‌ها: بودجه یا زمان تقریبی، سامانه‌های موجود و مواردی که هنوز نمی‌دانید.
در پایان جلسه بپرسید: «آیا برداشت شما از مسئلهٔ ما درست است؟ برای روشن‌ترشدن نیاز چه کسانی باید حضور داشته باشند؟ خروجی فاز صفر دقیقاً چه خواهد بود و چه زمانی دربارهٔ ساخت تصمیم می‌گیریم؟» پاسخ‌ها را ثبت کنید و نسخهٔ قابل فهم آن را با تیم به اشتراک بگذارید.
پرسش‌های پرتکرار دربارهٔ سفارش نرم‌افزار#
فاز صفر هزینه و زمان جداگانه دارد؟
معمولاً بله؛ چون کار واقعی پروژه — گفتگو، تحلیل و طراحی اولیه — در همین مرحله انجام می‌شود و خروجی مکتوب تحویل می‌دهد. سهم آن نسبت به هزینهٔ کل پروژه معمولاً کوچک است و در صورت ادامهٔ ساخت، اغلب در قرارداد اصلی لحاظ می‌شود. مهم این است که خروجی‌ها و هزینهٔ این مرحله را پیش از شروع، مکتوب بگیرید.
اگر از هوش مصنوعی فهرست امکانات گرفته‌ایم، باز هم فاز صفر لازم است؟
بله. آن فهرست ورودی خوبی برای گفتگوست، اما نمی‌گوید کدام موارد به مشکل «شما» مربوط‌اند. فهرست هوش مصنوعی نشان می‌دهد چه چیزی ممکن است وجود داشته باشد؛ فاز صفر روشن می‌کند چه چیزی برای شما لازم است.
می‌شود فاز صفر را حذف کرد و مستقیم ساخت را شروع کرد؟
می‌شود، ولی بهای آن روشن است: برآوردِ بر پایهٔ حدس، دوباره‌کاری پرهزینه در میانهٔ مسیر و اختلاف بر سر «منظورم این نبود». برای پروژه‌های خیلی کوچک گاهی نسخهٔ فشردهٔ آن — یک جلسهٔ متمرکز و چند طرح ساده — کافی است؛ حذف کاملش توصیه نمی‌شود.
اگر بعد از فاز صفر خواستیم ادامه ندهیم، چه می‌شود؟
خروجی‌های این مرحله — سند تحلیل، وایرفریم‌ها و اولویت‌ها — مال شماست. می‌توانید با هر تیم دیگری ادامه دهید یا بعداً از همان نقطه دوباره شروع کنید؛ ارزش اصلی فاز صفر همین است که تصمیم به ادامه را ارزان و آگاهانه می‌گیرید.
مدیر فنی نیستم؛ در جلسات فاز صفر چه نقشی دارم؟
مهم‌ترین نقش. شما تنها کسی هستید که مشکل، مشتریان و شیوهٔ واقعی کار مجموعه را از تجربه می‌شناسید. انتظار داشته باشید تیم، پرسش‌ها را به زبان شما بپرسد و جمع‌بندی‌ها را بدون اصطلاح فنی ارائه کند؛ همین معیار خوبی برای انتخاب همکار است.
اگر برای تحلیل مسیر یا ساخت سامانه نیاز به همراهی دارید، می‌توانید دربارهٔ خدمات نرم‌افزار اختصاصی آشیانه پارس و خدمات طراحی اپلیکیشن اطلاعات بیشتری ببینید. انتخاب درست از یک گفتگوی روشن و مسئلهٔ مشخص آغاز می‌شود؛ نه از یک فهرست طولانی امکانات.
