반갑습니다 :)

“설명이 가능하면 제작이 가능합니다”

저희는 최근 10년간 웹,모바일,앱,오프라인 윈도우,ERP 프로그램만을 해오는 개발전문 회사입니다.

항상 새로운 것에 호기심을 갖고 공부를 하는 회사입니다.

현재까지 고객과 많은 프로젝트들을 완료해 왔으며, 일부 클라이언트사와는 프로젝트 완료후 동업관계를 가지며, 다양한 사업을 진행하고 있습니다.

그러다보니, 서로 고마워 하는 Win Win 관계를 잘 유지하고 있습니다

저희도 최상의 서비스를 제공함과 동시에 좋은 평점을 받기 위해 많은 노력과 가능한 서비스들을 제공해드리려 애쓸것입니다.



1. 모바일 어플리케이션

1) 네이티브 앱(Native App)

- 안드로이드 : Java or Kotlin

- 아이폰 : Swift

2) 하이브리드 앱(Hybrid App)

- React Native

3) 웹뷰 앱(Webview App)

- Html, CSS, JavaScript, React Native

2. 프론트 엔드

1) 웹 or 모바일 웹

- Html, Css, JavaScript, React js

3. 백엔드

1) 서버 언어(Server)

- PHP

- Node js

2) 데이터베이스(Database)

- Maria DB

- MySQL

3. 디자인

- Adobe XD

4. 기획

- Pigma

턴키 방식으로 프로젝트는 기획 > 디자인 > 개발 순으로 진행됩니다.

1. 킥오프 혹은 상담

- 전달주신 기능명세서 혹은 요구사항정의서 내용을 검토하여, 서비스 진행 가능 여부와 견적, 일정에 대한 상담을 진행해드립니다.

기획적인 부분이나 상세한 기능 진행에 대한 디테일한 상담은 결제 후 진행이 가능합니다.

2. 결제

- 협의된 견적과 기간으로 크몽을 통하여 결제를 진행합니다.

3. 기획

- 기능명세서 혹은 요구사항 정의서 내용을 기반으로 개발용 기획서를 작성합니다. 스토리보드 형태로 UI/UX 화면정의가 진행되며, 사용자와 관리자 기능의 플로우와 정책의 내용을 기획서로 작성합니다.

기획서 컨펌 기간 동안 수정이 가능하며, 컨펌 완료 이후에 디자인 작성을 진행합니다.

4. 디자인

- 기획서 내용으로 전체적인 디자인 시안이 작성됩니다.

5. 개발

- 개발하고자 하시는 플랫폼에 맞춰 진행이 됩니다.

퍼블리싱을 먼저 진행하여, 검수과정을 거치게 됩니다.

검수가 완료되면 기능이 포함된 개발이 진행됩니다.

6. 검수

- 개발된 내용을 검수하는 단계입니다.

오타가 생기거나 오류가 발생하는 부분을 수정합니다.

단, 기능의 변경과 기획과 달라지는 수정은 별도의 과정 및 추가 일정이 필요합니다.

7. 수정

- 검수 과정에서 주신 피드백 사항을 수정합니다.

8. 완료

- 7번까지의 내용이 만족하였을 때 프로젝트가 완료됩니다. 완료 이후 추가사항이 없을경우 개발 코드는 전달 가능합니다.

1. 요구사항 정의서 혹은 기능명세서(필요시 작성 샘플을 제공드립니다)

2. 메뉴 구조도

3. API 명세서(별도 api 연동이 필요한 경우)

1. 준비해야 될 자료가 있나요?

클라이언트님이 전달하는 내용은 주로 비즈니스 모델에 대한 것이 반면 저희가 필요한 자료는 서비스의 설계나 기획, 기능의 구현 가능 여부 측면입니다.

위 내용을 구체적으로 설명하고 구현하기로 합의한 업무 범위를 명확하고 완전하게 명시한 문서가 '기능명세서' 혹은 '요구사항 정의서' 에 해당합니다.

성공하는 프로젝트에 ‘알아서 잘~’은 없으며, 클라이언트님도 저희와 한팀이 되어 서비스를 ‘함께’ 만들어나가야 합니다.

2. 요구사항 정의서가 왜 필요한가요?

클라이언트님과 저희가 충분히 커뮤니케이션하고, 요구사항이 의도한 대로 잘 반영되고 있는지 꼼꼼히 확인하기 위해서 필요합니다.

해당 서비스에 대해서 가장 잘 아는 사람은 클라이언트님입니다. 저희가 클라이언트님이 생각하시는 서비스와 똑같이 그릴 수 있도록 도와주셔야 합니다.

‘요구사항 정의서’의 내용으로 진행이 되기 때문에 이 과정에서 커뮤니케이션이나 정의 내용이 소홀히 되면 원하시는 서비스의 방향과 어긋날 수 있습니다.

3. ‘눈 감고 코끼리 만지기’를 아시나요?

클라이언트님이 생각하시는 서비스는 ‘코끼리 한 마리’입니다.

만약 클라이언트님께서 기능으로 ‘코’, ‘머리’, ‘다리’, ‘짧은 목’, ‘얇은 꼬리’라고 설명을 주신다면 저희는 설명 주신 기능을 상상해서 만들어야 될 수 있습니다.

요구사항 정의서는 누가 보더라도 ‘코끼리 한 마리’라는 것을 파악할 수 있게끔 작성이 되어야 합니다. ‘코’라는 기능을 얘기한다고 하였을 때 ‘길다란 코를 가지고 있으며 코는 손을 대신하여 쓸 정도로 섬세하고 주가 되는 기관이다’ 정도로 상세하게 작성이 필요합니다.

4. ‘요구사항 정의’라는 건 어떻게 해야 할까요?

1) 서비스 목적을 명확하게 정의

만들려는 서비스에서 핵심 고객은 누구인지, 고객들이 왜 해당 서비스를 사용하고자 하는지, 어떻게 서비스를 통해 수익화를 할 것인지 명확히 정하셔야 됩니다.

서비스 목적을 명확하게 정의해야만 내 서비스에 무엇이 필요한지 정확하게 인지를 할 수 있게 됩니다.

2) 요구사항 정의

서비스의 목적과 방향을 정했다면 이제 요구사항 정의를 해야 합니다. 외주를 맡기기 전에 요구사항 정의라는 과정은 꼭 필요합니다.

요구사항을 정의할때는 클라이언트님이 만들고 싶은 서비스의 기능별 플로우를 하나하나 펼쳐서 작성 해보시는 것이 좋습니다.

5. ‘요구사항 정의서’를 작성했는데 기획서는 필요 없는 건가요?

요구사항 정의서 작성이 기획의 완료를 뜻하는 것은 아닙니다.

‘기획완료’란 개발자가 기획문서를 보고 바로 작업에 착수할 수 있는 상태를 의미합니다

클라이언트님의 요구사항 정의서는 ‘초안 버전’에 해당하며, 저희가 전문가의 시선에서 다시 분석하고 다듬는 작업이 필요합니다. 기능명세서, 스토리보드 작성 등의 기획 고도화 과정을 거치고 나서야 디자인과 개발이 가능합니다.

6. ‘OO’앱과 똑같이 만들어주세요!

위와 같이 요청하신다면, 완전히 똑같은 결과물은 나올 수가 없습니다. 작업 시작 전 ‘OO’앱의 어떤 기능을 어떤 수준까지 동일하게 구현할 것인지 반드시 합의가 필요합니다.

기능이란 클라이언트님이 정의하셨던 서비스의 목적과 방향에 따라 기능의 정의, 플로우, 정책과 같은 다양한 것이 바뀔 수 있습니다.