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

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

تست یازدهم جوئل: آیا داوطلبان جدید، در موقع مصاحبه کد هم می‌نویسند؟

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

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

در این نوشته می‌خواهم به باید‌ها و نباید‌ها در حوزه همین تست کدنویسی بپردازم.


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

 
نکاتی درباره برگزاری تست کدنویسی

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

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

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

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

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

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

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

نکته پایانی اینکه حتماً برای بررسی نتیجه و کد خروجی داوطلب، وقت بگذارید (که بهتر است در حضور وی هم نباشد) و انتظار نداشته باشید که در 5 دقیقه و با پرسیدن 2 سوال، کد وی را مورد ارزیابی قرار بدهید. شاید لازم باشد برای بررسی کدها از نظر سایر افراد هم کمک بگیرید.

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

تست جوئل قسمت دهم: تست نرم‌افزارها

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

تست دهم جوئل: آیا بخش تست شما جداست؟

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

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

در ادامه هم لینکی به توضیح 5 دلیل اصلی اشتباه استخدام نکردن Tester ها داده شده است که در مطلب جداگانه‌ای آن را برای شما ترجمه خواهم کرد. 

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


آیا نرم‌افزار من احتیاج به تست دارد؟

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

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


در مجموعه داستان‌های 007، تصور کنید اگر گجت‌هایی که Q درست می‌کرد تست نمی‌شدند، چه بلایی سر جیمز باند می‌آمد!


چطور نرم‌افزارم را تست کنم؟

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

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

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


Tester کیست و چه وظایفی دارد؟

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

بنابراین شخص Tester یا اعضای تیم تست، دو مدل کار بر عهده دارند: یکی اینکه بر اساس Test Case‌های تهیه شده به صورت دستی اقدام به تست نرم‌افزار کنند. معمولاً در Test Case ها مراحل تست و نتایج مورد انتظار مشخص هستند و بنابراین این بخش کار چندان مشکل نیست.

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

دقت کنید که وظیفه Tester ارائه راه‌حل نیست، حتی قرار نیست که Tester یک برنامه‌نویس باشد. وظیفه Tester اندازه‌گیری معیارهای مشخص و گزارش نتیجه به تیم تولید نرم‌افزار است. نتیجه اندازه‌گیری این معیارها گاهی کاملاً شفاف و قابل ارائه در قالب اعداد مثلاً تعداد باگ‌های یک نرم‌افزار. گاهی هم کیفی هستند مثل میزان user friendly‌ بودن نرم‌افزار. 

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

نابینایی سازمان‌ها و راه درمان آن

چند هفته پیش برای تدریس در یک کارگاه 2 روزه آموزشی شیرپوینت برای مدیران و کارشناسان فناوری اطلاعات سازمان‌های دولتی به محمودآباد رفته بودم. در این سفر، یکی از دوستانم همراهم من بود تا پیش از من، در مورد business intelligence برای شرکت کنندگان ارائه‌ای داشته‌ باشد.

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

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

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

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

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

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

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

راه حل چیست؟ استفاده از داده‌های ذخیره شده در سازمان برای بینایی بخشیدن به تصمیمات سازمان.


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

تصمیم‌گیری هوشمندانه یا بینایی سازمان‌ها

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

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

وقتی از business intelligence صحبت می‌کنیم می‌خواهیم امکانی را برای سازمان‌ها فراهم کنیم که از محفوظاتشان (همان داده‌های نرم‌افزاری مختلف) به شکل آنی استفاده کرده و شاخص‌های خود را اندازه‌گیری کنند. در واقع می‌خواهیم داده‌های نرم‌افزاری را در تصمیم‌گیری مدیران موثر کنیم.

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

این مطلب را به عنوان مقدمه‌ای در گوشه ذهنتان داشته باشید، در مورد business intelligence بیشتر صحبت خواهیم کرد.

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

استفاده از کنترل CssRegistration در شیرپوینت 2010

چه در یک masterpage، چه در یک وب پارت، اگر بخواهیم فایل css ای را load کنیم، روش‌های مختلفی وجود دارد. یکی از روش‌های استاندارد در شیرپوینت برای تعریف فایل‌های css استفاده از کنترل CssRegistration است. قصد دارم در این مطلب به صورت کوتاه این کنترل را معرفی کنم.

اگر بخواهیم به صورت markup از این کنترل استفاده کنیم به شکل زیر خواهد بود:

 

