فراز و نشیب تعامل با کارفرما در پروژه‌های بزرگ‌مقیاس نرم‌افزاری

جمله مهمی از پیتر دراکر[1] وجود دارد که می‌گوید: «مهم‌ترین نکته در ارتباط، شنیدن چیزی است که گفته نمی‌شود!». این نکته مهم در بسیاری از پروژه‌های نرم‌افزاری بزرگ وجود دارد. این نوع پروژه‌ها ممکن است چالش‌ها و ابهاماتی داشته باشند که برای موفقیت آنها، تعامل صحیح و اصولی با ذی‌نفعان و توافق بر سر اقدامات لازم، گریزناپذیر است. همواره باید توجه داشت که هیچ‌گاه نمی‌توان از موفقیت کامل یک پروژه، بدون انجام تست، ارزیابی و رفع نقایص اطمینان حاصل کرد. به عبارت دیگر، موفقیت پروژه تنها با تأیید محصول مطابق با انتظارات مشتری حاصل می‌شود.

علاج واقعه قبل از وقوع!

اواسط سال ۱۳۹۸، هنگامی که شرکت ما درگیر اجرای یک پروژه بزرگ‌مقیاس استقرار بانکداری متمرکز بود، پروژه دیگری با هدف ادغام چند بانک دیگر در بانک اصلی در حال جریان بود که نهایتا شرکت ما به‌عنوان مجری پروژه انتخاب شد. در آن زمان، من سرپرست تیم توسعه پلتفرم بانکداری متمرکز بودم و تخصیص پروژه ادغام به تیم ما، مسئولیت‌مان را دو چندان کرد. کسب موفقیت در این پروژه برای داتین بسیار مهم بود و تاثیر بسزایی در پروژه مهاجرت بانک اصلی داشت.

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

• ادغام سرویس‌های پرکاربرد شش بانک با یکدیگر و ارائه خدمات در شعب همه بانک‌ها
• چندفازه بودن پروژه و اضافه شدن خدمات طی سال‌های پیش‌ رو
• حجم داده‌ها و تعداد کاربران پروژه
• استانداردهای وضع‌شده برای سرویس‌های بانک‌ها
• دغدغه‌ها و نکات امنیتی
• محدودیت‌های زمانی پروژه

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

از انتخاب تا توافق روی معماری پروژه

بر مبنای داده‌های دریافتی از جلسات تحلیل و طراحی و همچنین استناد به مطالعات قبلی و مهمتر از همه، ترکیب و مدیریت سرویس‌های چندین بانک با پروتکل‌های متفاوت، به این نتیجه رسیدیم که تولید محصولی از جنس Enterprise Integrator برای این پروژه انتخاب مناسبی است. مواردی که در نیازمندی‌های مشتری وجود داشت، مانند وجود فازهای مختلف که در آینده خدمات بیشتری را به سامانه اضافه می‌کرد، استقرار و به‌روزرسانی سامانه در سریع‌ترین زمان ممکن و استقلال نسبی بخش‌های کسب‌وکاری آن، ذهن ما را به سمت استفاده از معماری مطرح آن روزها، یعنی Microservices سوق داد. تا آن ‌زمان مانند هر توسعه‌‌دهنده نرم‌افزار علاقه‌مند به مباحث روز دنیا، تنها از منظر تئوریک با این معماری آشنا بودیم و به‌صورت عملی و واقعی درگیر چالش‌های آن نشده بودیم. کمبود وقت دست ما را در بررسی عمیق ابعاد معماری Microservices بسته بود اما براساس نیازمندی‌ها و شواهد موجود به نظر می‌رسید که این معماری می‌تواند پاسخگوی نیاز ما باشد. هرچند که سعی کردیم با احتیاط بیشتری این معماری را انتخاب کنیم اما باید اعتراف کنم که به‌روز بودن این معماری و صحبت از آن در جای‌جای کامیونیتی توسعه نرم‌افزار توسط اکثریت صاحب‌نظران (علی‌رغم هشدارهای استفاده از آن) ما را به استفاده از این معماری ترغیب کرد. استقلال در استقرار هر مایکروسرویس برای ما بسیار حائز اهمیت بود، چرا که یکی از نیازمندی‌های کارفرما حذف، اضافه، توقف و به‌روزرسانی هر سرویس بانکی مستقل از سایر سرویس‌ها بود. اما جداسازی پایگاه داده‌‌های آن‌ها چالش‌هایی را برای ما به ارمغان داشت. در نهایت درمورد طرحی که ما آن را برداشتی آزاد از معماری Microservices می‌نامیم، به توافق رسیدیم.

