슬랙이라는 메신저의 설계 철학
서로 다른 업무용 메시징 소프트웨어는 비슷해 보이지만 서로 조금씩 다른 철학을 의도했든 그렇지 않든 가지고 있습니다. 선택할 수 있는 입장이라면 이를 조금 파악하고 있으면 좋을 겁니다.
Software Development
절차에 대한 의사소통
우리들은 일상의 의사소통에 말을 사용합니다. 그런데 어떤 의사소통은 절대 그렇게 해서는 안됩니다.
인터랙션 오브젝트는 어쩌면 통합이 능사가 아닐지 모른다
지금까지 비슷한 기능을 하는 여러 장치를 한 가지 시스템으로 통합하거나 처음부터 그렇게 설계해 왔는데 어쩌면 그게 늘 옳은 방법이 아닐지도 모르겠습니다.
우리는 아직도 바퀴를 재발명하고 있다
이전에 왜 뻔한 기능을 항상 다시 개발하는지 생각해봤습니다. 시간이 지난 지금도 상황은 비슷합니다.
진짜 목적을 숨긴 빌드업
게임디자이너는 자신의 정확한 요구사항을 문서에 기술하기를 요구 받지만 때때로 이런 접근은 프로젝트가 처한 문제를 해결하는데 덜 효율적일 수도 있습니다.
데이터베이스가 고장 나면 게임이 어떻게 동작해야 하나요?
생각보다 드물지 않게 게임의 일부에 장애가 발생하면 나머지 부분이 어떻게 동작해야 할 지에 대한 게임디자인 관점의 대책을 제시할 것을 요구받습니다. 이 요구는 올바르지 않다고 생각합니다.
왜 그 프로젝트는 출시되지 않을까
어떤 프로젝트는 개발을 계속하지만 영원히 출시되지 않을 것처럼 보입니다. 어째서일까요? 어쩌면 출시가 목적이 아닐 수 있기 때문입니다.
소통이 원활히 이루어졌으면 해요
소통은 모든 것을 의미하는 단어이지만 동시에 그 무엇도 표현하지 못하는 단어입니다. 소통을 하려면 도대체 무엇을 해야 할까요?
이름과 본질
종종 어떤 의도를 가지고 본질과 다른 이름을 붙여 부를 때가 있습니다. 의도를 달성하기 위함이겠지만 종종 본질을 흐리게 만들어 문제를 일으키기도 합니다.
왜 우리의 서드파티 도구 도입은 실패할까?
여러 프로젝트에 걸쳐 항상 비슷비슷한 기능을 개발합니다. 이런 기능 중 상당수는 플러그인 모양으로 이미 누군가 예쁘게 만들어 놓아 돈을 내면 순식간에 이를 가져올 수 있습니다. 하지만 이런 행동은 보통 실패하는데 어째서일까요.
요구사항의 구렁텅이에서 빠져나오기
내가 작성한 기획서가 내가 원하지도 않는 이상한 요구사항들이 덕지덕지 늘어선 상태가 되었나요? 그 상태에서 빠져나와야 합니다.
종료되지 않는 모바일 앱 요구사항의 추억
기획팀은 처음으로 요구사항이 도착하는 곳입니다. 그런데 만약 불가능한 요구사항이 기획팀에 도착하면 어떻게 해야 할까요?