Программа может быть небольшой и при этом полезной: помогать выбрать настольную игру, находить нужный предмет в домашней коллекции или проводить викторину. Для первого такого проекта не обязательно придумывать совершенно новый сервис.
Лучше найти конкретную задачу знакомого человека и понять, что в её решении неудобно сейчас. Тогда у ребёнка появится возможность проверить свою идею в реальном использовании.
Найти небольшую повторяющуюся задачу
Допустим, семья регулярно выбирает настольную игру. Нужно учесть число участников и время, но каждый раз приходится перебирать коробки. Это можно обсудить как задачу для простого каталога.
Перед разработкой полезно понаблюдать за выбором. Какие сведения люди действительно ищут? Важна ли длительность партии? Учитывают ли возраст участников? Нужны ли правила прямо в приложении?
Так ребёнок отделяет собственные предположения от потребностей будущего пользователя. Возможно, нужен всего один удобный фильтр, а задуманный рейтинг окажется лишним.
Проверить идею до написания кода
Первую версию можно изобразить на бумаге: поля с числом участников и доступным временем, кнопка подбора и список результатов.
Покажите схему тому, для кого создаётся программа. Попросите объяснить, что он ожидает получить после нажатия кнопки. Если ожидания расходятся с замыслом автора, проще изменить бумажный вариант, чем готовый интерфейс.
Иногда выясняется, что задачу уже удобно решает таблица. Это тоже полезный результат обсуждения. Ребёнок может выбрать другую задачу или создать программу как учебный эксперимент, не приписывая ей несуществующую необходимость.
Ограничить первую версию
Для каталога настольных игр на старте достаточно небольшого набора записей и подбора по двум условиям. Регистрация, отзывы, сложные рекомендации и синхронизация между устройствами могут подождать.
Важно предусмотреть простые, но реальные ситуации. Что показать, если ни одна игра не подходит? Как объяснить, что число участников введено неправильно? Как пользователь вернётся к изменению условий?
Такие детали влияют на удобство сильнее, чем количество дополнительных экранов. Первая версия должна позволять пройти основной сценарий целиком.
Наблюдать за использованием
Когда программа готова, предложите человеку решить с её помощью конкретную задачу. Автору стоит на время отойти от роли помощника: не объяснять каждую кнопку и не нажимать вместо пользователя.
Обратите внимание, где человек останавливается, что вводит и понимает ли полученный результат. После проверки задайте несколько вопросов: что оказалось удобным, что запутало, чего не хватило именно для этой задачи.
Одна общая оценка «всё понравилось» даёт мало материала для улучшения. Конкретное наблюдение «не заметил, что список можно прокрутить» гораздо полезнее.
Выбрать одно улучшение
После первого теста не обязательно переписывать всё приложение. Можно увеличить заметность кнопки, уточнить подпись или добавить сообщение об отсутствии результатов. Затем стоит снова проверить тот же сценарий.
Для первых проб достаточно локального проекта и небольшого круга знакомых пользователей. Публичный запуск, сбор сведений о людях и работа с важными данными требуют отдельного обсуждения со взрослым и преподавателем.
В НАИТ представлены программирование, веб-разработка и компьютерный дизайн. Задача полезного приложения позволяет увидеть, как эти направления соединяются: код обрабатывает данные, интерфейс помогает ими пользоваться, а проверка показывает, что нужно изменить.
Вывод
Полезность проекта определяется тем, помогает ли он конкретному человеку выполнить нужное действие. Небольшая программа с понятным назначением даёт школьнику возможность пройти путь от наблюдения и идеи до проверки результата.
Новосибирская Академия Информационных Технологий предлагает детям изучать технологии и применять их при создании собственных цифровых проектов.
