조잡한 회사 문화를 어떻게 바꿀 수 있습니까? [닫은]

때로는 해결해야 할 문제가있을 때 가장 쉬운 방법은 작은 도구를 개인 도구로 작성하는 것입니다. 나는 그것을 사용할 유일한 사람이기 때문에 그것을 사용하거나 강력하게 만들지 않으며, 그것을 다듬고 철저히 테스트 할 시간이 없다.

그런 다음 동료는 프로그램을보고 요청합니다. 동일한 문제가 발생하여 도구가 도움이 될 수 있기 때문입니다. 나는 그에게 "예쁘지는 않지만 일을 끝낼 것입니다"면책 조항을 주었고 그에게 그 사실을 알려주었습니다.

다음으로 제가 아는 한, 상사는 저에게 전화를 걸어 소프트웨어를 클라이언트 컴퓨터에서 작동 시키려고하지만 X 오류 메시지를 표시한다고 알려줍니다. WTF ?? 그 소프트웨어는 출시 준비가되지 않았으며 출시 준비가 필요하다고 말하지도 않았습니다. 그러나 어떤 이유로 든 내 우수한 생각은 충분하다고 생각하여 원래 개발자에게 알리지 않고 발표했습니다.

이제이 특정 문제는로 쉽게 해결할 수 있습니다 MessageBox.Show("DO NOT GIVE TO CLIENTS!");. 그러나이 문제는 훨씬 더 깊은 문제를 나타냅니다. 회사 문화가 느슨합니다. 조잡한 소프트웨어가 정상이고 조잡한 프로세스가 정상입니다. 미래에 대해 걱정하지 마십시오. 지금은 거의 작동하지 않도록 바이너리를 .zip 파일에 넣고 배송하십시오. 정부 업무에 충분합니다.

이 회사는 정규직 직원이 10 명인 소규모 회사로 성장하고 있으며 한동안 주변에있었습니다. 나를 잘못 이해하지 마라. 나는 여기서 일하는 것을 좋아하고 회사를 좋아합니다. 달리라고 말하지 마십시오. 나는 회사를 더 잘 만들기 위해 참여하고 싶다. 이런 종류의 문화에 어떻게 좋은 변화를 가져 오기 시작합니까?

변화를위한 유일한 방법은 다른 사람들이 엉성한 문화의 단점을보고 더 중요하게는 경영진이이를 해결하도록하는 것입니다. 그러나 실제로는 그런 일이 일어나지 않으며 변경할 수 없습니다. 그것은 당신이 듣기를 기대했던 대답은 아닐지 모르지만, 5 년 정도 지나면 부패한 문화를 바꾸기 위해 여러 직장에서 노력하고 실패한 후, 나는 약간의 권위를 가지고 일반적으로 노력할 가치가 없다고 말할 수 있습니다.

첫 번째 단계는 다른 사람이 느슨한 문화를 알고 있거나 관심이 있는지 알아내는 것입니다. 당신이 어떤 문제를 보는 유일한 사람이라면, 당신의 노력은 헛된 것입니다.

동료 및 상사와 함께 앉아서 프로토 타입을 가지고 있었고 고객이 사용할 준비가되지 않은 것을 설명해야 할 수도 있습니다. 고객이 사용할 준비가 되었으면 충분한 시간을두고 변경을 수행 할 수 있지만 "빠르고 더러운"물건을 가져 가지 말고 고객에게 전달하십시오. 무언가가 효과가 있다고해서 배우는 것이 좋은 것은 아닙니다. 면책 조항을 제공하는 동안 그렇지 않은 경우 발생할 수있는 것으로 존중해야 할 사항이 있습니다.

