Главная
Проектний практикум: ЧТО ТАКОЕ ПРОЕКТНЫЙ ПРАКТИКУМ НА ПРОГРАММНОЙ ИНЖЕНЕРИИ — I-NURE

Проектний практикум: ЧТО ТАКОЕ ПРОЕКТНЫЙ ПРАКТИКУМ НА ПРОГРАММНОЙ ИНЖЕНЕРИИ — I-NURE

Содержание

ЧТО ТАКОЕ ПРОЕКТНЫЙ ПРАКТИКУМ НА ПРОГРАММНОЙ ИНЖЕНЕРИИ — I-NURE

Пошук…

Деталі
Категорія: Універ

На втором курсе программной инженерии есть предмет с интригующим названием. Что за практикум, и что на нем будет нужно делать? В этой статье «изнутри» посмотрим на один из увлекательнейших предметов кафедры программной инженерии в ХНУРЭ.

 

Если с такими предметами, как физика, высшая математика и объектно-ориентированное программирование вопросов не возникает, то словосочетание «проектный практикум» звучит не совсем понятно и достаточно интересно.

 

 

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

Цель этого предмета – дать студентам как можно более глубокое понимание разработки настоящего проекта.

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

Далее начинается очень длинный этап – проектирование. Именно тут как никогда вспоминаются диаграммы use-case, отношения в uml, er-диаграммы, проектирование пользовательского интерфейса.

 

 

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

д.).

Так как курс практический, то важной частью является готовый финальный продукт. Самое интересное, чтобы создать его, скорее всего не хватит всего того багажа программистских знаний, приобретенных за полтора года в университете. Техно-мир постоянно развивается, а значит и для своего проекта надо использовать что-то интересное и свежее. Тут, конечно, на помощь приходит команда, ведь вместе разбираться с чем-то новым намного продуктивнее.

Основными требованиями к финальному продукту являются его практичность, соответствие первоначально описанным требованиям, использование актуальных технологий. Он, желательно, должен иметь несколько вариантов реализации (например, web и mobile), а также обязан использовать API, например, для регистрации, карты, календаря, оплаты. В каком-то смысле проектный практикум похож на курсовую работу, которую можно выполнять в команде.

 

 

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

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

 

 

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

 

 

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

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

 

Cтефни Огу

  • Попередня
  • Наступна

Популярні статті

Читати далі

Підписатися на RSS


INSTAGRAM

 

Telegram

 

FB

 

NURE

 

Проектный практикум в вузе. Лучше писать курсач? / Хабр

Предисловие

Всем привет, меня зовут Егор. Совсем недавно я окончил второй курс радиофака УрФУ по специальности «программная инженерия» и сейчас прохожу стажировку в качестве системного аналитика. Одной из особенностей обучения в моем институте является проектный практикум, о котором я и хочу высказать свои мысли в этом тексте.

Спасибо Даниил

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

Структура обучения

Сначала вкратце о самом процессе обучения.

Все предметы делятся на обязательные и по выбору. Обязательные предметы – джентльменский набор инженера-айтишника: матанализ, дискретка, компьютерные сети и т.д., конечно же не забуду упомянуть БЖД (или ОБЖ, кому как привычнее). У этих курсов мы можем выбирать преподавателей, сложность и расписание (можно посмотреть расписание пар у групп и выбрать наиболее подходящую группу). С курсами по выбору немного интереснее.

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

Как все интересно! Раньше такого не было…

Да, действительно, такая модель обучения для России это что-то новое. По крайней мере, среди всех моих знакомых, широко размазанных по вузам страны, ничего подобного нет. И по-моему, это грустно. Такая модель дает удивительную гибкость при обучении. Попробовал фронт? Не понравилось? Ничего страшного, на следующий семестр выберешь DevOps. Учился C++, но ты модный и прогрессивный и хочешь попробовать машинное обучение? Да пожалуйста. И это круто.

Проблемы такого подхода на радике

К сожалению, и на солнце есть пятна. Но пятна «гибкого» обучения разрешимы.

Первое: непонятный первый курс. У нас были общие дисциплины, было программирование на шарпе. Также был очень интересный предмет «профориентация» (точного названия не помню, но суть понятна): приходили специалисты из разных фирм рассказывать о своих профессиях. И это было ужасно. Нет, дело не в специалистах. Просто, очень тяжело объяснить, чем отличается бэк от фронта людям, которые до этого учились только ЕГЭ сдавать. Конечно, были и шарящие ребята, но их мало и в чем интерес слушать такие базовые вещи? И все скатилось в балаган, когда приходил очередной оратор, а его никто не слушал. Грустно. 

