제3장 소프트웨어로 만들 때, 운영할 때, 그리고 사업할 때 주의 사항

Chapter 3 소프트웨어로 만들 때, 운영할 때, 그리고 사업할 때 주의 사항

들어가며

당장의 이윤이 있어야 사업을 굴리기에 무리한 일을 하거나 내부에 충분한 자신감이 있다고 생각해서 위험을 감수하기도 합니다. 위험을 감수했기에 정말 위험한 일이 생겨버리면 큰일 나는 것입니다.

없는 것을 만들었다고 하지 마세요

“어쩔 수 없잖아요”

덮어 둔 것이라고 해도 벗겨지지 않을 것이 없고, 숨긴 것이라 해도 알려 지지 않을 것이 없다

앞에 사례로 보여드렸던 사태를 분석해 보면 경영진은 다음의 실수를 저질렀습니다.

문제에 대한 해결책이 무엇인지는 좀 안 것 같았습니다. (그러니 입찰서류라도 썼다고 생각합니다.) 그러나 그 제품을 만드는 데 시간과 자원이 든다는 것을 몰랐습 니다. 알면서도 무시했다면 더욱 큰일입니다.
“입찰하고 뭐 하면 6개월 이상은 걸릴 거야”라는 것은 이해할 만했습니다. 하지만 그 6개월 동안에 실제 개발이 이뤄질 수 있는지에 대한 평가는 왜 하지 않았을까요?
어떤 선택이 되어도(입찰이 되든, 입찰이 안 되든) 어떤 이익이 돌아오도록 했어야 하는데 그러지 못했습니다. 입찰이 안 되면 그냥 시간을 버린 것이 됩니다. 그런데 입찰이 되면 정작 제시간에 제품을 만들 수 없어서 사업비를 되물어 주는 사태가 일어날 것입니다.

어디서부터 잘못된 것일까?

첫째로, 소프트웨어 개발과 치즈 버거 생산을 헷갈려 하는 사람들이 많습니다.

둘째로, 경영진들도 심리적인 어려움을 겪는 경우가 많습니다.

개발(development)과 생산(production)의 차이를 이해하라, 그리고 소외된 당신 자신을 돌보아라

소프트웨어 업계의 필독도서인 『피플웨어』의 저자들은 아래와 같이 이야기합니다.

개발 (development)과 생산(production)은 다르다

1부에서 이야기한 커네핀 모델을 생각해 보면 명확(Clear) 혹은 단순(Simple)한 경우입니다.

이러한 관점은 개발, 정확히는 지식 노동과는 아주 거리가 있습니다. 피플웨어의 저자들은 위의 조치들은 지식 노동을 위해 아래와 같이 바뀌 어야 한다고 합니다.

실수를 허용하라. 창의적이고 독창적인 일은 다그친다고 되는 게 아니다. 개발자, 아니 지식 노동자는 쉽게 교체할 수가 없다. 기존에 있던 사람과 똑같은 사람은 찾아볼 수 없다. 현상 유지 상태의 프로젝트는 사망이다. 일을 끝내는 데 몰두한 나머지 이 질문을 하지 못하면 끝장이다. “이것이 정말 해야 하는 일인가?”

개발(Development)과 생산(Production)은 어떻게 다른 것인가요? 그것은 생산은 기계로 대체할 수 있지만 개발은 인간만이 해야만 하는 일이라는 것입니다. 인간이 가치 있는 존재로 인정받을 때에만 할 수 있는 것이 지적 노동이고 개발입니다. 이러한 관점의 변화가 없이는 계속해서 모든 소프트웨어 개발 프로젝트에서 실패할 수밖에 없습니다.

거짓을 말할 수밖에 없는 자신, 괜찮으세요?

사실 회사대표의 스트레스는 상상을 초월하게 큽니다. 더 당황스러운 건 이런 상황에서 어찌저찌 성공하면 다행이지만 외상 후 스트레스 장애처럼 마음에 상처가 남아 있을 수밖에 없다는 것입니다.

