«پریدن تیک» یا وقتی یک «نرم افزار» برای کشور مشکل ایجاد می‌کند

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

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

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

مشکل کجاست؟

دولت بزرگترین مشتری نرم‌افزار است. به دلیل گستردگی و تنوع فعالیت‌های دولتی، سازمان‌ها و بخش‌های مختلف دولت همواره نیازمند نرم‌افزار برای سرعت بخشیدن به کارها و افزایش دقت و شفافیت هستند. اما چه اتفاقی می‌افتد که نرم‌افزارهای تولید شده در داخل کشور، بعضاً با مشکلات متعددشان کارها را پیچیده‌تر می‌کنند؟ به گمان من چند عامل در این مساله نقش دارند که در نوشته‌های دیگری به آن‌ها خواهم پرداخت:

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

تفاوت بین نگاه خوش بینانه تحلیلگران و واقعیت کار

  • عدم توجه به تجربه کاربری: یکی از تلاش‌های ما در آرایه این است که نرم‌افزار دوست داشتنی ایجاد کنیم و به کاربرانی که ساعت‌ها با نرم‌افزارهای تولیدی ما کار می‌کنند کمک کنیم تا تجربه لذت بخشی از کار با نرم‌افزار داشته باشند. ما همواره در حال یادگیری اصول مرتبط با تجربه کاربری و استفاده از آن‌ها هستیم. به کارگیری این روش، موفقیتش را در استقرار ساده‌تر سامانه‌ها و رضایت مشتریان خودش را نشان داده است. خوشبختانه در چند سال اخیر به مبحث UX توجه بیشتری شده اما هنوز در ابتدای راه هستیم. به یاد دارم دوستانی که سایت‌های وزارت خانه‌ها و سازمان‌های دولتی و اپراتورها و ... را بررسی می‌کردند و می‌کنند. متاسفانه بسیاری از نرم‌افزارها و وب‌سایت‌های دولتی هنوز ابتدایی‌ترین اصول تجربه کاربری برای دنیای امروز را رعایت نمی‌کنند.
    گاهی کار کردن با نرم‌افزارها چنان سخت و پیچیده است که کاربران حتی از همه امکانات نرم‌افزار اطلاع ندارد.
  • عدم استفاده از تست‌های نرم‌افزاری: هر جا سخن از باگ در میان است، نام عدم استفاده از Unit Test و Integration Test مناسب می‌درخشد! در این مورد شاید سری نوشته ۳۰ روز با TDD کمک کند. معتقدم عدم توجه شرکت‌های نرم‌افزاری و برنامه‌نویسان به موضوع تست، عواقب دردناکی برای آن‌ها و مشتریانشان به همراه دارد.

تصویری از Load Test یک سایت دولتی روی سرورهای اختصاصی که مشکلات نرم‌افزار استقرار یافته را نشان می‌دهد

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

صادرات نرم‌افزار و خدمات نرم‌افزاری: خوب، بد، زشت

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

صادرات ۴۰۰ میلیون دلاری نرم‌افزاری ایران: واقعیت یا افسانه؟

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

۱- صادرات نرم‌افزار: خوب

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

۲- صادرات نرم‌افزار: بد

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

۳- صادرات نرم‌افزاری: زشت

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

تجربه آرایه

ما در آرایه تجربه ارائه خدمات نرم‌افزاری برای یک مشتری بین‌المللی را داریم. مشتری ما به کمک بیش از ۷۰۰ سرور در سه دیتاسنتر در نقاط مختلف دنیا و ۲۷۰۰ سرور مجازی و ۲۰ هزار کامپیوتر در قاره‌های مختلف کسب و کارش را مدیریت می‌کند. نرم‌افزاری که ما روی آن کار کردیم مورد استفاده بیش از ۳۵ هزار کارمند بود و در اجرای کار، ما در رقابت با یک شرکت هندی بودیم. نکته جالب این بود که شرکت هندی رقیب، وقتی ما پروتوتایپی از کار را آماده می‌کردیم، پروتوتایپی با جزئیات بیشتر را آماده کرده بود! و کارشان خوب بود. آن‌ها مسلط به زبان انگلیسی بودند، تجربه اجرای موفق کارهای مشابه را داشتند و همه ایام هفته سخت کار می‌کردند (بعضاً روزی ۱۶ ساعت) و مشتریانی از سراسر دنیا داشتند...

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

درس‌هایی از استیو جابز و اپل برای کسب و کار نرم‌افزار قسمت هفتم: اهمیت استفاده از پیشنهاد کارکنان

