Перейти к содержимому

Английский для тестировщиков
онлайн, начало 7 декабря
Chrome DevTools: Инструменты тестировщика
онлайн, начало 10 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря
Фотография

QA в инженерных отраслях.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 35

#1 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 06 мая 2007 - 18:29

Вот давно хочу выяснить для себя, но никак не найду времени. Может быть кто-то исследовал уже этот вопрос. Действительно ли QA в смысле ISO 9000 широко применяется, отжирает себе щедрые куски бюджетов и приносит зримые плоды, например в проектном строительстве или при разработке летательных аппаратов? Для меня как-то странно было бы свыкнуться с мыслью, что соотвествующие конторы вместо того чтобы выполнять инженерные изыскания, направленные на то чтобы здания не разрушались, а самолёты не падали на глазах у удивлённой публики, развивают у себя процессы типа "ответ на жалобу удивлённой публики" или там "обеспечение обратного следа от поломки до инженера её спроектировавшего".
Если такое есть, то может быть кто-то поделиться названиями основных процессов?
А если ничего такого нет, а методологии QA пригодны только для улучшения массового производства (насколько я помню классику, изначально это была военная форма), то как так получилось, что в ИТ пытается складываться обратная ситуация? Всевозможные "процессологи" постоянно всеми правдами и, что особенно огорчительно, неправдами, пытаются установить примат своей области знаний над всеми остальными, при этом даже не обладая никакой заметной компетенцией в том что они собираются улучшать.

Далее следует субъективное мнение.
---------------------------------------------

Лично у меня вообще сложилось впечатление, что весь этот хвалёный процессный подход это нечто вроде отсоса благ в виде денежных средств из всяких туземных экономик, в виде: "Получи лишних сто баксов, за то что поставишь своих ближних на тысячу". Вроде форекса или тех же лицензий на некоторые виды софта.
Или может быть это у меня атавизмы "шарашного" сознания помноженные на пионерские знания в области качества?
Особенно хотелось бы услышать "голос Америки" по этому поводу.
  • 0

#2 Yury

Yury

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Yury

Отправлено 06 мая 2007 - 22:03

На все ваши вопросы я могу дать один и тот же ответ "It depends". :clapping:
Все условия применимости этих подходов описать в коротком сообщении невозможно, поэтому приведу лишь пару примеров.

Пример 1. Для маленькой начинающей фирмы, разрабатывающей новый продукт для открытого рынка (например начинающие Google и Microsoft), все эти пляски с бубном от посторонних организаций скорее всего не нужны.

Пример 2. Для аутсорсинговой организации, стремящейся привлечь новых клиентов, например из фармацевтической или атомной промышленности, сертификация их процессов (например CMM) может быть полезна.
  • 0

#3 melan

melan

    Новый участник

  • Members
  • Pip
  • 14 сообщений
  • ФИО:Дима Меланченко

Отправлено 12 мая 2007 - 13:25

Я немного знаком с процессами, которые применятся в местной конторе для разработки далеко леталельных аппаратов, т.е. тех, которые улетают за пределы атмосферы. Так вот, в этой котроре деятельность в области QA, а именно разработка процессов, их верификация и оптимизация, началась еще лет 50 назад. Т.е. никто, совершенно никто не спорит с тем фактом, что изделия или их прототипы нужно многократног испытывать (тестировать), что нужно разрабатывать тех. задания и спецификации на изделия (требования) и что нужно проводить многоуровневый контроль всех деталей и материалов (ревью).

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

На подобных предприятиях чаще всего нет отдела с названием QA, однако там есть отделы/люди занимающиеся поддержанием системы качества на должном уровне. По моим наблюдениям - это ответственность руководителей любых уровней.

Ну а на кустарных производствах ничего подобного нет. Да и нужно ли оно там?!

Если говорить про QA при разработке софта, то нужно просто понять к какому уровню относится та или иная разработка. Если это маленький кустарный проектик, то какой смысл там заморачиваться с QA. Все-таки эти люди не зарабатывают для конторы никаких денег, они только позволяют их экономить.
Ну а если разработка относится к серьезному производству с высокой стоимостью каждого бага, то тут нужно либо создавать свой отдел QA, либо привлекать экспертов со стороны.
  • 0
