우리는 모두 거기에 있었다 :
- 프로젝트가 실패했거나 취소되었습니다.
- 며칠 동안 일한 코드가 팀에 의해 거부되었습니다.
- 팀에 소개 한 디자인 패턴에 혼란이 생겼습니다.
- 모두는 당신의 아이디어를 무시합니다.
제 질문은 프로그래머가 이러한 개발 관련 장애를 처리하는 가장 생산적인 방법은 무엇입니까?
답변
프로젝트가 실패했습니다.
소프트웨어 개발은 프로젝트 실패가 발생하기 쉬우 며 심각도에 따라 관리가 가장 잘 처리합니다.
많은 프로젝트가 실패했으며 더 많은 프로젝트가 실패 할 것이므로 메모 해 두십시오! 다음에 같은 실수를하지 않도록 프로젝트가 실패한 이유를 알아보십시오. 성공보다는 실패에서 더 많은 것을 배웁니다.
코딩 일에 소비 한 내용이 팀에서 거부되었습니다.
작업을 저장하십시오 (나중에). 두 가지 가능성이 있습니다. (a) 짜증이 나고 여러 사람들이 같은 방식으로 반응했다는 사실은이를 나타냅니다. (b) 정말 천재적인 작업이지만 사람들이 익숙하거나 이해할 수있는 것보다 훨씬 앞서 있습니다. 사람들은 일반적으로 이해하지 못하는 것을 좋아하지 않습니다. 아마도 시간이 맞거나 다른 “문화”를 가진 다른 장소에있을 때 그것을 보여주는 것이 더 낫습니다.
아무도 당신 회사의 아이디어를 듣지 않습니다.
아마도 나쁜 생각이거나 문화가 당신의 생각과 맞지 않습니다. 문화를 지원하는 장소로 이동하거나 아이디어를 비판적으로 다시 평가하십시오 (객관적으로 자신의 편견없이)-> 내 아이디어가 정말 좋습니까? <- 네 자존심을 죽여라
팀에서 강제로 도입 한 디자인 패턴이 혼란 스러웠습니다.
솔직히 말해서 최선을 다했지만 어떻게 계획했는지는 알 수 없었습니다. 팀으로 디자인에서 실수를 다시 시작하거나 배우는 것이 좋습니다.
답변
그들은 실패가 아닙니다-그들은 경험입니다
당신은 그들이 당신을 어떻게 느끼게했는지, 그리고 그 느낌을 더 많이 원한다면 당신의 경험에서 배우고 성장합니다.
그것이 나쁜 경험 (제공 한 목록과 같은)이라면, 동반되는 나쁜 느낌은 피하고 싶을 것입니다.
전반적으로, 다른 사람들과 자신을 비교하는 데 너무 관여하지 마십시오. 그들은 당신과 같이 일하는 데 많은 어려움을 겪고 있습니다 .
답변
- 침착하십시오-당황하지 마십시오.
- 피해 관리-저장 가능한 내용 저장
- 실수를 통해 배운다-틀린 일을 다시하는 것이 효과가 없을 것이다
- 새로운 시작을 고려하십시오-실망과 죄책감의 배낭없이 다음 시도를 시작하십시오
- Ariane 5의 첫 비행과 비교하여 더 큰 실패를 살펴보십시오. 실패는 무시할 수 있습니다.
- 혼자 치료할 수 없다면 심리 치료사와 상담하십시오
답변
당신은 무언가를 만듭니다.
나에게 (나는 그것이 모두에게 옳다고 생각하지 않는다), 무언가 (만화, 그림, 작은 게임 등)를 구축하는 것은 전투 실패로 돌아갈 수있는 약간의 자신감을 쌓는 것과 같습니다. 또한 실패와 관련하여 분노 나 쓰라림 또는 감정을 표현할 수있는 좋은 방법 일 수도 있지만 “구성 적”방식으로 표현할 수도 있습니다.
어쨌든 그것은 나를 위해 작동합니다.
답변
글쎄, 당신은 물었다 🙂 하나씩 :
* Your project failed.
그것은 거의 새로운 것이 아닙니다. 우리는 모두 개인적으로 실패했으며 동료들에 대한 전체적인 관점에서 실패했습니다. 초등 및 중등 교육을받은 사람은 이것을 경험했습니다.
내가 실수를 할 수없고 안정적인 고용을 기대한다면 HR에 메모를 보내서 인류가 향후 고려에서 금지 될 것임을 알리는 것을 고려해야합니다.
연속해서 여러 번 실패하면 부당한 요구와 사양이 있거나 실수로부터 배우지 못했음을 의미합니다. 두 시나리오 모두 즉각적인 조치를 취합니다.
많은 사람들이 취업을 위해 무언가에 서명 한 다음 요구 사항을 충족시키는 방법을 고안하는 것이 가능합니다.
* What you have spent days coding was rejected by your team.
그런 일이 있습니다. 다른 사람들이 지적했듯이 저장하십시오. 다시 할. 이것이 우리가 그것을 작동이라고 부르는 이유입니다. 이 경우에, 당신은 아마도 당신이하고있는 일에 팀을 많이 관여시키지 않았을 것입니다.
어제 또는 한 시간 전에 요구 사항이 변경되었을 수도 있습니다. 그러나 이것은 예외가 아닌 표준이어야합니다. 동료 검토는 도움이되는만큼 잔인합니다. 코드가 지속적으로 ‘부적절하다'(또는 이와 유사한 것)로 기각되면 뇌를 고르고 다른 사람들을 참여시키는 데 더 많은 시간을 소비해야합니다. 나는 ‘팀’이 자기 설명이 아닌 한이 질문이 대부분의 팀 환경에서 잘못되었다고 생각합니다.
* Nobody listens to your ideas in your company.
다시 말하지만, 상황이 필요합니다. 거기에 얼마나 있었어? 동료 해커들은 당신의 능력을 얼마나 신뢰합니까? 많은 사람들이 더 많은 작업을하게하는 아이디어가 어떤 이유로 든 아이디어를 기각 할 수 있다고 생각 했습니까? IPV6가 준비되지 않았기 때문에 한 번 해산되었지만 루프백 장치에서 간단한 도메인 소켓을 사용했습니다. 침몰 한 사람은 더 이상 할 일이 없습니다.
또한 자신을 얼마나 잘 표현하고 있습니까? 친구를 사귀고 사람들에게 영향을 줄 수 있습니까?
* The design pattern you introduced with force in your team created a mess.
그러므로 힘을 피해야하는 이유는 무엇입니까? 대화 할 수 있다는 것은 듣는 것이 전제 조건이 아닙니다. 다른 의견은 없습니다.
답변
오 소년, 당신이 정말로 모든 일이 당신에게 일어난다는 것을 의미한다면 그것은 많이입니다!
경고 : 아래의 많은 부분에서 당신을 비판하는 것처럼 느껴질 수 있으며 잘못된 문제에 대해 책임지고 외부 요인을 고려하지 않기를 원합니다. 난 아니야 그것은 당신이 많은 세부 사항을 제공하지 않고 단지 일이 잘못되지 않도록하기 위해 수행 할 조치 목록을 제공합니다. 나는 내가 스스로 많은 실수를 저지른 것을 알고 있으며, 우리가 그로부터 배우면 더 나아집니다. 그리고 그것들로부터 배우려면, 우선 실수로 실수를보고, 우리가 잘못한 것에 대한 책임을 받아 들여야합니다. 지옥, 다른 사람들의 잘못에 대한 책임을 받아들이십시오. 당신도 그로부터 배울 수 있습니다.
프로젝트 실패
지금 완화하기 위해 할 수있는 일은 많지 않습니다.
그러나 나중에 재현하기 위해 많은 것을 할 수 있습니다. 프로젝트 및 시간 관리 기술을 향상시키는 것이 좋습니다.
내가 주제에 대해 읽은 최고의 비율 ((유효한 조언) / 페이지) 중 하나 인 책 중 하나는 아니지만 최고는 아니지만 Rob Thomsett의 Radical Project Management 입니다.
프로젝트가 실패한 것을 실제로 지정하지는 않지만 일반적인 비용 / 시간 / Qualiy Triangle 에서 불균형을 가져온 것의 조합을 가정합니다 . 내 눈에서 가장 중요한 요소는 프로젝트와 개발을 이끌면서 항상 기술 행위자 (개발자와 테스터)뿐만 아니라 이해 관계자와도 접촉하는 것입니다. 스폰서 나 이해 관계자의 말을 듣지 않고 프로세스에 참여하도록 강요하지 않기 때문에 너무 많은 프로젝트가 실패합니다.
참여하지 않으면 원하는 것을 알 수 없습니다. 원하는 것을 알 수 없으면 전달할 수 없습니다. 당신이 그것을 제공하지 않으면, 그들은 불행합니다. 실패입니다. 또한 이해 관계자를 참여시키지 않으면 소프트웨어 엔지니어링의 현실과 분리되어 문제를 이해하지 못합니다. 그들이 종종 당신과 연락을한다면, 그들은 당신이 다루어야 할 것을 더 잘 이해하게됩니다. “작은”[웃음] 기능은 몇 달이 걸릴 것이라고 말하면 더 잘 이해할 수 있습니다. 계획 수립에 도움이되므로 계획을 더 잘 신뢰할 수 있습니다. 프로젝트는 “처음에는 사양, 개발, 테스트, 마지막에는 배달”로 성공할 수 없습니다. 결코하지 않습니다. 사양에서 요청한 내용을 전달할 수 있습니다.
또한 가장 중요한 것은 회고 를하고 그것이 자존심이없고 비난 게임이 아닌지 확인하십시오. 문제를 식별하십시오.
코딩에 며칠 동안 보낸 것이 팀에서 거부되었습니다.
나는 그 상황에 있었다. 다시 말하지만, 다음을 제외하고는이를 완화하기 위해 할 수있는 일은 많지 않습니다.
- 나중에 SCM에 보관하십시오.
- 아마도 큰 리팩토링 대신 작은 비트와 조각을 주요 코드베이스로 점진적으로 밀어 넣으십시오.
그러나 이런 상황을 방지하기 위해 다시 할 수있는 일이 있습니다.
- 왜 그런 일이 일어 났습니까? 거절의 이유는 무엇입니까?
- 내가 이런 일이 일어나는 것을 보았을 때 (그리고 저도 마찬가지였습니다.) 개발자가 솔로로 또는 카우보이 코딩 모드에있어 결코 요청하지 않은 것을 만들어 냈습니다. 비즈니스 요구 사항에서 나오지 않는 코드는 환상적이고 “더 나은”것이지만 종종 시간과 돈을 낭비하게됩니다. 또한 다시 테스트해야하므로 통합하면 더 많은 비용이 듭니다. 돈을 다룰 사람들처럼 생각하십시오 : 당신도 그 수준에서 효율적이어야합니다.
- 제작 된 소프트웨어의 품질이 만족 스럽습니까? 회사 활동의 표준 및 규칙을 준수 했습니까?
- 이에 대해 정기적으로 (그리고 자주!) 직접 관리자에게보고 했습니까? 가끔 팀의 다른 개발자들과 교류 했습니까? 그렇지 않다면, 그들은 그것에 대해 아무 것도 모른다면, 지금 평가하고 검토하는 데 엄청난 시간이 소요될 것입니다. 결국 같은 시간에 설명되지 않습니다. 항상 렌트 아파트 청소를 중단 한 다음 이사 할 때만 청소하려고하는 것과 같습니다. 권리.
- 생산 테스트를 했습니까? 단위 테스트? 통합 테스트?
- 코드가 SCM에 정기적으로 체크인 되었습니까? 다른 지점에 있었습니까? 다른 지점이 필요 했습니까? 아니면 트렁크에서 수행 되었습니까? 커밋 코드를 끄는 것은 일반적으로 나쁜 징조입니다. 분명히 때때로 당신은 그것을하고 싶은 유혹을 느끼지만, 발로 스스로를 쏴 버립니다.
아무도 당신 회사의 아이디어를 듣지 않습니다
여기에는 두 가지 옵션이 있으며 두 가지를 모두 살펴 보겠습니다.
- 당신은 아이디어가 나빴습니다.
- 당신은 아이디어가 좋았습니다.
그들이 나쁘다고 가정 해 봅시다 (다시, 그것에 대해 스스로 생각하고 자신의 생각을 받아들이는 것이 어려울 수도 있습니다). 그걸 바꾸려면 어떻게해야합니까?
- 왜이 아이디어를 생각해 냈습니까? 근거 는 무엇입니까 ? 아이디어가 테이블에 가져 오려고하는 것이 실제로 필요한가?
- 아이디어를 어떻게 생각 해냈습니까? 당신은 그것을 스스로 했습니까? 공유 했습니까? 영감? 계획? 원형? (올바른 순서로이 작업을 수행하십시오. 실패하는 경우 아이디어를 버리고 계속 진행하지 마십시오. 최소한 작업 일정에는 없습니다.)
아이디어는 아이디어 일뿐입니다. 당신이 그것들을 아이디어로 제안하고 거부한다면, 왜 당신이 그것에 대해 기분이 나빠질 지 모르겠습니다. 그러나 당신이 아무에게도 알리지 않고 그들에게 행동하고 당신의 아이디어 만 제출하고 그들이 거부된다면, 분명히 당시의 좌절감을 느낍니다. 그리고 당신의 관리자는!
당신의 아이디어가 좋다고 가정 :
- 프레젠테이션이 좋았습니까?
- 프레젠테이션을 잘 전달 했습니까? (: 우리는 심술,있어 나는 내가 무슨 말을하는지 알아, 개발자입니다 거만하고 , 학자 연하는 항상 옳다 피타 누구와 함께입니다 작업을 하드 종종 있기 때문에 우리의 불균형 자아 ).
- 구현할 계획이 있습니까? 비용과 시간에 대해 생각 했습니까? 사용자 / 고객에게 어떤 이점이 있습니까? 그것이 판매에 어떤 영향을 미치는지 생각 했습니까? 그 아이디어에 대한 작업이 다른 프로젝트와 우선 순위에 어떤 영향을 줄 수 있다고 생각 했습니까? 당신은 “내가 왜이 모든 것을해야합니까? 그들은 내 매니저와 마케팅 또는 영업 팀의 일입니까?”라고 말할 것입니다. 지금을 제외하고는 모든 직무 중 일부를 수행하려고합니다.
팀에서 강제로 도입 한 디자인 패턴으로 인해 혼란이 발생했습니다.
- 패턴을 왜 소개 했습니까?
- 엉망이 된 경우 다음 중 하나 일 수 있습니다.
- 올바른 패턴이 아니 었습니다
- 제대로 구현되지 않았습니다
- 제대로 통합되지 않았습니다.
- 어떻게 소개 했습니까? 상태 “mess”를 정확히 어떻게 정의합니까?
- 읽기 어려운 코드?
- 덜 유지 보수가 가능합니까?
- 빌드가 깨졌습니까?
- 다른 종류의 “메스”가 있습니다. 혼란 이 무엇인지 아는 것은 실패가 무엇인지, 그리고 그것이 디자인 패턴의 결함인지를 아는 데 도움 이 될 수 있습니다.
또한 접근 방식 자체에 약간 놀랐습니다. 당신은 실제로했다 밀어 도입 될 디자인 패턴? 다소 이상해 보인다. 패턴이 이미 있거나 패턴에 따라 솔루션의 일부를 리팩터링해야합니다. 당신은하지 않습니다 밀어 (사람과 같은 프레임 워크 또는 기술의 채택이 것 당신처럼 밀려 사람들이 쓸 수 있도록 밀어 시작처럼 지금 모든 곳에서 XML을 가지고 정말 열심히, 그리고 HTML5를 큰 밝은 편지에서 자신의 제품 커버).
왜 밀어야 했어? 왜 저항이 있었습니까? 아마도 정당화되었을 수 있습니다.
이 특정 패턴이 코드 기반을 크게 개선하는 데 도움이되는 예를 제공 할 수 있었습니까 (예를 들어, 리팩토링에 대한 패턴 예와 일치 시켜 ).
완전히 주제를 벗어난 참고 사항 이지만 소프트웨어 실패와 관련하여 생각한 질문의 제목을 읽을 때 처음으로 생각한 것입니다 … BlackHole 클래스를 구현하여 매우 예외적 인 예외를 관리하는 소프트웨어가 있습니다. 구성 요소. 그것은 분명히 이상하고 더러운 해킹처럼 보일지 모르지만 명명 자체는 너무 훌륭하여 실패를 처리하는 상당히 멋진 방법으로 감사했습니다! 🙂
답변
1 단계 : 화가 나도 괜찮습니다!
첫째, 실패에 직면했을 때 화 나거나 화내는 것은 이해할 만합니다. 그러한 상황에있는 누군가에게 조언을한다면, 그들은“그냥 극복하고 넘어가십시오”또는“그것을 배우는 기회로 생각하십시오”라고 듣고 싶지 않을 것입니다.
사실, 개인적으로 또는 친구와 함께하는 경우 좌절감을 느끼고 배출하는 것이 건강하고 생산적 일 수 있다고 생각합니다. 사람들은 그렇게하는 방법이 다르지만, 가장 생산적인 방법 중 하나는 화난 가짜 편지 를 쓰는 것입니다 (중요! 이 편지를 다른 사람에게 보내지 마십시오 ). 발생한 일이 정당하지 않다고 느끼는 이유와 같은 감정을 설명하십시오.
2 단계 : 시간을내어 진정하십시오.
자신이 느끼는 모든 것을 표현했는지 확인하고 분노를 푼 후 잠시 시간을 내십시오. 아마도 몇 분 또는 몇 시간 만 필요할 수도 있습니다.
3 단계 : 1 단계에서 발생한 상황 검토
이 시점에서 상황에 대해 더 객관적으로 생각할 수 있기를 바랍니다. 편지를 쓴 경우 스스로 읽어보십시오. 누군가에게 자신감이 있다면, 말한 것을 기억하십시오. 누군가 소리 지르는 것을 상상했다면 정신적으로 그것을 검토하십시오.
나는 화가 났을 때 종종 편지를 쓴 다음 진정한 후에 편지를 수정하여 누군가 내가 읽은 내용이 무엇인지 이해할 때까지 원래 말하려고했던 내용을보다 명확하게 전달하도록 노력할 것입니다 당시 느낌.
요점은 객관적으로 요점을 파악하는 것입니다. 그들이 말이 되나요? 아마도 그것들은 설명이나 자세한 내용이 필요합니다. 그들은 근거가 없습니까? 다른 사람의 입장에서 객관적으로 행동해야한다면, 당신이 만든 요점을 이해 하시겠습니까? 그 점에 동의하십니까? 이 기회를 사용하여 자신을 평가할 수 있습니다. 무엇을 잘 했습니까? 더 잘할 수있는 일은 무엇 이었습니까?
4 단계 : 행동 과정 결정
상황을 개선하거나 최소한 개선하기 위해 할 수있는 일이 있습니까? 상황을 수정하거나 개선하기 위해 실제로 수행 할 수있는 것이 있는지 고려하십시오. 종종 존재하지 않지만 때로는 존재합니다.
당신이 무언가 잘못한 경우, 그것은 누군가에게 공식적인 사과만큼 간단 할 수 있습니다. 미래.
다음으로 미래를 개선하기 위해 할 수있는 일을 고려하십시오. 같은 일이 다시 발생하지 않도록하려면 어떻게해야합니까? 달성하고자하는 것이 무엇인지 결정하고 3 단계에서 배운 것을 사용하여 자신을위한 계획을 세우십시오.
다른 모든 방법이 실패하면 재부팅하십시오.
try
{
// ...
}
catch (OhNoes111Exception)
{
// reboot fixes everything!
System.Diagnostics.Process.Start("ShutDown", "/r");
}