Tim Lister - 책의 공동 저자

• "인적 요소. 성공적인 프로젝트 및 팀'(원본은 'Peopleware'라고 함)
• "곰과의 왈츠: 소프트웨어 프로젝트의 위험 관리"
• “패턴에 의해 아드레날린이 치솟고 좀비화되었습니다. 프로젝트 팀의 행동 패턴"

이 책들은 모두 해당 분야의 고전이며, 같은 분야의 동료들과 함께 집필되었습니다. 대서양 시스템 길드. 러시아에서는 그의 동료가 가장 유명합니다. 톰 드마르코 и 피터 흐루슈카, 그는 또한 많은 유명한 작품을 썼습니다.

Tim은 소프트웨어 개발 분야에서 40년의 경력을 갖고 있으며, 1975년(이 habrapost를 쓴 사람 중 올해 태어난 사람은 아무도 없음) Tim은 이미 Yourdon Inc.의 수석 부사장이었습니다. 그는 이제 상담하고, 가르치고, 집필하는 데 시간을 보내고 있으며, 가끔 다음과 같은 곳을 방문합니다. 보고서 포함 전 세계 컨퍼런스.

우리는 특히 Habr을 위해 Tim Lister와 인터뷰를 했습니다. 그는 DevOops 2019 컨퍼런스를 열 예정이며, 우리는 책 등에 관해 많은 질문을 갖고 있습니다. 인터뷰는 컨퍼런스 프로그램 위원회의 Mikhail Druzhinin과 Oleg Chirukhin이 진행합니다.

마이클 : 지금 하고 있는 일에 대해 몇 마디 말씀해주실 수 있나요?

팀: 저는 대서양 시스템 길드의 수장입니다. 길드에는 우리 여섯 명이 있는데, 우리는 스스로를 교장이라고 부릅니다. 미국에 XNUMX개, 유럽에 XNUMX개 - 이것이 바로 길드를 Atlantic이라고 부르는 이유입니다. 우리는 셀 수 없을 만큼 오랫동안 함께했습니다. 우리 모두에게는 전문 분야가 있습니다. 저는 지난 XNUMX년 이상 고객과 협력해 왔습니다. 내 프로젝트에는 관리뿐만 아니라 요구 사항 설정, 프로젝트 계획 및 평가도 포함됩니다. 시작이 좋지 않은 프로젝트는 대개 끝이 좋지 않은 것 같습니다. 따라서 모든 활동이 잘 계획되고 조정되어 제작자의 아이디어가 결합되었는지 확인하는 것이 좋습니다. 당신이 하고 있는 일과 그 이유에 대해 생각해 볼 가치가 있습니다. 프로젝트를 완료하기 위해 사용할 전략은 무엇입니까?

저는 수년 동안 다양한 방법으로 고객에게 상담을 해왔습니다. 흥미로운 예는 무릎과 고관절 수술용 로봇을 만드는 회사입니다. 외과 의사는 완전히 독립적으로 수술하지 않고 로봇을 사용합니다. 솔직히 말해서 여기에서는 안전이 중요합니다. 하지만 문제 해결에 집중하는 사람들과 요구 사항에 대해 논의하려고 하면... 이상하게 들리겠지만 미국에는 다음이 있습니다. FDA는 (Federal Drug Administration), 이러한 로봇과 같은 제품에 대한 라이센스를 부여합니다. 무엇이든 판매하고 살아있는 사람에게 사용하기 전에 라이센스를 취득해야 합니다. 조건 중 하나는 요구 사항, 테스트 내용, 테스트 방법, 테스트 결과를 보여주는 것입니다. 요구 사항을 변경하면 이 거대한 테스트 프로세스 전체를 계속해서 거쳐야 합니다. 우리 고객은 요구 사항에 애플리케이션의 시각적 디자인을 포함시켰습니다. 그들은 요구 사항의 일부로 직접 스크린샷을 가지고 있었습니다. 우리는 그것들을 꺼내서 대부분의 경우 이 모든 프로그램이 무릎과 엉덩이, 카메라와 관련된 모든 것 등에 대해 아무것도 모른다고 설명해야 합니다. 실제로 중요한 기본 조건이 변경되지 않는 한 요구 사항 문서가 절대 변경되지 않도록 요구 사항 문서를 다시 작성해야 합니다. 시각적 디자인이 요구 사항에 포함되지 않은 경우 제품 업데이트가 훨씬 빨라집니다. 우리의 임무는 무릎, 엉덩이, 등의 수술을 다루는 요소를 찾아 별도의 문서로 추출하고 이것이 기본 요구 사항이 될 것이라고 말하는 것입니다. 무릎 수술에 대한 격리된 요구 사항 그룹을 만들어 보겠습니다. 이를 통해 우리는 보다 안정적인 요구 사항 세트를 구축할 수 있습니다. 특정 로봇이 아닌 전체 제품 라인에 대해 이야기하겠습니다.

많은 작업이 수행되었지만 이전에는 의미나 필요 없이 몇 주, 몇 달 동안 반복 테스트를 보냈던 곳으로 여전히 도달했습니다. 왜냐하면 종이에 설명된 요구 사항이 시스템 구축에 필요한 실제 요구 사항과 일치하지 않았기 때문입니다. FDA는 매번 요구 사항이 변경되었으므로 처음부터 모든 것을 확인해야 한다고 말했습니다. 전체 제품에 대한 완전한 재검사로 인해 기업이 망가졌습니다.

따라서 흥미로운 일이 시작될 때 자신을 발견하고 첫 번째 행동이 게임의 추가 규칙을 설정하면 멋진 작업이 있습니다. 이 초기 활동이 관리적 관점과 기술적 관점 모두에서 잘 작동하도록 시작한다면 훌륭한 프로젝트가 될 가능성이 있습니다. 하지만 이 부분이 궤도를 벗어나 어딘가 잘못된 곳으로 갔다면, 근본적인 합의를 찾을 수 없다면… 아니, 프로젝트가 반드시 실패하는 것은 아닙니다. 하지만 더 이상 "우리는 훌륭하게 해냈습니다. 모든 일을 정말 효과적으로 해냈습니다."라고 말할 수는 없습니다. 제가 고객과 소통할 때 하는 일은 다음과 같습니다.

마이클 : 즉, 프로젝트를 시작하고 일종의 킥오프를 수행하며 레일이 올바른 방향으로 향하고 있는지 확인합니까?

팀: 우리는 또한 퍼즐의 모든 조각을 하나로 모으는 방법에 대한 아이디어도 가지고 있습니다. 즉, 어떤 기술이 필요한지, 정확히 언제 필요한지, 팀의 핵심은 어떤 모습인지, 기타 기본적인 사항도 있습니다. 정규직 직원이 필요한가요, 아니면 파트타임 직원을 고용할 수 있나요? 기획, 관리. 다음과 같은 질문이 있습니다. 이 특정 프로젝트에서 가장 중요한 것은 무엇입니까? 이것을 달성하는 방법은 무엇입니까? 이 제품이나 프로젝트에 대해 우리가 무엇을 알고 있는지, 위험은 무엇인지, 알려지지 않은 부분은 어디에 있는지, 이 모든 것을 어떻게 처리할 것인가? 물론 이 순간 누군가 “애자일은 어때요?”라고 외치기 시작합니다. 좋아요, 여러분은 모두 유연합니다. 그런데 어쩌죠? 프로젝트는 정확히 어떤 모습이며, 프로젝트에 맞는 방식으로 어떻게 꺼내실 예정인가요? 단순히 "우리의 접근 방식은 무엇이든 확장됩니다. 우리는 스크럼 팀입니다!"라고 말할 수는 없습니다. 이것은 말도 안되고 말도 안되는 일입니다. 다음에는 어디로 갈 예정이고, 왜 작동해야 하며, 요점은 어디에 있습니까? 나는 고객에게 이러한 모든 질문에 대해 생각하도록 가르칩니다.

민첩한 19년

마이클 : Agile에서 사람들은 종종 사전에 아무것도 정의하지 않고 가능한 한 늦게 결정을 내리려고 노력합니다. "우리는 너무 커서 전체 아키텍처에 대해 생각하지 않을 것입니다." 다른 것을 많이 생각하지 않고 지금 당장 고객에게 효과가 있는 것을 전달하겠습니다.

