Слишком уж все сложно расписано. Так начать невозможно.
Всё должно быть проще: в самом начале надо проработать два вопроса: концепцию и стратегию. Можно все написать в одном документе, можно разбить на два, не важно.
В Концепции даётся описание идеи, краткое описание того, для кого предназначен продукт, какие цели пользователя будут достигаться при использовании этого продукта; сравнение с конкурентами и позиционирование на рынке; даётся предварительная оценка рисков. Т.е. это все вышеперечисленные пункты 1, 2, 3, 4, 6, 9 Концепция нужна прежде всего самой команде разработки, чтобы понимать, какой именно продукт создаётся.
Стратегия нужна больше для поиска инвесторов: в ней расписываются предполагаемые затраты, а так же даётся описание планируемого развития продукта и соотв — получения прибыли. Исходя из Стратегии потом готовится бизнес-план. т.е. пункты — 8, 9, 11
Вот когда эти два документа у вас подготовлены — можно начинать готовить презентации продукта для поиска инвесторов. т.е. пп.5, 7 И дальше уже заниматься более детальной проработкой остальных документов.
А в вашем случае — одни метания…
Мне кажется, что всё начинается гораздо раньше. Прежде чем на сцену выйдет специалист по UX, должны выступить маркетинг-менеджеры и выяснить у заказчика один простой вопрос: «А что он хочет?» Вполне может так случиться, что Заказчик хочет получить именно сайт-визитку со всей этой шелухой. В этом случае просто глупо убеждать его в том, что «вашим пользователям нужно совсем другое!»
Первоначально идет выбор целей. Для каких целей создается сайт? Чего именно планируется достичь? Повысить продажи? Узнаваемость бренда?
После определения целей идет постановка задач. Чтобы повысить продажи, мы должны организовать электронный магазин. Либо, чтобы улучшить узнаваемость бренда мы хотим сделать презентационный сайт. Либо, чтобы повысить удовлетворенность клиента мы хотим сделать сайт технической поддержки, и т.п.
Когда поставлены задачи, начинается проработка взаимодействия: какой последовательностью действий будет выполняться та или иная задача. И вот только здесь в дело включаются специалисты по UX, которые помогают проектировщикам взаимодействия (IxD) правильно простроить все сценарии использования.
И когда сценарии использования простроены, задокументированы, утверждены с заказчиком, только тогда начинается работа по созданию сайта.
1. Чем тратить деньги на невнятное мероприятие с гарантированно недостижимой целью (надо либо переписать ВСЕХ, либо вообще не затевать), лучше бы на эти деньги заставили работать участковых и паспортные столы. Вся эта информация у них есть, по крайне мере, должна быть. Они получают деньги именно за эту работу — переписывать всех кто где живет. Если государство объявляет общую перепись населения — я понимаю, что на местах участковые и работники паспортных столов заняты непонятно чем. Потратьте деньги на оптимизацию и автоматизацию их труда — толку будет гораздо больше, т.к. появится не просто статистически не верный временной срез «раз в 10 лет», а ежедневно обновляемая картина, по которой реально можно будет видеть эмиграционные потоки и динамику.
2. Вся эта кутерьма лично мне не нужна, как бы меня не убеждали в обратном. Все аргументы сводятся к тому, что «это же вам самим надо!» Чушь полная. Это важно управленцам и функционерам. Ибо я с них спрошу, почему в нашем районе не хватает школ и детских садов? У вас есть данные регистрации населения — вы были обязаны их использовать для планирования жилой инфраструктуры. А то в районе 5 торговых центров и 2 детских садика… И я никак не обязан тратить на чиновников ещё свое свободное время, они и так при любом удобном случае вытянут у меня пол-дня.
P.S. К нам переписчики так и не пришли, хотя практически центр города и жена сейчас целыми днями дома.
P.P.S. Маленькая ложь рождает большое недоверие: то «перепись будет анонимна», а то оказывается, что без ФИО и адреса ты переписчику не интересен…
В целом всё написано правильно, всё верно.
Но по моему опыту, наиболее частая причина срыва сроков — когда заказчик начинает «капризничать»: «Мы совсем не это имели ввиду! Вот это надо понимать вот так, а вот это — вот так!»
Очень сложная задача — составить ТЗ таким образом, чтобы заказчик его принял, но и чтобы свои интересы были соблюдены. Особенно это заметно при работе с очень большими корпоративными заказчиками, когда малейшее изменение ТЗ приводит к необходимости согласования «по большому кругу». Такие проекты очень тяжело начать, но еще сложнее — завершить. «Хотелки» начинают вырастать на глазах…
Единственный варинат, когда такой ситуации можно избежать: писать ТЗ не в терминах реализации функциональности, а в терминах реализации сценариев использования. Тогда «хотелки» фильтруются на раз: «В наших сценариях, под которыми вы уже поставили свою подпись, такая функциональность не используется. Это вообще другой сценарий, который мы предлагаем реализовать во втором этапе проекта.»
Обычно во всех подобных приложениях есть пункт, запрещающий без ведома автора каким-либо образом менять продукт или какие-либо его части. Указанной проблемой должны прежде всего озаботиться авторы оригинального софта, ибо за их счет кто-то зарабатывает себе бабло. Даже если этот факт им фиолетов, то, как минимум, страдает репутация.
Забавно, забавно…
Рассказано, как добиваться своего «тихой сапой». «Не мешайте...», но при этом «укажите на то...», «укажите на это...»
Можно назвать «Краткий курс Серого кардинала».
А в целом, конечно, дельные замечания. К таким умным тестерам да еще и таких же умных менеджеров и программистов — просто взрыв бы получился! ;)
Разумеется, что тест-менеджер не в силах изменить ситуацию сразу, если руководство не понимает необходимости внедрения правильных маркетинговых процессов. Единственное, что может сделать TM — постоянно и везде поднимать этот вопрос, если он сам действительно понимает необходимость этого.
Тот факт, что даже у многих мировых лидеров такая практика не используется — виден хотя бы на примере WP7, когда даже в основных сценариях, которые позиционируются как Sales Point, есть просто «убийственные» пробелы. Если бы сценарии прорабатывались, то ничего подобного бы не было в принципе.
Вот чтобы такой ситуации не было и нужен документ «Сценарии использования» с расставленным в нём приоритетами. И оценка приоритета ошибок тогда делается очень просто: если в основном сценарии не выполняется главная задача — это Epic fail и без вариантов. А если в сценарии с приоритетом Low где-то что-то работает не так, как нужно, на это в первой версии можно и забить.
Вопрос упирается, как всегда, в терминологию. Какую роль вы отводите «тест-аналитикам»? За что они отвечают?
Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта. Разумеется, если продукт уже имеет выпущенные ранее предыдущие версии, то User's Experience от предыдущих версий должен учитываться в обязательном порядке, но это никак не отменяет необходимости подготовки сценариев для новой версии.
Все верно, именно так. Я не стал тут раскрывать всю цепочку, ибо там еще есть и Marketing Manager-ы, которые позиционирование прорабатывают, и Competitors Analyze ведут. И много еще кого.
Моя главная мысль была в том, что Testing Manager не должен заниматься маркетиновыми документами, это дело отдела маркетинга и проектировщиков взаимодействия. А получает он все документы от Project Manager-а, который отслеживает всю работу по проекту и координирует работу всех отделов.
Я про это и говорю. Можно сделать девайс на Android, который будет действительно бесплатным для пользователя, но это будет такое У.Г., которое никто в жизни не купит.
Точнее говоря, на такой «обрезанной» операционке можно делать различные специализированные девайсы, но простой универсальный КПК будет неконкурентоспособным.
При правильной организации процесса Program Engineering тестеры вместе с кодом (а лучше за некоторое время ДО того) должны получить от Project Manager-а такие документы как User's Scenarios & Personas. Эти документы должны описывать то, как именно будет использоваться продукт, и кем. Второе не столь важно. Важнее, чтобы в перечне сценариев стояли приоритеты. Первыми должны проверяться именно сценарии главного приоритета, и только затем — все последующие.
Важно здесь то, что распределять приоритеты (и уж тем более — писать сами сценарии) должен ну никак не Testing Manager. Это не его специализация и не его забота. Он должен получить их готовыми от Project Manager. Еще хорошо получить общий документ с общим описанием взаимодействия пользователя и текущей версии продукта. Это более широкий и более детальный документ, описывающий не только конкретные сценарии использования, а весь процесс взаимодействия пользователя и продукта. По этому документы Interface Designer должен был перед этим рисовать интерфейсы, а Developer Manager распределять работы между программистами.
Как-то так…
На самом деле, Андроид бесплатен только тогда, когда производитель не интегрирует никаких сервисных приложений от Google типа Gmail & AndroidMarket. Если такие приложения есть, значит производитель отчисляет рояльти гуглу. Плюс, если интегрирована синхронизация с Exchange — еще и роялти Microsoft. Много ли вы знаете девайсов без gmail?
Так что в статейке есть некие передергивания.
Мотивация очень проста: объективность. То, что указано в подборке — оно есть. С этим и будет сделан первый выпуск. Останется ли это ко второму — вопрос… Еще больший вопрос — получат ли исправления пользователи. Ибо вот у apple в Лицензионном соглашении сказано, что пользователь имеет право на бесплатное получение всех обновлений в рамках текущей версии и одного обновления на новую. Т.е. Apple гарантирует, что новую версию вы получите. MS всегда и всю жизнь требовал платного перехода на новые версии, за редким исключением предоставляя бесплатную возможность обновления, как это было для некоторых моделей HTC при выпуске WinMobile 6 (Artemis, TyTN, Excalibur и еще что-то).
8. Т.е. андроидные девайсы, позволяющие подключить внутреннюю карту к ПК просто как внешний диск, поощряют пиратство? Чет не улавливаю логики…
10. Пусть купит сперва, а потом и будем говорить…
11. Вот здесь причины про контрафакт вполне логичны, но тогда про какое «корпоративное применение» можно говорить? Кто из корпораторов будет выкладывать свой проприетарный софт на Marketplace для того, чтобы потом ставить его на устройства? Я много работал с корпораторами. Могу 100% сказать, что если в компании есть «1-ый отдел», то такие вещи сразу зарубают.
Всё должно быть проще: в самом начале надо проработать два вопроса: концепцию и стратегию. Можно все написать в одном документе, можно разбить на два, не важно.
В Концепции даётся описание идеи, краткое описание того, для кого предназначен продукт, какие цели пользователя будут достигаться при использовании этого продукта; сравнение с конкурентами и позиционирование на рынке; даётся предварительная оценка рисков. Т.е. это все вышеперечисленные пункты 1, 2, 3, 4, 6, 9 Концепция нужна прежде всего самой команде разработки, чтобы понимать, какой именно продукт создаётся.
Стратегия нужна больше для поиска инвесторов: в ней расписываются предполагаемые затраты, а так же даётся описание планируемого развития продукта и соотв — получения прибыли. Исходя из Стратегии потом готовится бизнес-план. т.е. пункты — 8, 9, 11
Вот когда эти два документа у вас подготовлены — можно начинать готовить презентации продукта для поиска инвесторов. т.е. пп.5, 7 И дальше уже заниматься более детальной проработкой остальных документов.
А в вашем случае — одни метания…
Первоначально идет выбор целей. Для каких целей создается сайт? Чего именно планируется достичь? Повысить продажи? Узнаваемость бренда?
После определения целей идет постановка задач. Чтобы повысить продажи, мы должны организовать электронный магазин. Либо, чтобы улучшить узнаваемость бренда мы хотим сделать презентационный сайт. Либо, чтобы повысить удовлетворенность клиента мы хотим сделать сайт технической поддержки, и т.п.
Когда поставлены задачи, начинается проработка взаимодействия: какой последовательностью действий будет выполняться та или иная задача. И вот только здесь в дело включаются специалисты по UX, которые помогают проектировщикам взаимодействия (IxD) правильно простроить все сценарии использования.
И когда сценарии использования простроены, задокументированы, утверждены с заказчиком, только тогда начинается работа по созданию сайта.
2. Вся эта кутерьма лично мне не нужна, как бы меня не убеждали в обратном. Все аргументы сводятся к тому, что «это же вам самим надо!» Чушь полная. Это важно управленцам и функционерам. Ибо я с них спрошу, почему в нашем районе не хватает школ и детских садов? У вас есть данные регистрации населения — вы были обязаны их использовать для планирования жилой инфраструктуры. А то в районе 5 торговых центров и 2 детских садика… И я никак не обязан тратить на чиновников ещё свое свободное время, они и так при любом удобном случае вытянут у меня пол-дня.
P.S. К нам переписчики так и не пришли, хотя практически центр города и жена сейчас целыми днями дома.
P.P.S. Маленькая ложь рождает большое недоверие: то «перепись будет анонимна», а то оказывается, что без ФИО и адреса ты переписчику не интересен…
Но по моему опыту, наиболее частая причина срыва сроков — когда заказчик начинает «капризничать»: «Мы совсем не это имели ввиду! Вот это надо понимать вот так, а вот это — вот так!»
Очень сложная задача — составить ТЗ таким образом, чтобы заказчик его принял, но и чтобы свои интересы были соблюдены. Особенно это заметно при работе с очень большими корпоративными заказчиками, когда малейшее изменение ТЗ приводит к необходимости согласования «по большому кругу». Такие проекты очень тяжело начать, но еще сложнее — завершить. «Хотелки» начинают вырастать на глазах…
Единственный варинат, когда такой ситуации можно избежать: писать ТЗ не в терминах реализации функциональности, а в терминах реализации сценариев использования. Тогда «хотелки» фильтруются на раз: «В наших сценариях, под которыми вы уже поставили свою подпись, такая функциональность не используется. Это вообще другой сценарий, который мы предлагаем реализовать во втором этапе проекта.»
Рассказано, как добиваться своего «тихой сапой». «Не мешайте...», но при этом «укажите на то...», «укажите на это...»
Можно назвать «Краткий курс Серого кардинала».
А в целом, конечно, дельные замечания. К таким умным тестерам да еще и таких же умных менеджеров и программистов — просто взрыв бы получился! ;)
Моё твёрдое убеждение, что пользовательские сценарии должны быть готовы еще ДО начала разработки продукта. Разумеется, если продукт уже имеет выпущенные ранее предыдущие версии, то User's Experience от предыдущих версий должен учитываться в обязательном порядке, но это никак не отменяет необходимости подготовки сценариев для новой версии.
Моя главная мысль была в том, что Testing Manager не должен заниматься маркетиновыми документами, это дело отдела маркетинга и проектировщиков взаимодействия. А получает он все документы от Project Manager-а, который отслеживает всю работу по проекту и координирует работу всех отделов.
Точнее говоря, на такой «обрезанной» операционке можно делать различные специализированные девайсы, но простой универсальный КПК будет неконкурентоспособным.
Важно здесь то, что распределять приоритеты (и уж тем более — писать сами сценарии) должен ну никак не Testing Manager. Это не его специализация и не его забота. Он должен получить их готовыми от Project Manager. Еще хорошо получить общий документ с общим описанием взаимодействия пользователя и текущей версии продукта. Это более широкий и более детальный документ, описывающий не только конкретные сценарии использования, а весь процесс взаимодействия пользователя и продукта. По этому документы Interface Designer должен был перед этим рисовать интерфейсы, а Developer Manager распределять работы между программистами.
Как-то так…
Так что в статейке есть некие передергивания.
10. Пусть купит сперва, а потом и будем говорить…
11. Вот здесь причины про контрафакт вполне логичны, но тогда про какое «корпоративное применение» можно говорить? Кто из корпораторов будет выкладывать свой проприетарный софт на Marketplace для того, чтобы потом ставить его на устройства? Я много работал с корпораторами. Могу 100% сказать, что если в компании есть «1-ый отдел», то такие вещи сразу зарубают.