소프트웨어 개발 프로세스의 추악한 진실

이미지 출처: perfectdigital.com

이 사진 아시죠?

큰 불일치와 비전 부족이 나타날 수 있음을 잘 보여준다고 생각합니다. 소프트웨어 개발 프로젝트 모든 참가자와 관련된 사람들 사이에 문제는 클라이언트가 (이론적으로) 최종적인 제품 비전을 제시하고 팀. 그런 다음 더 많은 오해와 오해가 발생하고 결국에는 프로젝트 는 금방 잘못된 개발의 길로 접어들게 됩니다.

위의 그래프를 분석하는 동안 가능한 모든 위협을 단계별로 제시하고 이에 대처하는 방법을 제안하겠습니다. 바로 시작하겠습니다!

1. 고객이 아이디어를 어떻게 설명했나요?

처음부터 제품 비전에 차이가 있을 수 있습니다. 왜 그럴까요? 그 이유는 매우 간단합니다. 모든 사람은 현실을 자신만의 방식으로 해석하고 마음속에 무언가에 대한 아이디어를 가지고 있으며 이 비전을 상대방에게 정확하게 제시하지 못할 수도 있습니다. 만들고자 하는 제품을 말로 설명하면 개발팀이 의도한 것과 다른 방식으로 비전을 이해할 가능성이 높습니다.

물론 이를 피할 수도 있습니다. 가능한 한 빨리 시각화를 시작하고 스케치를 기반으로 제품 기능의 개별 요소에 대해 논의해야 합니다. 흥미롭게도 첫 번째 스케치는 일반적으로 최종 제품과 공통점이 없습니다. 그러나 이 단계에서 가장 중요한 것은 비전을 일관성 있게 만드는 것입니다.

2. 프로젝트 리더는 이를 어떻게 이해했나요?

첫 번째 그림과 두 번째 그림이 왜 이렇게 다른지 궁금하신가요? 프로젝트 리더는 항상 제품 비전을 면밀히 검토합니다. 하지만 본질적으로 전체에 대한 책임이있는 사람이 중요합니다. 소프트웨어 개발 프로세스, 제품과 관련된 문제와 요구 사항을 완전히 이해합니다.. 프로젝트 리더는 명확한 "큰 그림"을 가지고 있어야 합니다. 보시다시피 두 이미지의 기능적인 측면은 다르지 않습니다. 단지 모양만 다를 뿐입니다. 이 점을 더 잘 이해하기 위해 첫 번째 그림으로 돌아가 보겠습니다. 프로젝트 초기에는 스케치가 없었기 때문에 이미 오해를 불러일으켰습니다. 제품의 기능은 정확하지만 디자인은 완전히 다릅니다.

3. 분석가는 어떻게 설계했나요? 그리고 4. 프로그래머는 어떻게 작성했나요?

때때로 분석가와 개발자는 사용자의 요구 사항이나 확립된 비즈니스 목표를 알지 못하는 경우가 있습니다. 그들은 전체 프로젝트의 작은 부분만 보고 자신의 주요 관심사를 파악합니다. 이들은 더 넓은 관점에서 바라보지 못하며, 특히 많은 개발자가 동시에 작업하는 대규모 프로젝트의 경우 더욱 그러합니다.

다른 예를 들어볼 수도 있습니다. 예를 들어 제품 소유자가 해결해야 할 문제를 잘못 설명하는 경우가 발생할 수 있습니다. 여기에는 불완전한 정보를 제공하여 개발자나 디자이너가 자신만의 해석을 만들어내고 제품이 의도한 개발 경로에서 점점 더 벗어나는 경우가 포함됩니다.

이를 어떻게 바꿀 수 있을까요? 좋은 해결책은 프로젝트에 핵심적인 역할을 하는 사람들이 프로젝트에 대한 자세한 지식, 이른바 "큰 그림"을 갖도록 하는 것이라고 생각합니다. 오해가 생길 경우, 그들이 더 쉽게 이해할 수 있을 것입니다. 소프트웨어 개발 프로세스 올바른 길로 되돌아갑니다. 따라서 모든 사람이 개발된 기능의 작은 부분만 보게 되면 비전에 대한 오해로 인해 위협이 될 수 있다는 점을 기억하세요.

5. 비즈니스 컨설턴트는 어떻게 설명했나요?

여기서 문제는 간단합니다. 제품이 팔려야 합니다. 예를 들어 정원을 위한 간단한 그네가 특별한 요소를 갖추려면 어떻게든 눈에 띄어야 합니다. 아이디어는 잠재적 구매자를 설득하는 것입니다. 마케팅 및 영업 부서는 제품이 독특하다는 것을 보여주기 위해 모든 것을 할 것입니다.

