3/02/2016
불쾌한 브레인스토밍의 6가지 방법
이 글은 “유쾌한 브레인스토밍의 7가지 비밀”에 상반되는 내용이다. 브레인스토밍은 좋은 아이디어를 취하기 위한 활동이다. 하지만 자칫 잘못하면 시간만 허비하게 된다. 다음은 경계해야 할 브레인스토밍 방법이다.
1.(반드시)보스가 먼저 말한다.
세상에 존재하지 않은 아이디어를 내놓으시오. 이런 배경 설정에 마주치면 주눅이 들어 말이 이어지지 않는다.
2.참여 인원 모두에게 차례가 돌아간다.
시계 방향으로 돌아가며 각자 2분 동안 본인의 아이디어를 말한다. 이런 방식은 고통스럽다. (민주적이긴 하지만…)
3.전문가만 발언한다.
브레인스토밍에서는 전문가만 찾지 마라. 실무자에게 발언 기회를 주자.
4.특별한 장소에서 진행한다.
창의력을 발산 할 수 있는 장소를 만든다.
5.진지한 대화만 한다.
황당무계한 아이디어들이 도움이 된다고 생각하자. 어떤 말을 해도 좋다. 웃고 즐기는 가운데 좋은 아이디어가 나온다.
6.메모에 대해 집착한다.
모든 내용을 메모하려 하지 말자. 당신에게 필요한 것만 취하여 스케치하라.
- 유쾌한 이노베이션 中
2/28/2016
유쾌한 브레인스토밍의 7가지 비밀
브레인스토밍은 연습이 필요하다. 연습을 통해 잘할 수 있는 방법을 찾게되고 결국 잘하게 된다.
1.초점을 명확히 한다.
문제를 명확하게 묘사하여, 참여하는 사람들이 쉽게 주제에 접근 할 수 있도록 해라. 가령 “개인 정보 유출에 대한 보상”은 브레인스토밍 주제로는 좋지 않다. “개인 정보를 유출당한 사람들의 화를 삭힐 수 있도록 도와주는 방법” 처럼 적극적으로 참여할 수 있는 구체적 주제를 제시해야 한다.
2.규칙을 만든다.
아이디어를 비판하거나 반박하면서 시작하지 마라. 이런 부분은 “활기 약화”로 이어질 수 있다.
3.아이디어에 번호를 매긴다.
가장 중요한 것은 아이디어의 질이지만 브레인스토밍 진행전에 참가자를 자극하는 도구가 된다. “방을 떠나기 전에 백 가지 아이디어를 냅시다.”
4.때로는 단숨에 뛰어넘는다.
관념적인 얘기들로 아이디어가 정체될 때 활력을 불러일으켜야 한다. 마치 국민MC처럼 팀의 에너지가 고갈될 무렵 능력을 발휘해야 한다.
5.아이디어를 사방에 기록한다.
아이디어를 기록하는 방법은 여러가지가 있겠지만, 모임이 시작되기 전에 모든 벽에 낙서가 가능한 종이를 붙여라. 아이디어를 벽의 여백에 쓰면서 이리저리 방안을 걸어다니면 시너지 효과가 생겨난다.
6.워밍업 시간을 갖는다.
다음과 같은 상황에서는 워밍업이 필요하다. 함께 일한 적이 없는 모임인 경우 브레인스토밍 초보자들로 구성된 경우 주의가 산만해졌을 때
7.바디스토밍을 실시한다.
만져보고, 느껴보고, 살펴본다.
-유쾌한 이노베이션 中
2/27/2016
어떤식으로 시스템을 만들어야 할까?
제품 개발에는 비용, 품질, 기간, 범위라는 네가지 제약 조건이 있다. 기간을 무시하고 빨리 개발하려고 밀어붙이면 품질이 저하되거나 개발 인력이 늘어나 폭발적인 비용을 감수해야 한다. 물론, 기간만 단축시키고 개발 인력을 늘리지 않는 곳도 존재한다.
같은 비용으로 더 나은 품질의 소프트웨어를 만들려면 기능을 축소하거나, 소수 정예의 개발자들이 충분한 시간을 가지고 개발을 하는 것이 현실적이다. (맨먼스 미신도 있지 않은가?) 비즈니스의 성격에 따라 위 변수중 어떤것을 우선해야 할지 결정해야 한다. 좋은 시스템을 만든다는 것은 위 변수의 값이 타당해야 한다. 비즈니스/시장상황에 의해 위의 방정식이 무의미한 극단적인 프로젝트도 존재하겠지만 그러한 방정식의 해답은 없다. 이런 경우 실현 불가능한 것을 가려내고, 추후 실현 가능한 대안을 제시해야 되지만 비기술자가 결정을 내리는 경우에는 엉망인 코드만 양산할 뿐이다. 이 세상에는 기술로 이해할 수 없는 것들이 많이 존재한다.
-휴가라서 이런 저런 잡생각이 많이 드는 나
2/16/2016
MongoDB Schema Design — Part #1
이제까지 MongoDB를 로그 분석용으로 주로 활용했었고 다른 용도로 사용 할 경우에 스키마를 어떻게 구성해야 하는지에 대해서 검색한 결과를 정리한다. RDBMS의 스키마 디자인과는 다른 전략으로 접근해야 하고 아래 사항을 고려해야 한다.
- User requirement 기반으로 스키마를 디자인한다.
- 데이터를 read할 때 join하는 것이 아니라 데이타를 write할때 join해야 한다.
- 객체간의 관계를 고려한다. (Multiple collection과 Embedded)
MongoDB는 아래의 방법으로 관계를 표현 할 수 있다.
db.person.findOne() {
name: ‘Kate Monster’,
ssn: ‘123–456–7890’,
addresses : [
{
street: ‘123 Sesame St’,
city: ‘Anytown’,
cc: ‘USA’
},
{
street: ‘123 Avenue Q’,
city: ‘New York’,
cc: ‘USA’
}
]
}
위와 같이 embedded 방법을 쓸 경우에는 한 Query로 모든 정보를 가져 올 수 있다는 장점이 있지만, embedded details 정보만 독자적으로 가져 올 수 없다는 단점도 존재한다. Embedded된 데이터의 크기가 증가하게 될 경우에 document의 사이즈 제한을 넘어서는 일이 생길 수 있다. 아래와 같이 part의 document가 있다고 하면,
db.parts.findOne() {
_id : ObjectID(‘AAAA’),
partno : ‘123-aff-456’,
name : ‘#4 grommet’,
qty: 94,
cost: 0.94,
price: 3.99
}
각각의 Product는 하나의 document를 가지고 part document의 ObjectID를 array로 가지고 있는 구조로 구성한다.
db.products.findOne() {
name : ‘left-handed smoke shifter’,
manufacturer : ‘Acme Corp’,
catalog_number: 1234,
parts : [ // array of references to Part documents
ObjectID(‘AAAA’), // reference to the #4 grommet above
ObjectID(‘F17C’), // reference to a different Part
ObjectID(‘D2AA’), // etc
]
위와 같은 경우에는 application-level join으로 두 document를 연결하여 사용해야 한다.
// Fetch the Product document identified by this catalog number
product = db.products.findOne({catalog_number: 1234});
// Fetch all the Parts that are linked to this Product
product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;
각 document를 독자적으로 관리 할 수 있다는 장점이 있지만 각 document를 여러 번 호출해야 한다는 단점이 존재한다. event logging system처럼 많은 양의 데이터를 처리해야 할 경우에는 16MB document size의 제한 때문에 위에서 언급한 방법을 사용하지 못한다. 이런 유형에서는 parent-referencing 방식을 사용해야 한다.
db.hosts.findOne() {
_id : ObjectID(‘AAAB’),
name : ‘goofy.example.com’,
ipaddr : ‘127.66.66.66’
}
db.logmsg.findOne() {
time : ISODate(“2014–03–28T09:42:41.382Z”),
message : ‘cpu is on fire!’,
host: ObjectID(‘AAAB’) // Reference to the Host document
}
application-level join을 사용하여 데이터를 가져온다.
// find the parent ‘host’ document
host = db.hosts.findOne({ipaddr : ‘127.66.66.66’}); // assumes unique index
// find the most recent 5000 log message documents linked to that host
last_5k_msg = db.logmsg.find({host: host._id}).sort({time : -1}).limit(5000).toArray()
References:
- http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1
6/01/2015
2015, Virtual Team 회고
작년 부터 Virtual Team에 참여하여 업무외 시간을 활용하고 있다. Virtual Team의 매력은 분명하다. 서로 떨어진 장소에서 온라인 툴을 활용하여 협업을 진행한다는 자체가 매력적으로 보였었다. 딜로이트의 연구자료에 따르면, 대다수의 사람들은 온라인 툴을 이용한 커뮤니케이션이 덜 생산적이라고 생각한다고 한다. 이런 점을 보완하기 위해 아래의 서비스를 이용하여 작업을 진행했었다.
사용중인 서비스
- Slack
- Trello
- Github
- leanstack
UX에 대한 논의, 의사결정, Research 작업들이 진행되면서 한계에 부딪히기 시작했고 오프라인 미팅을 통해 협의했었다. 이 방법외에는 효과적인 방법을 찾지 못했다. 결국, 어떻게 하면 효과적으로 Virtual Team을 이끌 수 있을지에 대해서 고민이 생겼다. Virtual Team에 대한 자료들에서는 아래의 사항들이 언급이 되어 있다.
적절한 팀
우린 이미 팀을 구성했다.
사람
원할한 커뮤니케이션이 가능하고 독립적으로 일하는 능력을 가진 사람 우리 팀은 이런 사람들로 구성되었다고 생각한다.
크기
아직까진 작은 크기의 팀을 유지하고 있으니, 팀 구성원이 늘어났을 경우에 대한 부분은 해당 사항이 없다. 역할 각자의 역할은 이미 정의했다.
적절한 리더쉽
신뢰감 조성하기. 신뢰는 존중과 공감으로 시작된다. 이것을 토대로 관계형성이 되는 것이다.
열린 대화
Observable candor (관찰 가능한 솔직함)을 실행해야 한다.
적절한 접점
특정 시기에는 실제로 모여야 한다고 한다. (대면 회의, 이정표)
토론 포럼 혹은 가상팀룸
Slack을 활용중이다.
효율적인 Virtual Team의 요소들 중 상당수는 수용하고 있다고 생각된다. 업무외 시간을 할애하다 보니 “개인 시간 소비”가 원인으로 보인다. 그렇다고 가족과의 시간, 지인들과의 친목 등등에 할애하는 시간을 단절할 수 는 없지 않은가? 어려운 문제이다.
2/14/2015
직관의 종말과 슈퍼크런처
슈퍼크런처(SUPER CRUNCHERS)란 책의 제목을 정할 때 저자는 무작위 추출실험을 수행했다고 한다.
저자가 처음 생각한 책의 제목은 “직관의 종말(The End of Intuition)”이었지만, 슈퍼크런처가 좀더 긍정적인 메시지를 전달해줄 수 있을 것 같아서구글 애드워즈 캠페인을 실행했다고 한다.
“데이터 마이닝” 또는 “넘버크런칭”을 검색하는 사람들에게 “슈퍼크런처”와 “직관의 종말” 중 한가지가 노출되도록 캠페인을 설정한 결과 “슈퍼크런처”를 클릭할 확률이 63%가 높은 사실을 발견했다고 한다.
저자는 무작위 추출실험의 결과대로 “슈퍼크런처”를 선택했고 책은 베스트셀러가 되었다. 만약, “직관의 종말”을 제목으로 선택했다면? 슈퍼크런칭에 의해 정말 직관은 종말을 맞이하게 되는걸까? 개인적인 생각으로는 직관의 종말은 오지 않을 것 같다. 다가 올 미래에서는 직관력과 슈퍼크런칭 능력을 갖춘 사람들에게 많은 기회가 주어지지 않을까 생각해 본다.