ظهور چالش بزرگتر: مشکلات تعاملی با کارفرما

همزمان با تحقیق، بررسی و آموزش Spring Cloud، سه فریم‌ورک مطرح شاملApache Camel، Spring Integration  و WSO2 Enterprise Integrator  نیز در دستور کار قرار گرفت تا اعضای تیم از جهات مختلف مانند بررسی Open Source بودن یا نبودن، وضعیت توسعه در گیت‌هاب از نظر بازه زمانی تغییرات، تعداد Issueها (بالاخص باگ) و Pull Requestها، سطح محبوبیت، پیچیدگی فراگیری و مواردی از این دست، آن‌ها را بررسی کنند. نتیجه‌ بررسی‌ها ما را متقاعد کرد تا  Apache Camel را به عنوان فریم‌ورک Integrator خود انتخاب کنیم.

طرح کلی معماری به همراه ابزارها و فریم‌ورک‌ها مشخص شده بودند و مقرر شد برای استقرار پروژه نیز از Docker Swarm استفاده شود. هرچند که دانش نسبی Docker در تیم وجود داشت اما به دلیل عدم وجود نیروی کافی در تیم و زمان محدود پروژه، تصمیم گرفتم برای این موضوع از تیم دیگری در داتین کمک بگیرم که خوشبختانه با پاسخ مثبت آن‌ها، دغدغه عملیات استقرار پروژه از تیم کاسته شد. از فضای فنی پروژه که کمی فاصله بگیریم، من در نقش مدیرمحصول، جلسات متعددی با کارفرما برگزار می‌کردم. در یکی از جلسات، به درخواست کارفرما، طراحی و معماری پروژه تشریح شد. این جلسه، آغازی بود بر اختلاف نظری که تا انتهای کار همراه ما بود. در آن جلسه که من روی قسمتی از معماری با یکی از مدیران پروژه از سمت کارفرما وارد بحث شده بودم، کم تجربگی به خرج دادم و باعث دلخوری و ایجاد تنش در جلسه شدم. این مسئله رخ داده بود و کمی کار ما را در تعاملات با کارفرما که یکی از ارکان اساسی تولید یک محصول نرم‌افزاری است، دچار اختلال کرد.

تولید این محصول وابسته به تعاملات فنی و غیرفنی با تمامی بانک‌های ادغامی بود. از برگزاری جلسات تحلیل سرویس‌های مورد نیاز تا تحویل آن‌ها بر بستر تستی و تعامل با نماینده‌‌های فنی معرفی‌شده، همه باید توسط تیم تولید مدیریت می‌شدند. یکی از چالش‌های ما در مسیر اجرای پروژه، وجود مشکلاتی در محیط تستی بود که به نظر می‌رسید به‌علت ابعاد گسترده پروژه، توجه زیادی به آن نمی‌شد. عدم ارائه سرویس‌های مورد نیاز براساس استاندراد تدوین‌شده نیز مشکل را دوچندان کرده بود. به دلیل وجود چنین مسائلی، درخواست کردیم که عملکرد سرویس‌های تحویل‌شده از سوی ذی‌نفعان تست، ارزیابی و تأیید شود. اما این درخواست‌ در مقاطع مختلف، با توجه کافی همراه نبود و اغلب آن را به اجرا در محیط اصلی موکول می‌کردند. بنابراین، ما پیش‌بینی می‌کردیم که هنگام اجرای اصلی سامانه، مشکلات جدی بروز خواهد کرد. اصرار و درخواست‌های ما راه به جایی نمی‌برد و تست‌ها آن‌گونه که باید، توسط کارفرما به‌درستی انجام نمی‌شدند و معمولاً با یک تائید ضمنی بدون پشتوانه همراه بودند.

شیرجه زدن در دریایی پر از کوسه‌های درنده!

