IT의 중심에서

기술은 사람을 행복하게 할 때 가장 가치가 크다.

성공적인 API 프로그램을 위한 10가지

Apigee Webinar 자료입니다.
API를 개발하고자 하는 기업이나 개발자들은 빼놓고 읽을게 없는 포스트입니다.

※ 출처 : 성공적인 API 프로그램을 위한 10가지(Apigee Webinar)

  1. Clear API ownership and strong internal evangelism
    (명확한 API 오너쉽과 강한 내부 전파 신념)

    • 강력한 스폰서쉽가 API 리더, 그리고 개발자 프로그램
      회사 전략과 API 가 어떻게 그 전략을 프로모션하는지를 이해하라.

    • API 전담팀
      product, engineering, community 매니저를 분리하고, 전담하게 하라.

    • 효과적인 커뮤니티 관리자
      외향적이면서, 코딩이 가능하고, 온라인 오프라인 커뮤니티를 좋아하면서, 열의에 차있고, 지속적인 전파성이 높은 사람
  2. Early and consistent vision, strategy, and metrics
    • API 비전에 대해 지속적인 설파 – 경영진부터 개발자까지
      비젼, 미션, 전략, 목표까지 공유하라.

    • top metric 상에서 조기 매입
      로드맵의 우선순위를 정하기 용이해진다.

    • 예상하는 숫자보다 실제 숫자를 따라가라.
      경쟁자와 비교가능한 수치에 근거해서, 규칙적으로 weekly dashboard 를 배포하라.


    VMSO Framework

    [Examples of API metrics]

    [Examples of Metrics Dashboard]

    • Vision : 브라우저를 넘어서 사업을 리딩해야 한다.
    • Mission : 개발자들이 고객이다. (매일매일 가르친다)
    • Strategy : 모바일, 소셜 개발자들에게 초점을 맞추고 새로운 개발자들의 진입장벽을 낮춘다.
    • Objectives : Reach (다가가기), Branding(브라우저 이상의 강한 이미지 심기), Revenue (3rd Party 앱으로부터 수익 share하기)
  3. Compelling and differentiated API
    • 만들어진 API가 쓸만해야 한다. Code examples = top priority resource
    • 1등 제품관리 : 개발문제에 초점을 맞추어서 개발해야 한다. 실제로 이 API를 쓸 것인가를 고민하라.
    • 차이점을 명확히 하라.

    [Product Positioning]

  4. Reminder : Less is more
    • 누구를 위해 만들 것인가? 타겟 개발자들이나 앱을 위해 기획하라.
    • 의심이 들면, 일단 그대로 두어라 : 모두를 만족시키려고 하지마라. 기능을 추가시킬 수는 있지만, 삭제시킬 수는 없다. 외부개발자들에게 내부 API를 배포하라.
    • API를 만드는 것보다, 사용하는 것에 10배의 노력을 기울여라.
      목표로 하는 앱과 비슷한 샘플을 만들고, 그것을 개발자들에게 배포해라.
  5. APIs are designed for adoption
    • 표준화되고 단순한 API = 더 많은 고객
      실용적인 REST 를 사용하고, 문서나 샘플코드가 훌륭한 프로그램을 개발하라.
      실용적인 REST 는 분석하거나 보호하기 더 쉽다.

    • 이상한 것을 추가하지 마라. 그냥 REST, XML, JSON 을 사용하라.
      call 을 작게 만들어라. 그냥 oauth 를 사용해라. custom security scheme을 만들지 마라.

    • Lots of APIs? 개발 경험의 일관성에 초점을 맞추어라.
      같은 회사가 만든 것 처럼. 동일한 사용법을. 등록하기 쉽고 사용하기 쉽게 가볍게 만들어라.

    “SOAP API 만 가지고 있겠다고 하는 것은, 당신 마켓의 80%를 미워하고 있다는 뜻이다.” – Sam ramji

  6. Get feedback early and iteragte quickly
    • 처음에는 당신이 틀릴 것이다.
      개발자들의 이야기를 잘 듣고, 빨리 진실되게 이야기하라.
      “우리의 고객은 우리를 완전히 다른 방향으로 데리고 간다.”

    • early feedback 을 위해서 알파,베타 그룹에 배포하라.
      개발자들에게 물어보라. “앞으로도 사용하실거예요?”

    • Design for agility
      버전정책이 잘못되면, API팀이 거의 유지보수할 수 없게 될 것이다.
      숨어 있는 아키텍쳐상에 코딩하지 마라.
      패키지로 버전닝하고, url 상에서 버전을 유지해라.
      하위버전 호환을 위해서 결정하라.
  7. Create leverage with developer community
    • 커뮤니티는 API 팀이 API를 보급하고 관리하기 위해서 매우 중요하다.
      비판과 채택에 대해 자유로운 커뮤니케이션의 가능한 집단
      피드백을 포럼이나 FAQ 에 저장하라. 폰에서 멀리 떨어져라.
      당신 직원이 아닌 사람도 데모를 할 수 있는가?

    • Developer marketing 은 developer portal 이 아니다.
      일단, 현재 있는 커뮤니티를 방문하라.
      그들의 소리를 듣고, 그들과 함께 일하라.

    • 무엇이 개발자들에게 동기를 주는지 연구하라
      개발자들은 마케팅을 싫어한다. 문제가 풀어지기를 원한다.
      개발자들은,
      – 다음직장을 위한 skill 을 배우고 싶어한다.
      – 자기가 개발한 제품이 사용되는 것을 보기를 원한다.
      – 유명해지기를 원한다.
      – 돈을 벌기를 원한다.

    [Profile Developer Segments]

    [Twitter Chirp 에 참여하기 전후 API Calls]

  8. APIs designed to understand use, prevent misuse
    좋은 API 디자인은 많은 장점을 가지고 있다.

    • API 디자인은 분석을 가능하게 한다.
      트래픽을 분석하기 위해서 sub-domain 을 활용하라 : API key를 사용하라.
      개발용인지, 사용자 트래픽인지 분간할 수 있어야 한다.

    • 사용과 미사용을 분석하라.
      파트너가 규칙을 어기는지를 지켜보는 고객이 있어야 한다.
      새 API 를 설계하기 전에 구 API 를 가지고 먼저 고민하라.

    • 처음부터 사용정책을 설계하라.
      limit (ops policy) 와 quota (business policy)에 대해 정의하라.
      사후에 key policy 를 강요해서는 안된다.
      당신의 이용방식을 구현하라.
      커뮤니케이션 하지 않고 개발자나, 파트너를 자르지 마라.
  9. Design business model and policies from start
    비즈니스 모델 만들기

    • 사전에 개발자들이나 파트너들과 기대를 공유하라.
      Policy 는 처음부터 정해져서 구현되어져야 한다.
      처음부터 비즈니스 모델을 염두해서 진행되어야 한다.

    • 선택이 가능한 여러개의 SLA 와 계층화된 접근
      일반 개발자를 위한 무료 API 군들
      프리미엄 개발자나 파트너를 위한 유료 API 군들로 나눌 수 있어야 한다.

    • 경영권자들과 기대 공유하기
      API 가 새로운 비즈니스를 만들 수 있을까?
      API 가 브랜드 영역을 확장시킬 수 있을까?
  10. Scalability and performance of platform and process
    • 낮은 API 성능과 신뢰성은 비즈니스 문제가 된다.
      수용량을 계획하라.
      트래픽 뿐만 아니라, 동시 처리성능도 높여야 한다.

    • 캐시와 트래픽 제어는 확장성을 높여준다.
      limit 와 quota 를 정하고, 계획된 최대치 이상의 접근을 통제하라.
      Best developer 들은 자르지 마라.

    • 비즈니스 프로세스 규모에 따라 설계하라.
      API 화가 미치는 영향을 측정하기 위해 사업 관계영역과 인터뷰하라.
      목표하는 최대치에 맞추어 규모를 설계하라.
      사전에 런칭 체크리스트를 가지고 프로세스를 설계하고 연습해보라.
      Advertisements

      답글 남기기

      아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

      WordPress.com 로고

      WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

      Twitter 사진

      Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

      Facebook 사진

      Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

      Google+ photo

      Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

      %s에 연결하는 중

정보

이 엔트리는 2011년 10월 27일에 님이 API와 기술에 게시하였으며 , , , 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: