프로젝트 (바이오 가스 및 폐기물 에너지 플랜트)의 설계 문서를 보면, 우리가 만들 계획은 있지만 다른 옵션이 고려되지 않은 이유와 폐기 이유를 알 수 있습니다. 이 정보는 엔지니어 헤드에만 있습니다. 때때로 플랜트는 몇 년 동안 개념적 단계에있을 수 있으며 때로는 엔지니어 사이에서 전환되기도합니다. 그래서 저는 동료가 작년에 고려하고 궁극적으로 버린 옵션을 다시 찾게되었습니다.
설계 결정, '이유'및 '이유'를 추적하는 좋은 방법은 무엇입니까? 업계의 다른 곳에서 시도, 테스트 및 사용 된 접근 방식을 강력하게 선호합니다.
추가 정보 : 우리 회사는이 QA 체제에 맞는 접근 방식을 선호하는 ISO 9001 인증을 추구 할 것입니다.
답변:
나는 이것이 당신이 원하는 정보의 양과 공식적으로 추적하고자하는 것에 달려 있다고 생각합니다. 현재와 같이 들리지만,이 정보는 어디에도 기록되지 않았으며, 이는 분명히 첫 번째 문제입니다. 그러나 추구하지 않는 솔루션에 대한 정보를 게시하는 것은 기껏해야 최적의 시간을 사용하지 않는 것입니다. 어떤 아이디어가 기록 될만큼 충분히 구체화되어 있는지 정의해야합니다. 회의가 있고 12 개의 아이디어가 탁자에 놓여 있지만 절반이 거의 즉시 폐기되는 경우 해당 아이디어가 무엇인지, 왜 폐기되었는지 메모하고 싶습니까? 그것은 아마도 매우 낮은 수준의 분석이었던 것에 많은 노력을 기울 였지만 여전히 디자인 결정입니다.
실제 작업을 수행하는 단계에 도달 한 아이디어에 대해서만이 작업을 수행하는 것이 더 직관적 인 것 같습니다. 이런 식으로, 당신은 이미 유형의 것을 얻었고, 이것은 단지 당신이 이미 가지고있는 것 인 프로젝트 파일에 보관해야합니다. 이 시스템은 실제로 향후 프로젝트를위한 참조 자료 만 생성 할 것이기 때문에 이러한 자료를 보관하거나 기존 시스템을 점검하기위한 완전히 새로운 시스템을 만드는 것은 좋은 생각이 아닙니다. 현재 설계 관리 시스템에 통합 할 수있는 방법을 찾으십시오.
내가 가지고있는 한 가지 열쇠는 다른 매개 변수를 주요 매개 변수로 분류하는 방법입니다. 나는 당신의 분야에 대해 잘 모르지만 각 프로젝트가 충족 해야하는 특정 설계 매개 변수 (물리적 크기, 용량, 식물 유형 등)가 있다고 가정합니다. 새 프로젝트를 시작할 때 다양한 측면에서 유사한 오래된 프로젝트를 식별 할 수 있도록 이러한 어딘가에 쉽게 표시되는지 확인하십시오. 폐기 된 아이디어가 해당 폴더에 저장되어 있으면 현재 프로젝트에 대한 해당 유틸리티를 분석 할 수 있습니다.
그러나 나는 또한 이것에 너무 깊이 들어가는 것에 대해 일반적으로 경고하고 싶다. 다시, 나는 프로젝트가 훨씬 더 짧은 다른 산업에서 일하고 있으며, 따라서 더 많은 프로젝트가 있지만 일부 제품은 수십 년 동안 어떤 형태로 존재했으며 15-20 개의 개정판이 있습니다. 구현 된 실제 설계 변경에 대한 개정 기록을 유지하는 것이 매우 중요합니다. 과거에 고객에게 무엇을 주 었는지, 언제 변경했는지, 왜 변경했는지를 아는 것은 과거의 실수를 반복하지 않고 오래된 디자인을 올바르게 서비스하는 데 중요합니다. 그러나 완전히 실현되지 않은 디자인을 카탈로그 화하면 필수 데이터 위에 필수가 아닌 데이터를 추가하게되며, 데이터가 손실되기 전에 분류 할 수있는 정보가 너무 많습니다. 너처럼 들린다 확실한 의사 소통과 좋은 경험을위한 대체물을 찾고 있습니다. 이러한 프로젝트가 바뀌면 관련된 엔지니어는 모든 관련 정보를 전달해야합니다. 나는 당신이 무엇을 고려했는지 알고 싶다는 것을 이해하지만, 불필요한 데이터로 레코드를 넘치지 않도록 그 욕구를 부드럽게하는 것이 좋습니다.
Trevor 의이 답변은 모든 철학에 비해 상당히 훌륭하지만 세부 사항에 대해 더 자세히 알고 싶습니다.
먼저 대체 레코드가 유지되지 않는 이유를 파악하십시오. 이는 예측 문제 또는 스토리지 (종이 또는 컴퓨터) 문제로 시작된 것 같습니다.
과거에 누군가는 대체품이 유용하지 않다고 생각하여 버려지거나 삭제되었습니다. 회사 문화 문제 일 수 있습니다. 이제 이것이 문제로 확인되었으므로 회사 전체에서 제기 될 수 있습니다. 이미 작성된 레코드를 유지하는 것은 쉽습니다.
원래 엔지니어가 대안을 유용하게 사용할 수 있다고 생각하더라도 스토리지 비용 (물리적 또는 컴퓨터) 때문에 문서를 보관하지 않았을 수 있습니다. 이 경우에도 여전히이 문제를 해결해야합니다. 이것이 더 이상 사실이 아닌 경우, 기록을 유지하는 것이 비용이 많이 드는 제안이 아니라는 말이 회사 전체에 퍼져 야합니다.
둘째, 다른 비교 방법을 살펴보십시오. 대체 고려 사항에는 사고와 계산의 두 가지 범주가 있습니다.
사고 비교는 개념 형태 이외의 다른 종이로 만들지 않을 정도로 빨리 버린 아이디어입니다. 이러한 아이디어가 처음에 너무 빨리 폐기 된 경우에는이를 기록 할 필요가 없습니다. 그들을 불신하려는 노력은 너무나 사소해서 다시 불신 될 것이다.
실제로 계산 단계에 적용한 대안은 어떤 형태로 유지해야합니다. 계산이나 계획을 처음 수행 한 경우 저장해야 할 것이 이미 있습니다. 아이디어가 막 다른 골목 인 것으로 밝혀 지더라도 작업은 이미 완료되었으므로 파일에 넣으십시오! 날짜가있는 한 참조 할 수 있습니다.
결정이 내려 질 때 (특히 다른 사람이 아닌 경우 파일에) 메모를 작성하십시오 . 이렇게하면 향후 시간이 절약되지만 프로세스에 단계가 추가됩니다. 이것은 일반적으로 개선 된 문서화와 함께 작동해야합니다.
마지막으로 모든 것을 데이트하십시오! 최종 기록을 유지하기 위해 이미 설치된 시스템으로 작업하고 모든 것에 날짜를 추가하십시오. 다른 구성 방법이 실패하더라도 항목의 날짜를 사용하여 대체 순서를 재구성 할 수 있습니다.
다음은 문서 아이디어와 관련하여 화이트 제품, 소비재 및 OEM 제조 방법에 대한 세 가지 일반적인 방법입니다.
프론트 엔드 (개념화) 아이디어 문서
크고, 영향력이 크며, 획기적인 아이디어이지만 현재 구현되지 않은 아이디어에 대한 프로젝트 번호를 작성하십시오. 대부분의 경우 이러한 아이디어를 1-2 페이지 문서에 문서화하기 전에 문서를 작성하십시오. 검색 엔진 기술과 소프트웨어의 성장에 따라 이러한 아이디어는 검색 가능한 데이터베이스에 저장 될 수 있습니다. 현재 인력의 과도기적 특성으로 인해 아이디어가 문서화되는 좋은 방법이라는 것을 알았습니다. 기술 및 구현 방법이 성장함에 따라 에서 기술의 세부 문서화는 관련성이 적으므로 기술을 개선하고 개선 할 가능성이 높습니다.
설계 검토 (NPD-신제품 개발)
설계는 엔지니어링 설계 결정을 문서화하는 데 도움이되는 또 다른 좋은 프로세스를 검토합니다. 이것은 더 기술적 인 문서 인 경향이 있으며, 거부 된 아이디어는 잘 문서화되지 않은 경향이 있습니다. 대부분의 조직에서 설계 검토 는 위상 게이트 모델의 일부입니다 .
백엔드 (생산 중 또는 마감 생산) 아이디어 문서
기존 변경 관리 시스템을 사용하여 새로운 아이디어를 문서화 한 조직을 찾았 습니다 . 이 시스템에서 엔지니어는 아이디어를 간단한 하나 또는 페이지 문서로 제안합니다. 아이디어는 검토되어 향후 수용 될 수 있습니다. 이 특정 조직은 SAP를 변경 관리에 사용했기 때문에 시스템은 기술 기반 검색에 적합하지 않았지만 잘 해내 지 못했습니다.
요약하면 대부분의 아이디어는 다음과 같은 이유로 보류됩니다.
따라서 장애물을 극복 할 때 아이디어가 현실적인 솔루션이되기 때문에 트랙 아이디어가 좋습니다.
참고 문헌 :
다른 사람들은 일반적으로 문서에 대해 많은 좋은 의견을 제시했지만 엄청난 도움이 될 특정 종류의 소프트웨어를 제안하고 싶습니다.
이러한 종류의 문제에 대해 버전 제어 소프트웨어 가 우수 하다는 것을 알았습니다 . 불행히도 소프트웨어 개발 외부에서는 흔하지는 않지만 다른 분야에서 따라 잡는 것은 시간 문제 일뿐입니다.
예를 들면 다음과 같습니다. 제 연구 그룹에는 대부분의 사람들이 사용 하는 Subversion 저장소가 있습니다 (일반적인 대체 소프트웨어는 git입니다 ). 버전 관리를 사용하면 프로젝트와 관련된 대부분의 파일이 거기에 있기 때문에 누군가가 떠난 후에도 연구 프로젝트의 연속성을 보장하는 데 도움이됩니다. 이론적 해석. 자세히 설명하겠습니다.
컴퓨터에 모든 파일이 들어있는 폴더가 있다고 가정 해 봅시다.
커밋 될 때 자동으로 날짜가 지정됩니다 (다른 사용자가 "업로드"라고 부르는 버전 제어 용어). 커밋 메시지는 짧은 메모 역할을합니다 (Mahendra Gunawardena가 제안했듯이 더 큰 결정을 위해 더 길고 공식적인 메모를 원할 수도 있습니다). 프로젝트 파일에 대한 변경 사항을 설명합니다. "접근 X는 불가능하다고 결정했습니다. 대신 Y를 시도하겠습니다. 접근 X와 연관된 파일을 삭제하고 접근 Y에 대한 새 CAD 모델을 작성했습니다."
그런 다음 나중에 X 접근 방식이 실제로 옳은 것으로 판단하고 삭제 된 파일을 파고 싶더라도 어렵지 않습니다. 모든 부분을 이전 버전으로 쉽게 롤백하고 계속 진행할 수 있습니다.
이 방법에는 몇 가지 추가 이점이 있습니다. 첫째, 다른 사람들과 파일을 쉽게 공유 할 수 있습니다. 그들은 저장소 (현재 버전 또는 모든 버전을 의미 할 수있는 버전 제어 용어)를 확인한 다음 정기적으로 업데이트합니다 (이를 수행하는 명령이 있습니다). 기본적으로 모든 사람이 동기화됩니다. 둘째, 기본적으로 무료로 백업 (이전 버전)을받을 수 있습니다. 그렇다고해서 정상적인 백업을 유지할 필요는 없으며 실수로 손실 된 파일을 복원 할 수있는 다른 옵션이 있다는 것입니다. 전체 리포지토리도 백업하는 것이 좋습니다.