문서 히스토리를 남기는 것은 프로젝트가 착수되는 시점부터 문서가 사용되는 최신 시점까지 상황에 따라 의도와 방향이 달라진 점과 날짜, 작성자를 기록하는 작업입니다.

 

 

주로 문서 앞 일부를 차지하는 문서 히스토리 페이지는 업무에 대한 디테일한 내용이 아니라 중요하지 않게 여겨집니다.

하지만, 프로젝트를 통해 시스템을 만들고 운영하는 관리자는 시스템을 구축/운영할 때 산출되는 문서가 본인의 자산이며 실력을 반증하는 도구가 됩니다.

 

  • 과거 현업 또는 개발사에게 들었던 내용과 본인이 말했던 내용 중 아무리 중요한 내용이라 할지라도,
    사람이라면 시간이 지남에 따라 기억이 왜곡되거나 없어질 수 있습니다.
  • 불과 1주일 전 자신의 입장과 의도가 지금과 동일하다는 보장은 아무도 할 수 없습니다.

 

히스토리가 빠짐없이 작성된 문서는 시행착오를 줄여주며 당시의 상황과 의도를 파악하는데 중요한 역할을 하게 됩니다.

대체로 큰 규모의 프로젝트일수록 문서 히스토리 기록의 중요도가 높아집니다.

 

히스토리가 기록되지 않은 문서는 현 시점에 참고해도 이슈가 없을지, 어떤 이유로 현재 상황에 도달하게 되었는지 확인할 길이 없으며, 과거의 상황을 모르고 의도를 오해하는 일을 만들게 됩니다.

 

 

* 문서 히스토리 페이지 구성요소
1) 버전
 - 정수 : 실제 운영이 가능한 버전 (현업 제공o)
 - 소수점 : 실제 운영과 유사한 환경에서 테스트를 위해 배포한 버전 (현업 제공x)
2) 개정일자
3) 변경내용
 - 문서가 변경된 이유에 대한 요약 설명
 - 현업과 개발사 간 의사결정이 완료되어 문서화된 내용이 반영되었다면 기록
4) 작성자 (부서+이름+직무)
5) 승인자

 

개발자가 말하는 "안됩니다"는 단순히 "하기 싫습니다"라는 뜻이 아닙니다.

 

개발자는 물론 도구가 아닙니다.

제품을 생산하는 기계마저도 정확한 명령과 정해진 납기에 맞춰 제품을 생산하게 되어있습니다.

 

현업은 개발자에게 업무를 요청할 때, 다른 현업부서와 동등하게 부담을 가지고 요청해야 합니다.

개발자도 현업에게 받은 업무를 성실히 수행해야 하며, 현업의 입장과 언어에 맞춰 답변을 해야 합니다.

 

개발자가 설령 도구가 되어 일을 한다고 하더라도, 아래 상황에 따라 "안됩니다"를 시전할 수 있습니다.

1. 요구사항이 명확하지 않은 경우
 - 소프트웨어로 설명하기 어렵거나 정의되지 않아 모호한 현업의 요구사항
2. 요구사항이 명확하더라도 원하는 일정을 맞출 수 없을 경우
 - 한정된 자원 내에서 운영되는 공수를 고려하지 않은 상황
 - 개인에게 분담되는 업무의 양이 과다할 경우
3. 시스템이 구현되는 환경(인프라)의 제약이 존재할 경우
 - 보안 및 정책의 제약으로 인해 조직의 의사결정이 수반되어야 할 경우
4. 실제로 기술 구현이 불가능한 경우
 - 하드웨어의 제약, 능력의 한계(AI, ML 등)

물론, 개발자도 사람인지라 매너리즘에 빠져 정말로 하기 싫어서 안된다는 말로 방어하는 경우도 종종 있습니다.

하지만 모두가 그런 시선으로 개발자를 바라본다면, 현업과 개발자의 갈등을 좁혀나갈 수 없어 결국 서로 원하는 바를 얻지 못하게 됩니다.

 

Tech PM - 비지니스 가치가 있는 소프트웨어를 발의하고 기획/설계/일정관리/오픈/운영까지 A-Z를 관리

 

소프트웨어 구축하는 프로젝트를 발의하고 시스템을 기획/설계하는 Tech PM은 아래와 같은 일을 해야 합니다.

1. 개발자가 이해할 수 있는 수준의 요구사항 정의
2. 비지니스 상황에 맞춘 구축 우선순위 선정 판단
3. 간결하지만 명료한 문서작성 기술

