사실 개발 방법론이라는 것을 7개월 전만 해도 귓등으로 듣고 그게 왜 필요한지도 알지 못했던 것이 사실입니다. 부끄럽지만 애자일이 수많은 프로그래밍 언어중 하나인줄 알았죠.10개월 전만해도 우리 팀은 저를 포함해서 3명에 불과했고 모든 것은 메신저와 구글 드라이브로 일을 처리했습니다. 기억력이 좋지않지만 머릿속에서 각 팀원들이 언제까지 뭘하고 다음엔 무엇을 언제까지 해야겠다라는 것이 그려질 정도로 적은 숫자였죠. 개발방법론이 필요한 이유가 없으니 무관심한 것은 당연했습니다. 이 글을 읽으시는 분들 중에 아마 7개월 전의 저와 같은 생각을 하신 분이 있을지도 모르겠네요.지금 우리 팀은 11명으로 늘어났고(그중에 소프트웨어 개발팀만 7명) 그들 하나하나를 마이크로 매니징하기에는 저라는 인간이 너무나 머리가 아팠습니다. 그래서 도입한 것이 애자일 개발방법론이었는데 애자일은 비록 실패로 끝났지만 거기서 많은 교훈을 얻고 칸반으로 전환하는 원동력이 되었습니다.우리 팀은 애자일 개발선언 중에서도 "계획을 따르기보단 변화에 대응하기"라는 선언을 굉장히 맘에 들어했는데, 그 이유는 애자일 도입이전 우리의 상황이 그랬기 때문이었습니다. 매일매일 고객의 요구는 들어오고 경영진과의 대화에서 매일매일 우선순위가 바뀌고, 그에 따라 하던 작업이 마무리되지 않으면 브랜치를 새로 파서 다른 작업을 하고 미완성된 코드는 늘어났으며 그에 따라 불평불만도 늘어났습니다.여러 애자일 개발방법론 중에서도 우리가 선택했던 것은 eXtreme Programming(XP)이었는데, 우리에게 스크럼과 같은 1달간의 스프린트는 너무 길다, 2주간의 이터레이션(Iteration)으로 구성된 XP가 좋다라는 것이었습니다.우리는 스크럼 보드를 준비했고 거기에 포스트잇을 붙여가면서 아침마다 스크럼 회의를 했으며, 기록을 남기기위해 레드마인을 사용하였습니다.eXtreme Programming Flow Chart간단하게 왜 실패했는지 이유를 들어볼게요.1. 배포 계획(Release Plan)을 수립하기 힘들다물론 계획자체를 만들기 힘들다는 것이 아닙니다. 배포 계획을 만들어도 그대로 지켜지지 않았습니다. 큰 틀로 배포 계획을 만들고 작은 틀로 반복 계획(Iteration Plan)을 세우는 것이 목표였는데, 수립을 해봤자 절대 지켜지지 않았습니다. 우리와 같은 작은 스타트업의 작은 팀은 시장의 요구사항이라는 급류에 이리저리 쓸려 매일매일 계획과는 다른 일을 하고 있었거든요. 리팩토링할 시간은 커녕 테스트 코드를 짤 시간조차 없었습니다.(핑계일수도 있지만요)거짓말이 아니고 단 한번도 계획대로 되지 않았습니다.2. 팀원들의 시간 예측 능력 부족애자일은 팀원들이 시간 예측을 굉장히 잘한다는 가정하에 잘 돌아가는 방법론입니다. 모두가 함께 한자리에 모여 복잡도를 논의하고 그에 따른 프로젝트의 시간 예측을 하고 함께 번다운 차트(Burn-down chart)를 그리며 하하호호 잘 나아가야 하는데, 우리 팀은 그렇지 않았습니다. 물론 실력부족이라고 탓할 수도 있겠지만 실제로 스크럼 보드에 예측시간 8시간이라고 적어놓고 4시간정도만 지나면 다른 문제가 터지거나 다른 기능을 개발해야하는 둥 제대로 지켜지지 않았을 뿐더러 그런 방해요소가 없다고 하더라고 8시간보다 더 많이 걸리거나 더 적게 걸리기도 했습니다.예측시간을 측정하기 힘든 마이너한 이유중에 하나는, 스파이크 솔루션(Spike solution)를 개발하는데 얼마나 걸리는지 예측하지 못한 탓도 있었는데 이 세상에 없는 솔루션을 개발하는데 있어 이전의 경험만으로는 턱없이 부족했습니다.이런 이유들 때문에 우리는 XP를 버릴 수 밖에 없었습니다. 계획보다는 변화에 적응하자!라는 원대한 목표가 있었지만 애자일 개발방법론은 우리가 닥친 미친듯한 변화를 감당하기에는 벅찼습니다. 우리는 스크럼 보드를 점점 멀리하기 시작했고 다시 구글 드라이브로 돌아갔습니다.저는 구글 문서(Google Docs)에 우리가 해야할 요구사항을 적었습니다. 우선순위가 높은 일일 수록 상단에 두었습니다. 그 오른쪽에는 일을 해야할 사람의 이름을 적었습니다. 그렇게 적고 문서를 공유하면 팀원들은 그 문서를 보고 그 순서대로 일을 진행하였습니다. 일을 진행하다가 생기는 의문점은 급한 일일 경우 구두로 전달하고 급하지 않을 경우에는 메신저 또는 문서의 빈공간을 활용하여 적었습니다.완료된 요구사항은 취소선을 긋고 옅은 글씨로 처리하여 해야 할일과 완벽히 구분되도록 하였으며 한 사람당 해당 시간에 하나의 일만 처리하도록 규칙을 세웠습니다. 보류되는 일은 보류 섹션으로 할일을 옮기고 보류가 되는 이유를 적도록 했습니다. 혼자 해결하기 힘들경우 회의를 통하여 함께 해결할 수 있는 자리를 마련했구요.그런식으로 우리는 배포 시기를 최대한 맞추려고 노력했고 이상하게도 XP를 버리고 구글 문서로 갈아타니 일이 더욱 수월해져서 이제는 생각보다 일이 빨리 끝나는 것이었습니다. 그리고 더욱 놀라운 일은 지금까지 우리가 했던 방식이 칸반과 유사하다는 것이었습니다.저는 바로 칸반 보드를 도입했고 이에따라 애자일에서 배운 규칙/정신과 칸반의 장점을 혼합하여 우리 팀만의 칸반보드를 완성하였습니다. 현재 우리가 쓰고 있는 칸반 보드는 Kanboard의 오픈소스를 그대로 사용하고 있습니다.1. 활발한 커뮤니케이션을 토대로 개발한다. 절대 혼자 일하지 않는다- 지속적으로 팀의 동의(Team agreement)를 구한다.- Knoledge island를 탈출하라(자신이 알고있는 지식이 전부가 아니다).- 코드 병목현상(Code bottleneck)을 탈출하라. Collective ownership을 발동하라.2. 한 번에 한개의 일만 처리하라. 보류하는 일은 최소로 하라칸반의 핵심으로 한 번에 한개의 일만 처리하도록 합니다. 개발자의 뇌는 하나도 손은 두개이고 손가락은 열개이므로 한 번에 하나의 일만 처리해야 합니다. 한 개의 일이 끝나지 않으면 다음 일을 진행하지 않는 것을 규칙으로 합니다.3. 가능하다면 예측시간을 적는 습관을 들인다개발완료시간을 정확히 예측하는 것은 개발자들에게 정말 중요한 능력중에 하나입니다. 신제품을 시장에 빨리 내놓을 수록 피드백을 빨리 받을 수 있으며, 고객으로부터의 소중한 피드백은 개선된 다음 버전을 위한 초석이 되기 때문입니다. 사업적으로 성공하고 싶다면 예측시간을 꼭 적는 습관을 들여 자신이 정해진 시간 동안 얼마만큼의 일을 할 수 있는지 예측하는 일이 큰 도움이 됩니다.4. 더 좋은 방법이 있다면 기존의 방법을 과감히 버린다저의 철학과도 일치하는 이야기인데요, 우리 팀과 회사가 함께 좋아질 수 있는 방법을 발견한다면 과감히 현재의 방법을 버리고 새로운 방법을 시도한다라는 우리 팀만의 맹세입니다. 앞으로 항상 발전하겠다는 의지를 가지고 잠시 손을 놓고 한발짝 물러서서 비판적인 자세로 모든 것을 바라보는 시간을 가지는 것도 혁신의 첫발짝이라고 생각합니다.지금까지 우리 팀이 꾀한 겉으로 보기에 가장 큰 혁신은 기존의 속도가 느리고 사용하기 불편했던 솔루션을 과감히 버리고 새로운 서버와 새로운 언어로 전환하면서 마이그레이션 및 새로운 형태의 최적화된 솔루션을 구축했다는 것입니다.(물론 내부적으로 가장 큰 혁신은 기존의 방법을 버릴 수도 있다라는 생각을 가졌다는 것이지요)현재 저는 팀 매니저로서 User story(요구사항정의서) 관리, Release plan(배포 계획서), 와이어프레임을 포함한 기획서 등 최소한의 문서만 관리하고 있으며, 팀원들 또한 이 시스템에 만족하며 아직까지는 판단하기 이르지만 굉장히 좋은 방법인것 같습니다.5개월간 칸반을 사용하면서 팀원들로부터 받은 피드백은 다음과 같습니다.1. 매일 아침 15분씩 하는 스크럼 회의는 새로운 기능 또는 새로운 프로젝트를 진행할 때는 굉장히 유용하지만, 디버깅 또는 테스팅 기간에는 시간낭비다.이 말을 한 팀원의 말에 따르면, 우리 팀은 데이터베이스를 관리하는 사람, API를 만드는 사람 등등 각자의 역할이 확실히 나누어져 있는데 새로운 기능을 개발할때는 여러사람과 소통해야하는 경우가 많고 개발 스펙이 달라지거나(작게는 함수이름 변경 등) 여러 변수들이 작용할 수 있으므로 짧게 자주만나는 것이 좋다고 말했습니다.2. 회의도 시간낭비다- 회의는 가급적 개최하지 않고 가능하다면 1:1 구두로 해결한다.- 급한일이 아닐경우에는 이메일/메신저를 활용하도록 한다.3. 칸반 보드에 보류 칼럼, 테스팅 칼럼을 나눈다보류 칼럼과 테스팅 칼럼을 나누어 적어 어떤 할일이 보류되었으며 어떤 할일이 테스팅 중인이 확실히 하도록 했습니다. 이는 테스팅을 하는데 오래걸리는 기능들이 있으며 테스팅을 하는 동안 다른 기능을 개발할 수도 있다는 것이 큰 이유였습니다.우선 순위가 바뀌었을 때 할 일을 잠시동안 놓아둘 칼럼이 없다는 것이 보류 칼럼이 존재하는 가장 큰 이유였습니다. 그러나 보류 칼럼에 놓을 수 있는 할 일의 수는 개인당 1개로 제한하여 2개 이상의 보류하는 일이 없도록하여 경각심을 갖도록 하였습니다.앞으로의 계획은 전에 언급했던 와비파커(Warby Parker)의 기술팀이 도입한 와블스(Warbles) 시스템을 적용해보는 것입니다. 우리 팀이 어떻게 바뀔지 정말 기대가 됩니다.#비주얼캠프 #인사이트 #경험공유 #조언 #개발자 #개발팀

