고객이 프로젝트에 기여할 수있는 가장 좋은 방법은 무엇입니까?

우리는 고객을위한 CRM을 구축하고 있습니다. 첫 번째 주요 단계가 완료되었고 두 번째 단계가 합의되었으므로 클라이언트는 일부 작업을 선택하여 데이터베이스 스키마 및 비즈니스 프로세스를 약간 수정 하여 두 번째 단계 를 작성합니다 .

나는 이것이 실제로 실용적인지 여부를 결정하지는 못했지만, 그것이 가정 할 때, 이것을 가능하게하기 위해 조치를 취할 수있는 몇 가지 지침을 원합니다. 내가 지금까지 얻은 것입니다 :

• 지금까지 클라이언트는 대부분 사용자의 관점에서 프로젝트를 보았습니다. 분명히, 두 부분으로 된 세미나는 우리가 그를 내부 활동에 대해 소개하는 장소에서 열어야합니다.

  • 먼저 기존 데이터베이스 스키마를 보여주고 확장하여
  • 그런 다음 샘플 코드를 보여주고 스키마 향상을위한 새로운 비즈니스 프로세스를 작성합니다.
• 코드는 현재 내부 Subversion 저장소에 있습니다. 우리는 자신의 네트워크 ( 공개 VPN) 에 하나 또는 둘 이상의 공개를 설정할 수 있지만 분산 시스템이 더 잘 작동한다고 생각합니다. 나는 그런 식으로 느끼는 유일한 사람 인 것처럼 보이므로 좋은 설득력있는 주장을 사용할 수 있습니다.

• 프로덕션에서 실행되는 코드가 커밋되도록 명령 / 확인하는 방법을 잘 모르겠습니다. "x는 휴가를 가기 직전에 중요하고 문서화되지 않은 변경을 가한 것 같습니다. 이제는 그 이후로 발생한이 버그를 파악하려고합니다"재앙은 불가피합니다. 이상적으로 배포하기 전에 모든 변경 사항은 다음과 같습니다.

  • 이슈 추적 시스템에 문서화되고
  • 먼저 별도의 테스트 환경에서 발생하며
  • 자동화 된 테스트를 통과해야합니다.

  아아, 나는에 대한 징계 의심 어떤 사람들의이 우선됩니다.

플러그인 아키텍처 또는 별도의 프로젝트가 실행 가능한 옵션이 아니라고 가정하십시오 .1) 전자는 존재하지 않으며 2) 후자는 클라이언트가 기존 코드를보고 수정하는 것을 금지합니다. 주장.

이것은 가장 좋아하는 답변이 될 것입니다. 그럼에도 불구하고 여기 있습니다!

초보자가 새 차를 운전하는 것만 큼 위험 하지만 위험 하지는 않습니다.

그들이 왜 이런 일을하고 싶은지 이해하십시오. 예비 자원이있는 것이 아니라 자신을 통제 할 수있게 만드는 것입니다.

당신이해야 할 일은 다음과 같습니다

1. 클라이언트 교육-소프트웨어는 단순한 코드 이상입니다. 참여하고 싶다면 먼저 건축 측면, 디자인 등을 검토하십시오. 그들에게 질문을 제기하고 그들이 이전에 선택한 선택의 의미를 보여줍니다.

2. 항상 접근 방식에 대한 찬반 양론 옵션으로 돌아 가야하며 (이 회의를 잘 문서화해야 함) 의사 결정을 내릴 수 있도록해야합니다. 적어도 그들은 자신이 많이 알지 못하거나 자신에 대한 소유권을 가지게 될 것임을 인식하기 시작할 것입니다.

3. 원하는대로 코딩 할 수 있도록 분기와 같은 별도의 공간을 만들 수 있습니다. 커밋이나 병합 전에 테스트해야합니다.

합병증이 발생할 수 있음을 알고 있지만 모든 문제는 기회입니다. 모든 것이 잘 진행된다면, 고객은 실제로 내부 문제에 대해 더 많은 감사를 표할 것이며, 당신이 잘한 일을 알고 있기 때문에 더 나은 신뢰를 얻게 될 것입니다!

추신 : 통찰력을주기 위해 – 나는 인도 출신입니다. 경영진이 실제로 실마리가없는 많은 IT 상점을 알고 있습니다. 그들은 일반적으로 프로젝트가 쓰레기통에 들어 가지 않도록 클라이언트가 추가 리소스를 사용한다고 생각하지 않습니다 (심지어 행복하다고 느끼지 않습니다)! 이것은 그들에게 잘 작동합니다. 그들은 모두 하나의 사고 방식 "당신이 무엇을 말하는가!"와 함께갑니다. 이것은 내 자신의 국가를 모욕하기 위한 것이 아니라 공동 개발 이 그렇게 나쁜 생각이 아님 을 보여주기 위한 것입니다. 결국 많은 경영 전문가 들이 비즈니스 문제에 대한 " 프로슈머 접근 " 이라고 묘사 합니다.

아야 .. 당신은 옳은 생각을 가지고 있지만 이것이 어떻게 지저분해질 수 있는지를 보았습니다. 현재 그러한 응용 프로그램을 유지하고 있습니다.

