Как справиться с этой, к сожалению, не гипотетической ситуацией с конечными пользователями?

Я работаю в компании среднего размера, но с очень маленькими ИТ-специалистами.

В прошлом году (2011) я написал приложение, которое очень популярно среди большой группы конечных пользователей. Мы достигли крайнего срока в конце прошлого года, и некоторые функции (я буду называть funcA с этого момента) не были добавлены в приложение, которое было запрошено в самом конце. Итак, это приложение работает в режиме реального времени / производства с конца 2011 года, я мог бы добавить без проблем.

Вчера целая группа конечных пользователей начала жаловаться на то, что funcA, которого никогда не было в приложении, больше не работает. Нашим приоритетом в этой компании является то, что если приложение не работает, оно должно быть исправлено в первую очередь до приоритетных проектов.

Я сравнил код и запросы, и с 2011 года нет никакой разницы, что является доказательством. Затем я смог заставить одного из конечных пользователей признать, что он никогда не работал с proofB, но с тех пор этот конечный пользователь вернулся и сказал, что он работал ранее ... Я считаю, что толпа конечных пользователей ассимилировалась ее. Я также просмотрел свои заметки по этому проекту, в котором есть требования и ежедневные обновления, касающиеся проекта, в котором конкретно говорится: «funcA не достигнута из-за нехватки времени», proofC.

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

Хуже всего то, что сейчас группа начинает думать, и мой начальник и глава ИТ фактически начинают верить им, даже если в коде или запросах нет изменений. Что касается проверки состояния логики, она очень резкая и сухая до такой степени, что если 1 = 1, funcA не будет работать.

Итак, это конец описания моего сценария, но я стараюсь не испытывать недостатка в моих показателях производительности из-за этого, что, по сути, заставило бы меня перейти к устранению производственной проблемы, которая, вероятно, вступит во владение. 1 месяц.

Споры о легко наблюдаемых фактах на самом деле довольно легко разрешить: просто наблюдайте за фактами. Если я скажу «есть дерево с фиолетовым деревом за пределами моего дома», любой, кто сможет прийти ко мне домой, может проверить для себя правду или ложь моего заявления.

Если они жалуются на то, что FuncA раньше был в продукте и работал в более ранней версии, а теперь он не работает, и вы не думаете, что он когда-либо был в продукте, попросите его доказать это. (Или, более мягкими словами, скажите что-то вроде «у нас проблемы с воспроизведением проблемы. Не могли бы вы помочь нам здесь?»)

Дайте им копию более ранней версии, если у них ее еще нет, и дайте им в LiveMeeting, и пусть они покажут вам, как они использовали FuncA. Если они не могут этого сделать, то (надеюсь) они понимают, что этого вообще не было, и отвлекаются от этого, или, по крайней мере, пытаются применить другую тактику, чтобы реализовать это. (И обязательно пригласите кого-нибудь из менеджмента или премьер-министра на LiveMeeting.)

Это не проблема, которая может быть решена на основе фактов - если вы попытаетесь, вы потеряете доверие.

Во-первых, признайте, что программное обеспечение «сломано», поскольку оно не выполняет то, что хотят пользователи. Теперь примите, что пользователи имеют право на то, чтобы программное обеспечение делало то, что они от него хотят - вот почему программное обеспечение. Так что у нас есть дефектное программное обеспечение и инженер отказывается его исправить .....

В результате, если система, которую вы запускаете для установки приоритетов, эти пользователи не могут исправить свое программное обеспечение, проходя через обычные каналы, поэтому они используют побочные каналы и увеличивают половину правды выше по пищевой цепи, чтобы попытаться выполнить маневр системы, в среднее время, когда ваш KPI выглядит плохо (вашей главной заботой должны быть клиенты, а не KPI) - ваши KPI считаются «побочным ущербом», если вы им нравитесь, или выгодным побочным эффектом, если они этого не делают. Тем не менее, они имеют некоторый контроль над тем, сколько всего происходит - лучше всего они вам нравятся.

Так что происходит то, что система сломана, и каждый пытается манипулировать вещами, чтобы получить то, что он хочет. Им нужна особенность, а вы хотите сохранить свои безупречные KPI.

Если вы не можете починить систему или научиться играть в офисную политику очень быстро, игра окончена: вы проиграли.

Примечание. Ни одно из этих обсуждений не касается «мертвых линий», обсуждений об ошибках и функциях, кто платит и т. Д. Это факты - и факты не имеют значения (ну, в некотором роде, но ими можно манипулировать различными способами…). в офисной политике.

Организационно я чувствую проблему.

Существует иерархия, в которую входят глава ИТ и ваш начальник. Если ваша организация традиционна (это не похоже на Agile), вы являетесь ресурсом, а они - менеджерами ресурсов. У вас есть постоянная работа, которая называется разработкой программного обеспечения. Если конечные пользователи напрямую запрашивают функции, устанавливают приоритеты и пытаются управлять своим временем, ваши менеджеры являются избыточными. Они могут быть подотчетны конечным пользователям, но если они выполняют свою работу, вы подотчетны им, и они должны оградить вас от выхода из режима сосредоточенного разработчика в режим защитного разработчика .

Несколько моментов, чтобы установить контекст моего ответа:

• Разработчики программного обеспечения не являются путешественниками во времени, поэтому о результатах следует судить по тому, кем они являются, а не тем, кем они могли бы быть.
• Если функция была в спецификации требований, расписании и имела приоритет над выполненной работой, может быть законная жалоба. В противном случае, каково оправдание, чтобы привлечь вас к ответственности?
• Ваше наказание, если оно оправдано, должно исходить из вашей цепочки командования. Точно так же, как маркетингу и продажам не понравится, если разработка продукта ругает клиентов, в большинстве организаций есть менеджеры по продуктам, которые получают гнев клиентов (и хвалят) и передают его по каналам.
• Менеджеры по продуктам могут создавать чрезвычайно сложные отношения, если они греются в тепле успешных частей проектов, но только когда-либо ломают кнут, когда сталкиваются с разработчиками.
• Если вы поставили функциональный продукт с годовой работой, и для того, чтобы добавить желаемую функцию, требуется месяц (или два), то, как я видел в нашей отрасли, ваша оценка была выше средней.
• Справедливое и продуктивное решение проблемы требует, чтобы люди сунули пальцы в свои карманы и составили план действий.

Вы сможете выполнять гораздо более качественную работу с большей мотивацией, если вас оценивают, вместо того, чтобы быть козлом в процессе, который должен принадлежать главе ИТ. Это честный и продуктивный путь. Я надеюсь, что вы будете управлять таким образом, и когда-нибудь в будущем, я надеюсь, вы будете управлять другими таким образом.

В случае провала реальности, как это, лучше всего двигаться вперед. Вместо того, чтобы спорить о прошлом, поговорим о том, как заставить его работать, и насколько легко или сложно это будет. На самом деле не имеет значения, решает ли проблема ее впервые или реализует. Если руководство хочет, чтобы А было сделано до того, как Б сделает это.

Вы единственный разработчик, который работал над этим проектом? Похоже, вы ответили кому-то во время создания проекта. Где этот человек во всем этом? Где находится документация по проекту с указанием того, что было доставлено?

Там должен быть документ бумажный след. Учебный документ, показывающий, как использовать приложение. Функциональная спецификация с описанием того, что было разработано. Если функция не была включена, должна быть документация по этому вопросу. Кто-то должен был подписать, говоря, что они принимают это.

Это не должно быть вашим словом против их, это должно быть все в документации.

Если у вас нет этой документации ... тогда, боюсь, вам придется ее укусить. Считай это жизненным уроком. В конце концов, ваши пользователи - ваши клиенты, и, как говорится, клиент всегда прав. Нарисуйте, как добавить эту функцию и сколько времени это займет. Проведите собрание и скажите что-нибудь вроде: «Наши записи показывают, что эта функция никогда не была реализована, но мы можем получить ее через x недель. Должны ли мы идти головой?

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