당신은 바보를 고칠 수 없습니다. 당신의 상사가 당신이 묘사하지 않은 일을하고 있다면 그것을 바꿀 수있을 것입니다. 특히 그가 소유자가 아닌 경우, 다른 방향에서 압력이 가해지고 그 방향이 급여 확인에 서명한다는 것을 기억하십시오. 다른 동료들과 동일합니다. 취할 수 있는 최선의 첫 번째 행동은 자신을 보호하는 습관을들이는 것입니다. 설명하는 메시지 상자와 같은 기술을 사용하십시오. 모든 이메일을 보관하십시오. 가능한 한 많이 서면으로 작성하십시오. 이런 식으로 당신은 어리 석음이 발생할 때 잔인한 것을 취하지 않습니다. 그런 다음 승진하면 원하는 변경 사항을 감독하에 변경하십시오.

다른 날, 한 동료가 실험실의 엔지니어가 위젯에 단일 명령을 발행하고 명령과 함께 사용되는 변수를 변경할 수있는 간단한 테스트 도구에 대해 이야기했습니다. 이것은 9 년 전에 쓰여졌 고, 그가 알고 있었지만, 오늘날에도 여전히 사용되고 있습니다. 실험실에서 어떤 것이 효과가 있음을 입증하기 위해 최소한의 테스트로 몇 시간 안에 작성된 도구는 전체 엔지니어링 실험실 테스트 도구의 기초였습니다. 코드를 작성하면 존재합니다. 유용한 일을하고 다른 사람들이 볼 수 있다면 사람들은 그것을 원할 것입니다. 그것이 잘하는 일을한다면 사람들은 X에게 할 것을 요구할 것입니다. 다음으로 아는 것은 간단한 도구가 중요한 요소입니다.

코드를 보거나 도구를 사용하는 사람은 그것이 프로토 타입인지 프로덕션 시스템이 아님을 이해하고 그 이유를 말할 수 있도록하는 것은 소프트웨어 개발자의 책임이라고 생각합니다. 그렇게 한 것처럼 들리지만 동료는 그 책임을 이행하지 않았습니다. 이 문제를 해결하기 위해 프로덕션 코드가 아니며 작업을 용이하게하기 위해 작성된 것임을 반복해서 이야기하는 것이 좋습니다. 그들이 유용하다고 생각되면 도구를 사용하거나 도구를 사용하는 다른 사람들이 도구를 향상시키고 생산에 더 적합하도록 지원하도록 제안하십시오.

조직의 프로세스 나 문화가 변화하는 한 시간이 걸릴 것으로 예상됩니다. 예제를 설정하여 시작하십시오. The Pragmatic Programmer를 읽지 않았다면 읽어보십시오 . 공예에 대한 관심, 변화를위한 촉매가되기 (사람들에게 더 나은 방법을 보여주십시오), 깨진 창문과 함께 살지 말고, 비난이 아닌 문제를 해결하십시오. 이 팁으로 해결 된 일부 문제를 인식하는 것처럼 들리므로 동료들과 함께 일하고 모범을 보이십시오.

의사 결정자들은 더 이상 잘못된 코드의 결과를 용인하지 않고 문제를 해결하는 방법을 기꺼이 지불 / 변경하려고합니다.

소규모 및 성장하는 회사에게는 어려운 결정입니다. 그들은 모든 노력을 다할 곳을 모릅니다. 비즈니스 규칙과 때로는 전체 비즈니스 라인이 밤새 나타나고, 변경되고, 사라질 때 코드를 너무 강력하게 만드는 위험이 있습니다.

좋은 코드를 작성하려고 노력하십시오. 정보에 근거한 결정을 내릴 수 있도록 모든 사람에게 결과를 알려주십시오. 잘못된 코드가 생산에 들어가는 경우 가능한 한주의 깊게 관찰하고 특히 비즈니스 부분이 중요 해지면 개선을 제안하십시오.

최소한의 실행 가능한 코드로 보는 것을 사람들이 기다리게하는 것은 현재 예상을 넘어서는 것 같습니다.

