https://virgool.io/feed/@p3ym4n شاید یک برنامه‌نویس، گاهی اوقات یک مسافر، یک روزی یک کارآفرین، بدون ِهیچ افسوسی. fa 2026-06-07 10:00:45 https://files.virgool.io/upload/users/5616/avatar/1w1k8l.png?height=120&width=120 https://virgool.io/@p3ym4n https://virgool.io/golangpub/%DA%86%D8%B1%D8%A7-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%87%D9%86%D8%AF%D9%84-%DA%A9%D8%B1%D8%AF%D9%86-%D8%AE%D8%B7%D8%A7%D9%87%D8%A7-%D8%AF%D8%B1-%DA%AF%D9%88%D9%84%D9%86%DA%AF-%D8%A7%D8%B2-richerror-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85-m88nvpaq5saj توی این پست می خوام که در مورد اینکه چرا استفاده از پکیجی مثل Rich Error به ما کمک می کنه که بتونیم سرویس‌های گولنگیمونو راحت تر دیباگ کنیم توضیح بدم.قبل از هر چیزی پیشنهاد می کنم که این سخنرانی گوفرکانف در سال ۲۰۱۹ راجع به Rich Error رو ببینید. https://www.youtube.com/watch?v=4WIhhzTTd0Y شاید براتون سوال پیش بیاد که توی گو هندل کردن خطاها به خودی خود به خوبی داره انجام میشه و چرا اصلا نیاز هست که وقت بیشتری براش بزاریم. در جواب باید بگم که یکسری سوال هست که با ارور هندلینگ عادی نمیشه بهشون جواب داد و به نظر من به اگه هنوز با این سوال ها مواجه نشدید شاید این پکیج خیلی به کارتون نیاد.حالا اون سوال ها چی هستن؟معمولا وقتی که تو گو خطایی رخ میده ما اون خطا رو لاگ می کنیم تا بتونیم اونها رو بعدا پیدا کنیم و فیکسشون کنیم. و در خیلی مواقع فیکس کردن اون خطا نیاز به اطلاعات بیشتری داره تا بتونیم علت اصلی رو راحت تر پیدا کنیم. اینجا هستش که جواب این سوال ها به ما کمک می کنن.پروسه ای که منجر به این خطا شده از کجا شروع شده و بعد از طی کردن چه مراحلی به اینجا رسیده؟در هنگامی که خطا رخ داده ما چه runtime argument هایی داشتیم؟آیا لازم هست که این خطا رو لاگ کنیم؟ریسپانس مناسب وقتی که این خطا رخ میده با توجه به محیط اجرا باید چی باشه؟ خب قبل از اینکه بریم سراغ جواب این سوال ها باید بگم که هندل کردن خطاها توی گو می تونه به صورت panic & recover یا به صورت شرطی باشه. من اینجا هیچ کاری با حالت اول ندارم و فقط تمرکزم بر روی حالت شرطی هست و بحث راجع به اینکه کدوم حالت مناسب‌تر هست بستگی به خیلی شرایط داره که خارج از موضوع این مطلب هست.پروسه ای که منجر به این خطا شده از کجا شروع شده و بعد از طی کردن چه مراحلی به اینجا رسیده؟بیاید اینجوری در نظر بگیریم که ما توی اپلیکیشنمون یکسری لایه های مختلف داریم که بر روی هم قرار گرفتن و پروسه از بالاترین لایه شروع میشه به سمت لایه های زیرین میره (این لایه ها میتونن صرفا یکسری فانکشن داخل یکسری پکیج باشن) و وقتی خطایی رخ میده، اون خطا به سمت لایه های بالاتر هدایت میشه تا در نهایت در لایه‌ی اول (لایه‌ی delivery) تصمیم مناسب براش گرفته بشه.به زبان ساده‌تر خطا در پایین‌ترین لایه ساخته میشه و به لایه‌ی قبلی خودش پاس داده میشه، ما لازم داریم تا توی هر لایه بهش اسم اون لایه یا فانکشن رو تزریق کنیم تا بتونیم بعدا اون مسیری که طی شده رو ردیابی کنیم. اینجوری میشه که توی لایه های بالاتر ما اصطلاحا خطا رو chain می کنیم.شاید با خودتون بگید که معمولا این مسیرها یکسان هستن و نیازی به اینکار نباشه و خب در خیلی مواقع به این صورت نیست، برای مثلا در نظر بگیرید که یک فانکشن دارید که وظیفه‌ی ارسال ایمیل رو بر عهده داره و امکان داره که از خیلی جاها صدا زده بشه.در هنگامی که خطا رخ داده ما چه runtime argument هایی داشتیم؟حتما شما هم تا حالا با این اتفاق مواجه شدید که بخاطر یکسری دیتاهای خاص در بعضی مواقع قسمت‌هایی از سرویستون خطا بده. کاری به این نداریم که چرا اصلا باید این اتفاق بیوفته ولی اونچه که به ما کمک می کنه این هست که بدونیم اون دیتاهای خاص چی بودن که بتونیم بعد از فیکس کردن اون سناریو ها رو به تست‌هامون اضافه کنیم.یه مثال خیلی ساده بخوام بزنم مثلا شما یه قسمت ثبت نام دارید که کاربرها باید بیان و شماره موبایلشون رو وارد کنن و یکسری فرمت‌های خاص رو شما کاور نکردید، مثلا اگه کاربر شمارشو به صورت +۹۸۹..... وارد کنه اون فانکشن خطا میده. اینجا هست که ما وقتی داریم خطا رو می‌سازیم (یا وقتی chain می کنیم) می تونیم به اون یکسری meta data اضافه کنیم.آیا لازم هست که این خطا رو لاگ کنیم؟خب احتمالا شما هم با این سناریو زیاد مواجه شدید که در هر لایه ای از اپلیکیشنتون توی یک فانکشن خاص با خطاهای متفاوتی مواجه بشید. و وقتی که این خطا به لایه‌ی بالاتر برمی گرده اون لایه‌ی والد هیچ ایده‌ای نداره که این خطا از چه نوعی هست. یک مثال سادش این هست که فرض کنید یک فانکشن داریم که قرار هست دیتای ورودی رو validate کنه و توی همون فانکشن هم امکان داره که در هنگام کار خطاهای دیگه ای رخ بده. یا یک مثال دیگه این هست که شما می خواید اطلاعات یک رکورد رو از دیتابیس بگیرید و امکان داره خود این پروسه با خطا مواجه بشه و یا امکان داره که اون کوئری اصلا هیج رکوردی رو برنگردونه که اون هم در نهایت خطا محسوب میشه اما نوعش با قبلی کاملا متفاوت هست.اینجاست که میشه خطاها رو در مبدا دسته بندی کرد تا در لایه های بالاتر با توجه به نوع اونها اقدام لازم اعم از لاگ کردن یا نمایش ریسپانس به کاربر رو انجام داد. من خطاها رو به این دسته بندی ها تقسیم کردم:نوع Invalid که معمولا نشان دهنده‌ای این هست که اطلاعات ورودی صحیح نیست.نوع Forbidden که همونطور که از اسمش مشخصه نشانگر این هست که کاربر اجازه دسترسی نداره.نوع Notfound که این هم از اسمش مشخصه و مثلا توی اون مثالی که بالا زدم وقتی استفاده میشه که نتیجه ای وجود نداشته باشه.نوع Unexcpected: که برای مواقعی قرار میگیره که خطای غیرمنتظره‌ای رخ میده و اگه ما هنگام ساخت خطا نوعی واسش در نظر نگیریم این نوع براش انتخاب میشه.نوع Unavailable که معمولا در رابطه با سرویس های خارجی بیشتر رخ میده.این رو هم فراموش نکنیم که این دسته بندی خیلی عمومی هست و شاید بنا به نیاز هر اپی شاید کم یا زیاد بشه.حالا اگه خطایی که رخ میده از نوع notfound باشه شاید ما فقط به کاربر یه ریسپانس نشون بدیم و اصلا نیازی نباشه که اون رو لاگ کنیم.ریسپانس مناسب وقتی که این خطا رخ میده با توجه به محیط اجرا باید چی باشه؟این قسمتی هست که هیج ربطی به این پکیج نداره و نیاز هست که خود شما در بالاترین لایه براش تصمیم بگیرید که آیا می خواید این رو لاگ کنید یا فقط ریسپانس بدید و اینکه اون کار رو به چه صورت انجام بدید. تنها کمکی که این پکیج در اینجا می کنه این هست که تمام موارد بالا رو می تونه به صورت خام یا پروسس شده بهتون تحویل بده تا مابقی کار رو شما روش انجام بدید.یه مدل از خروجی:لاگ یک خطای unexpectedاینجا من کمی راجع به این عکس توضیح میدم، گرچه تا حدودی گویا هست. اینطور که مشخصه این خطا توسط یک کرون جاب ران شده که سرویس notifier بوده و بعد بخاطر خطایی که توی مرحله بعد خورده در تلاش چهارم نتونسته که اون کار رو انجام بده. خطایی هم که بوده این بوده که نتونسته به دیتابیس وصل بشه چون دیتابیس دان بوده. شروع خطا هم در خط۲۳۱ از فایل مربوطه بوده! :)شاید براتون سوال پیش بیاد که چرا این پکیج از اینترفیس اصلی خطا در گولنگ تبعیت (implement) نمی کنه؟دلیل این کار این هست که هنگام دولوپ امکان اینکه یه خطایی به اشتباه به جای اینکه chain بشه دوباره ساخته بشه زیاد هست، ولی با استفاده از متدها با ورودی‌های مشخص، به سادگی جلوی این اشتباه گرفته میشه.در انتها پیشنهاد می کنم که یک نگاهی به سورس کد در گیت‌هاب بندازید، در اونجا توضیحات بیشتری درباره‌ی نحو‌ی استفاده‌ از پیکج داده شده. https://github.com/p3ym4n/re پیمان گلدسته پیمان گلدسته Fri, 26 Nov 2021 11:34:49 +0330 https://virgool.io/network-Ecomotive/%D9%86%D8%AD%D9%88%D9%87-%D9%85%D8%B0%D8%A7%DA%A9%D8%B1%D9%87-%D9%88-%D8%A8%D8%B3%D8%AA%D9%86-%D9%82%D8%B1%D8%A7%D8%B1%D8%AF%D8%A7%D8%AF-%D8%B1%D9%88%D8%B2-%D9%87%D8%A7-%D9%88-%D8%B3%D8%A7%D8%B9%D8%AA%D9%87%D8%A7%DB%8C-%DA%A9%D8%A7%D8%B1%DB%8C-%D9%88-%D8%B3%D8%A7%D8%B9%D8%A7%D8%AA-%D9%BE%D8%B4%D8%AA%DB%8C%D8%A8%D8%A7%D9%86%DB%8C-%D9%88-%D9%82%D8%A8%D9%84-%D8%A7%D8%B2-%D8%B4%D8%B1%D9%88%D8%B9-%D9%87%D8%B1-%DA%A9%D8%A7%D8%B1%DB%8C-exticpqqk7va این بلاگ پست یکی از مجموعه پست‌هایی هست که اینجا لیستشون کردم.سورس عکس روش قبلا تگ شده.خب می‌خوام که یکی از مهم‌ترینِ مهم‌ترین‌ها رو بگم، شاید نه بخاطر اهمیت بیشترش، صرفا بخاطر نکات بسیاری زیادی که این موضوع می‌تونه شامل بشه.توی این مطلب می خوام که تمامی بست‌پرکتیس‌هایی که طی این چند سال دولوپری داشتم رو لیست کنم و در کنارشون مشکلات و چالش‌های مرتبطشونم میگم. بحث ما اینجا بیشتر موارد پروژه‌ای و فری‌لنسینگ رو شامل میشه و در رابطه با کار‌های تمام وقت خیلی چالش‌های متفاوت تری وجود نداره(وقتی که سینیور بشید).باید من از اینجا این مطلب رو ۲ قسمت کنم:یکی موارد مربوط به استخدام و دیگری انجام پروژه‌ها(فریلنسینگ)قسمت اول :‌استخدامداستان مصاحبهتوی قرار‌های کاری شما هنگام مصاحبه باید خود واقعیتون رو نشون بدید. گفتن این‌ مطالب برای سینیور‌ها تکراری هست ولی خب شاید واسه بقیه نباشه. مهم ترین چیزی که شما باید روش مانور بدید صحبت بر روی کانسپت‌ها و نتایج کار‌هاییه که کردید. اینکه شما حرف از تکنولوژی‌هایی که باهاشون کار می‌کنید بزنید، یا اینکه حرف از این تونستید چه دستاورد‌هایی داشته باشید خیلی روی طرف مقابل شما تاثیر میزاره. پس برای همین سعی کنید از تجربه‌ها و دستاورد‌هاتون بگید. پرکتیس‌های خوب و بدی که داشتید. اینها چیز‌هایی هست که شما رو از بقیه متمایز می‌کنه.داستان روز‌های کاریاین داستان معمولا تو مصاحبه تغییر نمی‌کنه مگر اینکه شما یک اهرم فشار داشته باشید(مثل وقتی که کارفرما می‌خواد که زودتر کار رو شروع کنید). از اونجایی که شرکت‌ها اکثرا یک تایم کاری و ساعت ورود و خروج برای همه‌ی کارمنداشون دارن خیلی سخته که شما بخواید تافته جدا بافته باشید و بهتر هست که قبل از مصاحبه این مورد رو از بقیه پرس‌و‌جو کنید. اگه مثل من ساعت رفت و آمد خیلی براتون مهمه.اکثرا توی محیط‌های استارتاپی مانوری بیشتری میشه روی این قضیه داد ولی شرکت‌های سنتی‌تر کمتر?.داستان پشتیبانیبسته به پوزیشنی که شما دارید امکان داره که نیاز به پشتیبانی در ساعات غیر اداری داشته باشید. این از اون چیز‌هایی که هیچ کارفرمایی اول حرف ازش به میون نمیاره. ولی اگه خودتون به کیفیت کارتون ایمان دارید پشتیبانی دادن به شرکتی که در استخدامش هستید کار خیلی خوبیه و اینکه همونطور که گفتم اگه کارتون خوب باشه معمولا کمتر سیستم نیاز به پشتیبانی خارج از ساعات کاری پیدا می‌کنه. واسه همین این یک نکته مثبتی هست که شما می‌تونید مطرحش کنید و به عنوان امتیازی که به کارفرماتون میدید بعدا در مواقع خاص درخواست‌هایی ازشون بکنید. از اونجایی که پشتیبانی سیستم‌های نرم‌افزاری یک نیاز هست و جزیی از کار، معمولا وقتی که فاجعه رخ میده نیاز بهش هست (همراه با کلی استرس‌). برای حرفه‌ای بودن باید با خودتون اینجوری دیل کنید که این هم جریی از کار من هست و نباید از انجام دادنش طفره رفت.همیشه روی پرداکشن جدا از لاگ خطاها برای خودتون یه اطلاع رسانی اسلک یا ایمیلی هم داشتید باشید تا نفر اولی باشید که از ترکیدن سیستم مطلع میشه.داستان حقوق (اصل داستان)خب این قسمت از کار رو باید حواستون باشه که معمولا طرفین می خوان که قیمت اول رو از طرف مقابلشون بشنون (گرچه روال صحیح اینه که اون شرکت توی آگهی استخدامش باید رنج حقوقی که می‌تونه پرداخت کنه رو ذکر کنه). برخلاف بایاسی که توی این بحث وجود داره شما نفر اول قیمت بدید و همیشه عدد رو بر مبنایی که قبلا بهش رسیدید بگید. امکان داره که توی مصاحبه گول بخورید و این خیلی زیاد پیش میاد. بنابراین حواستون باشه که باید قبل‌تر به این فکر کرده باشید که چقدر حقوق براتون مناسبه(مگه میشه کسی بهش فکر نکنه!؟). اگه توی جلسه استخدام با اصرار طرف مقابل مبنی بر بالا بودن مبلغ پیشنهادیتون و دادن یکسری وعده‌های معنوی مواجه شدید و به این نتیجه (یا توافق با طرف مقابل) رسیدید که مبلغ رو پایین بیارید. مطمئن باشید دارید گول می‌خورید! گرچه فراموش نکنید که پایین آوردن مبلغ به یه میزان خیلی کم جوری که هنوز خودتون از مبلغ نهایی رضایت داشته باشید اشکال نداره.یه حالت دیگه هم داره که شما توی مصاحبه متوجه می‌شوید که جا داره مبلغ‌تون رو بالاتر ببرید. خب در اینجور موارد مشکلی نداره قیمت رو ببرید بالا ولی طمع نکنید. پس خوب فکر کنید، حتی اگه لازمه کمی از طرف مقابل وقت بخواید و در نهایت یک مبلغ بگید که خودتون ازش رضایت دارید.دلیل تاکید من بر روی رضایت از مبلغ نهایی این هست که شما اگه حتی ته دلتون یه نارضایتی کوچیک داشته باشید امکان داره که تو کار سست بشید و همیشه خودتون رو مقصر بدونید که عه مثلا می‌تونستم ماهی ۱-۲ تومن بیشتر هم بگیرما ولی الان نمی‌گیرم. مقصر اول و آخر این داستان هم خود شما هستید! پس از قبلتر دقت کنید و نزارید همچین اتفاقی براتون بیوفته. قابل پیشگیری هست.رفتار حرفه‌ایرفتار حرفه‌ای رو خیلی جدی بگیرید. این بیشتر از کیفیت کدتون ارزش شما رو بالا میبره. واسه همین همیشه حرفه‌ای رفتار کنید. هیچ وقت توی بحث‌های فرسایشی شرکت نکنید.حرف بزنید! ما ایرانیا حرف زدن رو بهمون یاد ندادن! هر مشکلی که دارید رو اول با فرد مورد نظر به صورت کاملا دوستانه مطرح کنید. هیچ‌وقت کسی رو تهدید به انجام کاری نکنید، فقط و فقط در موارد حاد یادآوری کنید که پیگیری قانونی می‌کنید(اگه حتی نمی‌خواید این کارو بکنید).یکسری اخلاق‌های ابتدایی هست که معمولا دولوپر‌ها ندارن، مثل سلام کردن ?‍♂️. این‌ها اصلا نباید مطرح بشن ولی خب باید همیشه واقعیت رو بپذیریم. این اخلاق‌ها باید همیشه به بهترین نحو ممکن پیاده بشن.تعامل رو یادمون نره. همیشه باید تعامل کنیم. نظر بدیم و رابطمون رو با بقیه صمیمی نگه داریم.صندلی ارگونومیک و کول‌پد(پایه لپ‌تاپ) رو باید همیشه داشته باشید و این رو از کارفرما بخواید.این‌جا میشه تا فردا صبح نکته گفت که تو حوصله بحثمون نیست. واسه همین اگه نکته‌ی مهمی رو می دونید و اینجا نبوده می تونید تو کامنت‌ها بگید.قسمت دوم :‌پروژه‌های فریلنسینگخب توی این مدل کار کردن خیلی از چونه زدن‌ها و توافق‌ها به قبل از نوشتن قرارداد بر می‌گرده که اکثرا هم سر قیمت و زمان انجام پروژه هست. ولی یادتون نره که توی همین صبحت‌های اولیه باید این موارد رو به کارفرما(که شاید فرد ناآگاهی به این حوزه‌ هم باشه) بگید:مبلغ قطعی قراردادمدت زمان قطعی تحویل پروژهمدت‌ زمانی که پشتیبانی رایگان می‌دهید و اینکه بعدا واسه پشتیبانی چقدر میگیرید.تا چند سال پروژه رو پشتیبانی می‌کنیداگه سورس‌کد رو تحویل نمی‌دید باید بهشون بگید.اگه هیچ تصویر ذهنی از این حرفا ندارید من مدلی که خودم کار می‌کنم رو براتون میگم. این توضیحاتی هست که من معمولا توی صحبت اول به کارفرما میگم: ما پروژه شما رو توی حدودا .... روز کاری با مبلغ حدودا ... تومن انجام میدیم. سورس کد رو به شما تحویل نمیدیم(اگه پروژه بزرگ باشه میدیم) و واسه همین هاستینگتون رو هم خودمون انجام میدیم. ما هاست رو از ....(فلان جا) میگیرم و هزینه‌ها همون هزینه‌های اونجا هست. تا چهار سال پروژه رو پشتیبانی می‌کنیم، سال اول رایگان هست و سال‌های بعدی ۱۰٪ مبلغ قرار‌داد رو میگیرم.من قیمت و زمان رو حدودی گفتم چون صحبت اول هست و روی پروپوزال نیمده. شما باید برای مشتری روشن کنید که به غیر از این‌ها کار با شما براشون هزینه‌ی دیگه‌ای نداره!خب مواردی بعدی رو اینطوری لیست می‌کنم.نکات مربوط به پشتیبانیکارفرما هیچ ایده‌ای از پشتیبانی نداره. اینکه چیا شاملش میشه و چیا نمیشه رو شما باید بهشون بگید. همیشه مشکلات و بروزرسانی‌های امنیتی یا خطاهایی که توی سایت بوجود میاد توی پشتیبانی قرار می‌گیره. تمام تغییراتی که کارفرما مد نظرشه و بعدا از شما می‌خواد به عنوان یک امکان‌اضافی باید توی پروسه‌کاری شما قرار بگیره. یعنی اولی بررسیش کنید. بعد قیمت و زمان بدید و بگید که کی فرصت می‌کنید که انجامش بدید و در نهایت بعد از تایید کارفرما امکان جدید رو اضافه کنید و پولش رو بگیرید (همه مکاتبات باید مکتوب باشن). چون شما سایت کارفرما رو در دست دارید می‌تونید که پول رو بعد از اضافه کردن فیچر بگیرید.همینطور حواستون باشه که اگه سورس کد رو به کارفرما میدید اون امکان داره که بخواد هر ۲ ماه یکبار هاستشو عوض کنه و هر سری برای کانفیگ کردن به شما زنگ بزنه که پشتیبانیش کنید! این اتفاق زیاد میوفته و چون معمولا هر کدی یک کانفیگ خاصی می‌خواد همیشه می‌تونه دردسرساز باشه. این می‌تونه یکی از دلایل محکم شما واسه ندادن سورس کد به کارفرما باشه.حواستون به بکاپ باشه! چون معمولا انتظار میره که وقتی شما دارید هاستینگ رو انجام میدید باید بکاپ هم رو هم خودتون انجام بدید. معمولا هاست‌ها برای بکاپ پول می‌گیرن. پس این رو به کارفرما بگید. که بکاپ می‌گیرید یا نمی‌گیرید و باید هزینش رو بپردازن. این از اون موضوعاتیه که می‌تونه طرفین رو بشدت درگیر کنه.نکات مربوط به قراردادنکاتی که الان میگم کلی هستن و صرف دونستنشون کفایت می‌کنه.حتما قرارداد کتبی بنویسید.(در ۲ نسخه)زمان پروژه همیشه حداقل ۲ برابر اون چیزی هست که فکر می‌کنید. با یه حداقل مثلا کلا زیر ۳۰ روز پروژه رو زمان ندید. شرایط پرداخت رو ذکر کنید و بنویسید که شروع پروژه منوط به پیش‌پرداخت هست.بنویسید که پولی که گرفته‌اید رو به هیچ وجه پس‌ نمی‌دید.اگه کارفرما خیلی اصرار می‌کنه برای زمان تحویل جریمه در نظر بگیرید. همینطور تحویل گرفتن سیستم از سمت کارفرما(و پرداخت).نظرات کارفرما رو مکتوب کنید که قابل استناد باشه.به کارفرما بگید که تهیه و آماده‌سازی اطلاعات اولیه بر عهده شما نیست(دیتا اینتری). ذکر کنید که ۱ بار بعد از تکمیل پروژه نحوه کار با سیستم رو به نماینده کارفرما آموزش میدید.رازداری و حفظ اطلاعات محرمانه کارفرما یکی از تعهدات شماست. اینو تو قرارداد بنویسید.ذکر کنید که کارفرما نمی‌تونه بدون اجازه شما این پروژه رو روی چندتا دومین بالا بیاره! پروژه وایت لیبل هزینه جداگانه داره.زمان تحویل گرفتن پروژه رو برای کارفرما مشخص کنید.ذکر کنید که در فوتر سایت بعدا امضای خودتون رو قرار میدید(البته قابل مذاکره هست. شاید یکی نخواد)ذکر کنید که تاخیر در پاسخ‌گویی از سمت کارفرما به زمان تحویل پروژه اضافه می‌کنه.داوری تعیین کنید. بهتر هست که بجای مراجعه به مرجع قضایی برای حل مشکلات بوجود آمده پیش داور بروید.ذکر کنید که همه‌ی عوارض یا مالیات مربوط به پروژه بر عهده کارفرماس و اینکه این قرارداد قابل انتقال به غیر نیست.فروس‌ماژور رو ذکر کنید و بنویسید که توی اون شرایط قرارداد به صورت خود به خود فسخ میشه.پروپوزالتون رو پیوست قرارداد کنید.خب اکثر موارد مهم همین‌هاست. یکسری از موارد هم بود که مربوط به تعهدات کارفرما میشد و باید توی قرارداد بیاد ولی چون قبلا توی پست تعهدات کارفرما لیست کرده بودمشون اینجا نیاوردم.امیدوارم که این مطالب براتون مفید بوده باشه و اگه هست لطفا اون رو هم با بقیه به اشتراک بزارید.ممنون. پیمان گلدسته پیمان گلدسته Sat, 12 Jan 2019 18:34:27 +0330 https://virgool.io/@p3ym4n/%D9%86%D8%AD%D9%88%D9%87-%D9%85%D8%B0%D8%A7%DA%A9%D8%B1%D9%87-%D8%AF%D8%B1-%D8%B1%D8%A7%D8%A8%D8%B7%D9%87-%D8%A8%D8%A7-%D8%A7%D8%B1%D8%B2%D8%B4%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%DA%A9%D8%A7%D8%B1-%D8%B4%D9%85%D8%A7-%D8%AF%D8%B1-%D9%87%D9%85%DA%A9%D8%A7%D8%B1%DB%8C%D9%87%D8%A7%DB%8C-%D8%B7%D9%88%D9%84%D8%A7%D9%86%DB%8C-%D9%85%D8%AF%D8%AA-%DB%8C%D8%A7-%D9%82%D8%B1%D8%A7%D8%B1%D8%AF%D8%A7%D8%AF%DB%8C-cnqqjmwomnel این بلاگ پست یکی از مجموعه پست‌هایی هست که اینجا لیستشون کردم.عکس رو از روی یکی از توویت‌های @OfferZen برداشتم.خب این مطلب خودش به تنهایی خیلی گستردس و بسته به اینکه شما توی چه استیجی از این کرریر هستید باید برای هر کدوم رویکرد‌های متفاوتی در نظر گرفته بشه، ولی فراموش نکنیم که هدف بحثمون مشکلات هستند چون شناخت اونها به تنهایی خودش خیلی کمک بزرگی می‌کنه تا بتونیم در لحظات مهم تصمیم‌گیری درستی بکنیم. همینطور من تا جایی که راه‌حل‌ها رو بدونم اونها رو بعد از ذکر هر مشکل میگم.خب به نظرم خوبه که استیج‌ها رو اینجوری دسته بندی کنیم:‌ اینترن یا همون کارآموزجونیور دولوپر که خب میشه گفت به برنامه‌نویس‌های تا زیر ۳ سال تجربه میگن (وحی نازل نیست!)سینیور دولوپر که به نظرم میشن افرادی که خودشون راهشون رو پیدا کردن، دیگه در قید و بند تکنولوژی یا زبان خاصی نیستن و خودشون تکنولوژی‌های جدید رو دنبال می‌کنن.خب بریم سراغ چالش‌های دسته اول یعنی اینترن‌هااینترنشیپ توی ایران روال کاملا بومی خودش رو داره، (مثل استارتاپ‌های ایرانی که اکثرا اول یه ایده بودن بعد دست و پا درآوردن). معمولا در جاهای دیگه شما برای کسب یه مهارت مدتی به یک شرکت میرید، همزمان باهاش یکسری دوره‌های آموزشی میگذرونید و برای همه‌ی اینها هم پول پرداخت می‌کنید.ولی توی ایران رویکرد اینه که شما میرید یه شرکت و اونجا یه مدتی کارایی که بهتون میگن و انجام میدید و بعد هم استخدام میشید (یا نه قبولتون نمی‌کنن). خبری از آموزش و دریافت پول و اینا نیست(گرچه باز میگم اینو نمیشه به همه نسبت داد من مادرم خودش یه موسسه آموزشی داره و همیشه مدل خارجی رو انجام میدن??). باز هم من رویکرد اول رو صرف خارجی بودنش تایید نمی‌کنم ولی در مورد قسمت آموزش مطمئنم که اینترنشیپ نیاز به آموزش هم داره.پس یکی از مشکلات یا چالش‌هایی که ما توی اینترنشیپ ایرانی میبینیم (اولیش نیستا!) اینه که به ما آموزش نمیدن. خیلی هم شاید حل کردنش سخت نباشه، چون ما اینترن هستیم تقریبا اگه از هر کسی تو سازمان سوال بپرسیم به احتمال خیلی زیاد اونها به ما جواب میدن و این ماییم که باید با پرسیدن سوالات درست این قسمت رو تنهایی به پیش ببریم.یادتون باشه که به صورت دوستانه بعد از هر هفته از مسئول مستقیمتون بپرسید که به نظرش عملکرد شما چجوری بوده.مشکل بعدی در اینترنشیپ این هست که معمولا کار‌هایی که به شما در ابتدا میدن شاید خیلی مرتبط نباشه و یا اون‌چیزی که شما به دنبالش هستید نیست. در این مواقع راه‌حل اثبات خودتونه! شما اینجا نیاز دارید تا یک ذهنیت خوب، پیگیر و پیش‌رو از خودتون در دیگران ایجاد کنید. راهشم اینه که هر کاری که بهتون میدن رو جدا از این که چی هست به بهترین نحو ممکن انجامش بدید. اینجا دقیقا یکی از همون جاهاییه که برنامه‌نویس نماها و برنامه‌نویس‌های واقعی مشخص میشن!خب حالا مشکل اول در اینترنشیپ مشخص نبودن زمان قراردادتون هست و اینکه به شما نمیگن با چه معیاری در آخر دوره قرار هست پیشرفت شما رو بسنجن و اگه قرار باشه بعد از قبول شدن همونجا شروع به کار کنید شما روی با چه حقوقی و در چه پوزیشنی قرار میدن. خب این از اون قسمت‌هایی هست که من هم راه‌حل بولت‌پروفی براش ندارم ولی توصیه‌هایی می‌تونم براش بکنم.برای پیش‌گیری از این مشکل ابتدا خیلی به سازمان یا شرکتی که برای اینترنشیپ انتخاب می‌کنید دقت کنید. خیلی مهمه که قرار هست با چه افرادی کار کنید. افراد متعهد یا باقی افراد (?!) و اینکه چندتا از افرادی که اونجا دارن در پوزیشن‌هایی که کار می‌کنن الگو یا اسطوره شما هستن و شما می‌خواید که دقیقا همون فرد در همون موقعیت باشید. در کنار همه این‌ها فراموش نکنید که ما ایرانی‌ها ارتباط برقرار کردن رو بلد نیستیم و نمی‌دونیم که باید حرف بزنیم و خواسته‌هامون رو مطرح کنیم و شاید خیلی مواقع توی کلمه‌ای به اسم تعارف گیر کنیم (بلاخره تو سنتمون بوده دیگه ?‍♂️). پس یادمون نره که وقتی برای اینترنشیپ میریم که صحبت کنیم بهتره که دقیقا خواسته‌هامون رو بگیم و حتی اگه قراره در آینده اونجا مشغول بشیم بهتره که کمی در مورد اون هم صحبت کنیم. این چندتا توصیه فقط می‌تونه به شما کمک کنه که انتخاب صحیح‌تری داشته باشید.اگه کارآفرینی و استارتاپ رو دوست دارید و فکر می‌کنید که در آینده برنامه‌نویسی موفقی میشید که می‌تونه به یک کارآفرین موفق تبدیل بشه، اینترنشیپ رو به هیچ وجه در شرکت‌های طراحی‌سایت یا تولید نرم‌افزار شروع نکنید!دسته دوم برنامه‌نویس‌های جوان! (جونیور)توی قسمت قبلی هیچ حرفی از ارزش‌گذاری کار دولوپر‌ها نکردم. چون هنوز اونجا دولوپری شکل نگرفته بود و اینجا شروع داستان پر فراز و نشیب ارزش‌گذاری کار افراد هست.بیاین به معیار‌های ارزش‌گذاری کار دولوپر‌ها یه نگاهی بندازیم: تجربهمهارت و دانش فنیتوانایی راهبری پروژهاخلاقیات خود فرد!خب در شروع کار چالش‌ها از اونجا شروع میشه که احتمالا ما هیچ‌کدوم به غیر از کمی از آخری رو نداریم(شاید اونم نداشته باشیم ?‍♂️).ما باید در تمام این ۳ سالی که سعی می‌کنیم از جونیوری به سینیوری برسیم (میانبر نداره!) باید بر روی این ۴ مورد کار کنیم. توی این مدت معمولا با حقوق پایه و شاید کمی بیشتر بشه کار پیدا کرد. که به نظر اوکی میاد. توی این مرحله من واقعا چالش خاصی توی ارزش‌گذاری کار نمی‌بینم شما معمولا هرچی‌ بگید اگه بالاتر از میزان کاری که می‌کنید باشه اون فرد سینیوری که توی جلسه استخدام هست مبلغ رو تعدیل می‌کنه و حرفشم معمولا منطقیه. ولی ما اینجا یه سوپر‌پاور داریم و اون اینه که میتونیم خیلی سریع یاد بگیریم و بر مهارتمون بیافزاییم. شما تقریبا همیشه و همه‌جایی که میز و صندلی و اینترنت باشه می‌تونید در نقش یک برنامه‌نویس ظاهر بشید(بخاطر همینه من انقدر این کارو دوست دارم). پس می‌تونید توی ۱ سال به اندازه ۳ سال کسب تجربه کنید و همش بر‌ می‌گرده به اینکه چقدر تلاش می‌کنید.اگه شما فرد تلاش‌گری بودید و پیشرفت خوبی داشتید به احتمال زیاد توی همون شرکتی هم که هستید درآمد و ارزش کارتون بیشتر میشه. اما اگه خیلی بیشتر بودید یا شرکت منصف نبود چی؟ راه حلش عوض کردن شرکت هست. شما الان یک فرد جونیر ولی تلاش‌گر هستید و نمودار رشدتون خیلی شیب زیادی داره. پس نگران نباشید و حتما شرکتتون رو عوض کنید و دقت کنید اینجا پله‌ای هست که شما ارزش کارتون رو یک مرحله بالاتر می برید و با یک حقوق بالاتر توی اون شرکت شروع به کار می‌کنید. ببینید چالش‌های این دوره همه روتین هستن و این روتین بودن می‌تونه خیلی خطرناک باشه و باعث بشه که شما دلسرد بشید، اگه اکثر جوک‌های برنامه‌نویسی رو ببینید همشون در مورد دولوپری‌هایی که توی این دوره هستن صادقه. مثل تحلیل رفتن انرژی، درآمد کم، کوچک شدن حلقه دوستان، سرو‌کله زدن با مشتری، نداشتن همدم و ارتباط کمتر با اعضای خانواده و ...یجورایی هم این دوره دوره گذار شما هست که بعدش به یک فردی تبدیل میشید که قبل از اینکه اینترنشیپتون رو شروع کنید دوست داشتید باشید. فقط نیاز به تلاش و یادگیری داره ولی چند‌تا مورد دیگه هم میگم که می‌تونه کمکی باشه برای رسیدن به مرحله بعد.توانایی راهبری پروژه مهمه از اونجایی که امکان داره شما بتونید یه زمانی سینیور دولوپر بشید اما بدون این هیچ وقت نمی‌تونید یک CTO بشید!اخلاقیات رو آخر نوشتم ولی درجه اهمیتش از همه بیشتره. سعی کنید نِرد نباشید. احتمالش زیاده آدم درونگرایی باشید ولی این منافاتی با اخلاقیات نداره.اگه عوض کردن شرکت خیلی بهتون حال داد مواظب باشید که توی دامش نیوفتید. شما نباید کمتر از یک سال در یک شرکت بمونید.خب میرسیم به دسته آخر، سینیور‌هاخب اینجا جاییه که بیشتر تو چشم بقیه هست و خیلی‌ها اگه میگن برنامه‌نویس منظورشون افرادیه که به این مرحله رسیدن. اگه منتظر بودید که از چونه زدن با کارفرما سر گرفتن پروژه یا موقع بستن قرارداد بگم اینجا جاییه که این اتفاق‌ها میوفته.مشکلات توی این مرحله همه و همه سر پول می‌چرخه. مشکلات دیگه‌ای مثل نحوه ارتباط با بقیه، کسب تجربه و یادگرفتن چیز‌های جدید، اینکه چیکار کنیم حالمون بهتر بشه و.... وجود نداره. اینجا شما که فرد حرفه‌ای هستید و برخلاف مراحل قبلی شما باید قواعد بازی رو بچینید و نقشه راه رو ترسیم کنید!اگه برنامه‌نویس خوبی باشید همه می‌خوان که شما رو داشته باشن و شاید خیلی‌ها هم حاضر نشن اندازه‌ چیزی که شما می‌خواید(/دلیور می‌کنید) پول بدن. باید در اینجور مواقع مذاکره کنید ولی اگه گزینه‌ی دیگه‌ای نداشتید باهاشون قرارداد پاره‌وقت ببنید یا قرارداد بیشتر از ۶ ماه نبندید، نه برای اینکه ۶ ماه دیگه از اونجا برید. برای اینکه ۶ ماه فرصت داشته باشید تا نیاز اونها به خودتون رو بهشون ثابت کنید و موقع تمدید از اون به عنوان اهرم فشار استفاده کنید تا بتونید مبلغ رو به اندازه دلخواه بالا ببرید.توی این مرحله سعی کنید که شما کار رو هل بدید به جای اینکه به دنبال کار بدوید. این باعث میشه که دیگران ارزش کار شما رو درک کنن. اگه سینیور هستید یعنی تا الان حتما چندسال، توی‌ چند‌تا شرکت کار کرده‌اید و نتورک خوبی دارید. از این نتورک برای بالاتر بردن ارزش کارتون استفاده کنید.توی این مرحله تعهد‌کاری شما خیلی مهمه و اینکه قولی بدید و نتونید دلیور کنید خیلی بهتون ضربه می‌زنه. مثلا اگه پروژه‌ای رو در دست دارید و تا یک ماه دیگه پر هستید، پروژه‌ی دیگه‌ای رو قبول نکنید یا به طرف بگید که یک ماه دیگه پروژه‌اش رو شروع می‌کنید. معمولا در اینجور مواقع کارفرما برای شروع اصرار می‌کنه که باید بهشون بگید خب من کار قبلی رو سر وقت نرسونم احتمالا کار شما رو هم نمی‌تونم طبق قولم سر وقت برسونم (من همیشه میگم خیلی خوب جواب میده ?). اگه در شرایطی قرار گرفتید که نتونستید با مذاکره مبلغ کارتون رو بیشتر کنید و طرف مقابل حرفه‌ای‌تر بود به خودتون اعتماد کنید و خیلی ساده از اون شرکت بیاید بیرون (البته بهتره که قبلش دنبال کار بگردید).نتیجه‌گیریخب شاید با خودتون بگید که من چرا هیچ حرفی از نحوه مذاکره و چونه زدن نزدم و حتی هیچ حدود مبلغی هم ذکر نکردم. دلیلش اینه که مهارت مذاکره چیزی هست که شما طی کار کردن(نه فقط دولوپری) بدست میارید. ارزش‌گذاری کارتون رو هم خودتون انجام میدید. هیچ وقت خودتون رو با بقیه مقایسه نکنید و قیمتی که میدید باید به میزانی باشه که شما را خوشحال نگه میداره. نه چیزی که بازار تعیین می‌کنه یا بقیه میگن.امیدوارم که این مطلب مفید بوده باشه، منتظر فیدبک‌هاتون هستم.(اگه هم خوشتون اومده اون رو با بقیه به اشتراک بگذارید ?). پیمان گلدسته پیمان گلدسته Mon, 07 Jan 2019 17:00:25 +0330 https://virgool.io/@p3ym4n/%D9%86%D8%AD%D9%88%D9%87-%D9%85%D8%B0%D8%A7%DA%A9%D8%B1%D9%87-%D8%AF%D8%B1-%D8%B1%D8%A7%D8%A8%D8%B7%D9%87-%D8%A8%D8%A7-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%AA%D8%B9%D9%87%D8%AF%D8%A7%D8%AA-%DA%A9%D8%A7%D8%B1%D9%81%D8%B1%D9%85%D8%A7-%D9%85%D8%B7%D8%A7%D8%A8%D9%82-%D8%A8%D8%A7-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-%D8%AF%D8%B1-%D9%BE%D8%B1%D9%88%DA%98%D9%87%D9%87%D8%A7%DB%8C-%D9%81%D8%B1%DB%8C%D9%84%D9%86%D8%B3%DB%8C%D9%86%DA%AF-voxtgxq4jckj این بلاگ پست یکی از مجموعه پست‌هایی هست که اینجا لیستشون کردم. تصویر رو از techoriginator.com برداشتم.نمی‌تونیم منکر بشیم که فری‌لنسینگ به عنوان یک راه درآمد دوم توی زندگی هر برنامه‌نویسی هست و با اینکه خودم هم علاقه‌ای بهش ندارم اما در بعضی شرایط مجبور به انتخابش هستیم (البته همیشه بد نیست ?).مهمترین تعهد کارفرما پرداخت کامل و به موقع پول هست.هیچ‌وقت این رو فراموش نکنید و خب مابقیشونم اینها هستن:ارائه محتوای جامع و مکتوب از محتوای پروژه (همون RFP)هماهنگی‌های لازم در خصوص انجام موضوع قراردادبررسی، تست و تحویل گرفتن سیستم طی مدت زمان توافق شدهجدا از اینکه تعهدات ریز دیگه‌ای هم هست که همه‌ی اونها در قرارداد ذکر شده این ۴ مورد مهمترین‌های اونها هستن.خب بریم سراغ اولین و مهمترین اون تعهدات.پرداخت‌های پروژه بدون در نظر گرفتن اینکه دارید یک وبلاگ می‌نویسید یا یه اپ ریکت‌نیتیو یا یک سرویس‌آنلاین بر روی میکرو‌سرویس (که آخری خیلی بعیده) توی بیشتر از ۲ حالت نمی‌گنجه.پروژه قسمت‌های ویژوال زیادی داره مثل اپ یا سایت یا وبلاگ یا فروشگاه یا لندینگ که باید توی ۳ تا پرداخت انجام بشه، یا اینکه قسمت‌های ویژوالش کمتره، کم اهمیت‌تره، یا اصلا نیست. مثل یه پنل یا یک api یا تکمیل یک پروژه نیمه‌کاره که قبلا تا فرانت پیش رفته (خودکشی!) که توی ۲ مرحله انجام میشه.مدل ۳ مرحله‌ای پرداخت‌هاش اینجوریه: ۴۰٪ + ۳۰٪ + ۳۰٪مدل ۲ مرحله‌ای پرداخت‌هاش اینجوریه: ۶۰٪ + ۴۰٪از اونجایی که چالش سر نحوه تعامل با کارفرما برای گرفتن پول هست و شما باید این پول رو مطابق با پیشرفت پروژه دریافت کنید بیاید ببینیم که توی هر مرحله کجا باید کار رو تا دریافت پول پیش ببریم و اگه لازم باشه انجام پروژه رو متوقف کنیم.پرداخت اول توی هر ۲ مرحله حساس‌ترین پرداخته(مهمترین‌ نیست). چون‌که مشخص کننده‌ی این هست که کارفرما با خودش، پروژه و شما چند چنده. اگه دقت کنید درصد اولین پرداخت‌ها هم بیشتره و این بیشتر بودن برای نشون دادن حسن‌نیت از سمت کارفرماس و اینکه جوری تعیین شده که اگه تا مرحله‌ی بعدی شما کارو پیش بردید و کارفرما منصرف شد (به هر دلیلی) شما ضرر نکرده باشید.خب پرداخت اول معمولا آگاهانه و ناآگاهانه توسط کافرماها به روش‌های بی‌شماری پیچونده میشه. حساسیت موضوع اینجا شکل میگیره که کارفرما برای اینکه از این پرداخت سر باز بزنه، شما رو وارد بازی‌های بسیار زیادی می کنه مثل آوردن بهونه‌های مختلف. مثلا پرداخت رو دادیم حسابداری انجام بده، یا این ماه بودجه نداریم یا اینکه افراد دیگه‌ای رو مسئول پیگیری می‌کنن که از شما طلب می‌کنن که فعلا پروژه رو شروع کنید تا کار عقب نمونه و ... . خیلی احتیاجی نیست این مثال‌ها رو بسط بدم چون واقعا بیشمار هستن ولی یک راه مقابله بسیار ساده دارن و اون هم این هست که شما تا پیش پرداخت رو به طور کامل دریافت نکردید نباید کار رو شروع کنید.پرداخت دوم توی مدل ۳ مرحله‌ای بعد از تحویل فرانت کار صورت میگیره و خیلی روش بحث و جدلی نیست، دقت داشته باشید که این مرحله هم اگه پرداختش انجام نشه نباید پروژه رو ادامه بدید.پرداخت آخر توی هر ۲ مرحله مهم‌ترین پرداخت پروژه هست و همیشه قبل از انتقال پروژه به پروداکشن صورت میگیره. دقت کنید که گفتم قبل از انتقال! یعنی شما پروژه رو توی محیط استیجینگ به کارفرما نشون میدید، بعد از تایید نهایی و گرفتن پول انتقال رو انجام میدید. اینجا هم چون آخره کار هست و شما به تمامی تعهداتتون عمل کردید و امکان داره که باز کارفرما به هر دلیلی از تحویل گرفتن پروژه منصرف بشه شما باید قبلا یجوری قیمت‌دهی کرده باشید که سودتون توی این پرداخت باشه (که البته اون رو هم بعدا مفصل راجع بهش توی یه پست دیگه میگم).این پرداخت تنها پرداختیه که باید براش مهلت تعیین بشه و در صورتی که توی زمان خودش انجام نشد براش جریمه در‌نظر گرفته بشه. تمامی مشکلات و بهونه‌هایی که واسه پرداخت اول گفتیم واسه این پرداخت هم میتونه اتفاق بیفته و مهم اینه که شما از موضع خودتون تحت هیچ شرایطی کوتاه نیاید.مهم‌ترین تجربه‌ی من توی پرداخت‌های پروژه این بوده که اگه کارفرما سر پرداخت اول بهونه آورد بهتر هست که هیچ وقت اون پروژه رو شروع نکنید چون احتمال اینکه شما به پولتون برسید زیره ۵ درصده!خب مورد مهم بعدی دادن RFP هست. اینکه کارفرما فکر می‌کنه که هرچی تو ذهنش هست رو به شما انتقال داده(یعنی پای تلفن یا توی جلسه به صورت شفاهی گفته) و کارش تمومه هم یکی دیگه از اشتباهاتی هست که شما باید به عنوان یه فری‌لنسر حرفه‌ای به اون آموزش بدید، نیاز پروژه باید از سمت کارفرما به صورت مکتوب در بیاد و شما توی پروپوزال همه‌ی قسمت‌های مورد نیاز رو به طور کامل پوشش بدید. اگه احساس کردید نیاز به جلسه دارید اصلا عجله نکنید و تا جایی که لازم میبینید جلسه برگزار کنید.مورد سوم که انجام هماهنگی‌های لازم هست بیشتر توی کارفرماهای شرکتی و اداری دیده میشه. اینجوری که شما برای گرفتن یه لوگو و شاید یه دسترسی کلودفلر ساده باید یک هفته ایمیل و تلفن بزنید. راه‌کار مقابله باهاش استفاده از ایمیل به عنوان یک راه ارتباطیه، که مکتوب و قابل استناده. همچنین ارتباط باید همیشه با یک نفر نماینده باشه که از طرف کارفرما معرفی شده. این خیلی مهمه که شما به فرد دیگه‌ای از سمت کارفرما نباید پاسخگو باشید. این در راستای آموزش کارفرما و راحت‌تر شدن کار خودتون در آینده کمک شایانی می‌کنه.خب مورد آخر تحویل سیستم هست که تا حدودی در راستای مورد قبلیه و اون اینه که باید نماینده و راه ارتباطی توی قرارداد ذکر شده باشه. فقط و فقط برای اینکه نماینده‌ای که توسط کارفرما معرفی شده بعدا در جاهای دیگه‌هم به رسمیت شناخته بشه و خود کارفرما هم نتونه زیرش بزنه. چون امکان داره که بعد از تایید تحویل سیستم نماینده عوض بشه و نماینده جدید امکانات و ایراد‌های جدید رو به شما اعلام کنه. در صورتی که شما پروژه رو تحویل دادید و باید پولتون رو می‌گرفتید!نتیجه‌گیریهمونطور که اول گفتم مهمترین قسمت این چالش‌ها دریافت پول هست که با کمی تمرین قابل کنترل هست. موارد بعدی هم مواردی هستن که در مجموع هر کدوم نیازی به بیشتر از یک پاراگراف توضیح نداشتن با این حال دونستنشون خالی از لطف نیست.سعی کردم تا جایی که میشه از شاخه و برگ‌های اضافی بزنم و بیشتر روی انتقال اصل موضوع تمرکز کنم. اگه چیزی رو از قلم انداختم یا پیشنهادی دارید من منتظر شنیدشون هستم. پیمان گلدسته پیمان گلدسته Mon, 07 Jan 2019 12:18:22 +0330 https://virgool.io/@p3ym4n/%DA%86%D8%A7%D9%84%D8%B4%D9%87%D8%A7%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AF%D8%B1-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D8%A8%D8%A7-%DA%A9%D8%A7%D8%B1%D9%81%D8%B1%D9%85%D8%A7%D9%87%D8%A7-%D9%88-%D8%B4%D8%B1%DA%A9%D8%AA%D9%87%D8%A7-sz3aefbxjyn7 برنامه‌نویسی در ایران چالش‌های بسیار زیادی رو با خودش به همراه داره. جدا از اینکه بعد از گذشت سال‌ها هنوز درک صحیحی از این شغل در بین عموم مردم وجود نداره، همین ناآگاهی‌ها مشکلات بسیاری رو برای افرادی که توی این زمینه فعالیت می‌کنن بوجود آورده.بار‌ها کارفرما‌هایی رو دیدم که حتی با داشتن تحصیلات مرتبط (با مدیریت پروژه یا IT)، هم درک درستی از انجام پروژ‌ه‌های نرم‌افزاری نداشتن و حتی توی خیلی از استارتاپ‌ها هم افرادی هستن که هنوز درک عمیقی از کاری که سال‌هاست دارن انجام میدن ندارن!قصد دارم که توی چند پست از این مشکلات و چالش‌ها بگم و توی هر پست به یکی از اونها بپردازم. قرار هست که این لیست مهمترین مشکلات و چالش‌ها رو در خودش جا بده.(این لیست به مرور آپدیت میشه و شما هم اگه موردی به ذهنتون رسید می‌تونید بهم بگید) نحوه مذاکره در رابطه با ارزش‌گذاری کار شما (در همکاری‌های طولانی مدت یا قراردادی)نحوه مذاکره در رابطه با انجام تعهدات کارفرما مطابق با پیش‌رفت پروژه (بیشتر در پروژه‌های فری‌لنسینگ)نحوه مذاکره و بستن قرارداد (روز ها و ساعت‌های کاری و ساعات پشتیبانی و ... ، قبل از شروع هر کاری!)هممون میدونیم که تمامی مواردی که لیست کردم خیلی قابل تفکیک از همدیگه‌ نیستن واسه همین بنا رو بر این میزاریم که با استاندارد‌های حرفه‌ای اینکار آشنا هستیم و داریم با همون دید به مسائل نگاه می‌کنیم. سعی هم می‌کنم بیشتر از اصول و مفاهیم بگم تا کسانی که برنامه‌نویسی رو تازه شروع کردن هم این مطالب رو به راحتی متوجه بشن.پ.ن. اولین مطلب قبلا ضمیمه همین پست بود که بعد از اینکه پست‌ها زیاد شدن هر کدوم رو به یک پست جدا انتقال دادم. پیمان گلدسته پیمان گلدسته Sun, 06 Jan 2019 03:31:19 +0330