Если хочешь поработать - ляг поспи и все пройдет.

#4 Igor eM

Igor eM

    Новый участник

  • Members
  • Pip
  • 9 сообщений

Отправлено 29 мая 2007 - 18:28

B]Yury[/B]ля маленькой начинающей фирмы, разрабатывающей новый продукт для открытого рынка (например начинающие Google и Microsoft), все эти пляски с бубном от посторонних организаций скорее всего не нужны.

Имея неплохой опыт работы в небольшой (меньше 100 но больше 60 человек вовлеченных в основной процесс) компании занимающейся разработкой собственного ПО могу сказать однозначно - Стандарты QA нужны как воздух.

Отсутствие стандартов может привести к следующим организационным проблемам:
1. Срыв сроков.
2. Плавающее качество ПО.
3. "Заточенность" ПО под конкретных разработчиков.

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

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

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

P.P.S. В тех же Google, Apple ... etc на начальном уровне QA осуществлялся за счет добросовестности и ответственности создателей (имхо).

P.P.P.S. В ряде случаев можно обойтись без QA за счет грамотной маркетинговой и адвертайзинговой политики - но такое положение может быть очень шатким :)
  • 0

#5 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 29 мая 2007 - 19:38

Стандарты QA  нужны как воздух.

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


Немножко цитат из peopleware:

Что касается проблемы неустойчивых продуктов, то почему бы не признать, что такая проблема существует даже в случае следования жёстким стандартам? Существующая стандартизация привела к документальной стабильности продуктов, но никак не к осмысленной функциональной стабильности. Иначе говоря, стандартизация в основном затронула бумажную работу, связанную с продуктами, но не сами продукты. Если же бумажный вариант проекта немного отличается от стандартного, то серьёзных неудобств это не вызовет.
...
следует отметить, что великий триумф стандартов в современном мире — это практически всегда успех стандартных интерфейсов.


  • 0
Andrey Yegorov. Изображение

#6 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 30 мая 2007 - 07:06

Действительно ли QA в смысле ISO 9000 широко применяется

Софистика в вопросе. QA <> ISO только и всего.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#7 Igor eM

Igor eM

    Новый участник

  • Members
  • Pip
  • 9 сообщений

Отправлено 30 мая 2007 - 17:02

dlg99
К чему это?

Стандарт - это инструмент организации производственного процесса и не более. Это не самоцель и не панацея от всех бед.

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

В противоположность написанному выше - возможно непонимание пишущими целей поставленных перед указанными в примере компаниями.
  • 0

#8 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 мая 2007 - 18:01

Действительно ли QA в смысле ISO 9000 широко применяется

Софистика в вопросе. QA <> ISO только и всего.

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

Ну не знаю уж, насколько это относится к современным версиям, но вот читаю в энциклопедии: стандарт ISO 9001:1987 назывался Model for quality assurance in design, development, production, installation, and servicing.
  • 0

#9 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 30 мая 2007 - 19:45

Действительно ли QA в смысле ISO 9000 широко применяется

Софистика в вопросе. QA <> ISO только и всего.

Ну не знаю уж, насколько это относится к современным версиям, но вот читаю в энциклопедии: стандарт ISO 9001:1987 назывался Model for quality assurance in design, development, production, installation, and servicing.

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

ISO - стандарт, суть - бумага в которой написано как можно достичь чего-то, именно модель, которая говорит как можно делать определённые работы. Распечатайте её и положите на полку - в компании станет больше порядка? QA это активность, а не стандарт, которому можно соотвествовать или нет. Набор действий, а не предписаний - я уже просто не знаю как ещё сказать.

Если оторваться от слов про QA и переформулировать ваш вопрос насколько широко применяются Стандарты для достижения Качества продуктов - вопрос становиться совершенно другим и тут мой ответ как у большинства в топике: "зависит от...".
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#10 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 30 мая 2007 - 19:46

Стандарт - это инструмент организации производственного процесса  и не более. Это не самоцель и не панацея от всех бед.

+1! :friends:
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#11 QArer

QArer

    Новый участник

  • Members
  • Pip
  • 57 сообщений

Отправлено 30 октября 2007 - 20:20

инженерные изыскания, направленные на то чтобы здания не разрушались, а самолёты не падали на глазах у удивлённой публики,


