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

چند روز قبل برای رفع مشکل در سیستم نرم افزاری یکی از مشتریان به شرکت آنها رفته بودم، تقریبا اولین باری بود که بخاطر اینکار به یک شرکت مراجعه می کردم، و همین کار دلیلی برای نوشتن این مطلب شد. شرکت مورد نظر فکر کنم تقریبا همزمان با ورود من به رشته نرم افزار، از نرم افزار مورد نظر استفاده می کند یعنی چیزی نزدیگ به 5 سال. ولی چیزی که برای من جالب بود، سوالات بسیار ساده و پیش پا افتاده آنها در مورد نرم افزار بود که از من می پرسیدند. سوالاتی که فکر می کردم هر کسی بعد از چند ماه استفاده از نرم افزار باید خودش در جواب دادن به آنها استاد باشد (کاربران نرم افزار مورد نظر در طول این چند سال تغییر نکرده اند.!). گفتم حق با نرم افزاریها است که اغلب اعتراضات کاربران را نادیده می گیرند(حداقل در گروههای که من از نزدیگ آنها رادیده ام). ولی یک چیز باعث شد که فورا تغییر عقیده بدهم. یک متن که تازه توی یک EBook خوانده بودم، سعی می کنم بعد از این  همیشه با این موضوع به این صورت برخورد کنم. متنی را که گفتم در کتاب Practices of an Agile Developer خوانده بودم که در پایین عین متن را آوردم. فقط چند قسمت از این کتاب را مطالعه کردم کتاب بسیار جالبی بود، و از همه زیباتر شیوه نگارش کتاب بود، در کل کتاب از دو شخصیت استفاده شده است چیزی شبیه سوژه های کارتونی یک شخصیت مثبت (یک فرشته که شیوه صحیح را نشان می دهد) و یک شخصیت منفی که شیوه اشتباه برخورد با مسئله را نشان می دهد.(جملات قرمز توصیه شخصیت منفی است و جملات سبز توصیه شخصیت مثبت است).

Listen to Users

Andy once worked for a large company that developed products for high-end Unix workstations. This wasn’t the sort of environment where you could just run setup.exe or pkgadd to install the software. You had to copy files and tune various settings on your workstation.

Andy and his team thought everything was going well, until one day Andy was walking past the tech support area and overheard a support engineer laughing loudly into the phone: “Oh, it’s not a bug; you made the same mistake everyone does.” And it wasn’t just this one engineer.

The whole department was chuckling at the poor, naïve, stupid customers.

Apparently there was a situation where you, the hapless customer, had to go tweak some obscure system file to contain a magic value, or otherwise the application would not run at all. No error message, no crash, just a big black screen followed by an abrupt exit. Granted, a line in the installation instructions mentioned this fact, but apparently some 80% of the customers missed that fact and had to instead submit to abuse via the company’s tech support line.

Whether it’s a bug in the product, a bug in the documentation, or a bug in our understanding of the user community, it’s still the team’s problem, not the user’s.

Then there was the case of the expensive manufacturing shop-floor control system that none of the users would use. It seems the first step to using the system was to log on with their name and password, and the majority of the workers in this plant were illiterate. No one have ever bothered to ask them or get their feedback, so a completely useless system was installed. (The developers in question had to retool the entire GUI to be picture-based at huge expense.)

We go to great lengths to get feedback from code using unit tests and such, but it’s all too easy to ignore the feedback from users. So not only do you need to talk to real users (not their managers or a surrogate

such as a business analyst), you need to listen to them.

Even if they sound stupid.

What It Feels Like

You don’t get irate or dismissive of stupid complaints; you can look past that and see the real, underlying problem.

Keeping Your Balance

• There is no such thing as a stupid user.

• There is such a thing as a stupid, arrogant developer.

• “That’s just the way it is” is not an answer.

• If the code can’t be fixed, perhaps the documentation and training

can be.

• Your users may have read all the documentation and will remember everything about your application all the time.

But probably not.

در پایان از همه دوستان بخاطر دیر به دیر آپ دیت شدن معذرت می خام، واقعا باور کنید فشار کار خیلی زیاد است و دلیلش هم خیلی ساده است: عدم رعایت زمانبندی، مدیریت اشتباه و …. از طرف دیگر فقط 2 ماه به کنکور مانده و من تازه می خام شروع به خواندن کنم و از همه اینها بدتر فقط یک ماه از فرجه 6 ماه مانده و احتمالا تا چند ماه بعد باید برم خدمت مثلا مقدس سربازی. از همه بدتر قضیه دنبال دار پروژه … می باشد، که واقعا نمی دانم دیگر باهاش چیکار کنم و تقریبا وقتی یادم می افته یا از طرف آنها تماس می گیرند کلاً انرژیم تخلیه می شه (نمی دانم یک پروژه مگه می تونه چقدر از زمانبندی عقب بیفته  چند هفنه، چند ماه، یک سال و چند ماه !!!!). دعا کنید ….