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

×


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

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


Сообщения - jtconsulting

Страницы: 1 2 »
1
Разница принципиальная и существенная, особенно сильно это заметно, так сказать, "на глаз" при внедрении (не разработке) систем.

Мы не флудим, а дискутируем. Для данной темы это даже хорошо, поскольку она все время в топе.

2
Цитировать
Тогда это "больше СА" чем "БА".
О чем и речь!

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

4
Цитировать
Хоть Заказчик и любит комиксы больше, чем скучный текст (особенно цветные, а-ля eEPC), но если он  в принципе не хочет копаться в промежуточных продуктах жизнедеятельности Исполнителя, всерьез он этого делать не будет.

Да кто же спорит )), но заставить его посмотреть кртинки проще, да и лучше иметь хоть какую-то инфу, чем не иметь никакой (что гарантировано при отсутствии диаграмм) :)).

С картинками UI дела лучше, но лишь частично, поскольку они не дают покрытия (этим полноту не проверить) ибо пользователь будет заниматься только кнопками, вкладками и их расположением (в лучшем случае функциями, отрабатываемыми по нажатию кнопок, НО лишь данного окошка). А вот диаграммы в данном случае идеальный (по отношению ко всем остальным) инструмент для проверки полноты (который в случае полного отсутствия дисциплины у заказчика, конечно также почти ничего не даст, но почти ничего, лучше, чем совсем ничего :))).

Что касается подписи под ТЗ, то это бесспорно дело хорошее, НО если это гос заказчик, то может случиться, что вас вынудят БЕСПЛАТНО!!! переделывать, а если не гос., то есть шанс что к вам более не обратятся (имеется ввиду данный конкретный заказчик). Так что подпись (в отсутствии фид бэка по ТЗ) хорошо в краткосрочной перспективе и скорее всего плохо в долгосрочной.

5
суть дела не меняет... нужен хороший специалист

6
Управление проектами тут и рядом не валялось, как и было написано и повторил Юрий нужен аналитик + тестер в одном флаконе (причем упор именно в аналитика, тестеру достаточно уметь тестировать "черный ящик").

Не Тургеневская)))

Можно в любое время, если нет встречь с членами проектной команды (как со стороны заказчика, так и со стороны исполнителя).

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

7
Неужели никому не интересно?

10
 - Проведение обследования с целью выявления и уточнения бизнес требований и требований пользователей к разрабатываемому ПО (фактически необходимо описать работу уже существующего ПО, границы функционала очерчены);
 - Формирование технического задания на разработку программного обеспечения;
 - Описание требований с применением результатов моделирования (формирование документации с использованием диаграмм UML)
 - Отслеживание изменений требований в ходе разработки и сдачи ПО заказчику;
 - Тестирование технического задания на полноту, непротиворечивость, однозначность, проверяемость;
 - Подготовка сценариев функционального тестирования;
 
Общее
 - Умение работать в команде;
 - Внимательность к деталям, усидчивость;
 - Ответственность, пунктуальность;

Занятость:
Плановая длительность работ 1 месяц, возможна удаленная работа. Плановое начало проекта с 30 апреля. Сроки и длительность могут немного измениться.

Оплата:
Оплата по факту в размере 85К рублей на руки, возможен вариант оплаты раз в две недели до половины суммы, остальное по факту. При высококлассной работе возможна выплата премии в размере до 15К рублей (на наше усмотрение :)).

Дальнейшее сотрудничество:
По результатам проекта возможно дальнейшее сотрудничество, занятость на других проектах и/или зачисление в штат.

jtconsulting@mail.ru
hr@jtconsulting.ru

11
 - Проведение интервью с Заказчиками с целью выявления и уточнения бизнес требований и требований пользователей к разрабатываемому ПО;
 - Формирование и четкое очерчивание границ продукта.
 - Формирование технического задания на разработку программного обеспечения;
 - Описание требований с применением результатов моделирования (формирование документации с использованием диаграмм UML)
 - Отслеживание изменений требований в ходе разработки и сдачи ПО заказчику;
 - Тестирование технического задания на полноту, непротиворечивость, однозначность, проверяемость;
 - Функциональное тестирование (ручное) программного обеспечения на соответствие техническому заданию;
 - Участие в подготовке и настройке стендов для тестирования;
 - Подготовка сценариев функционального тестирования;
 - Написание пользовательской документации на разрабатываемое ПО;
 - Проведение приемочного тестирования разработанного продукта на соответствие техническому заданию;
 - Ревью пользовательской документации на соответствие разработанному ПО;
 - Разработка программ и методик испытаний, необходимых к прохождению для сдачи ПО заказчику;
 - Выявление любых проблем при работе с продуктом, включая удобство использования

Общее
 - Умение работать в команде;
 - Внимательность к деталям, усидчивость;
 - Коммуникабельность;
 - Ответственность;

Белая зарплата 70 - 90К рулей (после уплаты налогов) в месяц. Свободный график работы (иногда возможен удаленный режим). Работа в Москве. Очень редко возможны командировки по России (по согласованию).

hr@jtconsulting.ru

12
ida,
Цитировать
... хотя тоже забавно - каждые полгода открытия...
это вы о чем?

13
дык, я ж про качество и написал. Вот же "Они просто думают сразу о том, как это будет реализовано, а не про то "что, кому и зачем нужно"". Т.е. их проблема в том, что они к работе подходят с точки зрения реализации (можно это сделать и если да, то как, а если нет, то почему) и это сильно мешает делу. Они постоянно пытаются написать или учесть в требования архитектуру приложения и/или структуру БД и т.д.

Опять же НЕ все такие, но большинство. Остальные, в большей степени, лишены указанного недостатка и поэтому при прочих равных из них приемлимые :)))) аналитики получаются чаще. У не программистов так сказать взгляд на требования к ПО незамутненный  ;D. "Плохость/хорошесть" аналитиков я оцениваю по результатам их работы:
1. Качество документации (и контент с полнотой, однозначностью, непротиворечивостью и т.д. и т.п. и структура + оформление контента)
2. Коммуникации с проектной командой (и заказчик и исполнитель, тут и удовлетворенность и прозрачность и язык  и т.д. и т.п.)

Кстати не встречал аналитиков из МП... Я бы даже сказал, что странно это...

PS может вынести это обсуждение в другую тему? А то мы тут немного оффтопом увлеклись - это раз, и мало людей смотрит на нашу вакансию  ;D ;D ;D, что сейчас топиком ниже в списке - это два.

14
bas, я ж не говорю что все поголовно аналитики, вышедшие из программистов плохие. Я лишь констатирую статистику. Они просто думают сразу о том, как это будет реализовано, а не про то "что, кому и зачем нужно"...

15
Виталий Григораш

ИМХО из програмистов получаются плохие аналитики (я вообще против того чтобы у аналитика было программистское прошлое :) ). Из тестеров, тех. писателей и консультантов (имеются ввиду специалисты по какому либо продукту, ну ERP например) аналитики много лучше.

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