이런 상황이다 보니, 이성적인 판단을 내려야 하는 순간에 몰리고 몰려서 최악의 판단을 해버리는 경우가 많습니다. 혹은 당장의 자금을 위해 투자자나 고객에게 거짓말을 해버리는 경우도 있습니다. “없는 것을 파는 경우”는 이런 상황에서 벌어지는 것이었습니다.

테라노스의 엘리자베스 홈즈의 사례

그럼에도 불구하고 만들지 않은 것을 팔아야 할 때

타협을 해야 하는 순간: 위험을 감수해야 한다

정말 사업은 소프트웨어 개발보다 더예측 불가능한 것들이 많습니다. 결국 때에 따라서 모험을 할 수밖에 없죠. 그러나 모든 것을 걸고 모험을 하기에는 너무나 위험합니다. 그리고 ‘최소한의 손실’만 지고 가야 다음 기회가 있습니다.

지금은 없는 기능이지만 ‘있다고 하고’ 만들지 말지 결정하기

실제 만드는 데 걸릴 시간, 검증하는 데 걸릴 시간, 여유 시간의 추정을 누가 하느냐입니다. 만약 본인이 이미 회사 제품을 설계하고 구현까지 다 하는 사람이라면 이에 대해 직접 해도 좋습니다. 하지만 대부분 그렇지 못할 것입니다.

최대한 얼마나 시간이 걸릴지에 대해서 계속 단계별로 노력해서 추정해야 합니다. 적어도 고객에게 ‘~~까지는 될 수 있을 것 같습니다’라는 이야기는 해줘야 합니다. 그리고 내부 구성원들이 이 약속을 지킬 수 있게 모든 자원을 다 지원해 줘야 합니다.

베이퍼웨어(vaporware)를 아시나요?

“컴퓨터 업계에서 베이퍼웨어는 일반적으로 컴퓨터 하드웨어 또는 소프트웨어와 같이 일반 대중에게 발표되었 지만 실제로 제조되지 않거나 공식적으로 취소된 제품”

“베이퍼웨어는 출시 예정일보다 수개월 또는 수년 전에 발표되는 경우가 많으며, 개발에 대한 세부 정보는 거의 공개되지 않습니다. 개발자들은 고객이 더 많은 기능을 제공하는 경쟁 제품으로 전환하지 못하도록 의도적으로 베이퍼웨어를 홍보한다는 비난을 받아왔습니다.”

실제 무언가 만들 이유는 없지만 이런 식으로 고객이 도망가지 못하게 하기 위해서 ‘이런 게 있다, 저런 게 있다’라고 하는 겁니다. 그러나 정작 나온 적이 없습니다.

오히려 고객이 이런 것을 살지 안 살지도 모르는데, 코드를 만들어서 전달하는 것보다 ‘이런 거 만들 건데 어때?’라고 한번 운을 띄워보는 것도 나을 수 있습니다.

그럼 어느 수준으로?

전단지 수준: ‘이러이러한 제품이 있다’라고 전단지 수준으로 정리만 되면 됩니다.
간단한 프로토타입(prototype): 화면만 만들어 보여주는 정도로 보여주는 것입니다.
진짜 제품이 있어야 합니다: 아주 위험합니다. 게다가 완성도가 있는 것을 내놔야 한다고 한다면 이건 정말 희생이 너무 큽니다.

긴급성 중독 환자 때문에 널뛰기를 한다면?

그런데 이런 일이 계속 반복된다면? 이것은 경영진이 긴급성 중독(urgency addiction)에 걸린 것은 아닌지 되돌아봐야 할 것입니다.

긴급성 중독은 특정 상황을 의도적으로 긴급하게 조성하여 강한 아드레날린 분비를 유발하고, 그로부터 나오는 심리적 중독을 의미합니다. 즉, 계획적 으로 일을 처리할 수 있음에도, 긴급함에서 오는 아드레날린에 중독되어서 일을 나도 모르게 꼬아서 모두를 급하게 휩쓸리게 만들어 버리는 것을 말합니다.