Для корректного выполнения данных изысканий нуже менеджмент качества (а QA это часть его)
  • 0

#12 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 03 ноября 2007 - 10:12

инженерные изыскания, направленные на то чтобы здания не разрушались, а самолёты не падали на глазах у удивлённой публики,


Для корректного выполнения данных изысканий нуже менеджмент качества (а QA это часть его)

Очень содержательное замечание, большое спасибо за фидбек.

Если Вы не заметили, в моём запросе содержался конкретный вопрос:
"Если такое есть, то может быть кто-то поделиться названиями основных процессов?"

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

Для того, чтобы Вам было проще сформулировать свои мысли по этому вопросу, предлагаю модельную задачку: Space Station: Internal NASA Reports Explain Origins of June Computer Crisis. Приведите пожалуйста список процессов (названия), жизненно необходимых для предотвращения подобного по воздействию на систему инцидента в будущем.
  • 0

#13 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 08 ноября 2007 - 08:03

Кстати, сегодня Всемирный день качества (надо полагать, в неинженерных отраслях - комм. напоминальщика).
  • 0

#14 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 08 ноября 2007 - 10:32

Привожу конкретный пример из практики.

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

Раньше это происходило так: программист вносит изменения, проверяет их (специально назначенных тестировщиков у нас тогда не было), кладёт версию в Source Safe (это всегда было обязательным требованием), а скомпилированный бинарный файл отдаёт ответственному за поддержку данного клиента, и тот отправляет её по почте.

При этом часто возникали проблемы, самыми распространёнными из которых были:
- локальные библиотеки у программиста не соответствовали недавно изменённым (исправленным) версиям, над которыми работает другой программист;
- программист проверил версию не на той конфигурации, которая используется у заказчика. Крайний случай: он вообще проверял свои изменения на одном железе, а потом просто перекомпилировал эту версию для другого, потому что "ему так удобнее и быстрее";
- версия, положенная в репозиторий, впоследствии не собиралась (выдавались ошибки компиляции) - например, из-за того, что на локальном компьютере программиста какой-нибудь header лежал в другом каталоге. Или он, полагаясь на встроенные в MSVC средста работы с Source Safe, просто забывал поместить в репозиторий файлы ресурсов или makefile, которые нужно класть "вручную";
- и т. д., всех случаев не упомнишь.

Пришлось разработать документированные пошаговые процедуры выпуска релиза и отправки софта клиенту. Ключевые положения:
- каждой отправлямой версии в Source Safe назначается уникальная метка;
- скомпилированный двоичный файл НИКОГДА не передаётся от одного человека к другому, а всегда собирается локально из исходников, выбранных из Source Safe в чистый каталог по заданной метке (пришлось написать пару .bat файлов);
- перед отправкой собранное приложение ОБЯЗАТЕЛЬНО должно быть загружено в терминал такой же конфигурации, которая используется данным клиентом, для проверки работоспособности;
- любая отправка должна быть зарегистрирована в едином трекере с приложением отправленных файлов.


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

В "запарке" всегда есть соблазн пропустить один-два шага на основании собственной (в 50% случаев ложной) уверенности, что в данном случае ошибки нет. Документированные процедуры, во-первых, чётко определяют последовательность действий, а во-вторых, также чётко определяют ответственность участвующих в процессе.


При чём здесь ISO 9000? А чёрт его знает, мы не сертифицированы. :) Но все учебники по качеству, которые мне довелось читать, ставят акцент именно на задравом смысле в выявлении процессов, а не на формальном оформлении и сертификации.
  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#15 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 08 ноября 2007 - 17:30

Раньше это происходило так: программист вносит изменения, проверяет их (специально назначенных тестировщиков у нас тогда не было), кладёт версию в Source Safe (это всегда было обязательным требованием), а скомпилированный бинарный файл отдаёт ответственному за поддержку данного клиента, и тот отправляет её по почте.

При этом часто возникали проблемы, самыми распространёнными из которых были:
- локальные библиотеки у программиста не соответствовали недавно изменённым (исправленным) версиям, над которыми работает другой программист;
- программист проверил версию не на той конфигурации, которая используется у заказчика. Крайний случай: он вообще проверял свои изменения на одном железе, а потом просто перекомпилировал эту версию для другого, потому что "ему так удобнее и быстрее";
- версия, положенная в репозиторий, впоследствии не собиралась (выдавались ошибки компиляции) - например, из-за того, что на локальном компьютере программиста какой-нибудь header лежал в другом каталоге. Или он, полагаясь на встроенные в MSVC средста работы с Source Safe, просто забывал поместить в репозиторий файлы ресурсов или makefile, которые нужно класть "вручную";
- и т. д., всех случаев не упомнишь.


Решается обычными best practicies командной разработки - "Collective Code Ownership", "Continuous integration" (autobuild), unitests.

http://en.wikipedia....ous_integration
http://en.wikipedia....mming_Practices

Если еще SourceSafe сменить на что-нибудь, нормально поддерживающее стандартные практики configuration management (branching etc.) то все станет еще проще для девелоперов.

Пришлось разработать документированные пошаговые процедуры выпуска релиза и отправки софта клиенту. Ключевые положения:
- каждой отправлямой версии в Source Safe назначается уникальная метка;


жалкое подобие бренчей. Я Вас ни в коем случае обидеть не хочу, это я насчет SourceSafe.
Как тут строить хотфиксы (если потребуется) и их интегрировать в более новые версии?
http://www.perforce....tpractices.html

- скомпилированный двоичный файл НИКОГДА не передаётся от одного человека к другому, а всегда собирается локально из исходников, выбранных из Source Safe в чистый каталог по заданной метке (пришлось написать пару .bat файлов);


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

т.е. направление движения явно правильное.

При чём здесь ISO 9000? А чёрт его знает, мы не сертифицированы. :)


вроде как совсем не причем тут исо 9000.
а вот практики из XP, SCRUM, MSF, Lean Development, Crystal Clear намного ближе.
  • 0
Andrey Yegorov. Изображение

#16 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 09 ноября 2007 - 08:36

вроде как совсем не причем тут исо 9000.
а вот практики из XP, SCRUM, MSF, Lean Development, Crystal Clear намного ближе.


ISO 9000, если я правильно его понимаю, никаких практик не навязывает. Сертификат всего лишь свидетельствует, что принятые у вас методы работы обеспечивают стабильное качество.
  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#17 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 09 ноября 2007 - 15:03

ISO 9000, если я правильно его понимаю, никаких практик не навязывает. Сертификат всего лишь свидетельствует, что принятые у вас методы работы обеспечивают стабильное качество.


http://en.wikipedia.org/wiki/ISO_9000

"Certification to an ISO 9000 standard does not guarantee the compliance (and therefore the quality) of end products and services; rather, it certifies that consistent business processes are being applied."
  • 0
Andrey Yegorov. Изображение

#18 greesha

greesha

    Опытный участник

  • Members
  • PipPipPipPip
  • 363 сообщений
  • ФИО:Печёнкин Григорий Михайлович
  • Город:Мытищи

Отправлено 09 ноября 2007 - 15:55

ISO 9000, если я правильно его понимаю, никаких практик не навязывает. Сертификат всего лишь свидетельствует, что принятые у вас методы работы обеспечивают стабильное качество.


http://en.wikipedia.org/wiki/ISO_9000

"Certification to an ISO 9000 standard does not guarantee the compliance (and therefore the quality) of end products and services; rather, it certifies that consistent business processes are being applied."


Ну, может быть. Я не специалист. Один завод в Корее, с которым мы взаимодействуем, сертифицирован по ISO 9000, но это точно ничего не гарантирует. :)

