Как заставить нетехнических людей оценить проблему, не связанную с пользовательским интерфейсом?[закрыто]

Question

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

Как вы убедили их в том, что эти инфраструктурные проблемы необходимо решать и что это важно для их бизнес-процессов?

Answer 1

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

Сложность заключается в следующем: клиент не заметит, когда все эти тонкие вещи были сделаны правильно, пока он не заметит, что они пропали без вести! Например, когда белье не готово вовремя, но на два дня позже, или овощи на супермаркете имеют коричневые пятна и выглядят ужасно.

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

То, что вы действительно должны забивать снова и снова и снова, это то, что программное обеспечение НЕ статично. О нем нужно заботиться даже после того, как его начальная фаза разработки закончена. Это не просто продукт, который вы покупаете один раз и о котором забыли. Каждый производитель автомобилей знает, что услуги имеют первостепенное значение для продуктов, которые они производят, просто потому, что будут происходить вещи, которые должны быть исправлены и улучшены. То же самое с программным обеспечением.

Так что сделайте презентацию, визуализируйте, вербализируйте, переведите техническую информацию в преимущества. Деловые люди не заботятся о вашем желании эстетики кода в проекте рефакторинга, но они БУДУТ понимать, что ваши изменения помогут продукту стать более надежным, получить лучшую репутацию и сократить количество будущих запросов на обслуживание. Дайте им понять, показав им преимущества!

Answer 2

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

Предполагая, что они не являются намеренно тупыми ...

Answer 3

Большой +1 за аналогии и метафоры.Если есть возможность, найдите тот, который будет резонировать с личными интересами вашей аудитории (если это 1-2 человека).В качестве общих метафор я по какой-то причине часто использую пригородный транспорт или метро.

напримерВ настоящее время мы переносим приложение из ООБД в Postgres/Hibernate:основная часть этой работы выполнена в версии «4».Многие эксперты в предметной области задаются вопросом, почему в R4 так мало функций, ориентированных на пользователя.Я им регулярно говорю, что мы «сносим город, чтобы поставить метро».Это очень дорого и, несомненно, рискованно, но как только это будет сделано, преимущества в R5+ будут поразительными. Истинный разговор более вовлечен, но я могу снова и снова возвращаться к этой теме, после R4.Через несколько месяцев я надеюсь сказать: «Вы просили X, и теперь это очень легко — именно потому, что вы позволили нам поставить это метро обратно на R4».

Answer 4

Самый надежный способ заставить руководство высшего звена расплатиться за разработку - это представить ее количественно. В идеале эта количественная мера находится в $$. Вам необходимо объяснить им последствия экономии на целостности данных, безопасности, транзакциях и т. Д. И как это повлияет на сообщество клиентов / пользователей и, в конечном итоге, на итоговые результаты. Вы должны быть осторожны в этих ситуациях, потому что иногда руководство ожидает, что эти нефункциональные требования "просто сработают". Если это так, вам следует либо оценить высокую оценку, и работать над этими элементами наряду с видимой работой пользовательского интерфейса (невежество - это счастье), либо вам необходимо задокументировать эти области потребностей, когда вы общаетесь с руководством, чтобы, если все пойдет не так, как вы ожидаете, дело не в твоей работе.

Answer 5

К сожалению, для того, чтобы этот материал привлек внимание, которого он заслуживает, обычно бывает катастрофа или две.

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

Answer 6

Автомобильные аналогии.

Все знают эту «систему», и она достаточно сложна, чтобы изобразить ужасную ситуацию.

Answer 7

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

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

Было бы полезно иметь возможность пометить различные ответы и увидеть их все в одном списке, но, увы, эта функциональность пока недоступна в SO. Я предложил его в uservoice .

Надеюсь, вы найдете что-то, что сможете использовать по ссылкам, которые я дал.

Answer 8

Правильный ответный вопрос – это секрет.

• Можно ли вылетать каждые 5 веб-страниц?
• Должны ли мы защищать номера кредитных карт?
• Можно ли платить подрядчикам за развертывание патча каждые выходные?
• Вы хотели этого сейчас или хотели, чтобы это сработало?

Answer 9

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

Answer 10

Мне нравится идея технического долга , поскольку она позволяет переводить технические проблемы ( хотя и слабо) в денежные вопросы - а деньги это то, что большинство менеджеров понимают.

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

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

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

Answer 11

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

_{(источник: sun.com )}

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