برون‌سپاری خدمات تخصصی – ۶

طی پنج قسمت قبلی این مطلب سعی کردم مشکلاتی که سر راه برون‌سپاری خدمات تخصصی بین شرکت‌های داخلی و برنامه‌نویس‌ها به ذهنم می‌رسد را دسته‌بندی کنم. به نظر من به طور کلی ۴ نوع مشکل برای برون‌سپاری وجود دارد:

۱- عدم اطمینان کارفرماها (قسمت ۲)

۲- نبود ادبیات مشترک بین کارفرما، برنامه‌نویس‌ها و کارمندان شرکت مقصد (قسمت ۳)

۳- استاندارد نبودن کارها و بی‌نظمی در شرکت‌ها (قسمت ۴)

۴- عدم اطمینان برنامه‌نویس‌ها (قسمت ۵)

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

لینک نوشته‌های این سری:

برون‌سپاری خدمات تخصصی – بخش اول

برون‌سپاری خدمات تخصصی – ۲

برون‌سپاری خدمات تخصصی – ۳

برون‌سپاری خدمات تخصصی – ۴
برون‌سپاری خدمات تخصصی – ۵

برون‌سپاری خدمات تخصصی – ۵

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

۱- آیا از لحاظ تخصصی در سطح مورد نظر هستند؟ بعضی شرکت‌ها آنقدر سطح پایین کار می‌کنند که نمی‌شود با ایشان کار کرد و نه می‌شود سطح کاریشان را بالا آورد.

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

۳- آیا کار شرکت مورد نظر آنقدر زیاد هست که ارزش برنامه‌ریزی و وقت گذاشتن داشته باشد؟ کار بعضی شرکت‌ها با چند ساعت مشاوره و برنامه‌نویسی تمام می‌شود و آنقدر نیست که بتوان روی آن حساب کتاب کرد.

۴- آیا شرکت مورد نظر مشکل پرداخت ندارد؟ شرکت‌های زیادی وجود دارند که همیشه پرداخت‌های آخرشان دچار مشکل شده و این تاخیر بعضاً تا یک سال هم طول می‌کشد.

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

توجه:
این نوشته جز سری نوشته‌های «برون سپاری خدمات تخصصی» می‌باشد.

برون‌سپاری خدمات تخصصی – ۴

یکی دیگر از مشکلات این موضوع، استاندارد نبودن و بی‌نظمی کارها در شرکت‌هاست. این مشکل بیشتر گریبان‌گیر نیروی کار بیرون شرکتی است که قرار است در داخل یک شرکت خدمات تخصصی ارائه دهد.

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

به عنوان دیگر مصادیق می‌توان به موضوعات دیگری نیز اشاره کرد: نبود مستندات کافی، عدم استفاده‌ی صحیح معماری‌های رایج، استفاده‌ی نامتعارف از فناوری‌ها و روش‌های مرسوم، عدم استفاده از نرم‌افزارهای Source Control، نام‌گذاری‌های نامناسب در سورس کد، استفاده از فناوری‌های متنوع برای یک کار یکسان مثل استفاده هم‌زمان از ADO و EF، NHibernate، SQL Server، MySQL و غیره در یک پروژه‌ی متوسط و…

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

توجه:
این نوشته جز سری نوشته‌های «برون سپاری خدمات تخصصی» می‌باشد.

برون‌سپاری خدمات تخصصی – ۳

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

به عنوان مثال: کارفرما منظورش از Component یک چیز است ولی برنامه‌نویسان شرکت برداشت دیگری از Component دارند. مدیر پروژه منظورش از تست، Integration Test است در حالی که منظور برنامه‌نویس Unit Test است. کارمند داخل شرکتی تفاوت زیادی بین Bug و Feature قائل نمی‌شود در حالی که این دو برای نیروی بیرون شرکتی تفاوت زیادی با هم دارند.

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

به هر حال نبود ادبیات مشترک هم ترس طرفین را نسبت به کار با یکدیگر زیاد می‌کند، هم دوباره کاری را زیاد می‌کند و هم هزینه‌ی کار را بالا می‌برد.

توجه:
این نوشته جز سری نوشته‌های «برون سپاری خدمات تخصصی» می‌باشد.

برون‌سپاری خدمات تخصصی – ۲

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

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

نتیجه‌ی این مسائل این می‌شود که کارفرما ترجیح می‌دهد کار تخصصی‌اش را به فردی کم تجربه‌تر ولی آشناتر بسپارد تا به فردی با تجربه‌تر ولی ناآشنا.

توجه:
این نوشته جز سری نوشته‌های «برون سپاری خدمات تخصصی» می‌باشد.

برون‌سپاری خدمات تخصصی – بخش اول

همیشه یک ایده وسوسه کننده در ذهن من بوده برای تخصصی کار کردن. چون این ایده هنوز در ذهن خودم هم جا نیفتاده مجبورم بیشتر با مثال توضیح بدهم.

فرض کنید یک شرکت نرم‌افزاری با ۵ الی ۱۰ برنامه‌نویس وجود دارد که ۱- قصد کار کردن با یک تکنولوژی جدید مثل ASP.NET MVC یا NHibernate را دارد یا ۲- می‌خواهد از ابزاری مثل Git برای سورس کنترل استفاده کند یا ۳- قصد بهبود شبکه داخلی خودش را دارد و می‌خواهد مثلاً پهنای باند اینترنتی را به نحو مقتضی بین کامپیوترها تقسیم کند. یا این که ۴- جدیداً مشکلات حادی با MS SQL Server پیدا کرده و می‌خواهد مسائلی مثل حجم خیلی زیاد دیتابیس، collation و ایندکس‌گذاری را در آن حل کند یا ۵- شرکت در محیط مشتری‌هایش مشکلات زیادی با فونت و حروف عربی-فارسی دارد و می‌خواهد این مشکل را یک بار برای همیشه با اعمال استانداردهای مرتبط حل کند یا ۷- شرکت می‌خواهد مسائل مشترکی را مثل اتصال به دستگاه کارت‌خوان، پرینت بارکد، تولید دیسکت بیمه، اتصال به نرم‌افزارهای جانبی مثل اکسل، Word و…، پرینت روی چک بانک‌های مختلف، پیاده‌سازی پروتکل ECE و غیره را که بارها و بارها در شرکت‌های مختلف حل شده‌اند را حل کند یا این که ۸- شرکت حس می‌کند تیم برنامه‌نویسی‌اش در مسائلی مثل documentation یا test ضعف دارد و به نحوی می‌خواهد این مشکلات را کاهش دهد یا این که ۹- شرکت مشکل خاصی ندارد ولی می‌خواهد برای چند سال آینده‌ش برنامه‌ریزی کرده و سمت و سوی تکنولوژی‌های موجود را بداند.

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

جواب دادن به این سوالات نیازمند به فکر کردن به مسائل خیلی زیادی است. علاوه بر این لازم است سوالات زیادی مطرح شده و به آنها پاسخ مناسب داده شود. طبق معمول نظرات دیگر همکاران و نظرات مدیران شرکت‌ها هم می‌تواند خیلی کارساز باشد. جرقه نوشتن این نوشته از مطلب «شبکه مجازی متخصصین و قوانین واقعی مورد نیاز» وبلاگ بهساد زده شد. این نوشته ادامه دارد…