Проект в конкурсе портфолио: типичные ошибки

Проект “Приложение (сервис) моей мечты” является ключевой частью портфолио на программе “UX-аналитика и проектирование информационных систем”, он приносит до 30 баллов. На обобщенном опыте работ прошлых лет разбираем основные ошибки, почему они важны и на что обратить внимание, чтобы их избежать.

Создано с помощью GigaChat

В проекте описывается концепция приложения (или сервиса), которое решает важную с вашей точки зрения задачу. Проект должен быть ориентирован на конечных пользователей, а не решать внутренние задачи b2b (business-to-business) проектов. Допускается – и даже рекомендуется – применение схем в выбранной абитуриентом нотации и эскизов. При этом проекты, состоящие только из схем, не оцениваются, наличие текста с описанием проекта обязательно. Описание проекта должно быть объемом 8000-12000 знаков.

Состав, структура и методика оценивания набора конкурсных документов

Критерии оценивания проекта:

1. Описание проблемы, решаемой сервисом/приложением, заинтересованных лиц/целевых групп
2. Критический анализ существующих решений, обоснование необходимости нового решения и его сравнение с аналогами
3. Техническое описание предлагаемого решения
4. Критический анализ сильных и слабых сторон предлагаемого сервиса/приложения, анализ степени решения проблемы

Обобщая, первые два критерия отражают "пользовательскую" часть проекта – насколько вы продумали, кому и зачем подобное приложение нужно, какие задачи позволяет решить. Последние два критерия отвечают за его реализуемость – подумали ли вы, как идея может быть воплощена в реальность, с какими сложностями придется столкнуться.

Другими словами, проект – это описание некоторого приложения (или сервиса), решающего интересную вам задачу, причем не существует приложения, которое ее уже решает в полной мере. Тематика и критерии оценивания проекта специально сформулированы таким образом, что позволяют проявить себя заинтересованным абитуриентам с различным бэкграундом ― кто-то может больше внимания уделить технической части, кто-то ― исследованию целевой аудитории. Главное ― описание проекта должно соответствовать всем критериям, указанным в портфолио, т.е. отсутствие, например, анализа существующих решений, приведет к снижению баллов даже при максимально проработанной технической части, как и в обратную сторону, хорошо проработанное описание проблемы без попыток ее решения (хотя бы концептуального, на уровне структуры, идеи или прототипа) не принесет высоких баллов.

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

Ниже перечислены основные ошибки, которые встречаются в описаниях проектов при поступлении. Для удобства описание структурировано следующим образом: сначала идет обобщенное описание ошибки и пояснение, почему на это нужно обратить внимание, а затем приведен пример рассуждения с такой ошибкой. Важный комментарий: все ошибки специально разобраны на примере несуществующего приложения, чтобы избежать пересечений с реальными проектами и предотвратить простое повторение этого примера в портфолио.

Ошибка №1. Ничего подобного не существует

Очень часто абитуриенты считают свои идеи абсолютно новыми и уникальными. Да, формально вы можете рассматривать такой набор ограничений, что приложения, полностью соответствующего им всем, нет (например, "на русском языке, бесплатное, с функциями ведения личного дневника, расшифровки аудиосообщений, возможностью видеоконференций, для Android").

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

В контексте проекта для портфолио указанные выше причины подводят к необходимости обосновать, почему отличие именно по этому параметру так важно. Например, может существовать удобное и популярное решение, но без дневника (или на другом языке, или для другой платформы, или для смежной сферы) – вам нужно показать, почему дневник так важен для вашей задачи.
Еще одна важная часть анализа существующих решений – это рассмотрение того, как задача решается сейчас, без предлагаемого вами сервиса. Это может быть решение совсем без приложения (например, ведение дневника в тетради) – и это тоже нужно знать, возможно, у такого способа есть элементы, которые пользователям удобны и привычны и их нужно постараться перенести в цифровой продукт.  

