손님
582
2021-03-19 11:36:01
2
1556

개발현장의 까다로운 사람들과 그 대처법


https://www.howtodeal.dev/
3
  • 댓글 2

  • kenu
    52k
    2021-03-19 11:42:30

    재밌고 유용한 링크 감사합니다.

  • kenu
    52k
    2021-03-19 11:48:06

    소프트웨어 프로젝트에서 어려운 사람들을 다루는 방법

    대화 형 인포 그래픽으로 이러한 문제 성격을 탐색 할 수 있습니다 .

    제품 관리자

    • The People Pleaser  – 핵심 업무 책임이 개발 팀과 이해 관계자 간의 양보와 타협을 찾는 것이라고 믿는 제품 관리자.
    • The Scope Wiggler  – 큰 요구 사항 변경 사항을 시간이 지남에 따라 배포되는 일련의 작은 변경 사항으로 제시하여 변경 제어 및 영향 분석을 우회하는 제품 관리자입니다.
    • 특허 저자  – 문서를 최신 상태로 유지해야하므로 변화에 적응하는 데 장애가되는 많은 양의 요구 사항 문서를 생성하는 제품 관리자입니다.
    • The Napkin Sketcher  – 요구 사항이 너무 모호하여 개발 팀이 그 차이를 메워야하지만 그들의 결정이 틀렸다는 사실 만 알려주는 제품 관리자.
    • The Executive Assistant  – 이해 관계자가 요청한 내용 만 문서화하고 이해 관계자에 대한 액세스를 거부하여 요구 사항을 협상 할 수없는 제품 관리자입니다.
    • The Sales Liaison  – 전체적인 제품 비전은 고려하지 않고 영업 팀의 요구 사항 만 충족하는 제품 관리자입니다.
    • The Dictator  – 그들에게서 오지 않은 아이디어를 거부하는 제품 관리자.
    • 범위 크리퍼  – 납품 날짜를 동일하게 유지하면서 프로젝트 범위를 늘리는 제품 관리자.

    디자이너

    • 메모 작성자  – 다른 사람의 아이디어를 문서화하는 것 이상을 수행하지 않는 디자이너.
    • 권리 박탈 자  – 프로젝트 디자인에 영향을 미칠 힘이 없다고 생각하여 디자인 방향을 제공하지 않는 디자이너.
    • 아티스트  – 최종 사용자에게 유용한 일을하는 것보다 제품의 모양과 느낌에 더 관심이있는 디자이너.
    • The Professor  – A Designer는 사용자 인터페이스 디자인의 과학과 이론에 전념하여 이해 관계자의 UI 요구 사항을 무시합니다.
    • The Distrusted  – 프로젝트 팀의 모든 신뢰도를 잃은 디자이너는 UI 요구 사항이 제품에 가장 관심이없는 것으로 간주되어 무시됩니다.
    • Blueprinter  – 개발자가 개발 시간을 단축 할 수있는 대체 구현을 선택할 여지가 없을 정도로 정밀한 수준의 사양으로 UI의 모든 세부 사항을 지정하는 디자이너입니다.

    프로젝트 관리자

    • 회의 스케줄러  – 모든 프로젝트 문제가 의사 소통과 조정 부족으로 인해 발생하며 많은 양의 회의가 해결책이라고 생각하는 프로젝트 관리자.
    • 통계 학자  – 항목이 무엇인지에 관계없이 목록을 설정하고 항목을 확인하는 데만 관심이있는 프로젝트 관리자입니다.
    • The Delusional  – 프로젝트 관리자는 프로젝트의 현실을 알지 못해 이해 관계자들에게 허위를 나타냅니다.
    • The Pessimist  – 프로젝트가 실패 할 것이라고 결론을 내린 프로젝트 관리자는 다른 방법으로는 확신 할 수 없으며 그들의 믿음에 대해 목소리를냅니다.
    • The Optimist  – 반대의 증거에 관계없이 프로젝트 성공을 스스로 확신 한 프로젝트 관리자.
    • 치어 리더  – 프로젝트의 성공 여부보다는 프로젝트에 참여하는 모든 사람이 만족할 수 있도록하는 데 초점을 맞춘 프로젝트 관리자.
    • The Tyrant  – 프로젝트 멤버를 더 열심히 일하도록 동기를 부여하는 이름으로 경멸 심으로 대하는 프로젝트 관리자.
    • 프로세스에 집착하는 프로세스  – 프로세스에 너무 집착하여 프로젝트가 성공하도록 돕는 것이 자신의 임무를 잊어 버렸습니다.
    • Hoverer  – 지속적으로 상태를 요청하면 사람들이 작업을 완료하는 데 집중할 수 있다고 믿는 프로젝트 관리자입니다.

    개발 관리자

    • The Formerly Technical  – 과거의 어느 시점에서 소프트웨어 개발자였던 개발 관리자로, 그들의 기술적 의견이 오늘날의 기술과 여전히 관련이 있다고 믿도록 이끌었습니다.
    •   기술자 – 기술 지식이없는 개발 관리자이므로 개발자를 관리 할 때 깊이가 없습니다.
    • The Ladder Climber  – 자신의 경력을 발전시키고 자하는 야망을 가진 개발 관리자이며, 개발 팀은이를위한 수단으로 만 생각합니다.
    • The Peacemaker  – 논쟁이 비생산적이라고 생각하는 개발 관리자로서 모든 종류의 논쟁을 억제하기 위해 노력합니다.
    • 기술  이 되고자하는 사람 – 개발 관리자의 삶이 자신을위한 것이 아니라는 것을 알게 된 후 코딩의 삶으로 돌아 가고자하는 개발 관리자.

    개발자

    • The Diva  – A Developer는 대체 불가능 함을 너무나 확신하여 관리가 불가능한 오만한 태도를 취했습니다.
    • 이상 주의자  – 개발자는 아키텍처의 우아함과 코드 완벽 성을 달성하는 데 너무 집착하여 비즈니스 가치를 추가하는 일을 잊어 버립니다.
    • The Rock Star  – 매우 재능 있고 생산적이며 필수적인 개발자로서 그들이 떠나면 전체 프로젝트가 무너질 것입니다.
    • The Aspiring Manager  – 코딩의 어려움에서 벗어나기로 결정한 개발자의 경력 경로는 경영진 중 하나가되어야합니다.
    • The Hostage Taker  – 미션 크리티컬 소프트웨어를 작성한 개발자이며 다른 개발자가 필수 소프트웨어로 작업하는 것을 거부합니다.
    • The Bull in the China Shop  – 개발자는 작업을 완료하는 데 너무 집중하여 품질에 대한 개념을 완전히 잊었습니다.
    • 무능한 사람  – 소프트웨어 작성 작업을 수행 할 지능이나 기술이 부족한 개발자.
    • The Extreme Underestimator  – 작업을 완료하는 데 필요한 시간을 지속적으로 과소 평가하는 개발자.
    • The Extreme Overestimator  – 마감일을 놓치는 것을 두려워하여 최대한 많은 추가 시간을 요구하는 개발자.
    • 솔저 (The Soldier)  – 옳은 일인지에 관계없이 질문없이들은대로 정확히 수행하는 개발자.
    • The Technology Enamored  – 새로운 기술을 시도하는 것에 너무 흥분하여 적절한 지 여부에 관계없이 프로젝트에 도입 할 수있는 개발자.
    • 레거시 유지 관리자  – 유일한 기능이 레거시 소프트웨어의 유지 관리이므로 새로운 작업을 수행 할 수없는 개발자.

    테스터

    • The Firehose  – 개발자에게 너무 많은 버그 보고서를 너무 빨리 넘쳐서 작업을 끝내지 못할 버그 백 로그로 개발 팀을 압도하는 테스터입니다.
    • Blamer  – 개발자가 버그를 발견 할 때마다 작업을 테스트하지 않는다고 비난하는 테스터입니다.
    • The Alarmist  – 전체 제품이 첫인상만을 기준으로 허용 할 수없는 수준의 품질이라고 선언 한 테스터입니다.
    • 과학자  – 새로운 버그를 찾는 대신 버그를 문서화하는 데 대부분의 시간을 소비하는 테스터입니다.
    • The Misleader  – 버그를 자주 부정확하게보고하는 테스터로, 개발자가 문제를 재현하고 수정하려고 시도 할 때 잘못된 경로로 안내합니다.
    • The Downtrodden  – 개발자 괴롭힘을 두려워하여 버그를 거의보고하지 않을 정도로 개발자에게 구타당한 테스터입니다.
    • The Random Clicker  – 버그가 어떤 느낌이든 클릭하여 버그를 찾는 테스터.
    • The Flippant  – 버그 보고서가 너무 수동적이어서 개발자가이를 무례한 것으로 해석하는 테스터입니다.
  • 로그인을 하시면 댓글을 등록할 수 있습니다.