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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

راه حل های ساده

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

ASP.NET Automatic DataBinding

ASP.NET مکانیزم خودکاری برای data binding صفحات دارد. در این مکانیزم همه کنترل‌های data aware صفحه شناسایی شده و توسط موتور ASP.NET با ترتیب معینی که ظاهراً قابل عوض کردن هم نیست data bind می‌شوند. این مکانیزم در بیشتر اوقات خیلی مفید و کار راحت کن است. اما این موضوع وقتی که تعداد کنترل‌های data aware از حد معینی بیشتر می‌شود مشکل زا خواهد شد. یکی از مثال‌های معروف این مشکل وقتی است که یک DropDownList و یک GridView در صفحه قرار دارند. DropDownList به ObjectDataSourceی به نام ods1 و GridView هم به ObjectDataSourceی به نام ods2 وصل هستند. فرض کنید یکی از پارامترهای ods2 به SelectedValue مربوط به DropDownList وصل است. در این حالت بعضی وقت‌ها دچار این مشکل می‌شویم که GridView زودتر از DropDownList مورد DataBinding قرار می‌گیرد. در نتیجه SelectedValue مربوط به DropDownList همیشه خالی بوده و مقدارش نامعتبر خواهد بود.

راه حلی که من همیشه استفاده می‌کردم پاک کردن صورت مسئله بود. یعنی هر نوع DataSource را از صفحه برداشته و خودم عملیات خواندن/نوشتن اطلاعات از/به دیتابیس را به طور دستی بر اساس eventهای مختلف کنترل‌های موجود انجام می‌دادم. نا گفته پیداست که این کار چه زحماتی ایجاد می‌کرده و چه قدر خطا ساز بوده است.

راه حل ساده‌ای که تازگی‌ها پیدا کرده‌ام این است که Data Sourceها و کلیه مکانیزم‌های مربوطه را در صفحه نگه داشته و به اصطلاح کاملاً به صورت declarative programming عمل کنم. اما برای رفع مشکل ناهماهنگی eventها یا اصطلاحاً Event Taming، مکانیزم Data Binding خودکار ASP.NET را از کار انداخته و خودم عملیات Binding یعنی صرفاً معرفی DataSourceها به کنترل‌ها و فراخوانی DataBind کنترل‌ها را به طور دستی از طریق Code Behind انجام می‌دهم. البته از کار انداختن مکانیزم خودکار Data Binding در صفحات ASP.NET کار چندان سختی نیست. فقط کافی‌ست خصیصه DataSourceID را از تمام کنترل‌های صفحه برداشته و بعداً خودتان آنها را از طریق code behind تنظیم کنید. جهت کسب اطلات بیشتر به این پیوند مراجعه کنید.

AutoComplete TextBox

AutoComplete TextBox امکانی است که از طریق آژاکس به صفحات وب اضافه می‌شود. با کمک این امکان وقتی کاربر چند حرف اول کلمه مورد نظرش را در TextBox تایپ می‌کند، تعدادی از موارد مشابه هم به وی نشان داده می‌شود. این موارد مشابه از طریق فراخوانی یک وب سرویس و به شیوه آژاکس به دست client می‌رسند. اجرای چنین راه حلی مستلزم نوشتن یک وب سرویس و استفاده از کنترل‌های خاصی مثل AutoCompleteExtender از کتابخانه Ajax Control Toolkit می‌باشد.

اما اگر از کنترل‌های Telerik استفاده می‌کنید و حجم دیتا خیلی زیاد نیست، یک راه حل ساده‌تر وجود دارد. این راه ساده‌تر استفاده از کنترل استاندارد RadComboBox و تنظیم خاصیت‌های AllowCustomText و Filter آن است. به این ترتیب بدون استفاده از هیچ نوع وب سرویس و هیچ نوع آژاکسی می‌توان به کاربر قبولاند که این Combo خاصیت AutoComplete دارد. البته اگر از Telerik هم استفاده نمی‌کنید، فکر می‌کنم بتوان کنترل DropDownList از ASP.NET را طوری دستکاری کرد که از آن بشود چنین استفاده‌ای کرد.

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

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

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

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

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