Добрый день!

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

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

а что такое "практика введения должности аналитиков "?

Какие задачи в системном интеграторе аналитик решает?
Смешение обязанностей аналитика и инженера. Как это устроено в других системных интеграторах?

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

Задачи аналитика зависят не от типа компании, а от конкретного проекта. Попробуйте описать коротко цели Вашего проекта, тогда смогу сказать какие задачи могут стоять перед Вами. Например, если проект по разработке новой системы, то это один набор задач. Если вы внедряете готовый продукт, то и задачи будут немного другие.

Про "хочу красиво" - типичный пример неправильных требований. Почитайте про характеристики правильных требований, например, тут: http://www.uml2.ru/index.php?option=com_content&task=view&id=88&Itemid=48

Про инженерные задачи - приведите, пожалуйста, один-два примера, чтобы понять, что Вы имеете в виду.

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

Учитесь выявлять и формализовать требования. Это не бог весть какой сложный навык.

Задачи аналитика зависят не от типа компании, а от конкретного проекта. Попробуйте описать коротко цели Вашего проекта, тогда смогу сказать какие задачи могут стоять перед Вами. Например, если проект по разработке новой системы, то это один набор задач. Если вы внедряете готовый продукт, то и задачи будут немного другие.

Про "хочу красиво" - типичный пример неправильных требований. Почитайте про характеристики правильных требований, например, тут: http://www.uml2.ru/index.php?option=com_content&task=view&id=88&Itemid=48

Про инженерные задачи - приведите, пожалуйста, один-два примера, чтобы понять, что Вы имеете в виду.

Denis Beskov правильно заметил, надо учиться выявлять требования и учиться их записывать.

Стоят задачи внедрения готовых продуктов и построения систем из множества разных готовых продуктов, как правило аппаратно-программных.

Могу для себя выделить два типа задач по профилю сайта:
1) по абстрактному ТЗ заказчика записать его пожелания и подобрать решение;
2) если необходимо привлекать партнера для реализации, то надо им ставить отдельно задачу - ТЗ для партнера;

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

Как мне кажется тут все в кучу собрано.
Все знают слова "ТЗ" и им подобные, но все равно, все как-то "по русски".

--
мои источники информации:
1) прочитал Элизабет Халл "Разработка и управление требованиями"
2) продолжаю читать Новикова и Иванова "Моделирование на UML"
3) читаю форум и материалы сайта

Дмитрий,

Вы опять все в кучу свалили ....

Я бы выделил вот такие активности
1. Получить запрос от Заказчика, проанализитровать его, собрать и проанализировать дополнительные требования
2. Написать ТЗ, см. ГОСТ 34 - там есть все и функциональные требования и требования к железу и много чего еще, что не нужно выкидывайте
3. Согласовать ТЗ
4. Составить ком предложение и согласовать его
5. Составить договор и подписать его
6. Если нужно то написать ЧТЗ для партнера и согласовть его
7. Доработать если нужно Систему, установить в тест
8. Протестировать
9 Установить клиенту и протестировать
10. Подписать акты сдачи-приемки

Выбирайте то, что делаете Вы.

Дмитрий,

Вы опять все в кучу свалили ....

Я бы выделил вот такие активности
1. Получить запрос от Заказчика, проанализировать его, собрать и проанализировать дополнительные требования
2. Написать ТЗ, см. ГОСТ 34 - там есть все и функциональные требования и требования к железу и много чего еще, что не нужно выкидывайте
3. Согласовать ТЗ
4. Составить ком предложение и согласовать его
5. Составить договор и подписать его
6. Если нужно то написать ЧТЗ для партнера и согласовть его
7. Доработать если нужно Систему, установить в тест
8. Протестировать
9 Установить клиенту и протестировать
10. Подписать акты сдачи-приемки

Выбирайте то, что делаете Вы.

