프로그래머 팀 관리: 그들에게 적절한 동기를 부여하는 방법과 방법은 무엇입니까? 두 번째 부분

Epigraph :
남편은 더러운 아이들을 바라보며 아내에게 말합니다. 글쎄, 이걸 씻어야할까요, 아니면 새 아이를 낳을까요?

아래 컷에는 프로그래머에게 동기를 부여하는 특징에 대해 우리 팀 리더와 RAS 제품 개발 이사 Igor Marnat가 쓴 기사의 두 번째 부분이 있습니다. 기사의 첫 번째 부분은 여기에서 확인할 수 있습니다. habr.com/ru/company/parallels/blog/452598

기사의 첫 번째 부분에서 나는 Maslow 피라미드의 두 가지 하위 수준인 생리적 욕구, 안전, 편안함 및 불변성에 대한 욕구를 다루었고 다음 세 번째 수준인 다음으로 넘어갔습니다.

III - 소속감과 사랑의 욕구

이탈리아 마피아가 '코사 노스트라'라고 불리는 건 알고 있었는데, '코사 노스트라'를 어떻게 번역했는지 알고 정말 감동받았어요. "Cosa Nostra"는 이탈리아어로 "우리의 사업"을 의미합니다. 이름 선택은 동기 부여 측면에서 매우 성공적입니다(직업은 제쳐두고 이 경우에는 동기 부여에만 관심이 있습니다). 사람은 대개 팀의 일원이 되어 크고 일반적인 사업을 수행하기를 원합니다.

육군, 해군 및 대규모 준군사 조직에서는 소속감과 사랑의 욕구를 충족시키는 것이 매우 중요합니다. 그리고 보시다시피 마피아에서. 공통점이 거의 없는 사람들, 처음에는 같은 생각을 가진 사람들로 구성된 팀을 구성하지 않은 사람들, (자발적이 아닌) 징집을 통해 모인 사람들, 서로 다른 교육 수준, 서로 다른 개인적 가치관을 가진 사람들을 강요해야 하기 때문에 이것은 이해할 수 있습니다. , 문자 그대로 치명적인 위험을 무릅쓰고 공통의 목적을 위해 그들의 삶을 바치려면 , 당신의 삶을 전우에게 맡기십시오.

이것은 매우 강력한 동기입니다. 대부분의 사람들에게 자신이 더 큰 무언가에 속해 있다고 느끼고 자신이 가족, 국가, 팀의 일원임을 아는 것이 매우 중요합니다. 군대에서는 군복, 다양한 의식, 퍼레이드, 행진, 깃발 등이 이러한 목적을 달성합니다. 거의 동일한 요소가 모든 팀에 중요합니다. 상징, 기업 브랜드 및 기업 색상, 도구 및 기념품이 중요합니다.

중요한 사건은 연관될 수 있는 가시적인 구체화를 갖는 것이 중요합니다. 요즘에는 회사가 자체 상품, 재킷, 티셔츠 등을 보유하는 것이 오히려 표준입니다. 하지만 회사 내 팀을 강조하는 것도 중요합니다. 우리는 종종 출시 결과에 따라 티셔츠를 출시하고, 이는 출시에 관련된 모든 사람들에게 제공됩니다. 전체 팀과 함께하는 일부 이벤트, 공동 축하 또는 활동은 동기 부여의 또 다른 중요한 요소입니다.

외부 속성 외에도 몇 가지 다른 요소가 팀에 대한 소속감에 영향을 미칩니다.
첫째, 모두가 이해하고 그 중요성에 대한 평가를 공유하는 공통 목표의 존재입니다. 프로그래머는 대개 자신이 멋진 일을 하고 있다는 사실, 그리고 팀으로서 함께 이 멋진 일을 하고 있다는 사실을 이해하고 싶어합니다.
둘째, 팀에는 전체 팀이 참여하고 해당 팀에만 속해 있는 커뮤니케이션 공간이 있어야 합니다(예: 메신저 채팅, 주기적인 팀 동기화). 업무 문제, 비공식적 의사소통, 때로는 외부 이벤트에 대한 토론, 가벼운 오프탑 외에도 이 모든 것이 공동체 의식과 팀감을 형성합니다.
셋째, 팀 내에서 우수한 엔지니어링 관행을 도입하고 회사에서 수용하는 표준과 비교하여 표준을 높이려는 열망을 강조하고 싶습니다. 먼저 팀에서, 그리고 회사 전체에서 업계에서 인정되는 최고의 접근 방식을 구현하면 팀이 어떤 방식으로든 다른 사람들보다 앞서 있다고 느낄 수 있는 기회를 얻고 앞서 나가며 소속감을 갖게 됩니다. 멋진 팀에.

