비 엔지니어의 관리자 엔지니어 팀과 잘 지내는 방법

요즘 세상의 흐름은 무섭다. 전체 산업 소프트웨어 기업이되지 않으면 경쟁력을 유지할 수 없다.

"잘 때 제조업, 아침에 일어나면 소프트웨어 기업"
by Werner Vogels (CTO 인 Amazon.com) at AWS re : Invent 2017 Key Note

무서운 이야기 관리직에 떨어지는 때문에 "잘 때는 제조 관리자, 아침에 일어나면 소프트웨어 기업의 관리자"가 될 수 있을까? 생각을 시작해야합니다.
원래 은행원으로 비 엔지니어 어느새 개발 툴 벤더에 푹 내 경험에서 Tips를 공유합니다.
엔지니어 분들은 비 엔지니어 관리자에 しれと 링크를 보내주세요 (웃음)

결론 :
목표도 버스가 달리게 방법도 버스에 태운 우수한 사람들에게 맡기고, 버스 정비를하는 사람이된다.
관리자가 "무엇을 만들까?"결정권을 가질 수있는 그 / 그녀가 우수한 엔지니어의 경우뿐입니다. 비 엔지니어의 관리자는 오로지 엔지니어가 일하기 쉬운 환경을 만들 수 최대한 할 것입니다.

비즈니스의 방식이 다르다는 것을 이해한다.

소프트웨어의 세계는 규모의 경제가별로 효과가 없다
        제조업의 프로토 타입 → 양산이 아닌 프로토 타입 → 서비스 인 → 계속 개선.
        하드의 초기 투자가 거의 필요 없습니다. 서버도 클라우드로 싸다.
        1000 명의 조직을 만든 것이 5 명의 조직이 만든 것을 이길 수는 없다.

    BtoB 제품은 마케팅 제품 전략도 엔지니어 밖에 모르는
        기업이 모든 소프트웨어 기업이 오면 BtoB에서 팔리는 제품은 "엔지니어에게 친숙한 제품 '이된다. 엔지니어의 목소리는 엔지니어 밖에 모르는.
        같은 비즈니스 요구에 수백 개 업체가 솔루션을 내려고하고있다. SIer 계약 업무와 같은 「제대로 움직인다 "는 이길 수 없다. "엣지가 선 (특색)"제품이 이긴다.
        특색을 유지할 수 개발 프로세스도 필요합니다.

    직능 별 조직이 성립되지 않는다. Product Manager라는 수수께끼의 직책
        Product Manager가 제품의 위치를 ​​결정 에지 (특색)있는 제품을 만든다.
        Product Manager 마케팅, 영업, 개발, 예산을 제품의 '엣지'에 맞춰 만들어 세상에 내 놓는다. 여기에 불일치가 있으면 에지가없는 제품이 세상에 나온다.
        기존의 직능 별 조직에서 영업 및 지원이 강한 조직은 에지가없는 제품을 바르게 생각하고 만든다.
        인사조차 Product Manager 시선으로 설계 · 운용이 필요하다.
        제조업과 서비스업 (또는 기존 SIer) 조직 규칙 시선으로 운용은 무리.

소프트웨어 뇌와 그렇지 않은 사람은 다른 인종임을 이해

"소프트웨어가 세상을 돌고있다"라는 세계관 (요시오카 씨 신용).
    두근 두근 움직이고있는 사람이 많다. 싫은 일을 포지션 파워로 할 수 없다.
    낭비 반복 데이터가없는 결정 근거없는 근성주의 등을 극도로 싫어하는 (사실은 비즈니스맨이라면 누구나이지만).
    코딩 작업이 아니라 '아트'같다. "무슨 라인 코드를 작성하고 얼마나 버그가 작거나 '등의 지표로 평가하려고하면"너는 화가를 쓴 그림의 숫자로 평가 하는가? "는 핀잔하고 좋은 엔지니어는 그만 간다.
    여명의 우수한 인재가 제품과 서비스를 달리고 있다는 사실을 받아 들인다. 비 속인 화는 높은 수준에서는 무리.
    회사의 업무 및 기타 부분의 경계가 모호한 사람뿐. "낮에는 회사에서 일하고 밤에는 Blog 쓰고, OSS 위해 노력하고, 주말에는 1 일 연구회 '같은 사람이 많다.
    "내부 조정을 잘하는 사람"이 "제품을 선도 할 사람"것은 아니다. 정치력에서 일을 결정하는 것이 좋아하는 엔지니어는 없다.
    반대로, CTO, Product Manager와 제품의 결정권을 가져야 사람이 예산 관리, 경영에 대한보고, 사람 관리, 비즈니스 모델 만들기가 특기 것은 아니다. 종종 골칫거리.
    함께 일해 엔지니어는 서로의 기량이 알고있는 것 같다. 인사 사람이 밖에서 봐도 모르는데.

