Donghee

프로그래밍팀은 요구사항에 의해 구성된다. 일에 관련되는 능력만 관련되지 않고, 일이 가능한지? 시간에 어떠한 영향을 받는지도 중요하다. Schedule is similary limiting. 최적, 최고의 상황에서 Schedule이 최저가 가능하다. 최적의, 최고의 상황

• Best worker
• 오랫동안 계획
• Mamber 개인문제가 일어나지 않는다.
• 그외 예상하지 않은 문제가 일어나지 않는다.

임산부9명이 있다구 1달만에 애를 낳지않는다.(팀에서 사람과 시간이 문제가 반비례하지 않는다)

• 1명이 8달 = 4명이 3달 = 9명이 2달

팀에서 가장 않좋은 상황은 많은 trainees와 압박과 절제없을때이다 → 요즘 대부분 이렇다(trainee라는 개념은 없어졌지만)

• trainee 많은 것보다 경험이 있는 greenprogrammer가 있는게 더 낫다.

팀조직은 target system과 팀구성(composition of team)이 중요한 요소이다. program structure에 의해 팀이 구성

5-1 : 경험있는 프로그래머와 trainee 들 MAIN PROGRAM은 경험있는 프로그래머 작은것은 trainee 5-2 : 비슷한 실력의 프로그래머, 일의 결정이 평등함, 2번은 팀웍에 좀더 시간을 할애하고 재능이 있어야 한다.

팀구조는 팀원이 어떠한 철학을 가지고 있는가에따라 달라진다 5-1 egoless programming을 가진다면, 덜 계층적이어진다. 5-2 egoless programming이 아니라면, 덜 평등적일것이다. 팀원의 상태는 서로에대한 지각에 크게 영향을 받는다.(ex 실력? ..)

Man-month 이야기(MMM 2챔터) 5-1 MMM sugical team!

팀에서 자기가 많은것이 중요하지 못한거라는 믿은은 팀노력에 해가 될 수 있다. 여러상황이 쉽게 편하므로 egoless programming이 중요하다. 사회심리학자들이 구성원들이 그룹의 목표를 공유하는것이 그룹의 perfomance에 영향을 주는것이라 했다.

5-3 시스템의 구성 : 처음에 비교적 비슷한 구성원으로 팀이 구성되어서 commoninterface를 제공하는 디자인이 되었다. Ibm 704(5-3구성) →(conversion) ibm 709 : 문제가 발생되어서 시간의 압박으로 709에서 704(호환)제거(?). 구성원들이 위에대한 합의를 하지 못해서 발생한 문제였다. 그럼 해결?

목적이 이해가 가도록 목표설정을 구성원과 같이 한다.
구성원들이 그룹목표에 참가하도록 권한을 준다. 

가장 위험한 메니저는 팀원이 문제보기도 전에 순위를 정하고 bit나 byte를 정하는 사람이다. 열정을 죽이고 팀원들을 단지 loader로만 생각한다. 프로그래머는 무엇보다 왜하는지를 알고 싶어한다. 시스템을 잘모르면 두려움을 준다. 시스템의 변화를 주어서, 왜 그것이 구성원에게 필요한지 알게 한다. 시스템목적이 명확해도 문제가 발생한다 예를들면 생산과 교육, 같은 그외의 충돌 하나의 명확한 목적이 있으면 좋으나 현실에서는 그렇지 못하다. 팀내에서 의견이 다 전달될수 없어서 일이 중복되기도 한다. 보통 이러한 중복으로 팀이 고비를 가진다. Guliver - 무시되어서 의견이 전달 되지 않음

egoless programming의 자세. 보통 프로그래머들이 자기 생각을 가지지 않는 프로그래밍이라 생각하는데, 어떠한것이 더 자기에게 이로운 자세일까? 동의에의한교육 세밀한 작업들은 무엇을 왜하난지 생각하는데 방해한다.

프로그래밍에서 리더는 보통 너그러움이 있어야한다.

군대 처럼 지도적으로 이끌게 되면, 일하는게 시간때우기처럼 될 수 있다. 비슷한사례 : 볼펜이 떨어져서 일을 못해요~. 참으로 필요한것은 포로그래밍 리더쉽을 존경하는 환경에서, 프로그래머의 상습적인 단점을 좋은환경으로 이끌어주는 하는 것이다.