소속감은 팀의 기획 및 관리 참여 여부에도 영향을 받습니다. 팀 구성원이 프로젝트 목표, 작업 계획, 팀 표준 및 엔지니어링 관행을 논의하고 신입 사원을 인터뷰하는 데 참여하면 참여 의식, 공유 소유권 및 작업에 대한 영향력이 커집니다. 사람들은 실제로는 일치하더라도 다른 사람이 제안한 결정보다 스스로 내리고 발언한 결정을 훨씬 더 기꺼이 수행합니다.

생일, 기념일, 동료의 삶에서 중요한 행사 - 공동 피자, 팀의 작은 선물은 따뜻한 참여와 감사의 느낌을 줍니다. 일부 회사에서는 회사에서 5년, 10년, 15년 동안 근무한 것에 대해 작은 기념 표시를 제공하는 것이 관례입니다. 한편으로는 이것이 새로운 성취에 대한 동기를 부여한다고 생각하지 않습니다. 그러나 분명히 거의 모든 사람이 그에 대해 잊지 않았다는 사실에 기뻐할 것입니다. 이는 사실의 존재가 동기를 부여하기보다는 부재가 동기를 저하시키는 경우 중 하나입니다. LinkedIn이 아침에 귀하에게 알림을 보내고 직장에서 10주년을 축하했다면 상당히 부끄러운 일이 될 수 있지만 회사의 동료 중 단 한 명도 귀하를 축하하거나 기억하지 못했습니다.

물론 중요한 점은 팀 구성의 변화이다. 팀에서 누군가의 도착 또는 이탈이 사전에 발표되더라도(예: 회사나 팀 뉴스레터 또는 팀 회의에서) 이는 누구에게도 새로운 성과를 달성하도록 특별히 동기를 부여하지 않는다는 것이 분명합니다. 하지만 어느 화창한 날 옆에 새로운 사람이 보이거나 예전 사람이 보이지 않는다면 그것은 놀라운 일이 될 수 있고, 떠나면 완전히 불쾌한 일이 될 수 있습니다. 사람이 조용히 사라져서는 안 됩니다. 특히 분산된 팀에서는 더욱 그렇습니다. 특히 귀하의 업무가 갑자기 나타나서 사라진 다른 사무실의 동료에게 달려 있는 경우에는 더욱 그렇습니다. 그러한 순간은 확실히 팀에 미리 미리 알릴 가치가 있습니다.

영어로 다음과 같은 중요한 요소입니다. 소유권 (“소유”의 문자적 번역은 그 의미를 완전히 반영하지 않습니다). 이것은 소유권의 느낌이 아니라 오히려 프로젝트에 대한 책임감, 즉 자신을 제품과 감정적으로 연관시키고 제품을 자신과 연관시킬 때 느끼는 느낌입니다. 이는 영화 '풀 메탈 재킷'에 나오는 해병대의 기도와 대략 일치합니다.이것은 내 소총입니다. 그런 소총이 많지만 이것은 내 것입니다. 내 소총은 나의 가장 친한 친구입니다. 그녀는 내 인생이다. 나는 내 인생을 소유하는 것과 같은 방식으로 그것을 소유하는 법을 배워야 합니다. 내가 없으면 내 소총은 쓸모가 없습니다. 소총이 없으면 나는 쓸모가 없습니다. 소총을 똑바로 쏴야 해요. 나를 죽이려는 적보다 더 정확하게 사격해야 한다. 그가 나를 쏘기 전에 내가 그를 쏴야 해요. 그렇게 놔두세요…”.

사람이 오랫동안 제품 작업을 하고, 제품의 생성과 개발에 대해 전적인 책임을 지고, 작동하는 것이 "무"에서 어떻게 발생하는지, 사람들이 그것을 사용하는 방법을 볼 수 있는 기회를 갖게 되면 이러한 강력한 느낌이 생깁니다. 하나의 프로젝트에서 오랫동안 함께 작업하는 제품 팀은 일반적으로 짧은 기간 동안 조립되어 전체에 대한 전적인 책임 없이 한 프로젝트에서 다른 프로젝트로 전환하면서 조립 라인 모드로 작업하는 팀보다 더 의욕적이고 응집력이 높습니다. 제품, 처음부터 끝까지.

