책“지식인을 관리하는 방법. 나, 너드와 괴짜들"

프로젝트 관리자(그리고 상사가 되기를 꿈꾸는 사람들)에게 바칩니다.

수많은 코드를 작성하는 것도 어렵지만 사람을 관리하는 것은 더욱 어렵습니다! 따라서 이 두 가지 방법을 모두 배우려면 이 책이 필요합니다.

재미있는 이야기와 진지한 수업을 결합하는 것이 가능합니까? Michael Lopp(좁은 범위에서는 Rands라고도 함)이 성공했습니다. 믿을 수 없을 만큼 보람찬(비록 허구이기는 하지만) 경험을 한 가상의 사람들에 관한 가상의 이야기를 발견하게 될 것입니다. 이것은 Rands가 Apple, Pinterest, Palantir, Netscape, Symantec 등 대규모 IT 기업에서 수년 동안 일하면서 얻은 다양하고 때로는 이상한 경험을 공유하는 방법입니다.

당신은 프로젝트 관리자입니까? 아니면 당신의 상사가 하루 종일 무엇을 하는지 알고 싶나요? Rands는 부풀어 오른 칠면조의 독성 세계에서 생존하는 방법과 역기능적으로 화려한 사람들의 일반적인 광기 속에서 번성하는 방법을 가르쳐 줄 것입니다. 이 이상한 정신병자들의 커뮤니티에는 신비한 조직 의식을 통해 많은 사람들의 계획, 생각 및 은행 계좌에 대한 권력을 얻은 관리자라는 낯선 생물도 있습니다.

이 책은 여느 경영이나 리더십 원고와는 다르다. Michael Lopp은 아무 것도 숨기지 않고 그냥 있는 그대로 말합니다(아마도 모든 이야기가 공개되어야 하는 것은 아닙니다: P). 하지만 그래야만 그런 상사와 함께 살아남는 방법, 괴짜와 괴짜를 관리하는 방법, "그 빌어먹을 프로젝트"를 해피 엔딩으로 가져오는 방법을 이해할 수 있습니다!

발췌. 공학적 사고방식

생각: 계속해서 코드를 작성해야 할까요?

관리자를 위한 규칙에 관한 Rands의 책에는 현대 경영자가 반드시 해야 할 일의 매우 짧은 목록이 포함되어 있습니다. 이 목록의 간결함은 "반드시"라는 개념이 일종의 절대적인 것이며 사람의 경우 절대적인 개념이 거의 없다는 사실에서 비롯됩니다. 한 직원의 성공적인 관리 방법은 다른 직원에게는 진정한 재앙이 될 것입니다. 이 생각은 관리자가 해야 할 일 목록의 첫 번째 항목입니다.

유연성을 유지하세요!

이미 모든 것을 알고 있다고 생각하는 것은 매우 나쁜 생각입니다. 세상이 끊임없이 변화하고 있다는 것이 유일한 불변의 상황에서는 유연성만이 올바른 입장이 됩니다.

역설적이게도 목록의 두 번째 항목은 놀라울 정도로 융통성이 없습니다. 하지만 이 점은 경영 성장의 기반을 마련하는 데 도움이 된다고 믿기 때문에 개인적으로 가장 좋아하는 점입니다. 이 단락은 다음과 같습니다.

코드 작성을 중단하세요!

이론적으로 관리자가 되고 싶다면 자신을 위해 일하는 사람들을 신뢰하고 코딩 전체를 그들에게 넘겨주는 법을 배워야 합니다. 이 조언은 일반적으로 소화하기 어렵습니다. 특히 새로 임명된 관리자에게는 더욱 그렇습니다. 아마도 그들이 관리자가 된 이유 중 하나는 개발 생산성 때문일 것입니다. 일이 잘못되면 그들의 첫 번째 반응은 자신이 전적으로 신뢰하는 기술, 즉 코드 작성 능력에 의지하는 것입니다.