긴급한 상황에서 능동적이고 빠르게 대처하며 성과를 올리는 모습은 주변에 긍정적인 인상을 줄 수 있습니다. 그러나 이러한 행동은 장기적으로 볼때 부정적인 영향을 미칠 수 있습니다. 긴급성 중독은 단기적으로 성과를 가져오더라도 장기적인 계획 및 전략의 부재로 인해 조직의 지속적인 성장을 저해할 수 있기 때문입니다.

긴급성 중독을 극복하기 위해 다음과 같은 전략이 효과적일 수 있습니다.

우선순위 설정
계획적인 업무 관리
스트레스 관리
의사소통과 협업

사례: 샌드버드에서 특정 고객에게서 자신만의 기능을 요청 받았을 때

“의외로 이런 요구사항들이 ‘실제 고객이 원하는 것’이었던 경우가 있었습니다. A라는 회사에서 ‘특정한 기능’이 필요하다고 해서 만들었더니, B라는 회사에서도 필요한 기능이었더라고요. 그래서 정식 기능으로 추가한 경험이 있습니다. 그러니까 고객이 무리한 요구를 한다고 하지 말고 왜 이런 것을 요구했는지, 다른 고객들은 어떻게 생각하는지도 같이 생각해 봐야 합니다.”

고객에게 피드백을 어떻게 받아야 하나요?

설문조사는 다시 한번 생각해 보세요

설문조사는 신뢰하면 안 됩니다. 특히 실제 구매 여부나 가격 범위와 같은 내용은 설문조사로 정확히 파악하기 어렵습니다. 왜냐하면 실제 구매 여부는 제품을 실제로 결제하기 전까지는 예측할 수 없습니다.

직접 만나서 제품 사용 과정을 관찰하고 화면 캡처나 비디오를 활용 하여 제품 사용 상황을 기록하고, 히트맵이나 사용자 행동을 분석할 수 있는 도구를 사용하여 고객의 행동을 파악해야 합니다.

가격 - 경쟁사들이 다 조사했습니다

충분히 시장에서 먼저 전쟁을 치르고 있는 경쟁 업체들이 이미 시장가를 형성하고 있을 것입니다.

오히려 최종 가격보다 조금 높게 책정하고 초기 고객에게 할인을 제공하는 것이 더 나을 수 있습니다.

구글 애널리틱스(google analytics)는 붙이셨지요?

중요한 것은 이런 도구들을 설정하기를 요구하셔야 한다는 것입니다. 작은 랜딩 페이지 하나에서도 사용자들이 이 안에서 어떻게 흘러 들어왔는지를 분석할 수 있는 도구로서 이만한 것이 드뭅니다. 꼭 잊지 마시고 설치하시기 바랍니다.

채팅 상담 장치 붙이기

