Рекомендации по заполнению заявки на IT-проект

Уважаемые друзья,

план работы на ближайшее время: вы сдаёте заявку. Пока только заявку. За эту заявку к концу полугодия вы получаете зачёт (ну, или не получаете, но не будем об этом).


***
Для отправки заявки необходимо:

1) Создать аккаунт и репозиторий проекта на ГитХабе
2) Запушить в репозиторий вашу заявку в виде md-файла (сам файл можно взять в группе)
3) На сайте 2359.hse.ru указать ссылку на репозиторий на ГитХаб. Другие поля (кроме контактных данных) можно не заполнять .

ВНИМАНИЕ: вы создаёте один репозиторий на всё время работы над своим проектом. Смена репозитория не разрешается. Репозиторий должен быть именно на ГитХабе.  

***
Правила оформления заявки и необходимые разделы можно посмотреть здесь: https://github.com/aakuptsov/test_repo/blob/master/akuptsov_application.md

ВНИМАНИЕ: заявки, оформленные не по правилам (не соблюдены правила оформления, отсутствует или прописан недостаточно / формально хотя бы один раздел) оформляться не будут. Вы получите стандартный комментарий типа “Правила оформления заявки не соблюдены”, “Проблемное поле не описано” и т. п. Мне кажется, лучше потратить чуть больше времени и написать хорошую заявку, которая будет рассматриваться серьёзно.

 
***

Рекомендации по написанию заявки:

1) Начнём с банального: делайте то, что вам интересно. Делать год проект, который не нравится - это плохо. Хуже того, если это потом перерастёт в отвращение к программированию и вообще ко всему. Помните, что сейчас ещё всё можно поменять, даже если вы не ходили на НИПСы по той предметной области, которую вы вдруг захотели делать.

НАПОМИНАЮ, что мы не рекомендуем заявлять IT–проект в качестве вашей ИВР, если вы только начинаете изучать программирование. Вам может быть тяжело справиться с необходимым объёмом работы (у вас не только же ИВР, но и обычная учебная нагрузка), а для изучения программирования в своё удовольствие делать IT–проект в качестве ИВР совершенно необязательно.

2) Обязательно чётко пропишите проблему, которую решает ваш проект (в проблемном поле). Проблема - это когда то, что хочется или должно быть, отсутствует, когда присутствует то, чего не должно быть; когда то, что должно возрастать, - падает, то, что должно падать, наоборот, возрастает; то, что должно давать доступ, доступ не даёт, то, что должно быть круглым - не круглое и т. п. Выделите жирным / курсивом в вашем проблемном поле те слова, которые обозначают отсутствие / недостаток / невозможность и т. п. Если таких слов нет, значит, вы не описали проблемное поле (и заявка не может быть принята);

3) Опишите своего заказчика или целевую аудиторию . Заказчик или целевая аудитория - это те, у кого есть или могут быть те проблемы, которые вы описали в проблемном поле. Укажите их возраст, тип занятости / профессию, какой минимальный уровень навыков пользователя вы у них предполагаете и т. п. Если вы используете фразы типа "широкая целевая аудитория", дальше, пожалуйста, укажите группы пользователей, которые вы выделяете в этой "широкой аудитории". Посмотрите, как это сделано в образце заявки. Без указания групп пользователей это поле считается незаполненным. 

4) Обратите внимание на раздел "Похожие / аналогичные продукты". Помимо упоминания аналогичных продуктов, у вас должен быть анализ того, каких функций нет в этих продуктах или почему их трудно использовать. В этом суть этого раздела. Вы доказываете таким образом, что ваш будущий проект имеет право на жизнь и он лучше , чем имеющиеся аналоги.

5) Раздел “функциональные требования» - самый важный раздел. Продумайте его максимально. Это то, на основе чего вы будете писать пользовательские сценарии. В списке функциональных требований должно быть минимум 6-7 пунктов . Не надо писать общих вещей типа “моя игра позволит играть”, но и какие–то излишние детали типа “приложение будет давать возможность сменить пароль” тоже не стоит указывать. Думаю, интуиция вам подскажет, а если нет - потом подскажем мы. 

6) Выбирайте что-то одно: веб-версию, Android, iOS, десктоп, бот. Ни в коем случае не заявляйте два и больше варианта. В образце это сделано просто, чтобы показать, как всё прописывается. Там даже сделан соответствующий комментарий.

7) Не пишите в рисках общепроектные проблемы типа "нехватка времени" или "не смогу освоить технологию Икс". И так понятно, что это возможно и это возможно у всех. Попробуйте спрогнозировать риски, которые имеют отношение непосредственно к вашему проекту. Например, если вы делаете приложение для изучения японского языка, но сами не очень хорошо знаете японский и собираетесь его учить в процессе работы, очевидным риском является то, что вы не сможете / не успеете освоить три системы японского письма. Вроде, это то же самое, но это уже конкретика вашего проекта. Подумаете, какие "слабые места" могут возникнуть в процессе создания именно вашего продукта.

8) И ещё раз - над проектом надо работать в радость!

Удачи вам, уважаемые друзья! 

По любым вопросам, пожалуйста, пишите: 

www.vk.com/alekscooper

akuptsov.hse@gmail.com  

Александр Александрович Купцов, 

эксперт по IT–проектам в Лицее