З вашої розмови про розробників та власників продуктів, мені здається, у вас немає середньої людини, відповідальної за функції вашої організації.
Що ж, в моїй організації я є такою людиною. Я інженер з вимог, той, хто навчився робити хороші технічні характеристики та вибирати функції, які призводять до високоякісного програмного забезпечення з зручним дизайном взаємодії. (В інших організаціях саме та людина, яка працює на UX, отримує таку ж роботу, можливо, ви будете більш знайомі з цим терміном).
І я можу вам сказати: отримати хорошу специфікацію важко. Звичайно, розробники ненавидять це робити. Це тягар для них - вони там, щоб створити програмне забезпечення, а не думати про владні ігри серед зацікавлених сторін та ментальні моделі лінивих користувачів. Але ти знаєш що? Це також є тягарем для власників продукції. Вони краще не знають, які функції повинно містити їх програмне забезпечення, ніж розробники або користувачі. Створення життєздатних специфікацій - це засвоєний навик, і якщо ти ніколи цього не навчився, ти не можеш у цьому бути хорошим. Звичайно, є багато розробників і власників продуктів, які можуть це зробити, тому що їм довелося це робити в попередніх проектах. Але середній власник продукту чи розробник бореться з цим, адже це, природно, не їхня робота. Не кожен, хто може керувати автомобілем, може спроектувати автомобіль; аналогічно,
Чи можете ви розробляти програмне забезпечення без вимог інженера? Звичайно, ти можеш. Але покласти всю вагу його специфікацій на плечі власника продукту не є справедливим і не добре для результату проекту. Тим більше, що він стикається з завданням, яке незвично для нього важке, отримати корисний внесок та підтримку інших. Якщо ви опинилися в такій ситуації, не дивіться на свого бідного власника товару і не кажіть "скажіть мені, що зробити для вас, і я зроблю вас", він справді не знає, що йому потрібно. Але обговорення з вами допоможе йому сформулювати свої думки та вивчити його ідеї.
Коли в структурі проекту немає інженера-вимог, виникає ще одна проблема: немає модератора. Всі розробники - з технічної сторони, всі власники продуктів - з боку бізнесу. Коли обидві культури стикаються, можуть виникати конфлікти, причому кожна сторона судить другу за дурну та необгрунтовану (бо вона використовує власну систему цінностей для судження). Отже, поговоріть з власником продукту про можливі функції, але будьте ввічливі та терплячі, навіть якщо ви думаєте, що він цього не заслуговує; Успіх проекту залежить від того, наскільки ви добре можете порозумітися, а іноді приймати неоптимальне рішення краще, ніж взагалі не приймати рішення через конфлікт. Можливо, буде корисно встановити ієрархію та дати одному з вас останнє слово, оскільки це запобігає конфліктам у тупику. Якщо він отримає останнє слово, відмовтеся від нього, навіть якщо ви вважаєте, що це несправедливо.
Про "пасивну" частину: якщо у вас немає ідей, не намагайтеся придумати щось, щоб проявити активність. Якщо власник продукту вже незахищений і не знає хороших критеріїв для оцінки своїх чи своїх ідей, дивні ідеї "просто мати щось" ще більше ускладнюють ситуацію. Придумати хороші ідеї для функцій - це не магія, але вона потребує знань. Якщо ви цього не вивчили з підручників, вам, напевно, знадобляться кілька років досвіду розробників, особливо в проектах, де ви піддаєтесь користувачам або створеним користувачем даними про зручність користування (аналітика, вимірювання задоволеності), перш ніж ваш мозок відібрає схеми для себе і ти починаєш помічати: тут є проблема, яку ми можемо вирішити. Користувачі, здається, щось не вистачає на цій сторінці, що це може бути? Тоді у вас будуть хороші ідеї, щоб поділитися.
Висновок 1: У проектах, які не вимагають вимог, добре вносити пропозиції, коли у вас є. Робіть це з чуйністю і тактовністю - обов’язково потрібно уникати конфлікту, навіть якщо це означає, що ваша добра ідея забивається в бутон.
А якщо ви в команді з вимогами інженера?
Я люблю чути ідеї про всі функції! Так, іноді ідеї розробників страшні (коли вони хочуть змусити інтерфейс користувача слідувати логіці програмування). Ідеї власників продуктів також часто жахливі (коли вони хочуть, щоб сонце та місяць були на бюджетному бюджеті - о, а користувач повинен вводити сторінки особистої інформації найвищої якості даних, не отримуючи нічого взамін). Але моя робота - розробити специфікацію, яка буде корисною для всіх в команді. І навіть якщо ваша ідея ніколи не спрацює, почувши, це дає мені зрозуміти, що ви хвилюєтесь. Можливо, ви вибрали неправильне рішення, але це не робить вашу стурбованість менш обгрунтованою. Якщо ви помітили це, його, ймовірно, потрібно вирішити (або мені потрібно придумати причину, чому це не загроза). Якщо у вас є інженер-вимога, відповідальний за специфікацію, ніколи не соромтеся звертатися до них із пропозиціями. Якщо вони вас не чують, вони роблять щось не так (зауважте, що "вважати" не означає "приймати").
Інженер з вимог повинен розглядати проект з точки зору кожного з зацікавлених сторін окремо (а іноді і одночасно). Ми лише людина, і часто в цьому не вдається. Якщо ви знаходитесь там, щоб надати свою справжню точку зору, а не точку зору, яку ми вважаємо, що ви маєте, ваш внесок дуже цінний.
Тут ви можете бути більш вільними у своїй поведінці. Це моя робота робити танець чутливості. Не будьте відкрито агресивними, це заважає моїй роботі, але вам потрібно менше самоконтролю та культурної / комунікативної обізнаності, тому що я можу перейняти цю слабкість. Ви також не пливете, в ситуації, коли є дві суперечливі ідеї, і ніхто не може судити, що краще. Я повинен знати, що, і якщо це не вийде, це моя голова в петлі.
Висновок 2: Якщо в команді є інженер-вимога, перейдіть до них із пропозиціями щодо функцій продукту. Цього разу вам не потрібні оксамитові рукавички.
І, нарешті, що робити, якщо немає вимог інженера, власник продукту перевантажений і бореться за ідеї, начальник наголосно дивиться на вас, а у вас немає ідей запропонувати?
У вас є кілька варіантів. Один, як ви вже згадували, кинути. Не всі організації працюють таким чином, і якщо це середовище для вас не підходить, знайдіть краще. Це буде добре для вас у довгостроковій перспективі.
Ви також можете зачекати і подивитися, чи щось зміниться. Наступний проект може мати більш досвідченого власника продукту (або одного з більшим лідерством). Але ти не можеш назавжди зупинитись.
Третій варіант - насправді вивчити деякі вимоги до інженерії самостійно. Цей навик дуже затребуваний в наші дні. Навіть якщо ви ніколи не плануєте займати посади, де ви інженер з повним робочим днем, наявність цієї навички підвищує вашу цінність як розробника, оскільки дозволяє краще розуміти інших членів вашої команди (та ваших користувачів) та робить процес розвитку проходить більш плавно. І вам не доведеться заглиблюватися в всю глибину цього. Підручник початкового рівня, який пояснює завдання, робочі процеси, ментальні моделі та орієнтовані на користувачів моделі даних, вже дозволить вам відзначити безліч можливостей удосконалення в програмному забезпеченні, розробленому командою бізнесменів та розробників. Дон ' не звертайтеся до найгустіших книг, що означають посилання на науковців (як, наприклад, недавній переклад Поля на англійську мову) - вони є переліком усіх можливих методів для кожного невеликого кроку, без пояснення, як насправді це зробити. Виберіть щось орієнтоване на практику.
Якщо ви спробуєте це і виявите, що у вас немає особистого інтересу до району, це все одно добре. Не змушуйте себе робити те, що вам не подобається. Але вам, напевно, слід шукати роботу в організації з іншою структурою команди.
Висновок 3: Замість того, щоб чекати роками, щоб зрозуміти інтуїтивне розуміння, прочитайте книгу чи дві, і ви вже будете мати хороші ідеї, щоб запропонувати