기획된 시스템의 비지니스 측면 가치에 대한 고민과 구축된 시스템이 Product(제품)로서 안정적으로 고정적인 수익을 창출할 수 있도록 설계해야 합니다.

 

Tech PM은 소프트웨어 기반의 회사에서 개발자와 현업이 서로 원하는 바를 얻게끔 만들어주는 역할을
책임을 가지고 헌신적으로 실천할 수 있어야 합니다.

 

프로젝트 매니저는 이 모든 고민을 문서로 남길 수 있어야 하며, 상시 보고할 수 있는 준비가 되어 있어야 합니다.

1. 문서 히스토리
2. 메뉴구조도
3. 요구사항 정의서 2부 (현업, 개발사)
4. 테스크플로우
5. I.A(정보구조도)
6. 와이어프레임
7. 화면정의서
8. 기능명세서
9. 플로우차트
10. ERD,  다이어그램 등

'IT > Tech PM' 카테고리의 다른 글

[Tech PM] 프로젝트란? Tech PM이란?  (0) 2023.08.30
[Tech PM] 요구사항 정의서(개발사)  (0) 2023.07.30
[Tech PM] 요구사항 정의서(현업)  (0) 2023.07.30
[Tech PM] 메뉴구조도  (0) 2023.07.30
[Tech PM] 문서 히스토리  (0) 2023.07.30

 You must set the Enterprise Structure of your company (commonly referred to as the "organizational data" in SAP) before you can process SD transactions. For example, without a sales area it is not possible to create a salea order in SAP.

 This organizational data reflects the structure of your business. Every transaction occurs within this structure. The organizational data is like the steel girders in a building, so setting it up correctly is essential. Once it is set, changing the Enterprise Structure of the business will be time consuming.

 The more thought you give to the organizational structure, the easier mySAP ERP SD will be to configure and use. You must understand how the business functions and have exhaustive knowledge of the impact of using specific elements to map the companies organizational structure into mySAP ERP.

 Organizational data is comprised of:

  • A Sales Organization An organizational unit that sells and distributes products, negotiates terms of sale, and is responsible for these transactions.
  • A Distribution Channel The channel through which materials or services reach customers. Typical distribution channels include Internet sales, wholesale, retail, and direct sales. You can assign a distribution channel to one or more sales organizations. A customer can be delivered from multiple distribution channels. A material master record can be maintained with different sales organization and distribution channel views, allowing different data to be accessed-for example, the delivering plant.
  • A Division Product groups can be defined for a wide-ranging spectrum of products. For every division you can make customer-specific agreements on, for example, partial deliveries, priving, and terms of payment. Within a division you can carry out statistical analyses or set up separate marketing.

 Figure 1-14 shows a basic organizational structure. In sales organization 1000, SD business transactions can be carried out for distribution channel 10 and 20 and division 01 and 02. In sales organization 2000 transactions can only be processed through distribution channel 10 and division 01 and 02. Likewise, transactions in sales organization 3000 can only be done through distribution channel 10 division 01.

 Sales organizations should be kept to a minimum; try to have only one per company code. You should have a very good business reason to have more than one sales organization per company code. For example, only have another sales organization if the company sells completely differently in an area-for example, if sales processed in Los Angeles are handled differently to sales processed in San Francisco.

 A rule of thumb is that if the material can be sold in both sales organizations and there is one company code, them there should only be one sales organization.

 

(FIGURE 1-14 Organizational data in SAP)

 

 Master data records are multiplied by each additional organizational elemen you have. Thus, 10 customer master records with 2 sales organizations, 2 distribution channels, and 2 divisions would have a total of 80 customer master record views. Add another sales organization and you have 120 customer master record views.

 Adding divisions does not multiply the material master views; however, it does multiply the customer master views. For example, add a division to our 80 customer master views and we suddenly have 120 customer master views. However, add the division to the material master views, and we still end up with 80.


TIP To reduce the master data you require, you can combine sales areas for customer master data purposes-see the Implementation Guide (IMG | Sales and Distribution | Master Data | Define Common Distribution Channels (and Division)).

 

 We know a sales area is compiled of a sales organization, a distribution channel, and a division. A sales area is used for reporting purposes; all data relevant for sales can be defined per sales area. For example, you can define pricing per sales area, or do your sales information analyses per sales area. You can also control configuration based on the sales area-for example, you can allow some sales processes for one sales area (for example, product samples), but not for another.

+ Recent posts