نوآوری در آموزش

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

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

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

این همان فلسفه‌ای است که گزارش Experiment Types for EdTech منتشرشده توسط EdTech Hub بر آن بنا شده است. نویسندگان این گزارش معتقدند که آزمایش صرفاً ابزاری برای ارزیابی نیست؛ بلکه روشی برای یادگیری است. هر آزمایش، بخشی از ابهام را کنار می‌زند و به تیم‌ها نشان می‌دهد کدام فرضیات درست بوده‌اند، کدام مسیرها باید اصلاح شوند و کدام ایده‌ها بهتر است هرگز وارد مرحله توسعه نشوند. 

چرا بسیاری از پروژه‌های فناوری آموزشی شکست می‌خورند؟

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

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

از همین منظر، آزمایش سه مزیت اساسی دارد:

- هزینه و زمان یادگیری را کاهش می‌دهد.

- نتایجی قابل اندازه‌گیری و مبتنی بر شواهد تولید می‌کند.

- امکان اصلاح محصول را پیش از سرمایه‌گذاری گسترده فراهم می‌آورد.

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

یک آزمایش خوب چه ویژگی‌هایی دارد؟

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

یک آزمایش خوب، برعکس، دقیقاً مشخص می‌کند:

- قرار است چه چیزی آزموده شود؟

- چه تعداد کاربر در آزمایش شرکت می‌کنند؟

- موفقیت با چه شاخصی سنجیده می‌شود؟

- اگر نتیجه مطلوب نبود، چه تصمیمی گرفته خواهد شد؟

یک آزمایش مناسب ممکن است چنین باشد: «نسخه اولیه را در اختیار ۵۰ دانش‌آموز قرار می‌دهیم، نرخ استفاده آن‌ها را طی یک ماه اندازه می‌گیریم و سپس بررسی می‌کنیم چه تعداد از کاربران بدون یادآوری دوباره به سامانه بازمی‌گردند.» تفاوت این دو رویکرد ظریف اما بنیادین است. در اولی، تنها برداشت‌های ذهنی جمع‌آوری می‌شود؛ اما در دومی، رفتار واقعی کاربران مشاهده و اندازه‌گیری می‌شود.

گزارش همچنین بر یک اصل مهم دیگر تأکید می‌کند. آزمایش باید تا حد امکان ساده و کم‌هزینه باشد. اگر هنوز نمی‌دانیم یک ویژگی برای کاربران ارزشمند است یا نه، ضرورتی ندارد نسخه کامل آن ساخته شود. کافی است حداقل امکانات لازم برای آزمودن همان فرضیه فراهم شود. به بیان دیگر، هدف آزمایش، ساختن محصول نیست؛ یاد گرفتن است.

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

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

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

آزمایش اول؛ شطرنج‌باز خودکار (The Automaton Chess Player)

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

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

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

گزارش برای توضیح این روش به تجربه مشهور شرکت IBM اشاره می‌کند. این شرکت در دهه ۱۹۸۰ تصمیم داشت سامانه‌ای پیشرفته برای تبدیل گفتار به متن توسعه دهد. اما پیش از آغاز توسعه، آزمایشی ساده طراحی کرد. کاربران تصور می‌کردند دستگاه گفتار آن‌ها را به متن تبدیل می‌کند، در حالی که در پشت صحنه فردی سخنان آن‌ها را به سرعت تایپ می‌کرد.

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

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

آزمایش دوم؛ پینوکیو (The Pinocchio)

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

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

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

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

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

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

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

آزمایش سوم؛ محصول حداقلی قابل ارائه (Minimum Viable Product)

بسیاری از تیم‌ها تصور می‌کنند نسخه اولیه محصول باید تقریباً کامل باشد؛ تنها با چند قابلیت کمتر. اما مفهوم Minimum Viable Product (MVP) دقیقاً خلاف این نگاه است. در این رویکرد، محصول تنها باید آن‌قدر کامل باشد که بتوان مهم‌ترین فرضیه پروژه را آزمایش کرد؛ نه بیشتر. به عبارت دیگر، MVP نسخه ناقص یک محصول نیست؛ بلکه نسخه‌ای است که همه اجزای غیرضروری از آن حذف شده‌اند و تنها هسته اصلی ارزش پیشنهادی را در خود حفظ کرده است. اگر همین هسته برای کاربران مفید نباشد، افزودن امکانات بیشتر نیز مشکل را حل نخواهد کرد.

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

گزارش، تجربه سازمان Worldreader را به عنوان نمونه‌ای از این رویکرد معرفی می‌کند. این سازمان در سال ۲۰۱۰ تصمیم گرفت کتاب‌های دیجیتال را از طریق تلفن‌های همراه ساده در اختیار کودکان محروم آفریقا قرار دهد. نخستین نسخه محصول، تقریباً هیچ‌یک از امکانات رایج کتاب‌خوان‌های دیجیتال را نداشت؛ نه تصویر جلد کتاب، نه سیستم امتیازدهی، نه توضیحات کتاب، نه بخش نظرات و نه حتی امکان نشانه‌گذاری صفحات. تنها چیزی که کاربران دریافت کردند، فهرست کتاب‌ها و یک ابزار ساده برای خواندن متن بود.

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

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

آزمایش چهارم؛ استانی یا محدود (The Provincial)

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

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

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

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

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

آزمایش پنجم؛ درِ جعلی (The Fake Door)

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

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

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

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

آزمایش ششم؛ زمان، پول یا اعتبار (Time, Money or Reputation)

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

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

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

آزمایش هفتم؛ وانمود کن مالک آن هستی (Pretend-To-Own)

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

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

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

آزمایش هشتم؛ مدل هزینه ناب (Lean Cost Model)

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

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

آزمایش نهم؛ برچسب جدید (Re-Label)

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

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

آزمایش دهم؛ کارآزمایی تصادفی کوچک (Mini-RCT)

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

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

آزمایش یازدهم؛ آزمون چندمتغیره (Multivariate Test)

اگر Mini-RCT تنها یک متغیر را بررسی می‌کند، Multivariate Test امکان مقایسه هم‌زمان چند راهکار را فراهم می‌آورد. در این روش، نمونه کاربران به چند گروه تقسیم می‌شود و هر گروه نسخه متفاوتی از مداخله را دریافت می‌کند. سپس با کنترل سایر عوامل، نتایج همه گروه‌ها با یکدیگر مقایسه می‌شود تا مشخص شود کدام ترکیب بیشترین اثربخشی را دارد.

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

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

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