Как интернет вещей «убьет» известные нам методики проектирования интерфейсовAlexey Kopylov
Устоявшаяся методика проектирования взаимодействия основана на персонажах и сценариях. Эта методика плохо работает на массовых продуктах с большим количеством уникальных видов деятельности и вариантов использования. Также она плохо учитывает гетерогенности современных информационных продуктов и услуг.
На помощь нам приходят картирование услуг (в частности Customer Journey Map) и такие методики, как Jobs to Be Done и Agile/Lean варианты. Однако, неизбежно грядущий интернет вещей делает и эти методики морально устаревшими.
Что дальше? Какую метододлогическую базу мы должны построить, чтобы быть встретить новый дивный мир во всеоружии?
Обзорный материал о применяемых методиках работы над цифровыми продуктами. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Презентация Юрия Ветрова "Алгоритмический дизайн: Экзо-скелет для дизайнера" с конференции User Experience Russia 2016. Обновлено для конференции Krupa Product Design Conference 2017.
Обзорный материал о базовых принципах прототипирования цифровых продуктов. Использованы общедоступные материалы по теме, собранные с различных тематических ресурсов. Для демонстрации использованы прототипы студии funkypunky. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Микромоменты: руководство по успешному мобильному маркетингуAIC
Микромоменты — спонтанные моменты, когда пользователи испытывают желание или потребность найти информацию, подходящее место, заказать товар или услугу и используют для этого мобильный телефон. Эти критически важные точки контакта с брендами случаются постоянно, и компаниям следует выработать для них особую стратегию поведения.
Google представляет подробное руководство по новой модели маркетинга, подкрепленное статистикой, наблюдениями и успешными примерами из разных областей бизнеса.
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...Yury Vetrov
Презентация Юрия Ветрова "Повысить конверсию или удобство использования? Оба варианта лучше. Кейс с сайтом Московского Кредитного Банка" с конференции Юзабилити Украина '10.
Что будет, если выйти за пределы парадигмы дизайнер-заказчик и самому управлять процессом получения результата? Управление проектированием, дизайном и разработкой продуктов, исследование рынка и конкурентов, тестирование ваших решений и поддержка ваших пользователей — что нужно знать дизайнеру о работе менеджера или для тех, кто хочет им стать.
Будущее UX методологии и проблемы/«дорожная карта» // RIF'2014Andrew Sikorskiy
Краткий обзор того, как связано UX с продуктовой и бизнес-разработкой, типовые проблемы становления и развития методологии и профессии и «дорожная карта» развития профессии
Как интернет вещей «убьет» известные нам методики проектирования интерфейсовAlexey Kopylov
Устоявшаяся методика проектирования взаимодействия основана на персонажах и сценариях. Эта методика плохо работает на массовых продуктах с большим количеством уникальных видов деятельности и вариантов использования. Также она плохо учитывает гетерогенности современных информационных продуктов и услуг.
На помощь нам приходят картирование услуг (в частности Customer Journey Map) и такие методики, как Jobs to Be Done и Agile/Lean варианты. Однако, неизбежно грядущий интернет вещей делает и эти методики морально устаревшими.
Что дальше? Какую метододлогическую базу мы должны построить, чтобы быть встретить новый дивный мир во всеоружии?
Обзорный материал о применяемых методиках работы над цифровыми продуктами. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Презентация Юрия Ветрова "Алгоритмический дизайн: Экзо-скелет для дизайнера" с конференции User Experience Russia 2016. Обновлено для конференции Krupa Product Design Conference 2017.
Обзорный материал о базовых принципах прототипирования цифровых продуктов. Использованы общедоступные материалы по теме, собранные с различных тематических ресурсов. Для демонстрации использованы прототипы студии funkypunky. Лекция проведена в рамках интенсива по продуктовому дизайну в Британской Высшей Школе Дизайна (Москва).
Микромоменты: руководство по успешному мобильному маркетингуAIC
Микромоменты — спонтанные моменты, когда пользователи испытывают желание или потребность найти информацию, подходящее место, заказать товар или услугу и используют для этого мобильный телефон. Эти критически важные точки контакта с брендами случаются постоянно, и компаниям следует выработать для них особую стратегию поведения.
Google представляет подробное руководство по новой модели маркетинга, подкрепленное статистикой, наблюдениями и успешными примерами из разных областей бизнеса.
Юзабилити Украина '10: Case Study: Московский Кредитный Банк. Повысить конвер...Yury Vetrov
Презентация Юрия Ветрова "Повысить конверсию или удобство использования? Оба варианта лучше. Кейс с сайтом Московского Кредитного Банка" с конференции Юзабилити Украина '10.
Что будет, если выйти за пределы парадигмы дизайнер-заказчик и самому управлять процессом получения результата? Управление проектированием, дизайном и разработкой продуктов, исследование рынка и конкурентов, тестирование ваших решений и поддержка ваших пользователей — что нужно знать дизайнеру о работе менеджера или для тех, кто хочет им стать.
Будущее UX методологии и проблемы/«дорожная карта» // RIF'2014Andrew Sikorskiy
Краткий обзор того, как связано UX с продуктовой и бизнес-разработкой, типовые проблемы становления и развития методологии и профессии и «дорожная карта» развития профессии
SQA Days 2009: Контроль качества интерфейсных решений на всех этапах процесса...Yury Vetrov
Мастер-класс Юрия Ветрова "Контроль качества интерфейсных решений на всех этапах процесса проектирования и разработки" на пятой конференции SQA Days 2009.
Макс Гапонов. Тактическое управление продуктами: все еще недостающее звеноScrumTrek
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
2. Двигать пиксели, или
решать проблемы?
• Ты либо берешь на себя ответственность за
продукт и решаешь дизайном проблемы
бизнеса. Либо остаешься рисователем
страниц в Фотошопе или серых
прямоугольников в Axure.
Не ждешь, пока тебя попросят — предлагаешь
изменения сам, рекомендуешь решения,
инициируешь процессы.
3. Двигать пиксели, или
решать проблемы?
• Чтобы перестать двигать пиксели, нужно
применять дизайнерский подход к решению
всех задач. Он хорош не только при
продумывании интерфейса, но и для
оптимизации процессов, решения
организационных проблем, поиска технических
решений.
• Нужно смотреть шире и не бояться
ограничений.
5. Двигать пиксели, или
решать проблемы?
• В таком активном подходе есть уйма
ограничений и придется с ними столкнуться —
на сам дизайн будет уходить меньше времени,
придется идти на компромиссы.
• Eсли подходить к запускам ответственно — от
дизайна до релиза проходит приличное
количество времени.
6. Двигать пиксели, или
решать проблемы?
• Зная это вы сможете строить свои
взаимоотношения так, чтобы быть
услышанными и понятыми. И иметь
полномочия на гораздо больший спектр
действий, чем просто определение
визуального стиля.
• Надоело слушать экспертов “моя жена
попросила добавить…” или “наш секретарь
думает, что лучше…”?
7. • Привлечение (Acquisition) — доля клиентов
(потенциальных), привлеченных через маркетинговые
каналы, и обнаруживших заинтересованность в продукте
(не сразу покинувших сайт).
• Активация (Activation) — доля клиентов, получивших
положительный опыт использования продукта.
• Удержание (Retention) — доля клиентов, повторно
использующих продукт.
• Доход (Revenue) — доля клиентов, которые платят за
продукт.
• Рекомендация (Referral) — доля клиентов, которые
рекомендуют продукт (делятся ссылкой, высылают
приглашения).
8. • Важно решать проблемы бизнеса — тогда вы
будете на одной волне с ним и сможете
внедрять настолько глубокие изменения своим
дизайном, о которых раньше и не мечтали.
10. Waterfall
• Каскадная модель (англ. waterfall model,
иногда переводят, как модель "Водопад") —
модель процесса разработки программного
обеспечения, в которой процесс разработки
выглядит как поток, последовательно
проходящий фазы анализа требований,
проектирования, реализации, тестирования,
интеграции и поддержки.
11. Waterfall
• Управление проектом, условно, можно
разделить на две составляющие — на
планирование и управление ходом.
• С этой точки зрения для waterfall всё ясно —
составили пошаговый (аналитика-разработка-
тестирование) календарный план задач по
оценкам сроков, распределили задачи и
вперед реализовывать.
http://habrahabr.ru/post/226323/
13. Waterflow
• Преимущества:
• Последовательное выполнение этапов проекта в строгом
фиксированном порядке
• Позволяет оценивать качество продукта на каждом этапе
• Недостатки:
• Отсутствие обратных связей между этапами
• Не соответствует реальным условиям разработки
программного продукта
15. Agile
• Гибкая методология разработки (англ. Agile
software development, agile-методы) — серия
подходов к разработке программного
обеспечения, ориентированных на
использование итеративной разработки,
динамическое формирование требований и
обеспечение их реализации в результате
постоянного взаимодействия внутри
самоорганизующихся рабочих групп, состоящих
из специалистов различного профиля
16. Agile
• В феврале 2001 в штате Юта США был
выпущен «Манифест гибкой методологии
разработки программного обеспечения».
Он являлся альтернативой управляемым
документацией, «тяжеловесным» практикам
разработки программного обеспечения, таким
как «метод водопада», являвшимся золотым
стандартом разработки в то время.
17. Agile
• Основные идеи:
• люди и взаимодействие важнее процессов и
инструментов;
• работающий продукт важнее исчерпывающей
документации;
• сотрудничество с заказчиком важнее согласования
условий контракта;
• готовность к изменениям важнее следования
первоначальному плану.
18. Agile
• Принципы, которые разъясняет Agile Manifesto[2]:
• удовлетворение клиента за счёт ранней и бесперебойной
поставки ценного программного обеспечения;
• приветствие изменений требований даже в конце разработки
(это может повысить конкурентоспособность полученного
продукта);
• частая поставка рабочего программного обеспечения (каждый
месяц или неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на
протяжении всего проекта;
19. • проектом занимаются мотивированные личности, которые
обеспечены нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор
(лицом к лицу);
• работающее программное обеспечение — лучший измеритель
прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность
поддерживать постоянный темп на неопределённый срок;
• постоянное внимание улучшению технического мастерства и
удобному дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у
самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.
20. • Один из повторяющихся пунктов критики: при agile-
подходе часто пренебрегают созданием плана
(«дорожной карты») развития продукта, равно как и
управлением требованиями, в процессе которого и
формируется такая «карта». Гибкий подход к
управлению требованиями не подразумевает далеко
идущих планов (по сути, управления требованиями
просто не существует в данной методологии), а
подразумевает возможность заказчика вдруг и
неожиданно в конце каждой итерации выставлять
новые требования, часто противоречащие архитектуре
уже созданного и поставляемого продукта.
Такое иногда приводит к катастрофическим
«авралам» с массовым рефакторингом и
переделками практически на каждой очередной
итерации.
21. Agile
• Customer Development — методология
непрерывного получения обратной связи от
потребителя, параллельного процессу
разработки продукта. Методология создана
Стивом Бланком (Steve Bank), ее описание
можно найти в его последней книге «The
Startup Owner's Manual: The Step-by-Step
Guide for Building a Great Company».
Ключевая идея: «Get out of the
building.» (Steve Blank)
22. Agile
• Lean Startup — методология использования
коротких быстрых итераций для тестирования
гипотез. Lean Startup — синтез методологий
Customer Development, Agile Software
Development и Lean (Toyota Production
System). Методология создана Эриком Рисом
(Eric Ries), ее описание можно найти в его
книге «The Lean Startup». (В сети есть
пересказ на русском Аркадия Морейниса).
23. Agile
• Канбан (яп. カンバン камбан) — система
организации производства и снабжения,
позволяющая реализовать принцип «точно в
срок».
24. Agile
• Канбан — это система работы, которая
позволяет организовать принцип вытягивания
заказчиком.
http://getpocket.com/a/read/314309095
.gif
25. Agile
• Идеальное состояние дел в студии — равномерная
заполненность проектами всех канбан-ячеек. Как только
заказчик «вытянул» проект с этапа верстки (для нас это
конечная стадия разработки дизайна сайта) — есть
необходимость тут же перевести один из проектов, находящихся
в отрисовке на этап верстки, чтобы заполнить пустую ячейку.
http://getpocket.com/a/read/314309095
27. Agile
• Канбан-доска очень наглядно показывает на
каком из этапов необходимо ускориться по
какому-либо проекту, а на каком образовался
«затор». И ещё — что пора бы задуматься о
том, что на складе уже почти ничего нет и
самое время заняться обработкой
потенциальных клиентов.
http://getpocket.com/a/read/314309095
28. Agile
• Зеленый — по проекту все ок. Желтый — есть
вероятность, что проект задержится на данном этапе.
Красный — проект задержался на данном этапе, и
надо постараться сделать все, чтобы перенести его на
следующий этап.
http://getpocket.com/a/read/314309095
29. Итоги
• Визуализация проектов с помощью канбан-доски
и принцип вытягивания позволяет легко оценить
необходимость обработки потенциального
клиента, переноса залежавшегося не срочного
проекта на следующий этап и т.д.
• Для оценки занятости дизайнера на ближайшие
два месяца достаточно посмотреть на доску,
посчитать количество стикеров с именем
дизайнера и понять насколько он загружен и
когда освободится.
30. Итоги
• Сейчас наглядно видно на каком этапе есть
проблема. Остается найти её и решить.
• Простой, но достаточно эффективный
инструмент финансового планирования. Да, он
позволяет заглянуть всего на 2-3 месяца
вперед. Но зато это очень наглядно. И на
денежный поток реально можно повлиять,
вовремя приложив все усилия к «нужным»
проектам.
33. Деловая переписка
• Thank you letter — не позже чем 60 минут
2 строчки благодарности за встречу.
• Follow up — не позже чем 24 часа
Протокол встречи + развернутые документы +
атачи файлов + принятые решения, сроки,
ответственные люди.
34. Структура письма
• Introduction – Вступление (предмет отчета, кто его
написал и по чьему запросу)
• Background - Исходные данные (общее описание
имеющейся ситуации, проблемы)
• Findings - Полученные данные (возможные пути
развития ситуации, решения проблемы, сроки,
ответственные люди.)
• Conclusion, recommendations - Выводы и
рекомендации
35. Деловая переписка
Язык личной переписки отличается от деловой. Но
одно дело — писать уважительно, и совсем
другое — казаться бездушным роботом.
Хорошее деловое письмо выглядит вежливым и
при этом не создает дополнительной дистанции
между отправителем и адресатом.
http://getpocket.com/a/read/584935569
36. Настоящим уведомляю,
довожу до сведения
Подобные фразы не несут пользы, а лишь
отталкивают своим официозом. Чаще всего после них
идет официальная информация с датой и событием.
Дорогие коллеги! Довожу до вашего сведения, что в
связи с государственными праздниками 1–4 мая
объявляются выходными днями.
Поправим:
Дорогие коллеги! По производственному календарю
на 2014 год 1–4 мая — выходные.
http://getpocket.com/a/read/584935569
37. Являться
Добрый день! Я являюсь управляющим
партнером сети кафе «Горшочек, вари!».
Поправим:
Добрый день! Я управляющий партнер сети кафе
«Горшочек, вари!»
http://getpocket.com/a/read/584935569
38. Данный
Коллеги! Помогите данному клиенту
разобраться с данным вопросом.
Поправим:
Коллеги! Помогите клиенту решить вопрос.
http://getpocket.com/a/read/584935569
39. А именно
Я готов встретиться на следующей неделе,
а именно 8 апреля.
Поправим:
Я готов встретиться 8 апреля.
http://getpocket.com/a/read/584935569
40. Осуществлять,
производить
Добрый день, коллеги! В понедельник, с 16:00
до 18:00, возле ресепшена будет производиться
раздача подарков для детей сотрудников.
Поправим:
Добрый день, коллеги! Подарки для детей
сотрудников выдаем в понедельник, с 16:00 до
18:00, возле стойки администратора.
http://getpocket.com/a/read/584935569
41. Осуществлять,
производить
Добрый день, коллеги! В понедельник, с 16:00
до 18:00, возле ресепшена будет производиться
раздача подарков для детей сотрудников.
Поправим:
Добрый день, коллеги! Подарки для детей
сотрудников выдаем в понедельник, с 16:00 до
18:00, возле стойки администратора.
http://getpocket.com/a/read/584935569
43. Как ответить на
агрессивное письмо?
• Sent: Tuesday, November 17, 2014 10:15 PM
To: team@xxx.com.ua
• Subject: Да вы #@$%ли совсем! Как вернуть
деньги? Пытаюсь отправить данные
(подставьте любой кейс), а оно пересылает на
сайт! Потратил два часа! Что за $#@%?!
Пользуйтесь сами своими $#%@@ услугами/
сервисами/продуктами!
http://goo.gl/gkzsd1
44. Ошибки
• Затягивать время ответа: не знаю, как ответить;
пусть подождет, может, что-нибудь придумаем или
«само рассосется».
• Подавить свои эмоции. Ответить по существу, в
стиле «в Багдаде все спокойно».
• Возмутиться поведением клиента и ответить на
агрессивное письмо-претензию в стиле «Что вы
себе позволяете?» При этом переслать письмо
начальству: посмотрите, дескать, с какими хамами
приходится работать!
http://goo.gl/gkzsd1
45. Ошибки
• Возмутиться некорректным поведением клиента и вообще не
отвечать: пусть вначале научится цивилизованно выражаться,
а потом будем общаться.
• Признать полную справедливость претензии, «посыпать
голову пеплом». Привести аргументы в свое оправдание.
Уверить, что такого впредь не повторится, попросить клиента
дать вам шанс все исправить.
• Ответить: «Деньги вернем». При этом вычеркнуть хама из
списка своих клиентов.
• С замиранием сердца открывать почту, опасаясь новой
«агрессивной атаки».
http://goo.gl/gkzsd1
46. Как ответить на
агрессивное письмо?
1. Старайтесь не затягивать с ответом. Среднее
стандартное время ответа на письмо клиента – не
более 2-3 часов.
Если Вам необходимо время для того, чтобы
разобраться с ситуацией, и это может занять
времени больше, нежели 2-3 часа – сразу напишите
клиенту письмо с сообщением, что Вы получили его
письмо и ответите на его просьбу не позднее…
Кстати, это время также позволит Вам справиться
со своей первоначальной эмоциональной реакцией.
http://goo.gl/gkzsd1
47. Как ответить на
агрессивное письмо?
2. Любое деловое письмо содержит в себе две
составлящих: фактическую, собственно
деловую (вопросы, которые необходимо решить)
и личную (эмоциональную).
Обычно как бы ни разворачивался личный
(эмоциональный) план письма, какие бы
негативные эмоции не посылал нам клиент, мы
обязаны ответить по существу заданного нам
вопроса.
http://goo.gl/gkzsd1
48. Как ответить на
агрессивное письмо?
Поэтому попробуйте поработать с письмом
следующим образом:
Внимательно прочтите письмо. Возможно,
это придется сделать несколько раз: иногда из
эмоционального послания бывает трудно понять,
чего же конкретно от нас хотят. Иногда самому
бывает трудно остаться спокойным и не затеять
внутренний диалог, который может мешать
пониманию сути письма.
http://goo.gl/gkzsd1
49. Как ответить на
агрессивное письмо?
Постарайтесь разделить содержимое письма на
«бизнес-составляющую», которую следует
решить, и «эмоциональную составляющую».
Разберитесь, где собственно факты, а где –
«эмоции по поводу».
http://goo.gl/gkzsd1
50. Как ответить на
агрессивное письмо?
Сосредоточьтесь на решении делового аспекта.
Определите, чего хочет клиент. Решите, какую
цель будет преследовать Ваше письмо. Цель
может быть разной: от простого ответа на
заданный вопрос до урегулирования конфликта и
решения возникшей у клиента проблемы. В любом
случае полно и конкретно ответьте по существу.
Не проявляйте в этой части письма своего
отношения к эмоциональным нападкам адресата.
Отвечайте так, словно клиент задал Вам вопрос в
спокойной и корректной форме.
http://goo.gl/gkzsd1
51. Как ответить на
агрессивное письмо?
Для комментария эмоций адресата и своих
эмоций воспользуйтесь постскриптумом.
http://goo.gl/gkzsd1
52. Как ответить на
агрессивное письмо?
Первой строкой письма обращаемся к клиенту
по имени.
Обращение по имени – признак внимания к
собеседнику, знак культуры делового общения и
инструмент, помогающий избежать безликости.
Имя клиента можно узнать из подписи или
строки адресата.
http://goo.gl/gkzsd1
53. Как ответить на
агрессивное письмо?
Уточняем у адресата правильность нашего
понимания его просьбы/претензии/вопроса.
Это бывает особенно необходимо, если
эмоциональное письмо клиента написано
сбивчиво, мысли в нем хаотичны, трудно понять,
где – собственно просьба, а где — мысли по
поводу. Корректно уточнить правильность
своего понимания позволяет замечательная
фраза: «Если я правильно Вас понимаю,..».
http://goo.gl/gkzsd1
54. Как ответить на
агрессивное письмо?
Если мы владеем информацией по заданному
нам вопросу: предельно четко и полно
сообщаем эту информацию адресату.
http://goo.gl/gkzsd1
55. Как ответить на
агрессивное письмо?
И только ответив клиенту по существу, мы
можем перейти к комментариям
эмоционального аспекта. Пользуясь
постскриптумом, проговариваем свое отношение
к некорректному стилю письма. Форма может
быть разная – в зависимости от нашей позиции в
общении с клиентами и от конечной цели,
которую мы для себя определили перед
написанием письма.
http://goo.gl/gkzsd1
56. Как ответить на
агрессивное письмо?
Завершаем письмо обязательным блоком
контактной информации.
http://goo.gl/gkzsd1
57.
58. Пример письма
Здравствуйте, Андрей!
Если я правильно понимаю, Вы недовольны работой
нашего сервиса и Вам хотелось бы вернуть назад деньги.
Уточните пожалуйста, что именно Вы отправляете на
каком из этапов работы (уточняем детали, правильно ли
мы поняли)…
Если Вы решите вернуть деньги сообщаю, как это можно
сделать. Согласно п.2.2. Договора Оферты,…
(описываем подробно)
http://goo.gl/gkzsd1
59. Пример письма
P.S. Андрей, мне так же, как и Вам, неприятна ситуация, в результате
которой Вы готовы прекратить взаимодействие с нами. Думаю, что и
мы, и Вы в этом случае оказываемся в проигрыше: мы теряем клиента,
а Вы – возможность пользования нашим сервисом (уверяю Вас,
сервисом достаточно удобным и эффективным!). Если Вы готовы
выделить время чтобы разобраться с ситуацией – напишите мне, что
произошло, что Вы обратились к нам с требованием возврата денег. Мы
разберемся в причинах и поможем Вам сделать пользование нашими
услугами максимально комфортным и результативным для Вас.
Единственная просьба: давайте общаться в нормативной лексике».
С уважением, Маша Петрова
Со-Founder «Rога&Копыtа»
+38 063 992 23 12,team@roga.com.ua
http://goo.gl/gkzsd1
61. Бриф
• Чем занимается ваша компания?
• Бизнес-цели приложения?
• Какой тип приложения вам нужен? (здесь
стоит указать для клиентов краткое описание
типов приложений)
• Каких результатов вы хотите добиться с
помощью данного приложения?
62. Бриф
• Приведите примеры подобных приложений.
• Что именно вам нравится в этих примерах?
• Какие решения в подобных приложениях вам не нравятся?
• Перечислите основной функционал будущего приложения:
• Что должно уметь делать приложение?
• Какие основные функциональные блоки вы можете выделить?
• Как приложением будет пользоваться конечный
пользователь?
63. Бриф
• Для каких платформ должно работать приложение? (Apple iOS,
Android, Windows Phone, Blackberry)
• Для какой платформы необходимо реализовать приложение в
первую очередь?
• Как должны обновляться данные в приложении?
• Существует ли необходимость разработки сайта-приложения?
• Кто будет заниматься технической поддержкой приложения?
Необходимо ли техническое обслуживание после гарантийного
обслуживания данного приложения?
• Существует ли необходимость создания системы управления
приложением?
67. Фриланс или фултайм
• Фриланс — хорошее начало для юниора.
• Фриланс — свобода работать круглосуточно.
• Фултайм — хороший/плохой начальник.
• Фултайм — наставничество, рост,
стабильность, большие проекты.
68. Стоит ли браться
за этот проект?
• Нейминг, копирайтинг, шрифты, картинки и
прочая “чужая” работа.
• Красивая цена, но профиль не мой.
• Хотят до завтра, ночь без сна.