Medium - 65 Lessons from 50 Years of Software Experience
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 50년의 SW 개발 경력으로 드리는 교훈
저는 1970년에 대학에서 처음 프로그래밍 수업을 들었습니다. (물론 포트란이죠.) 저는 지난 반세기 동안 소프트웨어 분야에서 많은 경력을 쌓았습니다. 요구사항, 설계, UX, 프로그래밍, 테스트, 프로젝트 매니징, 문서화, 프로세스 개선 리더쉽 등 7개의 저서와 많은 기사들을 투고했고 컨설팅과 교육을 했죠.
물론 커리어 중에 생물학 박사 취득, 리서치 사이언티스트로 몇 년간 일한 것도 있지만 그래도 기본적으로 저는 소프트웨어 업계 사람입니다. 오랜시간 동안 저는 소프트웨어 산업에 대한 많은 인사이트를 갖게 되었습니다. 거기서 65가지 교훈을 여러분들에게 공유해 드리며 여러분들에게 도움이 되셨으면 좋겠습니다.
ON Requirements
- 요구사항을 정확하게 수립하지 않으면 나머지 프로젝트를 어떻게 수행하든간에 여러분은 실패하게 되어있습니다.
- 점심 시간 후에 여러분의 책상에서 찾은 포스트잇이나 음성 메일, 이메일, 정확하지 않은 대화들의 모음들은 요구사항들이 아닙니다. 그냥 정보 덩어리 들일 뿐입니다.
- 요구사항 명세서를 수립하는 과정에서 가장 중요한 것은 프로젝트의 관계자들의 모든 관심사를 일치시키는 것입니다.
- 요구사항 명세서를 잘 뽑지 않으면 나중에 관계자들이 개발된 것을 보고 깜짝 놀랄겁니다. 이 깜짝 놀라는 반응은 거의 안좋은 소식입니다..
- 요구사항을 조사할 때 잠재 고객도 항상 생각하세요. 한번 없어진 고객도 여전히 여러분의 잠재 고객입니다.
- 사람들은 단순히 요구사항을 모아놓지 않습니다. 요구사항 도출은 조사, 협업, 발견, 창조의 과정이지 단순히 수집하는 프로세스가 아닙니다. 사업 분석가는 그냥 글쓰는 사람이 아닙니다.
- 요구사항을 도출은 고객의 소리를 (VOC, voice of customer)를 개발자에게 ( EOD, ear of developer) 전달해주는 것이 목적입니다. 사업 분석가는 관련 대화에서 커뮤니케이션 갭을 줄여주는 역할을 합니다.
- 요구사항 도출에서 주로 사용되는 두가지 기술은 텔레파시와 투시력입니다. 이 기술은 제대로 먹히지 않습니다.
- 사회적인 배경을 제외하더라도 고객이 항상 옳은 것은 아닙니다. 고객 또한 잘못 알고 있거나 타당하지 않거나 기분이 좋지 않을 수도 있죠. 그래도 고객은 항상 원하는 포인트가 있습니다. 그리고 여러분은 그것을 이해하고 존중해야 합니다.
- 요구사항을 문서화하는데 겁을 내지 마세요. 지식을 기록하는 것이 지식을 얻는 것보다 훨씬 적은 비용이 듭니다.
- 만약 어떤 기능이나 특성이 요구사항에 기록되어 있지않다면 아무도 그것을 제품에서 볼 수 있을 거라고 기대하지 않습니다.
- 효과적인 개발 요구 명세서는 그냥 요구사항 명세서를 글로 쓴게 아닙니다. 개발 요구 명세서에는 이해, 예측에 관한 것들이 공유되어야 합니다,
- 현실적인 개발 요구 명세서의 목표는 완벽하게 모든 요구사항을 가지고 있는 것이 아니라 개발팀에서 해당 요구사항들이 허용 가능한 위험 수준인지 알 수 있으면 됩니다. 이런 위험 수준은 지나친 개발 공수, 계획되지 않은 재작업을 유발시키는 것으로 누락되거나, 무시되거나, 불완전하거나, 모호하거나, 충분히 협의되지 않은 요구사항 때문에 계획되지 않은 재작업이 생깁니다.
- 가끔씩 우리는 요구사항을 무심하게 표현하고 합니다. 왜냐하면 요구사항을 보는 사람들도 우리와 비슷한 상식이 있다고 가정합니다. 그러나 사람들은 같은 문장도 다르게 해석합니다. 이런 모호함은 나중에 예상과 개발 결과를 일치하지 않게 만듭니다.
- 요구사항 워크샵을 유지하고 작은 팀으로 리뷰를 진행하세요. 큰 그룹의 사람들로는 불타는 방에서 도망치는 것조차 합의를 이끌어낼 수 없고 하나의 요구사항이 어떻게 명시되어야 하는 지도 합의를 이끌어 낼 수 없습니다.
- 처음 누군가가 새로운 요구사항이 이번 개발 범위에 들어가는지 물어본다면 그렇다고 하고 아니면 “아닙니다” 혹은 최소한 “이번 개발 범위에는 아닙니다.”라고 정확히 말해야 합니다. 만약 “아니요 근데 개발은 될거에요”라고 말한다면 개발 범위를 수정해야 합니다. 이 것은 비용, 스케줄, 자원, 관련 단체, 우선순위에 영향을 줍니다. (영어권에서 개발 범위에 대한 어감이 불분명할 떄 발생하는 오해를 설명하는 듯)
- 여러분이 프로젝트 범위에 대해 합의를 이끌어 내고 문서로 남기지 않는다면 나중에 범위가 변하게 될 때 어떻게 그것을 알아차릴 수 있겠습니까.
- 어떤 피쳐가 개발이나 이번 회차에 포함되어야 하는지 정할 때 목소리 큰 사람의 의견을 따르지 않도록 하세요. 목소리 큰 사람의 요구사항이 꼭 필요한 것은 아니고 가장 중요한 것은 비즈니스 관점에서 파악하는 것입니다.
- 프로젝트 관계자들은 개발 가능한 요구사항을 토론하는 것과 제품안에 해당 요구사항을 포함시키는 것의 차이를 반드시 알아야 합니다. ( 요구사항 회의 / 개발 범위에 대한 회의 )
- 예상되는 요구사항, 함축된 요구사항은 여러분의 피를 차갑게 만들 겁니다. 요구사항에서 원하는 바를 확실하게 명시하도록 커뮤니케이션 해야합니다.
- 요구사항의 퀄리티는 독자의 수준에 맞춰야 합니다. 만약 작성자가 충분히 좋다고 해도 요구사항을 읽는 사람들이 그 결정을 내리는 것입니다. 이 때문에 여러분은 요구사항 리뷰에 요구사항을 읽는 사람들을 꼭 포함시켜야 합니다.
On Project Management
- 프로젝트 관리라는 명확한 활동은 없습니다. 프로젝트 매니징 인적 관리, 요구 사항 관리, 리스크 관리, 기회 관리, 기대 관리, 위원회 관리, 형상 관리, 자원 관리, 공급 관리들의 총 집합입니다.
- 왜 항상 조직들은 소프트웨어를 제대로 만들지 않고 나중에 시간과 돈, 인력을 써가며 고치는 것일까요? 미스테리 입니다.
- 모든 사람들은 자기 팀원들이 엄청나게 재능이 있다고 생각하지만 사실 전체 개발자의 절반은 평균적인 능력에 못미칩니다. 그들은 대체 어디서 일을 하고 있는걸까요?
- 절대 기간에 대해서 서면으로 말하지 마세요. 개발 기간에 대한 문의가 들어왔을 때 가장 좋은 대답은 “나중에 생각해보고 공유해드리겠습니다” 입니다.
- 아무리 다른 사람들이 압박을 가해도 절대로 여러분이 충족할 수 없는 것을 할 수 있다고 하지 마세요.
- 여러분의 상황에 맞는 데이터가 있는 경우 훨씬 협상에서 유리한 입장을 취할 수 있습니다. 왜냐면 다른 사람들은 그런 데이터가 전혀 없기 때문이죠.
- 여러분들이 개발 기간에 대해서 예측한 것을 기록하고 나중에 실제 개발 기간과 비교해보지 않으면 여러분은 개발 기간 예측을 하는 것이 아니라 그냥 항상 추측만 하는 겁니다.
- 여러분들이 프로젝트 기간에 대해서 전달을 하는 경우 듣는 사람들이 원하는 바에 대해서 영향을 받으시면 안됩니다.
- 프로젝트 매니저는 다음 5가지 요소에서 최소한 1개라도 유도리가 있어야 합니다. 바로 스코프, 스케줄, 팀워느 예산, 그리고 퀄리티 입니다. 만약 이런 것들이 모두 유동성이 없다면 여러분은 실패할 겁니다.
On quality and Process Improvement
- 소프트웨어 퀄리티에 대한 수당은 지금 주셔도 되고 아주 아주 아주 나중에 내셔도 됩니다.
- 완벽을 향해 나아가고 탁월함을 추구하세요.
- 고객이나 상사가 부정한 일을 요구하지 않도록 하세요.
- 품질은 가장 최우선의 기준이어야 합니다. 장기적인 관점에서 생산성은 높은 품질과 직결됩니다. 왜냐하면 팀이 소모적인 재작업을 할 필요가 없게끔 해주기 때문이죠.
- 고객보다는 동료들과 함께 결함을 찾도록 하세요. 기술적인 피어 리뷰는 기술의 품질과 생산성을 검증하는 스킬입니다.
- 합리적이지 않은 사람과 작업을 한다면 어떤 엔지니어링 스킬도 제대로 안될겁니다.
- 만약 사람들이 다른방식으로 일하길 요청받는다면 그들은 자연스럽게 “저한테 무슨 문제가 있나요?”라고 물어봅니다. 그러나 이건 잘못된 질문이죠. 올바른 질문은 “우리에게 무슨 문제가 있나요?”라는 것입니다.
- SW 업계 사람들은 항상 좋은 개발도구들을 찾아다닙니다. 그러나 올바르게 사용하지 않으면 아무 소용없습니다.
- 사람들이 현재 작업 방식에 문제를 느끼고 있지 않다면 프로세스를 바꾸는 것은 매우 힘듭니다. 쥐를 잡을 필요가 없는 사람에게 쥐덫을 판매하는 것이 어려운 것과 마찬가지죠.
- Q: 전구를 바꾸는 데 필요한 소프트웨어 리더의 수는?, A: 1명, 그러나 전구가 바뀔 이유가 있어야 한다.
- 새로운 방식으로 작업을 하려면 조직 문화를 바꾸는 것의 필요성/어려움을 과소평가 하지 마세요. 새로운 프로세스를 정착시키는 것은 새로운 문화를 정착시키는 것보다 빠릅니다. 여러분은 둘 다 성공해야 됩니다.
- 좋은 의도가 있더라도 개선 작업이 항상 유용한 것은 아닙니다.
- 상식, 올바른 판단, 경험이 절차를 무시해야할 때도 있습니다. 여러분이 그렇게 절차를 우회하기 전에 항상 그래야하는 좋은 이유를 찾아내세요.
- 새로운 작업 방식을 조직에게 적용할 때 강요가 아니라 권유를 하세요.
- 변화의 가장 좋은 동기는 사람들의 작업에서 고충을 찾는 것입니다. 인의적으로 표현되는 고충이 아니고 실제 팀원들이 현재 작업방식에서 느끼는 것이어야 합니다. 이런 고충을 줄일 수 있는 개선 활동을 고르도록 하세요.
- 시간이 없더라도 회고를 통해 팀 프로세스를 개선할 수 있도록 해야합니다. 다음 프로젝트는 괜찮겠지 라며 낙관하시면 안됩니다.
- 여러분은 한번에 모든걸 바꿀 수 없습니다. 프로세스 변화가 많은 이점을 가져다 주더라도 다음주 월요일부터 시작하세요. 다시 한번 말하지만 다음주 월요일 부터입니다!
- 문서 양식에 있어서는 shrink to fit 철학을 적용하세요. 필요할 수도 있는 모든 정보를 담은 풍부한 문서양식에서 각 프로젝트의 성격, 크기, 요구사항에 따라 문서 양식을 줄여나가면 됩니다.
- 많은 팀들이 효율을 높이도록 요구를 받습니다. 그렇지만 딱히 가능한 방법을 제시하지 못하죠. 교육과 프로세스 개선이 없이는 효과적으로 효율을 높일 수 없습니다. 한번에 높은 생산성을 달성할 것처럼 기대하지마세요.
- 4명정도의 사람이 작은 방에서 일을 하는 경우에는 프로세스가 구축되어 있지 않아도 괜찮습니다. 그렇지만 개발팀이 많아지면 프로세스가 꼭 필요합니다.
- 만약 소프트웨어 산업에서 한가지 반복하고 있는 것이 있다면 그것은 한 프로젝트에서의 실수를 다음 프로젝트에서도 하는 것입니다. 회고를 통해 지속적으로 개선할 수 있도록 하세요.
- 만약 기존의 프로세스를 따르지 않는 사람이 있다면 여러분은 세가지의 선택지가 있습니다. 1) 프로세스를 따르도록 하기, 2) 프로세스를 더욱 실용적이며 효과적으로 수정하고 따르도록 하기, 3) 프로세스는 개나줘버리고 따르는 척하는 것을 멈추라고 하기
Other Insights
- 인공지능이 진짜 지능을 대체할 수는 없습니다.
- IT 업계에서는 여러분이 다른사람들 보다 일주일만 앞서나가도 마술사가 됩니다.
- 사람들은 자신의 권리에 대해서 많이 말하곤 합니다. 권리의 또다른 말은 의무입니다. 항상 협조적으로 생각하고 행동하세요.
- 비즈니스위크에서 하는 매니지먼트를 조심하세요. 다른 사람이 멋진 결과물을 냈다고 해서 소프트웨어 개발에서 핫한걸 바로 적용하려고 달려드는 것은 지양해야 합니다.
- 엄지와 검지를 살짝 벌려보세요. 언제나 수작과 망작의 차이는 그정도 였습니다. 조금 더 듣고, 여러분의 일을 체크하고 테스트를 다시하고 체크리스트를 확인하고 주의사항을 읽고 한번더 질문하세요. 이런 행동들이 좋은 제품이 되도록하는 작은 차이입니다.
- 여러분은 이전의 소프트웨어 개발에서 교훈을 얻어서 실수르 ㄹ되풀이 하지 않으셔야합니다. 문건들을 읽고 존중하세요. 동료들로부터 배우고 여러분의 지식을 주변사람과 널리 공유하세요.
- 소프트웨어 개발은 50이 코딩이고 50이 커뮤니케이션 입니다. 그러나 비즈니스 분석은 거의 커뮤니케이션이죠. 우리가 코딩부분에서 훨씬 낫습니다.
- 만약 여러분이 독립된 컨설턴트나 프리랜서라면 여러분을 스스로 홍보해야 합니다. 여러분이 아무리 실력이 좋아도 여러분이 거기있다는 것을 아무도 모르면 의미 없죠,
- 우리는 소프트웨어를 만들 때 많은 착각을 합니다. 우리는 올바른 이해관계자들을 알고 있는 것마냥 행동하고 그들또한 그들의 사업목표를 잘 이해하고 있는 척하고, 스스로의 요구사항을 잘 알고 있는 듯이 말합니다. 우리는 딱 맞는 사람과 정확한 요구사항에 대해서 얘기하고 있다고 착각하고 우리는 그것을 잘 이애하고 정확하게 기록했다고 생각합니다. 또 우리는 우리의 모든 작업들이 정확하게 예측된 것처럼 행동하고 프로젝트에서 모든 위험요소들이 고려된 것처럼 얘기하죠. 저는 이런 척 하는 것을 싫어합니다. 저 또한 현실에서 부족한 면이 많겠죠. 겸손해집시다.
Summary
- IT 업계 경력 반세기의 교훈,