팀: 내 생각에 애자일 방법론은 민첩한 선언 2001년 업계에 눈을 떴습니다. 그러나 반면에 완벽한 것은 없습니다. 나는 반복적인 개발을 지지합니다. 반복은 대부분의 프로젝트에서 많은 의미를 갖습니다. 하지만 생각해야 할 질문은 제품이 출시되어 사용되면 얼마나 오래 지속됩니까? 이 제품은 다른 제품으로 교체되기 전까지 1994개월 동안 지속되는 제품인가요? 아니면 이 제품이 수년 동안 작동할 수 있습니까? 물론 이름을 밝히지는 않겠지만... 뉴욕과 그 금융계에서는 가장 기본적인 시스템이 매우 오래되었습니다. 이거 엄청나 네. 당신은 그들을 보고 생각합니다. 시간을 거슬러 2019년으로 돌아가서 개발자들에게 이렇게 말할 수 있습니다. “나는 미래, XNUMX년에서 왔습니다. 필요한 만큼만 이 시스템을 개발하세요. 확장 가능하게 만들고 아키텍처에 대해 생각해 보세요. 그러면 XNUMX년 이상 동안 개선될 것입니다. 개발을 조금만 더 미루면 큰 계획에서는 아무도 눈치 채지 못할 것입니다!” 장기적으로 물건을 추정할 때는 총 비용이 얼마인지 고려해야 합니다. 때로는 잘 설계된 아키텍처가 그만한 가치가 있는 경우도 있지만 때로는 그렇지 않은 경우도 있습니다. 우리는 주위를 둘러보고 스스로에게 질문해야 합니다. 우리는 그러한 결정을 내릴 수 있는 올바른 상황에 있습니까?

따라서 "우리는 민첩성을 추구합니다. 고객이 원하는 것이 무엇인지 직접 알려줄 것입니다."와 같은 아이디어는 매우 순진합니다. 고객은 자신이 원하는 것이 무엇인지도 모르고, 무엇을 얻을 수 있는지도 모릅니다. 어떤 사람들은 역사적 사례를 주장으로 인용하기 시작할 것입니다. 나는 이미 이것을 보았습니다. 하지만 기술적으로 진보한 사람들은 대개 그런 말을 하지 않습니다. 그들은 이렇게 말합니다. "지금은 2019년입니다. 이것이 우리에게 기회입니다. 우리는 이러한 것들을 보는 방식을 완전히 바꿀 수 있습니다!" 기존 솔루션을 모방하여 좀 더 예쁘고 깔끔하게 만드는 대신 때로는 "우리가 여기서 하려는 것을 완전히 재창조하자!"라고 말해야 합니다.

그리고 나는 대부분의 고객이 문제에 대해 그런 식으로 생각할 수 없다고 생각합니다. 그들은 이미 가지고 있는 것만을 봅니다. 그게 전부입니다. 그 후에는 “이걸 좀 더 간단하게 만들어보자”거나 평소 말하는 대로 요청합니다. 하지만 우리는 웨이터나 웨이트리스가 아니기 때문에 아무리 어리석은 일이라도 주문을 받고 부엌에서 구울 수 있습니다. 우리는 그들의 가이드입니다. 우리는 그들의 눈을 뜨고 다음과 같이 말해야 합니다. "여기서 새로운 기회가 생겼습니다!" 귀하의 비즈니스에서 이 부분이 수행되는 방식을 우리가 정말로 바꿀 수 있다는 것을 알고 계십니까? 애자일의 문제점 중 하나는 무엇이 기회인지, 무엇이 문제인지, 무엇을 해야 하는지, 어떤 사용 가능한 기술이 이 특정 상황에 가장 적합한지에 대한 인식을 제거한다는 것입니다.

아마도 나는 여기서 지나치게 회의적일 것입니다. 애자일 커뮤니티에는 놀라운 일들이 많이 일어나고 있기 때문입니다. 하지만 사람들이 프로젝트를 정의하는 대신 손을 내밀기 시작한다는 사실에 문제가 있습니다. 저는 여기에서 묻고 싶습니다. 우리는 무엇을 하고 있고, 어떻게 할 것입니까? 그리고 마술처럼 항상 고객이 누구보다 더 잘 알아야 한다는 것이 밝혀졌습니다. 하지만 클라이언트는 누군가가 이미 만든 것 중에서 선택할 때만 가장 잘 압니다. 자동차를 사고 싶은데 가계 예산 규모를 안다면 내 라이프스타일에 맞는 자동차를 빠르게 선택하게 됩니다. 여기서 나는 누구보다 모든 것을 더 잘 알고 있습니다! 그러나 누군가가 이미 자동차를 만들었다는 점에 유의하십시오. 나는 새 차를 만드는 방법을 전혀 모릅니다. 나는 전문가도 아닙니다. 맞춤형 제품이나 특수 제품을 만들 때 고객의 목소리를 고려해야 하지만, 이것이 더 이상 유일한 목소리가 아닙니다.

올렉 : 애자일 선언문을 언급하셨습니다. 문제에 대한 현대적인 이해를 고려하여 어떻게든 업데이트하거나 수정해야 합니까?

팀: 나는 그를 만지지 않을 것입니다. 정말 훌륭한 역사적 문서라고 생각합니다. 내 말은, 그 사람이 바로 그 사람이라는 것입니다. 그는 이제 19세가 되었고, 늙었지만 그 시대에 그는 혁명을 일으켰습니다. 그가 잘한 것은 그가 반응을 일으키고 사람들이 그에 대해 속삭이기 시작했다는 것입니다. 아마도 당신은 2001년에 아직 업계에서 일하지 않았을 것입니다. 그러나 그 당시에는 모두가 프로세스에 따라 일했습니다. 소프트웨어 공학 연구소(Software Engineering Institute), 소프트웨어 완성도 모델(CMMI)의 XNUMX가지 수준. 그런 고대의 전설이 당신에게 뭔가를 말해 주는지는 모르겠지만 그것은 돌파구였습니다. 처음에 사람들은 프로세스가 올바르게 설정되면 문제가 저절로 사라질 것이라고 믿었습니다. 그리고 나서 선언문이 나와서 이렇게 말합니다. "아니요, 아니, 아닙니다. 우리는 프로세스가 아닌 사람을 기반으로 할 것입니다." 우리는 소프트웨어 개발의 달인입니다. 우리는 이상적인 과정이 신기루이며 그런 일이 일어나지 않는다는 것을 알고 있습니다. 프로젝트에는 너무 많은 특이성이 있습니다. 모든 프로젝트에 대해 하나의 완벽한 프로세스라는 아이디어는 의미가 없습니다. 모든 것에 대한 해결책이 단 하나뿐이라고 주장하기에는 문제가 너무 복잡합니다(안녕하세요, 열반).

나는 미래를 내다볼 생각은 없지만 이제 사람들이 프로젝트에 대해 더 많이 생각하기 시작했다고 말하고 싶습니다. 나는 애자일 선언문이 튀어나와서 “안녕하세요!”라고 말하는 데 매우 능숙하다고 생각합니다. 당신은 배를 타고 있고 당신 자신이 이 배를 운전하고 있습니다. 당신은 결정을 내려야 할 것입니다. 우리는 모든 상황에 대한 보편적인 방법을 제안하지 않을 것입니다. 당신은 배의 승무원이며, 당신이 충분히 훌륭하다면 목표를 향한 길을 찾을 수 있습니다. 당신 앞에도 다른 배가 있었고, 당신 뒤에도 다른 배가 있을 것입니다. 하지만 여전히 어떤 의미에서 당신의 여정은 독특합니다.” 그런 것! 그것은 사고방식이다. 나에게는 태양 아래 새로운 것이 없습니다. 사람들은 이전에 항해했고 다시 항해할 것입니다. 그러나 당신에게는 이것이 당신의 주요 여행이며, 나는 당신에게 정확히 무슨 일이 일어날지 말하지 않을 것입니다. 팀 내에서 조화롭게 작업하는 기술이 있어야 하며, 실제로 그러한 기술이 있으면 모든 것이 잘 풀리고 원하는 곳에 도달할 수 있습니다.

피플웨어: 30년 후

올렉 : 피플웨어도 선언문과 마찬가지로 혁명이었나요?

