«پریدن تیک» یا وقتی یک «نرم افزار» برای کشور مشکل ایجاد می‌کند
چرا بعضی نرم‌افزارها به جای اینکه مشکلات رو حل کنند به مشکلات اضافه می‌کنند؟
مدتی پیش نوشته‌ای در روزنامه خراسان تحت عنوان «ترخیص کالا قربانی سامانه بی سامان گمرک» توجهم را جلب کرد. بخشی از این نوشته را با هم بخوانیم:
پریدن تیک از سامانه هم یکی از مواردی است که بسیاری از ترخیص کاران و کارشناسان گمرک با آن دست به گریبان‌اند و به دلیل همین مشکل ممکن است چندین روز بین اتاق‌های گمرک و دستگاه‌هایی مانند وزارت راه، استاندارد یا غذا و دارو در آمدوشد باشند....
باز هم سامانه کار دست صاحب کالا داده است. این جا صاحب کالا دو گزینه دارد یا باید ضرر چهار میلیونی را بابت یک روز معطلی۸ تریلر به جان بخرد یا ضررش را بر روی قیمت تمام شده اجناسش بکشد. علت را که می‌پرسم این جواب را می‌شنوم که تیک وزارت راه پریده است! بیشتر شبیه یک شوخی است. مگر می‌شود سامانه جامعی آن هم از آن مرزبان اقتصادی کشور چنین مشکل پیش پا افتاده‌ای داشته باشد و مجوزی که صادر شده پس از یک روز از بین برود؟!
نویسنده این گزارش، احتمالاً خبر ندارد که در نرم‌افزار همه چیز شدنی است! حتی پریدن تیک نرم‌افزار. در جایی از این گزارش اشاره می‌شود که هر روز معطلی کالا در گمرک معادل یک درصد ارزش کالا است. تصور کنید وجود یک نرم‌افزار کارآمد چقدر می‌تواند در تسهیل ورود و خروج کالا در گمرک اثرگذار باشد و برای اقتصاد داخلی سودمند باشد. در عین حال یک نرم‌افزار باگ دار می‌تواند ضررهای بزرگی را متوجه صاحبان کسب و کارها و مردم کند.
مشکل کجاست؟
دولت بزرگترین مشتری نرم‌افزار است. به دلیل گستردگی و تنوع فعالیت‌های دولتی، سازمان‌ها و بخش‌های مختلف دولت همواره نیازمند نرم‌افزار برای سرعت بخشیدن به کارها و افزایش دقت و شفافیت هستند. اما چه اتفاقی می‌افتد که نرم‌افزارهای تولید شده در داخل کشور، بعضاً با مشکلات متعددشان کارها را پیچیده‌تر می‌کنند؟ به گمان من چند عامل در این مساله نقش دارند که در نوشته‌های دیگری به آن‌ها خواهم پرداخت:
- طولانی بودن پروسه تصمیم‌گیری درباره نیازهای نرم‌افزاری: این یک داستان تکراری است. نرم‌افزاری سفارش داده می‌شود اما تا روال اداری عقد قرارداد و جلسات تحلیل طی شود و نرم‌افزار نوشته شود یا بر اساس یک محصول نرم‌افزاری در سازمان مستقر شود، نیازمندی‌ها و قوانین و مقررات تغییر می‌کنند!
- ضعف تحلیل نیازمندی‌ها: دنیای تجارت با دنیایی که در مثال‌های دانشگاهی ما بررسی می‌شود متفاوت است. نمونه‌هایی سراغ دارم از تحلیل‌های ناقص که باعث شده حتی یک نرم‌افزار دوباره از ابتدا نوشته شود! عدم شناخت فناوری‌های تولید نرم‌افزار (که ابزار تولید هستند)، عدم آشنایی کامل با روال گردش کارها و درک ناقص آن‌ها دو عاملی هستند که در کنار هم، آینده پروژه‌های نرم‌افزاری و توسعه آن که مهمتر و هزینه‌برتر از تولید ابتدایی هستند را با تهدید جدی روبرو می‌کنند.
تفاوت بین نگاه خوش بینانه تحلیلگران و واقعیت کار
- عدم توجه به تجربه کاربری: یکی از تلاش‌های ما در آرایه این است که نرم‌افزار دوست داشتنی ایجاد کنیم و به کاربرانی که ساعت‌ها با نرم‌افزارهای تولیدی ما کار می‌کنند کمک کنیم تا تجربه لذت بخشی از کار با نرم‌افزار داشته باشند. ما همواره در حال یادگیری اصول مرتبط با تجربه کاربری و استفاده از آن‌ها هستیم. به کارگیری این روش، موفقیتش را در استقرار ساده‌تر سامانه‌ها و رضایت مشتریان خودش را نشان داده است. خوشبختانه در چند سال اخیر به مبحث UX توجه بیشتری شده اما هنوز در ابتدای راه هستیم. به یاد دارم دوستانی که سایت‌های وزارت خانه‌ها و سازمان‌های دولتی و اپراتورها و ... را بررسی می‌کردند و می‌کنند. متاسفانه بسیاری از نرم‌افزارها و وب‌سایت‌های دولتی هنوز ابتدایی‌ترین اصول تجربه کاربری برای دنیای امروز را رعایت نمی‌کنند.
گاهی کار کردن با نرم‌افزارها چنان سخت و پیچیده است که کاربران حتی از همه امکانات نرم‌افزار اطلاع ندارد. - عدم استفاده از تست‌های نرم‌افزاری: هر جا سخن از باگ در میان است، نام عدم استفاده از Unit Test و Integration Test مناسب می‌درخشد! در این مورد شاید سری نوشته ۳۰ روز با TDD کمک کند. معتقدم عدم توجه شرکت‌های نرم‌افزاری و برنامه‌نویسان به موضوع تست، عواقب دردناکی برای آن‌ها و مشتریانشان به همراه دارد.
ساخت نرم‌افزار پیش از اصلاح فرآیندها: حالا که از ایرادات خودمان به عنوان تولیدکنندگان نرم‌افزار گفتیم، خوب است درباره مشکل بزرگ مشتریان نرم‌افزار (اعم از دولتی و خصوصی) هم بگوییم. خیلی وقت‌ها، نرم‌افزار ایجاد می‌شود تا همان روال کاغذی و سیستم سنتی اجرای کارها، ثبت کامپیوتر شود! این همیشه کارساز نیست و بعضی وقت‌ها، اتفاقاً نه تنها روال کاغذی را از بین نمی‌برد بلکه پروسه اجرای کارها را طولانی‌تر هم می‌کند.
در مورد دولت (به عنوان قوه مجریه که صرفاً مجری قوانین است) دست ما برای پیشنهاد اصلاح قوانین و مقررات باز نیست اما در بخش خصوصی، بررسی پروسه‌ها و حذف بخش‌های تکراری یا زائد پیش از اجرای نرم‌افزار، به بهتر شدن تجربه نرم‌افزاری می‌انجامد.
نظر شما چیست؟ در این مورد بیشتر صحبت خواهیم کرد.