Archive for the ‘quality’ tag
개밥 먹기(Eating one’s own dog food)
얼마 전에 했던 생각인데 아직 파트장등에게 제대로 제안을 해 보지는 못한 아이디어 하나.
Rephrasing 하려고 했다가 그냥 도비호님 포스트에 적은 댓글을 그냥 옮겨왔다.
분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다.
그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.
그래서 부서내 게시판을 하나 만들어서 내가 아닌 남의 프로그램에 대해 아쉬운 점이 있으면 적는 건 어떨까 하는 생각을 했습니다. 그리고 주기적으로 각 부서장들이 모여서 리뷰를 해서 정말 코드 수정까지 반영할 만한 가치가 것을 뽑아서 다음 번 패치때 추가하는 겁니다.
근데 아직 제대로 제안은 못했습니다. 제 생각에는 그럴 듯한데 말이죠.
- 개밥 먹기란 자신이 만든 프로그램을 직접 사용하는 것을 의미한다. 내가 만든 걸 내가 사용해 봐야 당연히 소비자가 느낄 수 있는 불편함이나 아쉬운 점을 먼저 느낄 수 있을 것이다.
20 Famous Software Disasters
초난감 기업의 조건에 나올 만한 사건들
20 Famous Software Disasters, Part 2, 3 and 4 via DevTopics
Mission-critical software일 수록 정말 조심해서 프로그램을 만들어야 한다. 하지만 우리가 하는 일이 mission-critical이 아니라 할 지라도 단 하나의 버그로 인해 초래될 수 있는 현상은 그 회사의 이미지를 바닥으로 내동댕이 칠 수 있다는 점을 반드시 기억해야 한다.
주변을 보면(물론 나도 포함해서) 너무 쉽게 프로그래밍하고, 너무 쉽게 버그를 생각하는 경향이 있다.
그런 사람들은 현장에 나가 고객을 한번도 만나보지 못한 경우가 많다. 내가 만든 소프트웨어 하나가 회사를 대변할 수 있다는 사실을 체감할 일이 없어서 이다. 회사를 사랑하고 그렇지 않고를 떠나서 내가 다는 회사를 내가 망하게 하려는 의도가 있지 않는 이상, 내가 만드는 소프트웨어에 최선을 다해야 한다.
개발자의 자존심이라면 버그없는 프로그램을 만들려는 노력이 아닐까?
collaboration
Collaboration is a structured, recursive process where two or more people work together toward a common goal—typically an intellectual endeavor[1] [2] that is creative in nature[3]—by sharing knowledge, learning and building consensus. Collaboration does not require leadership and can even bring better results through decentralization and egalitarianism.[4] In particular, teams that work collaboratively can obtain greater resources, recognition and reward when facing competition for finite resources.[5]
http://en.wikipedia.org/wiki/Collaboration
Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.