IV. 인정의 필요성

친절한 말 한마디도 고양이를 기쁘게 합니다. 모든 사람은 자신이 수행한 작업의 중요성을 인식하고 이에 대한 긍정적인 평가를 통해 동기를 부여받습니다. 프로그래머와 대화하고 정기적인 피드백을 제공하며 잘 수행된 작업을 축하해 주세요. 대규모의 분산된 팀이 있는 경우 정기적인 회의(일대일이라고 함)가 이에 적합합니다. 팀이 매우 작고 로컬에서 함께 작업하는 경우 이 기회는 일반적으로 달력에 있는 특별 회의 없이 제공됩니다(정기적인 회의임에도 불구하고). 여전히 필요하므로 덜 자주 하면 됩니다.) 이 주제는 Manager-tools.com의 관리자를 위한 팟캐스트에서 잘 다루고 있습니다.

그러나 문화적 차이를 염두에 두는 것이 좋습니다. 미국 동료들에게 친숙한 일부 접근 방식은 항상 러시아 접근 방식에서 작동하지 않습니다. 서방 국가 팀의 일상 커뮤니케이션에서 허용되는 공손함의 수준은 처음에는 러시아 프로그래머에게 과도한 것처럼 보입니다. 러시아 동료들의 일부 솔직함 특징은 다른 나라 동료들에게는 무례함으로 인식될 수 있습니다. 이는 다민족 팀의 의사소통에 매우 중요하며 이 주제에 대해 많은 글이 작성되었으므로 해당 팀의 관리자는 이것을 기억해야 합니다.

프로그래머가 스프린트 중에 개발된 기능을 보여주는 기능 데모는 이러한 요구를 실현하는 좋은 방법입니다. 이는 팀 간의 커뮤니케이션 채널을 정리하고 제품 관리자와 테스터에게 새로운 기능을 소개할 수 있는 좋은 기회일 뿐만 아니라 개발자가 작업 결과를 보여주고 자신의 저작자를 표시할 수 있는 좋은 기회이기도 합니다. 물론 대중 연설 능력도 연마하세요. 이는 결코 해롭지 않습니다.

특별히 뛰어난 동료들의 공헌을 기념하기 위해 공동팀 회식에서 증서, 추모패(친절한 한마디라도)로 축하해 주시면 좋을 것 같습니다. 사람들은 일반적으로 그러한 증명서와 기념 표지판을 매우 소중히 여기며 이사할 때 가지고 다니고 일반적으로 가능한 모든 방법으로 관리합니다.

팀 작업에 대한 보다 중요하고 장기적인 기여, 축적된 경험 및 전문 지식을 표시하기 위해 등급 시스템이 자주 사용됩니다. 종속을 보장하는 것도 이러한 목적에 부합합니다). 종종 젊은 개발자들은 어깨끈에 새로운 스타를 추가하기 위해 두 배 더 열심히 일합니다(예: 주니어 개발자에서 정규 개발자로 이동 등).

사람들의 기대치를 아는 것이 중요합니다. 일부는 높은 등급, 예를 들어 건축가라고 불릴 수 있는 기회에 동기를 부여받을 가능성이 더 높은 반면, 다른 일부는 등급과 직함에 무관심하며 급여 인상을 회사의 인정의 표시로 간주합니다. . 사람들과 소통하여 그들이 원하는 것과 기대하는 바가 무엇인지 이해하십시오.

새로운 작업 영역에 더 많은 자유를 부여하거나 참여함으로써 팀의 높은 수준의 신뢰를 인정받을 수 있습니다. 예를 들어, 특정 경험을 얻고 특정 결과를 얻은 후 프로그래머는 사양에 따라 자신의 기능을 구현하는 것 외에도 새로운 아키텍처에 대한 작업을 수행할 수 있습니다. 또는 테스트 자동화, 최고의 엔지니어링 사례 구현, 릴리스 관리 지원, 컨퍼런스 연설 등 개발과 직접적인 관련이 없을 수 있는 새로운 영역에 참여하세요.

V. 인지와 자기실현의 필요성.

많은 프로그래머는 인생의 다양한 단계에서 다양한 유형의 프로그래밍 활동에 집중합니다. 어떤 사람들은 기계 학습을 하고, 새로운 데이터 모델을 개발하고, 업무에 필요한 많은 과학 문헌을 읽고, 처음부터 새로운 것을 창조하는 것을 좋아합니다. 또 다른 방법은 기존 애플리케이션 디버깅 및 지원에 더 가깝습니다. 기존 코드, 연구 로그, 스택 추적 및 네트워크 보안 문자를 며칠, 몇 주 동안 깊이 파고들어 새로운 코드를 거의 작성하지 않아도 됩니다.

두 프로세스 모두 엄청난 지적 노력이 필요하지만 실제 결과는 다릅니다. 프로그래머들은 기존 솔루션을 지원하기를 꺼리고 오히려 새로운 솔루션을 개발하려는 동기를 갖고 있는 것으로 알려져 있습니다. 여기에는 지혜가 있습니다. 반면, 제가 함께 일한 팀 중 가장 의욕이 넘치고 단결된 팀은 기존 제품을 지원하고 지원 팀이 연락한 후 버그를 찾아 수정하는 데 전념했습니다. 그 사람들은 말 그대로 이 일을 위해 살았으며 토요일과 일요일에 외출할 준비가 되어 있었습니다. 우리는 31월 1일 저녁이나 XNUMX월 XNUMX일 오후에 또 다른 긴급하고 복잡한 문제를 열심히 처리한 적이 있습니다.

몇 가지 요인이 이러한 높은 동기에 영향을 미쳤습니다. 첫째, 업계에서 큰 이름을 가진 회사였고 팀이 그 회사와 연관되어 있었습니다(“제휴의 필요성” 참조). 둘째, 그들은 최후의 개척자였고, 그 뒤에는 아무도 없었고, 그 당시에는 제품팀도 없었습니다. 그들과 고객 사이에는 두 가지 수준의 지원이 있었지만 문제가 그들에게 도달하면 후퇴할 곳이 없었고 그들 뒤에는 아무도 없었으며 회사 전체가 그들 위에 있었습니다(XNUMX명의 젊은 프로그래머). 셋째, 이 대기업은 매우 큰 고객(국가 정부, 자동차 및 항공 분야 등)을 보유하고 있으며 여러 국가에 대규모 설치 시설을 보유하고 있습니다. 결과적으로 항상 복잡하고 흥미로운 문제, 간단한 문제는 이전 레벨의 지원으로 해결되었습니다. 넷째, 팀의 동기는 상호 작용하는 지원 팀의 전문적인 수준에 크게 영향을 받았으며(매우 경험이 많고 기술적으로 유능한 엔지니어가 있었습니다), 우리는 그들이 준비한 데이터의 품질과 수행한 분석에 대해 항상 확신했습니다. , 등. 다섯째, 이것이 가장 중요한 점이라고 생각합니다. 팀은 매우 어렸고 모든 선수는 경력 초기에있었습니다. 그들은 크고 복잡한 제품을 연구하고, 새로운 환경에서 처음 접했던 심각한 문제를 해결하는 데 관심이 있었고, 주변 팀, 문제, 고객의 수준을 전문적으로 맞추려고 노력했습니다. 그 프로젝트는 훌륭한 학교로 판명되었고, 모두가 나중에 회사에서 좋은 경력을 쌓고 기술 리더와 고위 관리자가 되었습니다. 그 중 한 명은 현재 Amazon Web Services의 기술 관리자이고, 다른 한 명은 결국 Google로 옮겼습니다. 그들 중 아직도 이 프로젝트를 따뜻하게 기억하고 있습니다.

만약 이 팀이 15~20년의 경험을 가진 프로그래머들로 구성되었다면 동기가 달라졌을 것입니다. 물론 나이와 경험이 100% 결정 요인은 아니며 모두 동기의 구조에 따라 달라집니다. 특히 이번 사례에서는 젊은 프로그래머들의 지식과 성장에 대한 열망이 탁월한 결과를 낳았다.

일반적으로 우리가 이미 여러 번 언급했듯이 프로그래머의 기대치를 알아야 하고, 프로그래머 중 누가 자신의 활동 분야를 확장하거나 변경하고 싶어하는지 이해하고 이러한 기대치를 고려해야 합니다.

