융통성없는 프로그래머 다루기

때때로 프로젝트에서 오랫동안 일하는 프로그래머는 융통성이 없어서 추론하기가 어려워집니다. 우리가 그들을 설득하더라도, 그들은 우리의 제안을 이행하지 않을 수 있습니다.

예를 들어 최근에 빌드 및 릴리스 프로세스가 너무 복잡하고 불필요한로드 블록이있는 프로젝트에 참여했습니다.

결함 관리 및 버전 제어 도구를 통합하여 개발 스프레드 시트 (예 : 스프레드 시트 몇 개 작성)를 제거 할 것을 제안했습니다 (둘 다 IBM-Rational 도구이므로 통합은 매우 쉬운 일회성 노력 임). 또한 Maven & Ant (프로젝트에 Java 및 일부 COTS 제품이 포함됨)와 같은 도구를 사용하면 빌드 및 릴리스를 단순화하여 수동 오류 및 개입을 줄일 수 있습니다.

나는 다른 사람들을 설득하고 개념 증명을 개발하기 위해 노력할 준비가되었습니다. 그러나 '시니어'개발자는 현재 프로세스로 인해 더 가치가 있기 때문에 기꺼이하지 않습니다.

팀에서 마찰을 일으키지 않고이 상황을 어떻게 처리합니까?

귀하는 새로운 팀원이며 팀 운영 방식의 일부 기본 측면을 변경하려고합니다. 행운을 빈다, 나는 당신의 미래에 행복한 팀을 느낀다.

몇 가지 실용적인 조언 :

팀에게 자신을 증명하십시오. 기술 및 안정성 측면에서이 작업을 수행해야합니다. 사람들이 당신을 따르기를 원한다면, 그렇게 할 이유를 제공해야합니다.

방법론의 역사를 이해하십시오. 왜 존재합니까? 당시 어떤 문제가 해결 되었습니까? 솔루션이 실제로 팀에게 도움이되는지 확인하십시오. 변경 사항이 더 좋을 수도 있지만 실제로 팀의 문제를 해결하지 못할 수도 있습니다.

장애물에 대해 알아보십시오. 저항의 이유를 찾아 그 항목에 대해 작업하십시오.

변화의 에이전트 가 되려면 성공적인 변화의 에이전트가되는 방법을 배우십시오 . 여기서 얻을 수있는 것보다 훨씬 많은 정보를 제공 할 수있는 수십 권의 책과 기타 자료가 있습니다.

그리고 네, 행운이 있기를 바랍니다. 그러나 당신의 행복과 팀의 행복을 위해 현명하게하십시오. 올바른 길을 만들기 위해 에너지를 투자하지 않고 공정을 변경하려는 욕구는 선보다 훨씬 더 해로울 수 있습니다.

당신이 언급 한 입장에있었습니다. 나는 자바 개발자로 몇 년을 보냈고 결국 그들은 모두 스몰 토크를 사용하는 일을 시작했다. 나의 첫 반응은 "OMG, 그들은이 구식 기술을 사용하고있다"고 Java 솔루션과 관련된 스몰 토크 관련 문제를 해결하기 시작했다. 나는 다른 개발자들에게 어떤 두통이 있었는지 상상할 수 있었고 열정으로 Java를 싫어했습니다.

스몰 토크 언어를 배우고 좋아하는 것을 배우기 시작한 몇 개월 동안 두 명의 수석 개발자가 멘토링을받는 동안 중간 규모의 프로젝트를 진행할 때까지는 아니 었습니다. 욥을 떠나 Java 개발을 다시 시작한 이후 프로젝트를 수행하고 회사에서 사용하는 언어에 관계없이 프로젝트를 구현할 수 있다는 점에서 훨씬 유연하다고 생각합니다. 이 사람들이 이해하도록하는 핵심은 언어가 매체에 지나지 않는다는 것입니다. 또한 나 자신에게 Lisp와 Erlang을 가르치는 데 시간이 걸렸지 만 모든 사람에게 적용되지는 않을 것입니다.

팀 구축 전략으로 문제가있는 사람들에게 7 주 동안 7 개 언어를 추천 합니다.

또한이 사람들이 더 융통성있게 투자하는 데 얼마나 많은 시간을 투자 할 것인지에 달려 있습니다. 대부분의 대학들 (적어도 내가 본 것 중 하나)에서 문제는 그들이 특정 언어에 편향되어 있고 학생들이 언급 한 것처럼 '제도화'되었다는 것입니다. 전략의 일부는 팀에서 유연성을 배양하는 것이어야한다고 생각합니다. 이것은 도메인 중심 개발 로 보완 될 수 있습니다 .

(1) 도메인 모델링 (간단한 언어) (2) 두 가지 언어 (예 : Java 및 Lisp)를 사용하여 구현

다시 말하지만, 이는 위의 작업을 수행하고이를 달성하기 위해 자신의 시간을 기꺼이 투자 할 것이라는 가정하에 있습니다.

도움이 되었기를 바랍니다

나는 여기서 완전히 잘못된 길을 가고 있지만, 동일한 문제가 더 광범위하게 일반적이며 인간의 보수주의와 관련이있는 것 같습니다. 사람들은 언급하기에는 너무 많은 이유로 잘 알려진 행동 패턴을 변경하는 것을 종종 거부합니다.

나는 러시아 개발자이기 때문에 합리적인 서구 실용주의를 덜 보았 기 때문에 다른 사람의 신발을 타는 것보다 설득력이 떨어지는 실제적인 추론을 봅니다.

다시 말해, 선임 프로그래머는 현재 작업 계획과 관련된 자신의 위치를 ​​중요하게 생각합니다. 아마도 당신은 그 일을하는 새로운 방식이 그의 위치를 ​​더욱 가치있게 만들 것이며, 그것을 할 수있는 방법이 많이 있다고 그에게 확신시켜야합니다. 예를 들어, 실제로 아이디어를 발음하고 크레딧을 받도록하거나 프로세스에서 독점적으로 제어 할 수있는 특정 지점을 찾을 수 있습니다.

나는 당신의 아이디어의 명백한 이점 밖에서 융통성이 있다는 것이 여기에 마법의 마법이 될 수 있다고 생각합니다.

나는 다른 사람들을 설득하고 개념 증명을 개발하기 위해 노력할 준비가되었습니다. 그러나 '시니어'개발자는 현재 프로세스로 인해 더 가치가 있기 때문에 기꺼이하지 않습니다.

선임 개발자의 성격 (나쁜 움직임)에 대한 aspersions를 던지기보다는 왜 열정적이지 않은지 이해해야합니다.

• 어쩌면 그는 당신이 자신의 아이디어를 과도하게 판매하는 사람들 중 하나라고 생각합니다. 어쩌면 그는 당신이 그들에게 전달할 수 있는지 의심합니다.

• 그는 당신이 문제를 과장한다고 생각할 수도 있습니다. (그들은 그렇게 나쁠 수 없습니다 ...)

• 그는 당신이 기술적 위험을 완전히 이해하지 못한다고 생각할 수도 있습니다.

• 어쩌면 그는 지금해야 할 더 중요한 일이 있다고 생각합니다.

• 어쩌면 당신은 그를 잘못 길 들였을 것입니다.

내 충고는 그에게 자신을 증명하는 것입니다. 실제로 주어진 프로젝트를 수행하는 것과 같습니다. 그가 당신의 능력과 판단을 더 신뢰할 때,이 문제를 다시 방문하십시오.

지금 "프로세스 개선"라인을 추구하고 싶다면, 조금씩 단계적으로 천천히 진행하는 것이 좋습니다.

마음에 곰이 있음을 의심 할 여지없이 위험 당신의 제안 된 변경 사항 그룹의 생산성에 대규모 미치는 영향, 기존 소프트웨어를 유지하기 위해 그들의 능력. 그렇게되면 담당자가 고위 경영진으로부터 가장 큰 도움을받을 것입니다.

특히 무엇에 대해 제도화 되었습니까? 기술, 패턴, 사례?

만약 그들이 조직 / 프로젝트에 오랫동안 있었다면, 그들은 선임 개발자 일 가능성이 있고, 그 전화를 할 책임과 경험이 있고, 5 마리 원숭이 실험 처럼 조건화되기보다는 프로젝트에 경험이있을 것 입니다.

설득력있는 해결책은 주제가 무엇인지에 달려 있습니다. 패턴 / 기술이 이미 선택 되었다면, 정당한 이유가있을 것이며, 일을 버리고 재 패밀리 등을 정당화하기 위해 변화해야 할 더 나은 이유가있을 것입니다. 그렇다면, 솔루션은 회의를 조직하는 건축가 / 시니어 개발자가 최상의 솔루션을 민주적으로 결정하는 것입니다.

팀에 실제로 불필요한 도로 블록이있는 경우 문제 해결에 도움을주는 것이 가장 기쁠 것입니다. 그러나 그들이 거기에있는 데는 그럴만한 이유가있을 수 있습니다. 여러분이 오랫동안 모든 사람들에게 그것을 팔아서 "오, 글쎄, 저의 환상적인 아이디어는 효과가 없습니다"라고 말하면 어리석게 보일 것입니다.

먼저 조사한 다음 앞으로 나아가십시오. 또한 개선을 제안하는 방법을 보여줄 수있는 것이 핸드 파잉보다 훨씬 낫다는 점에 유의하십시오.

나는 당신이 "유연한 프로그래머"라고 말하는 경향이 있습니다. 당신은 프로젝트에 익숙하지 않지만, 당신의 아이디어가 최고이며 프로젝트를 이끌고있는 사람, 더 길고 내부와 외부의 시스템을 알고있는 사람은 그의 로커에서 벗어났다는 것을 모릅니다.

나는 경험이 풍부하고 잘 알려져 있으며 자주 호랑이 팀원으로 고군분투하는 프로젝트를 해결하기 위해 지명됩니다. 그럼에도 불구하고 나는 여전히 팀의 방법, 이유, 역학, 프로젝트 및 그들의 실습을 배우고 열렬히 들어 가지 않고 어떻게 이것이 잘못되었는지 이야기하지 않습니다. 사실, 나는 그들이하고있는 일이 잘못되었다고 말하지 않습니다. 왜냐하면 그것이 내가 원하는 응답을 얻지 못하기 때문에 일반적으로 그들이하는 일이 잘못되지 않기 때문에 약간의 조정이 필요합니다.

각 프로젝트는 고유합니다. 각 팀은 고유합니다. 귀하의 솔루션은 귀하와 개발자에게 더 좋을 수도 있지만 리드, 고객, 비즈니스 또는 프로젝트에는 더 좋지 않을 수도 있지만 더 잘 알 수있는 프로젝트 경험이 없기 때문에 모를 것입니다 그것에 대한 답변.

사람들이 원하는 것을 수행하도록하는 가장 좋은 방법은 모든 것이 자신의 아이디어라고 생각하게하는 것입니다. 따라서 직접 제안하는 대신 옵션을 제시하십시오. 귀하의 아이디어가 다른 대안보다 분명히 낫다면, 선임 개발자에게 아이디어를 고를 수있는 기회를주십시오. 신용을 얻는 것에 대해 걱정하지 마십시오. 중요한 사람들은 무슨 일이 일어나고 있는지 알게 될 것입니다.