비 엔지니어의 관리자 의식해야할 것

스스로도 소프트웨어 뇌를 조금씩 만들기

    도달 할 수없는 것을 알면서도 기술을 공부한다. 관련 기술은 "Hello World"수준도 좋기 때문에 스스로 손을 움직여 본다. 걱정되는 서비스 제품은 반드시 손을 움직여 만지는.
    스터디 그룹 등 엔지니어가 모이는 곳에 나온다. 처음에는 무섭기 때문에 누군가 엔지니어의 사람에 붙어 간다. 우수한 엔지니어의 사람과 잡담하면 전혀 다른 사고 방식에 언급합니다.
    여기서 중요한 것은 '길 들여진 凡庸な 엔지니어'와 '우수한 엔지니어」의 2 종류의 사람이있는 것. 기업 규모 나 위치에서 판단하면 반대의 사람을 모델로 할 수 있음.
    무섭지 만 출력한다. Take 만 좋지 않다, 무엇보다 출력은 자신에 대한이기도합니다.

자신의 권한과 Product Manager 권한의 분리

    "사람을 관리하는 관리자"이어도 제품 · 서비스의 방향을 결정 PM의 역할은 할 수 없음을 인정한다. 일본의 조직에서는 PM이 전권을 쥐고 있지 않은 경우가 많고, 운영 관리자가 자신이 판단해서는 아니라 PM이 판단해야 할 사항을 판단하는 경우가 많다.
    예산 설정에 반드시 PM을 넣는다. PM 자신이 자신이 사용할 자원 및 커밋 출력의 균형을 잡는 것이 제일. 그러나 귀찮은 예산 작업을 환 던져하지 말라. 좋은 엔지니어는 알 잘라 예산을 비 엔지니어의 맨 설명 할 것은 싫어.
    인사 평가 및 채용도 가능한 PM 및 엔지니어를 넣는다. 채용에서는 반드시 코드를 쓰게 엔지니어 리뷰 해달라고한다.
    위쪽의 책임은 책임을진다. 슬픈 일이지만 스스로 판단하지 않는 것에 대해 책임을 가져야합니다.
    그러나 PM이 "성장하고있는 분야이기 때문에 시장의 1 %라도 잡히면 돈벌이 지요."등의 에지가없는 제품 리드를 시작하면 즉시 해고합니다.

엔지니어의 일하기 좋은 환경을 만들기

    좋은 엔지니어의 출력은 평범한 엔지니어의 5 ~ 10 배. 인건비와 비교하면 다른 비용은 작다.
    모두 Happy 될 필요는 없다. 우수한 엔지니어 Happy있을 수있는 환경 · 조직 · 규칙을 만들어 보자. 영업 · 경리 · 총무 · 인사 등 사람의 "오래된 상식」에 끌려 않도록합시다. "공정성"은 필요하지 않습니다.
    좋은 기계를 사용한다. 엔지니어 기계 선정 시키면 최고.
    좋은 책상, 좋은 의자, 조용한 환경, 좋은 모니터, 좋은 개발 도구. 반복, CData Software를 비롯한 좋은 개발 도구.
    출장비 등으로 기운 번거 로움을 걸거나 최악.
    맛있는 커피. 에스프레소는 당연히.
    스터디, 세미나, 책 등 자유롭게 돈을 사용한다.
    그러나 교제가 나쁜 사람이 많다 (웃음) 그래서 팀이 교류하는 구조가 필요. 점심이나 매주 Pizza 날인가.



비 소프트웨어 뇌의 사람과 소프트웨어 뇌 사람들 사이를 주선   

회사의 최고 소프트웨어 뇌 교육을 꾸준히 계속한다. 회사의 톱이 아닌 엔지니어의 경우 (대부분의 경우는 그렇 겠지만) 최고야말로 최대의 저항 세력입니다. 외부에서 고액 고용 슈퍼 엔지니어로 회사를 소프트웨어 기업화하는 임무를 가진 많은 사람들이 위를 비빌 단기에 그만 둡니다. 톱을 세뇌 할 수 밖에 없습니다.
    하지만 비 소프트웨어의 현장이나 소위 도메인의 이해는 엔지니어 팀에 필수입니다. 현장에서 일을 달리고있는 사람과의 토론의 기회를 만들 필요가 있습니다. 처음에는 생각이 다르기 때문에 대립하지만 현장과 격리 너무 잘 안됩니다.
    어리석은 규칙에 치외법권을 깐다. 기업은 우수한 엔지니어 겐 나리시키는 여러가지 어리석은 규칙이 존재합니다. 외부 메일 확인 업무 중의 SNS 금지 소프트웨어 다운로드 금지, 정형 보고서, 상사의 평가 중심의 인사 평가 체계, 사람 관리를 중심으로 한 승급 시스템, etc .. 대기업은 필요하지만 소수의 우수한 엔지니어 집단에는 필요하지 않습니다.