وقتی یک فرم ساده، ۲۰ روز زمان برد

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

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

پس از بررسی اولیه، زمان اجرای پروژه را ۲۰ روز کاری اعلام کردم. کارشناس فنی شرکت با تعجب پرسید:

«آیا ۲۰ روز برای طراحی یک فرم ساده زمان زیادی نیست؟»

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

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

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

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

اگر سریال دستگاه اشتباه وارد می‌شد، کاربر چند بار می‌توانست دوباره تلاش کند؟ اگر کد شناسه با سریال دستگاه مطابقت نداشت چه اتفاقی باید می‌افتاد؟ اگر پیامک ارسال نمی‌شد یا کاربر کد یک‌بارمصرف را چند بار اشتباه وارد می‌کرد، سیستم چه واکنشی باید نشان می‌داد؟ اگر یک سریال یا حساب به دلیل تلاش‌های ناموفق مسدود می‌شد، چگونه باید امکان بررسی و پیگیری آن وجود می‌داشت؟

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

از طرف دیگر، موضوع امنیت اطلاعات اهمیت زیادی داشت.

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

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

در پنل مدیریت، کارشناس مربوطه امکان مدیریت اطلاعات ثبت‌شده، ورود کدهای جدید، بررسی وضعیت کدها و مشاهده موارد اشتباه یا مسدودشده را داشت.

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

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

بنابراین سؤال اولیه کارشناس فنی کاملاً منطقی بود:

«آیا ۲۰ روز برای طراحی یک فرم ساده زیاد نیست؟»

پاسخ من نیز روشن بود:

«اگر واقعاً فقط یک فرم بود، بله؛ اما این پروژه فقط یک فرم نبود.»

درسی که این تجربه به من داد

این تجربه برای من یک نکته مهم را دوباره روشن کرد:

ظاهر ساده یک نرم‌افزار، لزوماً به معنی ساده بودن پروژه نیست.

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

چیزی که مشتری در ظاهر می‌بیند ممکن است فقط یک صفحه باشد، اما پشت همان صفحه ده‌ها فرآیند و منطق نرم‌افزاری قرار داشته باشد.

یکی از اشتباهات رایج در برآورد پروژه‌های نرم‌افزاری، تخمین پیچیدگی پروژه بر اساس چیزی است که کاربر در ظاهر می‌بیند.

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

در نهایت، چیزی که از این تجربه برای من باقی ماند این بود که زمان واقعی یک پروژه را نباید از روی ظاهر آن تخمین زد؛ باید ابتدا فهمید پشت آن ظاهر چه مسئله‌ای قرار دارد.