مدتی است که درگیر مذاکره استخدام با یک شرکت حوزه فناوری اطلاعات و اینترنت هستم که کمی طولانی و پر پیچ خم شده. در چند پست دیگر هم به طور مستقیم و غیر مستقیم راجع به همین سری مذاکرات نوشته ام. یک ماه پیش مذاکراتم با شرکت ۶۲۲ (اسم مستعار) شروع شد. مذاکرات به خوبی پیش رفت و قرار شد به زودی کارم را شروع کنم. بلافاصله بعد از شروع کار، شرکت ۶۲۲ با شرکت کارفرمای خودش که اسم آن را ۷۰۱ (اسم مستعار) می‌گذارم مشکل پیدا کرد. نهایتاً تیم پروژه از شرکت ۶۲۲ به شرکت ۷۰۱ منتقل شد. در نتیجه این انتقال من و بقیه مجبور شدیم مذاکرات استخدام را یک بار دیگر از صفر با شرکت ۷۰۱ طی کنیم. الان که ابتدای مهر ۹۶ است، این مذاکرات هنوز تمام نشده. اول فکر می‌کردم این موضوع خیلی شخصی است و به درد کسی نمی خورد. اما بیشتر که فکر کردم دیدم که نکات زیادی در این فرایند هست و در طول آن راجع به چیزهای زیادی از وضعیت جاری IT و صنعت توسعه نرم‌افزار کشور صحبت شده که ارزش Document شدن و Share کردن دارد. در ادامه راجع به جزییات مذاکره استخدام با شرکت ۷۰۱ می نویسم.

بزرگی شرکت

شرکت ۷۰۱ تأکید زیادی روی ارزش Brand خودش دارد. در مذاکرات، مدام روی بزرگ بودن شرکت تأکید می‌شود و از کاندیداها خواسته می‌شود که در برابر این بزرگی و معروفی از توقعات مالی خود عقب نشینی کنند. در حدی که حتی کمتر از شرکت قبلی دریافت کنند. درست است که اسم یک شرکت معروف در رزومه یک برنامه نویس نکته مثبتی به حساب می‌آید ولی به چه قیمتی؟ اینکه من نوعی در یک شرکت معروف کار می‌کنم دلیل می‌شود که ده درصد زیر قیمت کار کنم؟

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

موضوع را با یک دید مثبت هم می‌توان دید. کسی که در یک شرکت بزرگ کار می‌کند با Business Ruleهای نرم افزاری که تولید می‌کند آشنایی خوبی پیدا می کند. یعنی کارمند یک شرکت بزرگ حتی اگر نرم‌افزار نویس خوبی تربیت نکند ولی می‌تواند باعث بالا رفتن دانش کارمندانش در مورد Domain باشد که نرم‌افزار برای آن تولید می شود.

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

سفته

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

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

اصولاً داستان سفته دادن و سفته گرفتن، من را یاد شاگرد مغازه ها در بازار و رستوران‌هایی می‌اندازد که آگهی می‌زنند کارگر شهرستانی با جای خواب نیازمندیم!

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

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

این موضوع به خودی خود هیچ ایرادی ندارد. موقعیت هایی وجود دارند که در آن همین مدل نرم‌افزارها کفایت می کنند. منظورم نرم افزارهایی است که عمدتا به اسکریپت های متعدد SQL وابسته هستند و بیشتر از آنکه شامل سورس کد باشند شامل ابزارهای مختلف هستند. مثلاً یک نرم افزاری که قرار است به یک تک کاربر ویندوزی محاسباتی را راجع به بورس ارائه دهد را می‌توان به همین روش‌ها ساخت و تولید کرد. در این‌طور وقت‌ها معمولاً کاربر آن برنامه اگر مجبور شود به خاطر سازگاری در ویندوز ده سال پیش بماند یا اینکه از کامپیوتر فقط برای اجرای این نرم‌افزار استفاده کند برایش قابل پذیرش است. خیلی از برنامه‌های حسابداری و اصولاً تعداد قابل توجهی از سیستم‌هایی که اصطلاحاً LOB یا Line of Business نامیده می شوند هم در هم دسته بندی جا می شوند.

سر و کار خیلی از شرکت های کوچک هم با برنامه‌هایی از این دست هستند که واقعاً نیازشان در حد LOB است ولی این موضوع در شرکت های بزرگ بیشتر است. حالا مشکل اینجاست که خیلی از مدیران شرکت های بزرگ، دیدگاهشان از نرم‌افزار همین LOB است. آن‌ها با خط کش LOB است که بقیه نرم‌افزارها و Applicationها را می سنجند. آن‌ها همه چیز را Domain و Business Logic می‌بینند. در نتیجه درک فرایندهایی مثل Refactoring، ارتقا Platform، قابلیت نگهداری کد، خوانایی، سورس کنترل، اسکرام، تولید تیکه تیکه محصول و این‌طور چیزها برایشان سخت می‌شود.

در شرکت ۷۰۱ هم مقداری زیادی سو تفاهم در این زمینه وجود دارد که باعث سخت شدن مذاکرات می شود.