새로 임명된 관리자가 코드 작성에 빠져 있는 것을 보면 나는 그에게 이렇게 말합니다. “우리는 당신이 코드를 작성할 수 있다는 것을 알고 있습니다. 문제는: 당신이 이끌 수 있습니까? 귀하는 더 이상 자신에 대해서만 책임을 지는 것이 아니라 팀 전체에 대해 책임을 져야 합니다. 그리고 저는 여러분이 직접 코드를 작성하지 않고도 여러분의 팀이 스스로 문제를 해결할 수 있도록 하고 싶습니다. 당신의 임무는 자신을 확장하는 방법을 알아내는 것입니다. 나는 당신이 하나만 있는 것을 원하지 않고, 당신 같은 사람이 많이 있기를 바랍니다.”

좋은 조언이죠? 규모. 관리. 책임. 이런 흔한 유행어. 조언이 틀려서 아쉽네요.

잘못된?

응. 조언이 틀렸어요! 완전히 틀린 것은 아니지만 이전 동료에게 전화를 걸어 사과해야 할 만큼 충분히 잘못되었습니다. “코드 작성을 중단하는 방법에 대해 제가 가장 좋아하는 말을 기억하십니까? 틀렸어! 예... 프로그래밍을 다시 시작하세요. Python과 Ruby로 시작하세요. 네, 진심이에요! 당신의 경력은 그것에 달려 있습니다!”

Borland에서 소프트웨어 개발자로 경력을 시작했을 때 저는 Paradox Windows 팀에서 일했는데, 이 팀은 거대한 팀이었습니다. 애플리케이션 개발자만 13명이었습니다. 핵심 데이터베이스 엔진, 핵심 애플리케이션 서비스 등 이 프로젝트의 핵심 기술을 지속적으로 연구하는 다른 팀의 인력을 추가하면 50명의 엔지니어가 이 제품 개발에 직접 참여하게 됩니다.

제가 일해본 어떤 팀도 이 정도 규모에 근접한 적이 없습니다. 사실, 해가 지날수록 제가 일하는 팀의 인원은 점차 줄어들고 있습니다. 무슨 일이야? 우리 개발자들은 점점 더 똑똑해지고 있나요? 아니요, 우리는 단지 부하를 공유하고 있을 뿐입니다.

개발자들은 지난 20년 동안 무엇을 해왔나요? 이 기간 동안 우리는 엄청난 양의 코드를 작성했습니다. 코드의 바다! 우리는 너무 많은 코드를 작성했기 때문에 모든 것을 단순화하고 오픈 소스로 전환하는 것이 좋은 생각이라고 결정했습니다.

다행스럽게도 인터넷 덕분에 이 과정은 이제 최대한 간단해졌습니다. 소프트웨어 개발자라면 지금 바로 확인해보세요! Google이나 Github에서 자신의 이름을 검색하면 오랫동안 잊어버렸지만 누구나 찾을 수 있는 코드를 볼 수 있습니다. 무섭죠? 코드가 영원히 살아 있다는 것을 모르셨나요? 예, 그는 영원히 살아요.

코드는 영원히 살아있습니다. 그리고 좋은 코드는 영원히 존재할 뿐만 아니라, 그것을 가치있게 여기는 사람들이 코드를 최신 상태로 유지하기 때문에 성장합니다. 이러한 고품질의 잘 관리된 코드 더미는 새로운 코드를 작성하는 대신 기존 코드에 집중하고 더 적은 인력과 더 짧은 시간 내에 작업을 완료할 수 있게 해주기 때문에 평균 엔지니어링 팀 규모를 줄이는 데 도움이 됩니다.

이러한 추론은 우울하게 들리지만, 우리 모두는 덕트 테이프를 사용하여 기존 사물의 서로 다른 부분을 연결하여 동일한 사물의 약간 다른 버전을 만드는 통합 자동 장치 무리일 뿐이라는 생각입니다. 이는 아웃소싱을 좋아하는 고위 경영진의 전형적인 사고 방식입니다. “Google 사용법을 알고 덕테이프만 갖고 있는 사람이라면 누구나 이 일을 할 수 있습니다! 그렇다면 왜 우리는 기계에 많은 돈을 지불하고 있습니까?”