اپل، استیو جابز و کسب و کار نرم‌افزار

اپل و استیو جابز و همکارانش درس‌های زیادی برای کسب و کارها دارند. در سری نوشته‌های «درس‌هایی از اپل برای کسب و کار نرم‌افزار» کتاب زندگینامه استیو جابز را با هم مرور می‌کنیم و درباره نکاتی که به کسب و کار نرم‌افزار مربوط است بیشتر صحبت می‌کنیم.

حکایت ۱۰۰ نفر اول اپل

اپل شرکت بزرگی است. نیروی کار شرکت‌های بزرگ مدام در حال کم و زیاد شدن هستند. در ابتدای فصل سی کتاب زندگینامه جابز درباره ۱۰۰ نفر اول اینطور می‌خوانیم:

«... جابز سالی یک بار، ارزشمندترین کارمندان اپل را به تفرجی می‌برد که "۱۰۰ نفر اول" نام داشت. انتخاب بر اساس یک راهبرد ساده انجام می‌شد: اگر مجبور بودی فقط ۱۰۰ نفر را با خودت سوار قایق نجات کنی و به شرکت بعدی ببری، چه کسانی را انتخاب می‌کردی؟
او در پایان هر تفرج، جلوی یک وایت‌بورد می‌ایستاد و می‌پرسید: ۱۰ پروژه بعدی که باید انجام دهیم چیست؟ افراد برای این که پیشنهادشان در فهرست قرار بگیرد می‌جنگیدند. جابز پیشنهادات را می‌نوشت و بعد آن‌هایی را که معتقد بود گنگ هستند ضربدر می زد. بعد از کلی شوخی، گروه به فهرستی ۱۰ تایی می‌رسید. اینجا بود که او زیر ۷ تا از آن‌ها را خط می‌کشید و می‌گفت: فقط از عهده انجام ۳ کار برمی‌آییم»

دریافت فیدبک از کارمندان

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

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

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


اهمیت فیدبک کارمندان

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

اگر به نیروی کار به چشم یک سرمایه نگاه می‌کنید، در کنار استفاده‌ای که از دانش و تجربه و کار این سرمایه می‌کنید، می‌توانید از ایده‌های کارکنان نیز برای بهبود کسب و کار خود بهره ببرید.

تولید‌کنندگان نرم‌افزاری یکی از بهترین گزینه‌ها برای استفاده از نظرات نیروهای متخصص خود هستند. نظر شما چیست؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

توسعه ترس محور یا Fear Driven Development چیست؟

توسعه ترس محور

روز گذشته اسکات هنسلمن نوشته‌ای رو در وبلاگش منتشر کرد و از ترس‌هایی که تبدیل به یک روال توسعه نرم‌افزار می‌شوند گفت. او نام توسعه ترس محور یا Fear Driven Development را برای این موضوع انتخاب کرده. شما هم در نظرات این نوشته از تجربیات خودتان درباره کار به روش ترس محور بگویید

ترس سازمانی

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

این «فلج تحلیلی» کل پروژه را کند می‌کند. یک نوشته خوب تحت عنوان «۱۰ راه برای از دست دادن تیم» وجود دارد که بسیاری از این رفتارهای منفی را پوشش داده. مواردی مثل:

  • ممنوع کردن جلسات تک به تک
  • عدم به اشتراک‌گذاری اطلاعات
  • القاء اینکه هر کسی را می‌توان جایگزین کرد
  • مدیریت به سبک Micromanagement

همه این رفتارها باعث افزایش ترس محیطی و ایجاد ابری از اضطراب در سازمان می‌شود

ترس از دست دادن شغل

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

ترس از تغییر کد

یک نوع دیگر از Fear Driven Development وقتی است که بخش توسعه نرم‌افزار سازمان یا کل سازمان از کد می‌ترسند! شاید کد قدیمی باشد (legacy code) اما معمولاً کد قدیمی فقط به خوبی درک نمی‌شود. کد قدیمی تقریباً درست کار می‌کند، اما افراد از تغییرات حتی کوچک در کد به دلیل اینکه ممکن است باعث ایجاد اثرات جانبی بشوند واهمه دارند. ترس از رگرسیون باگ- بازگشت مجدد باگ‌هایی که بسته یا رفع شده‌اند نیز باعث استرس برنامه‌نویسان می‌شود.

شما چه انواع دیگری از توسعه ترس محور را می‌شناسید؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

