Пытаюсь устроиться на работу Аналитиком - Консультантом 1С. Работодатель в письме просит ответить на 2 вопроса:  

1. Без чего, по Вашему мнению, невозможно приступить к выявлению требований к автоматизированной системе? Почему?  

2. С чего, по Вашему мнению, следует начать выявление требований к автоматизированной системе? Почему?

Дворнику такие вопросы не задют. Иди туда.

1. неадекватные люди.
2. с общения с адекватными людьми.

ИМХО остальное все дело техники...

1. Без мозга.
2. Позавтракать.

1. и 2. с поста на Мисте

мне кажется:
1. без определения цели
2. с определения ЛПР (лица принимающие решения)

(3) Лучший ответ.

(2) тоже верно

(6) Но неполный.

(2)
ответ на п.1 неправильный

кто такой аналитик ?

я так понимаю вопрос про бизнес процессы. собственно ответ на оба вопроса + конечно ЛПР, и результат который хотят получить в итоге.

1. без реально достижимых цен
2. с анализа текущих (реально действующих) бизнес процессов

тут на каждый вопрос эссе можно написать в 5килознаков запросто

без реально достижимых цеЛЕЙ

По ГОСТ 34 выявление требования является первым этапом. То, что этому предшествует - это уже самодеятельность конкретной конторы. И не сфера деятельности архитектора. Процессами инициации проекта РП занимается.

А начинают работы с обследования объекта и обоснования необходимости создания АС.

(0) 1. без запроса от заказчика.
2. с определения целей проекта и ключевых пользователей.

(14) Ну на счет цен тоже все правильно :)

А если так?

1. Без оплаты
2. С выставления счёта

(18) типа берите меня на работу - сначала платите зп, потом приступлю?

(14) Цели выявляются на этапе выявления требований. Ваш Кэп.

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

(18) ИМХО, учитывая размазанность формулировок вопросов в (0), это наиболее правильные вопросы.

(0)расскажите, что это за контора, которая такие вопросы дает при найме консультантов? а вы на хх есть?

(20) >> Цели выявляются на этапе выявления требований.

Глупость ляпнул.
Сначала ставится цель. Потом под эту цель формируются требования (что нужно сделать в ИС для достижения цели).

Пример (с потолка):

Цель (ставит бизнес):
уменьшить время формирования заказа на складе.

Требования (предъявляют пользователи):
- система должна содержать информацию о текущих остатках, о зарезервированных остатках, о предстоящих поставках (пополнениях остатков).
- система должна позволять формировать заказы с учетом имеющихся данных

Функциональные требования:
- АРМ приемщика (с полным описанием)
- АРМ завскладом
- АРМ менеджера, формирующего заказы
....

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

мне кажется тут цель = требование.

Какие у заказчика требования? Чтоб быстро работало?
Чтоб хоп-хоп и отчет готов?

Цель (обычно): у нас все плохо, а хотим хорошо.

Я бы ответил так:

1. Без плана обследования
2. С опроса кей юзеров.

(23) Вы про глупости разработчикам ГОСТ 34 рассказывайте, а не мне.
...
Стадия 1, этап 1.1 Обследование объекта и обоснование необходимости создания АС.
...

(25) я один раз обследовал и обосновал отсутствие необходимости создания АС )) я плохой продавец)

(26) Таки да, результатом может быть и обоснование отсутствия необходимости.

(26) да я вот тоже раньше себя винил в таких вещах - где можно денег снять - объяснял что людям это не нужно. Со временем это дало плюс - приток клиентов по рекомендациям + репутация..

о, прикольно мне такое же письмо прислали

(25) Обследование начинается тогда, когда цель уже сформулирована.

С чего начинается любой проект? Вам звонит заказчик и говорит: "Слушай, Джинн , нам тута нада замутить расчет себестоимости на производстве, начисление з/п работягам и дать менеджерам-торгашам инфу о запасах".

Всё. Цель поставлена. И только после этого (когда цель УЖЕ поставлена) ты идешь к заказчику и начинаешь выяснять конкретные требования, которые позволят достичь поставленных целей. И без этих целей любое обследование - это глупость несусветная.

(23)бизнесс потребность, потом цель
всегда так было

(29) Я бы поостерегся идти в контору, где такие неоднозначные вопросы задают на собеседовании. Как хочешь, так и понимай их и как хочешь, так угадывай что от тебя хотят услышать.

(30)>>Слушай, Джинн , нам тута нада замутить расчет себестоимости на производстве, начисление з/п работягам и дать менеджерам-торгашам инфу о запасах

ни разу не цель

)))
http://consulting.1c.ru/articles-view.jsp?id=100
"1. Цель проекта

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

http://www.yaplakal.com/forum7/st/125/topic1322798.html?hl=#entry45395071

(33)+ цели должны быть достижимы, измеримы и конечны

(34)про ресурсы забыл

(31) Это вопрос терминологии.
бизнес-потребность - это и есть цель.
Не может быть цель "Создать справочники Номенклатура и Контрагенты".

(33) Это и есть цель. Под эту цель рисуются требования.

(37)бизнесс потребность это хотелка
цель всегда достижима, измерима и конечна

(36) "Это не я!"(С)))
Там же см.
"4. План и бюджет"

(33) по аналогии семи "почему?" к этому можно применить семь "зачем?"

(0)эта вакуха на Аналитика
у менеджера по кадрам спросил: вам РП нужен?, её ответ нет, нужен Аналитик

так что нужно рассуждать как аналитик

(32) нормальные вопросы.
а если будет обозначен должностчне обязанности/круг того что должен делать
- консультант
- архитектор
- РП
- ..
..причем не  в частной конторе, а для всех - тогда можно и более "конкретно" отвечать. а то у каждого свое понимание что такое консультант/аналитик/рп

(30) Коллега, мы тут может долго свое понимание озвучивать и свой опыт, но IMHO на собеседовании спрашивают знание стандартов.

Меня учили, что инициация проекта:
- Разработка Устава проекта
- Определение заинтересованных сторон

(43) а "Определение заинтересованных сторон" разве не является частью "Разработка Устава проекта" ?

(43) знание стандартов говоришь?

банально рассмотрим IDEF-0 для нее нужно
1. входящие данные (это и есть цель, без нее все превращается в бесконечность)
2. управление (это ключевые сотрудники, без них внедрение не возможно)
3. ресурсы (это исполнители)

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

(43) Где учился, если не тайна? Я серьезно, без прицеливания на какой-то дальнейший стеб.

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

(46) СПб Институт Проектного Менеджмента. Но "учился" - это громко слишком. Курсы проходил по управлению проектами на базе PMBoK. Даже всякие там баллы копил на PM, тесты безумные сдавал, но как-то жизнь подергала по разным конторам и проектам и забросил. Жаль конечно :(

(45) IDEF-0 это ж тупо блок-схема

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

(49) да, это нотация описывающая БП, любой этап проекта (в том числе и сабж) это отдельный БП....

поверь, что что-либо делать без входящих_данных+управления+ресурсов  невозможно.. в том числе и что-то анализировать, разрабатывать проекты и т.д. без этого невозможно !!!

(45) "Входящие данные" не есть цель. Ваш вывод является безосновательным. На входе может быть цель. Но может и не быть ее. Может быть масса данных, не являющихся целью.

(50) спасибо кэп! )

для любого действия в этом мире есть вход, выход, ресурсы и управление

(all) коллеги давай не будем путать проектное управление и бизнесс процессы

поиск по строке с нумером 1 в яндексе вывел на обсуждение
http://www.yaplakal.com/findpost/45395071/forum7/topic1322798.html

это ссылка на конкретное сообщение.

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

(0) спистили с какой-то методички и теперь пытается оценить - попадете в ответ или нет

(55) ну вот пост со ссылкой как раз об этом.

(56) + да тут даже не читая все понятно...

а наши корифеи уже копья ломают...


не найдет "хрюша" у себя в подстрочнике буквы  IDEF-0 или PMBook - пойдет аналитик как непригодный

