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

[melan]

Приветствую всех!

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

Итак, что мы имеем сейчас. Ситуация следующая:
- Сфера деятельности: софт для медицинской сферы. Софт большой, а потому контролируется организацией под названием FDA

- Есть 3 компании:
* Головная (Г) - стояла у истоков разработки продуктов. Сейчас занимаеется исключительно работой с клиентами и планированием.
* Коллеги (К) - появились несколько раньше нас и находятся в соседнем государстве. Компния более мелкая нежели наша: порядка 100 человек.
* Мы (М) - аутсорсинговая компания. штат больше 300 человек. более 20 проектов [3-70 человек/проект] (честно сказать сам точно знаю сколько их). работает на одного заказчика.

- Основные практики применяемые в М:
* Работа с клиентскими требованиями
* Планирование версий
* Управление конфигурациями
* Учет дефектов
* Инспектирование кода
* Модульное тестирование. Местами автоматическое
* Многоуровневое системное тестирование
* Централизованные компиляции и установки версий на энвы. Процесс практически полностью автоматизирован.

- Состояние системы QA
* Несколько разрозненная и местами несогласованная система документов описывающая систему качества с точки зрения Г. А также предполагающая работу К и М в качестве интегрированных центров разработки.
* Несколько раз раз предпринимались попытки проведения аудитов соответствия текущих процессов исходным
* Собираются какие-то метрики описывающие процесс разработки. Пока что нам не удалось превратить эту информацию в инструмент для принятия управленических решений.

- Цель
* Изменить систему QA таким образом, чтобы она стала отражать новый формат взаимодействия Г и М: заказчик - поставщик решений (Vendor).

- Шаги для достижения цели
* Проанализировать входы и выходы в наших взаимодействиях с Г
* Провести оперативно аудиты в проектах с целью определения текущего состояния компании. В частности попробуем понять какие процедуры в каких проектах работают.
* Выделить "лучшие практики"
* Спланировать и организовать постояный сбор метрик, которые показали бы нам как меняется компания в результате тех или иных решений
* Выработать Quality Road Map для компании и каждого проекта. В этих документах опишем плановые показатели для компании и каждого проекта в отдельности
* Разработать систему стандартный процедур покрывающую все сферы деятельности компании
* Работать

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

Эх.. Лед тронулся..

[Green]

Melan,

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

"И увидел он, что это хорошо! И возрадовался."

Правильно?

Не правильно!

Вы думаете до Вас эту систему управления делали глупые люди? Или может быть они ничего не понимали в процессах, а так просто, взяли и написали какие-то документы, определили какие-то метрики? Для отписки? Что бы было?

Почему это не работает сейчас?

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

А почему Вы уверены, что после создания новой системы контроля качества ее не постигнет такая же участь?

[melan]

Сергей,

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

Существующая система работает и дает неплохие результаты: клиентская база растет (доходы соответственно тоже), количество проектов увеличивается.

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

Вы думаете до Вас эту систему управления делали глупые люди? Или может быть они ничего не понимали в процессах, а так просто, взяли и написали какие-то документы, определили какие-то метрики? Для отписки? Что бы было?

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

Почему это не работает сейчас?

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

А почему Вы уверены, что после создания новой системы контроля качества ее не постигнет такая же участь?

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

К счастью мне привили эволюционные подходы к моей работе, а не революционные.

[Green]

Действительно, у меня крайне мало информации о состоянии дел в вашей компании. Я руководствовался следующими заявлениями:

- Состояние системы QA
* Несколько разрозненная и местами несогласованная система документов описывающая систему качества с  точки зрения Г. А также предполагающая работу К и М в качестве интегрированных центров разработки.
* Несколько раз раз предпринимались попытки проведения аудитов соответствия текущих процессов исходным
* Собираются какие-то метрики описывающие процесс разработки. Пока что нам не удалось превратить эту информацию в инструмент для принятия управленических решений.

Их я интерпретировал так:
- раньше была система, навязанная нам сверху;
- эта система работает и до сих пор, но сама по себе;
- несколько раз пытались привести систему в актуальное состояние, но все без результатно.

- Цель
* Изменить систему QA таким образом, чтобы она стала отражать новый формат взаимодействия Г и М: заказчик - поставщик решений (Vendor).

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

Итог очевиден.

Но оставим схоластику в стороне.


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

