Як вирішити цю, на жаль, негіпотетичну ситуацію з кінцевими споживачами?

Я працюю в середній компанії, але з дуже невеликою інформаційною силою.

Минулого року (2011 р.) Я написав заявку, яка користується великою популярністю у великої групи кінцевих користувачів. Ми закінчилися в кінці минулого року, і деяка функціональність (я буду називати funcA відтепер) не була додана в програму, яку хотіли в самому кінці. Отже, ця програма працює в прямому ефірі / виробництві з кінця 2011 року, я можу додати без проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

Примітка. Жодне з цих обговорень не передбачає «Дед-строки», «помилки» та «дискусії» про те, хто платить і т. Д. Це факти - і факти не мають значення (ну, вони так і роблять, але ними можна маніпулювати так багато способів…. ) в офісній політиці.

Організаційно я відчуваю проблему.

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

Кілька моментів, щоб задати контекст моєї відповіді:

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

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

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

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

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

Це не повинно бути вашим словом проти їхнього, це має бути все в документації.

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

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