صنعت پرداخت یکی از حساسترین حوزههای توسعه نرمافزار است؛ حوزهای که در آن نرمافزار مستقیماً با پول و اطلاعات حساس کاربران سروکار دارد و یک خطای فنی میتواند پیامدهای مالی و اعتباری به همراه داشته باشد. در چنین فضایی، توسعه محصول تنها به تولید قابلیتهای جدید محدود نمیشود و موضوعاتی مانند امنیت، پایداری، مدیریت خطا، تجربه کاربر و مقیاسپذیری، بخش مهمی از فرایند توسعه را تشکیل میدهند.
به بهانه روز برنامهنویس، حامد کاشی، مدیر ارشد توسعه محصول شرکت پرداخت الکترونیک پاسارگاد، در گفتوگو با راه پرداخت از تجربه خود در توسعه محصولات پرداختی، تفاوتهای این صنعت با سایر حوزههای نرمافزاری، نحوه تصمیمگیری در توسعه محصول و نقش فناوریهای جدید در آینده برنامهنویسی گفت.
از تجربه نرمافزاری تا ورود به صنعت بانکداری و پرداخت
حامد کاشی فعالیت حرفهای خود در حوزه فناوری را از سال ۱۳۸۶ و با انجام پروژههای نرمافزاری برای کسبوکارهای کوچک آغاز کرد. او که کارشناسی ارشد فناوری اطلاعات با گرایش تجارت الکترونیک دارد، در ادامه مسیر حرفهای خود در حوزه توسعه محصول، مدیریت Product Ownerها، UI/UX و هدایت تیمهای توسعه نرمافزار فعالیت کرد.
یکی از تجربههای مهم در مسیر کاری کاشی، دوران فعالیت او در بخش IT و توسعه ارتش در کنار تیم شرکت توسن بود؛ دورهای که همزمان با توسعه و راهاندازی بانک حکمت، زمینه آشنایی نزدیکتر او با صنعت بانکداری و پرداخت را فراهم کرد.
کاشی درباره این دوره گفت: «این تجربه، نقطه ورود جدی من به صنعت بانکداری و پرداخت و آشنایی نزدیک با چالشهای این حوزه بود.»
توسعه نرمافزار در صنعت پرداخت؛ جایی که اعتماد کاربر اهمیت دارد
حامد کاشی تفاوت توسعه نرمافزار در صنعت پرداخت با سایر حوزهها را ناشی از سطح حساسیت و ریسک بالاتر این صنعت دانست. در این حوزه، نرمافزار مستقیماً با پول و اطلاعات حساس کاربران در ارتباط است و به همین دلیل، امنیت، پایداری، صحت تراکنش، جلوگیری از مغایرت و مدیریت خطا اهمیت بیشتری پیدا میکند.
او در این زمینه گفت: «به نظر من تفاوت اصلی برنامهنویسی در صنعت پرداخت، در سطح حساسیت و ریسک آن است. اینجا نرمافزار مستقیماً با پول و اطلاعات حساس کاربران سروکار دارد؛ بنابراین امنیت، پایداری، صحت تراکنش، جلوگیری از مغایرت و مدیریت خطا اهمیت بسیار بیشتری دارد.»
به گفته کاشی، تیمهای توسعه در صنعت پرداخت نمیتوانند تنها سناریوی موفق را در طراحی سیستمها در نظر بگیرند و باید از ابتدا برای شرایطی مانند اختلال سرویس، تراکنشهای تکراری و مغایرتهای مالی آماده باشند.
او افزود: «در پرداخت، فقط سناریوی موفق مهم نیست؛ باید از ابتدا برای قطعی سرویس، Timeout، Retry، تراکنشهای تکراری و مغایرت هم طراحی داشته باشیم.»
محصول موفق، مسئله واقعی کاربر را حل میکند
کاشی در تعریف یک محصول موفق، تعداد قابلیتها را معیار اصلی نمیدانست و حل یک مسئله واقعی برای کاربر را نقطه شروع توسعه محصول عنوان کرد.
او گفت: «به نظر من محصول موفق الزاماً محصولی نیست که بیشترین قابلیت را داشته باشد؛ محصول موفق محصولی است که یک مسئله واقعی را برای کاربر حل کند و برای کسبوکار هم ارزش ایجاد کند.»
به گفته او، شناخت درست مسئله، تجربه کاربر و امکان ایجاد ارزش و مقیاس برای کسبوکار، سه عامل مهم در توسعه محصول هستند و تکنولوژی باید در خدمت این سه موضوع قرار گیرد.
توسعه هر قابلیت جدید، همیشه به معنای بهتر شدن محصول نیست
در فرآیند توسعه محصول، اضافه کردن هر قابلیت جدید الزاماً به معنای ایجاد ارزش بیشتر نیست. کاشی توضیح داد که پیش از توسعه هر Feature باید مشخص شود این قابلیت چه مسئلهای را حل میکند و چه ارزشی برای کاربر یا کسبوکار ایجاد خواهد کرد.
او گفت: «قبل از توسعه هر Feature باید ببینیم چه مسئلهای را حل میکند و چه ارزشی ایجاد میکند. اگر ارزش آن برای کاربر یا کسبوکار مشخص نباشد، حتی اگر از نظر فنی جذاب باشد، ترجیح میدهم توسعه داده نشود.»
او افزود: «به نظرم یکی از وظایف مهم مدیر توسعه محصول این است که بتواند به بعضی درخواستها «نه» بگوید و منابع تیم را روی مسائل با ارزش بالاتر متمرکز کند.»
تصمیمگیری محصول؛ ترکیب داده، بازخورد کاربر و امکانپذیری فنی
کاشی در فرآیند تصمیمگیری برای توسعه محصول، تکیه صرف بر داده یا بازخورد کاربران را کافی نمیداند. از نگاه او، هرکدام از این دو ابزار بخشی از مسئله را مشخص میکنند.
او در این زمینه توضیح داد: «به نظرم هیچکدام به تنهایی کافی نیستند. Feedback کاربر به ما میگوید چه مسئلهای وجود دارد و داده کمک میکند اندازه و اهمیت آن مسئله را بسنجیم.»
به گفته کاشی، تصمیم نهایی در توسعه محصول باید بر اساس ترکیبی از شناخت کاربر، داده، اهداف کسبوکار و امکانپذیری فنی گرفته شود.
در صنعت پرداخت، خطا فقط یک خطای نرمافزاری نیست
مدیر ارشد توسعه محصول شرکت پرداخت الکترونیک پاسارگاد در توضیح تفاوت توسعه نرمافزار در صنعت پرداخت با سایر حوزهها گفت: «در صنعت پرداخت، برنامهنویس باید نگاهش از «کد درست» به «سیستم قابل اعتماد» تغییر کند. یعنی فقط به سناریوی موفق فکر نکند و از ابتدا برای خطا، قطعی سرویس، تراکنش تکراری، Timeout و مغایرت مالی راهکار داشته باشد.»
به گفته او، یک خطای نرمافزاری در پرداخت میتواند مستقیماً به خطای مالی و از بین رفتن اعتماد کاربر منجر شود.
مقیاسپذیری باید از مرحله طراحی وارد ذهن تیم شود
کاشی مقیاسپذیری را موضوعی نمیدانست که پس از رشد محصول و مواجهه با محدودیتهای فنی به آن پرداخته شود. به گفته او، این موضوع باید از همان ابتدای طراحی و هنگام تعریف مسئله وارد فرآیند توسعه شود.
او در این زمینه توضیح داد: «مقیاسپذیری باید از مرحله طراحی و مطرح کردن خود مسئله توسط تیم محصول یا کسبوکار، وارد ذهن برنامهنویس شود، نه زمانی که سیستم با مشکل مواجه شده است.»
سرعت توسعه و پایداری محصول در مقابل هم نیستند
در محصولات پرداختی، سرعت عرضه به بازار اهمیت زیادی دارد، اما این موضوع نباید به قیمت کاهش پایداری و کیفیت محصول تمام شود. کاشی معتقد است سرعت و پایداری دو مفهوم مقابل هم نیستند و میتوان میان این دو تعادل ایجاد کرد.
او توضیح داد: «به نظر من سرعت و پایداری در مقابل هم نیستند. ترجیح میدهم محصول را ابتدا در قالب یک MVP با سرعت بالا و در مقیاس محدود لانچ کنیم، اما از ابتدا معماری آن را بهگونهای طراحی کنیم که قابلیت مقیاسپذیری داشته باشد.»
به گفته او، این رویکرد کمک میکند محصول با ریسک کمتر در بازار واقعی آزمایش شود و در صورت موفقیت، امکان توسعه آن در مقیاس بزرگتر فراهم شود.
کاشی افزود: «به این شکل، با کمترین ریسک محصول را در بازار واقعی validate میکنیم و اگر MVP موفق بود، میتوانیم با اطمینان آن را به شکل عمومی و در مقیاس بزرگتر عرضه کنیم.»
کیفیت محصول فقط به چیزی که کاربر میبیند محدود نیست
کاشی معماری، امنیت، پایداری، عملکرد، مانیتورینگ و مدیریت خطا را از عوامل اثرگذار بر کیفیت محصول عنوان کرد. او همچنین هماهنگی میان تیمهای توسعه، محصول و دیزاین را یکی از عوامل مهم در ایجاد یک محصول باکیفیت دانست.
او گفت: «مواردی مثل معماری، امنیت، پایداری، Performance، مانیتورینگ و مدیریت خطا و از همه مهمتر هماهنگی تیمهای توسعه با محصول و دیزاین ارائهشده، روی کیفیت محصول تأثیر دارند.»
کاشی اضافه کرد: «کاربر ممکن است فقط یک صفحه ساده و یک دکمه پرداخت ببیند، اما اینکه همان پرداخت در شرایط بار بالا، قطعی سرویس یا خطا هم درست و قابل اعتماد انجام شود، نتیجه کیفیت همین بخشهای پشتصحنه است.»
مشاهدهپذیری باید از ابتدای طراحی محصول در نظر گرفته شود
مدیر ارشد توسعه محصول شرکت پرداخت الکترونیک پاسارگاد درباره اهمیت مانیتورینگ و مشاهدهپذیری در محصولات پرداختی توضیح داد: «در صنعت پرداخت، باید از همان زمان طراحی بدانیم چه شاخصهایی را باید پایش کنیم، خطاها را چطور تشخیص دهیم و وضعیت تراکنشها را چطور ردیابی کنیم.»
به گفته او، توجه به مشاهدهپذیری از ابتدای طراحی کمک میکند عملکرد محصول پس از انتشار نیز بهصورت مستمر بررسی و بهبود پیدا کند.
بازطراحی یا بازنویسی سیستم؛ تصمیمی که باید با دقت گرفته شود
بازطراحی یا بازنویسی یک سیستم همیشه اولین راهحل برای رفع مشکلات فنی نیست. کاشی معتقد است پیش از چنین تصمیمی باید هزینهها، ریسکها و همچنین اعتبار مسئلهای که سیستم برای حل آن ساخته شده، بررسی شود.
او در این زمینه توضیح داد: «وقتی هزینه و ریسک ادامه توسعه از هزینه و ریسک بازطراحی بیشتر شود، باید به بازطراحی یا بازنویسی فکر کنیم.»
به گفته کاشی، ممکن است در برخی موارد، مسئله اصلی کسبوکار یا هدف محصول تغییر کرده باشد و ادامه توسعه روی سیستم فعلی دیگر توجیهی نداشته باشد. به همین دلیل، پیش از هر تصمیمی باید مشخص شود آیا مسئلهای که سیستم برای آن ایجاد شده، همچنان وجود دارد یا خیر.
او همچنین بازطراحی تدریجی را رویکرد مناسبتری برای بسیاری از سیستمها دانست و گفت: «اگر مسئله همچنان معتبر باشد، ترجیح میدهم تا جای ممکن بهصورت تدریجی و بخشبهبخش سیستم را بازطراحی کنیم، نه اینکه الزاماً از ابتدا Rewrite کامل انجام دهیم.»
API خوب باید در شرایط خطا هم رفتار قابل اعتماد داشته باشد
کاشی در توضیح ویژگیهای یک API مناسب در صنعت پرداخت گفت: «به نظرم خیلی خلاصه میشود: API خوب، APIای است که در شرایط عادی و حتی در زمان خطا، رفتار مشخص و قابل اعتمادی داشته باشد.»
هوش مصنوعی شیوه کار برنامهنویسان را تغییر میدهد
هوش مصنوعی در حال تغییر فرایند توسعه نرمافزار است، اما کاشی این تغییر را به معنای حذف نقش برنامهنویسان نمیداند.
کاشی در این زمینه توضیح داد که تولید کد، Unit Test، مستندسازی و بررسی خطا از جمله بخشهایی هستند که میتوانند با کمک هوش مصنوعی با سرعت بیشتری انجام شوند.
او گفت: «به نظر من هوش مصنوعی بیشتر از اینکه جای برنامهنویس را بگیرد، شیوه کار او را تغییر میدهد. کارهایی مثل تولید کد، Unit Test، مستندسازی و بررسی خطا میتواند با کمک AI سریعتر انجام شود.»
به گفته او، نقش برنامهنویس در این شرایط بیشتر به سمت حل مسئله، طراحی، تصمیمگیری فنی و بررسی کیفیت خروجی هوش مصنوعی حرکت میکند.
کاشی تأکید کرد: «در صنعت پرداخت، خروجی AI باید حتماً توسط سرپرست یا مدیر فنی بررسی و تأیید شود.»
اعتماد به کد تولیدشده توسط هوش مصنوعی محدودیت دارد
استفاده از هوش مصنوعی در تولید کد، بهویژه در حوزههایی مانند پرداخت که با امنیت، تراکنش مالی و احراز هویت سروکار دارد، نیازمند بررسی و کنترل انسانی است.
کاشی درباره مرز اعتماد به خروجیهای تولیدشده توسط AI توضیح داد که هر کدی که روی بخشهای حساس سیستم اثرگذار باشد، باید توسط افراد متخصص بررسی شود.
او گفت: «هر کدی که روی امنیت، تراکنش مالی، احراز هویت یا منطق حساس سیستم تأثیر دارد، باید توسط سرپرست یا مدیر فنی Review و تست شود.»
او افزود: «در نهایت مسئولیت کیفیت و صحت محصول با تیم توسعه است، نه با AI.»
برنامهنویس صنعت پرداخت باید کسبوکار را بشناسد
ورود به صنعت پرداخت تنها به یادگیری زبانهای برنامهنویسی محدود نمیشود. از نگاه کاشی، شناخت فرآیندهای کسبوکار، منطق پرداخت و نحوه گردش تراکنشها، بخش مهمی از مهارتهای موردنیاز برنامهنویسان این حوزه است.
او در پایان توضیح داد که یک برنامهنویس در صنعت پرداخت باید بداند تراکنش از چه مسیری عبور میکند و در شرایط خطا چه اتفاقی برای آن رخ میدهد.
کاشی گفت: «به نظر من مهمترین مهارت، درک درست از منطق کسبوکار و فرآیندهای پرداخت است. برنامهنویس باید بداند تراکنش از کجا شروع میشود، چه مسیری را طی میکند و در شرایط خطا چه اتفاقی میافتد.»
او ادامه داد: «در کنار آن، امنیت و تفکر سیستمی هم اهمیت زیادی دارد؛ چون در صنعت پرداخت، برنامهنویس فقط کد تولید نمیکند، بلکه بخشی از یک اکوسیستم مالی حساس را توسعه میدهد.»