고객이 프로젝트에 직접 기여 해야하는 실제 이유를 찾으십시오 . 그들이 실제로 프로젝트를 현실화 할 수있는 것보다 더 빨리 프로젝트를 수행하기를 원하는가? 그들은 이미 변경을 원하지만 사양을 변경하거나 추가 기능을 요청하는 데 추가 비용이 발생하는 것을 두려워합니까? 내부 개발 리소스가 프로젝트에서 더 많은 제어 및 입력을 원하거나 내부 개발자를위한 바쁜 작업을 찾고있는 조직에 정치적 투쟁이 있습니까? (이 마지막 것은 집에 가까이 닿았습니다)

그들의 진정한 동기가 무엇인지 찾아 내고 가능한 경우 해결하십시오. 그들이 제안한 사실은 문제가 길을 가고 있다는 큰 경고 신호입니다. 이런 일에 동의하기 전에 그들의 실제 우려를 완화하려고 노력하십시오. 일어날 가능성보다 더 많은 것은 그들이 프로젝트에 대한 통제력을 강화하고 단계적으로 철폐 시키거나 대규모 혼돈과 실패한 프로젝트를 야기 할 것이기 때문입니다.

편집 : 불행히도 그 배는 당신을 위해 항해했지만 아직 절망하지 않습니다. 앞으로 오는 고통을 크게 최소화하기 위해 여전히 할 수있는 일이 있습니다. 그들의인지 절대 확인 상관없이 ONE AND ONLY ONE 프로젝트 매니저 (Project Manager) 및 제품 OWNER 이 사람이 조직 / 회사와 연결되어 있는지. 이 사람은 스프린트를 계획하고, 사용자 스토리를 포함 또는 제거하며, 회사 및 고객 회사의 리소스에 작업을 할당 할 수 있어야합니다. 어떤 일이 발생하든 회사의 개발 리소스가 고객 리소스와 분리되어 작동하지 않아야하며, 더 중요한 것은 하지 마십시오.회사의 개발자가 프로젝트 관리자 또는 제품 소유자에게보고 할 수 있습니다! 그들은 계약에 포함되지 않은 무료 작업을 완전히 이용하거나 자신의 프로젝트에서 당신을 막을 것입니다. 확실합니다.

법적인 관점에서, 당신은 기본적으로 "지뢰밭을 가로 질러 눈가리개를 타는 가장 좋은 방법은 무엇입니까?"라고 묻습니다.

프로그래밍 관점에서 더 많은 정보를 요청합니다. 클라이언트가 요구하는 것은 일종의 사용자 정의 EAV 시스템을 사용하거나 시스템에 추가 할 수있는 후크를 사용하여 구현할 수 있습니까? 이상적으로는 다양한 이유로 고객의 코드를 가능한 한 분리하여 유지하고 싶습니다.

일반적으로 여기에서 고객 역할을하는 사람이 있습니다. 솔직히이 문제는 없을 것입니다. 만약 이것이 멀다면 CI 설정과 QA 설정을 사용하여 소스를 제어 할 수 있기 때문입니다. 이러한 배치는 설정하기가 매우 어려울 수 있습니다. 컨설턴트들로부터 특히 많은 일이 일어나고 있습니다. 프로세스가 청구 가능 시간을 방해하는 것 같습니다.

나는 당신의 관점이 정직하게 약간 비뚤어져 있다고 생각합니다. 먼저 코드베이스가 아니라 코드베이스라는 점을 명심하십시오. 둘째, 대부분의 경우 클라이언트 측의 IT 샵은이 제품이 설계대로 작동하고 유지 관리, 관리 및 지원이 용이하도록하기 위해 훨씬 더 많은 동기를 부여합니다. 버그를 해결하기 위해 다시 다이빙 하는 것은 대부분의 컨설턴트와 달리 청구 가능한 시간 이 아닙니다 . 또한 코인의 운영 측면을 소유 할 때 쉽게 구성 가능하고 예측 가능한 방식으로 실패하는 것을 구축하는 것이 훨씬 더 중요합니다. 개발 직원의 일부가 청구 가능 시간에 제약을받지 않기 때문에 더 높은 품질의 프로젝트로 끝날 수 있습니다.

DCVS는 그것이 작동하는 방법에있어서 그것이 일어날 수 있다면 확실히가는 길입니다. 중립적 인 것을 선택하면 (bitbucket, github) 도움이 될 수 있습니다. CI를 제자리에 두는 것도 여기에서 신의 선물입니다. 모든 사람이 마지막 커밋에서 엉뚱한 것을 알면 엉망이되는 것이 어렵습니다. 일반적으로 공급 업체에 강제로 적용해야하는 CI를 통해 배포를 강제 할 수 있다면 모든 변경 사항이 적용되도록 할 수 있습니다. 교육적인면에서 며칠 동안 고객과의 페어링을 고려 했습니까? 그것은 당신이 필요로하는 측면 유대를 설정하는 좋은 방법 일 수 있습니다. 전반적으로 가장 좋은 방법은 모든 사람이 같은 팀에 있다는 것을 확신시키는 것입니다. 그들은 같은 팀에 있기 때문에.

