اطلاعات جعلی! چگونه اطلاعات نادرست و نیمه‌درست و دروغ‌ها به پروژه‌های آی‌تی آسیب جدی می‌رساند
اخیراً کم‌وبیش شاهد سه شیوۀ انتقال «اطلاعات» در پروژه‌های آی‌تی هستیم:
اول) انتقال نیمی از واقعیتِ خبرها یا به‌روزرسانی‌ها یا اطلاعات؛
دوم) انتقال دوبرابر بیشتر از واقعیتِ خبرها یا به‌روزرسانی‌ها یا اطلاعات؛
سوم) انتقال دقیق واقعیتِ خبرها یا به‌روزرسانی‌ها یا اطلاعات همان‌طور که هستند.
فکر کنید! واقعاً این‌گونه نبوده؟ منفی‌ها کم‌اهمیت یا پراهمیت جلوه داده می‌شوند و مثبت‌ها همیشه اغراق می‌شوند. فقط یک‌سوم از اطلاعات و خبرهای تازه دربارۀ پروژه دقیقاً همان‌طوری است که در واقعیت رخ داده و شنونده با شنیدن آن امکان واکنش مناسب دارد.
این سناریو را در نظر بگیرید: ادارۀ مدیریت پروژۀ شما ازقبل تحت فشار است که پی می‌برید راهبرد قبلی پروژه‌های آی‌تی شما دیگر نتایجی که در راستای اهداف تجاری شما باشد به‌بار نمی‌آورد. این مهمترین موضوع در سبد پروژۀ شماست و بی‌تعارف اگر راهبرد مناسبی نیابید، بهتر است که کارایی دفتر مدیریت پروژۀ (PMO) خود را زیر سؤال ببرید. شاید این اتفاق برای هم‌شغلان یا دوستانتان بیفتند و از شما راهکاری بخواهند.
فرض کنید که این مشکل راهبردی، نحوۀ دستیابی مشتری‌ها به محصولات و خدمات باشد؛ به‌طور مثال، آنلاین‌شدن یک شرکت و پروژه‌ای مثل کارآمدسازیِ عملیات درون‌مغازه‌ای آن را در نظر بگیرید.
این گزینه‌ها وجود دارند: (آ) مطرح کردن برآوردتان و مواجه‌شدن با عواقب آن یا (ب) پیشروی طبق برنامه یا (پ) اعتراف کردن و پذیرفتن اما کم‌اهمیت جلوه دادن مشکل و ایجاد تغییرات ماهرانه‌ای در محدوده [۱] که شکاف‌های فعلی را بپوشانند. پروژه باید به‌موقع و در محدودۀ بودجه باشد و باید نهایتاً زیر یک سال تحویل داده شود تا شخصی که پول گرو گذاشته، مجبور نباشند برای یازده ماه دیگر نیز گرو بگذارد. شاید غریزه‌تان شما را به نوسان بین گزینه‌های (ب) و (پ) هدایت کند؛ یعنی دائماً لبخند بزنید و به پیشروی ادامه بدهید.
بعید نیست که درآخر بعد از کمی فکر و بحث، وجدان یا حس حرفه‌ای‌تان بر شما غلبه کند و تصمیم به رویارویی بگیرید.
هیأت مدیره از درست‌کاری شما رضایت دارد. متفکران راهبردی هیأت مدیره نیز مانند شما تحول آنلاین را تشخیص داده‌اند اما متوجه نیستند که اگر همین روند ادامه پیدا کند، پروژۀ فعلی در پنج سال آینده تقریباً بی‌فایده می‌شود. برای تیم پروژه این وظیفه و مأموریت جدید تعیین می‌شود که تجربۀ آنلاین مشتری را نسبت‌به آنچه رقیبان عرضه می‌کنند بهتر کنند. این مثال دربارۀ شرکتی واقعیت داشت. سال ۲۰۱۰ شروع کردند و اعضای تیم پروژه تا الآن باید گروهای خود را پرداخت کنند.
سیسِلا باکِ [۲] فیلسوف معتقد است که دروغ گفتن نوعی اجبار و تهدید است. نگفتن حقیقت موجب هدایت فردی که با او ارتباط داریم به رفتاری می‌شود که اگر واقعیت را طوری دیگری جلوه نمی‌دادیم شاهد آن نبودیم. بی‌تردید ازلحاظ تیم‌های پروژه‌های آی‌تی، ناشفاف بودن در نشان دادن یک موقعیت مانع واکنش راهبردی مناسب به آن موقعیت می‌شود.
گاهی فقط یک دروغ تمام‌وعیار نیست که ما را سرجای اولمان می‌نشاند. هیأت مدیره‌ای بود که باور کرد که بهبود روند سفارش خرید تا ۱۵درصد موجب افزایش فروش می‌شود و بر این اساس، تغییر محدودۀ یک پروژۀ آی‌تی را پذیرفت. بررسی موشکافانۀ این ادعا بر صحت آن خدشه‌ای وارد نکرد اما کسی آن را به چالش نکشید و با تغییر عرضۀ جدید نرم‌افزار موافقت شد. پروژه به‌موقع و زیر بودجه عملیاتی شد و از دوازده ماه بعد، فروش هر سال ۵درصد افزایش یافت، نه ۱۵درصد. مدیرعامل توضیح می‌خواست.
مشکل این بود که اصلاً در توانِ این پروژۀ آی‌تی تحویل افزایش ۱۵درصدی فروش نبود. کاری که قرار بود بکند و واقعاً کرد تحویل سریع‌تر فرایند سفارش فروش بود؛ نیاز به مدیریت را کم می‌کرد تا کارکنانِ فروش زمان بیشتری برای دستیابی به ۱۵درصد افزایشِ تخمینی در فروش بیابند. اما واضح است که این افزایش به کار خودشان و جوِ بازار که در آن زمان به‌شدت چالش‌انگیز بود مربوط می‌شد.
اگر واقعیت‌ها را بررسی کنیم، می‌بینیم که پروژه به‌موقع و زیر بودجه تحویل داده شد و محیطی ایجاد کرد که موجب افزایش ۵درصدیِ فروش در آن جوِ دشوار شد. باید قلبتان از سنگ باشد که چنین بازدهی را موفقیت محسوب نکنید، اما همین اتفاق افتاد. هیچ جشن و سروری در کار نبود و عواقب بدقولی دربارۀ افزایش ۱۵درصدی فروش، آن‌ها را به سرجای اولشان برگرداند.
این یک دروغ تعمدی وتمام‌وعیار نبود و قرار نبود به بیراهه بیانجامد.
این است که رسانگری و انتقال دقیق و برحسبِ واقع، موجب واکنش و اقدامات سنجیده و مناسب می‌شود اما باید مراقب زبانی که به‌کار می‌برید نیز باشید. مثلاً ایمیلی را در نظر بگیرید که مدیر پروژه‌ای در آن پیش‌بینی کند که «موفقیت پروژه تقریباً تضمین‌شده است.». یک ذی‌نفع یا حامی مالی از ظاهر گفته به‌نظرش می‌رسد که حتماً مدیر پروژه آسوده‌خاطر است و مشتاقانه تاریخ تحویل پروژه را انتظار می‌کشد.
مسئله این است که در زمان نگارش ایمیل، مدیر پروژه از بعضی چالش‌های بالقوه‌ای که ممکن است موجب تأخیر پروژه شوند آگاه بوده است. می‌دانسته که به منابع اضافی برای مواجهه با این چالش‌های بالقوه نیاز دارند. اما برای اینکه این چالش‌ها جدی تلقی شوند باید اول اتفاقات احتمالی رخ بدهند؛ بنابراین مدیر پروژه دربارۀ احتمال وقوع این چالش‌ها یک تصمیم غیرعینی می‌گیرد. احتمالات «حداقل» برآورد می‌شوند و مدیر پروژه تصمیم می‌گیرد که پنهان کند.
حال فرض کنید که اتفاقات احتمالی واقع شوند و پروژه دیرتر از موعد و بالای بودجه تحویل داده شود!
مشکل کلماتی چون «تقریباً» این است که گمراه‌کننده‌اند. منظور چیست؟ مفهومِ «تقریباً تضمین‌شده است» می‌تواند «کم‌وبیش» یا «نه کاملاً» باشد. اگر مدیر پروژۀ ایمیل بزند که موفقیت پروژه «کم‌وبیش» یا «نه کاملاً» تضمین‌شده است، چقدر واکنش حامی مالی متفاوت می‌شود؟!
بیشتر زبانی که در ارتباطات پروژه به‌کار می‌بریم همانند ادعاهای آگهی‌هایی است که می‌گویند فلان دهان‌شور مانع بیماری لثه می‌شود یا فلان خوراکی چون بخشی از رژیم کنترل کالری است، باعث کاهش وزن می‌شود. یک شنوندۀ معمولی پیام را جلوگیری از بیماری لثه و کاهش وزن تلقی می‌کند اما واسطِ این نتیجه را در نظر نمی‌گیرد؛ اینکه باید برای اثرگذاری آنچه در محصول تبلیغ شده کاری انجام بدهد. استفاده از خمیردندان یا کم‌خوردن دونات نقش مهمتری از محصولات تبلیغ‌شده دارند اما این‌چنین پیام‌های بازرگانی چقدر می‌توانند موجب فروش شوند؟
در مورد آن ایمیل مدیر پروژه می‌تواند پیش‌بینی خود را با درصد بیان کند؛ مثلاً سفیدکننده‌ای که ۹۹.۹درصد از جِرم‌های شناخته‌شده را ازبین میبرد. می‌تواند معیاری را که ممکن است موجب تأخیر یا افزایش هزینه شود، هرچند هم که احتمالش کم باشد، توضیح بدهد. بنابراین به‌جای اینکه بنویسد «موفقیت پروژه… تقریباً تضمین‌شده است» باید بنویسد که «موفقیت پروژه تا ۹۸درصد و تا ۶۰درصد درصورت وقوع اتفاق‌های الف و ب و ج حتمی است». حداقل به این شیوه درصورت وقوع الف و ب و ج یک راه ارتباطی وجود دارد و حتی شاید حامی مالی ترغیب شود که بودجه‌ای برای احتمالات تنظیم کند.
درس اخلاقی این داستان‌ها این است که راست بگوییم! سختی راستگویی هیچ‌گاه به دشواریِ عواقب دروغگویی یا دور زدن یا پنهان کردن واقعیت نیست.
یادش به‌خیر! در گذشته وقتی که مشکل پروژۀ آی‌تی را نشان می‌دادید، معمولاً حامیان مالی مجبور بودند دستشان را در جیبشان کنند تا مشکل را برطرف کنند. دربارۀ مشکل راستش را می‌گفتید و سعی می‌کردید جایی نایستید که ضرر ببینید.
زمانه تغییر کرده و امروزه مدیریت پروژه که جزئی از بازار خدماتی است، آن‌قدر تکامل یافته که راهکارها برای اکثر مشکلات نباید با افزایش هزینۀ کلی همراه باشند.
حقیقت همین است!
با این دشواری‌ها اگر می‌خواهید بیشتر دربارۀ روش‌های جلب موافقت ذی‌نفعان و حامیان مالی بدانید، در خط دید بخوانید که:
چگونه می‌توانیم موافقت ذی‌نفعان ارشد پروژه را جلب کنیم
[۱] scope
[۲] Sissela Bok فیلسوف و اخلاق‌شناس آمریکایی-سوئدی و دختر دو برندۀ جایزۀ نوبل، فریدریش آوگوست فون هایک و آلوا میردال.