팀: Peopleware... Tom과 나는 이 책을 썼지만, 이런 일이 일어날 것이라고는 생각하지 못했습니다. 어쨌든 그것은 많은 사람들의 생각에 공감했습니다. 이 책은 소프트웨어 개발은 ​​매우 인간 집약적인 활동이라고 말한 첫 번째 책이었습니다. 우리의 기술적 특성에도 불구하고 우리는 크고, 심지어 거대하고, 매우 복잡한 무언가를 만드는 사람들의 커뮤니티이기도 합니다. 그런 것들은 누구도 혼자서는 만들 수 없잖아요? 그래서 '팀'이라는 개념이 매우 중요해졌습니다. 그리고 관리의 관점에서뿐만 아니라, 알려지지 않은 수많은 복잡한 문제를 해결하기 위해 함께 모인 기술 인력에게도 적합합니다. 개인적으로 이것은 내 경력 전반에 걸쳐 지능에 대한 엄청난 테스트였습니다. 그리고 여기에서 다음과 같이 말할 수 있어야 합니다. 예, 이 문제는 제가 혼자서 처리할 수 있는 것보다 더 크지만, 함께라면 우리가 자랑스러워할 수 있는 우아한 해결책을 찾을 수 있습니다. 그리고 저는 이 아이디어가 가장 큰 반향을 불러일으켰다고 생각합니다. 우리가 어떤 시간은 스스로 일하고, 어떤 시간은 그룹의 일원으로 일하고, 종종 결정은 그룹에 의해 이루어진다는 생각입니다. 그룹 문제 해결은 복잡한 프로젝트에서 빠르게 중요한 특징이 되었습니다.

Tim이 수많은 강연을 했다는 사실에도 불구하고 YouTube에 게시된 강연은 거의 없습니다. 2007년 '피플웨어의 귀환' 보고서를 보면 알 수 있다. 물론 품질은 많이 아쉽습니다.

마이클 : 책이 출판된 후 지난 30년 동안 어떤 변화가 있었나요?

팀: 다양한 각도에서 이를 볼 수 있습니다. 사회학적으로 말하자면... 옛날 옛적에, 더 단순한 시대에 당신과 당신의 팀은 같은 사무실에 앉아 있었습니다. 매일 친하게 지내고, 함께 커피를 마시고, 일에 대해 토론할 수도 있습니다. 실제로 변경된 점은 이제 팀이 서로 다른 국가 및 시간대에 지리적으로 분산될 수 있지만 여전히 동일한 문제를 해결하기 위해 노력하고 있으며 이로 인해 완전히 새로운 복잡성 계층이 추가된다는 것입니다. 구식으로 들릴 수도 있지만 모두가 함께 일하고 동료에게 다가가서 "내가 발견한 것 좀 봐, 이거 어때?"라고 말할 수 있는 대면 의사소통만큼 좋은 것은 없습니다. 대면 대화는 비공식적 의사소통으로 빠르게 전환할 수 있는 방법을 제공하며 민첩한 대화를 좋아하는 사람들도 이를 좋아할 것이라고 생각합니다. 그리고 현실적으로 세상은 아주 작은 것으로 밝혀졌고 이제는 모든 것이 분산된 팀으로 덮여 있고 모두 매우 복잡하기 때문에 걱정스럽습니다.

우리 모두는 DevOps에 살고 있습니다

마이클 : 컨퍼런스 프로그램 위원회의 관점에서도 캘리포니아, 뉴욕, 유럽, 러시아에 사람들이 있습니다. 싱가포르에는 아직 아무도 없습니다. 지리적인 차이가 꽤 크며, 사람들이 더욱 널리 퍼지기 시작했습니다. 개발에 관해 이야기한다면 데브옵스와 팀 간 장벽 허물기에 대해 더 자세히 알려주실 수 있나요? 모두가 벙커에 앉아 있다가 이제 벙커가 무너지고 있다는 개념이 있는데, 이 비유에 대해 어떻게 생각하시나요?

팀: 최근 기술 혁신을 고려할 때 데브옵스(devops)는 매우 중요하다고 생각됩니다. 이전에는 개발자와 관리자로 구성된 팀이 있었고 그들은 일하고 또 일하고 어느 시점에서 관리자에게 와서 프로덕션을 위해 출시할 수 있는 것이 나타났습니다. 그리고 여기에서 벙커에 대한 대화가 시작되었습니다. 왜냐하면 관리자는 적어도 적이 아니라 일종의 동맹이기 때문입니다. 그러나 모든 것이 생산에 들어갈 준비가 되었을 때만 그들과 이야기했습니다. 그들에게 무언가를 가지고 가서 이렇게 말했습니까? 우리가 어떤 애플리케이션을 가지고 있는지 보세요. 그런데 이 애플리케이션을 출시할 수 있습니까? 이제 배달의 전체적인 개념이 더 나은 방향으로 바뀌었습니다. 내 말은, 변화를 빠르게 추진할 수 있다는 생각이 있다는 것입니다. 우리는 즉시 제품을 업데이트할 수 있습니다. 내 노트북의 Firefox가 팝업되어 백그라운드에서 Firefox를 업데이트했습니다. 잠시 시간을 내어 여기를 클릭하시면 최신 릴리스를 제공해 드리겠습니다.라고 말할 때 저는 항상 미소를 지었습니다. 그리고 나는 "오 그래, 자기야!"라고 말했습니다. 내가 자고 있는 동안 그들은 내 컴퓨터에서 바로 새 릴리스를 전달하는 작업을 하고 있었습니다. 이것은 훌륭하고 믿을 수 없는 일입니다.

하지만 여기에 어려움이 있습니다. 소프트웨어 업데이트에 이 기능이 있지만 사람들을 통합하는 것은 훨씬 더 어렵습니다. DevOops 기조연설에서 제가 말하고 싶은 것은 이제 그 어느 때보다 더 많은 플레이어가 있다는 것입니다. 한 팀에 속한 모든 사람들을 생각해보면… 여러분은 이를 하나의 팀으로 생각하셨는데, 이는 단순한 프로그래머 팀 그 이상입니다. 이들은 테스터, 프로젝트 관리자 및 기타 여러 사람들입니다. 그리고 모든 사람은 세상에 대한 자신의 견해를 가지고 있습니다. 제품 관리자는 프로젝트 관리자와 완전히 다릅니다. 관리자에게는 고유한 작업이 있습니다. 무슨 일이 일어나고 있는지 계속 인식하고 미쳐버리지 않도록 모든 참가자를 조정하는 것은 다소 어려운 문제가 됩니다. 그룹의 업무와 모든 사람에게 적용되는 업무를 분리할 필요가 있습니다. 이것은 매우 어려운 작업입니다. 반면에, 나는 그것이 몇 년 전보다 훨씬 나아졌다고 생각합니다. 이것이 바로 사람들이 성장하고 올바르게 행동하는 법을 배우는 길입니다. 통합을 수행할 때 지하 개발이 있어서는 안 된다는 것을 이해하게 됩니다. 그래야 마지막 순간에 소프트웨어가 잭인더박스처럼 크롤링되지 않습니다. 예를 들어, 우리가 여기서 한 일을 보세요! 통합과 개발을 할 수 있게 되고, 결국에는 깔끔하고 반복적인 방식으로 출시하게 된다는 아이디어입니다. 이 모든 것은 나에게 큰 의미가 있습니다. 이를 통해 시스템 사용자와 고객을 위해 더 많은 가치를 창출할 수 있습니다.

마이클 : DevOps의 전체적인 아이디어는 의미 있는 개발을 가능한 한 빨리 제공하는 것입니다. 나는 세상이 점점 더 속도를 내기 시작했다고 봅니다. 이러한 가속도에 어떻게 적응하나요? XNUMX년 전에는 이런 것이 존재하지 않았습니다!

팀: 물론 모든 사람은 점점 더 많은 기능을 원합니다. 움직일 필요가 없습니다. 더 쌓기만 하면 됩니다. 유용한 정보를 가져오기 위해 다음 증분 업데이트를 위해 속도를 줄여야 하는 경우도 있습니다. 이는 완전히 정상적인 현상입니다.

달리고, 달리고, 달려야 한다는 생각은 최선이 아닙니다. 그런 삶을 살고 싶어하는 사람은 거의 없을 것입니다. 나는 전달의 리듬이 프로젝트 자체의 리듬을 설정하고 싶습니다. 만약 당신이 단지 작고 상대적으로 무의미한 것들의 흐름을 만들어낸다면 그것은 모두 의미가 없게 됩니다. 아무 생각 없이 가능한 한 빨리 출시하려고 하기보다는 수석 개발자, 제품 및 프로젝트 관리자와 논의할 가치가 있는 것은 전략입니다. 이게 말이 되나요?

패턴과 안티패턴

올렉 : 당신은 주로 패턴과 안티패턴에 대해 이야기하는데, 이것이 프로젝트의 생사를 가르는 차이입니다. 그리고 이제 데브옵스는 우리 삶에 깊숙이 들어왔습니다. 그 자리에서 프로젝트를 중단시킬 수 있는 자체 패턴과 안티패턴이 있습니까?

팀: 패턴과 안티패턴은 항상 발생합니다. 얘기할 게 있어요. 음, 우리가 "빛나는 것"이라고 부르는 것이 있습니다. 사람들은 정말 새로운 기술을 좋아합니다. 그들은 멋지고 세련되어 보이는 모든 것의 반짝임에 매료되어 질문을 중단합니다. 그것이 꼭 필요한가요? 우리는 무엇을 달성할 것인가? 이게 믿을만한가요? 말이 되나요? 나는 종종 최첨단 기술에 종사하는 사람들을 봅니다. 그들은 세상에서 일어나는 일들에 최면에 걸립니다. 그러나 그들이 하는 유용한 일을 자세히 살펴보면 종종 유용한 것이 전혀 없습니다!

우리는 올해가 인류가 달에 착륙한 지 1969주년이 되는 해라는 사실을 동료들과 논의하고 있었습니다. 사람들이 거기에 도달하는 데 도움이 된 기술은 1969년 기술이 아니라 오히려 1960년이나 62년의 기술입니다. 왜냐하면 NASA는 신뢰성에 대한 좋은 증거가 있는 것만 사용하기를 원했기 때문입니다. 그래서 당신은 그것을 보고 이해합니다. 그렇습니다. 그리고 그것은 사실이었습니다! 아니, 아니죠. 하지만 모든 것이 너무 세게 밀리고 모든 틈에서 팔리기 때문에 기술 문제에 직면하게 됩니다. 사람들은 어디에서나 소리치고 있습니다. "이봐, 이게 무슨 일이야? 이것은 세상에서 가장 새롭고, 모든 사람에게 적합한 가장 아름다운 것입니다!" 글쎄, 그게 다야... 보통 이 모든 것은 단지 미끼일 뿐이라는 것이 밝혀지고, 그러면 모두 버려져야 한다. 어쩌면 내가 이미 늙어서 그런 일들을 회의적인 시각으로 바라볼 때 사람들이 최고의 기술을 만드는 유일하고 가장 정확한 방법을 찾았다고 말할 때 때문일 수도 있습니다. 이 순간, 내 안에서 “이건 엉망이야!”라고 말하는 목소리가 일어납니다.

마이클 : 실제로 우리는 차세대 기술에 대해 얼마나 자주 들어보았습니까?

팀: 정확합니다. 이것이 일반적인 과정입니다! 예를 들어... 이것은 이미 전 세계적으로 농담이 된 것 같지만 여기서는 블록체인 기술에 대해 자주 이야기합니다. 그리고 실제로 특정 상황에서는 의미가 있습니다! 이벤트에 대한 신뢰할 수 있는 증거가 정말로 필요할 때, 시스템이 작동하고 아무도 우리를 속이지 않았다는 것, 보안 문제와 그 모든 것들이 뒤섞여 있을 때, 블록체인은 의미가 있습니다. 하지만 블록체인이 이제 전 세계를 휩쓸고 그 길에 있는 모든 것을 쓸어버릴 것이라고 말하면 어떻게 될까요? 더 많은 꿈을 꾸세요! 이는 매우 비싸고 복잡한 기술입니다. 기술적으로 복잡하고 시간이 많이 걸립니다. 순전히 알고리즘적인 부분을 포함하면 수학을 다시 계산해야 할 때마다 약간의 변경 사항을 적용하여... 이는 좋은 아이디어이지만 특정 경우에만 해당됩니다. 내 인생과 경력 전체는 매우 구체적인 상황에서의 흥미로운 아이디어에 관한 것입니다. 자신의 상황이 무엇인지 정확히 이해하는 것이 매우 중요합니다.

마이클 : 예, "생명, 우주 및 모든 것에 대한 주요 질문"입니다. 이 기술이나 접근 방식이 귀하의 상황에 적합한가요?

팀: 이 질문은 이미 기술 그룹과 논의될 수 있습니다. 어쩌면 컨설턴트를 데려올 수도 있습니다. 프로젝트를 살펴보고 이해하세요. 이제 이전보다 더 정확하고 유용한 일을 할 수 있을까요? 어쩌면 맞을 수도 있고 그렇지 않을 수도 있습니다. 그러나 가장 중요한 것은 단순히 누군가가 “우리에게는 블록체인이 절실히 필요합니다! 방금 비행기에서 잡지에서 그에 대한 기사를 읽었습니다!” 진지하게? 재미도 없습니다.

신화적인 “데브옵스 엔지니어”

올렉 : 이제 모두가 데브옵스를 구현하고 있습니다. 누군가 인터넷에서 데브옵스에 관해 읽고 있는데, 내일 채용 사이트에 또 다른 공석이 나타납니다. "데브옵스 엔지니어". 여기에 여러분의 관심을 끌고 싶습니다. "데브옵스 엔지니어"라는 용어가 생명권을 가지고 있다고 생각하십니까? 데브옵스는 하나의 문화라는 의견이 있는데 여기에는 뭔가 맞지 않습니다.

팀: 그저 그래. 그런 다음 즉시 이 용어에 대해 설명하게 하십시오. 독특하게 만드는 것. 이런 공석 뒤에 어떤 독특한 기술 조합이 있다는 것이 증명될 때까지 나는 그것을 사지 않을 것입니다! 내 말은, 우리에게는 "데브옵스 엔지니어"라는 직함이 있는데, 흥미로운 직함입니다. 네, 다음은 무엇입니까? 직위는 일반적으로 매우 흥미로운 것입니다. "개발자"라고 합시다. 어쨌든 그것은 무엇입니까? 다른 조직은 완전히 다른 것을 의미합니다. 일부 회사에서는 수준 높은 프로그래머가 다른 회사의 전문 전문 테스터가 작성한 테스트보다 더 의미 있는 테스트를 작성합니다. 그렇다면 그들은 이제 프로그래머인가, 테스터인가?

예, 우리에게는 직함이 있습니다. 하지만 질문을 충분히 길게 하면 결국 우리 모두가 문제 해결자라는 것이 밝혀집니다. 우리는 솔루션을 추구하는 사람들이며 일부는 기술적 능력을 갖고 있고 일부는 다른 기술을 가지고 있습니다. DevOps가 침투한 환경에 살고 있다면 개발과 관리의 통합에 참여하고 있으며 이 활동에는 상당히 중요한 목적이 있습니다. 그러나 당신이 정확히 무엇을 하고 무엇에 대한 책임이 있는지 묻는다면, 사람들은 아주 옛날부터 이 모든 일을 해왔다는 것이 밝혀집니다. "나는 아키텍처를 담당하고 있습니다.", "나는 데이터베이스를 담당하고 있습니다." 등 무엇을 보더라도 이 모든 것은 "devops" 이전에 있었습니다.

누군가 나에게 직위를 말하면 나는 별로 듣지 않는다. 그가 실제로 책임이 있는 것이 무엇인지 말해 주는 것이 더 낫습니다. 그러면 우리가 문제를 훨씬 더 잘 이해할 수 있을 것입니다. 내가 가장 좋아하는 예는 어떤 사람이 "프로젝트 관리자"라고 주장하는 경우입니다. 무엇? 아무 의미도 없어요. 아직도 당신이 무슨 일을 하는지 모르겠어요. 프로젝트 관리자는 개발자, XNUMX명으로 구성된 팀의 리더, 코드 작성, 작업 수행, 팀 리더가 되어 사람들이 스스로 리더로 인정하는 사람이 될 수 있습니다. 또한 프로젝트 관리자는 프로젝트에서 XNUMX명을 관리하고 다른 관리자를 관리하며 일정 작성 및 예산 계획을 담당하는 관리자가 될 수 있습니다. 이것은 완전히 다른 두 세계입니다! 하지만 그들의 직함은 똑같아 보입니다.

이것을 조금 다르게 바꿔보겠습니다. 당신이 정말 잘하는 것이 무엇인지, 경험이 많은지, 재능이 있는지? 당신이 그 일을 처리할 수 있다고 생각하기 때문에 당신은 무엇을 책임질 것인가? 그리고 여기서 누군가는 즉시 거부하기 시작할 것입니다. 아니요, 아니요, 아니요, 저는 프로젝트 리소스를 전혀 다루고 싶지 않습니다. 그것은 내 사업이 아닙니다. 저는 기술적인 친구이고 유용성과 사용자 인터페이스를 이해합니다. 사람들의 군대를 전혀 관리하고 싶다면 일하러가는 것이 좋을 것입니다.

