젊고 죽어가는 프로젝트를 저장하는 방법?

잠재적 인 문제를 일으키고 싶지 않기 때문에 익명으로 게시하고 있습니다.
큰 문제가 있습니다.
나는 최근에 1 살 미만의 팀에 합류했습니다. 한 달이 지나서 프로젝트가 시작되었습니다. 회사 구조는 다음과 같습니다.

• 소유자 (비 기술적)
  • 프로젝트 관리자 (비 기술적)
    • 선임 개발자 (기술적이지만 좋지 않음)

이 프로젝트는 수석 개발자가 끔찍한 아키텍처를 설계 한 ASP.Net을 사용하는 웹 사이트입니다. 내 말을 들어야하지만 기본적으로 웹 페이지를 작성하는 데 필요한 방법은 디버그 모드에서 VPN을 통해 단일 웹 페이지에서 3 분 이상로드하는 시간입니다.

다른 동료들이 실제 개발보다 페이지가로드되기를 기다리는 데 더 많은 시간을 소비한다는 데 동의하는 시점으로 나아갔습니다.

이제 큰 문제는 이것입니다. 프로젝트 관리자는 기술을 모르고 인정합니다. 그는 응용 프로그램 아키텍처에서 올바른 선택을하기 위해 수석 개발자를 신뢰한다고 구체적으로 언급했습니다.

팀의 어느 누구도 소유자의 의견이 무엇인지 알지 못하지만 모든 사람들이이 경제에서 물결을 치는 것을 두려워합니다.

당신은 무엇을 하시겠습니까?

이 문제는 매우 비전문적 인 용어로 프로젝트 관리자에게 증명 될 수 있습니다. 사이트를 PM 앞의 브라우저 창에두고 잠시 동안 게임을 해보라고 요청하십시오. 두 번 정도의 페이지로드 후, 당신이 말하는 것처럼 일이 나쁘다면 리드 개발자를 카페트에 불러야합니다.

PM은 왜 나쁜지 이해하기 위해 전문화 된 개발 지식을 가지고 있지 않을 수도 있지만, 일반적인 웹 사이트 사용자로 자신을 볼 수 있습니다. 비슷한 정보를 표시하는 다른 사이트는 귀하의 시간의 일부만에로드되며 다음 사이트의 서버에서 로컬 네트워크를 통해로드됩니다.

이것이 날지 않으면 소유자에게 가십시오. 주인은 돈이 많은 사람이지만, 아무도 방문하지 않는 느린 웹 사이트 == 돈이 없다는 것을 매우 빨리 볼 수 있습니다. 동일한 데모를 설정하고 첫 페이지를로드하기 전에 PM과 리드를 모두 더 높은 카펫에서 불러야합니다.

한 남자가 파도를 타는 것에 대해 걱정이된다면, 한 명 이상의 개발자가 자신의 우려를 기꺼이 말하게하십시오. 솔직히, 당신과 같은 평평한 회사에서, 당신이 개발하고있는 제품이 폭탄이라면, 말을하거나 조용히하더라도 일을하지 않아도됩니다. 따라서 그런 식으로 보면 회사에서 몇 주 또는 몇 달을 잃을 것이 없습니다. 그것이 문제라면, "치과 의사의 약속"을 계획하고 우려를 표명하기 전에 새로운 일자리를 찾으십시오. 따라서이 직업을 잃으면 다음 주 월요일에 시작합니다.

진술 내용이 정확하다고 가정하면 무능한 수석 개발자와 무능한 프로젝트 관리자가 있습니다 (적어도 팀의 기술을 평가할 수없는 정도까지). 좋아. 전 세계 모든 팀의 개발자와 똑같은 옵션이 있습니다.

1. 회사의 건강을 돌보지 않고 일을하십니까?

2. 다른 곳에서 일자리를 찾으십시오.

3. Lead, PM 및 Owner에게 합리적인 제안을하고 그들이 채택되기를 바랍니다.

위의 조합을 동시에 자유롭게 할 수 있습니다.

프로젝트의 건강을 적극적으로 보장하려면 여가 시간에 새로운 프레임 워크를 생각해 내고 다른 팀원들에게 팀이 왜 우수하고 오래된 작업을해야하는지 보여주기 위해 다른 개발자들과 협력해야합니다. 그것에 찬성 해 버린다.