1. 심장이 "말린 무화과" 같다는 생각을 해본 적이 있는지? 심장이 쫄깃! 하다는 말로는 표현이 부족하다. 쫄깃하다는 것은 충분한 수분과 탄력이 있다는 것을 말하지만.. 요즘 내 심장은 쫄깃이 아니라 거의 수분을 잃어가는 말린 무화과 같은 느낌이다. 그런데 그런 것들이 이제 일상이 되는 것 같은 느낌이랄까?심장이 "말린 무화과가" 된다는 것은...최소한 아직 안쪽은 쫀득하다는 뜻이겠지.2. 작은 성공을 계속 만들어가는 것이 중요하다. 스타트업 선배 중에 한 분이 말씀해 주신 것이다. 파펨을 1년 반 이상 경험을 하면서 느끼는 것은... 정말 중요하다는 것이다. 실제로 작은 성공을 만들어 내는 것일 수도 있고, 아니면 정말 별것 아니지만 성공으로 생각하고 축하하는 것이다.그래야 지치지 않는다.갈길이 멀기에...3. 어디로 가야 할지 아는 것사실 파펨의 모델은 처음에 기획된 부분도 많이 있지만, 계속해서 진화해 가고 있다는 것이 맞다. 그 중심에는 향기(fragrance)라는 것이 있고, 우리가 가는 첫 번째 목적지는 PerfumeTeller의 성공이다. 퍼퓸텔러는 기존의 향수 시장에서 Game Changer가 되겠다는 생각을 가지고 실용적이며 합리적인 면을 강조하고 있는데, 향수라는 제품이 지금까지 가지고 있던 category의 이미지와는 맞지 않는 것이 사실이다.게다가 우리는 후각의 객관화라는 중간 목표를 가지고 있고.. 마지막으로는 냄새를 생성해내겠다는 생각까지 가지고 있다. 이건 향수 회사인지 아니면 tech 회사인지 혼동이 될 수도 있겠지만, 중심에는 후각이 존재한다. 어디로 가야 할지 안다는 것은 파펨에 올라탄 사람들이 무엇을 해야 할지에 대한 방향을 잡아줄 수 있고, 스스로 일할 수 있게 만들 수 있기에 상당히 중요하다.4. 누구와 일할 것인가?파펨에서 일하는 사람은...생각할 줄 알고 그것을 실행할 줄 아는 사람이기를 바란다. 바란다기보다는 그런 사람을 계속해서 받아들일 것이다.생각을 할 줄 안다는 것은... 우리가 어디로 가야 하는지를 아는 상황에서 자신이 무엇을 고민해야 하는지 알며, 발전을 만들어 낼 수 있는 능력이 있다는 것이다.게다가 그 생각을 실현하는 능력 또한 중요하다. 단지 고민만 하는 사람보다는, 구현해낼 줄 아는 사람이 필요하다. 그것이 디자인이던, 글이던, 혹은 operation이던 실행까지 마무리할 줄 알아야 한다. 그러기 위해서는 본인의 speciality가 필요하다는 생각이다. 요즘 열심히 찾고 있는 중이다.5. 어떤 성장을 그릴 것인가?처음부터 폭발적인 성장을 하게 된다면 얼마나 다행이겠냐만은...   그럴 가능성이 높지는 않기에, 차근차근 성장 전략을 세워야 한다. 성장 전략 중에 중요한 하나는 자원의 배분이다. 또한 많은 자원 중에 가지고 있는 자본금을 어떻게 배분할까의 고민이다.처음부터 빵! 터트릴 것(full 조직 setting, 공격적 마케팅 등) 인가? 아니면.. 계속해서 조금씩 조금씩 가지고 있는 자원을 사용해가며 성장의 기회를 찾아볼 것인가? 두 모델의 장단이 있다. (이 내용에 대해서 글을 작성 중) 파펨의 경우는.... 차근차근 준비를 해왔다. 최적의 타이밍을 잡고서 모아둔 자원(이런 건 사실 없다..)을 쏟아붓는 것이다.옛날 전쟁 영화에서 (활이던 총이던) 사정거리 안에 적이 들어올 때까지.... 기다리고 기다렸다가 가지고 있는 공격력을 쏟아붓는 것처럼. 자... 이제 파펨도 공격의 타이밍을 잡을 때다.이 글을 어제 쓸 때만 해도... 소식을 기다리고 있던 상황이었으나, 답이 오지 않고 있었는데드디어 오늘 아침 축하 소식이 날아들었다. ㅠㅠFuturePlay와 아모레퍼시픽(AP)의 TechUP+ 프로그램에 최종 합격하신 것을 축하드립니다.물론 이 소식이 회사에 당장 어떤 큰 변화를 줄 수 있을지 모르겠지만, 우리에겐 축하해야 할 작은 성공이고 또 이로 인해 좋은 사람들을 모을 수 있는 계기가 된 것도 사실! 심장이 이젠 조금 쫀뜩해진 기분이다!!자 이제 공격하러 GOGO#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

