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

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

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

hr@jtconsulting.ru

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

Интересно.
Но вот гадаю - это специалисты в области управления проектами?
А Москва большая. Метро наверно Тургеневская?
И что значит свободный график - А ночью с 20.00 до 4.00 можно?

14 пунктов. Хорошо.
Не поясните "Описание требований с применением результатов моделирования" - Это как?

Одним словом нужен аналитик + тестировщик.

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

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

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

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

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

так на всякий случай: встреч - множественное число родительный падеж от слова встреча

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

Как то раз я составил для заказчика наглядную BPMN модель его процессов, связанных с назначением надбавок сотруднику. Ооо, заказчик с интересом их изучил, даже внес коррективы. Когда же по этим процессам было реализовано решение, то заказчик сильно не доумевал, почему ему сделали именно так. Обучение, правда, рулит. (с паяльником)

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

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

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

Вполне приличная у Вас вакансия. Мне бы такую пару лет назад, в кризис... Но "неблагоустроенных" аналитиков, насколько я понимаю, на этом форуме немного. На моей собственной вакансии толковый человек появился только спустя две недели после ее размещения (и то не уверен, что именно с этого форума). Вброс на hh дает более быстрые результаты (но менее информативные, это да).

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

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

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

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