그런데 저는 이런 종류의 기술 분리가 잘 작동하는 접근 방식을 강력히 지지합니다. 기술자가 원하는 만큼 경력을 쌓을 수 있는 곳입니다. 하지만 여전히 기술 전문가들이 불평하는 조직을 봅니다. 프로젝트 관리가 이 회사의 유일한 방법이기 때문에 프로젝트 관리에 들어가야 합니다. 때로는 이것이 끔찍한 결과를 낳기도 합니다. 최고의 기술자는 결코 좋은 관리자가 아니며, 최고의 관리자는 기술을 다룰 수 없습니다. 이것에 대해 솔직해지자.

지금은 이에 대한 수요가 많다고 봅니다. 당신이 기술 전문가라면 회사에서 도움을 줄 수 있지만, 기술이 계속 변하고 이에 맞춰 자신을 재창조해야 하기 때문에 필요 여부와 상관없이 자신만의 진로를 찾아야 합니다! 불과 XNUMX년 안에 기술은 적어도 XNUMX번은 바뀔 수 있습니다. 기술이 참 이상하네요...

"모든 것에 대한 전문가"

마이클 : 사람들은 이러한 기술 변화의 속도에 어떻게 대처할 수 있습니까? 복잡성이 증가하고 그 수가 증가하며 사람들 간의 의사소통의 총량도 증가하고 있으며 "모든 분야의 전문가"가 될 수 없다는 것이 밝혀졌습니다.

팀: 오른쪽! 기술 분야에서 일한다면, 확실히 구체적인 것을 선택하고 그것에 대해 탐구해야 합니다. 조직에서 유용하다고 생각하는 일부 기술(그리고 실제로 유용할 수도 있음) 그리고 당신이 그것에 더 이상 관심이 없다면 – 나는 내가 이렇게 말할 것이라고 결코 믿지 않았을 것입니다 – 아마도 당신은 기술이 더 흥미롭거나 연구하기에 더 편리한 다른 조직으로 이동해야 할 것입니다.

그러나 일반적으로 그렇습니다. 당신 말이 맞습니다. 기술은 한꺼번에 모든 방향으로 성장하고 있는데, “나는 존재하는 모든 기술의 전문 기술자다”라고 말할 수 있는 사람은 아무도 없습니다. 반면, 말 그대로 기술 지식을 흡수하고 그것에 열광하는 스펀지 피플이 있습니다. 저는 그런 사람들을 몇 명 보았는데, 그들은 말 그대로 숨을 쉬며 살아가고 있습니다. 그들과 대화하는 것은 유용하고 흥미로웠습니다. 그들은 조직 내부에서 무슨 일이 일어나고 있는지 연구할 뿐만 아니라 일반적으로 그것에 대해 이야기합니다. 그들은 또한 정말 멋진 기술자이며 매우 의식적이고 목적이 있습니다. 그들은 그들의 주요 직업이 무엇인지에 관계없이 파도의 꼭대기에 머물려고 노력합니다. 왜냐하면 그들의 열정은 기술의 움직임, 기술의 진흥이기 때문입니다. 갑자기 그런 사람을 만난다면 그 사람과 함께 점심을 먹으며 점심을 먹으면서 여러 가지 멋진 이야기를 나누는 것이 좋습니다. 어떤 조직이든 그런 사람이 최소한 두 명은 필요하다고 생각합니다.

위험과 불확실성

마이클 : 존경하는 엔지니어 여러분, 그렇습니다. 시간이 있을 때 위험 관리에 대해 다루겠습니다. 우리는 오류가 심각한 결과를 초래할 수 있는 의료 소프트웨어에 대한 논의로 이번 인터뷰를 시작했습니다. 그런 다음 오류로 인해 수백만 달러의 비용이 들고 어쩌면 여러 사람의 생명이 희생될 수도 있는 달 프로그램에 대해 이야기했습니다. 하지만 이제 업계에서는 사람들이 위험에 대해 생각하지 않고, 예측하려고 하지 않고, 관찰조차 하지 않는 정반대의 움직임을 봅니다.

올렉 : 빠르게 움직이고 물건을 부수세요!

마이클 : 예, 빠르게 움직이고, 뭔가를 부수고, 점점 더 많은 것을 깨뜨릴 때까지 무언가로 인해 죽을 것입니다. 귀하의 관점에서 볼 때 일반 개발자는 현재 위험 관리 학습에 어떻게 접근해야 합니까?

팀: 여기서 위험과 불확실성이라는 두 가지 사이에 선을 그어 보겠습니다. 이것들은 다른 것입니다. 불확실성은 특정 시점에 확실한 답을 얻기에 충분한 데이터가 없을 때 발생합니다. 예를 들어, 프로젝트의 아주 초기 단계에서 누군가가 “작업을 언제 끝낼 예정입니까?”라고 묻는다면 상당히 정직한 사람이라면 “모르겠어요”라고 대답할 것입니다. 당신은 모르셔도 괜찮습니다. 당신은 아직 문제를 연구하지 않았고 팀에 대해 잘 알지 못하며 그들의 기술도 모릅니다. 이것은 불확실성입니다.

위험은 잠재적인 문제가 이미 식별되었을 때 발생합니다. 이런 일이 일어날 수 있습니다. 확률은 XNUMX보다 크고 XNUMX% 미만입니다. 이로 인해 지연과 불필요한 작업은 물론 프로젝트에 치명적인 결과까지 모든 일이 발생할 수 있습니다. 결과는, 얘들아, 우산을 접고 해변을 떠나자, 우리는 결코 끝내지 못할 것이고 모든 것이 끝났다고 말할 때이다. 우리는 이것이 작동할 것이라고 가정했지만 전혀 작동하지 않습니다. 이제 멈출 시간입니다. 이것이 상황입니다.

종종 문제는 이미 나타났을 때, 문제가 지금 당장 발생하고 있을 때 해결하기 가장 쉽습니다. 그러나 문제가 바로 눈앞에 있다면 위험 관리를 하는 것이 아니라 문제 해결, 위기 관리를 하는 것입니다. 수석 개발자 또는 관리자라면 지연, 시간 낭비, 불필요한 비용 또는 전체 프로젝트의 붕괴로 이어질 수 있는 일이 무엇인지 궁금할 것입니다. 무엇이 우리를 멈추고 다시 시작하게 만들까요? 이 모든 것이 효과가 있을 때, 우리는 그것들로 무엇을 할 것인가? 대부분의 상황에 유효한 간단한 대답이 있습니다. 위험으로부터 도망치지 말고 노력하십시오. 위험한 상황을 해결하고, 상황을 완전히 없애고, 문제를 다른 것으로 바꾸는 방법을 알아보세요. 이렇게 말하는 대신, 문제가 발생하면 문제를 해결하겠습니다.

불확실성과 위험은 귀하가 다루는 모든 것의 최전선에 있어야 합니다. 프로젝트 계획을 세우고 특정한 중요한 위험을 미리 살펴보고 다음과 같이 말할 수 있습니다. 이 문제 중 하나라도 잘못되면 다른 것은 문제가 되지 않기 때문에 지금 처리해야 합니다. 저녁 식사를 요리할 수 있는지 확실하지 않은 경우 테이블 위 식탁보의 아름다움에 대해 걱정할 필요가 없습니다. 먼저 맛있는 저녁 식사를 준비하는 데 따른 모든 위험을 식별하고 처리한 다음 실제 위협이 되지 않는 다른 모든 사항에 대해 생각해야 합니다.

다시 말하지만, 귀하의 프로젝트를 독특하게 만드는 것은 무엇입니까? 무엇이 우리 프로젝트를 방해할 수 있는지 살펴보겠습니다. 이런 일이 일어날 가능성을 최소화하려면 어떻게 해야 합니까? 일반적으로 그들을 100% 무력화하고 명확한 양심을 가지고 다음과 같이 선언할 수는 없습니다. "그렇습니다. 더 이상 문제가 되지 않습니다. 위험은 해결되었습니다!" 나에게 이것은 성인 행동의 표시입니다. 이것이 어린이와 성인의 차이입니다. 어린이는 자신이 불멸의 존재이고 아무것도 잘못될 수 없으며 모든 것이 잘될 것이라고 생각합니다! 동시에 어른들은 세 살짜리 아이들이 놀이터에서 점프하는 모습을 지켜보고 눈으로 움직임을 따라 가며 스스로에게 "우-우, 우-우"라고 말합니다. 나는 근처에 서서 아이가 넘어지면 잡을 준비를 합니다.