Другими словами, в проекте нужно ответить на вопрос, можно ли решить поставленную задачу сейчас, без вашего сервиса, почему ваш сервис сделает этот процесс лучше.

Пример

Исходное предложение. Хотим создать социальную сеть для общения лесных ежиков, ведь такого приложения не существует, а ежикам нужно делиться новостями

Исправление. Шаг 1. Анализируем, как задача решается сейчас. Выяснили, что сейчас новости передаются от ежика к ежику напрямую, при встрече. Массовое распространение новостей возможно только в местах общего сбора. Для важных новостей есть система условных знаков. Что переносим в свое решение: 1) сохранение возможности общаться напрямую; 2) оцифровываем систему условных знаков; 3) добавляем необходимость массовой рассылки.

Шаг 2. Ищем схожие решения. Нашли социальную сеть для белок, она частично решает задачу, но не хватает возможности передать запахи. Из этого решения забираем принципы работы со звуком, а еще нашли важную функцию “поделиться интересными лесными маршрутами”, важную для лесных ежиков.

Шаг 3. Продолжаем искать схожие решения. Нашли социальную сеть для городских ежиков. Очень похоже на то, что нужно, базовые действия совпадают, многое забираем, но есть лишние функции, а вот критичной для леса функции создания и просмотра маршрутов нет.

Продолжая этот процесс, формируем список необходимых функции, удачных решений, на которые можно ориентироваться.

Ошибка №2. Есть разные приложения, решающие задачу, давайте объединим их функциональность, это и будет наше новое приложение

Довольно часто в проектах абитуриентов прослеживается обоснование, что чем больше функций в приложении, тем оно лучше. Но во многих задачах это совсем не так. Во-первых, чем больше функций, тем сложнее ориентироваться в приложении. Допустим, вы работаете с приложением для составления списка дел, чаще всего вам нужно быстро добавить новый элемент, когда возникает задача, и легко отметить выполненные. Но авторы приложения позиционируют его и как инструмент для ведения дневника и отслеживания продуктивности – и теперь при вводе задачи вам нужно обязательно отметить ожидаемую длительность задачи, а при завершении – отметить свое настроение и дать обратную связь по задаче. Да, у вас появляется возможность анализировать свое настроение, оценивать выполнение задач и улучшать планирование, но основную задачу теперь решать дольше и сложнее, использование приложения требует более длительного обучения. 

Во-вторых, в реальных проектах такие дополнительные функции могут потребовать еще и более долгой и сложной разработки, чем основные. Они могут требовать больше ресурсов во время выполнения, например, если на данных о настроении и обратной связи основана рекомендательная система с персональными советами по планированию. Иногда, функции могут даже конфликтовать друг с другом. Во многих случаях объединение большого числа функций оправдано только для сервисов с большим числом пользователей, где даже редкие сценарии встречаются у десятков тысяч пользователей.

В контексте проекта для портфолио такой вариант объединения функций требует обязательного обоснования, что потенциальным пользователям действительно нужны все эти функции в одном приложении, что наиболее частые сценарии использования включают разные комбинации функций, что переключение между приложениями для решения рассматриваемой задачи действительно ухудшает пользовательский опыт. Это не значит, что такие идеи не нужно предлагать, но они требуют очень аккуратного обоснования как с “пользовательской” стороны, так и при анализе реализуемости.

Пример

Исходное предложение. Хотим создать социальную сеть для общения лесных ежиков. Мы проанализировали различные существующие решения и отобрали интересные и уникальные функции. В приложении будет личный блог, возможность отправки текстовых, аудио- и видео- сообщений, возможность отправить сообщение, передающее запах, возможность поделиться интересным маршрутом и поделиться им. При этом довольно часто пользователи для записи маршрута используют браслеты, можно добавить блок с анализом других данных с браслетов и рекомендациям по ним. И так как пользователи все равно ведут личный блог, то можно добавить функцию ведения закрытого личного дневника, где пользователи могут в том числе, отмечать свое настроение.  

