Сообщений в теме: 60

[Undi]

А что подразумевается под словами "качественный продукт"? У разных людей будет разное представление об этом, даже если они будут опираться на один и тот же стандарт.
Перефразируя анекдот, я бы сказала, что гарантируется 50% качества. Либо получится КАЧЕСТВЕННЫЙ продукт, либо не получится :).
В любом случае, это будет субъективное мнение одного определенного человека.

[Undi]

Я смогу перевести бабушку, вполне случайно, так что полностью удовлетворю все её требования по переводу: скорость движения, давление на руку, конечній пункт (другая сторона).

То есть у неё будут невысокие требования - я окажу услуги согласно её требованиям, то есть окажу качественную услугу, соответсвующую требованиям + в нужное время, в нужном месте.

Я потому и усомнился в качестве, так как требования бабушки Вы ведь не узнали? Просто повели ее в неизвестном (удача - если совпало :)) направлении. Ваше качество будет очень субъективное. Бабушка может думать совсем по-другому.

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

PS: Есть цель и есть средства. Есть стандарты, которые помогают найти общий язык при требованиях выше низкого :). Но не больше.

[Green]

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

:P

Case абсолютно прав, возможно оказать качественную услугу совершенно не заморачиваясь на всякие стандарты. Если у вас есть слаженная сильная команда, способная ответственно трудиться над проектом, то возможно, что вы и преуспеете в нем.

:ph34r:

Стандарты нужны совершенно для другого!

Их задача описать принципы построения процессов по разработке РАЗЛИЧНЫХ проектов ЛЮБОГО РАЗМЕРА и ЛЮБОЙ СЛОЖНОСТИ командой ЛЮБОГО УРОВНЯ ПОДГОТОВКИ с ОДИНАКОВЫМ УРОВНЕМ УСПЕХА.

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

Одним словом это называется ТЕХНОЛОГИЯ!
B)

[Case]

Стандарт к бюджету каким местом?..

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

[Case]

Только не надо примеров из жизни - я ЗНАЮ как одно к другому корелирует! :)
Также как и политическая обстановка в стране и мире. А по существу? Бюджет и сроки - это параметры проекта по разработке, а не параметры продукта.

[Green]

Одним словом это называется ТЕХНОЛОГИЯ!
B)

Технология абсолютно не гарантирует высокое качество продукта.

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

[Green]

А по существу? Бюджет и сроки - это параметры проекта по разработке, а не параметры продукта.

Case,

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

Это софистика!
:P

[Green]

Стандарт к бюджету каким местом?..

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

На самом деле все очень просто.

Берем одну и туже организацию, один и тот же проект в одни и теже сроки, но даем два разных бюджета. Качество какого будет выше?

B)

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

B)

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

[Case]

Качество какого будет выше?

Нельзя сказать. Можно и денег дать и времени и ничего не выйдет. Можно убиться об стенку и ничего из них не выжать. Я работал над такими проектами :) Ещё будучи студентом. И денег давалось много и времени. А проект как был... там и лежит. НИКАКОЙ строгой взаимосвязи с качеством.

Будет мало - с большей вероятностью получат фигню. Дадут больше - никто качества не гарантирует.

Второй пример чётче - однако так можно сравнить всё-что угодно. Вопрос в том, что соимость проекта будет ОЧЕНЬ разная если отдать в контору где СММ есть (тем паче СММ 5) и там где его нет.

На качество продукта влияет только качество процесса. На качество процесса влияет его отточеность и формализация. Но никак не стоимость проекта и его бюджет.

Хотите другой пример? Художник. На работе по всем стандартам делает картинки на ширпортеб. Стабильно - в срок и рамках бюджета. Дома для себя делает шедевр. Один раз - продаёт за миллионы. Вопрос только в том что нужнее - раз в жизни шедевр или каждый день картинка. Вы сравниваете примерно также, Сергей.

[Case]

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

Запросто. Ты оперируеш ситауцией когда продукт=проект. Абстрагируйся от реалий. Мы не конкретную проблему разбираем. Прикинь чуть шире. Оторвись от ситуцаии когда над тобой заказчик со сроками и деньгами - над тоой заказчик с желанием качества. DOD!

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

Внедрение и применения стандартов будет гарантировать качество продукта, если это стандарт описывает процесс, который уже приносил качественный продукт. То есть стандарт может гарантировать только повтояремость. Делай также - получишь тоже. Какое тоже? Какое получили в результате того, с чего писали стандарт.

[barancev]

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

Я молчал, не высказывал своё мнение, хотя неявно агитировал за ответ "нет" на поставленный вопрос :)
Пришло время сказать несколько слов в защиту стандартов и моделей, а то "нет" стало перевешивать. :)

USDP (и, видимо, следом за ним RUP) даёт такие соотношения:
* процесс -- это шаблон проекта
* продукт -- это результат проекта

Логика за этим скрывается следующая (как и за другими моделями и за стандартами).

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

Из этого делается вывод, что если очередной 11-ый проект будет удовлетворять тому же шаблону, значения показателей качества продукта будут не ниже.

Согласитесь, вполне разумное предположение.

Конечно, гарантий никаких нет. Почему? Нет, не потому что "стандарты не могут". Причина в другом. Давайте на какое-то время поверим во всемогущество стандартов.

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

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

А во время выполнения проекта можно пользоваться шаблоном как руководством к действию, как путеводной нитью, которая поможет не уйти в неправильном направлении.

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

[Green]

