همیشه هم این طور نیست که شرکت‌ها و تیم‌های تولید نرم‌افزار درست عمل کنند ولی مشتری‌ها نسبت به فرایند تولید نرم‌افزار سفارش مشتری ناآگاه باشند، خیلی اوقات هم موضوع برعکس است یعنی مشتری می‌داند چه می‌خواهد، نیازمندی‌اش مشخص است، حدود و صغور کارش معلوم است، بهانه‌گیر نیست، تغییر مداوم در نیازمندی‌ها ندارد، دقیقه نودی نیست، کارشناسان خوبی دارد و مشکلات مالی هم ندارد ولی این شرکت یا تیم نرم‌افزاری یا شخص برنامه‌نویس (فریلنسر) است که کارش گیر دارد و پروژه را به خوبی جلو نمی‌برد.
انتخاب ابزار نامناسب
تیم‌ها معمولاً عادت دارند همه کارهایشان را با یک ابزار واحد انجام دهند. مثلاً یک تیم دات‌نتی سعی می‌کند هر نوع پروژه نرم‌افزاری را با ابزارهای موجود در دات‌نت انجام دهد. حتی بدتر از آن ممکن است خودش را محدود به آن قسمتی از دات‌نت نماید که به آن تسلط بیشتری دارد. مثلاً چون تخصصش برنامه‌نویسی وب است هر نوع کار را با ASP.NET انجام می‌دهد.
بعضی کارها برای بعضی ابزارها زیادی سبک یا زیادی سنگین هستند. اگر قرار است یک پروژه‌ای فقط یک یا دو کاربر Admin داشته باشد شاید بهتر باشد به جای استفاده از یک Membership Manager فول امکانات از یک ابزار ساده‌تر مثل امکانات داخلی خود وب‌سرورها استفاده شود. خیلی وقت‌ها استفاده از یک دیتابیس جمع و جور مثل MySQL یا Sqlite ترجیح دارد به یک دیتابیس بزرگ مثل MS SQL یا Oracle چرا ممکن است فقط از چند درصد امکانات آنها استفاده شده باشد. همین مسئله در مورد زبان برنامه‌نویسی هم مصداق دارد. گاهی اوقات PHP یا Ruby خیلی بهتر از Java یا C# جواب می‌دهند و بالعکس. خلاصه این که تیم‌های نرم‌افزاری تک منظوره گاهی اوقات باعث می‌شوند که کارهای غیر ضروری به پروژه تحمیل شوند.
این مسئله در مورد معماری‌های نرم‌افزاری مثل MVC و ابزارهای اتوماسیون مثل git و TFS هم مصداق دارند.
عدم شناخت نسبت به کارهای موجود
فکرش را بکنید یک نفر به شما سفارش یک نرم‌افزار CMS می‌دهد. آیا بهتر نیست قبل از دست به کار شدن نگاهی به ابزارهای موجود مثل Orchard CMS یا WordPress و جوملا بیندازید؟ شاید بتوان با به کار بردن آنها بخش زیادی از هزینه و زمان را صرفه جویی کرد. نوشتن یک ابزار کامل به صورت صفر تا صد هنر نیست. گاهی اوقات استفاده از جوملا و توسعه یک Addon برای آن خیلی بهتر و سریع‌تر می‌تواند کار مشتری را راه بیندازد. حتی گاهی اوقات بهتر است ۲۰۰ دلار بدهید یک component نرم‌افزاری را بخرید تا این که وقت بگذارید و آن را از اول بنویسید.
ارتباط ضعیف با مشتری
مشتری‌های فقط در حوزه کاری خودش تخصص دارند، آنها توسعه دهنده نرم‌افزار یا تحلیل‌گیر سیستم نیستند. گاهی اوقات باید یک بخش از کار را از ابتدا تا انتها جز به جز با مشتری تطبیق کرد. باید هزینه و تاثیر هر کدام از تغییرات یا حالات برای وی به طور کامل توضیح داد شود تا بتواند انتخاب درستی داشته باشد. بسیار پیش می‌آید که مشتری روی یک قابلیت کوچک مانور خیلی زیادی می‌دهد در حالی که پیاده‌سازی آن قابلیت فقط چند ساعت زمان می‌برد و بالعکس یعنی مشتری یک سری درخواست‌ها دارد که از نظر خودش خیلی ساده و کم اهمیت هستند در حالی که ممکن است انجام هر کدام از آنها یک هفته طول بکشد. باید به مشتری یاد داد که هر تیکه از کار را که دریافت می‌کند تست کند و زیر بار آزمایشی ببرد. همه را موکول نکند به زمان تحویل نهایی کار. خلاصه این که از آن دست شرکت‌ها و تیم‌هایی نباشید که بعد از امضای قرارداد غیب می‌شوند و درست دو روز مانده به زمان تحویل نهایی کار یک باره ظاهر می‌شوند با نرم‌افزاری که بخش زیادی از آن بر اساس پیش فرض‌های فقط شما ساخته شده است.
انجام چند پروژه با هم
به خاطر ترس از دست دادن پروژه‌های جدید یا ترس از خرابی بازار در چند ماه آینده یا به خاطر اعتماد بیش از حد به توانایی‌های خود و تیمتان و یا حتی به خاطر آن که فکر می‌کنید پروژه‌ای به خاطر ارزان بودن استحقاق وقت اختصاصی شما را ندارد، اقدام به انجام چند پروژه با هم نکنید. حتی اجازه ندهید مشتری پروژه‌ای را تعلیق کند یا در اجرا و تحویل آن وقفه بیندازد که مجبور شوید به خاطر فرار از بیکاری تیم یک پروژه دیگر را به طور موازی شروع کنید. بیشتر وقت‌ها می‌توان نیاز به پروژه هم زمان را با کمی پوشش مالی جبران کنید. اما در هر حال بدانید که انجام چند پروژه با هم باعث پایین آمدن کیفیت کار، نارضایتی مشتریان، کش آمدن بیخودی آن و افزایش فشار و استرس بر شما و تیم خواهد شد. به طور خلاصه سعی کنید تا می‌توانید توپ را در زمین خود نگه ندارید. پروژه اگر با سرعت انجام شود خیلی از اختلافات پیش نمی‌آید در غیر این صورت مشکلات با مشتری به صورت تصاعدی افزایش پیدا می‌کند. در پروژه‌هایی که کش می‌آیند ممکن است یواش یواش نظر مشتری نسبت به قسمت‌هایی از کار عوض شود، وضعیت مالی‌اش تغییر کند یا مدیریت جدید علاقه‌اش به IT کمتر از مدیریت قبلی باشد.
تخمین نادرست قیمت و زمان
این موضوع در تیم‌های تازه کار مصداق بیشتری دارد. بیشتر اوقات هم این تخمین نادرست کمتر و کوچک‌تر از مقدار واقعی است. به این معنی که زمان واقعی پروژه چهار ماه است ولی تخمین شرکت سه ماه است. تخمین نادرست زمانی باعث تداخل با پروژه‌های بعدی، افزایش فشار کار و استرس و ضرردهی می‌شود. این موضوع ناخودآگاه روی کیفیت کار تحویلی به مشتری هم تاثیر گذاشته و نارضایتی او را هم به دنبال خواهد داشت. تخمین نادرست هزینه‌ای هم اثرش مشابه اثر تخمین نادرست زمانی است. شرکت مجبور می‌شود از منابع ارزان قیمت‌تری برای انجام پروژه استفاده کند یا این که برخی از فرایندها مثل تست و کنترل کیفیت یا خوانایی کد و ساختار آن را کاهش دهد تا جبران هزینه شود. همه این‌ها باعث نارضایتی مشتری شده، فرایندهای پشتیبانی و افزودن یا تغییر قابلیت‌های جدید و موجود را دچار مشکل کرده و brand شرکت و تیم تولید کننده نرم‌افزار را به خطر می‌اندازد.
استفاده از تیم نامناسب
همراه کردن برنامه‌نویسان و توسعه دهندگان کم انگیزه، کم تلاش یا کم دانش و کم تجربه تاثیر بدی روی پیشرفت پروژه می‌گذارد. آنها باعث عدم تحقق پیش‌بینی‌های زمانی، پر باگ شدن نرم‌افزار، کثیف شدن کد و کاهش انسجام تیم می‌شوند. البته خیلی اوقات مشکل از نحوه چینش تیم و مدیریت آن است. استفاده از یک database designer به جای یک طراح رابط کاربری ایده خیلی جالبی نیست.
عدم تسلط و مدیریت کافی بر پروژه
این مورد هم در تیم‌ها و شرکت‌های تازه کار رواج بیشتری دارد. چینش نامناسب اعضای تیم که در مورد قبل نیز اشاره شد، تقسیم نامناسب کارها بین منابع موجود، تخمین غلط هر یک از بخش‌ها، ضعف در تشخیص وابستگی اجزا به یکدیگر، ضعف در تعیین و رعایت اولویت‌ها و مدیریت ضعیف بر مسائل فنی تیم از جمله مهم‌ترین نقاط ضعف مدیریت در پروژه‌های نرم‌افزاری است. ضعف در مدیریت پروژه به معنی تاخیر در تحویل کار، خارج شدن پروژه از چارچوب زمانی و هزینه‌ای، کیفیت پایین خروجی و حتی در برخی موارد عدم تکمیل پروژه و شکست کامل آن است.
قبول کردن بی‌چون و چرای هر نوع درخواست مشتری
بسیار دیده می‌شود (حداقل در ایران) که شرکت‌های نرم‌افزاری برای آن که بتوانند یک پروژه را بگیرند (خصوصاً وقتی که مدیر فروش مسئول قضیه است) هر چیزی را که مشتری بخواهند می‌پذیرند، از جمله تغییرات ساختاری در برنامه، تغییرات عمده UI، انواع تبدیل داده، انواع قابلیت‌های نامتعارف، تغییر در حین توسعه، پشتیبانی آنچنانی و غیره و غیره. قبول کردن تعهدات غیر قابل انجام یا تعهداتی که باعث انبساط پروژه و بیرون زدن آن از چارچوب هزینه‌ای زمانی شده یا منابع مناسب برای انجام آن وجود ندارد سرانجامی جز شکست، ضرر و زیان، فشار و استرس ندارد.
پشتیبانی ضعیف
نرم‌افزار بدون پشیتبانی مناسب چندان مفید نیست. خصوصاً اگر کاربران آن چندان فنی نباشند. برخی شرکت‌ها و تیم‌ها عمر کوتاهی دارند و بعد از انجام چند پروژه از بازار خارج می‌شوند. این طور شرکت‌ها باعث از بین رفتن اعتماد مشتریان به عموم شرکت‌های نرم‌افزاری می‌شوند. بعضی شرکت‌های دیگر اصلاً به پشتیبانی نرم‌افزار فکر نکرده‌اند با جزییات آن آشنا نیستند و حتی منابعی هم برای آن ندارند. این طور شرکت‌ها باعث می‌شوند مشتری نتواند کارایی لازم را از نرم‌افزار داشته باشد، نارضایتی او بالا برود و حتی در مواردی استفاده از نرم‌افزار را متوقف نماید. پشتیبانی دردسرهای خاص خودش را دارد. تلفن‌های بد موقع باعث کاهش تمرکز تیم می‌شود، بعضی مشکلات مشتری ناشی از خود نرم‌افزار نیست بلکه موارد ساده‌ای مثل فراموش کردن رمز ورود به سیستم، دستکاری تنظیمات نرم‌افزار توسط یک آدم ناشی، مشکلات نصب نرم‌افزارهای Third Party مثل دیتابیس و غیره است که با وجود عدم ارتباط مستقیم با نرم‌افزار مجبور هستید برای آنها وقت بگذارید.
نتیجه‌گیری
توسعه نرم‌افزار سفارش مشتری فقط نوشتن کد نیست. یک برنامه‌نویس صرف ممکن است نتواند یک شخص یا تیم توسعه نرم‌افزار سفارش مشتری خوب هم باشد. علاوه بر مهارت‌های توسعه نرم‌افزار (فنی) نیاز به مهارت‌های ارتباطی و مدیریتی و از همه مهم‌تر تجربه زیاد هم هست. در این کار تجربه بخش خیلی مهمی را بازی می‌کند. به دست آوردن این تجربه رایگان نیست و یک شبه هم به دست نمی‌آید. شکست در چند پروژه، فشار و استرس روزهای پایانی قرارداد در چندین قرارداد اول و ضررهای مالی حداقل هزینه‌های به دست آوردن چنین تجربه‌ای است.