Строчки кода, баги, отчетные точки - всегда вторичны. Люди - первичны. Следовательно, для усепшного управления руководителю нужна та информация, которая позволит ему эффективно управлять людьми. А все остальное должно укладываться в паттерн (типовое поведение в типовой ситуации). К счастью, разработка софта - это не письмо картин. 80%, а то и больше, операций могут быть описаны с помощью паттернов (без или с минимальной корректировкой для конкретного проекта).

Думайте как продавец. У вас есть потребитель информации, который должен ее покупать. Это руководитель проекта. Чем он реально пользуется в жизни из того, что ему сейчас доступно? Выясните это и оставьте в системе, все остальное - к черту! Это никогда не будет работать! Затем узнайте, какая информация может ему помочь еще лучше выполнять свою работу и дайте ему эти данные.

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

[sunlex]

Melan, из своего практического опыта я понял, что успех в подобных проектах зависит от:
1. Наличие стратегии, общего видения. Должны быть четкие ориентиры, как маяки.
Причем эти ориентиры должны однозначно пониматься и поддерживаться всеми участниками - руководство, employee (слегка из области фантастики:), и вами.
2. Далее, эти маяки must be привязаны к бизнесу.

  Цель
* Изменить систему QA таким образом, чтобы она стала отражать новый формат взаимодействия Г и М: заказчик - поставщик решений (Vendor).

Цель "отражать формат" - это конечно хорошо, но где здесь выход на $?
Руководство всегда думает о $, и может идти на траты только если видит бенефит, хотя бы в будущем.
К примеру, у нас, маяками выступают цели компании на год. Это определенные показатели, которых мы не достигнем без соответствующего уровня процессов.
Например, "Достигнуть уровня удовлетворенности потребителей хх%". Или "Достичь показателя качества кода (плотность дефектов) хх%". Под эти цели мы запускаем проекты типа внедрение новых метрик, или улучшение корпоративного портала.
3. Малые порции улучшений.
Эволюция в подавляющем большинстве случаев более оправдана чем революция. Эволюция неспешная. Пч народ неспешно втягивается:)
4. Не оставлять за собой незавершенных дел.
Одна из ошибок в улучшениях - вложить много сил, и оставить без внедрения. Здесь много оговорок, лучше не вдаваться. Суммируя - результат - это решенная задача, а не попытка ее решить.


Полностью согласен с Green по поводу:

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

Строчки кода, баги, отчетные точки - всегда вторичны. Люди - первичны. Следовательно, для усепшного управления руководителю нужна та информация, которая позволит ему эффективно управлять людьми. А все остальное должно укладываться в паттерн (типовое поведение в типовой ситуации). К счастью, разработка софта - это не письмо картин. 80%, а то и больше, операций могут быть описаны с помощью паттернов (без или с минимальной корректировкой для конкретного проекта).

Думайте как продавец. У вас есть потребитель информации, который должен ее покупать. Это руководитель проекта. Чем он реально пользуется в жизни из того, что ему сейчас доступно? Выясните это и оставьте в системе, все остальное - к черту! Это никогда не будет работать! Затем узнайте, какая информация может ему помочь еще лучше выполнять свою работу и дайте ему эти данные.

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

Руководители проектов - люди приносящие реальные $. C ними нужно очень плотно работать.
Кстати, люди улучшающие процессы - не приносят прямых денег(зато приносят прямые траты:-).

Несколько комментариев по вашему описанию ситуации:
- проекты медицинские, контроль некой FDA -> это значит, что важную роль должно играть тестирование. От 50% общего времени на проект. Посмотрите для справки например GAMP - британский стандарт для фармацевтики.
- "шаги для достижения цели" в целом стандратные. На практике возникнет масса нюансов, всего не опишешь. Поэтому мне больше всего понравился шаг "*Работать "

[Yury]

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

А какая у Вас роль/должность?
А какой у Вас мандат?
А кто является Вашим заказчиком?

Без ответа на эти вопросы посоветовать что-либо по существу очень трудно.

[SALar]

- Цель
* Изменить систему QA таким образом, чтобы она стала отражать новый формат взаимодействия Г и М: заказчик - поставщик решений (Vendor).

Это не цель. Называйте как хотите: "мысли вслух", "неспешные размышления", "благие пожелания",- но это не цель.

