توسعه‌دهندگان نرم‌افزار و پیشرفت شغلی

برنامه‌نویس‌های و توسعه‌دهندگانی که در شرکت‌های مختلف کامپیوتری، نرم‌افزاری و IT مشغول به کار هستند همگی یک دغدغه مشترک دارند. همه آنها به این فکر می‌کنند که آیا ماندن و ادامه کار در این شرکت به جز دریافت حقوق و مزایا عایدی دیگری هم برای آنها دارد؟ آیا ماندن در شرکت رشد و پیشرفت شغلی متناسبی برای آنها به ارمغان می‌آورد؟ آیا بعد از چند سال کار رزومه آنها واقعاً پربارتر می‌شود یا این که صرفاً به سابقه کار آنها چند سال دیگر اضافه می‌شود؟ آیا ادامه فعالیت در شرکت توانایی‌های فنی و مدیریتی آنها را به اندازه کافی افزایش می‌دهد؟ اینها دغدغه‌هایی است که هیچ گاه برنامه‌نویسان را رها نکرده و نمی‌کند.

 

توانایی‌های مدیریتی (غیر فنی) و حرکت در سلسله مراتب شرکت بخش مهمی از پیشرفت شغلی به حساب می‌آید. این که شما به عنوان برنامه‌نویس Junior شروع کرده و پس از مدتی به شما عنوان Senior داده می‌شود بعدش تبدیل به مدیر تیم توسعه نرم‌افزار شده و سپس مدیر پروژه شده و در نهایت مدیر فنی شرکت می‌شوید نشان دهنده پیشرفت شغلی شماست. لازمه این پیشرفت شغلی این است که شرکت به اندازه کافی بزرگ بوده و حداقل یک یا دو تیم مثلاً ۸ نفره از برنامه‌نویسان در آن حضور داشته باشند تا بتوان نقش‌هایی مثل مدیر پروژه یا مدیر فنی را تعریف کرد. علاوه بر این شرکت مورد بحث باید دارای تعداد تیم دیگر برای پشتیبانی و فروش هم باشد تا مدیر عامل را آنقدر مشغول کند که خودش شخصاً نخواهد نقش مدیر فنی یا حتی مدیر پروژه را به عهده بگیرد.

 

خیلی از شرکت‌های تولید کننده نرم‌افزار در ایران آنقدر بزرگ نیستند که بتوانند چنین مسیری را برای پیشرفت شغلی افراد مهیا کنند. تعداد کم پروژه‌ها و جمعیت کم تیم‌های توسعه نرم‌افزار اجازه تعریف خیلی از این نقش‌ها را نداده و افراد و مدیران شرکت را مجبور به چند نقشی (آچار فرانسه) می‌کند. برنامه‌نویس Senior و مدیر تیم برنامه‌نویسی و گاهی اوقات مدیر پروژه تبدیل به یک نقش واحد به نام برنامه‌نویس با تجربه می‌شود که هیچگاه فرصت توسعه توانایی‌های مدیریتی و ارتباطی را پیدا نمی‌کند. نقش‌های مدیر پروژه و مدیر فنی هم در نقش مدیر عامل یا یک مدیریت ارشد دیگر ادغام شده و عملاً شرکت در سه سطح خلاصه می‌شود: برنامه‌نویس تازه کار، برنامه‌نویس با تجربه و مدیر عامل.

 

