دموی نرمافزار هم از آن کارهاست! پوست آدم را می‌کند، تازه یک چیزی هم طلب‌کار است! ۱ کار پر استرسی است. اگر بخواهید برای دموی نرمافزار از اینترنت استفاده کنید، یحتمل آن روز یا اره ماهی بزرگوار خطوط اینترنت را اره می‌کند و یا لنگر کشتی معروف به آن گیر کرده‌است. اگر هم بخواهید از نسخه Offline استفاده کنید، احتمال آن وجود دارد که Database به مشکل بر بخورد و هزار یک مسئله پیش‌بینی نشده دیگر رخ دهد. اگر هر دو راه حل را باهم پیش‌بینی کرده باشید، کلمه عبور کامپیوتر به نحوی تغییر کرده و یا باطری لپ‌تاپ تمام شده و برق به مشکل می‌خورد. بگذریم، همه این موارد هست، اما نه به این حالت بدبینانه که من عرض کردم.
خیلی از موارد گفته شده را کارفرمایان اگر از بُعد فنی لازم برخوردار باشند با اندکی اغماض فراموش می‌کنند. اما نکته بسیار مهم نحوه ارائه است. واقعیت قضیه این است که من چند وقت است متوجه شده‌ام که برای دمو باید یک گروه ارائه وجود داشته باشد که دارای چند جنبه رفتاری باشد. اگر دموی سیستم را به افراد فنی و به خصوص برنامه‌نویس‌ها بسپارید این مشکل به وجود می‌آید که بیشتر از دیدگاه خود و جنبه‌های فنی و نه راه‌حل‌های مورد علاقه سازمان طرف ارائه، به موضوع نگاه می‌کند. در این حالت برنامه‌نویس بیشتر نکاتی را توضیح خواهد داد که از نظر فنی و برنامه‌نویسی جذابیت بیش‌تری برای او داشته باشد و بر اساس قانون قیاس به خود، فکر می‌کند که این موضوع برای دیگران نیز جذاب است. در حالی‌که مشتری اگر به دنبال رفع مشکل خود با نرمافزار باشد، شاید توجه چندانی به موارد فنی نداشته باشد. این نکته بسیار مهم است که بسیاری از نرم‌افزارهایی که در بازار به موفقیت می‌رسند، از به‌ترین و بالاترین فناوری برخوردار نیستند، بلکه محصول‌هایی می‌باشند که پاسخ‌گوی نیاز مشتری است. حضور برنامه‌نویس‌ها و افراد فنی مشکل دیگری نیز دارد. او بعد از طرح خواسته‌های مشتری ناخواسته در مورد تغییرات و نیازهای مشتری مقاومت می‌کند؛ چرا که می‌داند بدبختی پیاده‌سازی موارد درخواست شده با او خواهد بود و حتی برخی خواسته‌ها از نظر فنی ممکن نیست.
از طرف دیگر من فکر می‌کنم، ارائه دمو توسط افراد بازرگانی به خصوص زمانی به مشکل بر می‌خورد که بحث موارد فنی با حضور گروه فناوری اطلاعات مشتری صورت بگیرد. کامپیوتری‌های مشتری بیشتر مواقع در جلسه حضور دارند و گاه جلسه را به سمت ابعاد عمیق فنی می‌کشانند و یکی از اهداف آنها هم ارزیابی توان فنی شرکت شماست. این اشتباه بزرگی است که فرد ارائه کننده نرمافزار، همه موارد را به مذاکره با گروه فنی موکول کند و بگوید بعدها پاسخ شما را خواهیم داد. مشکل بعدی بازرگانی‌چی‌ها این است که در نقطه مقابل برنامه‌نویس‌ها قرار دارند. یعنی هر چه برنامه‌نویس‌ها در مقابل خواسته‌های مشتری مقاومت می‌کنند، این‌ها چون تمایل به فروش بیشتر دارند، خواسته‌های مشتری را با سهولت بیش‌تری می‌پذیرند و یا حداقل رد نمی‌کنند. این موضوع می‌تواند دردسر جدی برای برنامه‌نویس‌ها در آینده ایجاد کند.
یکی از موارد مشکل دیگر این است که گاهی سطح جلسه مشخص نیست و در همان جلسه مقدماتی دمو، موضوعات بیشتر از سطح دمو و در حد برخی تصمیم‌گیری‌های مدیریتی مطرح می‌شود. احتمال زیادی وجود دارد که حتی اگر مدیرعامل نیز در جلسه باشد، مطابق با اساس‌نامه نتواند تعهدی بدهد که منجر به بار مالی شود. درایت و توجیه می‌خواهد که این موارد به جلسه دوم منتقل شود.
جلسه دمو، جلسه کج‌دار و مریز است. سطح به اندازه‌ای از اطلاعات باید به مشتری منتقل شود. سطح به اندازه‌ای تعهد باید پذیرفته شود و سطح به اندازه‌ای از تصمیم‌ها باید اخذ شود و همه این موارد باید در یک صورت‌جلسه تنظیم شود. ترکیب گروه ارائه دهنده دمو باید شامل فنی، بازرگانی و تا حدی مدیریتی باشد. وجود یک تحلیل‌گر سیستم در جلسه دمو و حتی به عنوان ارائه دهنده دمو بسیار مهم است، یک تحلیل‌گر علاوه بر درک جنبه‌های فنی، نیاز مشتری را هم در نظر دارد؛ از طرف دیگر وجود او باعث می‌شود که با وجود درک نیازهای مشتری، تعهدات غیر قابل اجرا نیز پذیرفته نشود.
در جلسه دمو همه افراد گروه، باید حواسشان باشد. یکی باید رفتار افراد طرف مقابل را تحلیل و شناسایی کند. یکی باید وظیفه ارائه را داشته باشد و هر وقت هم کم آورد و یا مشکلی پیش آمد، افراد دیگر باید آن را به نحو مقتضی پوشش دهند. ارائه دمو یک کار گروهی سنگین و مانند ارائه یک نمایش و یا ساخت یک برنامه تلویزیونی زنده است که نیاز به برنامه‌ریزی، هماهنگی، ممارست و دقت دارد.
پاورقی______________________________________________________________________
-
این عبارت را از یکی از نامه‌های سهراب سپهری به احمدرضا احمدی در مورد نقاشی به عاریت گرفته‌ام.
سلام
خداقوت
یاد جمله شما افتادم که می فرمودید: مدیران بازاریابی کابوس برنامه نویسان هستند
یادش بخیر در جلسه ای در خدمت شما بودیم و کارفرما، فکر کنم شنبه بعد از ظهر بود. کارفرما پرسید سیستم کی آماده می شود که شما فرمودید : آماده است و پیشنهاد دادید شنبه هفته بعد راه اندازی شود
کارفرمای محترم هم فرمودند: دیر است و چهارشنبه باید همه چیز آماده باشد!
حالا بماند که ما برنامه نویسان هنوز نمی دانستیم برای چه چیزی باید سیستم بنویسیم و تنها سه روز وقت داشتیم!
یادش بخیر تازه کارفرمای محترم هم برای محکم کاری تهدید کرد که اگر سیستم آماده نشود ، از ساختمان آویزانمان می کند تا عبرتی شویم برای سایرین
یادش بخیر
سلام آقای مهندس
این قضیه که می‌فرمایید، مربوط به سال ۸۴ است و البته تا آن‌جا که من یادم هست، چهارشنبه‌ای بود که برای شنبه قول دادیم. خدا از سر تقصیرات من بگذرد. خوب یادم هست که در مسیر رفتن به جلسه در مورد این که چطور دروغ‌هایمان را هماهنگ کنیم، صحبت می‌کردیم.
این روزها اما دیگر از این اتفاق‌ها در بهساد نمی‌افتد. به چند دلیل:
اول این‌که من دروغ را به خصوص در جلسه دمو به کلی حذف کرده‌ام.
دوم این‌که بیشتر به سمت فروش محصول رفته‌ایم و کم‌تر کار سفارشی قبول می‌کنیم. ظاهر و باطن نرمافزار هم که تا حد زیادی مشخص است و جای دروغ و خالی‌بندی کم دارد.
و سوم این‌که من آن موقع خود کار برنامه‌نویسی هم می‌کردم و علاوه بر توان فنی بزرگانی مانند شما، خودم نیز تا حدی دست به آچار بودم و برای این‌که موضوع خیلی هم آبروریزی نشود، تا خود صبح هم که شده برنامه می‌نوشتم. حالا دیگر نه از آن انرژی جوانی اثری باقی مانده و نه اعتقادی به فشار به تیم برنامه‌نویس دارم.
واقعن که چقدر انسان تغییر می کند
و بازهم به قول سهراب عزیز
من چه دیر فهمیدم که انسان یعنی “عجالتاً “
تغییرات جدیدی در شرکت داشته ایم که باعث شده تصمیم بگیرم برخی از دموها و جلسات با مشتریان مهم تر وبزرگ تر را خودم شرکت کنم … تجربیات جدید و جالبی حاصل شده که یکی از آنها تایید همین فرمایش شماست… من هم چند جلسه اخیر را به صورت گروهی تشکیل داده‌ام که نتایج بسیار خوبی حاصل شده … مخصوصا حضور مشاور مالی در جلسه دمو نرم افزارهای فروش و مالی خیلی خوب جواب داده!