이것은 기술적 인 문제이기 때문에 많은 관리 문제인 것 같습니다. 컨설팅 및 소프트웨어 회사에서 이와 같은 상황을 처리했습니다. 전체적으로 "고객은 소프트웨어에서 얼마나 많은 가치를 얻을 수 있습니까?" "후반 작업을 유지하려면 얼마나 많은 노력이 필요합니까?" 이것은 실제로 당신에게 좋은 상황입니다. 많은 고객들이 그들의 직원들이 관여하고 있다고 주장합니다. 그래도 많은 작업이 필요합니다.

끝까지 염두에두면 좋은 작업 성명서 가 필요합니다 . 이것은 당신이 갈고리에있는 것과 갈고리에있는 것을 나열 할 것입니다. 역할과 책임 매트릭스 관련된 각 항목을 소유하고있는 사람이 바로 통보 할 필요가있는 설명 덜 율법 문서입니다. 이 두 가지 모두 각 작업이 무엇인지 낮은 수준 (추정하기에 충분히 낮음)으로 나열한 잘 정의 된 작업 분류 체계 가 있다고 가정합니다 .

작성과 관련하여 일반적으로 역순입니다. 범위 (귀하가 이미 가지고 있음)-> WBS (있을 수 있음)-> 역할 및 책임 매트릭스-> SOW.

소유권이 명확하게 정의되면 코드와 환경을 관리 할 차례입니다. 코드 관리 도구에 상당히 무관심합니다. 내가 말할 것은 핵심 팀 외부의 누군가가 수행 한 모든 것에 대해 코드 검토를 수행하는 것이 중요하다는 것입니다. 사용중인 도구가 이것을 플래그 지정하면 더 좋습니다. 이전에 결정한 주요 아키텍처 결정에 위배되는 무언가를 고정시키는 사람을 피하려고합니다. 4 개의 눈 개념 (모든 것을 검토하는 2 개의 추가 눈)은 가장 중요한 전술 결정입니다.

환경도 관리하기가 어렵습니다. 일반적으로 "우리는 환경에 대한 작업을 수행하고, 작업이 완료되면 사용자에게 전달됩니다."공급 업체와 고객 모두가 어려움을 겪는 상황을 경험했습니다. 상황이 더 복잡하게 들립니다. 프로젝트가 끝날 때까지 환경에서 작업 할 수있는 방법을 찾아 보라고 조언합니다. 환경 관리에서 클라이언트를 훈련시키는 방법을 찾을 수 있다면 (이것이 훌륭하다고 가정하지 마십시오), 모든 것이 좋습니다.

다른 몇 가지 경고 ...

1. 고객이 팀과 생산성이 같다고 가정하지 마십시오. (도메인 지식에 대한 놀라움, 소프트웨어에 따른 속도에 대한 놀라움이 있습니다.)

2. 고객이 귀하의 방법론을 알고 있다고 가정하지 마십시오.

3. 고객이 팀의 업무 윤리를 공유한다고 가정하지 마십시오. (나는 위와 아래로 놀라움을 모두 보았다.)

4. 많은 시간 훈련과 공동 위치를 보내십시오.

5. 고객에게 문제 해결을 가르치는 데 1 시간이 걸리면 앞으로 많은 시간이 절약됩니다.

6. 고객을 활용하여 내부 조직을 통해 작업하고 컨텐츠 및 도메인 질문에 대한 전문가를 찾으십시오.

7. 고객을 활용하여 조직 교육을 판매하십시오.

8. 기본적으로 개발 프로세스에 고객을 참여 시키면 전문 서비스 회사처럼 생각하게됩니다. David Maister 는 이 주제에 관한 최고의 책 을 썼습니다 . 20 % 만 관련이 있어도 읽을만한 가치가 있습니다.

이러한 모든 경고에도 불구하고 팀의 고객을 포함하여 구매자에게 더 가까이 다가가는 것은 놀라운 일입니다. 이 고객은 나중에 참조 할 가능성이 가장 높은 고객입니다. 이 상황을 최대한 활용하는 행운을 빕니다!

고객에게 모든 것이 어떻게 설정되어 있는지 반드시 확인해야하며, 첫 번째 단계에서 사인 오프해야합니다. 고객이 직접 무언가를 편집 할 수 있도록 되돌려 보내야하며 문제 추적 시스템에 입력되고 나머지 작업에 우선 순위를 둔 변경 요청을 작성해야합니다. 계약 범위를 벗어난 요청을 결정하는 것은 귀하와 귀하의 고객에게 달려 있습니다. 이것이 발생하는 경우 일종의 변경 관리 워크 플로우 / 문서 에서이 작업을 어떻게 수행해야합니까? 하나를 작성하지 말고 고객이 변경 사항을 처리 할 수있는 프로세스라는 것에 동의하도록 클라이언트에게 제안하십시오. 쓰기. 그렇지 않으면 아무것도 잘못되지 않도록기도하는 것 외에는 할 수있는 일이 많지 않습니다.