1

Вакансии / Руководитель проекта в Банк

« : 14 Октября 2013, 22:44:56 »

В Банк rsb.ru (Бизнес-блок «Кредитные карты») требуется Руководитель проекта для управления проектами в области CRM и клиентского сервиса и оптимизации банковских технологий

Обязанности руководителя проекта:

• Анализ банковских процессов, инициатив бизнес-заказчика, проблем и оценка целесообразности запуска проекта (подготовка Концепции, обоснование для защиты проекта на Правлении Банка), в т.ч. с ИТ составляющей
• Осуществление проектного планирования: выявление заинтересованных бизнес-подразделений, формирование рабочей группы проекта, оценка сроков выполнения проекта, приоретизация работ и этапов проекта
• Организация и проведение сбора и анализа бизнес-требований к проекту, формирование документа бизнес-требований и согласование их с заинтересованными подразделениями
• Формирование плана-графика проекта и согласование его с заинтересованными подразделениями
• Определение рисков проекта и проведение работ по предупреждению их возникновения
• Осуществление коммуникаций и взаимодействие с вовлеченными бизнес-подразделениями, внутренними и внешними исполнителями проекта, организация и проведение проектных встреч
• Осуществление контроля за проектом на всех стадиях проекта (инициация, анализ, проектирование, разработка, тестирование, внедрение), осуществление контроля за достижением бизнес-целей проекта и реализацией полного объема требований
• Формирование и предоставление регулярной отчетности о ходе реализации проекта в Проектный офис Банка
• Организация и участие в тестировании и опытной эксплуатации проекта, в т.ч. реализованных технологических решений и информационных систем Банка
• Организация работ по вводу проекта в промышленную эксплуатацию, контроль удовлетворенности бизнес-заказчиков проекта и заинтересованных подразделений
• Сбор статистики и анализ информации по факту запуска проекта с целью оценки достижения запланированных результатов
• Формирование предложений по оптимизации бизнес-процессов и технологических решений подразделения и Банка в целом

Требования/навыки/опыт:

Профессиональные:
• Образование высшее техническое обязательно, желательно дополнительное образование в области - экономика/маркетинг/финансы
• Опыт управления проектами по оптимизации и развитию банковских технологий
• Понимание процессов CRM и клиентского сервиса, знание банковских розничных продуктов (кредитные карты, кредиты наличными) и услуг для физических лиц – как плюс
• Знание методологии управления проектами, опыт управления требованиями (сбор информации, выявление и анализ требований/ограничений/зависимостей, приоретизация, описание и документирование)
• Опыт подготовки и ведения проектной документации (концепция, требования, план проекта, проектная отчетность)
• Хорошая эрудиция в ИТ-технологиях, понимание процесса разработки и внедрения информационных систем и технологических решений – как плюс
• Опыт взаимодействия со смежными подразделениями банка (продуктовые подразделения, операционные подразделения, фронт-офис, маркетинг, реклама, ИТ, кредитный центр) – как плюс
• Профессиональный уровень владения MS Office (Word, Project, Excel, PowerPoint,).
• Навыки презентации и переговоров.

Личностные:
• Высокая степень самоорганизации, активность, инициативность, клиентоориентированность, системность.
• Хорошие межличностные, письменные, коммуникационные, организационные навыки, наличие лидерских качеств
• Высокая самомотивация на достижение результата; готовность общаться, убеждать и преодолевать сопротивление

Уровень компенсации: 120 gross + премии

Контакты:
Юлия Дмитриева
Тел. +7(495) 933-53-83 доб. 6988
Моб. тел. +7 (985) 129-98-49

2

Бизнес-анализ и Целеполагание / Требования на автоматизацию

« : 04 Августа 2010, 11:46:49 »

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

Спасибо.

3

Проектирование / Постановка задачи программисту

« : 09 Июня 2010, 13:00:05 »

Доброго дня!

Хочется услышать кто и какой материал использует для постановки задачи программисту?
Проанализировав кучу материала я так и не нашел готового шаблона (документа), грамотного составленного с четким и понятным изложением, описывающим как нужно запрограммировать ту или иную задачу, функцию и т.п.

