소프트웨어 개발에 흔히 마주치는 현실과 해결 방안

 

 

오늘은 ITWORD 라는 사이트에서 오피니언을 보다가 IT근무 하시는 분들에게 도움이 될거 같은 컬럼이 있어 가져 왔습니다.

 

 

 

 

 

글의 본문은 아래와 같습니다.

https://www.itworld.co.kr/article/3958749/%ec%95%8c%eb%a9%b4%ec%84%9c%eb%8f%84-%ed%94%bc%ed%95%a0-%ec%88%98-%ec%97%86%eb%8b%a4-%ec%86%8c%ed%94%84%ed%8a%b8%ec%9b%a8%ec%96%b4-%ea%b0%9c%eb%b0%9c%ec%9d%98-4%ea%b0%80%ec%a7%80.html

“알면서도 피할 수 없다” 소프트웨어 개발의 4가지 역설

 

 

 

아래 내용은 위의 내용이 공감되서 우리가 해결 할수 있는 생각을 표로 정리 하였습니다.

 

요약된 역설 제목	설명	개선방안
끝을 모르는 일정	개발 시간은 정확히 예측하기 어렵지만, 항상 마감일은 요구된다.	- 불확실성을 고려한 일정 계획 - 점진적 납품과 빠른 피드백 - 고객과의 투명한 소통
인력 추가가 늦춤 효과	프로젝트가 늦어졌다고 사람을 더 투입하면, 오히려 일정이 더 늦어진다.	- 초기 인력의 전략적 구성 - 온보딩 및 커뮤니케이션 효율화 - 소수 정예 팀 유지
고수가 될수록 손은 덜 움직인다	경험이 쌓일수록 직접 코딩보다는 관리와 조율에 집중하게 된다.	- 영향력을 넓히는 기회로 인식 - 멘토링과 코드 품질 개선에 집중
도구는 늘었는데 속도는 그대로	개발 도구는 발전했지만, 설정과 복잡성도 같이 늘어났다.	- 필수 도구만 선택하여 단순화 - 자동화 도입과 반복 가능한 환경 구성
완성은 없다, 계속될 뿐	소프트웨어는 출시 이후에도 끝없이 수정과 개선이 필요하다.	- 완벽보다 배포 가능 상태에 집중 - 지속적인 개선과 유지 전략 수립

 

 

그래서 저희는 개발자한테 화면 개발시 시간을 재보고 개발을 하자고 제안 하고 그것으로 발생 하는 추가 요구 사항에 대해 다시 시간을 재어 평균 시간을 측정 하는 연습을 합니다.

 

그래야지 about time 측정이 된다고 생각하고 그것으로 wbs 실제적으로 측정 할수 있습니다.

 

객관적인 시간을 제공해야지 고객과 신뢰가 생깁니다.

 

 

디지털 트렌스포메이션의 변화를 위해 페리(pperi)는 동참 할것입니다.

도움이 필요 하시다면 언제든지 연락 주시기 바랍니다.

저희 pperi는 peri가 아닌점을 구독자님이 인지 하여주시기 바랍니다.