پیش نوشت:
آنچه می نویسم نظر شخصی من در این تاریخ (15 آبان 97) است و در آینده نزدیک یا دور و با یادگیریهای جدید ممکن است تغییر کند. همچنین این تحلیلها جنبه مطالعات آکادمیک ندارد و بیشتر از جنس تجربه است.
در این متن می‌خواهم درباره جوانب خرید یک اپلیکیشن موبایل برای یک استارتاپ بنویسم.
فرض کنید در یک استارتاپ طراحی محصولی انجام شده است و ساختار اپلیکیشنی به عنوان محصول استخراج شده است.
سوال اینجاست که اگر اپلیکیشن را به یک شرکت نرم‌افزاری سفارش دهم چه نتایجی خواهد داشت؟
دو سناریو را بررسی می‌کنم.
سناریو اول: ساختار اپلیکیشن به شرکت نرم‌افزاری تحویل داده شده و به ازای مبلغی مشخص، اپلیکیشن نهایی دریافت می‌شود. با توجه به ماهیت استارتاپی مجموعه و انعطاف پذیری بالای آن از نظر ذاتی، تیم تصمیم میگیرد تغییری بزرگ یا کوچک در اپلیکیشن ایجاد کند تا آنچه از فیدبکهای مشتری یاد گرفته در محصول اصلاح کند. در این صورت نیاز به قراردادی جدید با همان شرکت نرم‌افزاری قبلی داریم تا اصلاح محصول و آپدیت جدید ارائه شود. باید دقت کرد چون کد تنها در اختیار شرکت نرم‌افزاری قبلی است، تنها این شرکت امکان اصلاح محصول را دارد. بنابراین یک اهرم قدرتمند برای تعیین قیمت قرارداد جدید در اختیار این شرکت خواهد بود.
سناریو دوم:
در قرارداد اولیه اپلیکیشن و سورس کد خریداری شود.
در اینجا چند نکته مطرح می‌شود.
اول: آیا سورس کد به صورت کامل و صحیح تحویل داده شده؟ بخشی از منطق کد حذف نشده؟ بنابراین در این مرحله نیاز به بررسی صحت عملکرد کد تحویل داده شده توسط تیم فنی استارتاپ خریدار اپلیکیشن را داریم.
دوم: با فرض قابل کامپایل و اجرا بودن سورس کد تحویل داده شده، آیا کد فوق قابل فهمیدن و خواندن است؟ به بیانی دیگر آیا کد به صورت تمیز نوشته شده؟ کامنت گذاری شده و نام‌گذاری متغیرها و تابعها به صورت قابل فهم است؟ این مساله نیز کار یک تیم فنی است تا ساختار کد را بررسی کند و این مسائل را در کد تشخیص دهد.
سوم:کد تحویل داده شده در سطح تیم فنی استارتاپ هست؟ به بیانی دیگر اگر لازم باشد کد فوق اصلاح شود، آیا تیم فنی این توانایی را دارد؟ تمام روند فوق را طی کردم تا به این جمله تکراری برسم که: “خواندن کد دیگران سختتر از نوشتن همان کد است”
در واقع هر منطقی را با چند روش می‌توان پیاده‌سازی کرد. از طرفی هرکس استایلی در نوشتن کد دارد. این مساله باعث می‌شود نیم فنی استارتاپ خریدار اپلیکیشن، کاری سخت در فهمیدن کامل کد خریداری شده داشته باشد. در اینجا لازم به توضیح بیشتر است، عموما اتفاق می‌افتد که افراد فنی با سعی و خطا در کد مادر، سعی در ایجاد تغییر مد نظر خودشان در نرم‌افزار نهایی را دارند بدون اینکه کل ساختار تعامل بخشهای مختلف کد با یکدیگر را درک کرده باشند. این رویه عموما منبع باگهای اساسی نرم‌افزارهای اینگونه آپدیت شده است و دلیل آن هم روشن است: نفهمیدن تعامل کل بخشها با هم، تغییر یک جزء با امید تغییر کل سیستم آنگونه که انتظار داریم)
اما داستان اینجا تمام نمی‌شود و نمی توان گفت خرید اپلیکیشن کار غلطی است. حدود دو هفته پیش که در رویداد اینترنا 2018 در دانشکده کامپیوتر شرکت کردم هم تجربه مدیریت پروژه ای موفق با پرون سپاری را دیدم و مطمئن تر شدم که این مسیر شدنی است اما باید نکاتی در این میان رعایت شود. به عنوان مثال یکی از روشهای مرسوم تبدیل پروه به ماژولهای کوچکتر است و اینکه در نهایت با یک تیم فنی کوچک بتوانیم این بخشها را به هم متصل کنیم. این روند یک مساله مهم دارد و ان وجود فرد فنی خبره ای است که از صفر تا 100 پروژه را بفهمد و بتواند آنرا به بخشهای صحیح تقسیم کند. همچنین خروجی مد نظر برای برون سپاری را هم دقیقا مشخص کند که ماژولهای مختلف قابل وصل شدن به یکدیگر باشند.
در نهایت اما نمی توان سرعت را نادیده گرفت. اگر استارتاپی محصول صحیحی داشته باشد هرچه سریعتر وارد شود بیشتر برد می‌کند اما آیا می توان مطمئن بود که محصول طراحی شده ما نهایی است و به هدف می‌زند؟
(منبع عکس نوشته: https://in2computing.com)