Текущее время: Пт, мар 29 2024, 10:14

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 22 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Пт, дек 23 2005, 09:44 
Младший специалист
Младший специалист

Зарегистрирован:
Чт, янв 27 2005, 07:57
Сообщения: 59
Артему спасибо за полезную ссылку! :P


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 10 2006, 11:48 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:25
Сообщения: 218
Откуда: Moscow
artyom написал:
Про контроль качества в России говорить трудно. Когда этот контроль стоит 60% от стоимости консалта - еще труднее.
Перед переходом с 4.0 на 4.6 у нас были специалисты SAP и проводили review. Это не контроль качества, но что-то вроде.
Так вот это самое review показало, что какой-либо контроль после завершения проекта не только бесполезен, но в чем-то даже вреден.


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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 10 2006, 13:28 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Чт, авг 26 2004, 05:04
Сообщения: 922
Откуда: Челябинск
Пол: Мужской
vlad_ii написал(а):
artyom написал:
Про контроль качества в России говорить трудно. Когда этот контроль стоит 60% от стоимости консалта - еще труднее.
Перед переходом с 4.0 на 4.6 у нас были специалисты SAP и проводили review. Это не контроль качества, но что-то вроде.
Так вот это самое review показало, что какой-либо контроль после завершения проекта не только бесполезен, но в чем-то даже вреден.


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

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

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


Это написано в противопоставление моим высказываниям или в унисон?

_________________
Все будет хорошо...
http://sap-blog.ru/


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, янв 10 2006, 16:03 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:25
Сообщения: 218
Откуда: Moscow
Собственно и так и так, просто я не успел дописать как мысли кончились.

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

Цитата:

"Focusing on process, not results
Does this mean that there are no useful met-rics for processes with long cycle times? The Japanese often say, “Focus on process, not on results.” This is particularly good advice for processes with long cycle times. Process metrics such as “percentage of planned milestones missed or rescheduled,” “error based engineering change orders,” and “forecasting and planning process checklist items not completed” have been used effectively for driving improvement.
It is often tempting to define a metric as the gap between actual and planned results rather than process capability. However, that gap is linked to defects in the planning process or its implementation, not the under-lying process itself. In other words , it leads to the question “Why did we not achieve plan?” instead of “Why is the process pro-ducing these defects?”
"

С другой стороны сложно согласиться с положением о том что итоги подводить вредно.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 06:34 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Чт, авг 26 2004, 05:04
Сообщения: 922
Откуда: Челябинск
Пол: Мужской
Вы знаете я тоже где-то согласен, а где-то не согласен с Вами.
Согласен в том, что после окончания проекта не эффективно нанимать кого-либо на аудит. Наш проект далеко не провальный и review это показало, в принципе отзывы SAP были только положительные. Но вот это и вредно... Думаю понимаете почему.

С другой стороны под контролем качества понимают не только контроль качества выполнения проекта, но и качество продукта этого проекта.
Цитата:
Управление качеством проекта должно быть направлено как на управление
проектом, так и на продукт проекта. Хотя управление качеством проекта
распространяется на все проекты, независимо от продукта проекта, но
конкретные меры и методы обеспечения качества продукта зависят от
конкретного типа продукта, получаемого в рамках проекта.
PMBOK

Если качество проекта и правдо контролируется по формальным признакам, то качество продукта контролировать возможно по прямым метрикам, главное их правильно выбрать. Как говорил один мой преподаватель: "Главное выбрать систему координат и меру отсчета".

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

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

P.S. А про совместную вину клиента и консалтера в продукте плохого качества могу сказать только одно, недавно заходил на работу к своей жене и у неё над столом висит меморандум о клиентах. Мне понравился один тезис, точно не помню, но примерно так: "Если Вы понимаете что ваше сотрудничество не принесет пользу клиенту, то постарайтесь убедить его в несвоевременности вашего сотрудничества, в противном случае вся ответственность в неполучении клиентом пользы ложится на вас". Там конечно покрасивее, но смысл такой же.

_________________
Все будет хорошо...
http://sap-blog.ru/


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 07:06 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Чт, авг 26 2004, 05:04
Сообщения: 922
Откуда: Челябинск
Пол: Мужской
И еще.

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

_________________
Все будет хорошо...
http://sap-blog.ru/


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Ср, янв 11 2006, 10:11 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:25
Сообщения: 218
Откуда: Moscow
Согласен, мне и самому "формально" не понравилось. Речь идет о том, что качество обычно контролируют по конечному продукту, насколько он попадает под требования и ожидания клиента, но в случае, если продукта нет, как в случае с проектом внедрения, результат следует ждать после окончания внедрения, и производственный цикл соизмерим со временем изменения требований и ожиданий клиента. Поэтому хитрые джопанюги предлагают использовать показатели процесса а не продукта.

И очень согласен с вами, в том, что если консультант видит, что клиент не готов принять его услуги, то об этом нужно сразу сказать, а не ждать, пока он полностью (как вы планируете) с вами расплатится. В конечном счете это будет дешевле :D


зы. Собственно цитата взята из Metrics for the Order Fulfillment Process от Arthur M. Schneiderman.

Ссылку в инете не помню, но в гугле можно найти быстро. У него несколько статей об одном и том же. Мне понравилось.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 22 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB