jongfeel
commented
3 months ago EoA(Essence of Agility)를 생각하라 에서
데이비드 토머스, 앤드류 헌트 < 실용주의 프로그래머 > 책을 또 언급 https://github.com/jongfeel/BookReview/issues?q=is%3Aissue+is%3Aclosed+milestone%3A%22The+Pragmatic+Programmer+20th+anniversary+edition%22
Chapter 5 소프트웨어가 제대로 된 제품이 되기까지
명품은 비싸다
핵심은 모든 상황에 대해 ‘정직하게’ 대응하는 것입니다. 자신의 입장을 덮어두거나 무시하는 것은 피해야 합니다. 최종 목표인 최고의 소프트웨어와 서비스를 만들어 내기 위해선 고객과의 상호작용을 소중히 여겨야 합니다. 내 맘에 안 든다고, 그럴 리가 없다고 덮어놓거나 무시해서는 안 됩니다.
그래서 명품은 비쌉니다. 인내의 값은 그만큼 비싸지만 그 가치는 그만큼큰 법입니다.
인간의 존엄함을 지켜야 한다
인간의 존엄성은 어떠한 상황에서도 침해되어서는 안 되며, 이 원칙이 무너지면 우리는 불확실성을 다루기 어려워질 것입니다. 존엄과 겸손을 기반으로 한 팀원들 간의 존중과 상호작용은 우리가 최고의 제품을 개발하는 데 있어 필수적인 요소임을 명심 해야 합니다.
EoA(Essence of Agility)를 생각하라
첫 번째로, ‘큰 손실 피하기 (avoid big loss)’입니다. 어떤 일이든 그 일을 수행하지 못한다고 할 때, 이에 대한 대책을 마련해야 합니다.
두 번째로, ‘계속 배우면서 나아가기 (learn as you go)’입니다. 지속적으로 피드 백을 받아들이고 학습하며, 새로운 정보를 얻어 나가야 합니다.
세 번째로, ‘핵심적인 것을 일찍 적은 노력으로 성취하기 (achieve critical early with less effort)’입니다. 어떤 일의 핵심을 결정하려면 타임박싱 (time boxing)과 같이 시간을 제한하고, 그 안에서 해야 할 일과 하지 말아야 할 일에 대해 신중하게 고민해야 합니다.
마지막으로, ‘유연하게 대처하기 (be flexible)’입니다. 어떤 일이 어떻게 진행될지 예측할 수 없다는 인식을 가져야 합니다.
고객별로 소프트웨어나 서비스를 만들 때 기억해야 할 일
공통 – 가능하면 소프트웨어/서비스 사서 쓰세요
고객이 정말 원하는 것을 찾아내고 이를 제공하는 것이 핵심입니다. 의외로 고객이 원하는 건 ‘깔 끔한 소프트웨어나 서비스’가 아니라 ‘문제 자체의 해결’인 경우가 많습니다. 뒤에서 무언가 수동으로 처리하더라도 문제가 해결되느냐 아니냐를 더 중요하게 여깁니다.
소프트웨어나 서비스 프로젝트 관리에 대한 감이 잡히지 않는다면, 다음 세 권의 책을 추천해 드립니다. 첫째로, 『제품의 탄생』 은 제품 기획, 준비, 운영에 관한 다양한 방법을 상세하게 정리한 백과사전급 자료입니다. 둘째로 『프로덕트 매니지먼트』 는 실제 프로젝트를 관리하는 데 사용할 수 있는 방법들의 원칙과 방법론, 고객 개발 전략까지 많은 이야기들을 담고 있습니다. 셋째로, 『함께 자라기』 는 불확실한 소프트웨어 및 서비스 개발에 대한 접근 방법을 새롭게 제시하며 우리가 가진 많은 편견을 깨는 내용을 담고 있습니다.
당신이 초기 기업의 창업자라면
첫째로, ‘정말 랜딩 페이지 하나로도 얼마나 수요가 있는지 확인하고 또 확인하라’는 점입니다. 둘째로, ‘갑자기 비싼 개발자 채용이 어려울 때’에 대처하는 방법을 고민해야 합니다.
당신이 기업의 임원이라면
첫째, 일정을 ‘분할하여’ 달성한다고 생각해야 합니다.
두 번째로, 프로젝트의 기한을 ‘개발 조직의 추산 없이’ 위에서 ‘한 달 내’, ‘석달 내’라고 정해서 내리면, 이 프로젝트가 예상보다 어렵고 복잡할 것이라는 사실을 고려하지 않은 채로 진행될 가능성이 높아집니다. 이로 인해 어디인가 보이지 않는 곳에서 무리한 작업이 나타나고, 이것으로 프로젝트의 불확 실성은 더 커질 수 있습니다.
세 번째로, ‘이왕이면 다홍치마’를 피해야 합니다. 핵심 기능과 핵심 가치를 우선적으로 개발하고 전달하는 데 집중해야 합니다.
마지막으로, 제품 또는 서비스를 출시하기 전에 반드시 모든 이해 당사자가 직접 사용하고 경험해 보게 해야 합니다.
당신이 공공기관의 기관장이라면
공공기관이라면 공공기관이 할 수 있는 일을 해야 합니다.
첫째로, 공공기 관은 민간 기업과의 경쟁을 지양해야 합니다.
둘째로 특별히 데이터를 제공할 때, 기계가 읽을 수 있게 (machine-readable) 제공해야 합니다. 문서라면 HWP 말고, 국제 표준 문서 포맷인 오픈오피스 문서 파일 (openoffice document file, ODT)이나 마크다운 (markdown)으로 제공해야 합니 다.
셋째로, 영국 정부의 ‘정부의 디자인 원칙’을 여러 번 반복해서 읽어 보시 기를 권장합니다.
넷째로, 조달 입찰 구조의 혁신이 필요합니다. 현재의 조달 입찰 구조는 반복적인 개발을 허용하지 않으며, 이로 인해 한국 정부의 IT 경쟁력 개선에 대한 우려가 있습니다.
마지막으로, 우수한 개발자들을 계속 육성하기 위해, 교육 개혁 및 IT 교육 기관이나 교육 스타트업에 예산을 배정해야 합니다.
우리는 결국 끝까지 가야만 실체를 알 수 있다
정보가 가장 없는 때, 일찍 결정하지 말고 탐험하라
우리 손에 있는 지도는 지역의 ‘영역’ 만을 나타내거나 불완전한 정보만을 담고 있습니다. 그러므로 우리는 지속적 으로 모험하면서 지식을 확장해 나가야 합니다. 불완전한 지도를 완성한다고 생각해야 합니다. 이 과정에서 가장 중요한 것은 핵심 루트를 먼저 발견하고그 주변을 조사하고자 하는 열정입니다.
소프트웨어가 ‘제대로 된 제품’이 된다는 것은
‘고객’이 똑똑해야 합니다. 바른 비전에 입각해서 제대로 된 요구사항을 정리하면서, 개발 과정에 참여해서 개발하는 전체 여정에 필요한 의사결정과 정보를 정리해 줘야 합니다. 그리고 반복 개발로 나오는 산출물들에 대해서 사실에 입각한 피드백을 주어야 합니다. 마지막으로 이 모든 것들은 ‘인간의 존엄함’이 지켜질 수 있는 책임으로 구조를 잡은 시스템과 프로세스, 그리고 훌륭한 사람들로 구성된 ‘조직’이 필요합니다.
마지막에는 무엇이 있을까?
지금 이 순간에 있는 문제를 소프트웨어와 서비스를 통해 해결하려는 노력을 지속하는 게 가장 효과적인 방법이라고 생각합니다. 한 걸음씩 나아가며 단계적으로 발전시키고 로드맵을 지켜야 합니다.