기업 환경의 지속적인 변화를위한 개발?

Question

나는 현재 합병을 겪고있는 대기업에서 일하고 있습니다. 우리는 합병과 관련이없는 여러 프로젝트를 진행하고 있습니다. 내가 주목하는 한 가지 문제는 많은 개발자 그룹이 비즈니스 영역 내에서 많은 다른 프로젝트를 지원하더라도 매우 단편화된다는 것입니다. 나는 그로 인해 많은 데이터의 정확성에 대해 너무 확신하지 못합니다.

이러한 유형의 변화하는 환경을 관리하는 데 성공한 모델이나 표준이 있습니까? 이러한 변경 사항을 사용자에게 전달하는 좋은 방법은 무엇입니까? 이중화를 만들 수있는 방법이 있습니까? 생산의 한 부분에 변경이 제안되면 파이프 라인을 위아래로 통신 할 수 있습니까?

편집 : 주관성으로 인해이 커뮤니티 위키를 만들기

Answer 1

프로세스 감독, 마이그레이션 및 생성을위한 전용 리소스.

우리는 합병과 Unmergers를 겪은 다음 다른 회사를 구입하여 "프로세스"에 통합하는 과정에 있습니다. 나는 여기서 과정을 인용합니다. 제 생각에는 우리는 여전히 말할 것도 없기 때문입니다.

우리가 결국 성공할 곳은 우리가 작동하고 회사의 광범위한 프로세스를 만드는 데 전용 자원이 있다고 생각합니다. Scrum은 모두 좋지만 엔터프라이즈의 청구 및 마케팅주기에 반드시 적용되는 것은 아니지만 Dev, R & D 및 구현 팀에서 궁금해 할 것입니다 (아마도 3 개 중 단일 팀을 만들 수도 있습니다!). 그렇다면 우리는 각각의 전문 분야에서 효율적으로 작업 할 수있는 최상의 프로세스와 관행을 어떻게 생각해 내고, 모두 함께 묶어 두는가?

여기서 우리의 마법의 총알은 우리 가이 과제에 전념하는 사람이 있다는 것입니다. 그는 지금의 방법을보고, 필요한 것을보고, 그곳에 도착할 계획을 이끌어 낸 다음 실행할 계획입니다. 그는 부서와 함께 일할 것이며 누구와도 부서를 완료해야합니다. 무엇보다도, 그는 큰 헤드 바위를 롤링 할 수있는 적절한 레버리지를 제공하기 위해 큰 머리의 리더십과 후원을 가지고 있습니다 (나는 당신이 이것을 가지고 있다고 확신합니다. Peters 임계 값을 초과했습니다). 프로세스가 정의되면 프로세스를 적절하게 툴링하고 정의 전에 회사 (각 팀)가 채택한 모든 다른 시스템에서 모든 데이터를 마이그레이션하는 작업이 제공됩니다.

이 모든 작업을 수행하려면 다른 작업을 수행 해야하는 동안 불가능하지만, 그 일을 거의 해고 당했다는 것을 알고 있습니다 (한쪽에서 많은 바위를 밟았습니다).이 내부 구조에 전용 자원이 필요한 이유입니다. 당신이 당신의 회사에 아직 이것을 가지고 있지 않다면 나는 이것을 나의 첫 번째 전투 분야로 만들 것입니다.

우리가 여기에 온 것을 비유하는 것은 프로세스가 무엇인지 알고 바지를 완성 할 수있는 요리사 d '오케스터입니다. 이것은 CE* 유형의 사람이 될 수는 없습니다. 그렇게하면 그는 객관적으로 남아 있으며 한 걸음 물러서 동물 동물원에 끊임없이 빨지 않고 큰 그림을 볼 수 있습니다. 민첩한 프로세스 패러다임 모두에서 경험이있는 개발 배경을 가진 사람 이이 작업에 가장 적합하다는 것을 알게되었습니다. 개발 과정은 아마도 실제로 못을 박고 갈 수있는 가장 어려운 과정 일 가능성이 높습니다. 그가 할 수 있다면 나머지는 종이에서 가장 쉬워야합니다.

우리가 여기서이 변화를 얻었으므로, 느리게 나오지만 지금까지는 신이 매번 보내는 신입니다. 모든 변화는 나머지가 어떻게 비효율적인지를 밝히고 그에게 더 많은 탄약을 제공합니다. 이런 식으로 나는 누군가가 일하고 있다는 것을 알고 비 효율성과 함께 사는 것이 더 쉽다는 것을 알게되며 결국에는 다림질 될 것입니다.

운이 좋기를 바랍니다. 불가능하지는 않지만 확실히 할 수 있습니다.

Answer 2

당신의 큰 사업은 다른 모든 사업처럼 들립니다. 이러한 특성 중 몇 개가 귀하에게 적용됩니까?

1. 서버, 운영 체제, 시스템, 언어, 데이터베이스 등 다양한 생태계.
2. 시스템의 복제 (예 : 합병의 두 회사에는 약간 다른 방식으로 동일한 시스템을 수행하는 시스템이 있습니다).
3. 많은 중복 데이터베이스; 진실의 원천은 없습니다.
4. 여러 응용 프로그램에서 공유하는 데이터.
5. 코드를 테스트하기가 어렵다는 많은 복잡성과 종속성.
6. 한계를 중심으로 노력하기위한 "실질적인"노력으로 인한 많은 복잡성.

나는 상식이나 전문성이나 어떤 마술도 생산을 위아래로 전달하고 있다고 생각하지 않습니다.

Answer 3

한 가지 생각은 프로젝트를 감독하여 비즈니스와 일치하는지 확인하는 사람들의 그룹을 갖는 것입니다. 일이 기차 난파선이되는 것을 막기 위해서는 리더십이 필요합니다.

스크럼에는 스크럼의 개념이 있다는 것을 알고 있습니다. 기본적으로, 각 팀의 대표는 매일 (또는 경우에 따라 자주) 만나 팀이 무엇을하고 있는지, 오늘날의 일을하고있는 일을 말하고 장애물 (다른 팀일 수 있음)을 논의합니다.

또한, 일반적으로 민첩한 관행은 변화를 예상한다는 점에서 정확히 당신의 문제를 해결합니다.

따라서 경영진이 물건을 추적하지 않으면 내부에서 정말 좋은 의사 소통과 리더십이 있어야합니다.