월말마다 다음 달 근무표를 짜는 업무는 우리 모두에게 정말 골치아픈 일로 다가옵니다. 수많은 근무자들이 있는 환경에서는 극심한 악몽을 줄 수도 있습니다. 예를 들어, 한 회사가 화장품 리테일 매장을 50 개, 직원이 600 명 있다면 저희는 이 회사에 대하여 다음과 같은 추측을 할 수 있습니다. 여러 명의 지역 관리자가 있을 것이고 각 지점마다 매니저가 있을 수 있습니다. 관리자들은 이미 상점을 운영하기 위한 많은 업무로 바쁨과 동시에 해당 달의 판매 목표를 충족해야 하기도 합니다. 그 와중에 Excel을 이용하여 몇 시간 동안 컴퓨터 앞에 앉아 다음 달의 근무 일정을 계획 하기도 해야 합니다. 이들은 중요한 업무를 뒷전으로 두고 생산적이지 못한 근무표를 계획하고 급여정산을 하는 데에 많은 시간을 할애 할 수는 없는 노릇입니다. 매장을 관리는 어려운 일이지만 근무일정 스케줄링 만큼은 쉽게 할 수 없을까요?더 쉽고 빠르게 일정 짜기Shiftee는 다음과 같은 세 가지 방법으로 관리자의 스케줄링 프로세스를 용이하게합니다.쉽고 빠른 근무일정 및 휴무 스케쥴링근무표를 자동으로 공유급여 예측보다 쉽고 빠른 근무표 계획은 시프티의 강력한 기능인 멀티스케줄로 해결합니다. 한 번에 여러 근무일정들을 일괄 생성할 수 있습니다.- 특정 직원 멀티스케줄: 한 번에 특정 직원의 여러 산발적 근무일정을 만듭니다.- 다수 직원 멀티스케줄: 한 번에 다수 직원들의 함께 반복하는 근무일정을 만듭니다.멀티스케줄 작동 과정대규모 직원 풀과 시프티의 스케줄러시프티는 직원이 많고 지점이 많은 큰 규모의 기업에서 가장 효율적으로 이용할 수 있습니다. 우리는 4 가지 액세스 레벨을 제공하고 회사 내 다수 지점를 지원함으로써 중견/대기업에 맞는 스케줄링을 실현할 수 있습니다. 또한 특정 지점관리자에게 특정 지점(들)을 배정하여 타지점에 대한 접근을 허용하지 않습니다. 시프티는 다음 산업 분야에 적용될 수 있습니다:도급업체/파견업체: 고객에게 아웃소싱 혹은 파견인력을 제공하는 회사공장 또는 시설 운영 (예 : 제조, 발전소 등)물류센터테마 파크 (예 : VR, 방탈출, 놀이공원, 유원지 등)F&B 기업소매업병원호텔프로세스, 프로세스, 그리고 프로세스워크플로우, 절차를 개선하는 것은 프로세스 관리만큼이나 중요합니다. 프로세스 관리에 많은 함정과 비효율이있는 경우, 이를 수정하거나 전 절차를 다른 방법으로 대체하는 대안을 찾아야합니다. 현재 많은 관리자들의 스케줄링 프로세스는 다음과 같습니다.각 직원의 근무 가능 시간, 휴무일 등 확보 후 엑셀에서 관리무능한 스케줄러, 즉 Excel로 근무표 계획원본 근무표 엑셀과 동기화 할 수 없는 방식으로 근무표 공유 (예: 이메일 혹은 메신저)근무표가 수정될 때마다 재공유함으로서 발생하는 비효율기술적으로 진보 된 현 시대에 위의 프로세스에 걸맞지 않다고 생각하시나요? 시프티 30 일 무료 체험 버튼은 시프티 홈페이지에 있습니다.이제 스케줄링이 당신의 비즈니스에서 지각된 문제임라고 생각한다면 지금 바로 행동하세요. 시프티를 통해 관리자들이 보다 중요한 업무에 집중할 수 있도록 시간을 절약해 주세요.#시프티 #고객가치 #핵심가치 #기업소개 #서비스소개

