در واپسین روزهای اسفندماه 1398 و در قرنطینه خانگی در حال مرور توییت‌های ملت بودم که به توییت نیما شفیع‌زاده برخوردم. همین مورد بهانه‌ای شد تا در خصوص بدقولی برنامه‌نویس‌ها چند خطی بنویسم. البته قبلش دستم رو 20 ثانیه شستم!
بله درسته، دسته زیادی از برنامه‌نویس‌های ایرانی و خارجی به دلایلی مختلفی که برخی از اونها رو خواهم گفت تجربه بدقولی داشتند. این مورد صرفاً مختص ایران هم نیست اما شاید دلایل فرهنگی باعث شده باشه این مورد در ایران بیشتر به چشم بیاد.
به نقل از پروفسور صمیعی. (من نگفتما)
دسته زیادی از برنامه‌نویس‌ها مهارت‌های کدنویسی رو به صورت خودخوان و بر حسب تجربه یاد گرفتن و در همین مسیر به سمت دنیای فریلنسری سوق داده شدند. یکی از عارضه‌های فریلنسری، شوق زیاد (یا حرص زدن) برای گرفتن چندین پروژه به صورت همزمان است.
این هیجان باعث میشه تا فریلنسر در حین ارسال پیشنهاد، تخمین نامناسبی از زمان مورد نیاز در ذهنش شکل بگیره و وارد انجام پروژه بشه. در حین انجام کار به دلیل بروز مسائل غیرقابل پیش بینی و همچنین عدم تمرکز کافی بر روی یک کار، به احتمال زیاد شاهد به تعویق افتادن موعد تحویل خواهیم بود و این مورد تجارب تلخی را رقم خواهد زد.
ما در پارسکُدرز نیز به وفور شاهد چنین موردی هستیم و یکی از راهکارهای ما برای بهبود این مشکل ایجاد محدودیت ها برای دریافت پروژه همزمان هست.
این بند در خصوص روش های تخمین زمان نیست، بلکه اشاره‌ای است به چالش‌ها و حقایقی که در خصوص تخمین زمانی رخ می‌دهد و باعث بدقولی میشه.
اگر تجربه برنامه نویسی داشته باشید می دانید که یکی از اصلی ترین سئوالات کارفرمایان در حین مذاکرات اولیه پروژه پرسش در خصوص زمان مورد نیاز برای انجام پروژه است. در واقع پاسخ به این سئوال که چقدر زمان مورد نیاز است بسیار سخت است. چون ماهیت این کار با حل مسئله روبروست و ما دقیقاً نمی دونیم پاسخ مشکل چه زمانی پیدا می شه.
طی سال‌های گذشته تعدادی چهارچوب و متدولوژی توسعه نرم افزار خلق شدند که یکی از اهدافشون ارائه راهکارهایی برای تخمین بهتر زمان بوده. از جمله اینها میشه به روش دلفی یا اسکرام اشاره داشت.
اما چنین روش‌هایی بیشتر در تیم‌های برنامه نویسی به کار گرفته میشه و اگر مجری پروژه یک برنامه نویس منفرد دورکار یا فریلنسر باشه به احتمال زیاد بر اساس عادت همیشگی خودش عمل خواهد کرد و بر همین اساس احتمال تخمین زمانی اشتباه بالا میره و باعث خلق تجربه بد برای کارفرما میشه.
نکته مهم: بر اساس تجربه خودم، مشاهداتم در پارسکدرز و مرور چند کتاب و مقاله در این باب، یکی از بهترین راهکارهای جلوگیری از بدقولی ارتباط مستمر و صادقانه با کارفرما است. این رفتار باعث میشه تا باب گفتگو و تعامل باز بشه و کارفرما یا ذی نفعان از روند کار و مشکلات رخ داده اطلاع پیدا کنند و اثرات روانی ناشی از تاخیرها کاسته بشه.
در همین راستا بخوانید: کارهایی که یک فریلنسر حرفه ای انجام می دهد
در همین راستا بخوانید: کتاب رایگان “واقعی شوید”
اما متاسفانه بسیاری از فریلنسرها و برنامه نویسان منفرد یا تیم‌هایی که از روش‌های مرسوم و پذیرفته شده استفاده نمی کنند در زمان شروع کار با رویی گشاده قول های فراوانی می دهند و در افق محو می شوند و سر و کله اونها در موعد تحویل کار یا اندکی پس از آن با چهره ای نادم پیدا میشه. در واقع این قبیل افراد به دلایل مختلفی از جمله ضعف مهارت های نرم و ارتباطی تعامل خوبی برقرار نمی کنند.
بسیاری از شما تجربه تبادل احساس عاطفی یا اصطلاحاً لاو ترکوندن ❤️ در بستر پیام رسان ها رو دارید. از اونجایی که متن گاهی فاقد لحن و احساس هست ممکنه باعث سو برداشت مخاطب بشه و منظور شما رو متوجه نشه و مشکل ساز بشه.
مشابه مورد بالا به دلایلی که در بالا اشاره شد باعث بروز سوتفاهم و بدگمانی بین کارفرما و برنامه نویس میشه و تعامل جاش رو به کشمکش می ده. این کشمکش می تونه باعث گروکشی و از بین رفتن شوق برنامه نویس بشه و باعث بروز تاخیر بشه.
یکی از کارکردهای خوب ایمیل اینه که به شخصی که قرار هست پاسخی ارسال کنه این فرصت رو می ده که تامل و تعمق کنه و انتظاری از سمت فرستنده وجود نداره که به صورت آنی پاسخ داده بشه. ما در پیام رسان ها شاهد این هستیم که طرف اول بعد از ارسال پیام کاری انتظار داره تا طرف دوم خیلی سریع پاسخ بده و همین باعث سو تفاهم و بروز مشکل میشه.
از طرفی وقتی که از ابزارهای مناسب استفاده کنیم قابلیت استناد به وجود میاد و یکی از طرفین نمی تونه ادعاهای پیشین رو تکذیب کنه. مثلاً کارفرما نمی تونه هر وقت دلش خواست نیازمندها رو افزایش بده و انتظار داشته باشه شما با همون زمان و هزینه قبلی کار رو انجام بدید.
توصیه: استفاده از ابزارهای ارتباطی مناسب مثل اسلک، ترلو، تسکولو، تیم کمپ و ایمیل می تونه بخشی از این موارد رو بهبود بده.
توصیه: از ابزارهای طراحی Prototype یا Mockup استفاده کنید تا درک بهتری بین طرفین ایجاد بشه. در اینجا بیشتر بخوانید.
در همین راستا تماشا کنید: مبانی کار تیمی برای تیم های توسعه و برنامه نویسی
کارفرما: مهندس یه اپ مثل اسنپ میخام چند میشه و چند روزه تحویل میدی؟
من: ?
هنوزم که هنوزه بعد از عمری فعالیت وقتی با درخواست برآورد زمانی مواجه می شم خودم و دست بالا می گیرم و اولین مواردی که به ذهنم خطور می کنه اینه که این n روز زمان می خواد و وقتی بیشتر بررسی می کنم می بینم n+x روز زمان نیاز داره.
در این بین دو مشکل یا عادت بد وجود داره. اولی عدم ارائه جزییات کافی از نیازمندی ها از شرح پروژه و دوم عدم درک کامل و مناسب برنامه نویس از نیازمندی ها.
از نظر من این به عهده‌ی برنامه نویس هست که اگر در یک پروژه هر مقدار جزییات که نیاز هست رو از کارفرما طلب کنه. چون بسیاری از پروژه های نرم افزاری در مقیاس خرد هستند و کارفرمایان دانش یا تجربه کافی در خصوص ارائه نیازمندی ها ندارند.
وقتی که درک مناسبی از چند و چون کار حاصل نشه یا برنامه نویس دچار بدفهمی در خصوص نیازمندی ها باشه قطعاً زمان تحویل به تاخیر خواهد افتاد و باعث رقم خوردن تجربه بد خواهد شد.
به نظر من راه حل همواره درست و کارآمدی برای ارائه برآورد هزینه انجام پروژه وجود نداره. اما همواره کارفرما نیاز داره که برنامه نویس چنین برآوردی رو ارائه کنه. وقتی که برآورد اشتباه باشه و مبلغ کمتر از مقداری که می بایست گفته بشه باعث میشه برنامه نویس در میانه راه دچار یاس و دلسردی بشه و تمرکزش به سمت کارهای دیگه معطوف بشه.
این مورد مهم احتمالاً می تونه باعث تاخیر بشه. در چنین مواقعی به عهده برنامه نویس هست که با بیانی مناسب و صادقانه مطلب رو با کارفرما در میون بذاره و براش توضیح بده (با بیانی غیرتهدید آمیز) چرا چنین شده و اگر هزینه کافی پرداخت نشه آینده پروژه به خطر می‌افته.
وقتی که کارفرمایی حاضر نباشد هزینه لازم را بپردازد و برنامه نویس به دلیل تنگناهای اقتصادی مجبور به پذیرش پروژه شود احتمال تاخیر در تحویل و چالش هایی که گفته شد افزایش می یابد.
تجربه: ما در داوری های پارسکدرز هر زمان که حس کردیم برآوردها اشتباه صورت گرفته و می توان با وساطت طرفین را به تعامل تشویق نمود این کار را کرده ایم و نتایج خوبی حاصل شده.
توصیه: توصیه می کنم که کارفرمایان اگر با بیانی صادقانه از سمت برنامه نویس مواجه شدند تلاش کنند در پرداخت تجدید نظر کنند تا پایه های پروژه متزلزل نشه.
توصیه: حتماً تلاش کنید برای برآورد هزینه از برنامه نویسان و دوستان با تجربه تر خود استعلام بگیرید.
فکر کنم خیلی ها مثل من از ابتدا درست یاد نگرفتن چطوری کدها رو تست یا دیباگ کنند. همین مورد باعث میشه حاصل کاری که به کارفرما تحویل داده میشه به خوبی کار نکنه و باعث تاخیر و نارضایتی بشه.
خیلی لازم و ضروری هست که در میانه راه فراگیری برنامه نویسی به خوبی با تکنیک های دیباگ و تست کردن نرم افزار آشنا بشیم.
در همین راستا بخوانید: GUI Testing
می دونم حوصله نوشتن تست و تست کردن ندارید ?
