NOZHAN

شرکت نرم افزاری و توسعه پلتفرم کسب و کار

شرکت نرم افزاری و توسعه پلتفرم کسب و کار

اسکوپ کاری شرکت های نرم افزاری در دو دسته مجزا قابل طبقه بندی است:

  • ایجاد سیستم آنلاین بر مبنای قالب های پیش ساخته و پیش فرض
  • ایجاد سیستم آنلاین اختصاصی بر اساس نیاز کسب و کار هدف

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

در دسته دوم، کسب و کار با در نظر داشتن دورنمای فعالیت و بازار، به سمت توسعه سامانه اختصاصی گرایش پیدا می‌کند. در این حالت کسب و کار ها با انتخاب بین in-house کردن پروژه نرم افزاری خود و یا برون سپاری، نقشه راه و معماری کسب وکار آنلاین خود را متصور می‌شوند و فرایند توسعه را آغاز می‌کنند.

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

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

بررسی یک مطالعه موردی : توسعه اختصاصی پلتفرم ژاکت

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

ژاکت تا چندی پیش خود بر بنای قالبی آماده بود که با تلاش دولوپر های in-house شرکت، ظاهری به مراتب شخصی تر داشت. به این معنا که با تغییر کد ها، ایجاد فیچر های جدید و بومی کردن پلاگین های موجود، سایت ژاکت تنها یک قالب وردپرس خریداری شده نداشت، بلکه یک قالب پیش ساخته‌ی سفارشی برای خود ایجاد کرده بود.

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

اشتباهات رایج در مسیر توسعه اختصاصی نرم افزار

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

چه زمانی کسب وکار باید به سمت توسعه اختصاصی پلتفرم برود؟

همانطور که در مقاله آنلاین شدن لازمه بقای کسب و کار سنتی گفتیم:

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

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

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

کیفیت هزینه دارد

و چه بهتر که این هزینه زود تر پرداخت شود تا دیرتر

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

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

پس چه زمانی، بهترین زمان برای هزینه کردن است؟

پاسخ ما این است : همین لحظه، چرا که هزینه حتی یک روز دیرکرد در این فرایند میتوانند برای کسب وکار هزینه گزافی باشد.

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

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

طراحی معماری سیستم

به تعریف ویکیپدیا معماری سیستم طراحی مفهومی است که سازه و/یا رفتار یک سیستم را تعریف می‌کند. معماری سیستم شامل اجزای اصلی سیستم و تعریف وظایف آن‌ها می‌شود. همچنین معماری سیستم زیر مجموعه ای اجزا یا sub-component را تعریف کردن و نحوه تعامل بین این اجزا و زیر مجموعه ها با سیستم اصلی را نمایش می‌دهد.

معماری سیستم

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

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

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

در اینجا ۲ سوال پیش می‌آید:

  1. آیا یک RFP مشخص توسط تیم ژاکت تنظیم شده بود؟ آیا در این RFP توضیحات کامل در باره کسب و کار ژاکت داده وجود داشت؟ آیا این RFP به صورت منسجم نیاز های ژاکت و دلیل مهاجرت به سیستم جدید را دارا بود؟
  2. آیا در انتخاب این تیم نرم افزاری دقت کامل شده بود؟ انتخاب یک تیم نرم افزاری فرایند پیچیده ای است، در این انتخاب تنها توانمندی فنی تیم نباید مورد بررسی قرار بگیرد بلکه نحوه تعامل او با کسب و کار، درک نیاز کارفرما و ایجاد رابطه متقابل و متعهدانه اهمیت بالایی دارد.

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

انتقال داده ها از سیستم قبلی به سیستم جدید

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

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

مهاجرت داده نیازمند برنامه ریزی دقیقی است چرا که داده در بسیاری از موارد رفتاری غیرقابل پیشبینی نشان می‌دهد. بسته به محیط جدیدی که داده به آن انتقال داده می‌شود، فرمت داده در مبدا و مقصد و یا تغییر پذیر بودن داده در فرایند مهاجرت مشکلات زیادی پیش می‌آید. به همین دلیل کل این مسیر را به ۳ بخش تقسیم می‌کنند.
۱- برنامه ریزی Planning
۲- مهاجرت داده Migration
۳- عملیات بعد از مهاجرت Post-Migration
زمان بندی این فرایند کاری مشکل است که ترجیحا نباید با فورس و عجله انجام شود

 Nearly 40 precent of data migration projects were over time, over budget, or failed entirely

source : Practical Data Migration / Jhony Morris

طبق گفته کارشناسان ژاکت، زمان برنامه ریزی شده برای این مهاجرت ۲ روز درنظر گرفته شده بود که با بروز مسائلی مانند قطعی اینترنت این زمان به ۱۲ روز افزایش یافت.

در حالت ایده آل ، برای فرایند مهاجرت داده باید زمانی حداقل ۲ هفته را در سیستم های پیچیده در نظر گرفت تا ترجمه داده ها به فرمت جدید و قراردادن آن ها در محیط جدید و سپس تست نهایی روی داده های جدید انجام شود.

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

انتخاب تکنولوژی مناسب

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

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

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

تست و پشتیبانی از پروژه نرم افزاری

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

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

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

تست در شرکت نرم افزاری
فرایند تست نرم افزار

 

بازه زمانی آماده سازی پروژه

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

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

در فرایند توسعه، از منظر زمان‌بندی دو حالت مشکل زا خواهد بود:

۱- زمان بندی بدون محدودیت
۲- زمان بندی بسیار فشرده

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

در صورت نیاز به in-house کردن فرایند، متخصصان مربوطه را در تیم های مشخصی جمع می‌کند. در صورت برون سپاری، شرکت نرم افزاری مد نظر را با دقت انتخاب می‌کند.

سپس کسب و کار در کنار تیم فنی in-house یا همکار، با مطالعه RFP موجود به یک معماری مشخص می‌رسند.

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

همراهی تیم فنی ( شرکت نرم افزاری ) و کارفرما

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

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

در این دو پست از بلاگ نوژن به تفصیل از برون سپاری و تیم های فنی گفته ایم.

شرکت نرم افزاری یا فریلنسر

برون سپاری

فازبندی تحویل پروژه نرم افزاری

مدل توسعه مبتنی بر تکرار یا Iterative Development، مبتنی بر متدولوژی اسکرام است. در این رویکرد توسعه، فرایند توسعه یک اپلیکیشن یا پلتفرم گسترده به بخش هایی کوچیک تر شکسته می‌شود. هر بخش را یک Iteration می‌نامند که شامل فرایند های برنامه ریزی، طراحی، توسعه، تست و ریلیز می‌شود.

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

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

در نهایت تبریک به ژاکت…

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

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

پاسخی بگذارید

10 − 6 =