반면에 내가 이 사업을 그토록 좋아하는 이유는 위험하기 때문이다. 우리는 일을 하는데, 그런 일은 위험합니다. 성인의 접근이 필요합니다. 열정만으로는 문제가 해결되지 않습니다!

성인 공학적 사고

마이클 : 아이들의 모범은 좋습니다. 내가 평범한 엔지니어라면 어린아이가 되어 기쁘다. 하지만 좀 더 어른스러운 사고 방식으로 나아가려면 어떻게 해야 할까요?

팀: 초보자나 기존 개발자 모두에게 똑같이 잘 작동하는 아이디어 중 하나는 컨텍스트의 개념입니다. 우리가 하고 있는 일, 달성할 목표. 이 프로젝트에서 정말 중요한 것은 무엇인가요? 이 프로젝트에 참여하는 사람이 누구인지는 중요하지 않습니다. 인턴이건 수석 설계자이건 모두에게 맥락이 필요합니다. 우리는 모든 사람이 자신의 작품보다 더 큰 규모로 생각하도록 해야 합니다. "나는 내 작품을 만들고 내 작품이 작동하는 한 행복합니다." 아니, 또 아니지. 사람들에게 자신이 일하는 환경을 상기시키는 것은 항상 (무례하지 않게!) 가치가 있습니다. 우리 모두가 함께 달성하려고 하는 것. 프로젝트의 모든 것이 괜찮다면 어린이가 될 수 있다는 생각 - 제발 그렇게 하지 마세요. 결승선을 조금이라도 통과한다면 우리는 함께 통과할 뿐입니다. 당신은 혼자가 아닙니다. 우리는 모두 함께 있습니다. 나이가 많든 적든 프로젝트에 참여한 모든 사람들이 프로젝트에서 정확히 무엇이 중요한지, 우리 모두가 달성하려는 목표에 회사가 돈을 투자하는 이유에 대해 이야기하기 시작한다면... 대부분의 사람들은 훨씬 기분이 좋아질 것입니다. 그들의 작업이 다른 모든 사람의 작업과 어떻게 연관되는지 알게 될 것입니다. 한편으로 나는 개인적으로 책임이 있는 작품을 이해합니다. 하지만 일을 끝내려면 다른 사람들도 모두 필요합니다. 정말로 끝났다고 생각한다면, 우리는 항상 프로젝트에서 할 일이 있습니다!

올렉 : 상대적으로 말하자면, 칸반에 따라 작업하는 경우 일부 테스트의 병목 현상에 직면하면 그곳에서 수행하던 작업(예: 프로그래밍)을 중단하고 테스터를 도와줄 수 있습니다.

팀: 정확히. 내 생각에 최고의 기술자들은 자세히 살펴보면 일종의 관리자인 것 같습니다. 이것을 어떻게 공식화할 수 있을까요?

올렉 : 당신의 삶은 당신이 관리하는 프로젝트입니다.

팀: 정확히! 내 말은, 당신은 책임을 지고, 문제를 이해하고, 당신의 결정이 사람들의 업무에 영향을 미칠 수 있다는 것을 알게 되면 사람들과 접촉하게 된다는 것입니다. 단지 책상에 앉아 일을 하면서 주변에서 무슨 일이 일어나고 있는지조차 깨닫지 못하는 것이 아닙니다. 아니, 아니. 그런데 Agile의 가장 좋은 점 중 하나는 짧은 스프린트를 제안했다는 것입니다. 이렇게 하면 모든 참가자의 상황을 명확하게 관찰할 수 있고 모든 것을 함께 볼 수 있기 때문입니다. 우리는 매일 서로에 대해 이야기합니다.

위험 관리에 참여하는 방법

올렉 : 이 분야에 공식적인 지식 구조가 있습니까? 예를 들어, 저는 Java 개발자이고 교육을 통해 실제 프로젝트 관리자가 되지 않고도 위험 관리를 이해하고 싶습니다. 아마도 McConnell의 "소프트웨어 프로젝트 비용은 얼마입니까?"를 먼저 읽은 다음 무엇을 읽을 것입니까? 첫 번째 단계는 무엇입니까?

팀: 첫 번째는 프로젝트에 참여하는 사람들과 소통을 시작하는 것입니다. 이를 통해 동료와의 의사소통 문화가 즉각적으로 개선됩니다. 기본적으로 모든 것을 숨기지 말고 열어야 합니다. 말해보세요: 이것들은 나를 괴롭히는 것들입니다. 이것들은 나를 밤에 잠 못 이루는 것들입니다. 나는 오늘 밤에 잠에서 깨어 이렇게 말했습니다: 맙소사, 이것에 대해 생각해야 해요! 다른 사람들도 같은 것을 보나요? 그룹으로서 우리는 이러한 잠재적인 문제에 대응해야 합니까? 이러한 주제에 대한 토론을 지원할 수 있어야 합니다. 우리가 일하는 데 있어서 미리 준비된 공식은 없습니다. 햄버거를 만드는 것이 아니라 사람이 중요합니다. “치즈버거를 만들고, 치즈버거를 팔아요”는 우리의 일이 아니기 때문에 저는 이 일을 그토록 좋아합니다. 감독님이 하던 일이 이제는 팀의 소유가 되는 게 좋아요.

올렉 : 당신은 책과 인터뷰에서 사람들이 그래프의 숫자보다 행복에 더 관심을 갖는 것에 대해 이야기했습니다. 반면에, 팀에 우리는 데브옵스(devops)로 전환하고 있으며 이제 프로그래머는 지속적으로 의사소통해야 한다고 말하면 이는 그의 안전 영역에서 훨씬 벗어날 수 있습니다. 그리고 지금 이 순간 그는 몹시 불행할 수도 있습니다. 이 상황에서는 어떻게 해야 할까요?

팀: 정확히 무엇을 해야할지 모르겠습니다. 개발자가 너무 고립되어 있으면 애초에 작업이 수행되는 이유를 알지 못하고 작업에서 자신의 부분만 살펴보며 소위 "컨텍스트"에 들어가야 합니다. 그는 모든 것이 어떻게 연결되어 있는지 알아내야 합니다. 물론 공식적인 발표나 그와 유사한 것을 의미하는 것은 아닙니다. 나는 당신이 담당하는 부분뿐만 아니라 작업 전체에 대해 동료와 소통해야한다는 사실에 대해 이야기하고 있습니다. 여기에서 아이디어, 작업을 서로 잘 조화시키기 위한 공통 합의, 공통 문제를 함께 해결하는 방법에 대해 논의할 수 있습니다.

적응을 돕기 위해 그들은 종종 기술 전문가를 교육에 파견하고 교육에 대해 논의합니다. 내 친구는 훈련은 개를 위한 것이라고 말하기를 좋아합니다. 사람들을 위한 훈련이 있습니다. 개발자로서 학습할 때 가장 좋은 점 중 하나는 동료와 상호 작용하는 것입니다. 누군가가 어떤 일을 정말 잘한다면, 그 사람이 일하는 것을 지켜보거나 그 사람의 일이나 어떤 것에 대해 이야기해야 합니다. 일부 전통적인 Kent Beck은 익스트림 프로그래밍에 대해 끊임없이 이야기했습니다. XP는 매우 간단한 아이디어이지만 너무 많은 문제를 야기하기 때문에 재미있습니다. 어떤 사람들에게 XP를 하는 것은 친구들 앞에서 옷을 벗도록 강요받는 것과 같습니다. 그들은 내가 무엇을 하는지 보게 될 것이다! 그들은 내 동료입니다. 그들은 볼 뿐만 아니라 이해할 것입니다! 끔찍한! 어떤 사람들은 심각하게 긴장하기 시작했습니다. 그러나 이것이 학습을 위한 궁극적인 방법이라는 것을 깨닫는다면 모든 것이 달라집니다. 당신은 사람들과 긴밀하게 협력하며 어떤 사람들은 당신보다 주제를 훨씬 더 잘 이해합니다.