Maslow의 피라미드 너머: 결과 가시성, 게임화 및 경쟁, 헛소리 없음

프로그래머의 동기와 관련하여 확실히 언급해야 할 세 가지 중요한 사항이 있지만 이를 Maslow의 요구 모델에 적용하는 것은 너무 인위적입니다.

첫 번째는 결과의 가시성과 근접성입니다.

소프트웨어 개발은 ​​일반적으로 마라톤입니다. R&D 노력의 결과는 몇 달, 때로는 몇 년 후에 가시화됩니다. 지평선 너머 멀리 있는 목표를 향해 가는 것은 어렵고, 일의 양은 무섭고, 목표는 멀리 있고, 명확하지도 않고, 보이지도 않으며, “밤은 어둡고 공포로 가득 차 있다.” 도로를 여러 부분으로 나누고 눈에 보이고 도달 가능하며 윤곽이 명확하고 우리에게서 멀지 않은 가장 가까운 나무로 경로를 만들고이 가까운 목표로 이동하는 것이 좋습니다. 우리는 며칠 또는 몇 주 동안 노력하고 결과를 얻고 평가한 다음 계속 진행하고 싶습니다. 따라서 작업을 작은 부분으로 나누는 것이 좋습니다(애자일 모드의 스프린트가 이 목적에 적합합니다). 우리는 작업의 일부를 완료했습니다. 기록하고, 숨을 내쉬고, 토론하고, 유죄를 처벌하고, 무죄한 사람에게 보상했습니다. 다음 주기를 시작할 수 있습니다.

이러한 동기는 플레이어가 컴퓨터 게임을 완료할 때 경험하는 것과 어느 정도 유사합니다. 플레이어는 각 레벨을 완료할 때 주기적으로 메달, 포인트, 보너스를 받습니다. 이를 "도파민 동기"라고 부를 수 있습니다.

동시에 결과의 가시성은 말 그대로 중요합니다. 목록에서 닫힌 피처는 녹색으로 변해야 합니다. 코드를 작성하고, 테스트하고, 릴리스했지만 프로그래머가 볼 수 있는 시각적 상태에 변화가 없다면 프로그래머는 불완전하다고 느낄 것이며 완성된 느낌도 없을 것입니다. 버전 제어 시스템의 팀 중 하나에서 각 패치는 세 가지 연속 단계를 거쳤습니다. 즉, 빌드가 조립되고 테스트가 통과되었으며, 패치가 코드 검토를 통과하고, 패치가 병합되었습니다. 각 단계는 녹색 체크 표시 또는 빨간색 십자가로 시각적으로 표시되었습니다. 개발자 중 한 명이 코드 검토가 너무 오래 걸린다고 불평하자 동료들은 속도를 높여야 했고 패치는 며칠 동안 중단되었습니다. 나는 이것이 그에게 실제로 어떤 변화를 가져오는지 물었습니다. 결국 코드가 작성되고 빌드가 어셈블되고 테스트가 통과되면 주석이 없으면 전송된 패치에 주의를 기울일 필요가 없습니다. 동료들이 직접 검토하고 승인합니다(댓글이 없는 경우). 그는 “이고르, 가능한 한 빨리 녹색 진드기 세 개를 받고 싶습니다.”라고 대답했습니다.

두 번째 포인트는 게이미피케이션과 경쟁이다.

제품 중 하나를 개발할 때 우리 엔지니어링 팀은 오픈 소스 제품 중 하나의 커뮤니티에서 눈에 띄는 위치를 차지하고 상위 3위 안에 들겠다는 목표를 세웠습니다. 그 당시에는 커뮤니티에서 누군가의 가시성을 평가할 객관적인 방법이 없었습니다. 각 대규모 참여 기업은 자신이 최고의 기여자라고 주장(및 주기적으로 주장)할 수 있었지만 참가자의 기여도를 비교할 실제 방법은 없었습니다. 시간에 따른 역학을 평가합니다. 따라서 일부 앵무새에서 측정할 수 있는 팀의 목표를 설정하거나 달성 정도를 평가할 수 있는 방법이 없었습니다. 이 문제를 해결하기 위해 우리 팀은 기업과 개인 기여자의 기여도를 측정하고 시각화하는 도구를 개발했습니다. www.stackalytics.com. 동기 부여의 관점에서 볼 때 그것은 단지 폭탄에 불과한 것으로 판명되었습니다. 자신의 진행 상황과 동료 및 경쟁사의 진행 상황을 지속적으로 모니터링하는 것은 엔지니어와 팀만이 아니었습니다. 우리 회사의 최고 경영진과 모든 주요 경쟁사들도 stackalytics로 하루를 시작했습니다. 모든 것이 매우 투명하고 시각적으로 바뀌었고 모든 사람이 자신의 진행 상황을 주의 깊게 모니터링하고 동료와 비교할 수 있었습니다. 엔지니어, 관리자, 팀이 목표를 설정하는 것이 편리하고 쉬워졌습니다.

