نگاهی به نکات مذاکره حقوق برنامه‌نویسان قسمت اول: حقوق و عوامل موثر در آن

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

چقدر حق من است؟

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

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

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


معمولاً برای کارفرما، میزان ارزش آفرینی شما در عمل برای کسب و کارش، معیار تعیین حقوق است نه روزمه شما

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

چه عواملی بر حقوق تاثیر دارند؟

یک سری عوامل به صورت طبیعی بر میزان حقوق برنامه‌نویسان تاثیر دارند. مهم‌ترین این عوامل عبارتند از:

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

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

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

ساختار تیم‌های مدرن نرم‌افزاری قسمت چهارم: مدیریت ارتباطات بین اعضای تیم

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

مدیریت ارتباطات برای هر کار تیمی لازم است

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

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

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

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

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

نکات مهم در برقراری و حفظ ارتباط موثر در تیم‌های نرم‌افزاری

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

اگر developer شما فکر می‌کنه بتمن هست، اگر بت موبیل در اختیارش نمی‌گذارید، مهم نیست
اما اگر بهش بگید بتمن نیست، احتمالاً دیگه نمی‌تونید روی کمکش به تیم حتی به عنوان بت کید حساب کنید! 

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

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

این نگاه انسانی به نیروی کار، حتی در حوزه‌های دیگه هم وارد شده: اخیراً لینکی رو در بخش لینک‌های روزانه قرار دادم تحت عنوان "گوگل و سرمایه‌های انسانی" که نویسنده اشاره کرده بود که حتی نام بخش منابع انسانی یا سرمایه‌های انسانی (که در ایران بیشتر کارگزینی گفته می‌شه!) به بخش People Operations تغییر کرده، یا مثال دیگه در مورد تغییر ارزیابی‌ و رتبه‌بندی سنتی در مایکروسافت و جایگزینی آن با جلسات حضوری تحت عنوان connect‌ است.

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

اما این حرف زدن (در مورد کار) به تنهایی کافی نیست. باید مهارت گوش دادن موثر (و نه صرفاً شنیدن) و مشاهده موثر رفتارها را در خودتون (به عنوان مدیر تیم یا عضوی از تیم) تقویت کنید. بعد از تقویت این مهارت‌ها، افراد راحت‌تر به رشد و رفع نقایص خودشون و تیم کمک می‌کنند.

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

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

چطور اینترنت ما را به سطحی خواندن عادت داد و برای درمانش چه کنیم؟

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

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

امروز و بعد از گذشت چند سال بیشتر و بهتر به اثراتی که آقای کار در آن مقاله در موردشان هشدار داده بود پی می‌برم.

با بیشتر شدن اطلاعات قابل دریافت و راحت‌تر شدن راه‌های دریافت‌ آن‌ها و با توجه به ظرفیت دریافت اطلاعات،
باید یواش یواش مثل شلدون کوپر به این فکر باشیم که فقط اطلاعات لازم را دریافت کنیم!

ظرفیت دریافت اطلاعات ما چقدر است؟

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

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

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

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

در مثال بالا اگر به طور متوسط برای خواندن هر تیتر مطلب، 10 ثانیه وقت صرف کنید، فقط برای خواندن تیتر مطالب، نزدیک به 3 ساعت وقت باید صرف کنید. در این شرایط یا گزینه mark as read را انتخاب می‌کنید یا اگر وسواس فکری برای دیدن همه اطلاعات و گزینش بهترین‌ها پیدا کرده باشید، با حذف برخی به صورت تصادفی (که احتمالاً با دیدن یک کلمه در تیتر اتفاق می‌افتد) یا با نگاه کردن به وضعیت share شدن آن مطالب (امکاناتی که بعضی فیدخوان‌ها در اختیار کاربرانشان قرار می‌دهند) سعی می‌کنید که مطالعه مطالب روز را به پایان برسانید.

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

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

در مقابل این اثرات منفی چه می‌شود کرد؟

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

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

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

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

شما هم اگر راه حلی می‌شناسید در کامنت‌ها اعلام کنید. در این مورد بیشتر صحبت می‌کنیم، امیدوارم این مطلب را تا انتها خوانده باشید!

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

آیا فناوری و اینترنت ما را خنگ می‌کند؟

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

امروز اما می‌بینم خودم و بسیاری از مردم عملاً بدون آنکه از پیوندهای مکانیکی عضو به بدنمان خبری باشد تبدیل به انسان-ماشین شده‌ایم.

دانش ما اکنون به صورت گسترده‌ای وابسته به حافظه‌هایی غیر از حافظه طبیعی‌مان شده است. چند تا شماره تلفن را بدون مراجعه به دفترچه تلفن گوشی همراهتان می‌توانید بگویید؟ من برنامه‌نویس هستم، برنامه‌نویس‌ها به خاطر شغلشان مجبورند چیزهای زیادی را به خاطر بسپارند، اما حالا با کمک اینترنت یا مثلاً نصب MSDN دیگر لازم نیست زحمت به خاطرسپردن را متحمل شوم: هر جا گیرکردم، یک جستجوی کوچک راهگشاست.

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

این‌ها عالی هستند اما سوالی که پیش می‌آید این است که امروز ما از توانایی‌های ذهنی‌مان در چه جهتی استفاده می‌کنیم؟ ما دیگر مثل پدربزرگ‌هایمان شاهنامه و گلستان را حفظ نیستیم، شاید نیازی هم نباشد چون امروز نرم‌افزار می‌تواند به ما بگوید حافظ چند بار از کلمه "باده" در اشعارش استفاده کرده، کاری که پدربزرگ با همه تجربه‌اش نمی‌توانست انجام بدهد.

وقتی چنین امکانات فوق‌العاده‌ای در اختیار ما قرار می‌گیرد به طور طبیعی ما قادر خواهیم بود از ذهنم و حافظه‌مان برای مسائل مهمتری استفاده کنیم، ولی این مسائل چی هستند؟

اگر تصمیم‌گیری‌های عادی و روزمره را کنار بگذاریم، می‌بینیم مردم دیگر تمایلی به استفاده کردن از مغزشان ندارند. آیا ما داریم تبدیل به آدم‌های چاق و تنبل wall-e می‌شویم؟

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

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

دیزاین متفاوت سایت‌ها: خوب یا بد؟

در دنیای طراحی وب، با سبک‌های مختلفی در طراحی چه از نظر ظاهری و چه از نظر ساختاری روبرو هستیم. یک روز استفاده از وب سایت‌های سنتی با انواع صفحات کاربردی است و روز دیگر SPA یا Single Page Application ها رواج می‌یابد. گاهی اوقات طراحان وب، طرح‌های خلاقانه‌ و متفاوتی را ارائه می‌دهند. طرح‌هایی که کمتر سایت مشابهی را می‌توان برایش پیدا کرد.

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

قانون تجربه اینترنتی جیکوب

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

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

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


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

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

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

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

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

تست جوئل قسمت دوازدهم: کاربردپذیری راهرویی

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

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

تست دوازدهم جوئل: آیا از آزمایش "کاربردپذیری راهرویی" استفاده می‌کنید؟

در ابتدای توضیح درباره آخرین تست جوئل، باید اشاره کنم که کاربردپذیری را به عنوان ترجمه‌ای برای usability به کار بردم و در اینجا منظور از آن طراحی واسط کاربر یا user interface برای نرم‌افزارهاست.

جوئل اشاره می‌کند که "در تست hallway usability، شما خِر اولین فردی را که از راهرو رد می‌شود می‌گیرید و مجبورش می‌کنید بنشیند پای برنامه‌ای که الان نوشته‌اید. اگر با 5 نفر این کار را تکرار کنید، 95 درصد مشکلات usability برنامه‌تان را کشف خواهید کرد"

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

usability در نرم‌افزار و بررسی یک مثال از UI نامناسب

به این توصیه‌ها که به تازگی در اکانتم در توییتر نوشتم توجه کنید:

  • قرار دادن label در بالای textbox ها به جای قرار دادن در کنار، کمک می‌کنه چشم در حال پایین اومدن در صفحه راحت‌تر فرم رو ببینه. 
  • به جای استفاده از yes / no در popup ها که کاربر رو مجبور می‌کنه توضیح رو بخونه، عملیات رو در متن دکمه بنویسیم مثلاً save و don't save
  • از اینکه دکمه‌های عملیاتی (مثل reply) در hover نمایش داده بشن به جا استفاده کنید. مرورگرهای موبایل hover شدن موس رو درک نمی‌کنند.