우리는 이 경영진에게 정말 큰 돈을 주지만 그들은 그런 말도 안 되는 생각을 합니다. 다시 한 번 말씀드리지만, 제가 강조하는 점은 지구상에는 훌륭하고 열심히 일하는 개발자가 많다는 것입니다. 그들은 인증받은 대학에 앉아 단 XNUMX분도 시간을 보내지 않았지만 정말 똑똑하고 부지런합니다. 아 예, 이제 그 수가 점점 더 많아지고 있습니다!

나는 몇몇 뛰어난 동지들이 그곳을 찾고 있다고 해서 당신이 당신의 장소에 대해 걱정하기 시작하라고 제안하지 않습니다. 소프트웨어 개발의 발전은 아마도 당신보다 더 빠르게 진행될 것이기 때문에 이에 대해 걱정하기 시작하는 것이 좋습니다. 당신은 XNUMX년 동안 일해왔고 그중 XNUMX년은 관리자로 일하면서 "나는 이미 소프트웨어가 어떻게 개발되는지 알고 있다"고 생각합니다. 네, 아시죠. 안녕…

코드 작성은 그만하세요. 하지만...

내 원래 조언을 따르고 코드 작성을 중단하면 생성 프로세스 참여도 자발적으로 중단됩니다. 제가 아웃소싱을 적극적으로 활용하지 않는 이유도 바로 이 때문입니다. 오토마타는 창조하는 것이 아니라 생산한다. 잘 설계된 프로세스는 많은 비용을 절약하지만 세상에 새로운 것을 가져오지는 않습니다.

적은 돈으로 많은 일을 하는 소규모 팀이 있다면 코드 작성을 중단한다는 생각은 나에게 나쁜 직업 결정처럼 보입니다. 끝없는 규제, 프로세스, 정책이 있는 괴물 회사에서도 소프트웨어를 직접 개발하는 방법을 잊을 권리가 없습니다. 그리고 소프트웨어 개발은 ​​끊임없이 변화하고 있습니다. 지금은 변화하고 있습니다. 발 밑에! 바로 이 순간!

당신은 이의가 있습니다. 이해하다. 들어 보자.

“Rands, 나는 감독의 자리로 가는 중이에요! 계속해서 코드를 작성하면 내가 성장할 수 있다고 아무도 믿지 않을 것입니다.”

나는 당신에게 이것을 묻고 싶습니다: 당신이 "나는 이제 CEO가 될 것입니다!" 의자에 앉은 이후로 회사 내에서도 소프트웨어 개발 환경이 변화하고 있다는 것을 눈치채셨나요? 귀하의 대답이 '예'라면 또 다른 질문을 드리겠습니다. 정확히 어떻게 변화하고 있으며 이러한 변화에 대해 무엇을 하시겠습니까? 첫 번째 질문에 "아니오"라고 대답했다면 다른 의장으로 옮겨야 합니다. 왜냐하면 (장담합니다!) 바로 이 순간 소프트웨어 개발 분야가 변화하고 있기 때문입니다. 느리지만 확실하게 소프트웨어 개발 방법을 잊어버린다면 어떻게 성장할 수 있겠습니까?

내 조언은 다음 제품에 수많은 기능을 구현하는 데 전념하지 말라는 것입니다. 팀이 소프트웨어를 구축하는 방법을 파악하기 위해 지속적으로 조치를 취해야 합니다. 이사로서나 부사장으로서 이 일을 할 수 있습니다. 다른 것?

“어, 랜즈! 하지만 누군가는 중재자가 되어야 합니다! 누군가는 큰 그림을 보아야 합니다. 코드를 작성하면 관점을 잃게 됩니다."

