<div id="readability-page-1" class="page"><article><header><p>communication</p><small>Created: 2020, 11 15 &gt;<a href="https://github.com/shdkej/shdkej.github.io/blame/master/content/Feedback.md">Updated: 2021, 06 01</a></small></header><nav><strong>Table of Contents</strong><div><ul>
<li><a href="/feedback/#feedback-circuit">feedback circuit</a></li>
<li><a href="/feedback/#review-report-monitoring-response-communication">review, report, monitoring, response, communication</a></li>
<li><a href="/feedback/#software-feedback">Software Feedback</a></li>
<li><a href="/feedback/#feedback">Feedback</a></li>
<li>
<p><a href="/feedback/#%ED%94%BC%EB%93%9C%EB%B0%B1%EC%9D%80-%EC%9E%98-%EC%A7%84%ED%96%89%EB%90%98%EA%B3%A0-%EC%9E%88%EB%8A%94%EC%A7%80-%ED%8F%89%EA%B0%80%ED%95%A0-%EC%A7%80%ED%91%9C%EA%B0%80-%EC%9E%88%EC%9C%BC%EB%A9%B4-%EB%AA%85%ED%99%95%ED%95%B4%EC%A7%84%EB%8B%A4">피드백은 잘 진행되고 있는지 평가할 지표가 있으면 명확해진다</a></p>
<ul>
<li>
<ul>
<li><a href="/feedback/#%EB%B9%A0%EB%A5%B8-%EC%8B%A4%ED%8C%A8">빠른 실패</a></li>
<li><a href="/feedback/#feedback-1">feedback</a></li>
<li><a href="/feedback/#search">search</a></li>
<li><a href="/feedback/#feedback-2">feedback</a></li>
<li><a href="/feedback/#%EC%B1%84%EB%84%90%EC%9D%84-%EB%A7%9E%EC%B6%94%EA%B3%A0-%ED%86%B5%EC%8B%A0%ED%95%98%EB%A9%B4-%EC%86%8C%ED%86%B5%EC%9D%B4-%ED%99%95%EC%8B%A4%ED%95%B4%EC%A7%88-%EC%88%98-%EC%9E%88%EB%8B%A4">채널을 맞추고 통신하면 소통이 확실해질 수 있다</a></li>
<li><a href="/feedback/#%EB%B3%B5%EC%9E%A1%EC%84%B1%EA%B3%BC-%ED%94%BC%EB%93%9C%EB%B0%B1">복잡성과 피드백</a></li>
<li><a href="/feedback/#feedback-3">feedback</a></li>
</ul>
</li>
</ul>
</li>
</ul></div></nav><p>---</p><section><h2 id="feedback-circuit"><a href="#feedback-circuit" aria-label="feedback circuit permalink"></a>feedback circuit</h2>
<p><img src="https://shdkej.com/feedback/img/feedback.png" alt="feedback_circuit"></p>
<blockquote>
<p><a href="http://cad.kyungpook.ac.kr/micro/feedback/feedback-detail.html">http://cad.kyungpook.ac.kr/micro/feedback/feedback-detail.html</a></p>
</blockquote>
<h2 id="review-report-monitoring-response-communication"><a href="#review-report-monitoring-response-communication" aria-label="review report monitoring response communication permalink"></a>review, report, monitoring, response, communication</h2>
<p>5F</p>
<ul>
<li>fact, feeling, finding, future, feedback</li>
</ul>
<p>running server with auto attachment
auto feedback</p>
<ul>
<li>running well?</li>
<li>how speed?</li>
<li>any problem?</li>
<li>need more?</li>
</ul>
<p>program -&gt; feedback -&gt; program -&gt; feedback</p>
<ul>
<li>program send data to feedback</li>
<li>feedback send data to program</li>
</ul>
<p>running well: health check</p>
<p>how speed: test script</p>
<p>any problem: log</p>
<p>need more: receive client voice</p>
<p>선순환</p>
<ul>
<li>좋은 인재 - 좋은 글 - 많은 독자 - 수익 증가 - 좋은 인재</li>
</ul>
</section><section>
<h2 id="software-feedback"><a href="#software-feedback" aria-label="software feedback permalink"></a>Software Feedback</h2>
<p>알림이 너무 많이 오면 노이즈가 되어 무시하게 된다
변경 사항에 대해 알림을 준다</p>
<p>한 번에 너무 많은 메시지는 피곤하다
같은 에러가 여러 번 오면 따로 표시해준다
시각적으로 한 눈에 알 수 있으면 좋겠다
에러가 발생한 곳이 어딘지 알려주면 좋겠다</p>
<p>배포 후 배포 상황 확인</p>
<p>변경 작업 후 모니터링 페이지로 가서 한 눈에 확인할 수 있으면 1차 확인은 되겠다</p>
<p>행동별 보는 페이지가 있으면 되겠다</p>
<p>grafana는 다양한 메트릭을 보여줄 수 있어서 사용하되, 한눈에 보는 페이지는 따로
관리해야겠다</p>
<ul>
<li>grafana에서 셋팅하는게 무난해보인다... alert 설정도 좋고, export도 잘되고</li>
</ul>
<h2 id="feedback"><a href="#feedback" aria-label="feedback permalink"></a>Feedback</h2>
<ul>
<li>하루를 돌아보는 작업도 피드백</li>
<li>프로젝트를 회고하는 것도 피드백</li>
<li>
<p>슈팅 후 원하는 위치에 갔는지 확인하는 것도 피드백</p>
<ul>
<li>슈팅을 어떻게 했는지 모르고 감으로만 차면 감만 늘고, 기술적 성장은 안된다</li>
</ul>
</li>
</ul>
<h2 id="피드백은-잘-진행되고-있는지-평가할-지표가-있으면-명확해진다"><a href="#%ED%94%BC%EB%93%9C%EB%B0%B1%EC%9D%80-%EC%9E%98-%EC%A7%84%ED%96%89%EB%90%98%EA%B3%A0-%EC%9E%88%EB%8A%94%EC%A7%80-%ED%8F%89%EA%B0%80%ED%95%A0-%EC%A7%80%ED%91%9C%EA%B0%80-%EC%9E%88%EC%9C%BC%EB%A9%B4-%EB%AA%85%ED%99%95%ED%95%B4%EC%A7%84%EB%8B%A4" aria-label="피드백은 잘 진행되고 있는지 평가할 지표가 있으면 명확해진다 permalink"></a>피드백은 잘 진행되고 있는지 평가할 지표가 있으면 명확해진다</h2>
<p>계획이 성공되려면 중간 중간 평가할 요소가 있어야겠다
추적할 수 있는 지표</p>
<h4 id="빠른-실패"><a href="#%EB%B9%A0%EB%A5%B8-%EC%8B%A4%ED%8C%A8" aria-label="빠른 실패 permalink"></a>빠른 실패</h4>
<p>빠르게 진행해서 빨리 피드백을 받는 것
실패는 항상 찾아오니까 빨리 개선점을 찾으려고 하는 것</p>
<p>근데 무턱대고 하면 안되고, 그렇다고 너무 준비를 오래해도 안된다</p>
<p>어렵다</p>
<p>진행됐다고 치고, 진행이 되면 반드시 실패가 찾아온다. 피드백을 빨리 받고 고쳐서
다음 단계로 나간다.
처음 시작하는 것을 어떻게 할지가 어렵다
말을 적게 하면 좋다는 생각에서
많이 해서 고치는게 좋다는 생각으로 바꼈었는데
무작정 많이하면 안된다는 것도 새삼 깨달았다</p>
<p>많이 하되, 정제된 상태로 많이하는 것이 능력이겠다
+정 반 합 으로 생각을 한번 정리한 후에 말하면 되려나+
+피드백을 받을 수 있는 형태로 정제해서 진행+ 하면 무작정 뱉는 것보다 나아질 수
있겠다</p>
<h4 id="feedback-1"><a href="#feedback-1" aria-label="feedback 1 permalink"></a>feedback</h4>
<p>피드백을 어떻게 줘야 하나...</p>
<ol>
<li>콘솔에서 아웃풋</li>
<li>메신저로 보내기</li>
<li>슬랙 같은 팀 채널에서 모아서 관리하기</li>
</ol>
<p>피드백의 핵심은 즉시 알아차리게 하는 것인데
메신저는 약간의 지연이 있을 것 같다 (비동기 통신 방법이긴 하네)
동기 통신으로 보내자면 또 저장을 못하고,
그러면 개발 중에 메신저를 항상 켜놓는다는 전제로 생각해야하나
채널을 하나로만 하면 너무 많은 데이터가 쌓여서 또 곤란하겠네</p>
<p>개인 개발 시에는 메신저로 오게 할까
근데 메신저로 오면 업무의 연속성이 안좋을 것 같다
노트북으로 작업할 때는 노트북에서 바로 볼 수 있어야겠는데</p>
<h4 id="search"><a href="#search" aria-label="search permalink"></a>search</h4>
<ol>
<li>
<p>시작점을 찾는다 (내부에 들어가기 전에 내 생각을 먼저 확인한다)</p>
<ul>
<li>피드백을 빨리 받아서 고치는 방법을 알고 싶다</li>
<li>피드백을 효율적으로 받는 방법을 알고 싶다</li>
<li>과학적으로 행동에 대한 인지를 하는 방법을 알고 싶다</li>
<li>다른 영역이 응답을 빨리하는 것에 대해 모은 지식을 알고 싶다</li>
<li>어떤 방식으로, 어떤 주기로, 어떤 내용을 주면 좋을지 알고 싶다</li>
</ul>
</li>
<li>
<p>단어를 모은다 (측정 가능한 기준을 세워서 범위를 잡는다)</p>
<ul>
<li>
<p>피드백</p>
<ul>
<li>빠른 피드백 주는 법</li>
<li>피드백 실험</li>
</ul>
</li>
<li>모니터링 서비스의 피드백</li>
<li>운동에서의 피드백</li>
<li>기계 시스템에서의 피드백</li>
<li>빠른 피드백</li>
<li>개발에서 빠른 실패, 애자일</li>
<li>온라인스토어에서 고객의 불만 접수 및 응대</li>
<li>연예인이나 컨텐츠 제작 후의 시청자 반응에 대한 응대</li>
<li>공인이 불미스런 사건을 일으켰을 때의 조치</li>
<li>커뮤니케이션에서의 피드백</li>
<li>회사 메뉴얼의 축적</li>
<li>회고</li>
<li>fail fast</li>
<li>
<p>피드백의 종류가 다양하다. 정량적 피드백, 정성적 피드백
기계에게 하느냐, 사람에게 하느냐의 차이도 있다</p>
<ul>
<li>디자인 뉴스레터 디독</li>
</ul>
</li>
<li>제품 제작, 디자인 등 클라이언트가 있는 작업</li>
</ul>
</li>
<li>
<p>정보를 쌓는다 (인용이 많이 된 것들은 좋은 글일 확률이 높은 것 같다)</p>
<ul>
<li>
<p>커뮤니케이션에서의 피드백</p>
<ul>
<li>감정의 관리가 필요하다</li>
<li>해결해야 할 문제나 솔루션의 불확실성이 높을 때, 리뷰의 빈도를 올린다</li>
<li><a href="https://ridicorp.com/story/giving-honest-feedback/">https://ridicorp.com/story/giving-honest-feedback/</a></li>
</ul>
</li>
<li>
<p>회사 메뉴얼의 축적</p>
<ul>
<li>개인의 노하우가 회사의 노하우가 될 수 있도록 해야한다</li>
<li>문서가 너무 많아지면 오히려 읽지 않는다</li>
<li>회사에서 누군가 경험한 것이라면 다시 실수가 반복되지 않도록
알려주면 좋은데, 찾지 못하면 소용이 없다</li>
</ul>
</li>
<li>
<p>피드백을 주는 것은 시스템, 사람이지만 받는 것은 사람이다</p>
<ul>
<li>시스템끼리 피드백을 처리할 수도 있지만 최종 피드백은 사람이다</li>
</ul>
</li>
<li>변경 된 사항을 적절한 시점에 알게 되는 것이 필요하다</li>
<li> <a href="https://www.ejce.org/download/download_pdf?pid=jce-20-1-143">피드백 유형과 과제지속의 관계에 대한 연구</a></li>
<li>
<p> microsoft, google에서 피드백을 받는 도구를 만든게 있다</p>
<ul>
<li><a href="https://docs.microsoft.com/ko-kr/windows-insider/developers/tools">https://docs.microsoft.com/ko-kr/windows-insider/developers/tools</a></li>
</ul>
</li>
<li>
<p> 운동에서의 피드백</p>
<ul>
<li><a href="http://kocw.xcache.kinxcdn.com/KOCW/document/2018/seowon/yoonwanyoung201/9.pdf">http://kocw.xcache.kinxcdn.com/KOCW/document/2018/seowon/yoonwanyoung201/9.pdf</a></li>
<li><a href="https://blog.naver.com/choiyuwon/220810803366">운동학습</a></li>
</ul>
</li>
</ul>
</li>
<li>정리한다</li>
<li>검증한다</li>
<li>검색 범위가 넓으니까 지친다. 작게 작게 찾아지도록 해야겠다</li>
<li>피드백이라는게 넓은 의미를 가져서 다양한 영역에서 추상적으로 설명하고,
자기계발서 같은 곳에 뻔한 글들이 많아서 걸러내면서 찾기가 힘들다</li>
<li>피드백이 좋다는 것이나, 방법론 적인 추상적인 이야기가 많다</li>
<li>피드백이 중요하다는 것은 사람들이 알고 있으나, 정보 공유는 많이 하지 않는
영역이라 피드백이라는 단어보다 우회적인 단어를 찾아야한다.</li>
<li>이렇게 한 영역에 대해서 찾는 것을 하다보니 학술 공부하는 것과 비슷한
느낌이다. Roam Research에서 봤던 노트 구조로 작성하면 효과적일까</li>
<li>정보의 출처에서 연결된 정보가 또 나온다</li>
</ol>
<h4 id="feedback-2"><a href="#feedback-2" aria-label="feedback 2 permalink"></a>feedback</h4>
<p>머신러닝에서의 피드백
학기마다 보는 시험도 피드백
하루를 되돌아보는것도 좋은 피드백이다</p>
<p>상용서비스라면 유저들이 활동하는 영역에서 사용 경험이 산발적으로 나올 수 있다
이런 피드백도 잘 수집하면 좋긴 하겠다</p>
<p>it 기기 관련 리뷰는 그런 제품들을 사용하는 사람들이 많이 모인 커뮤니티에 주로 올라온다
물론 예상치 못한 곳에서도 올라온다</p>
<p>원하는 자료가 한 곳에만 올라오는 일은 거의 없다
그랬다면 자료 찾기도 훨씬 수월했겠지</p>
<p>그러면 흩어진 자료를 찾는 방법이 피드백을 찾는법과 비슷하겠다</p>
<p>기계의 고장률이 제로가 되지 않는다
기술이 많이 발전했지만 예상치 못한 문제가 생긴다</p>
<p>모니터링도 카오스 테스트도 예상 못한 지점을 찾으려고 한다
근데 경험을 통해 개선하는 것이 최선인 것 같다</p>
<p>로켓펀치 같은 채용사이트에 새로 등록되는 채용안내문은 많은 양이 아니라서 적당히 모아서 구직자에게 알림을 보내도 방해가 되지 않는다
이 알림의 적당량은 어느정도일까</p>
<h4 id="채널을-맞추고-통신하면-소통이-확실해질-수-있다"><a href="#%EC%B1%84%EB%84%90%EC%9D%84-%EB%A7%9E%EC%B6%94%EA%B3%A0-%ED%86%B5%EC%8B%A0%ED%95%98%EB%A9%B4-%EC%86%8C%ED%86%B5%EC%9D%B4-%ED%99%95%EC%8B%A4%ED%95%B4%EC%A7%88-%EC%88%98-%EC%9E%88%EB%8B%A4" aria-label="채널을 맞추고 통신하면 소통이 확실해질 수 있다 permalink"></a>채널을 맞추고 통신하면 소통이 확실해질 수 있다</h4>
<p>사람과 사람 사이에서 피드백은
강한 피드백 등 안좋은 영향을 조심해야한다</p>
<h4 id="복잡성과-피드백"><a href="#%EB%B3%B5%EC%9E%A1%EC%84%B1%EA%B3%BC-%ED%94%BC%EB%93%9C%EB%B0%B1" aria-label="복잡성과 피드백 permalink"></a>복잡성과 피드백</h4>
<p>각 서비스에서 피드백이 복잡성을 푸는 키다</p>
<p>복잡성은 복잡하지 않은 것들이 많이 동시에 일어날 때 생기는데</p>
<p>각 서비스에서 피드백을 어떻게 주느냐를 잘 설정하면
로그, 데이터 결합, 복잡성 해소가 해결되는 실마리가 될 수 있다</p>
<h4 id="feedback-3"><a href="#feedback-3" aria-label="feedback 3 permalink"></a>feedback</h4>
<p>feedback이 인터럽션이 될 수 있다</p></section><hr></article></div>