Исправление. Так как первоначальная идея – это социальная сеть, то нужно сосредоточиться именно на ней, включив базовые функции социальной сети и то, что отличает ее от существующей. Например, можно не реализовывать (особенно на первых этапах) видеосообщения, т.к. для ежиков положение тела менее важно для общения. И лучше не смешивать личные (дневник и анализ личных данных) и публичные (блог, общие маршруты, общие новости) функции – это усложнит первоначальное знакомство, а еще может привести к серьезным проблемам пользовательского опыта, например, если из-за сложности настроек пользователь случайно сделает личный дневник доступным подписчикам.

Ошибка №3. Сделаем существующий сервис бесплатным

Еще один частый случай в проектах абитуриентов – это предложение решать задачу, для которой уже есть полностью подходящее решение, но оно платное. Единственное, что отличает идею проекта от этого уже существующего решения – предложение сделать ту же функциональность бесплатной. 

К сожалению, в реальных проектах такой подход часто невозможен. Нужно иметь в виду, что разработка и сопровождение сервиса, ресурсы, необходимые для его функционирования, требуют затрат. Например, образовательный сервис может подразумевать постоянное обновление контента, а для его создания нужны люди и инструменты, довольно часто платные. Или приложение использует облачные сервисы для хранения данных, что тоже требует оплаты, особенно при большом количестве пользователей.  

Хотелось бы отметить, что любое приложение требует определенных ресурсов, но это не значит, что все из них автоматически должны быть платными для конечных пользователей. Просто эти ресурсы в реальных проектах поступают из других источников – грантов для социальных проектов, личных средств создателя, доходов компании от другой деятельности, рекламы и т.д. Довольно часто базовая функциональность предоставляется бесплатно, а за продвинутые и / или ресурсоемкие функции необходимо платить.

Если ваша основная идея – сделать сервис бесплатным, то в проекте для портфолио нужно очень аккуратно описывать, за счет чего это возможно. От вас не требуется подробный бизнес-план, но хотя бы предположения, за счет чего подобный подход можно реализовать.

Пример

Исходное предложение. В социальную сеть для общения лесных ежиков хотим добавить функцию перевода аудиосообщений в текст. Мы видели такую функцию в другом приложении, она пользуется популярностью, но то приложение является платным. Мы же хотим сделать ее бесплатной.

Исправление. После анализа идеи мы выяснили, что собственных вычислительных ресурсов нам не хватит, да и в команде нет того, кто сумеет развернуть нужнцую модель, поэтому мы решили воспользоваться одним из облачных сервисов. Каждый запрос пользователя будет стоить нам 2 единицы, ожидаем, что пользователи будут в среднем транскрибировать сообщения раз в два дня. При текущем числе пользователей мы не можем себе это позволить. Поэтому саму функцию мы решили все же добавить, но в формате расширенной подписки.

Ошибка №4. Для того, чтобы идея работала, будем использовать искусственный интеллект

Последние два года в проектах абитуриентов все чаще можно увидеть рассуждение следующей структуры: эта задача пока не решается в приложениях, поэтому создадим новое приложение, где задача будет решена с помощью ИИ. И да, многие задачи действительно отлично решаются различными методами ИИ. Но у широкого распространения ИИ в последнее время, особенно после активного внедрения LLM в различные решения, есть обратная сторона – представление о том, что ИИ может все. Это совсем не так, у методов есть границы применимости.

Во-первых, не все задачи хорошо решаются существующими инструментами (исторически достоверную визуализацию какого-то объекта одним запросом получить не удастся, например). В реальных проектах это может приводить к тому, что после нескольких попыток решить задачу приходят к решению с частичной автоматизацией, где ИИ выполняет только отдельные части задачи, упрощая финальное решение для человека, но не автоматизируя полностью процесс.

Во-вторых, даже если задача решается, например, современными LLM, то довольно часто ее внедрение требует значительных ресурсов – вычислительных и / или финансовых, как при использовании готовых решений через API, так и при развертывании собственных решений (на обычных персональных компьютерах многие модели просто не смогут работать). Такой подход требует, как минимум, предварительных идей, за счет чего это можно воплотить (см. примеры в ошибке №3).

