잠재적 이해 관계자가 너무 많은 경우 개발 프로젝트를 시작하는 방법

방금 (단독) 웹 응용 프로그램 개발자로 대학에서 새로운 직업을 시작했습니다.

이 대학에는 수많은 이질적인 시스템이 있지만 모두 잘못 코딩 된 레거시 시스템이 있습니다. 대부분 PHP로 작성되어 출석, 시험 결과, 표시 등을 처리합니다.

첫 번째 작업은이 많은 데이터를 통합하는 시스템을 구축하는 것입니다. 현재이 시스템은 친숙한 API없이 다양한 데이터베이스에 저장되어 있습니다 (기존 시스템은 데이터와 뷰를 분리하지 않고 바닐라 PHP로 코딩 됨) 학생들에 대한 목회 정보를 기록 할 수있는 새로운 플랫폼을 통해 교사 및 교직원에게 유용한 방식으로 제시하여 학생들의 문제에 신속하게 대응할 수 있습니다.

첫 만남에는 18 명이있었습니다! 대다수를 대표하는 명확한 지도자 나 목소리는 없었다. 식별 가능한 클라이언트가 없습니다 . 이 회의는 교수진의 소소한 기능에 대한 세부적인 구현 아이디어에서 데이터 입력에 Excel 스프레드 시트를 사용해야하는지 여부에 대한 논쟁으로 바뀌 었습니다.

당신이 상상할 수 있듯이 내 머리가 끝에 회전하고 있었다. 나는 실제로 좋은 아이디어가 많았지 만들을 수 없었습니다. 마케팅 대행사에서 개발 팀의 일원이되기 전에 이것은 매우 새로운 역할입니다. 프로젝트 관리자, 클라이언트, 디자이너, 개발자 등 매우 잘 정의 된 역할이있었습니다.

노련한 개발자 나 관리자가 동료를 프로젝트 팀과 유사한 것으로 끌어 올리는 방법에 대한 지침을 제공 할 수 있는지 알고 싶습니다. 민첩한 길입니까? 모든 다른 목소리를 어떻게 다룰 것인가? 일부 프로세스는 매우 신속하게 수행해야한다는 것이 분명합니다. 그게 무엇인지 잘 모르겠습니다.

현재 문제에 대한 해결책으로 "애자일 개발 프로세스"를 기대하지는 않습니다. 가장 먼저해야 할 일은 : 당신의 임무를 클리어하십시오 . 그것의 의미는:

• 자신의 책임이 무엇인지 분명히하다
• 다른 이해 관계자의 책임이 무엇인지 명확히
• 각 레거시 시스템을 담당하는 사람을 식별
• 웹 응용 프로그램을위한 클라이언트 (아직)가없는 경우 나중에 해당 응용 프로그램을 사용할 사람을 찾아서 시스템의 대표 사용자 (요구 사항을 논의 할 수있는 사람)로 통합 할 수있는 권한을 요청하십시오.
• 서로 다른 목표를 가진 다른 이해 관계자가 있다면, 그들의 요구 사항을 모으십시오 (예를 들어, 한 방에 18 명이 아니라 하나씩 하나씩 인터뷰함으로써). 결과를 목록에 작성하십시오. 그런 다음 우선 순위를 정하십시오.
• 릴리스 0.1에 대한 로드맵 (큰 그림)과 작은 사양을 작성하고 대표 고객뿐만 아니라 상사도 공식적으로 동의하도록합니다.
• 편집 : GlenH7의 의견 참조

이 작업에는 다소 시간이 걸릴 수 있습니다. 프로젝트의이 단계에서 많은 코드를 작성하지 않을 것입니다. 이러한 상황에서는 먼저 "요구 사항 엔지니어링"을 수행해야합니다. 그러나 작은 시작, 큰 생각. 첫 번째 릴리스를 개발 한 후에는 보여줄 내용이 있으며 이해 관계자 등과 다시 요구 사항에 대해 논의해야합니다.

이 프로젝트를 실제로 원하는 사람들을 무리에서 분리하십시오.

정치가 많기 때문에 누군가가 초대하지 않으면 가장 화나게 될 사람에 의해 멤버십이 결정된 참석자 목록과 함께이 회의를 구성했습니다. 일어난다. 이 목표는 완수되었지만 개발자는 결정된 것이 없음을 발견했습니다. 무엇을해야 할지가 할당되지 않았습니다. 운이 좋으면 다음 모임이나 신의 금지를 예약하고 매월 셋째 화요일에 재발 모임을 설정합니다.

