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

Вид так/не питання і чому?

Is it the responsibility of the software developer to understand what the customer meant with his/her request or is it the responsibility of the customer to properly explain his/her request to the developer?

Ситуація на роботі в даний час «клієнт вже пояснив нам, чого він хоче.

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

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

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

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

12
@ Keith-Thompson Відповідь полягала в тому, що оскільки я не перший розробник системи, ми не повинні турбувати представника клієнта з більшою кількістю запитань, але спробуйте і, якщо необхідно, витратите додатковий час на інтерпретацію питання.
додано Автор Dave Batton, джерело
@ Keith-Thompson Керівник проекту.
додано Автор Dave Batton, джерело
для танго потрібно два
додано Автор gnat, джерело
@JohnNevermore: Добре, але чи надає керівник проекту обґрунтування цієї позиції? Чи не хоче клієнт турбуватися про запитання?
додано Автор Keith Thompson, джерело
Якби я був замовником, і я дізнався, що розробник не розуміє мої вимоги і і не сказав, що я не повинен запитувати роз'яснення, я не буду радий. Чи можете ви принаймні отримати ясність про те, звідки виникла річ "не задайте більше питань"?
додано Автор Keith Thompson, джерело
@JohnNevermore: Я хотів би стверджувати, що змусить команду очолити перехід на питання. Це поза межами вашого впливу, що там, де розробники перед вами, і це не змінює, вам потрібно зрозуміти проблему. Якщо він відмовляється відповідати, біжіть.
додано Автор keppla, джерело
Чи не існує способу перейти до іншої команди/проекту, але всередині однієї компанії?
додано Автор Radu Murzea, джерело
Я також міг би почати документування того, що я розумію за вимогами і, можливо, електронною поштою, потім до керівника команди; "Це те, що ми збираємося реалізувати, чи все це виглядає нормально?". Червона стрічка може бути цікавою (TM)
додано Автор Nick Keighley, джерело
Хороший бізнес-аналітик може допомогти у спілкуванні. Якщо у вас немає такої доступної для вас, у вас буде кращий результат, якщо ви зможете перестати думати про код на секунду, поставити себе на місце і спробувати зрозуміти, в чому їхня проблема. Вони, швидше за все, не розуміють нічого про програмне забезпечення.
додано Автор JimmyJames, джерело
були там ... T_T
додано Автор Songo, джерело
Накрийте дупу, отримайте електронну пошту, якщо вам говорять, що ви не повинні ставити запитання і зберігати її для використання пізніше, якщо хтось повернеться до вас. Потім введіть код часу, який ви отримали. Ваша відповідальність полягає в тому, щоб виконувати накази або ризикувати звільненням.
додано Автор Seymour, джерело
Тому робота очікує, що ви повірите, що клієнт віддасть перевагу, щоб ви витрачали свої гроші на неправильну річ, а не вимагали роз'яснень? Так, я теж можу кинути палити.
додано Автор Devsman, джерело

9 Відповіді

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

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

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

41
додано
У таких випадках, як правило, начальство просто хоче, щоб щось вони могли пропустити як вищезгадану реалізацію, показуючи, що вони на вершині; тоді клієнт каже: "Добре, але ми можемо зробити це замість цього", і розмова може відбутися. Ще дуже поганий сценарій.
додано Автор KeithS, джерело
Як анекдот: кожен раз, коли я бачив таку поведінку, це було тому, що клієнту було гарантовано, що функція вже реалізована , і якщо хтось буде запитувати як зробити це Це виявляло б їхню брехню.
додано Автор keppla, джерело
@KeithS: так, це буде гарний спосіб, що ніхто не втратить обличчя. Але, в деяких особливих випадках, боси зуміли погодитися на доставку чогось логічно неможливого, і хвалилися про успішні тести ... :) Афіри, деякі жарти з форумів stackoverflow ставлять запит на програму, яка вирішує проблему зупинки на сайт торгів проекту. Відповіді були дивовижні, хтось, мабуть, вже вирішив цю проблему :)
додано Автор keppla, джерело
Перше речення говорить про все. Якщо ви збираєтеся кудись, то найважливішим фактором у визначенні того, що ви досягнете свого призначення, є знання того, що саме призначення. Крім того, єдиним найважливішим фактором для визначення успішності проекту є знання успішної реалізації. Це так само смішно ставити під сумнів останнього, як і перше.
додано Автор JimmyJames, джерело

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

Given/When/Then scenarios make it possible for you to get into detail about what needs to happen and because they're written in plain English and they're structured, you can use them to communicate to your superior and client: "Listen, I've gotten to this point and I have no idea what the system is supposed to do here".

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

6
додано

На мій погляд, як (клієнт, так і розробник) повинні отримати те ж саме] розуміння проблеми та її вирішення.

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

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

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

6
додано

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

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

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

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

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

3
додано

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

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

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

2
додано

Це засноване на деякій новій інформації в коментарях до початкового питання.

Це твердження

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

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

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

Отже, те, чого конкретно вам слід уникати, це турбувати клієнта питаннями .

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

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

Що хочуть користувачі ""

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

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

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

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

2
додано
+1 для просування цього до керівництва проекту. Забезпечення того, щоб у кожного були необхідні ресурси, це основна відповідальність керівництва проекту - це включає необхідну інформацію.
додано Автор Julien Hoarau, джерело

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

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

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

2
додано

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

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

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

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

1
додано

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

  • Розмір команди
  • стандарти компанії
  • Як працює начальник
  • Серед учасників команди є інший досвід

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

EDIT: Most importantly, the customer may not know he made such poor requirements, and the process of gathering requirements is often long and tedious, but it's an important process, and if it falls on you because no one else does it, then you should do it with them.

1
додано
android_jobs_ua
android_jobs_ua
120 учасників

Публикуем вакансии и запросы на поиск работы по направлению Android. Здесь всё: full-time, part-time, remote и разовые подработки.