Як розпочати проект розвитку, коли занадто багато потенційних зацікавлених сторін

Я щойно взяв на роботу в коледжі як (єдиний) розробник веб-додатків.

У коледжі є безліч розрізнених, але всі досить погано закодовані застарілі системи. В основному вбудовані в PHP, вони займаються такими речами, як відвідування, результати іспитів, оцінювання тощо.

Моє перше завдання - створити систему, яка містить багато цих даних, яка в даний час відпочиває в різних базах даних без будь-якого дружнього API, щоб витягнути її (існуючі системи кодуються у PHP ванілі без поділу даних та перегляду) з новою платформою для запису душпастирської інформації про студентів та корисно представляє її викладачам та старшим працівникам, щоб вони могли швидко реагувати на проблеми зі студентами.

У нашій першій зустрічі було 18 людей! Не було чіткого лідера чи голосу, який би представляв більшість. Немає ідентифікуючого клієнта . Нарада перегорнула від детальних ідей щодо впровадження незначних особливостей від керівників викладачів до аргументів про те, чи слід використовувати таблиці Excel чи ні для введення даних!

Як ви можете уявити, моя голова крутилася наприкінці. У мене було дуже багато хороших ідей, але я не міг їх почути. Це дуже нова роль для мене, перш ніж я був частиною команди розвитку в маркетинговому агентстві. У нас були дуже чітко визначені ролі: керівник проекту, клієнт, дизайнер, розробник.

Мені хотілося б знати, чи будь-які досвідчені розробники чи менеджери можуть дати мені певні вказівки щодо того, як я можу збити своїх колег у щось, що нагадує команду проекту. Чи є спритний шлях? Як би ви підійшли до поводження з усіма розрізненими голосами? Зрозуміло, що якийсь процес потрібно запровадити дуже швидко, я просто не впевнений, що це таке.

Я б не очікував, що будь-який "спритний процес розвитку" тут буде вирішенням вашої поточної проблеми. Першим для вас має бути: очистити свою місію . Це означає:

• уточнити, які ваші власні обов'язки
• уточнити, які обов'язки інших зацікавлених сторін
• визначте, хто відповідає за кожну із застарілих систем
• якщо для вашого веб-додатку немає клієнта (поки що), знайдіть того, хто його буде використовувати в майбутньому, і попросіть дозволу включити його в якості представника користувача вашої системи (людину, з якою ви можете обговорити вимоги)
• якщо є різні зацікавлені сторони з різними цілями, збирайте їхні вимоги (наприклад, опитуючи їх по одному, а не 18 людей загалом в одній кімнаті). Результати запишіть у список. Після цього починайте пріоритети.
• запишіть дорожню карту (велика картинка) та невелику специфікацію для випуску 0.1 і змусьте свого начальника, а також представницького клієнта офіційно погодитися на це
• EDIT: дивіться коментар GlenH7

Це може зайняти деякий час, напевно, ви не будете писати багато коду на цьому етапі проекту. У такій ситуації спочатку слід виконати деякі «вимоги до вимог». Але почніть з малого, подумайте великого. Після розробки першого випуску вам буде що показати, знову обговорити вимоги із зацікавленими сторонами тощо.

Відокремте тих, хто справді хоче, щоб цей проект працював зі стада.

Через багато політики, хтось зібрав цю зустріч із списком присутніх, де членство визначалось тим, хто найбільше засмутить, якщо я їх не запрошу. Це буває. Ця мета була повною, але як розробник, ви виявили, що нічого не вирішено. Нікому не було призначено, що робити. Якщо вам пощастило, їм вдалося запланувати наступну зустріч або не дай бог, вони встановили повторну зустріч на 3-й вівторок кожного місяця.

Далі відбудеться формування комітетів, підкомітетів та робочих груп. Це краще, але ви знайдете їх однаково нікчемними.