Вторая причина заключается в отсутствии курсов по аналитике и управлению команды. Подробнее рассмотрим далее, в контексте.

Проектный практикум на бумаге

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

Проблемы

1. Сайт. Проекты самые разнообразные от «накидать тем для онлайн курса» до «разработать нейронку по распознанию чего-либо». Но большинство, в какой-то степени, да относятся к бизнесу или разработке продуктов, нацеленных на масмаркет. И как в таком разнообразии выбрать подходящий тебе проект? Как удачно, что у нас есть сайт, который призван помочь с этим! Выглядит это так: для каждого проекта заказчик указывать компетенции, которые необходимы для работы над этим проектом. Сам. Ручками по клавиатуре. Думаю вы уже поняли, в чем беда. Да, по итогу сайт хранит кучу мусора: «фигма», «дизайн в фигма», «ui/ux figma», «Figmf», «Figma» и так далее, я думаю вы поняли, это может продолжаться бесконечно. Проблема в том, что потом студенты должны из общего пула компетенций выбрать подходящие им и сервис покажет наиболее уместные проекты. Что получается в итоге прекрасно демонстрирует картинка ниже.

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

2. Роли. На мой взгляд, сейчас существуют разногласия между проектным практикумом и обучением в целом. У нас на выбор есть много курсов по коду, но совсем нет курсов по аналитике и руководству технической команды. Конечно, можно начать рассуждения в стиле «технический вуз, неудивительно, что не учат менеджеров», окей, а системный аналитик? Это не айтишник? А продакты, которые ведут ваши проекты, тоже не айтишники? Они не должны разбираться в теме? Я считаю, что IT, как и любая другая сфера, требует от менеджеров достаточно глубокого понимания внутренних процессов и это достигается либо огромным опытом работы в сфере, либо профильным образованием. Но вернемся к проектному практикуму. Многие проекты подразумевают не только написание кода, а анализ проблемы, поиск путей ее решения, общение с заинтересованными сторонами и т.д. Кураторы у каждой команды разные: у кого-то куратор полностью организует работу и тогда тимлид не нужен, а кому-то с куратором не повезло и он вообще никак не реагирует на сообщения. Получается, что задачи решаем бизнесовые, а бизнес составляющей в команде нет.

Безусловно, если человеку понравилось быть аналитиком или дизайнером он сам будет развиваться в этом направлении, но кто-то боится себя попробовать в новой роли, держа в голове мысль, что от него зависят другие люди, кто-то не попадает в проекты, где нужны такого рода кадры и так далее, причин может быть много.

Решение? Профориентация, дополнительные лекции в рамках проектного практикума, обучающие курсы.

3. Мотивация. Зачем студенту тратить кучу времени на проект? Что он получит? Многие ребята относятся к этому как к очередной строке в зачетке и самое важное – это оценка (если им и это неважно, то движений по проекту вообще не производится). Далеко не все студенты имеют искреннее желание научиться чему-то новому, развить скилы, создать новый продукт, придумать новое решение. Еще реже попадаются те, у кого присутствует все сразу, а именно таким ребятам и нужен проектный практикум.

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

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

Вторая идея решения проблемы заключается в том, чтобы ввести рейтинг студентов по проектам. Самое активные и скиловые ребята будут в топе и им будет легче находить друг друга и объединяться в команды. Сейчас очень трудно найти команду, в которой 100% состава скиловые и заинтересованные. Обычно в команде 1-2 вовлеченных участника, которые тащут всех за собой.

4. Заказчики. Довольно часто бывает так, что заказчик кидает ТЗ проекта (часто и тз сделано из под палки) и забивает. Лично мне на последнем проекте мой заказчик говорил «если бы ты не написал, я бы даже не вспомнил, что проект закидывал». Но нам повезло, мы смогли найти общий язык и куратор не пропал посередине проекта (это случилось ближе к концу). На предыдущем проекте заказчик отвалился уже через 1,5 месяца. Мы вот ему отправляем модель БД на одобрение 12 ноября, а 6 декабря он отвечает «норм». Конечно, я понимаю, работа, семья, под дулом пистолета заставили, но люди берут обязательства и не выполняют их. У кого-то кураторы реально помогают, у кого-то теряются еще в начале, а кому-то и вовсе мешают делать проект (да-да и такое бывает). А оценивают проекты одинаково. Никого не интересует какой наставник у тебя был и это, на мой взгляд, неправильно.

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

5. Оценка проектов. За 5 минут расскажите двум людям без лица, что у вас за проект. Звучит очень грубо, но весьма точно отражает суть. Вообще, очень много возмущения по поводу оценки проектов как от студентов, так и от специалистов в комиссии.