در صورتی که در کد بخواهیم از آن استفاده کنیم از کدی مانند کد زیر می‌توان استفاده کرد:

 var myCss = new CssRegistration();
 myCss.Name = "CSS_URL";
 myCss.After = "corev4.css";

در کد بالا در خط مشخص شده، آدرس فایل css مورد نظر را وارد خواهیم کرد.

این کنترل چند مزیت نسبت به یک تگ link ساده دارد:

امکان تعیین ترتیب load

به کمک خاصیت After که در کد بالا هم مشخص شده است، می‌توانیم مشخص کنیم که فایل css ما بعد از چه فایلی load شود. این مساله به خصوص در پیاده‌سازی تم جدید برای شیرپوینت حائز اهمیت است تا بتوانیم css‌های پیش‌فرض شیرپوینت را به درستی override کنیم.
به عنوان مثال در کد سی شارپی بالا، فایل css ما بعد از corev4.css لود خواهد شد. 

امکان تعیین شرط برای load

به کمک خاصیت ConditionalExpression در این کنترل می‌توان css های شرطی ایجاد نمود. به عنوان مثال اگر ConditionalExpression را برابر IE 7.0 قرار دهیم خروجی مشابه زیر حاصل خواهد شد.

 

امکان اینکه مرورگری غیر IE هم در این شرط‌ها لحاظ شود وجود دارد، اما باید RevealToNonIE را true مقداردهی کنید.

امکان ایجاد پوسته برای استایل‌ها

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

امکان تعیین آدرس نسبی برای فایل‌ها در کد

چه در زمانی که به صورت markup از این کنترل مثلاً در masterpage یا page layout استفاده می‌کنیم چه زمانی که آن را در یک کد سی‌شارپی به کار می‌بریم این امکان وجود دارد که آدرس فایل css را به صورت نسبی بدهیم. مثلاً در کد اول این نوشته که به صورت markup هست عبارت sitecollection~ مشخص کننده آدرس مجموعه سایت است. 
مزیت این کار در این است که انتقال کد حاوی کنترل CssRegistration‌ از محیط توسعه به محیط مشتری، نیازمند تغییر و تنظیم مجدد نیست. 

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

تست جوئل قسمت نهم: خریدن بهترین‌ها

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

نهمین سوال تست جوئل: آیا بهترین ابزارهایی که وجود دارد را می‌خرید؟

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

به هر حال سوال اصلی اینجاست که آیا دستیابی به پاسخ مثبت برای این سوال برای شرکت‌های ایرانی امکان‌پذیر است؟

چند سال پیش مطلبی در وبلاگ بهساد منتشر شد تحت عنوان "چگونه بدون پول شرکت تاسیس کنیم؟" در آن اشاره شده بود که مثلاً خرج کردن برای شبکه بی‌سیم در ابتدای کار درست نیست یا می‌توان به جای مانیتور LCD از مانیتورهای CRT استفاده کرد و ...

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

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

در همین حال من توسعه برنامه‌های وب بر مبنای ASP.NET MVC هم انجام می‌دهم اما این کار بر روی لپ تاپی که 4 گیگابایت RAM دارد هم قابل انجام است.


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

اجازه بدهید مثال دیگری بزنم: تصور کنید که یک طراح دارید که وظیفه‌اش طراحی ظاهری سایت‌ها و برنامه‌ها و پیاده‌سازی آن طرح‌هاست. ارائه یک مانیتور CRT مثلاً 17 اینچ (که تا 1280 پیکسل را پشتیبانی می‌کند) به این طراح اشتباه است و او برای انجام بهتر کارش حداقل به یک مانیتور 20+ اینچ با رزولویشن 1600 در 900 پیکسل احتیاج دارد.

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

به جز کاربرد مورد انتظار، باید به یک نکته دیگر هم توجه داشت، آن هم واقعی کردن انتظار ما از ابزارها است. دوستی دارم که در این مواقع می‌گوید A bad worker always blames his tools. این حرف درستی است. در واقع ابزارها باعث موفقیت ما نمی‌شوند، اگر آدم موفقی باشیم، اگر تیم موفقی باشیم، این ابزارها کمک می‌کنند که سریع‌تر به اهدافمان برسیم و وقت کمتری را به خاطر مسائل زیرساختی تلف کنیم.

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

نرم‌افزار یا کالای تزئینی

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


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

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

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

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

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

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

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

وقتی نرم‌افزار خیلی بر روی دردهای سازمان مرهم نباشه، تبدیل می‌شه به یک کالای تزئینی.

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

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

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

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