• 물질적보상, 기회제공.
• 일에 재밌어하고 도전하록 한다.
• 큰조직에서 보통의 환경(종업원이 이익없고, 일환경과 조직상태가 비슷하도록)
• 리더의 경쟁력?(the competence of supervisors and leaders)

여러 다른 불만 보다 리더에 대한 불만은 보통 가지고 있다. 프로그래머에서 리더쉽은 프로그래머들에게 얼마나 영향을 줄 수 있는 능력이다. non-programmer가 프로그래머의로서 부적합. 경험에서 나오는 프로그머 리더 은 팀에 존경을 받지만, 그렇지 못한다면 조롱을 받을 수 있다. Arnold C. 그가 알고리즘을 이야기 했는데 아무도 그걸 이해하지 못했다. 그후 개인적인 자기 이야기를 했더니 나중에 mamber들이 그 알고리즘에 눈물을 흘린 일화

민주적인그룹(democratic)에서의 리더쉽

• 리더 개인으로 정의되는게 아닌 mamber와 manber사이의 능력과 아이디어의 이해에서 온다.
• 리더쉽은 외부가 아닌 팀내부에서 발현된다. 그래서 서로배우고 가르치는게 필요하다.
• 민주적 리더쉽은 위기에 놀라운 적응력을 가진다. 그러나 single leader가 결정이 옳 을때 더 빠르고 결정적일때가 있다.

어떤프로그래밍팀도 민주적이지 않는다.

• right man은 팀에 없다.
• 리더의 개인성은 적적한 사람의 선택에 의해 나타난다.(?)
• 밖에 보여질때(경력) 리더가 편견에 싸여 보여진다.

이런 경력은 외부에선 잘알 수 없고, 팀내부 사람이 안다

''리더는 자기보다 높은 관리자에게 의해(계약) 경력이 결정 되어진다''

그래서 지명되어진 리더의 운명을 극복하고 과 자기가 권한을 가진 리더로 가기위해 팀리더는 다음사항을 중시해야한다.

• 메니저가 진짜 원하는것
• 팀이 할 수 하기 쉬운 결과 얻기.

지명된 팀리더라면 자기팀이 할 수 없는일에 저항해야한다.

• 환경이 새로이 변하고(기계발전, people,…)는것을 매니저에게 인지시키고, 자기팀이 할 수 있는 내에서 자기뜻을 굽히지 않는다.
• 돈을 더 준다고 해도 자기의지를 굽히면 안된다.(돈을 더줘도 안된다는건 리더가 안다)
• 대부분 특별한보수의 계약은 리더가 성공하지만 그러나 그일을 하는데 리더가 결정하지는 않는다.

Harold M

자기팀을 위해 못하는일을 거절. 매니저에게 많이 까불엇지만 결국 회사에서 잘리진 않았다.

One of the paradoxed of leadership : only the leader who is ready to step down has a real chance of success.

방식이 공무원 일처리 방식과 아주비슷. 학교교육에서의 문제(ex 참고서 없어서 공부 못했어요~) 지금 프로그래머에게 존경받는 리더라면 좋은 리더이다. 지명되는 팀 리더의 고뇌!

팀은 새로운사람의 영입, 목적의 변화, 일의 구성작업하고 , 새로운 목적 생김으로써 거의 마쳐진다. 이러한 팀은 수많은 위기를 가져서 소설을 쓸정도로 재미있는 것 이다 일활동에 일중심의 디자인(목적을위한 작업중심)과 유지중심의디자인(문제가 있을때해결중심)이 유용하다. 이에따라 두가지 리더를 고른다. 일중심디자인의 리더 유지중심디자인의 리더. 목표를 위한 일 디자인의 리더는 경쟁력을 보이지 않으면 짤릴수 있다. 유지중심의 리더는 아무대서나 올수 있다.유지중심리더는 종종 팀멤버에게 인기가 좋다. 실력이 좋든그렇지 않든, 여자 일 수 도 있다. 대부분의 cultures에서 팀에서 이상적인 아버지는 task-specialist는 이상적 어머니는 maitenace-specialist이다. 몇몇 팀에서 team-mother로 여성이 있다. 부드러움은 유지작업하는데 상징으로, 딱딱함은 목적달성의 상징으로 보인다. 관리자는 여성이 task-specialist보다 유지관리하길 원한다. 물론 근거는 없다. 리더가 바뀌는건 팀위기일때이다. leader는 멤버의 추가나 없어짐은 구릅에서 이해에 의존한다 단순 팀맴버의 모든능력이 팀의 능력은 아니다. 다른사람의 작업을 볼수 있다.