1. Запрос получает менеджер, а вот анализ за мной с ответом на вопрос "можем ли мы это сделать?"
2 и 3. Да, тут мне сложно. Надо написать ТЗ самому себе по его служебной записке заказчика его высокому руководству (без шуток).
4 и 5. Здесь за мной приложение к договору т.е. смета без сумм, хотя и их прикидывать надо, чтобы уложиться в рамки.
6. Это для меня еще вопрос... в каком виде лучше делать.
7, 8, 9. Интегрируются готовые решения, не с нуля написанные, но с соответствующим допиливанием на стыках систем.
10. О да. Это уже же надо понимать на пункте №1,2,3.

Итого прикладываю руку в той или иной степени к 1,2,3,4,5,6,7,8,9,10 пунктам.

Сейчас я стою на пункте 2.

Признаю и понимаю, что в голове каша...
Спасибо за напоминание про ГОСТ34...

Задачи порой стоят далеко не инженерные...

Так правильно, нужен был один человек выполняющий много задач .

А у Вас получается, что Системный интегратор не в информационных технологиях? Что связь?

Запрос получает менеджер, а вот анализ за мной с ответом на вопрос "можем ли мы это сделать?

А если Вы скажете что не сможем, то менеджер и Заказчику говорит что нет?
Я так понимаю что ответ-то на вопрос "сможем" -  Да, а вот как и что хочет Заказчик - уточняет Аналитик или назначенный специалист (с ролью в данный момент - аналитик).

Теперь про разные коммерческие предложения.
Вы и за деньги отвечаете ? Цена это к менеджеру, в Вам техническое предложение, как Вы будете это делать (с учетом тех денег что есть).

Ознакомьтесь с материалом в статье  Образ мышления СА.

Что связь?

Не совсем, но очень близко. ТВ
В какой-то степени пытаюсь понять, как же надо "правильно" работать, а не как мне пытаются навязать.

Я так понимаю что ответ-то на вопрос "сможем" -  Да, а вот как и что хочет Заказчик - уточняет Аналитик или назначенный специалист (с ролью в данный момент - аналитик).

По сути да, именно такую роль приходится играть в начале пути и на протяжении всего пути.

Вы и за деньги отвечаете ? Цена это к менеджеру, в Вам техническое предложение, как Вы будете это делать (с учетом тех денег что есть).

Деньги не моя ответственность, но если бюджет известен, то, как вы заметили, в бюджет надо вписаться.

Ознакомьтесь с материалом в статье  Образ мышления СА.

Спасибо за ценную статью и за комментарии.

Дмитрий, вопрос Ваш довольно обширный, можно книгу написать. Ну а если коротко, то я рекомендую такой план.
1. Собрать материал для обследования из всех возможных источников, включая людей, документацию и существующие системы.  Абстрактного ТЗ заказчика в качестве материала вероятно будет не достаточно.
2. Проанализировать собранный материал, сформулировать и задокументировать требования по категориям: функциональные, нефункциональные, по оборудованию и по инфраструктуре. Функциональные требования в Вашем случае не должны быть очень детальными. Уровень функциональных возможностей будет вполне достаточен. Документировать можно по ГОСТу, если у вас нет внутреннего стандарта.
3. Определить список потенциальных партнеров и разослать им запросы с вашими требованиями. Они должны ответить на вопрос “Какие из указанных требований их продукты будут удовлетворять и как?”
4. Провести сравнительный анализ всех полученных ответов от потенциальных партнеров и представить заказчику результат с исходными данными. Вы можете предложить заказчику решать самому, что лучше выбрать, или высказать свои рекомендации. Ваши рекомендации вкратце могут звучать, например, так: “Рекомендуем продукт X, поскольку он покрывает наибольшее количество требований”. Критерии выбора лучше обдумать заранее.

Надеюсь, мой ответ Вам в чем-то поможет.
Успехов.

Alfia, спасибо за краткий план.
Для меня сейчас любой совет будет полезен. Мне приходится протаптывать дорожку в описанном ключе самостоятельно и, по ощущениям, я нахожусь сейчас между уровнями "понимание" и "знание" искусства анализа. На уровень "применения" знаний только-только выхожу - стимулирует обязательство выдавать результат в ограниченные временные рамки.

Спасибо!

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

http://www.planetahr.ru/publication/2411