요새는 채널톡 (https://channel.io)이나 깃플 (https://gitple.io/) 같은 서비스들을 첫 화면에 붙여 놓습니다. 이러한 서비스들을 사용하면 좋은 점은 첫째, 상담 창구를 단일화해 줍니다. 둘째, 상담 담당이 효율적으로 일할 수 있습니다. 마지막으로 이 상담 내용 전체가 한곳에 남아 있어서이 기록을 바탕으로 제품을 개선할 아이디어를 만들어 낼 수 있습니다.

정기적으로 고객에게 유용한 정보를 담은 이메일을 보내라

오랫동안 서비스에 들어오지 않는 혹은 구매하지 않은 고객에게 어떤 이유인지 물어보는 것은 필수적으로 해야 할 일입니다.

이렇게 글을 적고 정리해서 보내는 일이 쉬운 일은 아닙니다. 때로는 보내도 답이 없는 고객이 너무 많을 수도 있습니다. 그러나 전문성 있는 사업자로 고객들에게 자리매김하고 싶다면 반드시 해야 합니다.

가능하면 비용을 들이더라도 메일침프 (Mailchimp, https://mailchimp.com/) 나 스티비 (Stibee, https://stibee.com/) 같은 서비스들을 이용하기를 권합니다. 누가 읽었는지 안 읽었는지도 확인이 되고, 이메일로 보낸 내용이 쌓여서 정보가 한곳에 집중됩니다.

시장에 안착했는지 안 했는지 확인하기

이것을 ‘제품/시장 적합 설문조사 (product/market fit survey, PMF survey)’라고 합니다. 이 질문은 2009년 Dropbox의 초기 멤버인 션 엘리스 (Sean Ellis)가 개발했습 니다. 이 핵심 질문은 “만약 [제품]을/를 더 이상 사용할 수 없다면 어떠실 것같나요?”를 묻는 것입니다.

초창기라면 ‘매우 속상할 것 같다’라고 한사람을 몇 명이라도 찾아가야 합니다. 이른바 이분들이 팬이 될 확률이 높기 때문입니다. 잘 되는 곳에 기름을 부어서 불을 더 질러야 합니다.

허세지표에 속지 말자

무언가 지표를 설정한다고 하면 늘 ‘의심’을 꼭 해보시기 바랍니다. ‘이게 지금 맞는 건가?’라고 의심을 더 하면서 더 나은 방법은 없는지를 고민해야 합니다.

기간별로 어떤 변화가 있는지 코호트 분석 (cohort analysis)으로 바꿔 놓으면 매우 도움이 됩니다. 예를 들어, 세로축으로 1주일마다 앱의 다운로드 숫자를 추적하고 가로축으로 이때 다운로 드받은 사람들이 얼마나 서비스 이용을 유지하는지를 보는 것입니다. 이렇게 하면 이 1주일마다 다운로드 받은 사용자들이 얼마나 살아남는지를 보면서 시장에 지금 얼마나 잘 안착했는지를 볼 수 있습니다.

테크스펙 – 새로운 기능을 만들 때 같이 쓰고 일하자

테크스펙이란 의사결정에 필요한 관련된 사람들 (stakeholders)이 아래와 같이 어떤 제품을 만들어야 하는지를 정의하는 ‘한 개의 문서’를 말합니다.

기획자가 아예 무엇을 원하는지를 말로 적을 수도 없으면 개발 담당자나 디자인 담당자는 더더욱 무엇을 만들어야 할지 모르게 됩니다. 그래서 이러한 문서를 통해서 서로 ‘목표 합의’를 하는 것입니다. 저는 노션 (https://notion.so)으로 이 테크스펙들을 관리하고, 관련 담당자들 모두에게 이 테크스펙을 작성하게 합니다. 최종 편집은 제가 다시 하지만 관련 담당자들이 이 문서를 한 줄이라도 적게 하는 것이 중요합니다.

사실에 근거한 기록을 남기지 않겠다는 의지를 보이는 사람은 언제나 문제를 일으킵니다다. 그래서 ‘모든 것이 글쓰기’라는 실용주의 프로그래머의 말은, 진정 진리라고 생각합니다.

관리할 수 없는 모든 것을 다 해준다고 하면 무슨 일이 벌어질까?

서로 버전이 갈라지게 되면, 결국 각 버전의 고객이 달라지고, 요구사항이 각자 마구잡 이로 들어가게 됩니다. 세 가지로 갈라진 버전의 소프트웨어를 제한된 인력으로 다 유지보수해야 한다면 어떻게 될까요? 일이 세 배로 늘어나게 됩니다. 이를 위해서 인력을 추가하게 되면 ‘비용이’ 그 이상이 들게 됩니다. 의사소통 비용이 세제곱으로 보통 늘어나게 되기 때문입니다.

결정 한 번 잘못 내려서 비용을 세 배, 네 배로 늘려버리면 어떨까요? 그래서 이러한 결정은 매우 신중하게 내려야 합니다. 그래서 CTO나 개발 총책임이 참여하지 않은 개발 관련 의사결정은 안 내리는 게 낫습니다. 대표가 ‘통 크게’ 지르는 결정이라면 더더욱 위험할 수 있습니다.

왜 개발자는 맨날 모자라지?

보통은 바로 ‘개발자’들이 제일 느린 조직입니다. 즉 병목 자원입니다. 개발자들은 왜 ‘대기’할까요? 한마디로 뭘 만들지 정확하게 정의하지 않았기 때문입니다.

이걸 해결하려면 어떻게 해야 할까요?

첫째, 다른 조직이 놀아야 합니다. 개발팀이 일을 끝낼 때까지 다른 조직들은 쉬어야 합니다. 왜냐하면 어차피 열심히 다른 기획이나 디자인팀이 일을 해서 쌓아 놔도 개발 자체가 진행이안 되기 때문입니다.

둘째, 불필요한 일을 제거합니다. 어떻게 해야 할까요? 개발이 필요한 일인지 아닌지 구분을 해야 합니다.

개발자가 모자란 게 아니라 개발자들을 잘 배치하지 못한 경영의 문제 였다는 것이 저자의 의견입니다.

외주 개발사를 쓰려면, 반드시 이를 최고 관리자 수준에서 관리해야 한다

첫째, 외주 개발사가 어느 구조로 코드 작업을 할지 의사결정하는 데 관심을 두지 않으면 대부분 자신들이 해온 대로만 하게 됩니다.

둘째, 적절한 품질로 만들어 오는지 아닌지를 확인해야 합니다. 앞서 이야기했듯이 소프트웨어가 비싼 것은 ‘유지보수성’ 때문이라고 했습니다.

셋째, ‘내 컴퓨터에서는 잘 돼요’라는 소리를 들을 수 있습니다. 이른바 CI/ CD가 없을 확률이 매우 높습니다.

가능하면 엔지니어링에서 ‘최고 관리자 (CTO나 VP of engineering)’가 이를 챙기거나, 적어도 팀장급 사람이 하나 붙어서 지속적으로 반복 개발을 할 수 있게 관리해야 합니다.

여기서 ‘관리’를 하라는 뜻은 반복 개발할 수 있게 일정을 관리하고, 산출물로 나온 코드들을 이해할 만큼 학습하고 때로는 더 나은 대안을 제시하고, 최종적으로 해당 외주사가 없어도 이 제품을 내부에서 유지보수할 수 있게 사람들을 육성해서 완전히 회사의 자산으로 흡수하라는 것을 의미합니다.

핵심 개발자를 ‘반드시’ 제거하라

제럴드 와인버그의 프로그래밍 심리학이란 책을 보면 이런 무서운 문구가 나옵니다. “절대 없어서는 안 될 프로그래머가 있다면 한시라도 빨리 그를 프로젝트에서 제거하라”

첫째, 그 사람이 가진 임무들을 먼저 나눠봅니다.

둘째, 그 사람의 일을 감당할 만한 경력자를 채용하든지 키웁니다.

셋째, 문서화를 해야 합니다. ‘이건 누구한테 물어봐야 돼요?’라고 하면서꼭 한 명에게 다 몰리는 경우가 있습니다. 이럴 때를 대비해서 문서들을 정비하고 위키 같은 온라인 문서 시스템을 구축해서 ‘여기부터’ 보라고 해야 합니다.

핵심 개발자를 ‘제거’해서 전체 프로젝트의 안정성을 키워야 합니다. 이런 거 없이 머리 숫자만 보고 관리하면 매우 위험한 상황을 맞이하실 것입니다. 파레토의 80:20의 법칙까지는 아니라도 무언가 십자가를 매고 고생 하는 소수는 반드시 있습니다. 이런 사람들을 ‘빨리 제거’해서 번아웃 되기 전에 지켜내야 합니다.

파괴적인 아이디어나 기술이 시장을 와해시키는 조건

『초난감 기업의 조건 』이라는 책이 있습니다. 우리가 알고 있는 여러 실리 콘밸리의 IT기업들이 어떤 난감한 마케팅 활동으로 사업을 날려 먹었는지에 대한 이야기들을 적고 있습니다.

이 책에는 파괴적인 아이디어나 기술이 시장을 와해시키려면 이러한 조건을 가지고 있는지 체크하라고 리스트를 소개하고 있습니다.

변화하려는 아이디어가 있어야 한다.
시장이 변화를 요구해야 한다.
변화가 이득이 되어야 한다.
변화를 뒷받침할 기반 구조가 있어야 한다.
변화를 퍼트릴 메커니즘이 있어야 한다.
적당한 가격 범위에서 변화해야 한다.
변화 후 품질이 적정해야 한다.

지금 기획하는 제품이 위의 7가지 조건에 비춰 봤을 때, 합리적이고 제대로 된 답을 줄 수 있는지 말입니다. 그리고 그 결과를 당신이 생각하기에 가장 먼저 사용할 것 같은 고객이나 동료에게 보여주 십시오. 뭐라고 피드백이 오는지를 들어보십시오.

공공기관은 어떻게 디지털 서비스를 만들어야 하나?

2012년 4월, 영국 정부는 정부 서비스 설계를 위한 ‘정부의 디자인 원칙 (Government Design Principles)’을 공개했습니다.

사용자의 수요에서 시작하라(Start with user needs)
덜 일 해라(Do less)
데이터를 가지고 디자인해라(Design with data)
단순하게 만들기 위해 노력해라(Do the hard work to make it simple)
반복해라, 그리고 반복해라(Iterate. Then iterate again)
모두를 위한 것이다(This is for everyone)
문맥을 이해해라(Understand context)
디지털 서비스를 만들어라, 웹사이트 말고(Build digital services, not websites)
일관성을 유지하라, 획일적이 아니라(Be consistent, not uniform)
개방성 더 나은 서비스를 제공하라(Make things open it makes things better)

사용자의 수요에서 시작하라(Start with user needs)

서비스 디자인은 사용자의 니즈를 파악하는 것에서 시작됩니다. 사용자의 요구가 무엇인지 모른다면 제대로 된 것을 만들 수 없습니다. 조사하고, 데이터를 분석하고, 사용자와 대화하세요. 추측하지 마세요. 사용자에 대해 공감하고, 사용자가 요구하는 것이 항상 필요한 것은 아니라는 점을 기억하세요.

덜 일해라(Do less)

정부는 정부만이 할 수 있는 일만 해야 합니다. 효과가 있는 방법을 찾았다면 매번 같은 일을 반복하지 말고 재사용하고 공유할 수 있도록 만들어야 합니다. 즉, 다른 사람들이 구축할 수 있는 플랫폼과 레지스터를 구축하고, 다른 사람 들이 사용할 수 있는 리소스(API 등)를 제공하고, 다른 사람들의 작업과 연결 해야 합니다. 환원 불가능한 핵심에 집중해야 합니다.

데이터를 가지고 디자인해라(Design with data)

대부분의 경우 기존 서비스가 어떻게 사용되는지 살펴보면 실제 행동에서 배울 수 있습니다. 직감이나 추측이 아닌 데이터가 의사결정을 주도하도록 하세 요. 서비스를 출시하고, 프로토타입을 만들고, 사용자를 대상으로 테스트한 다음, 이에 대한 응답을 반복한 후에도 계속 그렇게 하세요. 분석은 항상 켜져 있고 읽기 쉬운 기본 제공 기능이어야 합니다. 분석은 필수적인 도구입니다.

단순하게 만들기 위해 노력해라(Do the hard work to make it simple)

무언가를 단순하게 보이게 만드는 것은 쉽습니다. 기본 시스템이 복잡할 때 사용하기 쉽게 만드는 것은 훨씬 더 어렵지만, 이것이 바로 우리가 해야 할 일입 니다. “항상 그래왔어요”라는 대답을 당연하게 받아들이지 마세요. 일반적으로 일을 단순하게 만드는 것은 점점 더 어려운 일이지만, 그렇게 하는 것이 옳은 일입니다.

반복해라, 그리고 반복해라(Iterate. Then iterate again)

좋은 서비스를 구축하는 가장 좋은 방법은 작게 시작하여 거칠게 반복하는 것입니다. 최소한의 실행 가능한 제품을 조기에 출시하고, 실제 사용자를 대상으로 테스트하고, 알파에서 베타로 전환하여 실시간으로 기능을 추가하고, 작동 하지 않는 기능을 삭제하고, 피드백을 바탕으로 개선해 나가세요. 반복은 위험을 줄여줍니다. 큰 실패의 가능성을 낮추고 작은 실패를 교훈으로 삼을 수 있습니다. 프로토타입이 작동하지 않는다면 과감히 폐기하고 다시 시작하는 것을 두려워하지 마세요.

모두를 위한 것이다(This is for everyone)

접근성 높은 디자인은 좋은 디자인입니다. 우리가 만드는 모든 것은 가능한 한포괄적이고 가독성이 높으며 읽기 쉬워야 합니다. 우아함을 희생해야 한다면 그렇게 해야 합니다. 우리는 청중이 아닌 필요를 위해 구축합니다. 우리는 웹 사용에 익숙한 사람들뿐만 아니라 전 국민을 위해 디자인하고 있습니다. 우리 서비스를 가장 필요로 하는 사람들은 종종 서비스를 가장 어렵게 느끼는 사람들입니다. 처음부터 이러한 사람들을 생각해야 합니다.

맥락을 이해해라(Understand context)

우리는 화면을 위한 디자인이 아니라 사람을 위한 디자인을 하고 있습니다. 고객이 서비스를 사용하는 맥락에 대해 깊이 생각해야 합니다. 도서관에 있나요? 휴대폰을 사용하고 있나요? 페이스북에만 익숙한가요? 웹을 사용해 본 적이 없나요?

디지털 서비스를 만들어라, 웹사이트 말고(Build digital services, not websites)

서비스란 사람들이 무언가를 할 수 있도록 도와주는 것을 말합니다. 우리의 임무는 사용자의 니즈를 파악하고 그 니즈를 충족하는 서비스를 구축하는 것입니다. 물론 그 대부분은 웹상의 페이지가 되겠지만, 우리는 웹사이트를 구축하기 위해 여기에 있는 것이 아닙니다. 디지털 세계는 현실 세계와 연결되어야 하므로 서비스의 모든 측면을 고려하고 사용자의 니즈를 충족하는 무언가를 만들어야 합니다.

일관성을 유지하라, 획일적이 아니라 (Be consistent, not uniform)

가능한 한 동일한 언어와 동일한 디자인 패턴을 사용해야 합니다. 이는 사람들이 서비스에 익숙해지는 데 도움이 되며, 만약 이것이 불가능할 때는 접근 방식이 일관성을 유지해야 합니다. 이것은 획일적인 지침이나 규칙서가 아닙니다. 상황은 모두 다릅니다. 효과가 있는 패턴을 찾으면 이를 공유하고 그 패턴을 사용하는 이유에 대해 이야기해야 합니다. 하지만 그렇다고 해서 향후 더 나은 방법을 찾거나 사용자의 요구가 변화할 때 이를 개선하거나 변경하는 것을 막아서도 안 됩니다.

개방성: 더 나은 서비스를 제공하라(Make things open: it makes things better)

우리는 할 수 있을 때마다 우리가 하고 있는 일을 공유해야 합니다. 동료, 사용자, 전 세계와 공유해야 합니다. 코드를 공유하고, 디자인을 공유하고, 아이디 어를 공유하고, 의도를 공유하고, 실패를 공유하세요. 서비스에 대한 시선이 많을수록 문제점을 발견하고, 더 나은 대안을 제시하고, 기준을 높이는 등 더 나은 서비스를 만들 수 있습니다. 우리가 하고 있는 일의 대부분은 오픈 소스 코드와 웹 디자인 커뮤니티의 관대 함이 있었기에 가능했습니다. 우리는 이에 보답해야 합니다.

영국 정부는 자신들의 Github (https://github.com/alphagov)를 통해서 정부 예산으로 만든 공개할 수 있는 모든 것을 공개하고 있습니다.

jongfeel / BookReview