다음으로위원회, 소위원회 및 태스크 포스 팀이 구성 될 것입니다. 이건 더 낫지 만 모두 똑같이 가치가 없다는 것을 알게 될 것입니다.

마지막으로, 누가이 프로젝트에 관심이 있는지 알아볼 것입니다. 누가 제대로 시간을 내고 싶어하는지. 바라건대,이 사람 (들)은 시간을 할애하고 이미 긴 할일 목록에 다른 항목을 만들지 않고 시간을 할 수있는 감독자를 가질 것입니다. 이 사람들을 최대한 빨리 찾으십시오! 상사의 기대를 관리하고 합의 된 양의 약속을 얻도록 도와주십시오.

원래 그룹의 많은 사람들 앞에서 귀가하기를 원하는 무언가를 얻으십시오. 그들은 모두 똑똑하고 교육받은 사람들 일지 모르지만 많은 사양을 읽지는 않을 것입니다. 그들은 어떤 것을 좋아하고 다른 것을 미워하고 더 많이 원할 것입니다. 제안을 적어 두는 것은 아프지 않지만 게임에서 그 파티가 피부를 추적하도록하십시오. 모든 것을하겠다고 약속하지 마십시오. 가까운 미래에 할 수있는 일을 해결하십시오.

당신이 정기적으로 5 명 이상을 다루어야한다면, 일부 관리자는 몇몇 사람들이 참여하기를 원하지 않기 때문에 참여하기 때문입니다.

관찰 및 "필요"를 기반으로 기존 시스템을 강화 / 개선하고 실제로 눈에 띄는 이익을 얻을 수있는 위치에 집중할 수있는 아이디어 목록을 생각해보십시오. 유용하다고 생각되는 각각의 아이디어와 비 개발자들의 "합리적인"제안을 목록에 포함 시키십시오.

개발 노력에 "포함해야 할"기능 목록을 작성하십시오. 각 구성원에게 "투표"권한을 부여하고, 아마도 "고착성 별"형태로 각 구성원이 실제로 중요하다고 생각하는 것 옆에 별을 배치하여 원하는 것을 찾으십시오. 어떤 사람들은 수표에 서명하고 마지막 말 등을하면 더 많은 별을 얻게 될 것입니다. 로드맵으로 번역

1). 팀 조사 -각 구성원이 중요 / 필요 / 최우선 과제로 간주하는 사항 찾기

2). 신속하게 무언가를 얻으십시오 -모든 문제를 한 번에 해결하려고 시도하지 말고 "최소한"기능을 가져 와서 승인 한 다음 사용자의 피드백에 따라 일괄 적으로 진행하십시오.

삼). 피드백 및 다른 사용자의 피드백을 사용하여 개발 프로세스를 안내하십시오.

(빌드, 피드백 평가, 빌드, 피드백 평가) 헹구고 반복하십시오.

또한 "노력 포인트"또는 예상 시간을 완료하는 것을 고려할 수도 있습니다.이 또한 우선 순위 지정에 도움이 될 수 있습니다.

첫 번째 과제는이 프로젝트의 필요성을 파악하는 것입니다. 모든 사람들과 다시 만나서 해결해야 할 문제를 적어달라고 부탁하십시오. 그들이이 프로젝트가 해결책이 될 수있는 많은 방법에 대해 이야기하게하지 마십시오. 그들이 필요 / 문제를 진정으로 식별하도록 강요하십시오.

이를 수행하는 한 가지 방법은 각 메모에 개별적으로 해당 메모를 스티커 메모에 기록하도록 요청하는 것입니다. 그런 다음 선호도 다이어그램 을 실행하여 서로 다른 아이디어를 특정 요구에 그룹화 할 수 있습니다. 마지막으로, 가장 큰 요구 사항을 볼 수 있도록 투표를합니다 ( 다중 투표 ).

애자일은 고객 가치가 가장 높은 기능을 먼저 다룰 것을 상기시킵니다. 가장 큰 필요로 시작한 다음 실제로 짧은 시간 안에 할 수있는 첫 번째 작은 조각이 나올 때까지 해당 항목을 계속 분할하십시오.

키스-여정 만들기. 와 주셔서 감사합니다. 검토하고 해보세요. 우려 사항을 공유하여 문제를 해결하고 회의 후에도 머무를 것을 요청하면 측면 추적이 느려집니다. 가장 행복한 상태를 유지하기 위해 논쟁이있는 곳에서 투표로 결정하십시오. 모든 시스템에 참여하려는 동기는 그 방법에 대한 개인의 신념과 직접 관련이 있습니다.