Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Gekkon

Страницы: 1
1
Обучение / Re: Интервьирование заказчика
« : 26 Апреля 2016, 11:56:53 »
О! Спасибо за Леффингуэлла. Вы, словно заглянули в мои планы, через пару дней сяду за него, надо окончить освоение Виггерса.
Такие книги нельзя читать как Донцову, о них хорошо сказано: "Некоторые книги нужно попробовать на вкус, другие - проглотить, и лишь немногие - разжевать и переварить".
А после Леффингуэлла буду уже искать рабочее место, где опробовать в боевых условиях полученные знания.

2
Обучение / Re: Интервьирование заказчика
« : 22 Апреля 2016, 11:58:13 »
Специально искал литературу на эту тему. Про интервьюирование заказчика ничего не нашёл, но что-то полезное можно почерпнуть из книг для журналистов на тему "Как брать интервью".
Да, спасибо за наводку, поищу на эту тему. От себя могу сказать, что весьма интересную информацию нашел в литературе по социальной психологии. А конкретно об управлении впечатлением, мнением и реакцией собеседника.
В классическом полном подходе заказчик рассказывает вам о продукте, а вы его спрашиваете о:
- что делает он или люди, проблему которых он хочет решить
- в чём именно заключается проблема
- чего он хочет добиться в смысле результата
- как, по каким признакам он поймёт, что результат получился
- какие ограничения у него есть.
Да, вы абсолютно правы, я некорректно высказался, но подразумевал именно это. От себя могу добавить, что часто стараюсь также составить социальный и психологический портрет представителей групп потребителей, так как это особо актуально при разработке веб-системы (начиная от дизайна и интерфейсов заканчивая модулями системы)
Если вы будете хвататься сразу за видение заказчика, то сильно рискуете тем, что через 2 месяца концепция изменится, т.к. заказчик поймёт, что она не очень решает его настоящую бизнес-задачу. И вы будете бегать кругами пересогласовывая требования.
Пару лет назад бывало периодически наступали на подобные грабли, но ситуация была такая: После собеседования с заказчиком мы разрабатывали несколько макетов дизайна (в целом есть схожести, но все равно более разные, чем схожие). На демонстрации заказчик выбирал один и это фиксировалось на бумаге. А когда уже на половине готовности реализации на вебе, он прибегал, крича, что все плохо, и нужно разрабатывать что-то еще. На высказывание, что мы согласны на это, но это будет стоить дополнительных денег, мне чуть ли не бросали бумаги в лицо обвиняя в мошенничестве...

3
Обучение / Интервьирование заказчика
« : 21 Апреля 2016, 11:56:52 »
Всем доброго дня.
Часто возникает необходимость собеседования (интервьюирования) представителя заказчика на предмет выявления требований к разрабатываемой системе.
Может кто подскажет литературу или иные источники содержащие полезные советы(тактики, приемы, хитрости - любая доступная информация начиная от психологии и заканчивая древнегреческими способами) по проведению интервьюирования заказчика с целью выявления его "желания-видения" разрабатываемого продукта. Спрашиваю из-за желания повышения собственной эффективности в этом деле.

4
но кроме узкоспециализированных знаний, бывает полезно получить-освежить обще академические знания, сам использую и даю другим
https://id.hse.ru/books/92037643.html

выкладываю ссылку внизу с междометием 'Йааар!' на устах
http://www.twirpx.com/file/1898373/

5
Для всех / Re: Выбор ГОСТ'а
« : 27 Февраля 2016, 12:59:13 »
Вообще, мое мнение, гост 15288 - более абстрактный и смещающий ответственность с исполнителя (меня и товарищей) на организацию (в целом) гост 12207. Вот по части применения, не вижу возможной ситуацию, когда применим 12207 и не применим 15288 и обратно.

6
Для всех / Выбор ГОСТ'а
« : 16 Февраля 2016, 15:32:28 »
Всем доброго дня.
Возник вопрос, какой ГОСТ на "Процессы жизненного цикла ПС" более корректно использовать - ГОСТ Р ИСО/МЭК 12207 или ГОСТ Р ИСО/МЭК 15288?
Может кто-нибудь использует у себя их?

7
1. А что, по вашему, сподвигнет пользователя добавлять материалы? Зачем ему вообще это делать?
2. Допустим, нам попался пользователь с неясной мотивацией который надобавлял непонятного, а потом, провалив какой-нибудь экзамен, написал в Аппсторе разгромный коммент, что ваше приложение только навредило ему. И в чем выгода для вас в этом?
В общем я подумал над вашими словами, подумал над замечанием Denis'a Beskov'a и решил, что вы правы, а я пытался съесть слишком большую лягушку за один раз. В общем, я упростил ВИ и уменьшил область с "Изучение языка" до "Пополнение словарного запаса".

8
"Изучение иностранного языка" — это не юскейс, а дорога длинною в жизнь.
Юскейсом бизнес-уровня может быть "Выучить язык X на уровне, достаточном чтобы спросить дорогу и понять ответ".
Юскейсом уровня приложения может быть "Пройти сеанс обучения", "Пройти урок", "Пройти тест".
"Запись статистики", "сборка статистики", "запись прогресса в картах" — это тоже не юскейс, а отдельные функции.
Вы почитайте про сценарную сторону юскейсов у Коберна/Вигерса, а то у вас видны типичные перекосы новичка в стиле "всё есть объект".
Спасибо большое за помощь, сегодня выписавшись из больницы, уже купил книжку Вигерса от "Майкрософт Пресс" и буду изучать.
Вопрос в другом, зачем это вообще?
Какие цели это преследует?
В каком бизнес-процессе участвует?
В чем выгода от такого?
Я пока придумал только один закономерный итог - все будет засрано кем попало (как в википедии), качество упадет ниже плинтуса и интерес к приложению будет потерян.
"Зачем", "Выгода", "Цель" - Вкладывание средств(ведь потраченное время тоже стоит денег) в того, кто изучает.
На счет "засранности" - вы более чем правы, и я сам понимаю это. Именно поэтому базовые материалы будут поставляться с программой, а изменения будут Локальны - каждый уникальный пользователь портит свою уникальную установленную версию. И ответственность будет висеть на самом же пострадавшем в случае чего.

9
Материалы все подряд пользователи могут добавлять?
Если так, то как контролируется их качество и адекватность?
Да, материалы могут все добавлять.
Добавление будет происходить средствами языка XML, а требуемая структура  будет описана в FAQ. Программа же будет иметь алгоритм проверки структуры вводимых данных и, в случаях отхождения, будет оповещать пользователя о неправильных данных, не введя изменения в базу. Так мы решим вопрос со стандартизацией входных данных.
А вот как проверять на адекватность, пока что идей нет. А у вас?
Возможно добавление своих непроверенных материалов будет происходить только в локальную версию... ведь будет существовать возможность откатить базу до дефолтного состояния.

10
Всем доброго времени суток.
Готовлюсь к самостоятельной сдаче OCUP 2, а так же в рамках саморазвития встал вопрос о необходимости создания инструмента для изучения языков.
Прежде чем приступить к анализу технических возможностей и формированию требований к реализации, сформировал UseCase и Activity(немного абстрактный, но все таки процесс работы пользователя с основными функциональными блоками), прошу посмотреть старожилов на возможные нарушения нотации UML. Буду рад свежим идеям для развития детища.
После окончания реализации поделюсь детищем, если будут желающие.
Заранее благодарю.

Страницы: 1