shdkej

feedback circuit
http://cad.kyungpook.ac.kr/micro/feedback/feedback-detail.html
review, report, monitoring, response, communication
5F
fact, feeling, finding, future, feedback
running server with auto attachment
auto feedback
running well?
how speed?
any problem?
need more?
program -> feedback -> program -> feedback
program send data to feedback
feedback send data to program
running well:  health check
how speed: test script
any problem: log
need more: receive client voice
선순환
좋은 인재 - 좋은 글 - 많은 독자 - 수익 증가 - 좋은 인재
[[Archive#review of 6 months of german life]]
Software Feedback
알림이 너무 많이 오면 노이즈가 되어 무시하게 된다
변경 사항에 대해 알림을 준다
한 번에 너무 많은 메시지는 피곤하다
같은 에러가 여러 번 오면 따로 표시해준다
시각적으로 한 눈에 알 수 있으면 좋겠다
에러가 발생한 곳이 어딘지 알려주면 좋겠다
배포 후 배포 상황 확인
변경 작업 후 모니터링 페이지로 가서 한 눈에 확인할 수 있으면 1차 확인은 되겠다
행동별 보는 페이지가 있으면 되겠다
grafana는 다양한 메트릭을 보여줄 수 있어서 사용하되, 한눈에 보는 페이지는 따로
관리해야겠다
grafana에서 셋팅하는게 무난해보인다... alert 설정도 좋고, export도 잘되고
Feedback
하루를 돌아보는 작업도 피드백
프로젝트를 회고하는 것도 피드백
슈팅 후 원하는 위치에 갔는지 확인하는 것도 피드백
슈팅을 어떻게 했는지 모르고 감으로만 차면 감만 늘고, 기술적 성장은 안된다
피드백은 잘 진행되고 있는지 평가할 지표가 있으면 명확해진다
계획이 성공되려면 중간 중간 평가할 요소가 있어야겠다
추적할 수 있는 지표
빠른 실패
빠르게 진행해서 빨리 피드백을 받는 것
실패는 항상 찾아오니까 빨리 개선점을 찾으려고 하는 것
근데 무턱대고 하면 안되고, 그렇다고 너무 준비를 오래해도 안된다
어렵다
진행됐다고 치고, 진행이 되면 반드시 실패가 찾아온다. 피드백을 빨리 받고 고쳐서
다음 단계로 나간다.
처음 시작하는 것을 어떻게 할지가 어렵다
말을 적게 하면 좋다는 생각에서
많이 해서 고치는게 좋다는 생각으로 바꼈었는데
무작정 많이하면 안된다는 것도 새삼 깨달았다
많이 하되, 정제된 상태로 많이하는 것이 능력이겠다
+정 반 합 으로 생각을 한번 정리한 후에 말하면 되려나+
+피드백을 받을 수 있는 형태로 정제해서 진행+ 하면 무작정 뱉는 것보다 나아질 수
있겠다
feedback
피드백을 어떻게 줘야 하나...
콘솔에서 아웃풋
메신저로 보내기
슬랙 같은 팀 채널에서 모아서 관리하기
피드백의 핵심은 즉시 알아차리게 하는 것인데
메신저는 약간의 지연이 있을 것 같다 (비동기 통신 방법이긴 하네)
동기 통신으로 보내자면 또 저장을 못하고,
그러면 개발 중에 메신저를 항상 켜놓는다는 전제로 생각해야하나
채널을 하나로만 하면 너무 많은 데이터가 쌓여서 또 곤란하겠네
개인 개발 시에는 메신저로 오게 할까
근데 메신저로 오면 업무의 연속성이 안좋을 것 같다
노트북으로 작업할 때는 노트북에서 바로 볼 수 있어야겠는데
search
시작점을 찾는다 (내부에 들어가기 전에 내 생각을 먼저 확인한다)
피드백을 빨리 받아서 고치는 방법을 알고 싶다
피드백을 효율적으로 받는 방법을 알고 싶다
과학적으로 행동에 대한 인지를 하는 방법을 알고 싶다
다른 영역이 응답을 빨리하는 것에 대해 모은 지식을 알고 싶다
어떤 방식으로, 어떤 주기로, 어떤 내용을 주면 좋을지 알고 싶다
단어를 모은다 (측정 가능한 기준을 세워서 범위를 잡는다)
피드백
빠른 피드백 주는 법
피드백 실험
모니터링 서비스의 피드백
운동에서의 피드백
기계 시스템에서의 피드백
빠른 피드백
개발에서 빠른 실패, 애자일
온라인스토어에서 고객의 불만 접수 및 응대
연예인이나 컨텐츠 제작 후의 시청자 반응에 대한 응대
공인이 불미스런 사건을 일으켰을 때의 조치
커뮤니케이션에서의 피드백
회사 메뉴얼의 축적
회고
fail fast
피드백의 종류가 다양하다. 정량적 피드백, 정성적 피드백
기계에게 하느냐, 사람에게 하느냐의 차이도 있다
디자인 뉴스레터 디독
제품 제작, 디자인 등 클라이언트가 있는 작업
정보를 쌓는다 (인용이 많이 된 것들은 좋은 글일 확률이 높은 것 같다)
커뮤니케이션에서의 피드백
감정의 관리가 필요하다
해결해야 할 문제나 솔루션의 불확실성이 높을 때, 리뷰의 빈도를 올린다
https://ridicorp.com/story/giving-honest-feedback/
회사 메뉴얼의 축적
개인의 노하우가 회사의 노하우가 될 수 있도록 해야한다
문서가 너무 많아지면 오히려 읽지 않는다
회사에서 누군가 경험한 것이라면 다시 실수가 반복되지 않도록
알려주면 좋은데, 찾지 못하면 소용이 없다
피드백을 주는 것은 시스템, 사람이지만 받는 것은 사람이다
시스템끼리 피드백을 처리할 수도 있지만 최종 피드백은 사람이다
변경 된 사항을 적절한 시점에 알게 되는 것이 필요하다
 피드백 유형과 과제지속의 관계에 대한 연구
 microsoft, google에서 피드백을 받는 도구를 만든게 있다
https://docs.microsoft.com/ko-kr/windows-insider/developers/tools
 운동에서의 피드백
http://kocw.xcache.kinxcdn.com/KOCW/document/2018/seowon/yoonwanyoung201/9.pdf
운동학습
정리한다
검증한다
검색 범위가 넓으니까 지친다. 작게 작게 찾아지도록 해야겠다
피드백이라는게 넓은 의미를 가져서 다양한 영역에서 추상적으로 설명하고,
자기계발서 같은 곳에 뻔한 글들이 많아서 걸러내면서 찾기가 힘들다
피드백이 좋다는 것이나, 방법론 적인 추상적인 이야기가 많다
피드백이 중요하다는 것은 사람들이 알고 있으나, 정보 공유는 많이 하지 않는
영역이라 피드백이라는 단어보다 우회적인 단어를 찾아야한다.
이렇게 한 영역에 대해서 찾는 것을 하다보니 학술 공부하는 것과 비슷한
느낌이다. Roam Research에서 봤던 노트 구조로 작성하면 효과적일까
정보의 출처에서 연결된 정보가 또 나온다
feedback
머신러닝에서의 피드백
학기마다 보는 시험도 피드백
하루를 되돌아보는것도 좋은 피드백이다
상용서비스라면 유저들이 활동하는 영역에서 사용 경험이 산발적으로 나올 수 있다
이런 피드백도 잘 수집하면 좋긴 하겠다
it 기기 관련 리뷰는 그런 제품들을 사용하는 사람들이 많이 모인 커뮤니티에 주로 올라온다
물론 예상치 못한 곳에서도 올라온다
원하는 자료가 한 곳에만 올라오는 일은 거의 없다
그랬다면 자료 찾기도 훨씬 수월했겠지
그러면 흩어진 자료를 찾는 방법이 피드백을 찾는법과 비슷하겠다
기계의 고장률이 제로가 되지 않는다
기술이 많이 발전했지만 예상치 못한 문제가 생긴다
모니터링도 카오스 테스트도 예상 못한 지점을 찾으려고 한다
근데 경험을 통해 개선하는 것이 최선인 것 같다
로켓펀치 같은 채용사이트에 새로 등록되는 채용안내문은 많은 양이 아니라서 적당히 모아서 구직자에게 알림을 보내도 방해가 되지 않는다
이 알림의 적당량은 어느정도일까
채널을 맞추고 통신하면 소통이 확실해질 수 있다
사람과 사람 사이에서 피드백은
강한 피드백 등 안좋은 영향을 조심해야한다
복잡성과 피드백
각 서비스에서 피드백이 복잡성을 푸는 키다
복잡성은 복잡하지 않은 것들이 많이 동시에 일어날 때 생기는데
각 서비스에서 피드백을 어떻게 주느냐를 잘 설정하면
로그, 데이터 결합, 복잡성 해소가 해결되는 실마리가 될 수 있다
feedback
feedback이 인터럽션이 될 수 있다

Feedback

댓글