Определение. Цель есть нормированное представление о достижимом результате.

Ключевое слово здесь "нормированное". Т.е. заданы критерии по которым можно однозначно определить достигнута цель или не достигнута.

"За три месяца снизить среднее время решения проблем заказчика в два раза." - Вот это более похоже на цель. Правда нужно еще проверить на достижимость...

[melan]

А какая у Вас роль/должность?

Должность QA манагер. Роль... хм, по идее моя роль - человек управляющий системой качества.

А какой у Вас мандат?

Мой мандат состоит в введение практики управления системой качества в повседневную жизнь компании.

А кто является Вашим заказчиком?

Руководство компании. А бывают в подобных случаях другие заказчики?

[melan]

Это не цель. Называйте как хотите: "мысли вслух", "неспешные размышления", "благие пожелания",-  но это не цель.

Определение. Цель есть нормированное представление о достижимом результате.

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

Однако у всех рефакторингов есть одна цель: сделать не хуже, а по возможности лучше чем было. А вод задачи этих работ уже совершенно различные. Так что позвольте мне оставить цель неизменной, а вот задачу на начальный этап работ сформулировать следующим образом: создание формального описания 60% процессов связанных с разработкой ПО в компании.
Допущения: в сферу интереса начального этапа не попадают процессы связанные с наймом сотрудников, заказом отпусков/больничных и т.п. Должны быть описаны процессы в которых принимает участие более 1 человека или же которые встречаются более чем в одном проекте. Не рассматриваются процессы непосредственного заполнения форм - эти этапы описываются как факт, что форма должна быть заполнена.

Возможно я что-то упустил из допущений. Ну и конечно нет методики выбора тех самых 60% счастливчиков - я постараюсь придумать и дописать это позже.

[Green]

Так что позвольте мне оставить цель неизменной, а вот задачу на начальный этап работ сформулировать следующим образом: создание формального описания 60% процессов связанных с разработкой ПО в компании.

Я бы написал, не 60%, а всех ключевых процессов разработки ПО. Их не так уж и много. К примеру в RUP выделено 6 ключевых и 3 вспомогательных.

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

[Yury]

А какой у Вас мандат?

Мой мандат состоит в введение практики управления системой качества в повседневную жизнь компании.

Повторю то, что Вам уже пытались объяснить sunlex и SALar.
В первую очередь Вам не мешало бы понять, что же от Вас, на самом деле, хотят.
У меня сложилось впечатление, что Вы понимаете внедрение новых процессов, как самоцель. Если это, на самом деле, так (в чём я сильно сомневаюсь), то Ваша задача достаточно проста - любой новый внедрённый процесс автоматически приведёт к достижению этой цели.

А кто является Вашим заказчиком?

Руководство компании. А бывают в подобных случаях другие заказчики?

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

[astenix]

C чего начать: статья I’ve Just Been Assigned To Manage Testing, What Next? by Brad Kuhn.

I recently received a question on a previous post of mine about what test documentation should be pulled together for management when you get assigned to manage a test project. I’ve been asked this before, so I thought the answer warranted a post.

Not all of us have managed a test phase or team before. I would summarize preparing and running a test project in five groups of activities:

• Define the Test Strategy
• Document the Test Plan
• Prepare the Test Scripts
• Execute the Test Plan
• Deliver Metrics and Lessons Learned

Test Strategy

You should start with the test strategy. The strategy document defines:

• Any applicable quality assurance guidelines to be followed
• Overall approach to testing (e.g. use of automated test tools, need for regression testing, etc…)
• Overall responsibilities for testing
• The test phases that will be executed and various information about each phase (e.g. description, timing, roles and responsibilities, etc…)

Some people don’t see the need for an overall test strategy and write test plans instead, but I prefer a summary level document like this one. One advantage to this approach is that you can develop your test strategy fairly early in the project - but test plans generally require that you’re further along in the project life cycle.

The Test Plan

Don’t make the mistake of leaping immediately into the definition of test scripts after you’ve defined your test strategy - you need to flesh out a test plan for each test phase of the project. This includes unit testing (Development should develop this plan). I’ll be publishing a test plan template shortly, so I’ll provide more information in that post, but here’s the type of information the test plan should have (at a minimum):

• Scope (including what won’t be tested)
• Quality risks
• Schedule (including planned test iterations)
• Entry, exit, and stopping criteria
• Test configuration(s)/environment(s)
• Roles and responsibilities
• Defect reporting (including references to documentation on how to use the defect tracking tool)
• Release management
• Test case status and metrics reporting

Test Scripts

Here’s a couple of posts that will help in planning and writing test scripts - the first one is on test case planning and execution, and the second one describes a test script template.

Test Execution

If you’ve put together a good test plan and developed a thorough set of test scripts, test execution is a snap! Well, not really - but a large amount of your total test effort should be spent in preparing for test execution. That way you won’t be swamped when all of the unforeseen emergencies land (and they will).

Test Metrics and Lessons Learned

You should regularly deliver test metrics while you execute each test phase. I’ve written a previous post on test statistics, and I’d suggest you start there for some ideas. Also, at the end of testing don’t forget to put together a lessons learned, which should include what went well/could be improved for the next time. You don’t want to constantly hit the same difficulties over and over, do you?

[stavnichaya]

Буквально с завтрашнего дня я начинаю заниматься переработкой существующей системы гарантирования качества в моей компании…

И вот уже прошло полгода. Скажите, пожалуйста, melan, удалось ли достигнуть цели? С какими проблемами пришлось столкнуться? Какие положительные результаты получены?

[X-act]

Буквально с завтрашнего дня я начинаю заниматься переработкой существующей системы гарантирования качества в моей компании…

И вот уже прошло полгода. Скажите, пожалуйста, melan, удалось ли достигнуть цели? С какими проблемами пришлось столкнуться? Какие положительные результаты получены?

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

[melan]

Буквально с завтрашнего дня я начинаю заниматься переработкой существующей системы гарантирования качества в моей компании…

И вот уже прошло полгода. Скажите, пожалуйста, melan, удалось ли достигнуть цели? С какими проблемами пришлось столкнуться? Какие положительные результаты получены?

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

Я действительно уже и забыл про этот пост. Удалось ли достигнуть цели? Определенных целей действительно удалось достигнуть: выяснили на каком этапе зрелости (психологической) находится компания - мы находимся на этапе феодального общества: каждый проект свое княжество и каждый менеджер проекта практически полностью определяет что и как ему делать. Есть всего несколько точек соприкосновения между проектами, и, чаще всего, это группы технического сапорта или общекорпоративные инструменты и процедуры. Плохо это или хорошо - я не знаю, но тот факт, что продукты пишутся и продаются говорит о приемлемости данного подхода.
Кроме того за это время удалось побывать в "логове зверя", пообщаться с людьми, в том числе и топ менеджментом, из головной конторы. И должен заметить, что с той стороны мир выглядит немного по другому. Т.е. там людей вообще не волнует есть у нас система качества или нет. Для них главное - это результат-продукт-деньги. Все остально - второстепенно. Очень интересно их отношение к их же процедурам правилам. Чаще всего они удивленно спрашивают: а что, у нас такое есть?!

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

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

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

Подводя итог могу сказать, что формально проект провалился: цель не достигнута, план по ее достижению - оказался несостоятельным. А по сути проект из революции превратился в эволюцию и жить становится лучше с каждым днем :)

[X-act]

Подводя итог могу сказать, что формально проект провалился: цель не достигнута, план по ее достижению - оказался несостоятельным. А по сути проект из революции превратился в эволюцию и жить становится лучше с каждым днем :)

Мда... перспективы радостными не назовёшь...

[Vasiliy]

Это не перспективы. Это проза жизни.
А она показывает, что мир еще жив и это не может не радовать.

А так процесс идет, о чем и было сказано в последней части сообщения.

[SALar]

То, что проект провалится можно было сказать полтора года назад, просто взглянув на формулировку цели. У него изначально практически не было шансов.
Не расстраивайтесь, это совершенно типичная ситуация. Примерно 99% проектов в РФ начинаются без ответа на вопрос "Зачем?". А далее мы получаем... То что получаем. Гужевые повозки от автоваза, школьный портал, CMMI пятого уровня, ...

[DrVal]

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

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

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

Что ж до достигнутых результатов, на самом деле Вы не ставили перед собой цели (например, по SMART или по 6W) и у Вас не было плана (Software Quality Assurance Plan), были благие пожелания что-то поменять к лучшему. Распространенная ошибка, я тоже был бы рад от нее избавиться.