Нарешті, ви збираєтесь з’ясувати, хто насправді переймається цим проектом. Хто насправді хоче вкласти час, щоб зробити це правильно. Будемо сподіватися, що ця особа (і) матиме керівника, який дозволить їм зробити це, а не просто внести її в інший список, який вже є тривалим. Знайдіть цих людей якнайшвидше! Допоможіть їм керувати очікуваннями свого начальника та отримайте узгоджену кількість зобов'язань.

Знайдіть щось перед такою кількістю людей у ​​початковій групі, які навіть будуть намагатися повернутися. Вони можуть бути розумними та / або освіченими людьми, але вони не збираються читати купу технічних характеристик. Їм сподобаються одні речі, ненавиджу інших та хочуть більше. Не завадить записувати пропозиції, але спробуйте домогтися того, щоб учасник дотримувався певної роботи в грі. Не обіцяйте робити все. Просто вирішіть, що можна зробити найближчим часом.

Якщо вам доведеться регулярно спілкуватися з більш ніж 5 людьми, це тому, що якийсь менеджер змусив залучити кількох своїх людей, які не дуже хочуть бути там.

Створіть перелік ідей, які, на вашу думку, зміцнюють / покращують існуючі системи на основі ваших спостережень та їх «потреб» та забезпечують зосередження уваги на тому, де ви зможете досягти фактичних видимих ​​вигод. Додайте до цього списку кожну ідею, яку, на вашу думку, буде корисною, а також будь-які вигідні пропозиції «розумних» від неробочих.

Створіть список особливостей, які "повинні" бути включені у ваші зусилля щодо розвитку. Надайте кожному члену владу на "голосування", можливо, у формі "липких зірок" і з’ясуйте, чого насправді хоче кожен член, розміщуючи зірки поруч із тим, що вони вважають важливим. Деякі люди можуть отримати більше зірок, якщо вони підпишуть чек, мають остаточне слово тощо. Після цього, сподіваємось, ви та всі інші побачите, що важливо для всього, і, сподіваємось, вони погодиться на пріоритет, який буде потім перекладіть у дорожню карту

1). Огляньте команду - з’ясуйте, що кожен член вважає важливим / необхідним / першочерговим

2). Швидко дістаньте щось там - не намагайтеся вирішити всі проблеми одразу, отримайте функціонал «чистого мінімуму» і дозвольте їм, а потім колективно просувайте його на основі відгуків користувачів.

3). Використовуйте їх відгуки та відгуки інших користувачів для керівництва процесом розробки

(Створюйте, оцінюйте зворотній зв'язок, будуйте, оцінюйте зворотній зв'язок) .

Крім того, ви можете розглянути можливість додавання "балів зусиль" або прогнозованих годин для завершення .., що також може допомогти визначити пріоритетність.

Ваше перше завдання - визначити необхідність цього проекту. Проведіть ще одну зустріч з усіма цими людьми і попросіть їх записати проблеми, які потрібно вирішити. Не дозволяйте їм говорити про багато способів вирішення цього проекту. Змусити їх по-справжньому визначити потреби / проблеми.

Один із способів зробити це - попросити кожного окремо задокументувати ці потреби на клейких записках - одна ідея за клей. Потім запустіть діаграму спорідненості, щоб допомогти їм згрупувати ці різні ідеї під конкретні потреби. Нарешті, змусьте їх голосувати ( багатоголосне ), щоб ви могли бачити найбільші потреби.

Agile нагадує нам в першу чергу вирішити цю функцію, яка має найбільше значення для клієнта. Почніть з найбільшої потреби, а потім продовжуйте ділити цей предмет вниз, поки у вас не з’явиться перший невеликий шматок, який ви зможете зробити за короткий проміжок часу.

KISS - Складіть маршрут. Дякуємо всім, що прийшли, перегляньте це, зробіть це. Сторонне відстеження сповільниться, якщо ви звернетесь до нього, поділившись своєю турботою і попросіть їх залишитися ПІСЛЯ зустрічі. Приймайте рішення шляхом голосування там, де є суперечки, щоб залишатись найбільш щасливими. Мотивація до участі в будь-якій системі безпосередньо пов'язана з вірою людей у ​​її методи.