تغییر روش

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

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

آزاد کاری یا Freelancing ممکن است مشکلات و خطرات زیادی داشته باشد ولی در عوض ممکن است بتواند از مشکلات کار شرکتی را حل کرده و بتواند پویایی و انگیزش بالا را با خود به ارمغان بیاورد.

کاهش تمرکز مهارتی و خلاقیت در کار شرکتی

در کنار همه مزایایی که کار شرکتی دارد (در مقابل freelance بودن)، معایبی هم وجود دارد. یکی از این معایب جلوگیری از تمرکز کاری و مهارتی افراد و کاهش خلاقیت است. در شرکت‌ها رایج است که برنامه‌نویس با یک سری توانایی‌ها و علایق خاص استخدام می‌شود ولی بعدها به مرور زمان کارهای دیگری هم از او خواسته می‌شود. مثلاً طرف برنامه‌نویس C#‎ است ولی ممکن است از او CSS یا jQuery هم خواسته شود. یا مثلاً تخصص کسی در دیتابیس است ولی امورات مدیریت و نگهداری سورس کنترل هم از او خواسته می‌شود.

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

شرکت‌ها معمولاً می‌خواهند کارهایشان تنها به یک روش خاص انجام شود. بیشتر وقت‌ها هم از تغییر گریزان هستند. همین دو مشکل به تنهایی می‌تواند باعث کاهش خلاقیت ذهنی افراد برنامه‌نویس شود.

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

اصرار بی‌فایده بر کیفیت کد

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

۱- کیفیت کد (خوانایی، انجام unit test و…)
۲- بالا بودن امکان نگهداری کد برای افزایش قابلیت تغییر در آینده
۳- documentation صحیح و اصولی برای افزایش فهم کد توسط دیگران
۴- استفاده از ابزارهای Issue Tracking مثل Jira برای افزایش فهم کد توسط دیگران
۵- استفاده از ابزارهای ALM مثل سورس کنترل و Build اتوماتیک برای افزایش همکاری تیمی و افزایش کیفیت کار
۶- …

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

عدم قدرت جذب فنی

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

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

تصور کنید یک چیز خاص مثل Socket Programming، برنامه‌نویسی به زبان Python، استفاده تمام عیار از سری ابزارهای ALM مثل TFS یا git/TeamCity، اسکرام، TDD یا حتی مدیریت اصولی یک تیم استاندارد برنامه‌نویسی را خیلی خوب بلد هستید. فکر می‌کنید چند نفر باشند که به یکی دو تا از موارد بالا به طور کامل نیاز داشته باشند؟ بیشتر شرکت‌های ایرانی فقط به مقدار کم یا متوسطی از هر کدام از این مهارت‌ها نیاز دارند. نتیجتاً هر چقدر هم که شرکت‌تان را عوض کنید باز هم در محیطی قرار خواهید داشت که قدرت جذب فنی کامل شما را نداشته و مدام کارهای معمولی از شما خواهد خواست.

اندر معایب چند شغله بودن

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

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

یک سال در پرشیا شبکه

موسسه اطلاع‌رسانی مهندسی پزشکی پرشیا شبکه  که به اختصار پرشیا شبکه (PersiaBME) نامیده می‌شود نام شرکتی است که کم و بیش یک سال در آنجا کار کرده‌ام و حالا که همکاری تمام وقتم با پرشیا شبکه قطع شده است وقت آن رسیده است که مروری داشته باشم بر این یک سال.

عمده فعالیت پرشیا شبکه همان طور که می‌توان از اسمش حدس زد در حوزه شرکت‌ها و موسسات تجهیزات پزشکی است. اما این همه ماجرا نیست. پرشیا شبکه روی طیف متنوعی از نرم‌افزارهای تحت وب غیر پزشکی از جمله هتل‌داری، انتشارات و… هم کار می‌کند.

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

یکی دیگر از مزایای مهم پرشیا شبکه امکان بهره‌برداری از فناوری‌ها و روش‌های روز تولید نرم‌افزار است. همین قدر اشاره کنم که از کلیه امکانات TFS 2010 از جمله build اتوماتیک، continuous integration و work item management بر اساس اسکرام به طور کامل استفاده می‌شود و تقریباً بیشتر جاها از NHibernate استفاده شده است.

به عنوان آخرین آیتم از فهرست خوبی‌ها باید اشاره‌ای هم داشته باشم به قابلیت کار از راه دور و نیاز خیلی کم به ارتباط چهره به چهره. این روش کار برای من در یک سری موارد بسیار مفید و با ارزش بوده.

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

با همه خوبی‌ها و بدی‌ها، به پرشیا شبکه بدرود می‌گویم. به پرشیا شبکه‌ای که با داشتن کمترین رانت (تا آنجا که من می‌دانم) همیشه به فکر کسب رضایت مشتری‌هایش بوده است. بدرود!

پ.ن. ۱: فکر می‌کنم پرشیا شبکه هنوز هم در حال جذب نیروی جدید برنامه‌نویس باشد. لطفاً رزومه‌هایتان را به آدرس info atsign persiabme dot com بفرستید. جهت کسب اطلاعات بیشتر به اینجا مراجعه کنید.

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

تولید نرم‌افزار یا تحقیق و توسعه؟

خیلی وقت‌ها (نه بعضی وقت‌ها) حس می‌کنم کارم به عنوان یک مهندس نرم‌افزار به جای تولید نرم‌افزار (software development) تبدیل شده به تحقیق و توسعه (R and D). البته فکر می‌کنم این فقط مشکل من نباشد. فقط کافی است به بعضی شرکت‌ها سر زده و نگاهی به مانیتور افراد بیندازید. خیلی‌ها را پیدا می‌کنید که از صبح تا شب یا در حال PDF خوانی هستند یا همیشه در حال کار روی پروژه‌های تستی و آزمایشی هستند.

تحقیق و توسعه (R and D) لزوماً چیز بدی نیست. اما اولاً که برنامه‌نویس‌ها معمولاً برای درست برنامه‌نویسی آموزش دیده‌اند نه R and D و ثانیاً این که تاکید زیاد به R and D می‌تواند نشانه‌ای از آموزش غلط برنامه‌نویسان یا کم سوادی تصمیم‌گیرندگان شرکت باشد.

آیا نرم‌افزار تجارت کثیفی است؟

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

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

این طور مسائل هم باعث می‌شود سازمان‌ها و افراد دید چندان مثبتی نسبت به کار نرم‌افزار نداشته باشند و هم باعث می‌شود رقابت در بین شرکت‌های نرم‌افزاری کمی کثیف شود.

‫شرکت‌های «الف» و «ب»

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

شرکت «ب» هیچ فریمورک درست و حسابی ندارد. اختلاف سطح بین افراد تیم برنامه‌نویسی خیلی زیاد نیست. گاهاً اگر لازم شود از ابزارهای ساده‌تری مثل دلفی و اکسس هم استفاده می‌کند. documentation در شرکت «ب» غنی‌تر است، دامنه اختیارات و مسئولیت‌های برنامه‌نویس‌ها بیشتر است. افراد اعتماد به نفس بیشتری داشته و کارهای پیچیده‌تری هم می‌توانند انجام دهند. به طور کلی آدم‌های شرکت «ب» انگیزه بیشتری برای کار و پیشرفت دارند.

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

شرکت‌های «الف» مصاحبه‌های راحت‌تری دارند، مسئولین شرکت معمولاً فارغ التحصیلان غیر نرم‌افزار هستند، در انجام پروژه‌ها موفق‌ترند چون هدف آنها صرفاً انجام کار است نه داشتن یک تیم فنی قوی، آموزش نیرو چندان اهمیتی ندارد، وقتی رییس نیست کار تعطیل می‌شود و…

شرکت‌های «ب» دوام کمتری دارند چون بازار ایران تمایل کمتری نسبت به آنها دارد، برنامه‌نویسان آنها self motivated هستند یعنی لازم نیست مدام یک نفر کار آنها را چک کرده یا به آنها یادآوری کند، علاقه به low level، مطالعه و open source در برنامه‌نویسان شرکت بیشتر است و…

اینها نظرات شخصی، خام و اولیه من بودند راجع به انواع شرکت‌ها. نظر شما چیست؟

پ.ن.: حرکت از سمت شرکت‌ها و تیم‌های نوع «الف» به شرکت‌ها وتیم‌های نوع «ب» همواره یکی از انگیزه‌های قوی بنده بوده برای شرکت عوض کردن.

از این شرکت به اون شرکت

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

در بعضی شرکت‌ها رفت و آمد پروژه و پول خیلی خوب است اما تیم فنی خیلی ضعیف است. در بعضی شرکت‌ها تیم فنی خیلی خوب کار می‌کند اما مدیریت شرکت ضعیف است. در بعضی شرکت‌ها انضباط (Disipline) بسیار خوبی حاکم است اما بعضی تصمیم گیری‌های تکنولوژیک کار را به بیراهه می‌کشاند. در بعضی شرکت‌ها پول، نیروی انسانی خوب و شهرت کافی وجود دارد اما بی‌نظمی کار را خراب می‌کند. در بعضی شرکت‌ها…

واقعاً چرا؟