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

22

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

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

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

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

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

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

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

Пользователь Smith
источник
1
Мы не форум в традиционном смысле этого слова, мы - сайт вопросов и ответов, который ищет ответы на вопросы. Арендные ставки, опросы и обсуждения, как правило, не соответствуют нашему формату.
maple_shaft
12
@maple_shaft: я не согласен. Это серьезный вопрос о поиске способа решения реальной проблемы, которая возникает, когда мы имеем дело, скажем, с менее осведомленными конечными пользователями. Мы все это видели и были разочарованы, не так ли? Поэтому идеи о том, как работать с такими сценариями, очень хорошо подходят для формата этого сайта.
Мейсон Уилер
1
Разве не возможно, что может быть ответ на этот вопрос? Кто будет наблюдать за наблюдателями?
Пользователь Смит
2
В интересах других, читающих это, этот случай представляет собой еще один урок для тех из нас, кто считает документацию второстепенной и что требования к исполнению не важны.
NoChance
1
«ничего не изменилось» знаменитые последние слова.
Джефф

Ответы:

18

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

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

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

Мейсон Уилер
источник
Они показали скриншот доказательства, которое я могу объяснить, но это только частично, поэтому детали сценария, как они говорят, на самом деле не определены через скриншот. По сути, это сводится к тому, что MGMT не очень осведомлен о логике, и на данный момент это слово целого отдела против одного непритязательного программиста. (Также предыдущая версия совпадает с первоначальным выпуском, который произошел в 2011 году)
пользователь Smith
3
@UserSmith: Вот почему я сказал использовать LiveMeeting. Труднее ошибиться в том, что происходит, когда вы действительно делаете это с людьми, которые смотрят.
Мейсон Уилер
1
Этот ответ дает гораздо лучшее определение доказательства, чем «так говорит конечный пользователь» или «я читаю код». Остановитесь и запомните последние 10 раз, что, будучи программистом, вы были совершенно ошеломлены, что вы можете быть настолько неправы, несмотря на то, что в коде вы видите 1 = 1 (например, когда это должно было быть 1 == 1). Если вы думаете о доказательствах с точки зрения «чтения кода» как о человеке, подверженном ошибкам, то откровенно говоря, ваши показатели производительности должны быть хитом. @MasonWheeler предложил вам более точную и более привлекательную эпистемологию, и вам следует следовать ей.
Джечлин
На переговорах звучит поговорка «Если тебе нужно защищаться, ты уже проиграл». Доказательство фактов является окончательной формой защиты - как правило, лучше этого не делать, если только об этом не спросят, даже если держать кратко - меньше значит больше.
Mattnz
1
Отмечено как ответ, вероятно, самый конкретный ответ. Хотя я уже проводил живые встречи до публикации этого вопроса. Плюс одна пара других, которые были частично хорошими ответами. Честно говоря, на данный момент меня не волнуют мои показатели, это скорее тот факт, что фундаментальная структура нашей ИТ-организации находится в таком состоянии руины, что это даже происходит, что беспокоит меня.
Пользователь Smith
13

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

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

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

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

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

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

mattnz
источник
1
Как вы можете потерять авторитет, если вы можете доказать это?
Томас Эдинг
3
@ThomasEding Доверие в деловом мире больше связано с тем, как другие воспринимают вас, а не с фактами. Если вы станете мишенью, никакие факты не защитят вас. Сколько разработчиков рок-звезд вы встретили, которые были полными мошенниками? Я встретил больше, чем я хотел бы признать.
maple_shaft
2
Я бы согласился с хорошей частью этого, это определенно форма офисной политики. Когда я столкнулся с какой-либо ситуацией, я бы подумал, что первым делом нужно разобраться с фактами, так что вы как бы потеряли меня там, но я бы согласился с тем, что клиенты приходят первым, пока не уволят вас. +1 для другого взгляда на ситуацию. +1
пользователь Smith
2
Никогда не жалуйся, никогда не объясняй. Спор заставляет вас выглядеть слабым. Слушать вежливые просьбы - это хорошо. Сказать, что вы обсудите их запрос с вашим боссом для приоритета, это хорошо. Если вы спорите, то делайте то, о чем они кричали, это усиливает их неприятное поведение. Если они обострятся, власть вашего начальника усиливает вежливость. Ваш босс может дипломатично объяснить свой выбор на ваше время. Это также показывает, что они не босс вас. Когда вы спокойно решаете эту проблему со своим боссом, вы можете услышать такие слова, как «не волнуйтесь, я получил вашу спину». Сосредоточьтесь, сделайте продукт, беспорядок остановится
DeveloperDon
@thomas Спросите любого невиновного обвиняемого, если какое-то конкретное безнравственное преступление ....
mattnz
9

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

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

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

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

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

DeveloperDon
источник
DevDon, хотел бы, чтобы это было в ответе № 1, так как я думаю, что это большая часть нашей проблемы .... наша IT-структура для этого сценария крайне случайна. +1
пользователь Smith
1

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

ddyer
источник
Конечно, это правда, но когда конечный пользователь узнает, что он может манипулировать системой таким образом, моя компания окажется в серьезном нисходящем уклоне, если это будет продолжаться, поскольку ресурсы будут использоваться таким образом, а не использоваться для общей стратегической деятельности компании. директивы, которые действительно будут способствовать росту прибыли компаний.
Пользователь Smith
0

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

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

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

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

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

Tyanna
источник
Да, я был единственным, кто работал над этим проектом. Есть документация с ежедневными обновлениями, которую я назвал proofC в своем вопросе.
Пользователь Smith
@UserSmith ~ Я понял, что это означает ежедневное обновление статуса. Это не совсем документация, о которой я говорил. Кто-то подписывался на конечный продукт? Есть ли у вас обучение или какая-либо документация по применению, которую вы дали конечному пользователю или заинтересованному лицу?
Тианна
К сожалению нет. Была тренировка, но очень короткий период обучения. Существует прикладная документация, но она не покрывает отсутствие этой функциональности. Ежедневные обновления - это, по сути, инструмент журнала, который мы используем для описания начальных, ежедневных и окончательных описаний того, что произошло с проектом.
Пользователь Smith