Как да се движат далеч от "печат" парадигма и пресъздайте управлението на промени в дизайна Блог
Спомняте ли си какво е "в списъка на хартиен носител?" Ако пишете програми за компютъра през 1980 г., можете да си спомните за разпечатки - печат копие на chelovekochitaemom формат код или цифрови данни. Прочетете свързаната статия от Wikipedia. Ние вече не се използват разпечатките. Те имат в миналото. Wikipedia го обяснява с прости думи:
Днес разпечатки рядко се използват, тъй като съвременните екрани показват повече линии от всякога, програми са модулни, съхранение в електронен вид за предпочитане е да се съхранява в хартиен и електронен материал, по-лесно да се предават по мрежата, на диск или на лента. Освен това, количеството на данните става толкова голям, че те са трудно да отпечатате, и търсенето е по-лесно да се извърши по електронен път.
Моят дългогодишен приятел на блога Lopategyu Ед (Ed Lopategui) обсъжда общата практика и трудностите, пред които са изправени производствените компании в областта на управлението на промени в дизайна. Аз препоръчвам да обърнете внимание на две от неговите статии в блога GrabCAD: ECOS не са мъртви, но те са бавни и Stupid (управление не е умрял промени в проекта, той е бавен и глупав) и ECOS са глупави II: Цената на неперсонифицирано промяна (управление на инженерната промени глупав II. Цена променя неперсонифицирано). Най-добри практики в областта на дизайн за управление на промените е сериозно зависими от традиционния подход на стандартите за управление на конфигурацията. Този пасаж обяснява много добре:
Повечето от процесите на промени в проекта се крие в самото официално традиционната рамка. Управление на промени в проекта са възникнали от практиките за управление на конфигурацията (см), които се връщаха от времето преди появата на CAD (да не говорим за PDM / PLM), когато светът е бил управляван от рисунки на хартия. Дизайн данни не са нито преносими нито широко достъпни. Тези ефективни, но сложни практики бяха създадени в старите големи промишлени компании, които са първите клиенти за използване на PDM / PLM. В резултат на това тези процеси продължават да живеят и се отглеждат до абсолюта. Те остават почти без промяна, за да се поддържа култура на правене на процесите в големи компании, независимо от възможността за еволюция.
Неперсонифицирани промяна - още един стар практика, която е отражение на старите практики на изменение на чертежите. Сложността на промените в документа е довело до появата на процеса на промяна. Така нареченият практиката на "беше - беше" се дължи на факта, че сравнението между двете фази на проектирането е много сложно:
Концепцията на неперсонифицирано промяна е необходима компромис в миналото поради ограниченията в дизайна на данни промени, особено в ерата на чертежите на ръка и CAD продуктовата гама в първата, при изготвянето на фигурата не може да актуализира един - кликвания две мишката. Разбиране на разликите между версиите на продукта се състои главно от чертежа е видяна от много време, докато промяната няма да стане ясно и / или търсите в началото заслепи. За да се намали натоварването на очите, промени често са специално обозначен като WAS / Е.
Нека сега се върнем към съвременния свят на софтуер. Представете си, че един програмист пише документ на хартиен носител с обяснения за промените на кода, че той ще направи утре. Той ги отпечатва, и отбелязва различията в жълто "е / беше." След това ги изпраща за одобрение. След това въведе самите промени. Тя изглежда странно.
Традиционният парадигма в областта на PLM са много подобни на стария софтуер за печат. Те са бавни и сложни. Чувам, че инженерите не правят формални промени и не се отказвайте от жизнения цикъл на процеса, тъй като изпълнението на този процес е труден и бавен. Никой не иска да работи със сложни процеси. В много случаи този процес е твърде сложен за групи и лица за работа с него. Говорих за някои от тези въпроси в по-ранните ми статия - защо PLM, следва да преразгледат NPI продукти (PLM Защо трябва да прегледат своите процеси, представящи нови продукти).
Динамичната разработка на софтуер е станал много популярен през последните десет години. Имаше един набор от понятия, които могат да бъдат използвани от производствените компании. Един от най-интересните характеристики - Как да направим процеса на промяна по-лесно и по-бързо. Когато става дума да се промени, скоростта е много важно.
Старите навици са напуснали домовете си в продължение на дълго време. Управление на промени в проекта - единият от тях се състои от 20 - 30 години история на най-добрите практики, разработени преди CAD система може да се сравнява двете версии на модела и се визуализира на различията. Прочетете по-рано съобщението ми как да се сравни версии и промени (как да се сравни версии и промени). Новите технологии и нови практики, следва да влязат в живота и да заместят старите подходи, динамична и документи на хартиен носител. Просто моето мнение ...
Най-добри пожелания, Олег
Всички споменати материали - на английски език.
Превод получава чрез "Irisoft".