Кто про что, а...
мы про одно и тоже!
:P

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

[Case]

Я прошу прощения, просто не мог удержаться :)

Эту тему читают:
3 Пользователей: Case, barancev, Green

Идеологи, блин :)

[Case]

О!

При применении на предприятии устоявшихся процессов качество разработок будет выше

Соглашусь.

Но не следование стандартам! Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять. Я уже не говорю что стандарт для начала нужно выбрать :)

[Viktor]

Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять.

Это, кстати, одно из первых требований стандарта 12207

[Viktor]

У меня складывается впечатление, что многие ожидают следующих гарантий от применения процессных стандартов: лепят, лепят, и вдруг получается качественный кирпич. Нет, неправда, процессный гост требует, что если вдруг кирпич оказался не совсем качественным - обязанность разработчика устранить его недостатки. Нельзя выдергивать отдельный процесс и ожидать что продукт этого процесса окажется качественным. Вот если соблюдать ВСЕ (адаптированные) требования ко ВСЕМ (адаптированным) процессам - тогда ожидайте гарантий :)
Программный продукт - результат процесса разработки. Есть в 12207 и процесс обеспечения качества - его результат качественный продукт :). Выполняешь требования процессса - получаешь качественный продукт.

[Viktor]

При применении на предприятии устоявшихся процессов качество разработок будет выше (при условии соблюдении стандартов на эти процессы).

Не уверен, цель устоявшихся (адаптированных?) процессов может быть далека от целей обеспечения качества.

[Viktor]

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

Почему нельзя гарантировать заранее, что проект будет следовать качественному процессу?
Сертификация как раз это и подтверждает.

[barancev]

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

Почему нельзя гарантировать заранее, что проект будет следовать качественному процессу?
Сертификация как раз это и подтверждает.

Давайте рассмотрим пример из со-о-овсем другой области.

Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.

Но вот кто-то бросил шкурку от банана как раз в тот момент, когда он собирался сделать 1286-й прыжок, и она упала ему под ноги, и он поскользнулся и сшиб планку. Кошмар! Да нет, ничего страшного, ногу-то не сломал, в следующий раз он снова прыгнет выше двух метров. Не надо отбирать у него сертификат. Он всё ещё хороший прыгун. Но прыгнуть не смог.

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

Сертификация подтверждает, что организация знает как и умеет следовать качественному процессу. Но она не даёт гарантий для данного конкретного проекта.

[Viktor]

Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.

Но вот кто-то бросил шкурку от банана как раз в тот момент, когда он собирался сделать 1286-й прыжок, и она упала ему под ноги, и он поскользнулся и сшиб планку. Кошмар! Да нет, ничего страшного, ногу-то не сломал, в следующий раз он снова прыгнет выше двух метров. Не надо отбирать у него сертификат. Он всё ещё хороший прыгун. Но прыгнуть не смог.

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

Сертификация подтверждает, что организация знает как и умеет следовать качественному процессу. Но она не даёт гарантий для данного конкретного проекта.

Если это качественный прыгун и он следует требованиям, он не остановится пока не прыгнет на два метра, даже если первый раз ему это не удалось.
Именно для того, чтобы не было таких "брошенных" прыжков и существуют требования стандартов по обеспечению качества. Прыгун должен прыгать до тех пор, пока не перепрыгнет. И заказчик знает, прыгун будет прыгать, а не плюнет и скажет, что "в следующий раз". И вот это я называю гарантия качества и этого требует стандарт. Прыгать не до обеда (или один раз), а прыгнуть на определенную высоту, и не важно сколько раз придется прыгнуть для этого. Хотя в другой ситуации, возможно, потребуется прыгать до обеда. Значит качественный будет тот прыгун, который будет прыгать до обеда.
Заказчик не любит случайностей. Все должно быть определено и измерено. ГОСТ нужен заказчику, а не производителю изначально. Здесь палка о двух концах, на одном конце один поставщик, у которого, возможно, "толковые ребята", на другом - поставщик с гарантированным качеством услуги. Где заказчик? Особенность системы менеджмента качества как раз и заключается в том, что стоимость услуги не увеличивается(даже сокращается). Заказчику должно гарантироваться качественное исполнение заказа. А сколько это стоит (сколько раз нужно прыгнуть), это не проблема качества (хотя, возможно, проблема заказчика). Возьмите такой пример: без ТЗ сложно оказывать качественные услуги, с этим все согласны (кроме бабушки :)). Сколько будет стоить разработка продукта без ТЗ, или по ТЗ? Заказчику? Разработчику? (Я уже не говорю о рисках вообще не получить продукта). Но получение продукта - лишь доля работ по получению прибыли. Его нужно качественно подать, качественно поддержать и т.д. Вот у разработчика есть продуктный стандарт. Продукт удовлетворяет требованиям заказчика сегодня. А завтра? Заказчику, необходимо чтобы и завтра он удовлетворял его требованиям. А где это требование прописано? В процессном стандарте :). Вот и понятие возникло - жизненный цикл. Требования стандарта - обеспечение качества на протяжении всего жизненного цикла. Хочешь мертвую программу - пожалуйста, говорят, есть нетленные тела. Лично мне нужна программа без запаха. "Программа умирает", если не поддерживается и не обслуживается. Прыгун дряхлеет и чахнет, банан гниет. Но появится новый прыгун, вырастет новый банан. Появится другая программа и другой разработчик на нашем месте, если мы не будем качественно исполнять заказ.