در مقابل شرکت‌های کوچک و متوسط شرکت‌های بزرگ وجود دارند که شامل همه یا بیشتر این نقش‌ها هستند و تصور اولیه بر این نیست که پیشرفت شغلی در این طور شرکت‌ها معنا دارتر است. اما اینجا هم اوضاع تعریف چندانی ندارد. چون خیلی از این شرکت‌ها بر اساس منافع گروهی و جناحی تشکیل شده‌اند، ورود به تیم‌ها و بالا رفتن از نردبان ترقی شغلی آنها همیشه هم بر اساس شایسته سالاری، مهارت‌ها و توانایی‌ها و توزیع فرصت‌های برابر برای پیشرفت نیست. منافع گروه‌های مختلف ایجاب می‌کند که شخصی بدون داشتن توانایی‌های کافی وارد تیم شود یا این که شخص دیگری عمدتاً بر اساس اصل «از خودمان است» تکیه بر جایگاه مدیریت پروژه بزند در حالی توانایی‌ها و تجارب کافی در این زمینه ندارد. خلاصه این که امید زیادی هم به این دست شرکت‌ها نیست چون به اندازه کافی بلوغ سازمانی پیدا نکرده‌اند، بروکراسی زیادی دارند و منافع گروهی و بعضاً فامیلی موجود در ساختار آنها فرصت‌های پیشرفت شغلی را ناعادلانه کرده است.

 

یکی دیگر از جنبه‌های پیشرفت شغلی که در مشاغل مرتبط با IT نمود بیشتری پیدا می‌کند توسعه مهارت‌های فنی مثل توسعه نرم‌افزار با تکنولوژی‌های مختلف، معماری سیستم، امنیت اطلاعات و غیره است. خوشبختانه از این جهت که این مهارت‌ها را مستقلاً هم می‌توان یاد گرفت اوضاع در این جنبه از پیشرفت شغلی کمی بهتر است. اما نه آنقدر بهتر که نتوان انتقادی به آن داشت. اصل بهبود و توسعه مهارت‌ها زمانی اتفاق می‌افتد که آن آموخته‌ها در حین کار اصلی مورد استفاده قرار بگیرد. نه این که در طول ۸ ساعت کاری از روش‌ها و فناوری‌های ۱۰ سال پیش استفاده شده ولی دلخوش باشیم به ۲ ساعتی که در شب با تکنولوژی‌های روز تمرین می‌شود. در کل در این زمینه شرایط شرکت‌های کوچک و متوسط نسبتاً از شرکت‌های بزرگ بهتر است. آنها انعطاف پذیری بیشتری دارند و راحت‌تر زیر بار سویچ به تکنولوژی‌های جدید می‌روند.

 

شاید با کمی توجه بیشتر به جنبه‌های مختلف پیشرفت شغلی در صنف توسعه‌دهندگان نرم‌افزار راحت‌تر بتوان درک کرد که چرا جابجایی نیرو در شرکت‌های نرم‌افزاری اینقدر زیاد است و چرا پیدا کردن و نگه داشتن یک برنامه‌نویس کار سختی است. توانایی‌ها و مهارت‌های فنی تنها چیزی است که برنامه‌نویس‌ها دارند. کمتر شرکتی حاضر می‌شود یک برنامه‌نویس کم توان را به صرف سابقه کار ده ساله‌اش در جایگاه مناسبی به کار بگیرد. برنامه‌نویسی مثل حسابداری، مهندسی عمران یا معلمی و نظامی‌گری نیست که عنصر سال‌های سابقه کار به تنهایی عنصر مهم و تعیین کننده‌ای برای وضعیت شغلی آنها باشد. برنامه‌نویسی که به روز نباشد (خودش خودش را به روز نکرده باشد یا شرکت این امکان را برای او مهیا نکرده باشد) ممکن است با آینده شغلی مبهمی روبرو شود.


پ.ن. ۱: این نوشته در لینکدین نیز منتشر شده است.

پ.ن. ۲: چند روز است که سایت disqus مسدود شده و  به همین دلیل قابلیت کامنت وبلاگ از کار افتاده است.

پروژه‌های خوب، شرکت‌های بد

همیشه هم این طور نیست که شرکت‌ها و تیم‌های تولید نرم‌افزار درست عمل کنند ولی مشتری‌ها نسبت به فرایند تولید نرم‌افزار سفارش مشتری ناآگاه باشند، خیلی اوقات هم موضوع برعکس است یعنی مشتری می‌داند چه می‌خواهد، نیازمندی‌اش مشخص است، حدود و صغور کارش معلوم است، بهانه‌گیر نیست، تغییر مداوم در نیازمندی‌ها ندارد، دقیقه نودی نیست، کارشناسان خوبی دارد و مشکلات مالی هم ندارد ولی این شرکت یا تیم نرم‌افزاری یا شخص برنامه‌نویس (فریلنسر) است که کارش گیر دارد و پروژه را به خوبی جلو نمی‌برد.

 

انتخاب ابزار نامناسب

تیم‌ها معمولاً عادت دارند همه کارهایشان را با یک ابزار واحد انجام دهند. مثلاً یک تیم دات‌نتی سعی می‌کند هر نوع پروژه نرم‌افزاری را با ابزارهای موجود در دات‌نت انجام دهد. حتی بدتر از آن ممکن است خودش را محدود به آن قسمتی از دات‌نت نماید که به آن تسلط بیشتری دارد. مثلاً چون تخصصش برنامه‌نویسی وب است هر نوع کار را با 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 مثل دیتابیس و غیره است که با وجود عدم ارتباط مستقیم با نرم‌افزار مجبور هستید برای آنها وقت بگذارید.

 

نتیجه‌گیری

توسعه نرم‌افزار سفارش مشتری فقط نوشتن کد نیست. یک برنامه‌نویس صرف ممکن است نتواند یک شخص یا تیم توسعه نرم‌افزار سفارش مشتری خوب هم باشد. علاوه بر مهارت‌های توسعه نرم‌افزار (فنی) نیاز به مهارت‌های ارتباطی و مدیریتی و از همه مهم‌تر تجربه زیاد هم هست. در این کار تجربه بخش خیلی مهمی را بازی می‌کند. به دست آوردن این تجربه رایگان نیست و یک شبه هم به دست نمی‌آید. شکست در چند پروژه، فشار و استرس روزهای پایانی قرارداد در چندین قرارداد اول و ضررهای مالی حداقل هزینه‌های به دست آوردن چنین تجربه‌ای است.

مشتری‌های ناآگاه و نرم‌افزارهای سفارش مشتری

مشتری که عمدتاً از جنس کارآفرین است به تیم نرم‌افزاری مراجعه می‌کند. ایده و نیازمندی‌هایش را مطرح می‌کند و درخواست می‌کند که بر اساس آنها یک نرم‌افزار یا سرویس وب تولید شود. اما در این میان به علت تازه وارد بودن در دنیای IT و حتی در دنیای کارآفرینی دچار اشتباهات زیادی می‌شود. چون اطلاعات و تجربه کمی در این موضوعات دارد دچار ساده انگاری شده و برآوردهای خیلی کوچکی از ابعاد کار می‌نماید. زمان را خیلی کم در نظر می‌گیرد، همین برآوردهای کوچک را در مورد بودجه کل کار و هزینه توسعه نرم‌افزار و همین طور پیچیدگی‌های IT انجام می‌دهد. نتیجه‌اش این می‌شود که سایت مشابه فیسبوک را با بیست میلیون پول و دو ماه زمان درخواست می‌کند. اگر هم اما و اگر بشنود می‌گذارد به حساب کیسه دوزی تیم نرم‌افزاری و سو استفاده آنها از تازه واردی او. البته تیم‌ها و شرکت‌های نرم‌افزاری کلاهبردار هم وجود دارند ولی من اینجا فرض را به این گرفته‌ام که مشتری داستان من خوش شانس بوده و با یک سری آدم حرفه‌ای و اخلاق‌گرا طرف حساب شده است.

 

توسعه نرم‌افزار به معنی سر هم کردن ماژول‌های آماده نیست

حساب مشتریان با تجربه، با اطلاع و صبور جداست ولی این سناریویی است که بسیار رایج است و رفتار خیلی از مشتریان و سفارش دهندگان تازه کار از آن تبعیت می‌کند. این نوع مشتریان نمی‌توانند به سادگی حساب توسعه نرم‌افزار (یعنی چیزی که از قبل وجود نداشته و باید طراحی و تولید شود) را از حساب استفاده از نرم‌افزارهای موجود و کانفیگ و راه اندازی آنها جدا کنند. خیلی از آنها فکر می‌کنند هر نوع وب سایت و web application را می‌توان با سر هم کردن چند ماژول وردپرس و جوملا، کانفیگ آنها و نهایتاً نوشتن ۱۰ الی ۲۰ درصد کل کار در قالب یک ماژول جدید انجام تولید کرد.

 

در دسترس بودن نرم‌افزار به معنای رایگان بودن آن نیست

متاسفانه برخی از آنها فکر می‌کنند چون ویندوز را به قیمت ۱ الی ۲ دلار از بازار رضا تهیه می‌کنند معنی‌اش این است که توسعه یک سیستم عامل مثل ویندوز کار خیلی سختی نیست و نهایتاً کار شش ماه یک تیم دانشجویی ۵ نفره است. در همین راستا تصورات غلطی وجود دارد که شرکت‌های نرم‌افزاری یک بار نرم‌افزار را می‌نویسند و بعد از آن با فروش مجدد نرم‌افزار به افراد دیگر سودهای کلانی به دست می‌آورند. رایگان بودن نرم‌افزارهای open source نیز مزید بر علت شده است.

 

تقلید بدون بررسی

داستان‌های موفقیت startupها و کارآفرین‌های آمریکایی از جمله فیسبوک و اینستاگرام از جدیدترها و مایکروسافت و IBM از قدیمی‌ترها مردم را شیدا کرده است. این داستان‌ها همان بلایی را سر کارآفرین‌ها آورده که شهرت فوتبالیست‌ها و هنرپیشه‌ها بر سر قوتبال دوستان و علاقمند بازیگری آورده است. هزاران نفر بخش مهمی از زندگی خود را صرف می‌کنند ولی فقط عده خیلی خیلی کم و انگشت شماری می‌توانند خودشان را به بالا برسانند.

 

تصورات غلط راجع به تسلط برنامه‌نویسان به حوزه کاری مشتری

یکی دیگر از مشکلات رایج این است که مشتری‌ها از تیم نرم‌افزاری انتظار دارند که به حوزه کاری آنها تسلط کامل داشته باشند و خودشان خیلی چیزها را از قبل بدانند و در سیستم لحاظ کنند. مثلاً کسی که در حوزه حسابداری فعالیت می‌کند انتظار دارد که تیم توسعه نرم‌افزار تمام ریزه کاری‌های حسابداری را بدانند. او به این موضوع توجه نمی‌کند که اگر قرار بود تیم نرم‌افزاری به ازای هر نرم‌افزاری که تولید می‌کند به همه جزییات آن حوزه هم تسلط پیدا می‌کرد آن وقت باید قبل از یاد گرفتن توسعه نرم‌افزار باید در تمام حوزه‌های کاری دیگر از جمله حسابداری، مخابرات، امور مالی، آموزش و پرورش، سلامت و پزشکی، جرایم و پلیس، بیمه، مالیات و بسیاری حوزه‌های دیگر نیز تسلط پیدا می‌کرد و به عبارتی دیگر عالم الدهر می‌شد. شاید به همین علت باشد که خیلی اوقات که نرم‌افزار کامل شده و به مشتری تحویل می‌گردد، مشتری با تعجب فراوان از نبود فلان مکانیزم صحبت می‌کند و انتظار داشت چنان چیزی که از نظر خودش بدیهی بوده در نرم‌افزار نیز وجود داشته باشد.

 

مکانیزاسیون افراطی

از جمله مشکلات دیگری که وجود دارد قاطی شدن بخش‌های قابل مکانیزه شدن و غیر قابل مکانیزه شدن است. مشتری به فرایندهای خودش نگاه می‌کند و علاقمند می‌شود که هر چیزی که وجود دارد و ندارد را مکانیزه کند و به نرم‌افزار منتقل کند. از جمله فعالیت‌های نگهبانی دم در و کنترل فعالیت‌های کارمند نام نویسی.

 