گزارش آماری از دستمزد برنامه‌نویسان و طراحان وب در ایران

گزارش آماری حقوق و دستمزد سال ۱۳۹۲

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

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

در این طرح آماری ۲۹ هزار نفر شرکت داشته‌اند که ۷۰ درصد آنان را مردان تشکیل می‌دهند. نزدیک به ۳۰ درصد مسلط به زبان انگلیسی بوه‌اند. ۴۵ درصد کارشناس، ۲۸ درصد سرپرست و ۲۷ درصد مدیر بوده‌اند. ۴۱ درصد فارغ‌التحصیل دانشگاه دولتی و ۳۹ درصد فارغ‌التحصیل دانشگاه آزاد و ۲۰ درصد سایر مراکز آموزشی بوده‌اند. ۵۶ درصد مدرک لیسانس و ۳۳ درصد فوق لیسانس و دکترا و سایر موارد نیز ۱۱ درصد شرکت‌کنندگان را تشکیل می‌دهند.

نکات شاخص گزارش آماری دستمزدها در سال ۹۲

  • دریافتی ماهانه در شرکت‌های خارجی فعال در ایران به طور متوسط ۳۳ درصد بالاتر از عرف بازار است و در برخی سمت‌ها متوسط این اختلاف به ۵۰ درصد نیز می‌رسد.
  • دریافتی افراد با تحصیلات فوق لیسانس به طور متوسط ۱۷ درصد بالاتر از افراد با تحصیلات لیسانس است.
  • دریافتی فارغ‌التحصیلان دانشگاه‌های دولتی به طور متوسط ۱۷ درصد بالاتر از فارغ‌التحصیلان دانشگاه‌های آزاد است.
  • متوسط دریافتی خانم‌ها در سمت‌های مشابه نسبت به آقایان ۲۳ درصد کمتر است.

بررسی حقوق و دستمزد شاغلان در حوزه فناوری اطلاعات در سال ۹۲

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

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

جزئیات دستمزد مهندسان کامپیوتر شاغل در حوزه نرم‌افزار و طراحی وب بر حسب سابقه کار به شرح زیر است:

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

اگر مشتری پولتون رو نداد با بمب ساعتی منفجرش نکنید!

بمب ساعتی نرم‌افزاری چیه؟

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

چند روز پیش در یک مهمانی افطاری بودم. روبرویم مرد جوانی نشسته بود که گویا در حرفه‌ای از مشاغل ساختمانی مشغول به کار بود. داشت از یکی از خاطراتش درباره گرفتن بدهی مشتری صحبت می‌کرد. می‌گفت کار مشتری را انجام داده و مشتری یک میلیون و هفتصد هزار تومان پولش رو نداده، ایشان هم یک روز عصر با کمک برادرش رفته بود به محل ساختمان مشتری و از دیوار بالا رفته بود و زده بود بخشی از کارش را خراب کرده بود. نگهبان ساختمان به صاحبکار زنگ می‌زند. صاحبکار خودش را می‌رساند و تهدید به شکایت و پلیس ۱۱۰ می‌کند. پاسخ پیمانکار هم این بوده که «به ۱۲۰ هم زنگ بزنی فرقی نمی‌کنه، تا با پول نقد نیای همینه» صاحبکار در نهایت به دادن چک روز راضی می‌شود اما پیمانکار فقط پول نقد را مورد قبول می‌داند. نیم ساعت بعد صاحبکار با پول نقد آمده بود.
در نهایت هم آنطور که مرد جوان تعریف می‌کرد ۱۵۰ هزار تومان دیگر گرفته بود تا خرابکاری آن روزش را درست کند! نتیجه‌گیری که مرد جوان داشت هم برایم جالب بود. می‌گفت: «در این مملکت فقط زور جواب می‌ده!»

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

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

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

در بعضی موارد هم استفاده از راهکارهای قانونی مثل شکایت و حکم جلب و ... دیده شده است.

راه حل چیست؟
قبل از اینکه درباره راه حل‌ها صحبت کنیم، می‌خواهم عبارتی در خصوص دلیل اصلی کسب و کارها را نقل قول کنم:

  هدف اصلی یک کسب و کار، سودآوری نیست، هدف اصلی یافتن و حفظ مشتریان است.

تا زمانی که درباره راه‌حل‌ها بنویسم، ضمن درخواست برای مشارکت در بحث، می‌خواهم خواهش کنم از ترکاندن مشتریان با بمب ساعتی یا هر روش دیگر جداً خودداری کنید!

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی