دموی نرم‌افزار – آن سوی میز
چندی پیش فرصتی به دست آمد تا به عنوان مشاور یکی از سازمان‌ها در جلسات دموی نرم‌افزار شرکتهای مختلف حضور پیدا کنم. تجربه خوبی بود که این بار در سمت کارفرما بنشینم و به ارزیابی هم‌کاران نرم‌افزاری خود بپردازم. چند نکته به ذهنم رسید که بد ندیدم که در روزنوشت‌ها هم بنویسم.
-
فرآیند تولید نرم‌افزار
بسیاری از نرم‌افزارهای تولید شده در کشور ما به این شکل تولید می‌شوند که ابتدا یک مشتری سفارش یک سیستم خاص را به یک شرکت نرم‌افزاری/مشاور ارائه می‌دهد. پس از آن‌که نرم‌افزار ساخته شد، شرکت نرم‌افزاری آن را به عنوان یک محصول روانه بازار می‌کند؛ غافل از این‌که این نرم‌افزار بر مبنای نیازهای یک مشتری خاص نوشته شده و نه بر مبنای نیازسنجی عمومی و تخصصی در بازار. مشتریان دوم، سوم و … بر اساس شباهت نسبی به مشتری اول به جمع مشتریان اضافه می‌شوند و چون نرم‌افزار کامل نیست و البته بر اساس نیازهای اختصاصی، برای هر یک نیز خاص‌منظوره‌سازی (Customize) مورد نظر انجام میشود که تبعات زیادی از جمله افزونگی کارکردها و کثیف شدن کد و به وجود آمدن موجودیت‌های نامتجانس و قواعد تجاری پیچیده را به دنبال دارد.
شاید به همین دلیل و یا با توجه به وجود پیشران‌های فناوری برخی اوقات شرکتهای نرم‌افزاری تصمیم می‌گیرند که نرم‌افزار خود را دوباره تحلیل کرده و با یک فناوری جدید بنویسند که در این‌جا در دام دیگری می‌افتند. در این شرایط شرکت ترجیح می‌دهد که نرم‌افزاری همه‌کاره و به عبارتی پارامتریک بنویسد که بتواند نیازهای همه مشتریان را پاسخ دهد؛ غافل از این‌که هیچ راه‌کار جامعی برای همه طیف‌های مشتریان وجود ندارد. به عنوان نمونه، مدیریت پروژه در نفت و گاز با مدیریت پروژه در صنایع اتومبیل فرق دارد. حتی مدیریت پروژه صنعت انتقال برق با حوزه توزیع نیروی برق فرق دارد. پس نمی‌‌توان یک نرم‌افزار مدیریت پروژه نوشت که همه جا و برای همه صنایع کاربرد داشته باشد و اگر هم چنین نرم‌افزار نوشته شود، بسیار پیچیده خواهد بود.
شاید به همین دلیل و فقدان سرمایه‌گذاری خطر پذیر در شناخت نیازها، مطالعه، تحلیل و طراحی راه‌کار خاص یک صنعت، تاکنون نتوانسته‌ایم در کشور نرم‌افزارهایی قابل اعتنا و جامع را مطابق با استاندارد جهانی توسعه دهیم.
-
دمو یک کار تخصصی است
پیش‌تر هم در این باره نوشته بودم (این‌جا). ارائه دموی نرم‌افزار یک تخصص جدی محسوب میشود که شرکتهای نرم‌افزاری باید در مورد آن مطالعه و برنامه داشته باشند. با این‌حال این موضوع به خصوص در شرکتهای ده-بیست نفره نرم‌افزاری جدی گرفته نمی‌شود. کارشناس نصب و راه‌اندازی نرم‌افزار، هر چند هم که آن را خوب بشناسد، نمی‌تواند لزومن گزینه خوبی برای شرکت در جلسه ارائه نرم‌افزار باشد، چرا که در هر دمو، تخصص‌هایی مانند بازاریابی، مذاکره، ارزیابی توان مشتری و … مورد نیاز است. متاسفانه هنوز هم شرکتهای ما با مشکلاتی در تهیه فایل ارائه، نحوه گفتگو و مدیریت جلسه روبرو هستند که باید روی این نقطه ضعف به طور جدی کار کنند. باید باور کنیم که هر دمو مانند ساخت یک نمایش و یا فیلم سینمایی است که باید در مورد آن کار کرد.
-
خالی‌بندی و دروغ‌گویی
من صلاحیت پرداختن اخلاقی به موضوع را ندارم. اما از منظر گفتگو، وقتی به طرف مقابل دروغ می‌گوییم به نوعی او را احمق و در به‌ترین حالت نا آگاه فرض می‌کنیم؛ در حالی‌که چنین نیست و به سادگی خود را خراب می‌کنیم. این موضوع در جلسه‌های دمو و تهیه کاتالوگ‌ها و … زیاد بروز می‌کند. شرکتی در اسناد تجاری خود ادعا می‌کند که «مدیریت گردش کار» دارد و در هنگام دمو هم بر ادعای خود پافشاری می‌کند؛ در حالی‌که گردش‌کارهای سازمان باید توسط برنامه‌نویس پیش از نصب برنامه Hard Code شود! یا وقتی از امکانات خاص پرسیده میشود و می‌گوید در نرم‌افزار موجود است و بلافاصله آن را به پایان جلسه موکول می‌کند و می‌داند که در پایان جلسه به احتمال زیاد همه آن سئوال را فراموش کرده‌اند (از تکنیک‌های فرافکنی در جلسه دمو). به طور خاص به هم‌کاران خود در شرکتهای نرم‌افزاری پیشنهاد می‌کنم که خالی‌بندی و دروغ را از برنامه‌های دموی خود خارج کنند. مشتریان امروز به مراتب از مشتریان دیروز آگاه‌تر هستند.
-
تعهدات ویران‌گر
در راستای مطالب قبلی، بسیار پیش می‌آید که وقتی از ارائه دهنده نرم‌افزار در مورد برخی امکانات مورد نیاز پرسیده میشود، موضوع را به خاص‌منظوره‌سازی‌های بعدی موکول می‌کند که این کار به خودی خود، «بد» محسوب نمی‌شود. اما این خطر وجود دارد که پذیرش این تعهدات یا به ساختار نرم‌افزار آسیب برساند و آن را کثیف کند و یا دارای تبعات سنگین مالی برای شرکت باشد و پروژه را زیان‌ده کند. توجه به این نکته ضروری است که وقتی که حفره‌ای به عنوان تغییر در نرم‌افزار در قرارداد پیش‌بینی میشود، سیل دمان خواسته‌های مشتری از همین حفره می‌تواند به راه بیفتد. بنابراین در پذیرش چنین تعهدی باید بسیار محتاطانه و با درایت عمل کرد و صرفن به دلیل جذب کار نباید، پذیرای چالش‌های بعدی بود.
این مطالب را در ذهن سپرده بودم که در روزنوشت‌ها بنویسم. دلیلی هم ندارد که این اشکال‌ها در مورد بهساد و من تا به حال پیش نیامده باشد. به هر حال در هر دو طرف میز بودن این خاصیت را دارد که احاطه بیشتری نسبت به موضوع به وجود می‌آید و ما می‌توانیم خود را از آن سو هم ببینیم. شاید به این دلیل بود که آخرین دموی من بعد از این جلسات، به نحوی متفاوت بود.
نکات مفید و آموزنده ای بودند. ممنون.
سلام
ممنون از محبت شما. همواره لطف دارید.
با سلام
در مورد روش کار شرکت های نرم افزاری برای ساخت محصول و به اصطلاح تبدیل محصول سفارشی به یک محصول جنرال که توانایی فروش دوباره را داشته باشد با شما موافقم ولی به نظرم دلیل استفاده از این شیوه نبودن سرمایه کافی برای تولید محصول قبل از فروش و قرارداد می باشد و اکثر شرکتها تا قبل از دریافت پیش هیچ ریسکی نمیکنند به خاطر مسایل مالی . در مورد ارایه و دمو هم با دقیققا همینطوره و “اقدام بدون برنامه ریزی عامل همه شکستهاست” باید برای تمام سوالهای احتمالی و برای تمام لحظه های ارایه برنامه داشت و فکر کرد . صرف بالا بودن امکانات فنی نرم افزار چیزی را عوض نمیکند. به شخصه اگر برای یک دموو یا پرزنت آماده نباشم ترجیح ملاقات را به عقب می اندازم و تا کامل آماده نشوم نمیروم . شاید کارم عقب بیفته ولی درست انجام میشه .
سلام
من فکر می کنم مادامی که شرکتهای ما به این روش به تولید نرم افزار می پردازند، نمی توانیم خیلی روی رشد آن ها حساب کنیم. باید فکری کرد که روی محصولات فناوری اطلاعات هم سرمایه گذاری شود که البته هنوز این موضوع زیاد در کشور ما جا نیفتاده است.