عدم هماهنگی داخلی

متاسفانه خیلی اوقات در جلسات بررسی و تحلیل سیستم متوجه می‌شویم که مشتری با افراد داخل تیم خودش هماهنگی نیست و دید و طرح مشترکی از کار خودشان ندارند و خیلی اوقات تازه در همان جلسه که با هم گفتگو می‌کنند تا به دیدگاه مشترکی برسند. این وسط نماینده تیم نرم‌افزارهای هم باید به آنها کمک کند تا آنها چیزی را که مربوط به او نیست را اصلاح نمایند. اصولاً خیلی از مشتر‌های نرم‌افزارهای سفارشی تیم‌های توسعه نرم‌افزار را با تیم‌های مشاوره مدیریتی و سیستمی اشتباه می‌گیرند.

 

نداشتن RFP

این یکی که نوبر است و با تجربه و بی تجربه نمی‌شناسد. به ندرت می‌توان یک مشتری پیدا کرد که قبل از شروع کار یک RFP کامل و شسته و رفته از کار خودش داشته باشد. RFP یعنی شرح کامل و شفافی از نیازمندی‌های مشتری که قرار است برای آن نرم‌افزار توسعه پیدا کند. بیشتر اوقات جلسات شفاهی اولیه که معمولاً هم عجله‌ای و بدون مزد از آب در می‌آیند جای این RFP را می‌گیرد. در حالی که درست آن این است که مشتری از قبل با کمک مشاور مورد اعتماد خودش نیازمندی‌های خودش را با دقت بررسی کرده و همه چیز برای خودش شفاف و واضح شده و سپس همه آنها را مکتوب کرده آنگاه به دنبال یک تیم یا شرکت نرم‌افزاری برای اجرای آن بگردد.

 

ندیدن جزییات اجرا

گاهی اوقات مشتریان چنان غرق در طراحی سیستم و مکانیزاسیون می‌شوند که یادشان می‌رود که این سیستم قرار است بعداً به طور واقعی در محیط واقعی مورد استفاده قرار بگیرند. آنها خصوصیات رفتاری و توانایی‌ها و ضعف‌های کارمنداشان، علایق مشتریان خودشان، محدودیت‌های فنی و خیلی چیزهای دیگر را فراموش می‌کنند و آخر سر به سیستمی می‌رسند که کمتر از ۲۰ درصد آن مورد استفاده واقعی قرار می‌گیرد.

 

ارزان بودن

نوشتن نرم‌افزار هرگز کار ساده و ارزان قیمتی نبوده است. برنامه‌نویس‌ها منابع گران قیمتی و حساسی هستند. نیاز به آموزش دارند، نرخ جابجایی آنها بین تیم‌ها و شرکت‌ها و حتی مهاجرت آنها خیلی بالاست و مدیریت کردن آنها هم کار ساده‌ای نیست. به این بیفزایید پیچیدگی ذاتی خود نرم‌افزار و مدیریت پروژه‌های تولید نرم‌افزار را. به همین علت خیلی سخت است که بتوان یک نرم‌افزار ارزان قیمت تولید کرد.

 

نتیجه گیری

این طور مباحث را نمی‌توان را بدون مثال به خوبی توضیح داد و مثال‌های واقعی ممکن است اطلاعات محرمانه اشخاص را به خطر بیندازد. کاش فرصتی بود و می‌شد که بهتر به این موضوعات پرداخت شک ندارم که بیشتر مشتری‌های ناآشنا به کار هم اگر درست راهنمایی شوند می‌توانند تبدیل به مشتریان طلایی شده و کارهای بسیار ارزشمندی انجام دهند که آخر کار همه راضی باشند و کسی با دیگران contact پیدا نکند. یادآوری این که این مشکل مختصات ایران نیست و کم و بیش در کشورهایی دیگر هم وجود دارد.