دو روش برون سپاری پروژه های نرم افزاری در عمل

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

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

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

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

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

چرا شرکت‌ها به دنبال برون سپاری پروژه های نرم‌افزاری هستند؟

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

بسیاری از شرکت ها قبل از برون سپاری، تیم‌های داخل سازمان داشتند ولی به دلیل اینکه پروژه ها جلو نمی‌رفت فکر کردند که با برون سپاری می توانند سرعت دریافت خروجی ها را بالا ببرنند. عملاً زمانی که شما پروژه را برون‌سپاری می کنید ریسک انجام نشدن کار (چه از نظر ابعاد تکنولوژی یا مسائل منابع انسانی یا …) یا سرموقع انجام نشدن آن را، برون سپاری کردید و عملاً مجری این ریسک را قبول کرده است.

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

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

برای همین بسیاری از شرکت‌ها به فکر افتادند که دوباره تیم های نرم افزاری خود را ایجاد کنند و به جای برون سپاری از استراتژی درون سپاری بهره بگیرند.

مدل برون سپاری ها باید تغییر کند

شما در برون سپاری پروژه های نرم افزاری باید یک اصل طلایی را بخاطر بسپارید:

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

مثال کاربردی

برای اینکه این مثال را با هم چک کنیم، فکر کردم مدل نقشه واردلی می‌تواند به ما در درک اصل طلایی برون سپاری کمک کند.

تصویر بالا نقشه واردلی را نمایش میدهد. این نقشه در واقع دو بعد اساسی دارد، بعد جریان ارزش (اینکه اجزای یک سیستم با هم کار می کنند تا یک ارزش را به مشتری یا کاربر برسانند)، بعد تکامل (هر جزء سیستم، یک چرخه تکامل دارد).

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

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

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

مثال واقعی یک شرکت بورسی

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

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

در ادامه از نظر تکامل، هر کدام از اجزاء را در ستون خود قرار داد.

اکنون نوبت انتخاب برای درون سپاری و برون سپاری بود. (همانند شکل زیر)

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

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

اگر خود پلتفرم برون سپاری می شد، چه اتفاقی می‌افتاد؟

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

اما فکر کنید، یک تیم با انگیزه بر روی این پلتفرم کار کنند، خود آنها از کاربران بازخورد بگیرند، اصلاح کنند، دوباره نسخه جدید و …

سخن پایانی

برون سپاری پروژه های نرم افزاری بشدت در ایران با چالش مواجه شده است. بهترین شیوه این است که شرکتها در استراتژی برون سپاری خود تجدید نظر کنند. نه به این معنی که دیگر برون سپاری نکنند. اما آنچه برون سپاری می کنند را تغییر بدهند.

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

چابک و موفق باشید

اسد صفری

این نوشته قبلا در این آدرس منتشر شده بود