여전히 심판이 되어야 하고, 결정을 방송해야 하며, 매주 월요일 아침 엔지니어 중 한 명과 함께 건물 주위를 30번 돌아다니며 그의 주간 "우리는 모두 운명에 처해 있습니다"라는 외침을 XNUMX초 동안 들어야 합니다. 분. ! 하지만 그 모든 것 외에도 엔지니어링 사고방식을 유지해야 하며, 이를 위해 풀타임 프로그래머가 될 필요는 없습니다.

엔지니어링 사고방식을 유지하기 위한 팁:

1. 개발 환경을 사용하세요. 이는 코드 빌드 시스템, 버전 제어, 프로그래밍 언어 등 팀의 도구에 익숙해야 함을 의미합니다. 결과적으로, 귀하는 팀이 제품 개발에 관해 이야기할 때 사용하는 언어에 능숙해지게 됩니다. 또한 완벽하게 작동하는 즐겨 사용하는 텍스트 편집기를 계속 사용할 수 있습니다.
2. 언제든지 어떤 표면에서도 제품을 설명하는 상세한 아키텍처 다이어그램을 그릴 수 있어야 합니다. 이제 세 개의 셀과 두 개의 화살표가 있는 단순화된 버전을 의미하는 것이 아닙니다. 제품의 상세도를 알아야 합니다. 가장 어려운 것. 그냥 귀여운 다이어그램이 아니라, 설명하기 어려운 다이어그램입니다. 제품에 대한 완전한 이해에 적합한 지도이어야 합니다. 끊임없이 변화하고 있으므로 특정 변화가 발생한 이유를 항상 알아야 합니다.
3. 기능 중 하나의 구현을 인계받습니다. 이 지점에는 숨겨진 위험이 많이 있기 때문에 이 글을 쓰면서 문자 그대로 움츠러들었습니다. 하지만 적어도 하나의 기능을 구현하지 않고도 1번 지점과 2번 지점을 달성할 수 있을지 확신할 수 없습니다. 기능 중 하나를 직접 구현하면 개발 프로세스에 적극적으로 참여할 수 있을 뿐만 아니라 주기적으로 "모든 것을 담당하는 관리자" 역할에서 "하나의 구현을 담당하는 사람"의 역할로 전환할 수 있습니다. 기능의.” 이러한 겸손하고 겸손한 태도는 작은 결정의 중요성을 일깨워줄 것입니다.
4. 아직도 온몸이 떨리고 있어요. 누군가가 이미 나에게 소리를 지르고 있는 것 같다. “기능 구현을 스스로 맡은 관리자?! (저도 그 말에 동의합니다!) 예, 여전히 관리자이십니다. 즉, 작은 기능이어야 한다는 뜻입니다. 그렇죠? 네, 아직 할 일이 많아요. 기능 구현을 직접 수행할 수 없다면 몇 가지 조언을 드리겠습니다. 몇 가지 버그를 수정하세요. 이 경우 창작의 기쁨은 느끼지 못하지만, 제품이 어떻게 만들어지는지 이해하게 되므로 작업에서 결코 소외되지 않을 것입니다.
5. 단위 테스트를 작성합니다. 나는 사람들이 미쳐가기 시작하는 제작 주기의 후반부에 아직도 이 일을 합니다. 귀하의 제품에 대한 건강 체크리스트라고 생각하십시오. 이것을 자주 하십시오.

또 이의?

“Rands, 내가 코드를 작성하면 팀이 혼란스러워질 것입니다. 그들은 내가 관리자인지 개발자인지 알지 못할 것입니다.”

좋아.

네, "알았어!"라고 했어요. 개발자 연못에서 수영하는 것만으로도 팀을 혼란스럽게 할 수 있다고 생각하니 기쁘군요. 간단합니다. 소프트웨어 개발에서 다양한 역할 간의 경계가 현재 매우 모호합니다. UI 담당자는 광범위하게 JavaScript 및 CSS 프로그래밍이라고 할 수 있는 작업을 수행합니다. 개발자는 사용자 경험 디자인에 대해 점점 더 많이 배우고 있습니다. 사람들은 서로 소통하고 버그, 다른 사람의 코드 도난에 대해 배우고 관리자가 이 대규모의 글로벌 교차 수분 정보 바카날리아에 참여하지 않을 타당한 이유가 없다는 사실도 배웁니다.