Обговорим сразу, да, мне важна оценка за мой труд. Нет, мне не важна цифра, мне важно, чтобы мои усилия оценили по достоинству. Если моя команда работала на отлично я ожидаю и соответствующую оценку.

Формат проведения защиты. Так как сейчас вездесущая удаленка, то и защита проходила у меня 3/4 раз удаленно. Проекты делятся на несколько треков. В последний раз это были: gamedev, Art-design, Application, ML, mobile, web. У каждого трека указаны эксперты (от 1 до 3) и очередь команд. В указанное время команда заходит и у докладчика есть 5 минут чтобы защитить свой проект. Затем вопросы от экспертов и конец. Что должен рассказать докладчик за 5 минут: выделить проблему, обозначить цели, задачи, показать анализ конкурентов, аудитории, рассказать о своем решение, продемонстрировать, что получилось. Если что-то отсутсвует, то обязательно спросят почему. Если заказчик захотел сам сделать велосипед, это его право, но ребят на защите завалят вопросами «зачем вы придумали велосипед?».

Я думаю и так понятно, что за 5 минут уловить суть проекта и оценить проделанную работу невозможно. Поэтому перейдем к другой проблеме защиты – оценивание. Критерии максимально размытые и это не только мое мнение, так говорят и проверяющие эксперты (сами критерии прикрепил ниже). Далее приведу пару цитат от экспертов. Мы попросили их рассказать об их участии в проектном практикуме. Я отметил основные моменты.

Я не был куратором, меня просто позвали послушать проекты. …

…У ребят разный уровень проработанности и не понятно как на такое реагировать, вроде что-то делали, а вроде у других в 2-3 раза больше результата (но тут и от размера команды зависит). …

…Система оценивания в корне не правильная и почти бесполезная. Из тех критериев что там были, это скорее относится к презентации проекта, а не к нему самому. …

…Мне кажется времени мало дается на презентацию. Они все либо торопились рассказывать, либо делали мини презентации, где ничего не раскрыто.
(С) Эксперт – мобильный разработчик


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

Заключение

Отвечая на вопрос в названии статьи – нет, не лучше. Лично для меня. Проектный практикум и гибкое обучение это правда крутые идеи, я бы сказал прорывные, как минимум для заМКАДья. Я лишь передал мысли и взгляд конечного потребителя – студента.

P.S. Так как автор ранее не писал статьи для хабра, случайно отправил на модерацию недописанную версию статьи. Теперь все должно быть ок.

Что такое проектный семинар и в чем его преимущества?

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

Как провести семинар по открытию продукта? Как это может помочь нам обратить внимание на основную стратегию всего процесса разработки продукта? Есть ли шаблон для него? Посмотрим.

Краткое определение семинара по знакомству с продуктом

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

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

Как спланировать семинар по проекту

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

Также, поскольку нет ни одного окончательного семинара, ни определенного количества семинаров — все зависит от масштаба проекта и прогнозируемых проблем или возможностей.

Узнайте больше о корпоративной культуре и о том, как она влияет на работу команды.

Семинары по изучению продукта – преимущества

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

Определено

Объем работ

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

Лучшее понимание потребностей как клиента, так и конечного пользователя 

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

Соответствуют ли эти предположения потребностям пользователей? Каковы признаки востребованности продукта на рынке? Чего хочет целевая аудитория? Благодаря определению персонажей пользователей, написанию пользовательских историй, составлению карт пути пользователя и другим творческим методам, у нас есть свежий взгляд на этот вопрос и мы можем установить ключевые точки клиентов. Следовательно, мы можем адаптировать цифровой продукт к его целевой аудитории.

Короче говоря, мы проверяем эти важные аспекты, чтобы мы могли превратить видение продукта в реальный продукт.

Узнайте больше о процессе проверки рынка из статьи Как проверить идею цифрового продукта?

Комплексный анализ

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

Экономичность

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

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

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

Узнайте о других способах сократить расходы на разработку программного обеспечения, сохранив при этом качество продукта.

Вся информация разобрана

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

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

Выявление упущенных возможностей, сильных и слабых сторон

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

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

Суть проекта

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

Дополнительная ценность -> знакомство с людьми, с которыми вы сотрудничаете

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

Проектный семинар на протяжении всего процесса разработки продукта

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

Что такое бриф? Это интерактивный документ, содержащий все необходимые вопросы о схеме, потребностях вашего бизнеса, целях и ожиданиях.

Этап подготовки

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

Что вы получаете от процесса? Во время семинара наша команда готовит макеты, пользовательские истории, дорожную карту и смету. Далее идет творческая мастерская для создания финального потока.

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

Что включено в каталог продукции?
  • История проекта – это один из важнейших результатов семинара. Он основан на четырех жизненно важных вопросах, на которые мы должны ответить:
    – Какой мы строим?
    – Почему мы это делаем?
    – Кто  целевая группа?
    – Как мы собираемся достичь цели?

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

  • Истории пользователей — это в основном о цели приложения.
  • Изображение вашего потенциального клиента  – определяется как «персонаж пользователя». Во время исследовательского семинара команда проекта и клиент пытаются ответить на такие вопросы, как «Кто хотел бы использовать приложение?» или «С какой самой большой проблемой они сталкиваются и что мы можем сделать, чтобы помочь им?».
  • Блок-схема — показывает, как работает процесс. Например, он может показать, как работает навигация или как пользователи могут перемещаться по приложению.
  • Технические вопросы – описывает проблемы, связанные с используемой техникой.
  • Информация о членах команды – это полная презентация команды и их навыков.
  • Оценка проекта – это ориентировочная стоимость прототипа приложения.

Информационный бюллетень

Узнайте больше о процессе разработки программного обеспечения из нашего информационного бюллетеня. Зарегистрируйтесь сейчас и побалуйте себя порцией знаний Горриона.

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

Области исследований 

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

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

Бизнес и технический

Например, в  сфере бизнеса мы отличаемся от таких тем, как «Кто является нашим целевым рынком?» на «Как поживают наши конкуренты» или «Какие ключевые функции ищет рынок?».

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

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

Например: «Что может помочь в положительном приеме заявления?» Подтверждая идею продукта с помощью тестов и PoC, мы гарантируем, что достичь соответствия продукта и рынка будет проще. Это, в свою очередь, будет способствовать общему успеху созданной компании клиента.

Как быть с управлением рисками проекта в разработке программного обеспечения? Узнайте здесь.

Процесс для специальных задач

В рамках семинара мы можем предложить Design Sprint (по желанию). Особенно, когда идея новаторская, и мы хотим посмотреть, удовлетворит ли она потребности пользователей.

Design Sprint — это ограниченный по времени и очень творческий способ проверки концепции. Он направлен на снижение риска вывода нового решения на рынок. Будь то функция, услуга или продукт, это помогает нам установить цели и проверить правильность первоначальных предположений. Это также позволяет нам проверить и сделать как можно больше в кратчайшие сроки.

Ниже вы можете найти шаблон образцового Design Sprint, который мы подготовили для одного из наших клиентов.

Как видите, даже во время Design Sprint наша команда хочет поддерживать постоянный контакт с вами как с нашим партнером. Все это для того, чтобы решения соответствовали вашим требованиям.

Разработка программного обеспечения на заказ — управление проектами

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

Когда дело доходит до  разработки программного обеспечения,  этот подход очень гибкий – мы можем изменять его много раз. То же самое касается бюджета. Благодаря такому подходу вся команда чувствует ответственность за проект. Кроме того, клиент имеет полное и постоянное представление о процессе разработки программного обеспечения.

Советы по проведению удаленной мастерской

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

  • Mentimeter — мы используем его на семинарах для интерактивных презентаций.
  • Whimsical & Miro  – инструменты для всех нас, позволяющие создавать потоки и новые идеи, анализировать заинтересованные стороны и голосовать за решения.
  • Slack — для ежедневного обсуждения всей командой и клиентом. Это место для общения, решения вопросов, обмена планами и выдвижения идей.
  • Звонки Slack и Google Meet — для обсуждения прогресса Sprint и приоритетов на следующую неделю.
  • ClickUp  – благодаря этому инструменту мы можем планировать и самостоятельно организовывать свою работу.
  • Figma  – инструмент для совместной работы, который мы используем, чтобы делиться и обсуждать каркасы проекта, интерактивные прототипы и их дизайн. Это также отлично подходит для сеансов мозгового штурма и создания систем проектирования. В целом, Figma чрезвычайно полезна в процессе проектирования.

Что такое дизайн-система и действительно ли она вам нужна? – прочтите эту статью и узнайте все о дизайн-системах.

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

Ключевые выводы

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

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

Семинары отлично подходят для укрепления доверия, поскольку они предоставляют пространство для всех участников, где они могут генерировать и предлагать свои идеи, давать отзывы о них и, в конечном итоге, выслушивать мнения и идеи друг друга. Это, в свою очередь, закладывает основу для долгосрочного сотрудничества.

Примечание редактора. Первоначально мы опубликовали этот пост в августе 2020 года и обновили его для полноты информации.

Семинар по определению проекта – Blueprint Technologies