В своей практике постоянно сталкивался с документами ГОСТ:
1) "Описание алгоритма" (который в данный момент и используется как постановка) и
2) "Описание постановки задачи (комплекса задач)".

В ходе общения с прогерами и аналитиками пришел к мнению, что не очень практичны, долго пишутся, не так трактуются, содержат ненужную информацию или не содержат того чего нужно.

Итог: данные документы разрабатываются на этапе ТехПроекта для "ДАЛЬНЕЙШЕЙ ИХ СДАЧИ ЗАКАЗЧИКУ" (чтобы закрыть этап). Отсюда второй итог: эти документы носят по большому счету формальный характер и в дальнейшем абсолютно не применимы.


Многие с кем общался перечисляют общие документы, разрабатываемые по разным методикам: ТЗ, Техпроект, ЮзКейзМодель, ДатаМодель, SRS, Design Specification и т.д. и т.п.
Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.


Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту? Есть ли у вас готовый шаблон, документ или что-то типа того?


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

Фух...

Понятна ли проблема? Готов услышать ваши ответы.

Спасибо.

4

Примеры / Проектная работа - Коммунальные платежи

« : 22 Января 2010, 17:59:03 »

Господа, добрый день!

Грызу гранит науки и пытаюсь научиться анализу.

Имеется задание по разработке приложения, предназначенного для установки на АРМ оператора по приему коммунальных платежей.
Подробнее см. задание в 2-ух картинках.

Наваял две диаграммы Use Case и Class (тоже в картинках к сообщению).
Покритикуйте пожалуйста, что не верно, что верно и на правильном ли я пути.

Очень хочу научиться.

Спасибо.

5

UML SysML и пр. / Литература для начинающих по UML

« : 12 Октября 2009, 13:37:34 »

Добрый день!

Подскажите пожалуйста, какая существует на сегодня литература для начинающих (для чайников) по UML?
Чтобы простым и внятным языком, по делу (без размазываний) и желательно с примерами.

PS. Есть (была) такая книга "Освой самостоятельно UML за 24 часа" Шмуллера. Является ли эта книга тем, что я ищу?
Посоветуйте где можно достать или найти альтернативу?

Спасибо.

6

Варианты Использования (Use Case) / Вариант использования или ... ?

« : 15 Декабря 2008, 12:06:07 »

Добрый день!

Я начинающий аналитик.
Активно изучаю методики анализа требований, вникаю в эту область.
И одновременно работаю аналитиком на проекте.

Мне попал в руки документ, якобы ТЗ...
В нем присутствует таблица со сценариями.

Выглядит это таким образом:

Функция: Подключение услуги
Сценарий:

1. PPPt получает запрос от NT на регистрацию услуги KLH.
2. В случае если получен запрос на регистрацию услуги пользователю, ранее не зарегистрированному в PPPt, то производится регистрация профайла пользователя и выдается системное предупреждение об автоматической регистрации.
3. При получении запроса на регистрацию услуги пользователю, уже имеющему эту услугу формируется документированное предупреждение системы. Повторная регистрация не производится.
4. PPPt в профайле зарегистрированного пользователя регистрирует запись о подписке на услугу с указанием даты регистрации, после чего обработка прекращается.

Уважаемые эксперты. Поправьте меня пожалуйста...

1. Актером здесь выступает система, внешняя (далее во всем ТЗ именно так). Имеет ли смысл оформлять все в таком виде и дальше, с рисованием юзкейс диаграмм?
2. Очень хочется использовать для такого описания какой-то иной документ, возможно архитектурный или системный (подскажите какой?). Прав ли я? Или оставить все в ТЗ? Просто мне привычнее видеть ТЗ в виде функций, которые удовлетворяют требования пользователя, а здесь - сторонняя система удовлетворяет требования системы.
3. Этот документ (это ТЗ) используется разработчиками как первоисточник, актуальный и понятный по функциям. Может имело бы смысл оформлять не юзкейс диаграммы, а какие-либо другие типы диаграмм, для подобного описания (см. выше 4 пункта)?

Вобщем... большая путаница.