Здравствуйте, dmz, Вы писали:
dmz>Ну я не "онаним". DOORS изучали, когда выбирали RMS для конторы, где я работал. Мое мнение о нем полностью совпадает с мнением онанимов. Типичное Bloatware за совершенно неадекватные деньги. Кстати, руководство склонялось к его внедрению, это был один из поводов для меня расстаться с этой компанией.
Уже радует что не анонимно ... но тем не менее малоинформативно. На какой позиции вы там работали? Менеджер, аналитик, разработчик? Занимались ли созданием документации требований? Какие использовали стандарты на документацию требований? Какие именно недостатки инструмента вы обнаружили? Какой до этого компания использовала инструментарий? Какова зрелость процессов разработки ПО в компании (или это Люксофт
)? Какого рода проекты (инхаузеры или аутсорсеры)? ... Была ли практика одновременной работы нескольких аналитиков над требованиями? Документация требований в печатном виде формально подписывалась у заказчика? Как именно планировали использовать инструмент? Территориально это где Москва, Питер, др. регион?
Ответив на эти вопросы уже можно будет видеть более-менее аргументированную точку зрения. Именно аргументация интересна большинству участникам форума думаю. ... А пока, к сожалению, только эмоции
.
B>На какой позиции вы там работали? Менеджер, аналитик, разработчик?
Как это влияет на качество продукта?
B>Занимались ли созданием документации требований?
Да
B>Какие использовали стандарты на документацию требований?
Внутренние. Удовлетворящие SOX. Не ГОСТ. Как это влияет на качество продукта?
B>Какие именно недостатки инструмента вы обнаружили?
Громоздкий, неудобный, убогий интерфейс, столь же убогий внутренний скрипт, совершенно больная
политика производителя, максимально затрудняющая даже ознакомление с продуктом. Собственно, достаточно
было бы последнего пункта. Запуск ознакомительной копии представлял собой целый квест — это вкупе с документацией мне хватило.
B>Какой до этого компания использовала инструментарий?
Как это влияет на качество продукта?
B>Какова зрелость процессов разработки ПО в компании (или это Люксофт )?
Как это влияет на качество продукта?
B>Какого рода проекты (инхаузеры или аутсорсеры)? ...
Лично мои были аутсосными, но были и те и другие. И?
B>Была ли практика одновременной работы нескольких аналитиков над требованиями?
Проекты самые различные. Не меньше сотни. Везде по разному.
B>Документация требований в печатном виде формально подписывалась у заказчика?
В печатном это необязательно, заказчик внутренний. Но цикл согласования документов в
электронном виде был.
B>Как именно планировали использовать инструмент?
Для управления требованиями.
B>Территориально это где Москва, Питер, др. регион?
Как это влияет на качество продукта?
B>Ответив на эти вопросы уже можно будет видеть более-менее аргументированную точку зрения. Именно аргументация B>интересна большинству участникам форума думаю. ... А пока, к сожалению, только эмоции
Продукт неудобен в использовании и отличается крайне параноидальной политикой производителя, причиняющий неудобства пользователям, а так же стоит чрезмерно много для своего качества. Это впечатление, которое сложилось от опыта его изучения, включая лекции представителей поставщика этого продукта, плюс изучение документации, плюс попытки пробного использования. Этого мне хватило, что бы сделать заключение для себя. Писать на этот продукт подробные ревью в мои планы тогда не входило, извините.
Здравствуйте, dmz, Вы писали:
B>>Какие именно недостатки инструмента вы обнаружили?
dmz>Громоздкий, неудобный, убогий интерфейс, столь же убогий внутренний скрипт, совершенно больная
dmz>политика производителя, максимально затрудняющая даже ознакомление с продуктом. Собственно, достаточно
dmz>было бы последнего пункта. Запуск ознакомительной копии представлял собой целый квест — это вкупе с документацией мне хватило.
B>>Какой до этого компания использовала инструментарий?
dmz>Как это влияет на качество продукта?
B>>Какова зрелость процессов разработки ПО в компании (или это Люксофт )?
dmz>Как это влияет на качество продукта?
B>>Была ли практика одновременной работы нескольких аналитиков над требованиями?
dmz>Проекты самые различные. Не меньше сотни. Везде по разному.
B>>Как именно планировали использовать инструмент?
dmz>Для управления требованиями.
dmz>Продукт неудобен в использовании и отличается крайне параноидальной политикой производителя, причиняющий неудобства пользователям, а так же стоит чрезмерно много для своего качества. Это впечатление, которое сложилось от опыта его изучения, включая лекции представителей поставщика этого продукта, плюс изучение документации, плюс попытки пробного использования. Этого мне хватило, что бы сделать заключение для себя. Писать на этот продукт подробные ревью в мои планы тогда не входило, извините.
По поводу "Как это влияет на качество продукта?". Поясняю. Качество -- это в первую очередь соответствие определенным тем или иным образом критериям. В данном случае, оценка возможности использования инструмента определяется критериями, которые диктует сложившаяся практика работы с требованиями в организации. Она может быть разной. В частности, вы сказали что планировали использовать инструмент "Для управления требованиями". Только для управления? А для разработки их не планировали использовать
? Несомненно, накладывается еще и один момент, связанный с тем, что подразумевается в данном конкретном случае под "управлением требованиями". Я в своей практике встречал и попытки использования инструментария RDM для целей Issue Management. И люди были искренне уверены что это и есть "Управление требованиями". Так что по такому ответу мне все равно достаточно сложно судить. Но, несомненно, я не в праве требовать от вас большего
.
С другой стороны, хотелось бы обратить внимание на тот факт, что коль скоро вы занимались как аналитик разработкой требований, то наверняка имеете предстваление о критериях "хороших требований". Наверняка вы не писали в вашей документации фраз типа "продукт должен иметь дружественный пользовательский интерфейс", ибо это имеет мало шансов на ОБЪЕКТИВНУЮ проверку. В то же время говорите что "Продукт неудобен в использовании". В каком использовании, в каком качестве? Что именно неудобно, увы осталось за кадром.
Лично у меня сложилось впечатление, что основным критерием является именно цена, а точнее соотношение "цена"/"ваше представление о том какой вам нужен продукт". Вот об этих критериях было бы интереснее всего услышать.