Сам стандарт я не осилил (http://www.standartization.com/), а высказанное выше мнение у меня сложилось после прочтения книги "Управление качеством. Сказки, мифы и проза жизни".
  • 0
Григорий Печёнкин
greesha.ru
жежешечка

#19 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 29 января 2008 - 14:33

Вот давно хочу выяснить для себя, но никак не найду времени. Может быть кто-то исследовал уже этот вопрос. Действительно ли QA в смысле ISO 9000 широко применяется, отжирает себе щедрые куски бюджетов и приносит зримые плоды, например в проектном строительстве или при разработке летательных аппаратов? Для меня как-то странно было бы свыкнуться с мыслью, что соотвествующие конторы вместо того чтобы выполнять инженерные изыскания, направленные на то чтобы здания не разрушались, а самолёты не падали на глазах у удивлённой публики, развивают у себя процессы типа "ответ на жалобу удивлённой публики" или там "обеспечение обратного следа от поломки до инженера её спроектировавшего".
Если такое есть, то может быть кто-то поделиться названиями основных процессов?
А если ничего такого нет, а методологии QA пригодны только для улучшения массового производства (насколько я помню классику, изначально это была военная форма), то как так получилось, что в ИТ пытается складываться обратная ситуация? Всевозможные "процессологи" постоянно всеми правдами и, что особенно огорчительно, неправдами, пытаются установить примат своей области знаний над всеми остальными, при этом даже не обладая никакой заметной компетенцией в том что они собираются улучшать.

Далее следует субъективное мнение.
---------------------------------------------

Лично у меня вообще сложилось впечатление, что весь этот хвалёный процессный подход это нечто вроде отсоса благ в виде денежных средств из всяких туземных экономик, в виде: "Получи лишних сто баксов, за то что поставишь своих ближних на тысячу". Вроде форекса или тех же лицензий на некоторые виды софта.
Или может быть это у меня атавизмы "шарашного" сознания помноженные на пионерские знания в области качества?
Особенно хотелось бы услышать "голос Америки" по этому поводу.

Могу превести такой пример:
Компания А решила заключить контракт с компанией Б.
- сколько вы хотите за такую работу? - спросила компания А.
- Чемодан денег, ответила компания Б.
- а каков ваш уровень, и есть ли у вас сертификат это подверждающий?
- нет - ответила Б - но нас ведь все и так хорошо знают.
- ну тогда мы готовы дать вам пол-чемодана денег, так как мы тоже о вас наслышаны - сказала А - а вот если бы у вас был сертификат, с уровнем больше 3, мы бы дали вам целый чемодан.
- ок - сказала компания Б - мы получим сертификат.

Закончилось тем, что компания Б успешно получила сертификат нужного уровня. Они потратили какое-то время на вылизывание процессов и прочие подготовительные акции, нужные для сертификации. У них была и есть QA команда, которая этим занималась. Контракт был заключен на чемодан денег, а не на его половину.
Это яркий пример того, что наличие QA команды и ее деятельность на протяжение нескольких лет до этого - принесла прибыль. Да на них тратили средства все это время, но они не сидели тупо и ждали, когда же нас сертифицируют. Люди честно делали свою работу. И к моменту когда появилась необходимость получить сертификат - плоды работы данной группы людей стали видны в явном виде.
Их спрашивали - а у вас это есть? А они отвечали - да есть! И показывали реальные данные. Т.к. отмазки: есть но где-то на компе у инженера такого-то - при сертификации не годятся. И могли они так отвечать и показывать потому, что у них это уже реально было и было сделано не для сертификации, а для выпуска качественных продуктов.
На вопрос, принесла ли пользу сертификация (кроме этого контракта) - я получил ответ, что огромную пользу. Так как им указали на какие-то недостатки - это раз. Два, во время подготовки, они сами поняли, чем они могут гордится, а что надо бы поправить - ибо есть неувязки и из-за этих неувязок у них реально были сбои.

Да, кстати, все это было в америке.
  • 0
Regards,
Alexey

#20 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 29 января 2008 - 17:51


Лично у меня вообще сложилось впечатление, что весь этот хвалёный процессный подход это нечто вроде отсоса благ в виде денежных средств из всяких туземных экономик, в виде: "Получи лишних сто баксов, за то что поставишь своих ближних на тысячу". Вроде форекса или тех же лицензий на некоторые виды софта.

Могу превести такой пример
...
Да, кстати, все это было в америке.

Я, если честно, не уловил логической связи между приведённым примером и подтверждением высокого качества продукции неназванной компании. Т.е. где переход от "у нас есть вылизанные процессы" к "мы делаем качественную продукцию"? Про монетаризм, кредитно-денежную и инвестиционную политику я представление имею, но (точнее "и поэтому") жажду ещё какого-нибудь второго подтверждения.
  • 0


Школа Тест-Аналитика
онлайн
Организация автоматизированного тестирования
онлайн
Школа тест-менеджеров v. 2.0
онлайн
Тестирование юзабилити (usability)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале