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

×


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

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


Сообщения - Andrey Verbitsky

Страницы: 1 2 3 4 »
1
Тогда, может, проще свой написать? :)

А что - вполне себе стоящая идея!:) "БаБук в картинках"... Или вот - Бабук для чайников.

2
Ответ прост: потому что "голый" eTom не дает тех ответов, которые нужны менеджменту соответствующих компаний.

Ну, за этим им надо или к Библии или к Богу:)

4
Я  тоже не имею возражений

5
Да, я знаю такой способ: захожу в книжный магазин, выбираю нужную рубрику и вручную обрабатываю несколько тысяч наименований.

Эмм... впечатляет... у меня после сотни уже замыливается глаз...

А сколько же времени занимает такой поход (что бы несколько тысяч за раз)? (мой мозг рисует мне страшные цифры, даже если взять по 10 секунд на книгу)
И по какому принципу происходит "первичный отбор наименований"?
И как быть с "граничными задачами" - на стыке областей?

6
Марина, если знаете такой способ - поделитесь - все будут только рады. Я тоже с удовольствием поучусь/послушаю - ибо имею аналогичную задачу.

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

7
вспомнился анекдот про автоматическую парикмахерскую - "это только в первый раз головы у всех разные"

Пять балов!:)

Для сомневающихся - могу предложить самостоятельно поискать ответ на вопрос: Почему, в телекоммуникациях, при наличии(!) eTom нет ни одной компании из организаторов TMForum, чья бы модель работы соответсвовала этому стандарту ;)

8
Присоединяюсь!:)

Удачи, любви, здоровья!:)

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

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

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

10
На сколько я в курсе - бесплатные:)

11
Благодая содействию коллег http://www.raum-7.com/ провожу цикл открытых семинаров в Питере (тематика - анализ, проекты, продукты, люди).

Первый 13-го числа в 20.00.


12
На прошлой работе решали подобную задачу.

Способ был примерно такой, как его описывает Водолей.
Дополнительно могу порекомендовать только как можно более четко определить границы "ядра" и планировать его развитие заранее, что бы другие группы знали - что в нем будет и когда.

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

14
Согласен с коллегами.
Основная задача продовца на данном этапе - понять, почему заказчик купил проект и донести эту мысль до "своих". Т.е. рассказать про мотивацию человека (людей), согласовавшего, утвердившего и подписавшего контракт.

15
Ну не знаю..
Я бы отталкивался от слов "Требуется описать последовательность..."
И сделал, например упрощенную sequence-диаграмму (только основные операции, не детализируя сущности в глубине) в которой использовал Клиента, программу Клиент и программу Банк.
Или UC в любом формате с теми же сущностями.

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

Страницы: 1 2 3 4 »