마이클 : 하지만 이 모든 것이 당신을 안전지대에서 벗어나게 만듭니다. 엔지니어로서 당신은 자신의 안전지대에서 벗어나 소통해야 합니다. 문제 해결자로서 당신은 끊임없이 자신을 약한 위치에 놓고 무엇이 잘못될 수 있는지 생각해야 합니다. 이러한 유형의 작업은 본질적으로 성가신 작업으로 설계되었습니다. 당신은 의식적으로 스트레스가 많은 상황에 처하게 됩니다. 보통 사람들은 그들에게서 도망치고, 사람들은 행복한 어린이가 되기를 좋아합니다.

팀: 할 수 있는 일은 나와서 공개적으로 다음과 같이 말할 수 있습니다. “모든 것이 괜찮습니다. 내가 처리할 수 있습니다! 나만 불편한 게 아니다. 여러 가지 불편한 점을 팀 단위로 함께 논의해 봅시다!” 이것은 우리의 공통된 문제이므로 해결해야 합니다. 개성 넘치는 천재 개발자들은 매머드 같아서 사라진 것 같아요. 그리고 그 중요성은 매우 제한적입니다. 소통이 안 되면 제대로 참여할 수 없어요. 그러므로 그냥 말하십시오. 정직하고 개방적이어야 합니다. 이것이 누군가에게 불쾌감을 주어서 매우 죄송합니다. 수년 전에 미국의 주요 두려움이 죽음이 아니라는 연구 결과가 있었다는 것을 상상할 수 있습니까? 대중 연설에 대한 두려움! 큰 소리로 칭찬을 하느니 차라리 죽고 싶은 사람이 어딘가 있다는 뜻이다. 그리고 무슨 일을 하느냐에 따라 어느 정도 기본적인 능력만 갖추면 충분하다고 생각해요. 말하기 능력, 쓰기 능력 - 하지만 업무에 실제로 필요한 만큼만 사용하세요. 분석가로 일하지만 읽고, 쓰고, 말할 수 없다면 안타깝게도 내 프로젝트에서 할 일이 없습니다!

의사소통의 대가

올렉 : 이렇게 퇴임하는 직원을 고용하는 것은 여러 가지 이유로 더 많은 비용이 들지 않습니까? 결국 그들은 일하는 대신 끊임없이 채팅을 하고 있는 것입니다!

팀: 나는 모든 사람뿐만 아니라 팀의 핵심을 의미했습니다. 데이터베이스 튜닝을 정말 잘하고, 데이터베이스 튜닝을 좋아하며, 남은 생애 동안 데이터베이스 튜닝을 계속할 사람이 있다면 그걸로 충분합니다. 계속 유지하세요. 그러나 나는 프로젝트 자체에 살고 싶어하는 사람들에 대해 이야기하고 있습니다. 프로젝트 개발을 목표로 하는 팀의 핵심입니다. 이 사람들은 정말 끊임없이 서로 소통해야 합니다. 특히 프로젝트 초기에 위험, 글로벌 목표 달성 방법 등에 대해 논의할 때는 더욱 그렇습니다.

마이클 : 이는 전문 분야, 기술 또는 작업 방식에 관계없이 프로젝트에 참여하는 모든 사람에게 적용됩니다. 여러분 모두는 프로젝트의 성공에 관심이 있습니다.

팀: 예, 당신은 프로젝트에 충분히 몰입했다고 느끼며, 당신의 임무는 프로젝트가 실현되도록 돕는 것입니다. 당신이 프로그래머, 분석가, 인터페이스 디자이너 등 누구든지 상관없습니다. 이것이 제가 매일 아침 출근하는 이유이고 우리가 하는 일입니다. 우리는 그들의 기술에 관계없이 이 모든 사람들에 대한 책임이 있습니다. 어른들이 대화를 나누는 그룹입니다.

올렉 : 사실, 수다스러운 직원들에 관해 말하면서 저는 사람들, 특히 데브옵스로 전환하라는 요청을 받은 관리자들의 완전히 새로운 비전에 대한 반대를 시뮬레이션하려고 노력했습니다. 그리고 컨설턴트인 당신은 개발자인 나보다 이러한 반대 의견을 훨씬 더 잘 알고 있어야 합니다! 관리자가 가장 걱정하는 것이 무엇인지 공유해 주세요.

팀: 관리자? 흠. 대부분의 경우 관리자는 문제로 인해 압력을 받고 긴급하게 무언가를 출시하고 배송해야 하는 등의 상황에 직면합니다. 그들은 우리가 무언가에 대해 끊임없이 토론하고 논쟁하는 방식을 지켜보고 다음과 같이 봅니다. 대화, 대화, 대화... 또 어떤 대화가 있습니까? 다시 일하세요! 그들에게는 말하는 것이 일처럼 느껴지지 않기 때문입니다. 당신은 코드를 작성하지도 않고, 소프트웨어를 테스트하지도 않고, 아무것도 하지 않는 것 같습니다. 당신에게 뭔가를 하라고 보내는 게 어떨까요? 그러고보니 배송이 벌써 한 달 앞으로 다가왔습니다!

마이클 : 가서 코드를 작성해 보세요!

팀: 그들은 일에 대해 걱정하는 것이 아니라 진행 상황에 대한 가시성이 부족한 것 같습니다. 성공에 가까워진 것처럼 보이게 하려면 키보드의 버튼을 누르는 모습을 보여줘야 합니다. 아침부터 저녁까지 하루 종일. 이것이 첫 번째 문제입니다.

올렉 : 미샤, 당신은 뭔가 생각하고 있어요.

마이클 : 죄송합니다. 생각에 빠져 회상 장면을 포착했습니다. 이 모든 것이 어제 있었던 흥미로운 집회를 생각나게 했습니다... 어제 집회가 너무 많았습니다... 그리고 이 모든 것이 매우 친숙하게 들립니다!

월급없는 삶

팀: 그건 그렇고, 의사 소통을 위해 "집회"를 조직하는 것은 전혀 필요하지 않습니다. 내 말은, 개발자들 사이에서 가장 유용한 토론은 그들이 서로 대화할 때 일어난다는 것입니다. 아침에 커피 한 잔을 들고 들어오면 다섯 명의 사람들이 모여서 기술적인 것에 대해 격렬하게 토론하고 있습니다. 제가 이 프로젝트의 관리자라면 그냥 웃으면서 내 사업에 관해 어딘가에 가서 논의하도록 하는 것이 낫습니다. 그들은 이미 가능한 한 많이 참여하고 있습니다. 이것은 좋은 징조입니다.

올렉 : 그건 그렇고, 당신의 책에는 무엇이 좋고 무엇이 나쁜지에 대한 많은 메모가 있습니다. 당신은 그들 중 하나를 직접 사용합니까? 상대적으로 말하자면, 이제 회사는 매우 특이한 방식으로 구조화되어 있습니다.

팀: 정통적이지는 않지만 이 장치는 우리에게 완벽하게 어울립니다. 우리는 오랫동안 서로를 알고 있습니다. 우리는 서로를 믿고, 파트너가 되기 전에도 서로를 많이 믿었습니다. 예를 들어, 우리는 급여가 전혀 없습니다. 우리는 일만 하고 있습니다. 예를 들어 고객으로부터 돈을 벌면 모든 돈이 나에게 돌아갑니다. 그 후 우리는 조직에 회비를 지불하는데, 이는 회사 자체를 지원하기에 충분합니다. 게다가, 우리는 모두 다른 일을 전문으로 합니다. 예를 들어, 나는 회계사와 함께 일하고, 세금 신고서를 작성하고, 회사를 위해 모든 종류의 행정 업무를 수행하지만 아무도 나에게 비용을 지불하지 않습니다. James와 Tom은 우리 웹사이트에서 일하며 아무도 그들에게 돈을 지불하지 않습니다. 당신이 회비를 지불하는 한, 누구도 당신이 무엇을 해야 하는지 말해 줄 생각을 하지 않을 것입니다. 예를 들어, Tom은 이제 예전보다 일을 훨씬 적게 합니다. 이제 그는 다른 관심사를 갖고 있으며 길드를 위해서가 아닌 일도 하고 있습니다. 하지만 그가 회비를 지불하는 한, 아무도 그에게 다가와서 "안녕, 톰, 일하러 가세요!"라고 말하지 않을 것입니다. 당신 사이에 돈이 없을 때 동료를 대하는 것은 매우 쉽습니다. 그리고 이제 우리의 관계는 다양한 전문 분야와 관련된 기본 아이디어 중 하나입니다. 그것은 작동하고 아주 잘 작동합니다.

최고의 조언

마이클 : "최고의 조언"으로 돌아가서, 고객에게 계속해서 말하는 것이 있나요? 80/20에 대한 아이디어가 있으며 일부 조언은 아마도 더 자주 반복될 것입니다.

