مشتری‌های ناآگاه و نرم‌افزارهای سفارش مشتری
[ مشتری‌های ناآگاه و نرم‌افزارهای سفارش مشتری ]
توسعه نرم‌افزار به معنی سر هم کردن ماژول‌های آماده نیست
حساب مشتریان با تجربه، با اطلاع و صبور جداست ولی این سناریویی است که بسیار رایج است و رفتار خیلی از مشتریان و سفارش دهندگان تازه کار از آن تبعیت می‌کند. این نوع مشتریان نمی‌توانند به سادگی حساب توسعه نرم‌افزار (یعنی چیزی که از قبل وجود نداشته و باید طراحی و تولید شود) را از حساب استفاده از نرم‌افزارهای موجود و کانفیگ و راه اندازی آنها جدا کنند. خیلی از آنها فکر می‌کنند هر نوع وب سایت و web application را می‌توان با سر هم کردن چند ماژول وردپرس و جوملا، کانفیگ آنها و نهایتاً نوشتن ۱۰ الی ۲۰ درصد کل کار در قالب یک ماژول جدید انجام تولید کرد.
در دسترس بودن نرم‌افزار به معنای رایگان بودن آن نیست
متاسفانه برخی از آنها فکر می‌کنند چون ویندوز را به قیمت ۱ الی ۲ دلار از بازار رضا تهیه می‌کنند معنی‌اش این است که توسعه یک سیستم عامل مثل ویندوز کار خیلی سختی نیست و نهایتاً کار شش ماه یک تیم دانشجویی ۵ نفره است. در همین راستا تصورات غلطی وجود دارد که شرکت‌های نرم‌افزاری یک بار نرم‌افزار را می‌نویسند و بعد از آن با فروش مجدد نرم‌افزار به افراد دیگر سودهای کلانی به دست می‌آورند. رایگان بودن نرم‌افزارهای open source نیز مزید بر علت شده است.
تقلید بدون بررسی
داستان‌های موفقیت startupها و کارآفرین‌های آمریکایی از جمله فیسبوک و اینستاگرام از جدیدترها و مایکروسافت و IBM از قدیمی‌ترها مردم را شیدا کرده است. این داستان‌ها همان بلایی را سر کارآفرین‌ها آورده که شهرت فوتبالیست‌ها و هنرپیشه‌ها بر سر قوتبال دوستان و علاقمند بازیگری آورده است. هزاران نفر بخش مهمی از زندگی خود را صرف می‌کنند ولی فقط عده خیلی خیلی کم و انگشت شماری می‌توانند خودشان را به بالا برسانند.
تصورات غلط راجع به تسلط برنامه‌نویسان به حوزه کاری مشتری
یکی دیگر از مشکلات رایج این است که مشتری‌ها از تیم نرم‌افزاری انتظار دارند که به حوزه کاری آنها تسلط کامل داشته باشند و خودشان خیلی چیزها را از قبل بدانند و در سیستم لحاظ کنند. مثلاً کسی که در حوزه حسابداری فعالیت می‌کند انتظار دارد که تیم توسعه نرم‌افزار تمام ریزه کاری‌های حسابداری را بدانند. او به این موضوع توجه نمی‌کند که اگر قرار بود تیم نرم‌افزاری به ازای هر نرم‌افزاری که تولید می‌کند به همه جزییات آن حوزه هم تسلط پیدا می‌کرد آن وقت باید قبل از یاد گرفتن توسعه نرم‌افزار باید در تمام حوزه‌های کاری دیگر از جمله حسابداری، مخابرات، امور مالی، آموزش و پرورش، سلامت و پزشکی، جرایم و پلیس، بیمه، مالیات و بسیاری حوزه‌های دیگر نیز تسلط پیدا می‌کرد و به عبارتی دیگر عالم الدهر می‌شد. شاید به همین علت باشد که خیلی اوقات که نرم‌افزار کامل شده و به مشتری تحویل می‌گردد، مشتری با تعجب فراوان از نبود فلان مکانیزم صحبت می‌کند و انتظار داشت چنان چیزی که از نظر خودش بدیهی بوده در نرم‌افزار نیز وجود داشته باشد.
مکانیزاسیون افراطی
از جمله مشکلات دیگری که وجود دارد قاطی شدن بخش‌های قابل مکانیزه شدن و غیر قابل مکانیزه شدن است. مشتری به فرایندهای خودش نگاه می‌کند و علاقمند می‌شود که هر چیزی که وجود دارد و ندارد را مکانیزه کند و به نرم‌افزار منتقل کند. از جمله فعالیت‌های نگهبانی دم در و کنترل فعالیت‌های کارمند نام نویسی.
عدم هماهنگی داخلی
متاسفانه خیلی اوقات در جلسات بررسی و تحلیل سیستم متوجه می‌شویم که مشتری با افراد داخل تیم خودش هماهنگی نیست و دید و طرح مشترکی از کار خودشان ندارند و خیلی اوقات تازه در همان جلسه که با هم گفتگو می‌کنند تا به دیدگاه مشترکی برسند. این وسط نماینده تیم نرم‌افزارهای هم باید به آنها کمک کند تا آنها چیزی را که مربوط به او نیست را اصلاح نمایند. اصولاً خیلی از مشتر‌های نرم‌افزارهای سفارشی تیم‌های توسعه نرم‌افزار را با تیم‌های مشاوره مدیریتی و سیستمی اشتباه می‌گیرند.
نداشتن RFP
این یکی که نوبر است و با تجربه و بی تجربه نمی‌شناسد. به ندرت می‌توان یک مشتری پیدا کرد که قبل از شروع کار یک RFP کامل و شسته و رفته از کار خودش داشته باشد. RFP یعنی شرح کامل و شفافی از نیازمندی‌های مشتری که قرار است برای آن نرم‌افزار توسعه پیدا کند. بیشتر اوقات جلسات شفاهی اولیه که معمولاً هم عجله‌ای و بدون مزد از آب در می‌آیند جای این RFP را می‌گیرد. در حالی که درست آن این است که مشتری از قبل با کمک مشاور مورد اعتماد خودش نیازمندی‌های خودش را با دقت بررسی کرده و همه چیز برای خودش شفاف و واضح شده و سپس همه آنها را مکتوب کرده آنگاه به دنبال یک تیم یا شرکت نرم‌افزاری برای اجرای آن بگردد.
ندیدن جزییات اجرا
گاهی اوقات مشتریان چنان غرق در طراحی سیستم و مکانیزاسیون می‌شوند که یادشان می‌رود که این سیستم قرار است بعداً به طور واقعی در محیط واقعی مورد استفاده قرار بگیرند. آنها خصوصیات رفتاری و توانایی‌ها و ضعف‌های کارمنداشان، علایق مشتریان خودشان، محدودیت‌های فنی و خیلی چیزهای دیگر را فراموش می‌کنند و آخر سر به سیستمی می‌رسند که کمتر از ۲۰ درصد آن مورد استفاده واقعی قرار می‌گیرد.
ارزان بودن
نوشتن نرم‌افزار هرگز کار ساده و ارزان قیمتی نبوده است. برنامه‌نویس‌ها منابع گران قیمتی و حساسی هستند. نیاز به آموزش دارند، نرخ جابجایی آنها بین تیم‌ها و شرکت‌ها و حتی مهاجرت آنها خیلی بالاست و مدیریت کردن آنها هم کار ساده‌ای نیست. به این بیفزایید پیچیدگی ذاتی خود نرم‌افزار و مدیریت پروژه‌های تولید نرم‌افزار را. به همین علت خیلی سخت است که بتوان یک نرم‌افزار ارزان قیمت تولید کرد.
نتیجه گیری
این طور مباحث را نمی‌توان را بدون مثال به خوبی توضیح داد و مثال‌های واقعی ممکن است اطلاعات محرمانه اشخاص را به خطر بیندازد. کاش فرصتی بود و می‌شد که بهتر به این موضوعات پرداخت شک ندارم که بیشتر مشتری‌های ناآشنا به کار هم اگر درست راهنمایی شوند می‌توانند تبدیل به مشتریان طلایی شده و کارهای بسیار ارزشمندی انجام دهند که آخر کار همه راضی باشند و کسی با دیگران contact پیدا نکند. یادآوری این که این مشکل مختصات ایران نیست و کم و بیش در کشورهایی دیگر هم وجود دارد.
