Вимоги до ділових людей?

Які методи, здається, найкраще справляються з вимогами нетехнологічних ділових людей? Я працюю з командою, яка намагається зібрати специфікацію для проекту. Щоразу, коли ми зустрічалися, і це зводиться до очікувань на наступну зустріч, ми просимо ділових людей повернути свої вимоги. Зазвичай вони відповідають на щось подібне: "Ну, ви думаєте, ви, хлопці, могли зірвати прототип, щоб ми могли побачити, що нам подобається на наступному тижні ... ви знаєте, не з якимись даними чи чим-небудь, оскільки це прототип, просто функціональність". Це це проект на 6 місяців плюс, що, очевидно, нездійсненно (нам слід було б розробити всю річ!), і ми навіть не знаємо, що прообразувати без якоїсь специфікації. Чесно кажучи, я думаю, як і більшість людей, вони мають певне уявлення про те, чого хочуть, вони просто не думають про це цілеспрямованим чином, необхідним для збору справжніх вимог. Як альтернативу просто сказати їм, "Дайте нам те, що ви хочете, або ми не можемо / не будемо робити жодної роботи" (ми хочемо, щоб вони були задоволені результатами), чи є способи допомогти їм вирішити, що вони хочуть? Наприклад, ми могли б сказати їм:

“Накресліть кілька екранів (у Powerpoint, на серветці, будь-який інший), на якому відображається потрібний інтерфейс користувача, з усіма даними, які ви хочете побачити, та описом функціональності в полях. Виходячи з цього, ми відполіруємо його та створимо бекенд на основі цього набору вимог до поведінки. "

АБО

"Не хвилюйтеся, як це буде виглядати зараз (номер 1 відкладений). Просто дайте нам список усіх потрібних даних про кожну річ, яку програма відстежує. Тож для "Клієнта" ви можете перелічити: ім'я, адресу, номер телефону, замовлення тощо. Це не повинно бути ідеальною структурою бази даних, але ми можемо щось вирішити з цього питання і отримати уявлення про те, що ви шукаєте "

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

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

Кілька уроків, які я засвоїв:

• Різні зацікавлені сторони думають на різних рівнях абстракції.

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

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

• Розділяй і володарюй

  Якщо ви не хочете, щоб щось було зроблено, надішліть це комітету.

  Не зустрічайтеся з комітетами. Зберігайте ці зустрічі якомога менше. YMMV, але, на мій досвід, ідеальний розмір - 3-4 людини (включаючи себе) для відкритих сесій і 2-3 людини для закритих сесій (тобто коли вам потрібно відповісти на конкретне питання).

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

• Зустріч без підготовки - це зустріч без мети.

  Кілька інших відповідей / коментарів посилаються на техніку солом’яної людини, яка є відмінною для тих клопітких людей, на які ви просто не можете отримати відповіді. Але занадто не покладайтеся на солом’яних людей , інакше люди почнуть відчувати, що ви їх переправляєте. Ви повинні обережно підштовхувати людей у ​​правильному напрямку і нехай вони самі придумують специфіку, щоб вони відчували, як вони їм володіють (і в певному сенсі, вони ними володіють).

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

  Одного разу в цей момент я виявив, що найефективніше працювати з конструкціями високого рівня, такими як "Використовувати випадки", які, як правило, є приємними для всіх, але все одно важливо задавати конкретні питання. Якщо ви почнете з "Як ви виставляєте рахунки своїм клієнтам?" , ви дуже довгу зустріч. Задавайте питання, які передбачають процес, а не знімати процес під час руху: Що таке позиції? Як вони обчислюються? Як часто вони змінюються? Скільки існує різних видів продажів чи контрактів? Де їх друкують? Ви отримуєте ідею.

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

• Відкладіть дискусії поза темою .

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

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

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

  Різні аналітики вирішують це по-різному; дехто любить саму публічну дошку або журнал фліп-чартів, інші мовчки торкаються її до своїх ноутбуків і обережно заглиблюються в інші теми. Що б ти не відчував себе комфортно.

• Вам потрібен порядок денний

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

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

• Знущайтеся з цього

  Якщо ви використовуєте PowerPoint або Visio як макетний інструмент, ви будете страждати від проблеми, яка виглядає занадто відшліфованою . Це майже незвична долина користувальницьких інтерфейсів; люди відчуватимуть себе комфортно з малюнками серветки (або створеними на комп'ютері малюнками, схожими на малюнки серветки, використовуючи такий інструмент, як Balsamiq або Sketchflow ), оскільки вони знають, що це не справжня річ - з тієї ж причини, коли люди можуть дивитися героїв мультфільмів. Але чим більше це буде схоже на справжній інтерфейс, тим більше людей захочуть його вибрати і лапати, і тим більше часу вони витратять на сперечання про деталі, які в кінцевому рахунку незначні.

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

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

• Будьте терплячі.

  Для багатьох програмістів важко повірити, але для більшості нетривіальних проектів ви не можете просто за один раз сісти і вибити повну функціональну специфікацію. Я не просто кажу про терпіння під час однієї зустрічі; Аналіз вимог є ітеративним так само, як і код. Група А щось говорить, а потім Група Б каже щось, що повністю суперечить тому, що ви чули від групи А. Потім група А пояснює невідповідність, і виявляється, це те, що група C забула згадати. Повторіть 500 разів, і у вас щось приблизно нагадує істину .

  Якщо ви не розробляєте крихітний додаток CRUD (у такому випадку чому взагалі не турбуєтесь?), То не сподівайтесь отримати все необхідне за одну зустріч, або дві, або п'ять. Ви будете багато слухати, багато говорити і багато чого повторювати. Що не страшне, пам’ятайте; це шанс створити деякий зв'язок з людьми, які неминуче збираються підписуватись на вашу доставку.

• Не бійтеся змінити техніку чи імпровізувати.

  Різні аспекти проекту можуть насправді вимагати різних методів аналізу. У деяких випадках класичний UML (Use Case / Activity diagram) чудово працює. В інших випадках, ви можете почати з бізнес-KSI, або мозковий штурм з картою розуму, або зануритися прямо в макети, незважаючи на попереднє попередження.

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

• Тримайте вухо до землі.

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

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

• Нарешті, прочитайте між рядків .

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

  Настільки банально і нечутно, як це звучить, Five Whys - це справді корисна техніка. Щоразу, коли у вас є така "відверта" реакція на коліна (не те, щоб ви коли-небудь це говорили вголос), зупиніть себе і перетворіть це на питання: Чому? Чому ця інформація повторно вводиться чотири рази, потім її надруковують, фотокопіюють, сканують, друкують знову, прикріплюють на дошці, знімають цифровою камерою та нарешті надсилають електронній пошті менеджеру з продажу? Там є причина , і вони можуть не знати , що це таке, але це ваша робота , щоб з'ясувати. Удачі в цьому. ;)

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

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

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

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

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

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

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

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

Багато хто має ці загальні уявлення, що ти програміст, тому ти знаєш, як створити всі програми. Сайти електронної комерції все однакові, правда?

Почніть з малого. На жаль, поки ви не отримаєте щось перед ними, процес просто не реєструється. Якщо вам нічого не минати, то просто підробіть це.

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

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

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

• Проведення демонстрацій Що важливіше для завоювання клієнтів? Які частини програми або функціоналу потрібно виділити, і які потрібно повністю відшліфувати? Чи можете ви надати мені демонстраційну макет, використовуючи нотатки для запису, картонні коробки або інші стояки, які ви хотіли б працювати?

• Інформація про ринок / конкуренцію Для кожної історії користувача, що ми робимо, що схоже на наших конкурентів? Інший? Яку історію розповідають наші конкуренти, і чи намагаємось ми копіювати / наслідувати / вдосконалювати / вносити інновації / бути цілеспрямовано різними?

• Відкриті запитання Що з вимог та дизайну є інформацією, в якій ви впевнені, а що таке експеримент? Де ми будемо спробувати альтернативи, щоб побачити, яка з них працює? Якщо ви переглядаєте кілька альтернативних варіантів, і ви сказали нам лише одну, які інші ви розглядаєте?

Потім намалюйте деякі межі:

• Будь ласка, не накладайте на мене технічних обмежень . Ділова особа не повинна говорити вам "використовуйте Windows, тому що це краще, ніж Linux". Однак вони можуть надавати інструкції відповідно до того, що "весь наш цільовий ринок використовує вікна, наша програма повинна працювати на Windows, щоб досягти успіху"

• Не хвилюйтесь про дизайн Особливо якщо ви маєте справу з продажами або маркетинговими орієнтованими людьми, вони, як правило, заграють проблемами дизайну. Знову ж таки, звузити область інформації до того, на що вони спеціалізуються - "блакитний тут красивіше", мабуть, не підходить. "Наш конкурент використовує тему синього кольору, і існує вже з 80-х, для частин нашої програми, де ми не інновації, ми повинні використовувати синю схему, щоб повідомити, що ми не нові", ймовірно, це доречно. "Ім'я має бути вгорі екрана", мабуть, не підходить, але "найважливіша інформація на цій сторінці - це ім'я користувача та баланс банківського рахунку", ймовірно, є. Переконайтеся, що дизайнер бере участь у перекладі цих вимог в інтерфейс користувача.

• Запишіть рішення Переважно вкладайте їх у договори чи інші зобов'язання, які ви берете на себе. Пам'ятайте, що рішення, яке замовник не розуміє, не вартує документа, про який він пише. Вихід із клієнта на "додаток працюватиме на порту 1521" не стоїть стільки, скільки клієнт підписується на "додаток буде працювати на користувальницькому, конфігуруваному порті, який може потребувати спеціальної конфігурації для брандмауера та безпеки при розгортанні. "

З вашої точки зору, щоб заохотити процес продовжувати:

• Забезпечуйте зворотний зв'язок на тому ж рівні абстракції. Це є у всіх напрямках, наприклад, для одиниць - якщо замовник говорить щомісяця за кількістю користувачів, не відповідайте в гігабітах пропускної здатності. Або, для випадків використання - опишіть функціональність з точки зору випадків робочого використання, а не модулів чи виправлень помилок чи функцій.

• Забезпечте змістовне спілкування. Сформулюйте питання, які у вас є, та додаткову інформацію, яку ви виявили або шукаєте, стосовно інформації, яка була надана вам. "Ми йдемо з Linux", ймовірно, погано написані відгуки, тоді як "наші тести показують, що програма працює більш гладко, коли розміщується на машинах Linux та отримується доступ до IE у Windows", можливо, буде більш підходящим.

• Ітерація швидко Щоб клієнт займається, забезпечують швидкі, значущі поновлення і ітерації. Характеристики та інформація, яку було недоступно або легко отримати при запуску процесу, може зайняти багато зусиль у вашого замовника, який, ймовірно, платить вам, поки ви не платите їм за будь-яку їх роботу. Залучення клієнта до залучення та вкладення коштів у цей процес може допомогти, коли робота закінчиться тим, на що доведеться витратити час і сили.

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

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

Іноді купа швидких прототипів, з якими може заграти замовник, може бути єдиним способом експериментально виявити та конвергувати якесь корисне рішення для потреб клієнта (озвучене та необмежене). Це може бути або не підходить для будь-якого договору без відкритого типу.

ДОБАВЛЕНО: Якщо ви спробуєте вимусити документ про вимоги у клієнтів, які не мають необхідного досвіду, це потенційно може бути величезним червоним прапором, що свідчить про майбутню катастрофу.

Не вимагайте інтерфейсу чи вимог до даних, не вимагайте вимог щодо функціональності.

Запитайте їх про те, що вони хочуть робити. Нехай вони пройдуть, як вони хотіли б використовувати додаток. Залиште деталі, такі як інтерфейс користувача, дані тощо, для початку.

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

Після того, як ви це зробите, зробіть швидкий макет (мені подобається Бальзамік ). Просто припустимо, яким буде інтерфейс / дані, і не витрачайте на це багато часу. Потім поверніть цей макет до Клієнта. Звідти вони можуть сказати вам "нам не потрібні ці поля" або "Ми насправді хочемо список номерів телефонів #, а не лише одного", або "це повинно бути спадне меню, а не список".

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

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

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

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

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

Я б сказав їм, що ви будете розвивати функцію програми за особливістю. До наступної зустрічі скажіть, що через 1-2 тижні ви збираєтесь працювати X кількість функцій. Це може бути 1, 2, 3 або більше.

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

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

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

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

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

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

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

Що я роблю, це так: говорити з ними про те, що вони хочуть, на своїй доменній мові. Вони не зможуть або не бажають бути точними, як ви сподіваєтесь (використовуйте випадки, дизайн за контрактом тощо), але ви можете бути точними в перекладі їх виду розпливчастого та легкого списку десідерата в фактичний дизайн, і , отже, проектний документ. Якщо вони планують вам час, щоб це зробити формально, тим краще. Якщо ні, створіть імпровізований, неофіційний, який ви можете повторити.

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

Без менеджера, який знає щось програмування, я ніколи не мав успіху в цьому. Швидше за все, єдиний підхід, який я знайшов, - це спостерігати за тим, що відбувається насправді.

Я думаю, що програмісти мають кращі можливості передбачити, як буде виглядати програма до її створення. Прототипування паперу може бути ефективною методикою подолання цього. Паперові прототипи порівняно «дешеві» для побудови. Проводячи своїх клієнтів за допомогою простого паперового прототипу, ви демонструєте потребу в мисленні "зосередженим способом, необхідним для збору справжніх вимог". І це дає конкретний спосіб зосередитись: насправді намагаються використовувати додаток, який є у вас в голові!

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

Я працював на веб-сайті, де інші партнери були більш орієнтовані на бізнес. Я постійно просив конкретні вимоги різними способами. Їхня відповідь була в основному: "Ви хлопець з комп'ютера, ми очікуємо, що ви зрозумієте це. Ми вважаємо за краще займатися бізнесом". Вони не переймалися конкретними подробицями ... до виходу першої версії! Вони були набагато більш захоплені вимогами після звільнення, даючи всілякі відгуки, які заощадили б мені багато часу , коли я спочатку запитав.

Тому я вирішив, що ітерація є ключовим: створити мінімально життєздатну версію та вдосконалити її на основі зворотного зв'язку. Якщо вимоги занадто розпливчасті та загальні, приймайте рішення на основі "Що найпростіше, найшвидше виконання?" (заборона основного дизайну / архітектури системи). Не варто занадто зважувати припущення, виходячи з того, що ви вважаєте «правильним». Це просто закінчиться витрачати час, оскільки велика ймовірність того, що ваш продуманий процес відрізняється від ваших клієнтів.

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

Насправді зі мною трапилось: запит на реєстраційну форму із спеціальним кодом запрошення. Ідея полягала у створенні вірусного процесу реєстрації, де кожен новий користувач отримав кілька запрошень. Я витратив багато часу на те, щоб коди були унікальними і їх можна було використовувати лише один раз. Я також доклав чимало зусиль, щоб зробити процес максимально без тертя, зробивши поля імені та прізвища необов’язковими. Врешті-решт, партнери попросили про ці зміни: ім’я та прізвище обов'язкові, "реєстраційний код" дійсний, якщо взагалі щось було введено в поле ... зітхніть ~