این توصیه‌ها و سایر موارد مشابه، برای ایجاد ظاهری راحت‌تر برای کاربران نرم‌افزار هستند. در خصوص مواردی که به ایجاد یک UI خوب نرم‌افزاری می‌انجامد، در آینده یک سری نوشته را شروع خواهم کرد، اما تا آن موقع با یک مثال، بحث UI را بیشتر بررسی می‌کنیم.
 
اخیراً با پروژه‌ای درگیر شدم که هدفش ایجاد یک سیستم نظرسنجی ساده است که البته ویژگی‌های خاص خودش را دارد. تصویر زیر، تصویر پیشنهادی برای UI بخش ثبت نظرسنجی و سوالات آن است. 
تصور کنید که من بر اساس تست hallway usability شما را در حین رد شدن در راهرو شکار می‌کنم و می‌نشانم پشت سیستمی که برنامه‌ای با UI بالا در آن اجرا شده. حالا از شما می‌خواهم که یک نظرسنجی جدید ثبت کنید و تعدادی سوال نیز در آن وارد نمایید. سناریوهای انجام کار به شرح زیر هستند:
 
ثبت یک نظرسنجی جدید: شما ابتدا باید در textbox شماره 2 یک نام را برای نظرسنجی وارد کنید،‌ سپس دکمه شماره 6 را بزنید.
 
ثبت سوال برای یک نظرسنجی: ابتدا نظرسنجی مورد نظر را با استفاده از شماره 1 انتخاب کنید، بعد در شماره 3، عنوان سوالتان را بزنید و دکمه شماره 4 را کلیک کنید.
 
با توجه به توضیحات بالا و صرفنظر از اینکه برای همه سناریوها (مثل ویرایش یا حذف نظرسنجی) امکانی در نظر گرفته نشده است، سایر سناریوهای کار کاربر را می‌توانید حدس بزنید که چگونه خواهند بود.
 
خب حالا با شرایط بالا، شما که به خاطر بدشانسی گرفتار hallway usability test‌ من شده‌اید،‌ محو تماشای فرم هستید و خب خبر بد برای من این خواهد بود که نمی‌توانید با این فرم کار کنید!
این کار به نظر ساده خیلی کمک می‌کند که شما به عنوان برنامه‌نویس، اشکالات کاربران را شناسایی کنید. تحویل نرم‌افزار را برای شما ساده‌تر می‌کند و در نهایت کاربران هم، نرم‌افزار شما را قبول می‌کنند. در مورد پذیرش نرم‌افزار توسط کاربران هم باید مطلب جداگانه‌ای بنویسم، فعلاً فقط یادتان باشد که hallway usability test به شما کمک می‌کند تا نرم‌افزارهای قابل پذیرش درست کنید.
 
در خصوص استفاده از این تست، خاطره جالبی دارم. یک بار به یکی از همکاران تازه وارد که برنامه‌نویس قهاری در زمینه تولید نرم‌افزارهای دسکتاپ بود اما تجربه‌ای در تولید نرم‌افزارهای تحت وب نداشت و البته با محیط شیرپوینت نیز آشنایی نداشت، یک راهکار اجرا شده در بستر شیرپوینت را نشان دادیم و خواستیم که با آن کار کند. نتیجه فوق‌العاده بود: چیزهایی که برای ما (به دلیل کار بیش از حد با user intreface شیرپوینت) عادی شده بود برای آن همکارمان تازگی داشت و این یعنی فرض‌هایی که درباره میزان اطلاع کاربران نهایی سیستم از نحوه کار آن داشتیم چندان درست نبودند.
 
به طور کلی، یکی از دام‌هایی که در تولید UI نرم‌افزارها وجود دارد این است که چون من می‌فهمم که چطور باهاش کار کنم، دیگران هم خواهند فهمید. hallway usability test به شما کمک می‌کند که صحت این ادعا را بسنجید!
به اشتراک گذاری این نوشته در شبکه‌های اجتماعی