협업시스템

CRC는 언제쩍 기술인가요?

요즘 객체지향에 흥미가 있는 개발자라면 대부분 들어봤을 법한 책이 있습니다. 저도 지난 6월 27일 무려 6권이 사서 회사 동료들에게 돌립니다. 아래 그 증거가 있죠. 분명히 말하지만, 저자가 지인이라서 산 것은 아닙니다. :) 6권 구입의 나비효과 이런 경우에도 나비효과란 말을 써도 되는지 모르겠네요[1]. 책을 나눠줬더니 한 동료가 회사에서 쓰는 협업시스템dooray에 글을

[북경창업기] UI 기획자가 도망갔다!

언제였나? 암튼 커머스 혹은 유통 도메인 설계에 대한 연작이라는 이름으로 진지하게 나만의 글쓰기 놀이를 한 일이 있습니다. 찾아보니 올해 2월까지 했네요. 최근에 배운 일에 대한 감상을 이어서 쓸까 하다가 혼자 놀기도 그렇고... 마치 다른 사람인양 글쓰기 연습도 하기로 마음 먹고 사실에 기초한 픽션을 연재로 걍~ 해봅니다. 제목은 북경창업기 왜 그런

SaaS: 머나먼 소프트웨어 "다품종 소량 생산"의 길

클라우드 소프트웨어 서비스 산업이란 장르에서 아직 정제되지 않은 우리의 진보에 대해 기록하려고 한다. 이 글은 개념적으로 잘 정제된 용어나 기술을 다루는 대신에 타이밍을 다투는 비즈니스 시장에서 벌어지는 실제 이야기를 담는데 그 가치를 두려 한다. 또한, 중국시장에서 한국 개발자가 주도하여 중국 개발자들과 함께 이제 막 열리고 있는 SaaS 시장에 도전하는 우리의

생산성

메일과 두레이를 이용한 협업 파이프라인 구축

같은 제목의 기사가 HBR 한글판에 올라왔다. 유료 매체이니 관심있는 분들은 찾아서 읽어 보시길 바란다. 필자는 이 글에 매우 공감하는 입장이지만, 이미 오랜시간 스스로의 방법으로 이메일로 소비하는 시간을 줄여 왔다. 그래서, 기사 제목과 저자가 말하는 핵심 메시지만 빌리고, 평소 나의 활용법을 저자가 주장하는 방식에 대한 구체적인 한 가지 실천 방법으로 공유하려고

그룹웨어 결재 기능으로 보이는 동료의 작명 검토를 하다가...

이 글은 갑자기 벌어진 일상의 장면에서 나 자신이 어떻게 행동하는지 스캔하듯 돌아본 글이다. 그 과정에서 내면을 관찰하고 긍정적인 방향으로 항해하려고 노력한 기록을 사후 해석해보는 시도이다. CostApproval (비용-결재) 이라는 이름은 적절한가? 최초의 나의 질문은 동료가 지은 이름을 검토하는 일이었다. 처음에는 영어 표현이 옳은지 살피려 했는데, 습관적으로 위키피디아로 나아갔다. 그런 습관적

Aggregate를 애그리게잇 대신 조립물로 쓴 사연

동료 유영모가 ID로 다른 애그리게잇을 참조하라에서 애그리게잇을 본문에서 조립물로 바꾼 사연에 대한 이야기다. 두레이로 popit 글 검토를 하는 우리회사 popit 글 검토는popit 저자들이 글을 쓰는 워드프레스 시스템 상에서 벌어진다. 그런데, 사내에서 쓰는 두레이로 우리끼리 대화를 하고 싶어서 회사안에서는 채널을 만들었다. 워드프레스는 결과물 편집은 좋지만, 의견을 주고 받기는 어려우니까. 그러던 차에

DDD의 BoundedContext가 우리의 이야기와 밀접해지다

첫 연재에서 소개한 개념 정제 후에 동료 개발자가 해당 내용 구현에 나섰습니다. 두 계층으로 나누어 연결한 상품 개념 이전에 그린 그림을 조금 수정해서 상황에 대한 설명을 보강합니다. Product와 Item 개념 사이에 그린 두 가지 관계를 동료 개발자가 구현한 것이 아닙니다. 그래서, 둘 사이를 연결하는 Catalog 개념을 추가하여, 그의 구현을 Catalog

(소프트웨어) 모델링은 왜 하는가?

얼마 전에 객체 모델링 공부하게 책 하나 추천해주세요를 쓴 탓인지 동료의 작업에 댓글[1]을 달다가 문득 모델링이란 개념에 대한 생각에 빠졌다.   벤 다이어그램을 왜 그리는가? 동료에게 왜 저런 제안을 했을까? 목적은 두 가지다. 하나는 작업 내역을 읽다 보니 아직 하려는 일의 초점이 불분명한데, 성급하게 코딩부터 하려는 동료 개발자를 돌려

상품 정보 관리 라이브사이클 정의

커머스 혹은 유통 도메인 설계에 대한 연작 (지난 글) 1편. 커머스 혹은 유통 도메인 설계에 대한 연작 오랫동안 추적한 일이다. 생각으로는 금방 정리할 수 있는 내용이지만, 실제로 구현할 수 있도록 정의하는 일은 그와는 다른 일[4]이다. 여튼 또 기회가 왔다. 시작은 한 개발자가 엑셀 업로드 기능을 만들었는데, 동료 기획자가

Dooray 서비스를 이용한 서비스 개발조직 협업 개선

요즘 일상에서 가장 많이 쓰는 도구는 Dooray 서비스다. 지난 번에 지극히 개인적인 활용을 다룬 글을 올리긴 했지만, 두레이의 일반적인 쓰임새는 개인 작업 관리용이 아니라 협업 도구다. 약 19개월정도 써온 사용자1)로서 두레이를 쓰면서 이 점은 좋으니 널리 알리고 싶다거나 이렇게 써보면 좋겠다고 느낀 내용을 몇 가지를 써본다. * 화면 기획서를 공유하며

개인 작업 관리를 Trello에서 Dooray로 옮기기

10년 가까운 기간 동안 팀 협업 도구로는 주로 이슈 트래커를 썼다. Jira, Redmine, Github 등을 쓰고 Confluence 위키 제품을 보완하는 도구로 써왔다. 그런 가운데도 따로 개인 시간 관리를 할 필요를 느꼈다. 회사 일외에 개인적으로 일정을 챙길 필요가 있고, 가끔은 회사 일이지만 혼자만의 작업이 필요한 경우도 있었다. 또한, 회사 일인지 아닌지

조직 문화를 소프트웨어 개발 조직답게 만들어가기

정확히 이러한 문화를 뭐라 불러야 할지 모르겠다. 기민한 개발조직으로 만들려고 혹은 시장에서 도태되지 않기 위한 간절한 변화의 노력으로 지난 2년간 만들어낸 우리 조직[1]의 개발 문화에 대한 이야기다. 뭉뚱그려 말하면 애자일이라 할 수 있겠으나 애자일이라는 말의 쓰임이 너무나 다양하게 쓰여지고 있어 의미를 얼마나 전달할까 싶다.  아무튼 일을 해나가는 과정속에서