وبلاگ افشار محبی

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

یکی از تاثیر گذارترین عوامل شکست این دست همکاری‌ها، کم اطلاعی صاحب ایده یا همان کارآفرین است. همه توسعه دهنده‌هایی که کار پروژه‌ای یا Freelance انجام داده به احتمال زیاد با این موضوع آشنا هستند. سفارش دهندگانی وجود دارند که فقط ظاهر کار را می‌بینند و از پشت زمینه آن خبر ندارند. مثلاً یک بار جستجوی دیجی کالا را می‌بینند بعدش همان Feature را در وب سایت خودشان می‌خواهند. مثال برعکس هم وجود دارد. مورد داشتیم که طرف حاضر بوده برای رفع مشکل «ی» و «ک» فارسی دو برابر یک Search ساده دیتابیسی پول پرداخت کند. منظورم حالتی است که یک موضوعی که نیاز به برنامه‌نویسی کمی دارد از دید کارفرما بسیار بزرگ دیده شده، آن هم به این علت که خودش به آن Feature خیلی نیاز داشته یا این که هیچ جا مشابه آن را ندیده است.

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

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

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

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

عدم آشنایی کارآفرین با فرایندها و ساختارهای مهم تولید نرم‌افزار یکی از بزرگ‌ترین دلایل بروز تنش و شکست پروژه است. کارآفرین نوعی ما خیلی عجله دارد. او می‌خواهد هر Feature که به ذهنش رسید را فوری پیاده‌سازی کند. غافل از این که زمان کافی برای تست در نظر بگیرد یا این که تفاوت بین محیط Development و Production را در نظر بگیرد. او شاید نداند که اضافه کردن یک فیلد کوچولو به یکی از موجودیت‌ها ممکن است خیلی بیشتر از یک ساعت طول بکشد.

یکی از سندرم‌های پر تکرار این موضوع نداشتن Integration کافی بین اجزای کار و Communication ضعیف بین اعضای تیم است. در بعضی از پروژه‌های برنامه‌نویسی تیم شناخت قبلی از هم ندارد. اصلاً تیم را خود مشتری تشکیل داده است. یک نفر Mobile Developer را کنار یک نفر Web Developer می‌نشاند و انتظار دارد تیم با حداکثر کارایی پیش برود. روی ارتباط بین API و Client به درستی تعریف نشده. مکانیزمی هم برای کار روی آن در نظر گرفته نشده. مشتری اینها را به خود تیم واگذار کرده. تیم هم چون پروتکل مناسبی ندارد یا کار را خراب می‌کنند یا این که مدام با هم اختلاف پیدا می‌کنند. این مورد را خودم خیلی زیاد دیده‌ام.

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

.

شما هم نظری دارید؟ یا تجربه‌ای دارید؟ با ما در میان بگذارید.

.

در همین راستا دو مطلب زیر را هم بخوانید:

• توسعه و تولید نرم‌افزار با قراردادهای ساعتی
• ابزار ارتباطی تیمی: تلگرام یا اسلک؟