나는 실제로 회사의 파트너 인 수석 개발자가 소프트웨어의 "핵심"을 만들어 냈고 그와 직접 협력 한 친한 친구를 제외하고 다른 개발자는 핵심.

"각 기능"은 각 모듈과 마찬가지로 규칙을 생성하기 때문에 하나의 데이터베이스 테이블 만 가질 수있는 규칙을 만들었습니다. 그 결과 별도의 테이블이 아닌 데이터베이스의 테이블에서 "DISTINCT"를 선택하여 기존 드롭 다운을 만들었습니다.

구현 팀이 작업을 완료해야하고 제품이 즉시 작동하지 않기 때문에 여러 가지 잘못된 패치가 떠 다니고있었습니다. 이러한 패치는 수정 될 때마다 많은 문제를 일으켰으며 각 설치마다 사용자 정의 (해킹)되었습니다.

저의 접근 방식은 코어가 작고 좋은 일반 패치를 지원하지 않고 작성하지 않았다는 사양의 작은 부분을 취하는 것이 었습니다. 구현 팀을 만족 시켰지만 "우리의 생각을 완전히 바꿔야 할 것"만큼 위협적이지 않은 것. 구현 팀과 핵심 개발자 간의 적대감으로 인해 구현 팀이 해킹보다 나은 방법을 구현 팀에 확신시키는 데 몇 달이 걸렸습니다. 그러나 일단 그들은 그들이 그들의 말을 듣고 그들을 지원하기 위해 추가 조정을 할 것이라는 것을 알게되자 기뻤고 내 편에있었습니다. 수석 개발자가 패치를 수락하는 데 한 달이 더 걸렸지 만 일단 패치를 적용하면 시스템의 다른 부분을 디자인하는 더 나은 방법에 대해 우리 모두 사이에 의사 소통을 실제로 시작했습니다.

특히 사람들과 시민 관계를 유지해야하는 경우 사람들의 생각을 바꾸는 짧은 길은 아닙니다. 그러나 올바르게 접근하면 상사를 모욕하지 않고 존경을 얻을 수 있습니다.

희망이 도움이됩니다!

매우 간단한 답변과 솔루션. 모든 사람이 문제를 알고있는 것 같습니다. 따라서 문제를 지적하는 것은 아무에게도 가치가 없습니다. 사실 그것은 단지 당신을 위너처럼 보이게 만듭니다. 가치를 높이려면 솔루션을 지적하고 솔루션으로 변경하기위한 비즈니스 사례를 구축해야합니다. 그런 다음 해당 솔루션의 문제를 지적 할 수 있습니다. 데모는 또한 솔루션을 입증하는 데 먼 길을 갈 것입니다. 물론 이것은 자신의 시간에 일하는 것을 의미 할 수도 있지만, 그것이 너무 중요하다는 것에 달려 있습니다.

우선, VPN 구성의 문제가 아니라 응용 프로그램 아키텍처 문제라는 사실을 확인하는 것이 좋습니다. VPN 구성이 잘못되어이 정확한 문제가 발생하는 것을 확인했습니다. 사무실 내부에서 앱이 느리다는 것을 알고 있습니까?

네트워크를 배제했다면 KiethS 제안을 따르고 PM에게 페이지를 가져 오십시오.

그것은 사업처럼 들리거나 적어도 프로젝트가 곧 어느 시점에 진행될 것입니다. 종료가 빠르면 가능한 한 빨리 자신과 거리를 두려고 노력합니다. 진행중인 다른 프로젝트에 대한 자원 봉사 / 요청 작업. 시간이 지남에 따라이 재난에 더 적은 시간을 할애하고 일할 수있는 다른 프로젝트에 더 많은 시간을 할애 할 것입니다. 당신은 '작동하지 않는 프로젝트에서 일한 사람'으로 생각하고 싶지 않습니다. 그것은 당신의 명성을 보호하는 것입니다.

소유자가 좋은 제품을 원하십니까? 나는 대답이 "예"라고 의심합니다. 그러므로 당신은 말을해야합니다. 현재 아키텍처를 문서화 한 다음 (제국 데이터가 양호 함) 제품이 적절한 성능 기대치를 충족하지 않는 방법을 보여야합니다. 당신의 동료들은 모두 자신의 성과가 좋지 않다는 것을 알고 있습니다. 고객은 어떻습니까? 그들은 무슨 말을하는거야? 성능 측정 도구를 사용하여 시간이 오래 걸리는 것을 결정하십시오. 많은 도구가 각 함수 호출에 걸리는 시간을 보여줍니다. 이 모든 데이터를 통해 프로젝트 관리자 및 기술 담당자와 대화를 나눌 수있는 충분한 탄약을 확보해야합니다. 이유는 무엇을해야하는지와 제품의 속도를 높이기 위해 몇 가지 주요 리팩토링이 필요한지에 대한 것입니다.

그런 다음 (PM 및 리드와 대화 한 후에 만)이 변경을 시작하기에 충분해야합니다. PM이 그 시점에 확신이 없다면, 이것이 실제로 당신이 원하는 곳인지 결정해야합니다. 그렇다면 소유자와의 회의 일 가능성이 큽니다. 그렇지 않은 경우 이력서를 준비하십시오.

모든 단계마다 문서화해야합니다.

기술적 인 용어로 위의 제안에 동의합니다. 반면에 나는 그것이 기술적 인 문제 라기보다는 관계 문제라고 생각합니다.

원활한 길을 가고 싶다면 수석 개발자와 대화하는 것이 적합합니다. 나는 사무실에서 이야기하지 않을 것입니다. 밖에서 커피를 마시면 일이 조금 비공식적이고 편안해집니다.

그래도 문제가 해결되지 않으면 PM에게 문의 한 다음 소유자에게 문의하십시오.

아무것도 효과가 없다면, 새로운 일자리를 찾는 것이 좋습니다.

정직-그리고 당신이 소집 할 수있는 한 많은 전술.

수석 개발자부터 시작하여 필요에 따라 작업하십시오. 성격의 더 나은 측면을 시도하십시오-당신이 개발자를 이끌면 문제를 해결하는 것을 좋아합니다 / 하루를 저장하는 것을 좋아합니다 / 효율적인 것을 좋아합니다 / 등등. 과거에 추가적인 동기로 성공했습니다.

파도를 만들지 않으면 아마도 물에서 죽었을 것입니다.

프로젝트 관리자와 소유자가 이해할 수 있도록 측정 가능하고 기술적이지 않은 수준으로 문제를 되돌릴 수 있습니까?

예를 들어,로드 시간이 3 분 이상인 느린로드를 언급 한 경우 사양에 어딘가에 "1 초 내에로드 할 페이지"와 같은 성능 요구 사항이 있다고 가정합니다. 이와 같은 것은 측정 가능하며 반박 할 수 없습니다. 이 문제의 근본 원인이 회피 아키텍처 인 것으로 밝혀지면 프로젝트 관리자 및 / 또는 소유자가 일부 변경을 수행해야합니다.

그렇지 않은 경우 회사에 초기 분석이 제대로 수행되지 않아서 이러한 유형의 문제를 포착 할 충분한 프로세스가없는 체계적인 문제가 있습니다. 배 점프를 고려하십시오!

진짜 남자는 분개 나 감정없이 말을합니다. 그게 속임수입니다.

누군가가 당신과 대화를 나눌 수있는 유일한 이유는 당신이 원망하는 사람을 만나는 것입니다.

리더 개발자는 무엇을했는지 전혀 알 수 없습니다. 나는 이것이 일어날 것이라는 것을 알고 있었지만 아무도 나를 들었다.

어디서

유지 관리가 어렵고 느리기 때문에 코드 모델이 잘못되었습니다. 우리는이 발전에 대해 전략적이어야하며이 두 가지 문제를 해결해야합니다.

전자는 파괴하기위한 싸움이고, 후자는 평화를위한 싸움이며, 장기적으로는 사람이 정직하게 대하는 존중을 얻게 될 것입니다.

프로젝트 리더가 이것을 정면으로 생각한다면, 그가 해고 될 것이라고 생각했을 것입니다.

구현할 책임이없는 것에 대해 책임을지지 마십시오. 나는 단지 정직합니다.