6. 프로젝트는 어떻게 문서화되었나요?

문서 누락은 매우 흔한 문제입니다. 때로는 문서를 작성하는 동안 제품 개발 는 불필요한 시간 낭비처럼 보입니다. 이것은 실수입니다. 저는 종종 문서에서 변경 사항이 더 빨리 이루어진다고 말합니다. 코드를 클릭해 보세요. 또한 변경 사항을 추적하기 위해 문서를 참조하는 것이 더 쉽습니다. 문서가 없는 프로젝트는 비전을 놓칠 위험이 매우 높습니다.

7. 어떤 작업이 설치되었나요?

이 단계는 서버에 환경을 배치하는 것을 말합니다. 프로그래머와 분석가에 대한 요점에서와 같이 전체 데이터가 없고 통신 공백이 있는 경우 필요한 환경의 일부만 생성된 것으로 판명될 수 있습니다.

8. 고객에게 요금이 어떻게 청구되나요?

이는 잘못된 커뮤니케이션, UX 부족 등의 결과입니다. 오류가 발생하면 개발 시간이 늘어납니다. 그리고 시간은 곧 돈이니까요. 제 힌트는 애자일에 따라 프로젝트를 실행하는 것입니다.최고의 커뮤니케이션 표준을 유지하고 명확한 예산 지침을 유지하세요. 그렇게 함으로써 이러한 문제를 피할 수 있을 것이라 믿어 의심치 않습니다.

9. 어떻게 지원되나요?

고객들은 종종 제품 구축에만 집중하고 거기서 끝내는 경우가 많습니다. 하지만 우리는 많은 변화와 기술 혁신의 시대에 살고 있기 때문에 지속적인 기술 지원이 필요합니다. 구식이 되어 갑자기 작동이 멈추고 제품이 가치를 잃는 상황을 피하기 위해서입니다. 이 측면도 잊어서는 안 됩니다.

10. 고객에게 정말 필요한 것은 무엇인가요?

마지막 지점에 도달했습니다. 첫 번째 그래프와 마지막 그래프 사이의 불일치를 보세요. 결국 둘 다 고객의 관점과 관련이 있습니다. 왜 이런 일이 일어날까요? 설문조사 결과는 항상 응답자의 실제 요구 사항과 다릅니다. 연구자의 질문에 답하는 동안 사용자는 자신의 장점을 최대한 보여주고 싶어 합니다. 따라서 그들은 종종 진실하게 응답하지 않습니다.가 아니라 자신이 대답해야 한다고 생각하는 방식으로 대답합니다. 기본적으로 다른 사람의 부정적인 평가에 노출되는 것을 원하지 않습니다. 여기 작은 힌트가 있습니다. 지침에 좋은 답변도 나쁜 답변도 없다는 점을 언급하세요.

또 다른 차이점은 어디에서 나타날까요? 사람들은 종종 자신이 진정으로 원하는 것이 무엇인지 모릅니다. 처음에는 제품에 10가지 기능이 필요하다고 했다가 나중에 실제로는 3가지 기능만 사용하는 경우가 많습니다.

그렇다면 이 문제를 어떻게 해결할 수 있을까요? 사용자에게 무엇을 원하고 필요한지 물어보는 것 외에도 신뢰성을 유지하기 위해 가급적 실제 제품을 사용해 제품을 테스트할 수 있도록 하세요. 제품을 만드는 동안 더 많은 테스트를 수행할수록 결과가 정확할 가능성이 높아집니다.

요약

회원으로 가입한 경우 소프트웨어 개발 프로젝트에서 위의 오류를 복사하지 않도록 제 예제를 기억하고 결론을 도출하세요. 그리고 이러한 개념은 처음부터 제품(애플리케이션)을 구축하는 데 매우 중요하다는 것을 기억하세요:

- 좋은 UX와 테스트를 통해 사용자에게 실제로 필요한 것이 무엇인지 파악할 수 있습니다,

- 프로젝트 내 커뮤니케이션을 통해 프로젝트의 핵심 담당자가 문제와 요구 사항을 깊이 있게 이해할 수 있습니다,

- 에 따라 제품을 개발합니다. 애자일,

- 기술 지원도 잊지 마세요.

자세히 읽어보세요:

– 원격 개발자를 효과적으로 관리하는 방법은 무엇인가요? CTO를 위한 가이드

– Python 대 루비? 제품 개발에 어떤 기술을 사용해야 할까요?

– 나만의 마켓플레이스를 구축하고 개발하기 위한 빠른 가이드입니다. 알아야 할 사항은 무엇인가요?