(57) ну и хорошо, зачем в такой компании работать?

(58) затем, чтобы зарабатывать деньги.

(10) человек, который смотрит за "а налито ли"

(58) дык может там

1. работа нужна срочно
2. неплохие условия
2. там все не так плохо если пробиться через первичный слой глупостей людей сидящих "на входе"

(59) а типа больше заработать негде?

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

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

Что характерно, через эту компанию прошло оооочень много молодых людей. Ну как молодых, не старше 35 лет.

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

>кто-то же нанимал этот первичный слой, и он может оказаться еще хуже

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

рано еще на всей конторе крест ставить - если игра конечно свеч стоит

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

Формально входами процесса разработки Устава являются:

1 Описание работ проекта
2 Экономическое обоснование
3 Контракт
4 Факторы среды предприятия
5 Активы процессов организации

(68) экономическое обоснование)))

в твоей практике оно хоть раз было?

(69) на нескольких работодателях (когда я - фикси) было, а когда у клиентов-заказчиков - ни разу

(69) но оно зачем было нужно? для удовлетворения запросов последующих аудиторских проверок, насколько я помню и передачи отчетов "на верх"

(69) В ИТ-проектах - нет, ни разу. Но стандарт универсальный для любого проекта. Хоть для строительства завода, хоть для внедрения информационной системы.

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

(5) в яблочко :)

1. Цель, бла-бла-бла.
2. Список шагов к цели, бла-бла-бла.

(0)
1) Без цветовой дифференциации штанов
2) с двух ку господину ПЖ

(0)

1. Без аванса/предоплаты
2. С получения/выбивания аванса/предоплаты

(22) Да, я есть на хх: https://m.hh.ru/applicant/resume/4d231f05ff019a9b160039ed1f364746733332

(77)
> АНО Международная Академия Биржевой Торговли "Форекс Клуб"
Расскажи про биржу. Работаешь ли там?

(68) а Вы уверены, что работа "Аналитиком - Консультантом 1С" включает в себя "процесс разработки Устава проекта" ????

задачи аналитика какие?

давайте разберемся, во первых аналитики бываю разные, есть
1. бизнес аналитики, их задача сказать как лучше организовать БП компании что бы компания была более эффективна. Тут аналитик вообще не имеет отношения к процессу автоматизации, и ни какие "описания работ по проекту" его вообще не касаются....
2. системные аналитики, их задача сказать что надо автоматизировать а что нет. Реально он пытается согласовать требования бизнеса (уже сформированные) с возможностями автоматизации, именно тут он и порождает всякие обоснования экономической выгоды и т.д., То есть на входе у него Цель + Средства а на выходе детализированные требования к системе которые потом архитектор вместе с РП превращают в ТЗ и паспорт проекта....
3. прочие аналитики (рынка, PR и т.д.)


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

А все что ты описал - это удел РП....

(0) 1. без целей, ганиц и объекта автоматизации
2. с определения цели, границ и объекта автоматизации

(79) Выше я именно об этом писал - аналитик начинает работу с выявления требований. Перед этим есть только работа РП.

(80) Это и выясняется на этапе выявления требований :)

(0)

Вопросы общие, намекающие то ли на ГОСТ34, то ли на классические труды по разработке требований к ПО

Например, можно сказать так:

1. Выявления бизнес-целей
2. Определение заинтересованных лиц

Думаю, если вдумчиво просмотреть Карла Вигерса - этого будет достаточно для дискутирования на тему аналитики требований к ПО.

Также аналитики еще рекомендуют Дина Леффингуэлла

по стадиям создания АС, согласно ГОСТ 34.601 дела выглядят так (группировка по проектным методологиям):

Предпроект:
1. Формирование требований к АС
2. Разработка концепции АС

Планирование
3. Техническое задание

Принятие проектных решений (проектирование/создание технических спецификаций)
4. Эскизный проект
5. Технический проект

Разработка самописного ПО, кастомизация и документация
6. Рабочая документация

Комплектация и развертывание АС
7. Ввод в действие

Эксплуатация и поддержка
8. Сопровождение АС