در یک روز جمعه در زمستان 1399 و دقایقی پیش از حضور در یک جلسه کاری فوق‌العاده، در حال نوشیدن یک فنجان قهوه بودم که به یاد جمله‌ای از آن‌مورو لیندبرگ نویسنده فقید امریکایی افتادم: «برقراری ارتباط مؤثر مانند نوشیدن قهوه تلخ، انرژی‌زا، تأثیرگذار و البته به‌اندازه خوابیدن پس از مصرف آن، دشوار است». در حقیقت، دشواری و مشکل ایجادشده در برقراری ارتباط با ذی‌نفعان یک پروژه نرم‌افزاری بانکداری سبب شده بود که تلخی قهوه در آن جمعه خاص، به‌دلیل از بین رفتن برنامه تعطیلات آخر هفته، دو چندان شود. تلخی واقعه هنگامی بیشتر می‌شد که بدانیم دشواری در برقراری ارتباط، مربوط به برگزاری مانوری بود که برای پیشگیری از بروز بحران برنامه‌ریزی کرده بودیم. با وجود این، عدم برقراری ارتباط شفاف بین افراد درگیر در خصوص موضوعاتی مثل اهداف و جزییات مانور، بحران و پیامدهای غیرمنتظره را برای پروژه به‌همراه داشت. برای اینکه درک درستی از ابعاد ماجرا و دلایل آن به‌دست آوریم، نیاز است ابتدا رویدادهای پیش از آن را بررسی کنیم و سپس به تحلیل آن بپردازیم.
مانور چیست و چرا در پروژه‌های نرم‌افزاری به آن نیاز داریم؟
کلمه مانور در لغت‌نامه دهخدا به‌معنای آزمایش، مشق و رزمایش است. در پروژه‌های نرم‌افزاری هدف از مانور، اطمینان از کارکرد ایمن، درست و بی‌کم‌وکاست خروجی‌های سامانه و یا محصول توسعه داده شده است. به‌عبارت دیگر، مانور، صحت‌سنجی از عملکرد نرم‌افزار توسعه داده شده پیش از استقرار در محل کارفرما و ورود به مرحله Go-live است. جزئیات فراوان موجود در پروژه‌های نرم‌افزاری ضرورتی را ایجاب می‌کند که به‌تدریج و در چندین مرحله قابلیت‌ها و نیازمندی‌های مورد نظر بررسی شود. در واقع، اجرای مانور به کاربران فرصت می‌دهد که نرم‌افزار را قبل از راه‌اندازی نهایی بررسی و تأیید کنند که به نوبه خود افزایش اعتماد و رضایت کاربران را موجب می‌شود. ازسوی دیگر، به توسعه‌دهندگان فرصت می‌دهد که خطاها و ناسازگاری‌های نرم‌افزار را شناسایی و رفع کنند. این کار بهبود کیفیت، عملکرد و امنیت نرم‌افزار، کاهش هزینه‌ها و زمان ترمیم و نگهداری را به‌دنبال دارد. همچنین، شرایطی را برای سازمان مهیا می‌کند که برآورد دقیق‌تری از زمان، هزینه و منابع لازم برای استقرار نرم‌افزار داشته باشد؛ امری که باعث بهینه‌سازی فرایند استقرار، جلوگیری از تأخیرات و سوءاستفاده از منابع می‌شود. نکته قابل تامل این است که نباید کارکرد مانور در پروژه‌های نرم‌افزاری، بر مبنای معنای عامیانه آن معادل خودنمایی کردن، تفسیر شود. اگر چه ممکن است یکی از اهداف جنبی مانور به معرض نمایش گذاشتن توانمندی‌های یک سامانه نرم‌افزاری باشد، اما بدون تردید هدف اصلی اطمینان از صحت عملکرد سامانه در محیط واقعی خواهد بود.
اساس پایه‌ریزی مانور در پروژه ما چه بود؟
هنگامی که درگیر توسعه و استقرار یک پروژه بزرگ‌مقیاس در حوزه بانکداری متمرکز بودیم، برای ارزیابی خروجی اقدامات انجام‌شده و اطمینان خاطر از آمادگی کاربران برای مهاجرت به سامانه‌های جدید، سه مرحله مانور بهره‌برداری به‌منظور تست سامانه در محیط واقعی تعریف کردیم. این مانورها به‌نوعی شبیه‌سازی عملیات پس از بهره‌برداری در شعب مختلف کارفرما بودند تا هم آمادگی کاربران برای کار با سامانه و هم توانایی سامانه در پوشش نیازمندی‌های معین سنجیده شوند. در هر مانور، دامنه فعالیت گسترده‌تر و شرایط تست به شرایط روز بهره‌برداری نزدیک‌تر می‌شد. طراحی صورت‌گرفته به شکلی بود که می‌توان درجه پیچیدگی آسان، متوسط و سخت را به ترتیب به آنها نسبت داد. در واقع، این پیچیدگی هم به لحاظ ماهیت به‌کارگیری فرایندهای توسعه‌داده‌شده در سامانه و هم تعداد کاربران مشارکت‌کننده، در مانور سوم به اوج خود می‌رسید.
پیش به سوی سومین مانور برنامه‌ریزی‌شده
مانور اول و دوم را با موفقیت کامل و ابراز رضایت کارفرما پشت‌سرگذاشتیم و شاهد نتایج مورد انتظار و مطلوبی از عملکرد سامانه تحت سناریوهای تعریف‌شده بودیم. همه چیز آرام بود و موفقیت در این دو مانور اعتمادبهنفس مضاعفی را به اعضای تیم توسعه تزریق کرده بود. اگرچه مدیران باتجربه نگران بودند که شاید این حد از اعتمادبهنفس در مرحله فعلی کاذب باشد و مدام تأکید می‌کردند که نباید در برنامه‌ریزی مربوط به مانور آخر، هیچ نکته‌ای از قلم بیفتد! با وجود دو پیروزی قبلی و اینکه نزدیک به 70 درصد کار به‌درستی پیش رفته و فقط یک مانور دیگر پیش از بهره‌برداری کامل مانده است، ناخودآگاه حس خوش‌بینی را در بین اعضای تیم توسعه ایجاد کرده بود. بنابراین، با رویکرد خوش‌بینانه، برنامه‌ریزی اجرای مانور سوم را در دستور کار قرار دادیم. یکی از اهداف مانور سوم، تست عملکرد سامانه تحت فشار کاری زیاد و مشابه شرایط واقعی بود. با هماهنگی عوامل پروژه، از حدود پانزده هزار همکاران بانک در صدها شعبه در نقاط گوناگون کشور درخواست شد تا به مدت سه ساعت در روز پنجشنبه غیرکاری (یک روز پیش از جلسه کاری فوق‌العاده) در شعب حاضر شوند و به اجرای فرایندهای از پیش مشخص‌شده بپردازند. این تعداد کاربر در مقایسه با سناریوهای قبلی، به مراتب بیشتر بود.
وقتی که زنگ‌ها به صدا درآمدند!
به هر حال، مانور سوم در زمان تعیین‌شده شروع شد و در نیم ساعت اول از شروع، کاربران به‌تدریج و بدون مشکل در حال ورود به سامانه بودند و مثل دو مانور گذشته، شرایط نرمال و موفقیت‌آمیز به‌نظر می‌رسید. پس از ورود و فعال شدن حدود نیمی از کاربران، نشانه‌هایی از اختلال در عملکرد سامانه دیده شد. به‌طور دقیق‌تر در این پروژه، با توجه به مقیاس آن در ابتدا تصمیم گرفته شد که برای پاسخگویی حداکثری به نیازمندی‌های گسترده و متنوع موجود، از یک لود بالانسر[1] خاص استفاده کنیم که پیش‌تر، عوامل اجرایی و فنی پروژه تجربه عملیاتی استفاده از آن را نداشتند. اگر چه احساس می‌شد شاید این موضوع در محیط عملیاتی برای پروژه دردسر‌ساز شود، اما باز هم تأکید می‌کنم که دو موفقیت قبلی باعث شده بود که تمرکز لازم روی جزییاتی مثل این مورد نداشته باشیم. لود بالانسر جدید به پاشنه آشیلی برای ورود کاربران به سامانه تبدیل شد؛ به‌طوری‌که با افت شیب گراف ورودی، امکان کار با سامانه برای کاربران جدید فراهم نشد.
همزمان، کاربران یکی پس از دیگری تماس می‌گرفتند و مواجهه با خطا در ورود به سامانه را گزارش می‌دادند. در حالی‌که عوامل فنی و اجرایی پروژه به‌شدت در تلاش برای رفع مشکل بودند، اتفاق بدتری رخ داد و آن هم قطع شدن غیرمنتظره دسترسی‌های راه دور به مراکز پشتیبانی بود؛ اتفاقی که انجام هرگونه اقدام اصلاحی را غیرممکن و باز هم قصه تلخ عدم توجه به جزییات را در خاطرمان پررنگ می‌کرد. در واقع، با توجه به موفقیت در مانورهای قبلی و پیش‌بینی روند احتمالی مشابه در مانور جاری، عوامل اجرایی در محل ستاد بانک حاضر نشدند و از راه دور وضعیت سرورهای کارفرما را کنترل می‌کردند. با قطع شدن دسترسی‌ها، بر اساس تصمیم مدیریتی، تیم اجرایی پروژه به دو دسته تقسیم شدند: عده‌ای به محل ستاد مراجعه کردند و عده‌ای دیگر هم منتظر برطرف شدن احتمالی نقص ارتباط راه دور شدند تا بدون فوت وقت به ادامه حل مشکل بپردازند. اما همان‌طور که گفتم، مدت زمان مانور محدود بود؛ با وجود محدود بودن مدت مانور و فرارسیدن زمان اتمام کار در شعب بانک، عملاً تصمیم‌های گرفته‌شده را بی‌اثر کرد و شکست انجام مانور سوم در انتظارمان بود.
این یکی شیر است که آدم می‌خورد و آن یکی شیر است که آدم می‌خورد!
بالاخره جلسه کاری فوق‌العاده به دلیل این شکست روز جمعه تشکیل شد. البته در نگاه اول، شکست در یک مانور و آزمایش نه تنها موضوع بحران‌زایی به نظر نمی‌رسید، بلکه برعکس! اقدامی برای مقابله با بحران در آینده بود. از دیدگاه عوامل اجرایی، کارکرد اصلی یک مانور، تمرین و شناسایی ضعف‌ها برای پیشگیری از رخداد بحران در محیط عملیاتی بود. بر پایه این استدلال، انتظار می‌رفت که عوامل درگیر با برگزاری نشستی عادی و در آرامش، عملکرد لود بالانسر را عیب‌یابی و راهکار لازم را برای حل مشکل پیش‌آمده پیدا کنند. اما نگاه دیگری نیز وجود داشت، درست مانند حکایتی که برایمان نام‌آشناست: «این یکی شیر است که آدم می‌خورد/ و آن یکی شیر است که آدم می‌خورد». به عبارت دیگر، عواقب این شکست فراتر از حد انتظار بود و در نشست فوق‌العاده، صحبت از تأثیرات منفی این شکست روی همکاران دو مجموعه، مدیران و به‌طور کلی تمامی ذی‌نفعان بود. آنچه درآن جلسه مطرح شد، نشان داد که ذی‌نفعان پروژه برداشت دیگری از مفهوم مانور داشتند و آن، نمایش اقتدار و قابلیت‌های ویژه سامانه بانکداری متمرکز جدید به کاربران بود. با توجه به چنین ذهنیتی، حدود پانزده هزار فرد درگیر، توقع تجربه کار با یک سامانه منعطف و کاربردوست را در روز مانور داشتند؛ توقعی که به‌درستی برآورده نشد و حتی اغلب آنها قادر به ورود به سامانه نیز نبودند. حالا، بی‌اعتمادی ایجادشده‌ای در این ابعاد و مقاومت‌های احتمالی کاربران در برابر مهاجرت به سامانه بانکداری متمرکز، بحران و مانعی جدی در مسیر بهره‌برداری کامل از سامانه خواهد بود.
آسیب‌شناسی مانور سوم: غرور کاذب نباید می‌آمد!
به هر حال این بحران غیرمنتظره رخ داده بود و باید با ریشه‌یابی مشکلات در راستای حل آنها اقدام می‌کردیم. در بررسی‌های صورت‌گرفته، دلایل بحران‌در دو دسته کلی فنی و غیرفنی دسته‌بندی شدند. در این بین، می‌توان از «غفلت» به‌عنوان یک مسئله غیرفنی، در صدر دلایل بحران در جریان مانور سوم نام برد. به عبارت دیگر، از منظر دست‌اندرکاران پروژه، مهم‌ترین علتی که بحران مانور سوم را رقم زد، غفلت از در نظر گرفتن جوانب مختلف در سناریوی مربوط بود. موفقیت در مانورهای قبلی باعث شد تا عوامل پروژه، مانور سوم را دست‌کم بگیرند و با اعتمادبهنفس کاذبی با آن برخورد کنند. البته مسئله غفلت و غرور کاذب در انجام عملی خاص، تنها مختص عوامل این پروژه نیست و حتی افراد فوق حرفه‌ای و باتجربه مانند ورزشکاران نیز در مواقعی در دام آن می‌افتند. در رتبه بعدی از دلایل بحران، روی دو جنبه از مشکلات فنی تمرکز شد: یکی و به‌طور خاص، نقص لود بالانسر و دیگری، طراحی مانور سوم به‌شکل مدیریت ریسک خنثی. نقص در کارکرد لود بالانسر تنها عاملی بود که در بررسی اولیه و در خلال برگزاری مانور کاملاً به چشم آمد و باید درباره چگونگی عملکرد آن آگاهی لازم کسب و راه‌حل مناسب گرفته می‌شد. همچنین، در برنامه اجرای مانور سوم، هیچ‌گونه راهکار جایگزینی تمهید نشده بود؛ برای مثال، اگر از ابتدا بخشی از کارشناسان فنی در محل مرکز عملیاتی کارفرما حضور داشتند، شاید می‌توانستند مشکل را مرتفع سازند. اقدامی بسیار ساده و کم‌هزینه که ممکن بود از نارضایتی شدید به‌وجودآمده پیشگیری می‌کرد. یعنی در برنامه مانور سوم، مدیریت ریسک و پیش‌بینی لازم پیرامون مخاطرات احتمالی در اجرا مورد توجه قرار نگرفته بود.
در نهایت، می‌توان به عامل دیگری از جنس مسائل غیرفنی اشاره کرد که مربوط به زوایای ناپیدا و اتفاقات غیرمنتظره در اجرای مانور می‌شد. از جمله این جوانب ناپیدا، سوءبرداشت از مفهوم و هدف از عملیات مانور و عدم برقراری ارتباط مؤثر بین دست‌اندرکاران پروژه بود. همچنین، خدشه‌دار شدن اعتبار سامانه نزد کاربران در روز مانور به‌علت آشنا نبودن با هدف مانور نیز در زمره دلایل غیرفنی در این بحران قلمداد می‌شود.
نوشیدن قهوه‌ای که دیگر تلخ نبود!
تجربه به‌دست‌آمده از نتایج این مانور برای ما در داتین نکات ارزشمندی داشت که در ادامه آنها را گفته‌ام:
- پرهیز از غرور و خوش‌بینی کاذب نسبت به مانورهای در دست اقدام
- لزوم اطمینان از صحت کارکرد تجهیزات فنی در اوج فشار کاری
- مدیریت ریسک از طریق در نظر گرفتن راه‌حل‌های گوناگون در شرایط مختلف
- لزوم برنامه‌ریزی مرحله به مرحله با در نظر گرفتن کلیه جزئیات در برگزاری مانور
- مدیریت ارتباطات با مشتری پیرامون هدف و جزئیات برگزاری مانور
با درس گرفتن از این تجربه‌ها و پس از مدت زمان مشخصی، مانور سوم دوباره طبق سناریوی اصلاحی برگزار شد. در سناریوی اصلاحی مواردی مثل لحاظ کردن راهکارهای جایگزین، تقسیم برنامه سناریو به اجزای کوچک‌تر و قابل اجرا در زمان‌های مختلف و ایجاد هماهنگی و تفاهم کامل بین عوامل پروژه درباره اهداف مانور، در دستور کار قرار داده شد. تحت این تمهیدات، این‌بار خروجی مانور رضایت کامل ذی‌نفعان را به‌همراه داشت و پس از مدتی کوتاه بهره‌برداری کامل سامانه به شکل موفقیت‌آمیزی صورت پذیرفت. حال وقت نوشیدن یک فنجان قهوه درکمال آرامش بود؛ قهوه‌ای که به‌علت ارتباط مؤثر ایجادشده بین همه عوامل پروژه، دیگر تلخی پیش را نداشت!
[1]. Load Balancer
داتین
راهکارها
سرمایه‌های انسانی
ارتباطات