یکی دیگر از چالش‌های پروژه، لزوم پرورش ایده‌ای برای طراحی «سامانه مغایرت‌گیری» بود. نه کارفرما و نه ما در ابتدا ایده‌ای برای چگونگی فرایند مغایرت‌گیری نداشتیم. در نهایت موظف شدیم خودمان برای این مسئله چاره‌ای بیندیشیم و آن را به کارفرما درقالب مستندات برای بررسی ارائه دهیم. ایده‌ها و طراحی‌هایی برای مغایرت‌گیری به شکلی کامل و مفصل به ذی‌نفعان ارائه شد که به‌طور خلاصه، بانک‌ها باید سرویس‌های جدیدی را برای انجام مغایرت‌گیری ارائه می‌کردند. با این حال، به‌نظر می‌رسید که این پیشنهادها نیز مورد توجه کافی قرار نگرفتند و در نتیجه، مستندات به‌درستی بررسی نشدند. همچنین، در محیط تستی، هیچ‌گونه بازخوردی به تیم توسعه ارائه نشد و تلاش‌ها برای آزمون و ارزیابی مستندات ناکام ماند. تنها جنبه مثبت ماجرا این بود که ذی‌نفعان پروژه مسئولیت عدم تست در محیط تستی و به تعویق انداختن آن تا روز اجرا را پذیرفته بودند. به عبارتی امیدوار بودیم که کارفرما اصطلاحاً «می‌داند که چه می‌کند!». اجرای بدون تست مساوی بود با شیرجه زدن در دریایی پر از کوسه‌های درنده!

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

در نهایت، با وجود تلاش‌های تیم توسعه، بدون هیچ‌گونه تستی در بخش مغایرت‌گیری، روز اجرا فرارسید. سامانه با مشارکت سه بانک راه‌اندازی شد. در این زمان هم با حضور کارفرما در شعب منتخب از رضایت آن‌ها از سامانه مطلع شدیم. من با اضطراب منتظر پایان ساعت کاری سامانه بودم تا بدانم بالاخره آن سرویس‌های مغایرت‌گیری وعده داده شده با سازوکار پیاده‌سازی شده توسط ما همخوانی دارد یا خیر؟ خیلی عجیب است، نه؟ تست مسئله‌ای با این سطح از حساسیت به راحتی هرچه تمام‌تر به روز راه‌اندازی اصلی موکول شده بود!

از طرف کارفرما فراخوانده شدیم!

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

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

لحظات سخت اما نتیجه شیرین بود

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

این تجربه، برای من خیلی مهم بود؛ اینکه تعامل صحیح و اصولی با کارفرما و توافق بر سر اقدامات لازم در پروژه از اهمیت بالایی برخوردار است و هیچ‌گاه نمی‌توان از موفقیت کامل پروژه مطمئن بود، مگر آنکه تمام تلاش‌ها برای تست، ارزیابی و رفع نقایص انجام شده باشد. اتفاقات رخ‌داده از زمان شروع توسعه تا اجرای سامانه، گواه این موضوع بود که به‌ویژه مشکلات تعاملی و نبود تفاهم بر سر روش‌های انجام کار، می‌تواند بحران‌هایی را در زمان تحویل پروژه به‌وجود آورد. اگر از ابتدا با برنامه‌ریزی و تحلیل شرایط برای نحوه تعامل با دیگران، روش مناسبی پیدا نشود، این امکان وجود دارد که چالش‌های ارتباطی و پاسخگویی و متعاقباً اختلال در پیشبرد پروژه به‌شدت افزایش یابد. بر اساس تجربه به‌دست‌آمده، اعتقاد راسخ پیدا کردم که یک مدیر محصول باید تا حد امکان مهارت‌های مذاکره و برقراری ارتباط را در خود تقویت و حتماً از مشاوره‌های افرادی با تجربه مشابه در تیم استفاده کند. همچنین، این تجربه نشان داد که مطابق گفته‌ پیتر دراکر یکی از ناگفته‌های مهم در تعاملات بین عوامل پروژه این است که هیچ محصولی نباید بدون تأیید رسمی مشتری اجرا شود، چون مشکلات اجرایی ممکن است فراتر از آن چیزی باشد که تیم توسعه بتواند پیش‌بینی‌اش کند.

[1] Peter Druker: از برجسته‌ترین نظریه‌پردازان مدیریت و استراتژی.