انتخاب نرم‌افزار مدرسه؛ پیش از خرید، یک اجرای آزمایشی مفید طراحی کنید
پیش از خرید نرم‌افزار مدرسه، یک کار واقعی را با مشارکت معلمان و خانواده‌ها امتحان کنید و نتیجه را بر اساس شواهد، پشتیبانی و شرایط مدرسه بسنجید.
انتخاب نرم‌افزار مدرسه گاهی در یک جلسه معرفی بسیار ساده به نظر می‌رسد. فروشنده صفحه‌ها را باز می‌کند، چند گزارش نشان می‌دهد و توضیح می‌دهد که کارها چطور سریع‌تر انجام می‌شوند. اما پرسش مدیر هنوز باقی است: آیا همکاران ما هم می‌توانند با همین ابزار، در شرایط واقعی مدرسه، کار مورد نیازشان را انجام دهند؟ پاسخ این پرسش را باید در استفاده دید، نه فقط در نمایش امکانات.
فرض کنید مدرسه می‌خواهد روند رساندن گزارش پیشرفت به خانواده‌ها را بهتر کند. هدف فقط فرستادن یک فایل نیست؛ معلم باید بتواند اطلاعات مناسب را آماده کند، خانواده آن را پیدا کند و بفهمد قدم بعدی چیست. اجرای آزمایشی محدود فرصتی است برای دیدن همین مسیر. مدیر با مشارکت چند کاربر بررسی می‌کند ابزار پیشنهادی کجا کمک می‌کند، کجا ابهام می‌سازد و برای استفاده پایدار چه پشتیبانی‌ای لازم دارد.
انتخاب نرم‌افزار مدرسه را به یک نیاز روشن گره بزنید
پیش از درخواست دمو، جمله‌ای بنویسید که مسئله را بدون نام هیچ محصولی توضیح دهد. مثلاً «خانواده‌ها گزارش را دریافت می‌کنند، اما نمی‌دانند برای پیگیری یادگیری فرزندشان چه کاری انجام دهند.» این جمله با «نرم‌افزار گزارش‌گیری می‌خواهیم» فرق دارد. شاید بخشی از مشکل از متن گزارش، زمان ارسال یا نبود فرصت گفت‌وگو ناشی شود؛ در این صورت ابزار تازه به‌تنهایی پاسخ کامل نیست.
راهنمای بنیاد موقوفه آموزش بریتانیا، EEF، درباره فناوری دیجیتال بر شروع از نیاز آموزشی و برنامه‌ریزی برای آموزش و پشتیبانی تأکید دارد. این نگاه برای مدیر مهم است: ابتدا روشن کنید چه بهبودی انتظار دارید و سپس ببینید ابزار چگونه به آن کمک می‌کند. در این مقاله، اجرای آزمایشی پیشنهادی برای بررسی تناسب ابزار با کار مدرسه است؛ نتیجه آن را نباید به‌تنهایی اثبات افزایش یادگیری دانست.
نیاز منتخب را محدود نگه دارید. اگر هم‌زمان ثبت‌نام، تکلیف، ارتباط خانواده و گزارش مدیریتی را امتحان کنید، فهمیدن علت نتیجه دشوار می‌شود. یک مسیر کامل اما کوچک انتخاب کنید؛ کاری که شروع و پایانش معلوم باشد و کاربران بتوانند درباره تجربه انجام آن توضیح بدهند. امکانات دیگر را برای مرحله بعد نگه دارید تا جذابیت فهرست قابلیت‌ها، مسئله اصلی را پنهان نکند.
بیشتر بخوانید
اگر هنوز معلوم نیست کدام نیاز مدرسه باید زودتر بررسی شود، ابتدا این راهنما را بخوانید:
از فروشنده بخواهید مسیر کار شما را نشان دهد
در جلسه معرفی، به‌جای درخواست نمایش همه منوها، یک سناریو مطرح کنید. برای مثال بگویید: «معلم می‌خواهد گزارش کوتاهی را برای یک گروه مشخص آماده کند؛ خانواده باید آن را ببیند و مدرسه بداند برای پرسش احتمالی از چه مسیری پاسخ می‌دهد.» سپس بخواهید هر بخش، با نقش همان کاربر نشان داده شود. دیدن صفحه مدیر کافی نیست؛ ممکن است کاری در آن صفحه ساده باشد اما کاربر دیگری به اطلاعات یا اختیار لازم دسترسی نداشته باشد.
بخش‌های نامعلوم را همان‌جا جدا کنید. آیا این کار در نسخه قابل خرید وجود دارد یا فقط درباره توسعه آینده صحبت می‌شود؟ آیا انجام آن به سرویس دیگری وابسته است؟ آیا همکار مدرسه باید بخشی از اطلاعات را دوباره وارد کند؟ این پرسش‌ها قرار نیست جلسه را به بازجویی تبدیل کنند؛ کمک می‌کنند دو طرف درباره کاری که باید انجام شود برداشت مشترکی داشته باشند.
دمو و اجرای آزمایشی هم یکسان نیستند. در دمو معمولاً فردی مسلط، مسیر آماده‌ای را نشان می‌دهد. در آزمایش، کاربر مدرسه باید خودش کار را انجام دهد و امکان توقف یا اشتباه داشته باشد. پیش از شروع، با ارائه‌دهنده درباره دسترسی، مدت، امکانات قابل استفاده و شرایط پایان آزمایش توافق کنید. در دسترس‌بودن نسخه آزمایشی، رایگان‌بودن آن یا یکسان‌بودنش با نسخه نهایی را فرض نکنید.
کاربران آزمایش فقط همکاران مسلط به فناوری نباشند
اگر ابزار قرار است در اختیار افراد متفاوتی قرار بگیرد، گروه آزمایش هم باید بخشی از این تفاوت را نشان دهد. در کنار همکاری که با سامانه‌ها راحت است، از فردی دعوت کنید که برای شروع به راهنمای روشن‌تری نیاز دارد. اگر خانواده‌ها کاربر هستند، تجربه آن‌ها را نیز بررسی کنید؛ به‌خصوص تفاوت دستگاه، فرصت استفاده و آشنایی با ابزارهای دیجیتال را در نظر بگیرید.
تعداد افراد را متناسب با امکان پشتیبانی انتخاب کنید، نه برای ساختن یک نمایش شلوغ. هدف این مرحله، پیدا کردن ابهام‌ها و سنجیدن امکان اجرای کار است. یک گروه کوچک نماینده قطعی تمام مدرسه نیست، اما می‌تواند پرسش‌هایی را آشکار کند که در جلسه فروش دیده نمی‌شوند. ثبت کنید چه گروه‌هایی در آزمایش حضور نداشتند تا نتیجه محدود را به همه کاربران تعمیم ندهید.
به همکاران توضیح دهید که قرار نیست مهارت آن‌ها نمره‌گذاری شود. وقتی فرد از قضاوت‌شدن نگران باشد، ممکن است مشکل خود را نگوید یا از دیگری بخواهد کار را به‌جایش انجام دهد. مدیر به مشاهده صادقانه نیاز دارد: کاربر کجا مکث کرد، کدام عبارت را نفهمید و برای چه کاری کمک خواست. همین جزئیات برای تصمیم درباره آموزش و پشتیبانی ارزشمندند.
آزمایش را شبیه یک روز معمول مدرسه اجرا کنید
ابتدا با اطلاعات نمونه و غیرشخصی شروع کنید تا بتوانید مسیر را بدون ورود شتاب‌زده پرونده‌های واقعی امتحان کنید. نقش‌ها، کار مورد انتظار و مسئول پاسخ‌گویی را از پیش مشخص کنید. اگر مرحله بعد به اطلاعات واقعی نیاز داشت، مسئول سامانه باید پیش از انتقال، دسترسی‌ها، ضرورت اطلاعات و شرایط نگهداری آن‌ها را بررسی کند. آزمایش کوچک نباید به جابه‌جایی بی‌برنامه تمام داده‌های مدرسه تبدیل شود.
از کاربر بخواهید یک کار مشخص را از ابتدا تا پایان انجام دهد. در مثال گزارش پیشرفت، معلم نمونه گزارش را آماده می‌کند و فردی در نقش دریافت‌کننده تلاش می‌کند آن را پیدا و باز کند. سپس از او بخواهید با زبان خودش بگوید از گزارش چه فهمیده و قدم بعدی را چه می‌داند. ممکن است فایل بدون مشکل باز شود، اما پیام آموزشی همچنان مبهم باشد؛ این تفاوت برای تصمیم مدیر مهم است.
شرایط استفاده نیز تا حد ممکن به محیط معمول نزدیک باشد. اگر بیشتر خانواده‌ها از تلفن همراه استفاده می‌کنند، نتیجه آزمون روی رایانه دفتر کافی نیست. اگر معلم در زمان کوتاهی میان دو فعالیت کار را انجام می‌دهد، مسیر طولانی را فقط با این استدلال که «بالاخره شد» موفق ننامید. در عین حال، یک مشکل اتصال مقطعی را فوراً به ضعف قطعی نرم‌افزار نسبت ندهید؛ موقعیت و علت احتمالی را ثبت و دوباره بررسی کنید.
یک یادداشت ساده کافی است: کار چه بود، چه کسی با چه نقشی آن را انجام داد، چه اتفاقی افتاد و چه پرسشی باقی ماند. مشاهده را از برداشت جدا بنویسید. «کاربر محل گزارش را پیدا نکرد» مشاهده است؛ «کاربر علاقه‌ای به فناوری ندارد» نتیجه‌ای است که از آن مشاهده به دست نمی‌آید. شاید عنوان بخش نامفهوم بوده یا راهنمای شروع کافی نبوده است.
نتیجه را با معیارهایی که از قبل تعیین کرده‌اید بسنجید
پیش از آزمایش روشن کنید چه چیزی برای مدرسه ضروری است. در سناریوی گزارش، رسیدن اطلاعات به فرد درست، قابل فهم بودن پیام و امکان انجام کار توسط مسئول مربوط می‌تواند ضروری باشد. زیبایی نمودارها ممکن است مطلوب باشد، اما نباید شکست در یک نیاز اساسی را جبران کند. معیارها را پس از دیدن محصول محبوبتان تغییر ندهید تا نتیجه مقایسه قابل دفاع بماند.
| چیزی که می‌سنجید | پرسش قابل بررسی | شاهد مفید |
|---|---|---|
| انجام کار اصلی | آیا کاربر مسیر توافق‌شده را تا پایان انجام داد؟ | نتیجه کار و مرحله‌ای که متوقف شد |
| نیاز به کمک | کجا راهنمایی لازم شد و آیا دوباره تکرار شد؟ | نوع راهنمایی و تجربه تلاش بعدی |
| فایده برای دریافت‌کننده | آیا پیام را فهمید و اقدام بعدی را شناخت؟ | توضیح کاربر با زبان خودش |
| بار کاری مدرسه | چه کار تازه یا ثبت دوباره‌ای ایجاد شد؟ | شرح کار اضافه و مسئول انجام آن |
برای مقایسه منصفانه، روال فعلی را هم ببینید. اگر پیش از این آماده‌کردن گزارش دشوار بوده، فقط شمار کلیک‌های ابزار تازه را نسنجید؛ مسیر کامل از آماده‌سازی تا دریافت را مقایسه کنید. ممکن است بخشی سریع‌تر و بخش دیگری طولانی‌تر شود. همچنین زمان یادگیری اولیه را از زمان انجام کار پس از آشنایی جدا کنید تا هم دشواری شروع و هم فایده احتمالی استفاده مستمر دیده شوند.
پشتیبانی و هزینه ادامه استفاده را وارد تصمیم کنید
راهنمای خرید فناوری مدارس وزارت آموزش انگلستان به هماهنگی ابزار با زیرساخت موجود و بررسی خدمات پس از خرید توجه می‌دهد. برای مدرسه شما هم پرسش عملی این است که پس از پایان جلسه معرفی، چه کسی در کنار کاربران می‌ماند. از ارائه‌دهنده بخواهید مسیر دریافت کمک، آموزش اولیه و حدود خدمات را روشن کند؛ وجود یک شماره تماس به‌تنهایی نشان نمی‌دهد مشکل کاربر چگونه پیگیری می‌شود.
هزینه تصمیم فقط مبلغ اشتراک نیست. آماده‌سازی اطلاعات، آموزش همکاران، زمان پاسخ‌گویی داخلی و امکاناتی که جداگانه تهیه می‌شوند هم باید در بررسی مدرسه دیده شوند. به‌جای حدس‌زدن صرفه‌جویی، این موارد را با شرایط واقعی پیشنهاد دریافتی بنویسید. اگر قرار است ابزار به سامانه دیگری متصل شود، همان اتصال و مسئول پشتیبانی آن را پیش از اتکا بررسی کنید.
درباره پایان همکاری نیز سؤال کنید: اطلاعات لازم را چگونه تحویل می‌گیرید و چه کاری برای ادامه فعالیت مدرسه باید انجام دهید؟ پاسخ را صرفاً به عبارت کلی «خروجی دارد» محدود نکنید؛ نمونه‌ای بخواهید که مسئول مربوط بتواند کاربردش را بررسی کند. این پرسش درباره امکان ادامه کار مدرسه است و به یک محصول خاص محدود نمی‌شود.
تصمیم نهایی می‌تواند ادامه، اصلاح یا توقف باشد
در پایان، از گروه بخواهید درباره همان سناریو و شاهدها گفت‌وگو کنند. اگر کار اصلی انجام شده اما چند ابهام آموزشی باقی مانده، شاید یک دور اصلاح و آزمایش دوباره کافی باشد. اگر نیاز ضروری در نسخه قابل استفاده پاسخ ندارد، افزایش تعداد کاربران راه‌حل آن نیست. توقف یک آزمایش نامناسب، وقتی دلیلش روشن است، می‌تواند تصمیم مسئولانه‌ای باشد.
اگر ادامه را انتخاب کردید، گسترش را مرحله‌ای انجام دهید. مسئول آموزش، زمان پیگیری پرسش‌ها و موعد بازبینی را مشخص کنید و به کاربران بگویید بر اساس بازخوردشان چه چیزی تغییر کرده است. انتخاب نرم‌افزار مدرسه زمانی به تصمیم بهتری تبدیل می‌شود که تجربه معلم و خانواده در آن دیده شود؛ ابزاری ارزشمند است که برای یک نیاز روشن، در شرایط واقعی مدرسه، قابل استفاده و قابل پشتیبانی باشد.
نظرها و تجربه‌ها
نظرها پس از بررسی منتشر می‌شوند. می‌توانید به هر گفت‌وگو پاسخ دهید.