Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
аналитик такой же как все???Да. С одной стороны - да, он отличается от рабочего на конвейере. Хотя и рабочие иногда выдвигают настолько полезные и проработанные идеи и рац. предложения, что диву даёшься. С другой стороны - ничего исключительного. Обычный инженер. Ощущение "исключительности" и "элитарности" - ложное, как и во всех остальных случаях. За редчайшим исключением.
нет ну понятно дисциплина, хотя почитайте последние вакансии на hh, им всем готовы дать по дивану для расслабиться, а не лежать и спортинвентарь чуть ли не в кабинете...обратитесь к опыту зарубежному...Дисциплина - не самоцель, а способ организации достижения результата рабочей группой. Когда группа становится командой, в ней всегда развивается самодисциплина. Например в том, чтобы:
одаренный аналитик - это необычный сотрудник, и во многих организациях это просто тень, не всегда и понятно рядовым и линейным руководящим сотрудникам, что он делает и кто он.Ага, не признанный всеми везде гений, как же.
нередко при приходе аналитика в организацию сами по себе баласты (пустые должности) заявления пишут, и это необъяснимо, т.к даже человек не приступил даже к обязанностям и обычно он подчиняется все же тем кто стратегию развития компании решает.Если стратегия развития компании далека от тех, кто будет обязательства брать и планировать, проектировать, код писать, тестировать, продукт рекламировать и продавать - она так и останется на бумаге, в самом лучшем случае её реализуют на оценку "для галочки". Стратегия должна с самого начала быть для них близкой, а для этого её нужно создавать при их участии. Чтобы каждый знал, что конкретно ему в соответствии с этой стратегией делать.
Да. Но в довольно коротком и обозримом времени. Через месяц его работы на проекте людям должно уже стать легче понять, что нужно сделать. Даже если аналитик просто фиксирует запросы на доработку и помогает отвечать на вопросы "как пользователю нужно, чтобы вот в этом месте работало", при этом ещё слабо разбираясь в предметной области, не создав полные целостные [логико-математические] модели системы и организации, в первую очередь в своей голове.
его положение сильно зависит от целей и задач, а его основная оценка - это результат...во времени!
но опять, мы о персонаже стереотипе или все же о том, у которого в голове более двух измерений?Голова и измерения в ней - инструмент. Без хорошо подобранного инструмента качественно сделать работу очень трудно. Но рабочему платят не за то, что у него на поясе висят молоток и клещи, а за результат работы, которую он с их помощью делает.
.
<...>
поэтому процессы у них могут даже называться одинаково (и более того, иметь одинаковые в общем-то цели), но при этом будут отличаться содержанием функций.
1. Оценка требований продукт-менеджером и менеджером проекта относительно общего качества и эффективности продукта на рынке после разработки продукта.Для менеджера продукта - системные требования отвратительные: в них не вошла и половина того "турбулентного потока сознания", который он выплеснул на системного аналитика. Ну и что, что это потому что архитектор с ведущим разработчиком сказали, что реализовать невозможно.
2. Отзывы ключевых клиентов о реализации процесса управления требованиямиДля ключевого клиента требования отвратительные: его "хотелки" не будут реализованы сейчас же, как он хотел! Клиент этим не удовлетворён, ну и что, что он сменил "элитную" поддержку на самую дешёвую, и хочет сделать из АСУ склада систему SCADA. Да к тому же он же написал "сделайте, чтобы мне было хорошо, нажимаешь кнопку и ага!", чего уж непонятного, а этот глупый системный аналитик зачем-то расспрашивает...
3. Показатели удовлетворенности клиентов
4. Соблюдение или превышение планов разработки требований, ограничений по ресурсам и качественных целейПлан не соблюли! Хотели сделать за неделю 20 UC на 15 страниц, а пришлось 3 месяца делать 1500 требований и UC на 2000 страниц. Ну и что, что оказалось, что это - естественная сложность предметной области, помноженная на то, что решили делать подробное ТЗ для аутсорсеров...
5. Контроль расползания требований, связанный с пропущенными требованиями и просачиванием "неформальных" требований в проектТребования "расползлись", разработчики всеми правдами и неправдами добились того, что в SRS прошло их представление о том, что нужно Заказчикам. Ну и что, что именно благодаря этому продукт имел оглушительный успех.
<...> Подскажите, пожалуйста, внутренний корпоративный портал является автоматизированной, информационной или автоматизированной информационной системой? Как можно это обосновать?<...>IMHO, в большинстве случаев, это просто информационная система. Хранит много справочных данных, даёт к ним доступ. CMS. Ничего толком не считает и не автоматизирует.
как называется интерфейс руководителя на портале, в котором он может смотреть отчеты, статистику и т.п.? Может ли он называться АРМ?<...>Отчёты о чём? Статистика чего? В большинстве случаев, "портал" - не СППР, не MIS. Если это АРМ, то что оно автоматизирует?
<...>Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текстНиже оригинал объявления ...<...>
. Так вот, надо рассказать этому пользователю-администратору-программисту, как ему удовлетворить его потребности при помощи существующей, великой, могучей, до конца не познанной системы, созданной, чтобы получить просветления, а не ради удовлетворения земных нужд. Причём лучше описать языком Пришвина и снабдить занимательными цветными картинками а-ля "Мурзилка".Всем добрый вечер. Передо мной стоит задача формирования задания на разработку OLAP-отчета <...> нет четкого представления о содержимом этого документа<...>Начните с того, на какие вопросы хочет получить ответ пользователь при помощи "OLAP-отчётов". Дальше, если нужны именно отчёты, согласовать с заказчиком список и содержание отчётов. Возможно "OLAP" и "ad-hoc" на самом деле не нужно, а нужно ввести пару параметров в условии фильтрации, вывести таблицу и строчку "итого". Это и опишите.