그래서 에이스프로젝트에는 어떤 역할이 있나? 팀 야구 구단에는 단장과 감독이 있다. 단장과 감독은 둘 다 구단의 성공을 목표로 하지만 서로 다른 역할을 수행한다. 단장은 외부 커뮤니케이션에 대해 권한이 더 크고 감독은 선수의 육성을 책임진다. 감독과 단장이 리더의 각 역할을 나누어 수행하는 것처럼 에이스프로젝트도 기존 팀장의 역할을 팀 디렉터와 팀 매니저의 역할로 세분화해 수행하고 있다. 팀 디렉터는 팀원의 업무 역량을 이끌어 아웃풋을 퀄리티업 한다. 팀 매니저는 팀 문화를 주도하며 내적 동기부여를 유도해 팀원이 일하기 좋은 환경을 조성한다. 1. 팀 디렉터팀 디렉터는 팀원의 역량 개발과 성장을 책임진다.팀원 개개인의 전문성을 향상시키고 팀의 전문화에 관련된 의사결정을 한다.팀원이 더 나은 방향으로 성장하기 위해 필요한 인사 배치, 평가, 교육에 관여한다. ＊ 구성원에게 적합한 업무와 역할을 배정한다＊ 직접 교육하거나 사외 교육을 지원한다＊ 팀원의 성장을 위한 평가와 피드백을 제공한다＊ 면접을 보고 팀원 채용 여부를 결정한다＊ 앞으로의 업무 발전 방향을 제시한다＊ 현재 진행되고 있는 작업물의 퀄리티 향상을 위해 도움을 준다  2. 팀 매니저협상 기술에는 소프트 스킬과 하드 스킬이 있다. 하드 스킬이 '지식'을 강조한다면 소프트 스킬은 정성적인 면에 더 초점이 맞춰져 있다. 팀 매니저는 구성원 간의 커뮤니케이션, 팀워크, 리더십 등을 활성화할 수 있는 소프트 스킬을 주로 활용하는 역할을 한다. 팀원들의 회사생활과 동기부여, 팀 문화를 책임진다.  ＊ 주기적인 면담을 통해 팀원 개개인과 소통한다＊ 조직문화에 대해 팀원과 소통한다＊ 팀의 행정 업무를 수행한다＊ 팀 내 행사(회식, 워크샵, 스터디 등)을 운영한다   프로젝트 기능별로 구성된 팀과는 별개의 형태로 프로젝트 조직이 있다.프로젝트 내에서는 기획, 그래픽, 클라이언트, 서버 파트가 유기적으로 협업한다.프로젝트 조직은 전문화를 목표로 하는 팀과는 달리 성과/목표지향적인 조직으로 결정권이 PD에게 집중되어 있다.스크럼 마스터는 스케쥴 관리자, 각 파트 디렉터는 투수 코치, 타자 코치와 비슷하다고 볼 수 있다.     1. PDPD는 프로젝트 전체를 계획, 총괄, 감독하는 역할이다.PD는 프로젝트의 효율적인 성공을 위한 의사결정을 해야 한다.  ＊ 프로젝트 총괄 의사결정권이 있다＊ 프로젝트 인원을 편성한다＊ 프로젝트 내 각 파트 분쟁을 중재한다＊ 비용 집행과 관련된 의사결정을 한다＊ 개발과 릴리즈 일정을 결정한다  2. 스크럼마스터스크럼마스터는 스크럼 프로세스를 관장하고 구성원의 스케쥴을 관리한다. 줄여서 '스마'라고 부른다. ＊ 무리한 일정을 거부할 수 있다＊ 스크럼 회의를 주재한다＊ 구성원의 업무 진행상황을 파악한다  3. 파트 디렉터프로젝트 내 각 파트에서 만들어진 아웃풋에 대한 의사결정을 내리는 사람을 파트디렉터라고 한다.기획 파트 디렉터, 그래픽 파트 디렉터, 클라이언트 파트 디렉터, 서버 파트 디렉터가 있다.  ＊ 맡은 파트의 아웃풋 퀄리티를 향상시킨다＊ 파트 구성원에게 업무를 배분한다'숟가락 얹기'를 금지한다최근 많은 회사들이 커뮤니케이션은 자유롭되 업무역량은 전문가적인 조직을 만들기 위해 고민하고 있다. 대기업이 창의적인 문화를 도입하기 위해 복장규정을 완화하거나 스타트업이 체계적으로 일하기 위해 여러 가지 규칙을 만드는 것도 보다 좋은 문화를 가진 회사, 일을 잘 해내는 회사를 만들기 위한 시도라고 볼 수 있다. 에이스프로젝트도 일하기 좋은 회사, 역량 있는 인재들이 함께하고 싶을 만한 회사를 만들어나가기 위해 여러 사람들이 모여 다방면으로 고민했다. 다양한 가치관을 가진 구성원들이 맡은 업무를 하는 와중에도 지금 우리에게 맞는 최선의 문화가 무엇인가에 대해 생각했다. 무수한 토론과 열띤 설득의 과정을 거쳐 나온 것이 지금의 역할 중심 문화다.요약하자면 역할 중심 문화는 역할은 있지만 직급은 없고, 직책은 있지만 위계는 없는 문화다. 기존의 팀장이 혼자서 결정하던 것들을 각 역할을 가진 사람들이 모여  함께 논의한다. 위계를 없애 의사결정 전에는 커뮤니케이션을 활발하게 하면서도 최종적으로 결정하고 책임지는 사람을 지정해  더 일하기 좋은 환경을 만든 데에 의의가 있다. 문화는 제도나 규범과 달리 반드시 지켜져야 하는 정해진 무엇이 아니기 때문에 계속해서 변화한다. 현재의 역할 중심 문화가 에이스프로젝트의 ‘정답’이라고 할 수는 없다. 실제로 역할 중심 문화를 운영하면서 예상하지 못한 문제가 드러나 이를 개선하기 위해 새롭게 고민하기도 했고 누군가 더 나은 방법을 제시해 그것을 도입해보기도 했다. 에이스프로젝트는 모두가 참여해 어제보다 오늘이 더 나은 회사를 만들어가고 있다.