팀: 곰과 함께 왈츠를 춘다 같은 책을 쓰면 역사의 흐름이 바뀌고 사람들이 멈출 것이라고 생각한 적이 있습니다. 그런데... 글쎄요, 회사들은 종종 모든 것이 괜찮은 척합니다. 나쁜 일이 일어나자마자 그것은 그들에게 충격이고 놀라움이다. “보세요, 우리가 시스템을 테스트했는데 어떤 시스템 테스트도 통과하지 못했습니다. 또 XNUMX개월 동안 예정에 없던 작업이 계속되는데 어떻게 이런 일이 일어날 수 있겠습니까? 누가 알았 겠어? 무엇이 잘못될 수 있나요? 진심으로, 당신은 이것을 믿습니까?

현재 상황에 너무 화를 내지 말아야 한다는 점을 설명하려고 합니다. 우리는 문제에 대해 이야기하고, 무엇이 잘못되었을 수 있는지, 그리고 앞으로 그러한 일이 발생하지 않도록 방지하는 방법을 실제로 이해해야 합니다. 문제가 나타나면 어떻게 대처하고, 어떻게 억제할 것인가?

나에게는 이 모든 것이 무섭게 보인다. 사람들은 복잡하고 짜증나는 문제를 다루면서 단지 최선을 다해 최선을 다하면 실제로 "최고"가 일어날 것처럼 가장합니다. 아니요, 그런 식으로는 작동하지 않습니다.

위험관리를 실천해보세요!

마이클 : 귀하는 리스크 관리에 참여하는 조직이 몇 개나 된다고 생각하시나요?

팀: 나를 화나게 하는 것은 사람들이 단순히 위험을 적어두고 결과 목록을 보고 일하러 간다는 것입니다. 실제로 위험을 식별하는 것이 위험 관리입니다. 하지만 나에게는 이것이 질문할 이유처럼 들립니다. 좋습니다. 목록이 있습니다. 정확히 무엇을 바꾸시겠습니까? 이러한 위험을 고려하여 표준 작업 순서를 변경해야 합니다. 작업에서 가장 어려운 부분이 있으면 이를 해결한 다음 더 간단한 작업으로 넘어가야 합니다. 첫 번째 스프린트에서는 복잡한 문제 해결을 시작하세요. 이것은 이미 위험 관리처럼 보입니다. 그러나 일반적으로 사람들은 위험 목록을 작성한 후 무엇을 변경했는지 말할 수 없습니다.

마이클 : 그런데 이들 회사 중 위험 관리에 관여하는 회사는 XNUMX%입니까?

팀: 안타깝게도 이런 말을 하기는 싫지만 이는 아주 사소한 부분이다. 하지만 25개 이상이면 정말 큰 프로젝트가 있고 적어도 뭔가를 하지 않으면 존재할 수 없기 때문입니다. 그냥 XNUMX%만 넘으면 정말 놀랄 것 같아요. 소규모 프로젝트는 일반적으로 이러한 질문에 다음과 같이 대답합니다. 문제가 우리에게 영향을 미치면 우리는 이를 해결할 것입니다. 그런 다음 그들은 성공적으로 문제를 해결하고 문제 관리 및 위기 관리에 참여합니다. 문제를 해결하려고 노력했지만 문제가 해결되지 않으면 위기 관리에 오신 것을 환영합니다.

네, “문제가 생기면 해결해 드리겠습니다.”라는 말을 자주 듣습니다. 물론이죠? 우리가 정말 결정할까요?

올렉 : 순진하게 프로젝트 헌장에 중요한 불변 사항을 작성하고, 불변 사항이 깨지면 프로젝트를 다시 시작하면 됩니다. 그것은 매우 엉뚱한 것으로 밝혀졌습니다.

마이클 : 예, 위험이 촉발되었을 때 프로젝트가 단순히 재정의되는 일이 일어났습니다. 좋아요, 빙고, 문제가 해결되었습니다. 더 이상 걱정하지 마세요!

팀: 리셋버튼을 눌러보자! 아니요, 그런 식으로는 작동하지 않습니다.

DevOops 2019 기조연설

마이클 : 이번 인터뷰의 마지막 질문에 이르렀습니다. 기조연설로 다음 DevOops에 오실 예정인데, 말씀하실 내용에 대한 비밀의 막을 열어주실 수 있나요?

팀: 현재 그들 중 XNUMX명은 조직의 무언의 규칙인 업무 문화에 관한 책을 집필하고 있습니다. 문화는 조직의 핵심가치에 의해 결정됩니다. 일반적으로 사람들은 이를 눈치채지 못하지만 수년 동안 컨설팅 분야에서 일하면서 우리는 이를 알아차리는 데 익숙합니다. 당신은 회사에 들어가고 말 그대로 몇 분 안에 무슨 일이 일어나고 있는지 느끼기 시작합니다. 우리는 이것을 '맛'이라고 부릅니다. 어떨 때는 이 향이 정말 좋기도 하고 어떨 때는 아, 아차. 조직마다 상황이 매우 다릅니다.

마이클 : 나도 수년 동안 컨설팅 분야에서 일해 왔으며 당신이 말하는 내용을 잘 이해합니다.

팀: 사실 기조연설에서 이야기할 가치가 있는 것 중 하나는 모든 것이 회사에 의해 결정되는 것은 아니라는 점이다. 귀하와 귀하의 팀은 커뮤니티로서 고유한 팀 문화를 가지고 있습니다. 이는 회사 전체일 수도 있고 별도의 부서, 별도의 팀일 수도 있습니다. 하지만 말씀하시기 전에, 여기에 우리가 믿는 것이 있고 중요한 것이 있습니다... 특정 행동 뒤에 숨은 가치와 신념이 이해되기 전에는 문화를 바꿀 수 없습니다. 행동은 관찰하기 쉽지만 신념을 찾는 것은 어렵습니다. DevOps는 상황이 점점 더 복잡해지고 있음을 보여주는 훌륭한 예일 뿐입니다. 상호 작용은 점점 더 복잡해지고 전혀 깨끗해지거나 명확해지지 않으므로 자신이 믿는 것과 주변 사람들이 침묵하는 것에 대해 생각해야 합니다.

빠른 결과를 얻고 싶다면 여기에 좋은 주제가 있습니다. 아무도 "모르겠어요"라고 말하지 않는 회사를 본 적이 있습니까? 그가 뭔가를 모른다고 인정할 때까지 말 그대로 사람을 고문하는 곳이 있습니다. 모두가 모든 것을 알고 있으며, 모두가 믿을 수 없을만큼 박식합니다. 어떤 사람에게든 접근하면 그 사람은 즉시 질문에 답해야 합니다. “모르겠어요”라고 말하는 대신. 만세, 그들은 많은 박식한 사람들을 고용했습니다! 그리고 일부 문화권에서는 "모르겠어요"라고 말하는 것이 일반적으로 매우 위험하며, 이는 약함의 표시로 인식될 수 있습니다. 반대로 누구나 “모른다”고 말할 수 있는 조직도 있다. 그것은 완전히 합법적이며, 누군가가 질문에 대해 엉뚱한 대답을 하기 시작하면 "무슨 말을 하는지 모르시나요?"라고 대답하는 것이 완전히 정상입니다. 그리고 그것을 모두 농담으로 바꾸십시오.

이상적으로는 끊임없이 행복할 수 있는 직업을 갖고 싶습니다. 쉽지 않을 거예요. 매일이 맑고 쾌적하지는 않고, 때로는 열심히 일해야 할 때도 있지만, 재고를 조사하기 시작하면 다음과 같은 결과가 나올 것입니다. 와, 이곳은 정말 멋진 곳입니다. 여기서 일하는 것이 기분이 좋습니다. 감정적으로나 지적으로나. 그리고 컨설턴트로 갔다가 XNUMX개월 동안 참지 못하고 겁에 질려 도망갈 것이라는 사실을 즉시 깨닫는 회사도 있습니다. 이것이 제가 보고서에서 이야기하고 싶은 것입니다.

Tim Lister가 기조 연설을 가지고 도착할 예정입니다. "인물, 공동체, 문화: 번영의 중요한 요소"2019년 29월 30~2019일 상트페테르부르크에서 열리는 DevOops XNUMX 컨퍼런스에 참석하세요. 티켓을 구매하실 수 있습니다 공식 웹 사이트. DevOops에서 여러분을 기다리고 있습니다!

출처 : habr.com