여기서 문제의 한 부분은 처음에 빠르고 더러운 도구를 작성했다는 것입니다. 물론 좋은 이유가있었습니다. 물론, 그것은 일을했다. 그러나 , 나는 것으로 나타났습니다 아무것도 해결하는 문제를 당신이 그것을 통과 시작하면, "좋은 충분"솔루션의 함정에 빠지지 것입니다.

동료가 원하는 경우 정중하게 기능이 제대로 작동하지 않는다고 말하면 키를 유지하는 것입니다. 때때로 그를 위해 실행할 수 있습니다. 또는 프로젝트 초기부터 추가 기능을 추가하십시오.

이 시점에서 빠르고 더러운 도구는 모두 엄격하게 테스트 된 스켈레톤 파일에서 가져 왔습니다. 그것은 빨리 갈 수있게 해주 며, 시작점을 제공하며, 필요한 무딘 모서리를 모두 추가하는 것을 잊게합니다. getopts 라이브러리와 그 단점에 대해 걱정할 필요가 없습니다. 파이썬을 사용할 때 메모리 관리에 대한 세부 사항을 기억할 필요가 없습니다. 하나의 간단한 작업과 하나의 작업 만 수행 하도록 프로그램을 빌드하십시오 . 따라서 모양이 구부러 지는지 쉽게 테스트 할 수 있습니다.

마지막으로 유한 상태 머신 아키텍처를 활용하십시오. 가능한 모든 상태로 진행되는 것을 알고 있다면 사용자가 트랙을 뛰어 넘을 수 없도록하는 것이 훨씬 쉽습니다. 이 패러다임을 따르기 위해 작성한 프로그램이 있습니다. 임의의 입력 파일을 허용하며, 바이트 단위로 읽습니다. 클라이언트가 바이너리 실행 파일을 읽도록 지시하더라도 아무런 문제가 없습니다. 찾고있는 것을 찾지 못하므로 내부 버퍼가 채워집니다. 이로 인해 정상적으로 정리, 종료 및 사용자에게보고해야한다고보고 할 수 있습니다.

소프트웨어가 품질을 쉽게 판단하기가 어렵다는 점을 제외하면 프로그래밍과는 관련이 없습니다.

소프트웨어 품질에 영향을받는 사람들은 프로세스와 관련이 없기 때문에 사람들이 실수를 하지 말아야 할 실제 동기가 없기 때문에 문화를 바꿀 수 없을 수도 있습니다 . 예를 들어, 고객은 소프트웨어를 구매하여 업무를 수행해야하지만, 소프트웨어의 문제에 대해 개인적으로 비난받지 않거나 소프트웨어의 미덕에 대해 보상받지 않기 때문에 소프트웨어의 효과에 대한 개인적인 이해가 거의 없습니다 (대부분) 경쟁 소프트웨어가 더 나을지 아무도 모르기 때문입니다). 따라서 너무 오래 걸리지 않고 기능 요청을 충족해야 할 수도 있지만 버그가 있는지 걱정할 필요는 없습니다. 따라서 당신은 결과에 영향을 미치지 않고 (당신에게 영향을 미치는 결정을 한 사람에게) 상당히 부주의 할 수 있습니다.

이 같은 경우인지 모르겠지만, 문화를 바꾸는 데 어려움을 겪을 수 있습니다. 변화를 시도하는 사람들이 실제로 더 나아지지 않기 때문입니다.

그들이 더 나아질 경우, 당신은 그들이 왜 그런지 설득 할 수 있기 때문에 더 쉬운 시간을 가질 수 있습니다. 차종 sloppiness OK 그들은 아마하지 않을 것이라고 정치 상황의 어떤 종류가 아니었다면 불행하게도, 수 처음에 실수 때문에 힘든 될 가능성이 높습니다. "언젠가 일을 올바르게해야하는 일이있을 수 있습니다"라는 주장을 항상 시도 할 수 있습니다 (아마도 더 외교적으로 말하면 ...)