민주적으로구성된팀 - 사람이 빠지는건 문제 없는데 사람을 영입할때 그사람이 할 정확한 자리가 없어서 좀 문제다. 냉정하고 덜 인간적이다. 일의 구성에 있어서 평등함. 경쟁력없는사람도 도덕적문제로 함부로 자르지 못한다. 경쟁력있는 사람이 어려운문제를 같이해결할 수 있는 사람이 없다. antisocial member는 communication라인에 잘린다. anitisocial은 좀더 실력이 있기 때문일수도 있다.

(authoritarian team) 새로운사람에게 친절함. 새로운사람은 리더만 따르면됨. 리더가 많은일을 함. 정신없을때 팀이 팀원을 읽을 수 있다. 아이디어 공유에서의 조합이 안될때 자르는건 답이 푸는건 아니지만 수행하기엔 충분한 시간이 없어 자른다. autoritarian group은 경쟁력있는 사람이 잘 할 수 있지만 리더와 오래일하지 않으면 그의 강점을 보일수 없어다. 사회화 가 안된 맴버는 autoritarian에서 일한는게 낫다.

조지G 이야기.

변화를 대응하는 팀이어야 한다. 팀위기는 보통상황에서 일어나지는 않기때문이다. 팀의 위기1. group에서 리더 강력한힘을 받아들일때, 동시에 group이 인내가 적어질때 민주적 팀은 하나의 모습과 같을까? 팀에서 사람을 로를때 self-shitfting한 사람을 뽑는다. 리더를 잘따르게하거나, 리더쉽의 장점을 믿게 한다. 팀과 member가 화낼지라도 결국 효과적 결과를 가져온다. 현명한 매니져는 팀의 구조와 구조 변경에 hand-off를 취한다.

팀유지에 관련된 사람이 여자이면 좋은점? 섬세하다는거 믿을 수 있나? 천재들이 일찍죽는 한 설은 사회에 적응 못하여 죽는데, 다른사람이 이해 못하기 때문이라고 한다. 이걸 생각하면 천재들 육성을 따로하자는 이야기가 나올만도함.

팀구성 요구사항이 늘어났다 (+development of capability in the team and team members) 지름길은 제시간에 성공적인 시스템을 만들어준다! 단 모든것이 모두 잘 돌아갈때. 최적의 측정으로 프로젝트는 잘돌아간다 미신을 가지고 있다. 그러나 거의 잘못돌아간다. 시간이 지날수록 사실임. 최소비용의 best programming은 프로그래머에게 충분한시간과 적은 사람(them)들의 조건을 최대한 주는것이다. (+ 적은숫자는 혼자가아니다 충분한시간은 팀구성시간까지 더한다. 본일은 팀에게 엄청난 잇점을준다.) 프로그래밍프로젝트에서 매우 안 좋은것들은 trainees를 많이 고용하는것과, 압박 받고과 절제가 없이 일하는 것이다.(+ 요즘은 trainees고용하지 않고, 압박과 절제문제가 가장흔한문제이다 그리고 고용된 많은 contactor에게 일의 압박과 절제를 그들에게 맞겨라. 프로그래밍에서 팀조직은 target system과 팀구성에 가장 영향을많이 받는다. 팀구성에서 기술보다는 compatibility가 더중요하다?(개인성격) 예전의 걱정,establishing,accepting goals의 예는 지금도 유효하다.(ibm 704→709의 예가 pcdos→windows)

팀목적의 동의가 중요하다. 팀원의 목적이 다 같은게 아닌 큰부분의 동의(overlapping)를 말한다. 리더쉽의중요성.(20년이 지나도 여기책의 내용은유용하다.)

프로젝트당 꼭 한명의 여성프로그래머가 있어야 한다고 했는데 지금은 맞지 않음. 사람들은 여성프로그래머때문에 집중력에 방해받는다고 하지만 결론적으로 그들은 여성과 대화를 할 기회가 없었기 때문이다. 팀위기에대해 크게 생각하지 못했다. 팀위기를 잘 방지하면 많은것들을 쉽게 할 수 있다.

여성프로그래머에 대해..