게다가 쉽게 교체할 수 있는 부품으로 구성된 팀의 일원이 되고 싶나요? 이는 팀을 더욱 민첩하게 만들 뿐만 아니라 각 팀 구성원이 다양한 관점에서 제품과 회사를 볼 수 있는 기회를 제공합니다. 빌드 스크립트의 단순하고 우아함을 본 후 빌드를 담당하는 차분한 사람인 Frank를 어떻게 존경하게 될 수 있습니까?

나는 당신의 팀이 혼란스럽고 혼란스러워지는 것을 원하지 않습니다. 오히려 팀이 더 효과적으로 소통했으면 좋겠어요. 제품을 만들고 기능을 개발하는 데 참여한다면 팀과 더 가까워질 것이라고 믿습니다. 그리고 더 중요한 것은 조직 내 소프트웨어 개발 프로세스의 지속적인 변화에 더 가까이 다가갈 수 있다는 것입니다.

개발을 멈추지 마세요

볼랜드에 있는 내 동료가 나를 "코더"라고 불렀다는 이유로 나를 공격한 적이 있다.

“Rands, 코더는 생각 없는 기계예요! 원숭이! 코더는 쓸모없는 코드를 지루하게 작성하는 것 외에는 중요한 일을 하지 않습니다. 저는 코더가 아니라 소프트웨어 개발자입니다!”

그녀는 옳았습니다. 그녀는 제가 신임 CEO에게 처음에 했던 조언인 “코드 작성을 중단하세요!”를 싫어했을 것입니다. 내가 그들이 코더라고 제안하는 것이 아니라 그들이 자신의 직업에서 가장 중요한 부분 중 하나인 소프트웨어 개발을 무시하기 시작한다고 적극적으로 제안하고 있기 때문입니다.

그래서 조언을 업데이트했습니다. 좋은 리더가 되고 싶다면 코드 작성을 멈출 수 있지만...

융통성을 가지십시오. 엔지니어가 된다는 것이 무엇을 의미하는지 기억하고 소프트웨어 개발을 중단하지 마십시오.

Об авторе

마이클 롭(Michael Lopp)은 아직 실리콘 밸리를 떠나지 않은 베테랑 소프트웨어 개발자입니다. 지난 20년 동안 Michael은 Apple, Netscape, Symantec, Borland, Palantir, Pinterest 등 다양한 혁신적인 기업에서 근무했으며 천천히 망각 속으로 떠오른 스타트업에도 참여했습니다.

업무 외적으로 Michael은 Rands라는 가명으로 기술 및 관리에 관한 인기 블로그를 운영하고 있습니다. 여기서 그는 관리 분야의 아이디어를 독자들과 논의하고 끊임없이 최신 정보를 확인해야 하는 필요성에 대한 우려를 표명하며, 제품 제작에 대한 넉넉한 보상, 귀하의 성공은 귀하의 팀 덕분에 가능합니다. 블로그는 여기에서 확인하실 수 있습니다 www.randsinrepose.com.

Michael은 캘리포니아 레드우드에서 가족과 함께 살고 있습니다. 바쁜 것보다 건강이 더 중요하기 때문에 그는 항상 산악자전거를 타거나 하키를 하고 레드 와인을 마실 시간을 냅니다.

» 책에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 발행인의 웹사이트
» 차례
» 발췌

Khabrozhiteley의 경우 쿠폰을 사용하여 20% 할인을 받으세요 - 사람 관리

책의 종이 버전에 대한 결제가 완료되면 전자 버전의 책이 이메일로 전송됩니다.

추신: 책 가격의 7%는 새 컴퓨터 책 번역, 인쇄소에 넘겨지는 책 목록에 사용됩니다. 여기에.

출처 : habr.com