Что делать. Не нужно сразу отказываться от использования ИИ, но в вашем проекте его применение должно быть описано подробнее, чем фраза "для решения используем ИИ". Это могут быть конкретные подходы, алгоритмы, архитектуры, но не обязательно. Например, можно привести примеры сервисов, где реализуется что-то похожее, или публикаций, в которых описывались схожие подходы, т.е. покажите, что то, что вы предлагаете, возможно. Описание ограничений подхода будет хорошим дополнением.

Пример

Исходное предложение. В социальную сеть для общения лесных ежиков хотим добавить генерацию персонализированных интересных маршрутов. Реализовывать будем с помощью ИИ.

Исправление. Сначала покажем, что такое возможно – мы нашли похожий сервис, который строит маршруты для ежиков в городах, отлично. Но при этом мы понимаем, что в городах плотность маршрутов больше, больше известных данных о местах, места расположены ближе друг к другу, что упрощает подбор интересующих точек и составление маршрутов. В случае лесных маршрутов функцию, скорее всего, не получится сразу реализовать в полной мере из-за того, что у нас пока мало данных, а уже имеющиеся маршруты мало пересекаются. Мы все равно будем развивать генерацию маршрутов, но постепенно, а сначала продумаем несколько готовых рекомендаций на основе хорошо известных точек интереса. 

Ошибка №5. Предложенная идея не имеет слабых сторон

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

В частности, у любого приложения, основанного на взаимодействии пользователей, есть важное ограничение – очень сильная зависимость от пользовательской базы. Приложение может быть идеальным с точки зрения функций, хорошо технически проработанным, красивым и удобным визуально, но если в нем нет нужных пользователю других пользователей, работать полноценно оно не будет. Для тех, кто использует соц.сеть для публичного общения, для продвижения себя, нужна широкая база нужного сообщества, для личного общения нужно присутствие определенных людей (вспомните, например, как вам приходилось пользоваться мессенджером с неудобным интерфейсом из-за того, что только в нем зарегистрирована ваша бабушка или именно в нем есть соседская группа).

В реальных проектах именно такие ограничения часто становятся критичными – и хорошо проработанный проект закрывается через короткое время. А их проработка может привести к более успешной версии проекта.

Что делать. Честно продумать, что может не сработать, где могут возникнуть сложности реализации идеи, причем не только внутри команды, но и во внешнем мире. Проект в рамках портфолио – это не попытка "продать" свою идею, а результат анализа выбранной вами задачи.

Пример

Исходное предложение. Мы учли все предыдущие замечания и создаем социальную сеть для общения лесных ежиков. Идея реализуема, отличается от существующих решений, включает уникальные возможности. Из ограничений можно отметить только потребность в ресурсах, но монетизацию мы тоже продумали.

Исправление. Мы понимаем, что важным ограничением для социальной сети является привлечение пользователей. Поэтому мы планируем активно рассказывать о новом приложении в местах сбора ежиков и показывать преимущества ее использования.

Ошибка №6. Техническое описание как перечисление технологий

Довольно часто техническое описание предложенного решения (критерий №3) представлено просто списком используемых технологий и общими словами (“будет использована клиент-серверная архитектура”). С учетом того, что такой список легко получить запросом к любому ИИ-инструменту, он никак не иллюстрирует мысли автора о реализуемости идеи. 

Что делать. Эта часть проекта должна содержать описание того, как вы видите конечный результат, за счет чего решение будет работать, как взаимосвязаны компоненты между собой. Рекомендуется использовать схемы, показывающие логику взаимодействия элементов, иллюстрации, таблицы, скетчи интерфейсов, показывающие, например, различия для разных ролей пользователей и т.д. Другими словами, используйте различные инструменты для обобщения и структурирования идеи. Использование конкретной нотации (UML, например) не требуется, можно делать так, как вам удобно, главное – покажите логику и взаимосвязи