정량적 지표 시스템을 구현할 때 발생하는 중요한 점은 시스템을 구현하자마자 시스템이 자동으로 이러한 정량적 지표 달성에 우선순위를 부여하여 정성적 지표를 손상시키려고 노력한다는 것입니다. 예를 들어, 완료된 코드 검토 수가 지표 중 하나로 사용됩니다. 분명히 코드 검토는 다양한 방법으로 수행될 수 있습니다. 테스트 확인, 벤치에서 실행, 문서 확인을 통해 복잡한 패치를 철저하게 검토하고 확인하는 데 몇 시간을 소비할 수 있으며 카르마에서 추가로 1개의 검토를 받을 수 있습니다. 몇 분 안에 수십 개의 패치를 맹목적으로 클릭하고 각 패치에 +1을 부여하고 카르마에서 +XNUMX을 얻습니다. 엔지니어들이 패치를 너무 빨리 클릭해서 CI 시스템의 자동 패치에 +XNUMX을 주는 우스꽝스러운 경우도 있었습니다. 나중에 농담처럼 "가자, 젠킨스." 커밋의 경우에는 코드 서식 도구로 코드를 살펴보고, 댓글을 편집하고, 마침표를 쉼표로 바꿔서 업보를 올리는 분들도 많았습니다. 이를 처리하는 것은 매우 간단합니다. 우리는 상식을 사용하고 정량적 측정 항목 외에도 필수적이고 질적 측정 항목도 사용합니다. 팀 작업 결과의 활용 정도, 외부 기여자 수, 테스트 범위 수준, 모듈 및 전체 제품의 안정성, 규모 및 성능 테스트 결과, 핵심 검토자를 수용한 엔지니어 수 스트랩, 프로젝트가 핵심 프로젝트 커뮤니티에 승인되었다는 사실, 엔지니어링 프로세스의 다양한 단계 기준 준수 등 이러한 모든 요소와 기타 여러 요소를 간단한 정량적 측정 기준과 함께 평가해야 합니다.

그리고 마지막으로 세 번째 요점은 헛소리가 아닙니다.

개발자는 매우 똑똑한 사람이고 자신의 업무 분야에서 매우 논리적입니다. 그들은 길고 복잡한 논리적 체인을 구축하는 데 하루 8~10시간을 소비하므로 즉석에서 취약점을 찾아냅니다. 무언가를 할 때, 그들은 다른 사람들과 마찬가지로 왜 그 일을 하는지, 무엇이 더 좋게 변할지 이해하고 싶어합니다. 팀을 위해 설정한 목표가 정직하고 현실적이라는 것이 매우 중요합니다. 나쁜 아이디어를 프로그래밍 팀에 팔려고 하는 것은 나쁜 생각입니다. 자신이 믿지 않거나 극단적인 경우 동의하지 않고 헌신하는 내부 상태가 없으면 아이디어는 나쁜 것입니다(동의하지는 않지만 할게요). 우리는 한때 회사에서 동기 부여 시스템을 구현했는데, 그 요소 중 하나는 피드백을 제공하기 위한 전자 시스템이었습니다. 그들은 많은 돈을 투자하고 훈련을 위해 사람들을 미국으로 데려 갔으며 일반적으로 최대한 투자했습니다. 한번은 훈련 후 대화에서 관리자 중 한 명이 부하 직원에게 이렇게 말했습니다. “아이디어는 나쁘지 않고 효과가 있을 것 같습니다. 나는 당신에게 전자 피드백을 직접 제공하지는 않지만 당신은 그것을 당신의 사람들에게 주고 그들에게 요구합니다.” 그게 다입니다. 더 이상 구현할 수 없습니다. 물론 그 아이디어는 아무것도 끝나지 않았습니다.

출처 : habr.com