Це відповідальність розробника програмного забезпечення, щоб зрозуміти, що мав на увазі клієнт під своїм запитом?

Вигляд питання «так / ні» і чому?

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

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

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

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

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

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

Якщо це ваша робота з розумінням, це ваша робота, щоб задавати питання, поки ви цього не зробите

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

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

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

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

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

На мою думку, і замовник, і розробник повинні мати однакове розуміння проблеми та її вирішення.

Якщо ви не розумієте запит, ви не можете створити рішення.

Отже, ви повинні прочитати характеристики. Якщо специфікація недостатньо чітка (або немає письмової специфікації), має бути хтось, хто може дати відповіді.

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

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

Звичайно, якщо ви не задасте цих запитань, вам знадобиться набагато більше часу, щоб заповнити / змінити систему, і результат може бути не тим, що хотів замовник, що спричинить більше затримок і ТАКОЖ погано відображатиметься на менеджера проекту та його компанія, принаймні в очах замовника.

Є кілька причин, через які менеджер проекту може не вирішити вас:

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

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

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

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

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

Замовник та розробники повинні співпрацювати, щоб вдосконалити своє розуміння системи.

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

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

Це ґрунтується на деякій новій інформації в коментарях до оригінального питання.

Заява, що

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

походить від керівника проекту; викладене обгрунтування є

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

Тож те, що вам конкретно кажуть, уникати, це турбує клієнта питаннями .

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

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

що роблять ці люди хочуть ??? »

запитати щось подібне,

У пункті 17 документа про вимоги йдеться про те, що foobar повинен роздмухувати мороз; на кого з цих трьох морозів йдеться? "

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

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

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

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

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

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

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

• Розмір команди
• Стандарти компанії
• Те, як звик працювати начальник
• Різна експертиза серед членів команди

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

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