== hari haddi===

  1. Ways to communication.
    • email is
    • issue 트래커 -> 이슈트래커(트롤로??) 이슈 트래커(마케팅, 비용결제, 출장?) 효율적으로 일할 수 있음.
    • 코멘트를 달면서 관리할 수 있음 (알람.)

CC 달려서 계속 온다. 이슈트래커는 본인에 대한 처리만 하면됨. (게시판)

slack -> 안좋다. > 밀고 당기기의 문제.

  1. push vs pull 정보를 계속 보내면 상대방은 무시하게 된다. 정보의 양을 제한해야한다. 문서를 쓰든, 프로세스를 쓰든.

  2. Internal newsletter 사보. 사내신문. 이런일을 했어요…..

    • 상품 개발은 어떻게 되고 있고..
    • 수익은 어떻게 되고..
    • 내부 컨퍼런스.. 마케팅 or 기술과 관련없는 것도 이야기를 하더라…. Technical Wednesday’s : 기술적인 이야기를 할 수 있는 날. 웬스테이…

3. 회사의 사다리를 올라가는데 더이상 그 사다리를 올라가지 못함. 항상 상사의 허락을 구해야하고, 아무리 원해도 그걸 만들 수 없는 한계점…

No micro-management : 좋은거아냐? 사실 그렇게 쉽지는 않다.

  • 사람들을 모아 불러서,

KPI : 주요 성과 지표를 하면서 시스템화 하기는 쉽다. 내가 뭔가를했고그걸 측정하기 위해서 매우 쉽다. 케파를 못맞췄다. 상사가 울그락 풀그락…. 더 일하고 케파를 맞춰야하는지,

시스템안에서 유용한 것을 만드는게 아니라 KPI를 맞추는데 중요하게 된다.

층층별로 결제를 받을 일이 없다면 보고할 필요도 없고, 보고를 해야만하는 것도 있고…. 한국시스템은 아닌거 같은데….

보고(중복 업무)를 막기 위해서….무정부 사태…에 대한 방지책.. 목표를 정한다. 개발이 효율적으로 이루어지게가 목표.

Set a series of goals -> 개발자를 도와서 효율적으로 작업할 수 있다.sk

Knowing how to control your passions > 열정있는 개발자를 찾습니다? 열정이 지나쳐서는 안된다. 열정이 지나치면 필요한 것에 집중을 하지 못한다.

And auestionin if what you’re doing adds value > 업무가 부가가치를 생성하는지 어떻게 알수있을까?

리더쉽 = 회사의 병목현상을 해결해줌. -> not being a bottleneck Learning to delegate

  • 마음을 열고 다른 사람과 비교하지 않고 비판을 하지 않으면서 다른방안같은 지침을 주는 사람.
  • 어떤 사람은 지식

Providing guidance

  • 지침을 주고, 안주고를 판단하며,

Being candid

  • 업무 성과가 별로일떄, 지금 업무가 별로 진행되지 않는다.

  • 부서 및 사람 : 그 사람의 커리어에 손해다.

  • Knowing how to listen and be heard : 리슨과 히얼은 틀리다. 리슨은 경청을 한다. 신경을 써서 든다. 히얼은 소리가 들리니까 들리는 거다. 논쟁이 붙었을 때, 이 사람이 하는 말이 내가 마음에 안드는 말이다. 내가 반박을하고, 계속 반박을 할 때, 나는 경청을 할떄 그냥 들었을 때…

Most of all - trusting and caring.

  • 진정으로 믿기가 숩지는 않다. 배려는 어렵다.
  • 상사가 날 신경안써줄 때 , 친절과 친분은 다르다. 배려를 해줄 수가 없다. 행동(관계)성이 중요하다. 개인적인 관계가 더 중요하다. 그건 배려를 해줄 수가 없다. 서로 믿지 않으면 믿을 수가 없으면, 서로 불신이 쌓인다.

사람들이 왔을 때, 불신이 생기면 다시 신뢰를 쌓기는 매우 어렵다.

Keeping the Culture.

Culture is infused. You lead by example. -> 문화를 주고 그대로 따라라고 해서는 안된다. 사람들이 행동으로 보여주고, 그대로 따라가야한다.

“Never attribute to malice that which is adequately expalained by ignorance.” Don’t moan up the corporate ladder. Help fix it.

Emphasis on Feedback. Give it, Receive it.

  • 기업문화적으로 보았을 때, 직접 말로 긍정적으로 피드백을 주는 것도 좋다. 내가 그 KPI를 못맞췄을 때

====

20년간 개발시간과 소프트웨어의 품질은 그렇게 까지 차이가 나지 않는다.

소프트웨어의 가치를 근로자의 노동 시간으로 측정할 것인가?

  • 소프트웨어는 소비자 눈에는 경계까 보이지 않는 제품.
    • 하드코딩? ?
    • docker

4차 산업 혁명 blurring

클라우드? 5G 모델 싸움? 2020년 (인텔리IDE) 이론상 100배, 체감상 10배. AI. VR 의 고도화되는 세상이 만들어짐.

BUT, 개발자는 코드만 봅니다.

개발자가 보지 못하는 시장의 가치 -> 개발자는 피해자인가? 사안에 대해 서로를 이해못하기 때문이다. 10년이 지나면 앞으로 사라질 것이 아닌가 싶다.

왜 클라우드 기업이 되어야하는건가? -> 개발하청을 받은 기업이 클라우드 기업이 되어야하는데, 기업솔류션에게 사업아이템을 판매해야함. 그런 솔류션은 써보고 달달이 내면된다. 매출액 비율로 산정하면, 장사가 안되었을 때, 수수료를 내면 장사가 안되면 금액이 떨어지는데, 프로젝트를 하면 3:3:4가 중요하지 장사가 안되어도 계약대로 하여야하며, 서로상생하기 위해서는 클라우드로 해야함. 이런 이야기가 개발자에게는 안들린다. 개발자의 가치를 내가 짠 코드가 사용자 가치에 맞추는 과정이 클라우드 이관 작업이다.

웹앱의 미래 (The Future of Web Apps) 1,138조의 비즈니스 웹 앱 시장

브라우져를 벋어났다.

MSA 적용에 대한 조언을 묻는 분들에게 우리가 취하는 아키텍쳐의 자세는?

기민한 개발 조직을 위한 (방법론이 아닌) 개발일상 설계 팀 네부 기술 문제는 그들의 일상문제

  • 만들고 나서 떠날 사람이 정할 수 있는가? 조언은 몰라도… 표준은 여러 개의 마이크로 서비스가 난립할 떄 비로소 필요
  • 개발 초기 표준 정하는 일은 위험없이 생색내는 방법 기획은 피드백을 빨리 받을 수 있을 때 유효함
  • 장기 계획을 구체적으로 세우는 오류는 범하지 말자. 아키텍쳐는 사업과 우리 조직의 모양에 따르는 일 당신은 MSA 로 무엇을 얻을 것인가?

—-> 개발해보고 문제 생기면 고쳐라. 한번 성공하려면 대여섯번은 삽질해야한다. 삽질을 티안나게 작게하자!

쌍방의 노력이 필요하다.

——-> 자극 : 사회적 가치?????