Posts tagged качество

Является ли тестирование чисто затратной функцией?

0

В локальных консалтинговых компаниях по внедрению ERP систем замечена тенденция ….

или полного отсутствия или значительной минимизации функции тестирования.

Аргумент – это затраты, клиент за это не платит.

То что клиент за это платит могу легко доказать:

  • Клиент платит за превышение сроков проекта – несвоевременно найденные ошибки задерживают
  • Клиент платит за низкое качество проекта
  • Клиент платит за часы консультантов которые будут дольше разбирать

Да, действительно иногда трудно объяснить клиенту зачем нужно тестирование. На этой неделе я лично доказывал ИТ директору средней украинской компании что в проекте кроме разработки нужны затраты на анализ, архитектуру и тестирование. Трудно но доказал что нужно управлять проектом. Своим 10% доказал. Фуххх. Бывает что действительно тяжело объяснить клиенту. Но можно.

А вот что делать с ощущением что функция эта затратная. Давайте посмотрим что получается на практике. А на практике выходит что при недостатке тестировщиков их функция часто перекладывается на … самый дорогостоящий и иногда самый дорогой ресурс – консультантов и руководителей.

Учитывая что тестировщики:

  • Увеличат удовлетворение клиентов от качества продуктов и услуг
  • Уменьшат нагрузку на консультантов – это реальный bottleneck
  • Снизят риски качества проекта

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

Компоненты информационной среды управления проектами

0

Для более менее крупных проектов мы задумываемся о построении информационной системы для управления проектами. Прежде чем говорить – да у нас есть MS Project – и в северном варианте (Project Server) он будет очень классно покрывать все нужды – не спешите. Давайте рассмотрим основные компоненты такой среды и какие потенциальные компоненты могут подойти.

Коммуникации - сайт проекта, форум, рассылка, группы. Это может быть как сайт на SharePoint так и любая WiKi/Wordpress/LinkedIn группа. Для небольшого бизнеса вполне удобно создавать закрытые группы в социальных сетях и использовать их как готовые платформы для проектных коммуникаций.

Документы проекта – минимум файловый сервер. Лучше всего – сразу SharePoint или аналогичное средство с функционалом управления версиями. Если документы проекта будут готовиться исключить в веб форме – то вам также отлично подойдут Wiki системы. В них очень легко контролировать версии документов (но несколько сложнее научиться писать их с использованием внутренней разметки)

Записи проекта - это различные типы записей – структура работ, запросы на изменения, вопросы, дефекты, риски, требования, тесты, результаты выполнения тестов. Кроме фиксации самих записей важно чтобы работали хотя бы простые workflow по организации работы над записями – это даже крайне желательно. Для управления такого рода записями нужна система с удобным конструктором как новых записей так и процессов, удобными формами. SharePoint в базовой конфигурации для этого не очень хорошо подходит (но вполне терпимо для малых проектов). Хорошим кандидатом сюда – Microsoft Dynamics CRM  2010, SharePoint + Nintex + кастомные решения для организации документооборота. Также могут подойти ваши существующие ERP системы (в них легко создавать новые сущности и формы но менее просто решаются вопросы по автоматизации процессов)

Календарь проекта и Фактические данные – тут рулит Microsoft Project.

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

 

Наша клубничка: Формула удовлетворения

0

Давайте попробуем немного острой клубнички. Есть такая точка зрения – что менеджер проекта организовывает удовлетворение клиента. Ну как сутенер – только все легально  :-)  А насколько у него получается все это гут? (прошу прощения за немецкий акцент)

Давайте посчитаем! Дэвид Майстер, признанный гуру в области профессиональных услуг, пишет:

Удовлетворение = Восприятие – Ожидание

Какая простая, классная и очевидная формула. Ее нужно знать и о ее простых компонентах нужно заботиться. Компоненты – восприятие и ожидание. Если в начале проекта не сформировать, не задокументировать и не согласовать правильные ожидания – у вас появится серьезные риск по самой важной компоненте. Почему важной? А она вычитает!

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

Давайте обсудим что формирует Восприятие и Ожидание и как мы на это можем повлиять.

6 углов проектного менеджера – уже не так железно

0

Развитие концепции железного треугольника управления проектами- стоимость, время и содержание проекта – шестиугольник проектного управления.

В состав шестиугольника входят следующие дополнительные компоненты:

  • Удовлетворенность клиента (Customer Satisfaction)
  • Риск (Risk)
  • Качество (Quality)

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

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

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

Больше промежуточных версий

0

Чем больше промежуточных вверсий продукта проекта – в которых отражается успешное поэтапное продвижение проекта – тем лучше. Это с одной стороны позволяет сделать проект более легко планируемым по объему выполненых работ и готовности продукта, создает доверительные отношения с закачиком (только если заказчик не дурак – ибо дуракам как говорит народная мудрость показывать не готовый результат нельзя – что на практике  редко встречается). Ко всему прочему это схема которая подпитывает формулу успех порождает успех.

Разрушительная сила низкого качества

0

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

Снижение качества продукта в проекте

0

Хотите снизить качество продукта в проекте?

  • Безбожно давите на сроки, поставьте их нереальными и прессуйте
  • Снижайте стоимость, давите поставщиков до истощения
  • Вовлекайте ваших сотрудников в 5 проектов одновременно
  • Не в коему случае не доверяйте людям в проекте
  • Увеличьте бюрократию в проекте
  • Людей их проекта рассадите в разных комнатах в пяти корпусах.
  • Писать требования? Зачем! Это бумагомарательство. И завтра все равно мы что-то переделаем. А принимать будем когда более-менее будет готово.
  • Ни в коем случае не тратьтесь на тестировщиков. Разве и так не понятно что это должно работать?

Кросс-пост.

Go to Top