چالش‌های مواجهه با پروژه‌های ناگهانی با تعهدات گسترده، ابهامات زیاد و مهلت محدود

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

زمانه در حال تغییر!

سال ۱۳۹۸، هنگامی که در تیم «پرداخت مدرن» داتین مشغول اجرای مراحل تحلیل شکاف و بومی‌سازی سامانه درگاه پرداخت اینترنتی بودیم، ناگهان ساختار سازمانی و نحوه تخصیص پروژه‌ها در شرکت داتین دستخوش تغییرات شد و یک پروژه جدید با مقیاسی بزرگ به تیم ما اختصاص یافت. به زبان ساده، پروژه جدید عبارت بود از مهاجرت تمامی سامانه‌های قدیمی یک بانک به بستر جدید، بدون اینکه مشتریان بانک، کوچکترین تغییری را در کار با سامانه‌های جدید حس کنند. پیش از واگذاری این مسئولیت جدید، تیم پرداخت مدرن در قالب یک گروه چهار نفره فعالیت می‌کرد. در آن زمان پس از تکمیل فاز تحلیل سامانه درگاه پرداخت اینترنتی (IPG) و پرداخت الکترونیک (E-payment)، در حال انجام فاز بومی‌سازی برای بانک‌های هدف بودیم و به لحاظ عملکردی پیشرفت قابل قبولی داشتیم. پس از تخصیص این پروژه، اهمیت مسئولیت جدید به میزانی بود که حتی نام و حوزه فعالیت تیم ما، به «بانکداری باز» تغییر کرد. با توجه به حساسیت پروژه، تعدد سامانه‌های مشمول مهاجرت و حجم مسئولیت‌های پیشین، حدس می‌زدیم که با تعداد نفرات موجود، در پیشبرد کار دچار مشکل شویم. علاوه‌بر مشکل کمبود همکار، نامشخص بودن محدوده دقیق تحویل پروژه نیز بر ابهام‌ها اضافه می‌کرد. به همین دلیل، نیاز بود فاز تحلیل شکاف انجام شود که به نوبه‌ خود فرایند حیاتی و زمان‌بری بود. منظور از تحلیل شکاف در پروژه‌های نرم‌افزاری، بررسی فرایندهای کاری فعلی از یک طرف و انجام نیازمندی‌های عملیاتی برای بهبود کسب‌وکار در بانک هدف از طرف دیگر است.
در اثر انجام فاز تحلیل شکاف، می‌توان به طرحی دست یافت که در حقیقت نقشه راه فرایند توسعه نرم‌افزار خواهد بود. انجام این فاز در این پروژه به‌علت جدید بودن معماری آن و محدودیت زمانی، دشواری‌های خاص خود را داشت و نباید فراموش کنیم، این شرایط جدید همزمانی داشت با تعهدات قبلی ما. در نتیجه موظف بودیم مطابق قرارداد و زمان‌بندی از پیش تعیین‌شده، تعداد قابل توجهی وب‌سرویس را آماده تحویل کنیم. درهم تنیدگی و پیچیدگی‌ها موجود، همه و همه بیانگر این موضوع بود که تیم ما در انجام مسئولیت جدیدش با عدم قطعیت و چالش‌ قابل ملاحظه‌ای دست و پنجه نرم خواهد کرد.

کوچک بودن تیم، حجم کارها در فاز تحلیل، به‌دست آوردن رضایت مشتریان از رابط کاربری سامانه و محدودیت زمانی تحویل پروژه، از جمله مشکلاتی بود که در این مسیر داشتیم.

زیر باران باید رفت!

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

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

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

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

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

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

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

آری به یُمْنِ لطفِ شما خاک زر شود!

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