Я молодой UX-специалист. Я работал над несколькими реальными проектами в университете, но я не особо в них вкладывался, не было такого большого давления, чтобы сделать их правильно.
Последние полтора года я работаю на своей первой настоящей работе. Это разработка с нуля в государственном учреждении. Хотя они выбрали меня в основном как разработчика, они выбрали меня, потому что хотят, чтобы я использовал свои навыки в разработке программного обеспечения и UX.
До сих пор моим единственным источником для сбора требований был владелец продукта. Я всегда думал, что она очень предана проекту, посвящая ему много времени. У всех в команде (у меня, штатного младшего разработчика, и у моего начальника, который занимается управлением проектами) с ней сложились очень хорошие отношения, и у меня всегда было ощущение, что мы вчетвером работаем вместе для достижения общей цели.
На прошлой неделе я начал проводить юзабилити-тесты. А после второго теста я был так переполнен плохими новостями, что решил, что надо отложить остальные тесты. Я созвал кризисное собрание, когда еще был в полном расстройстве (теперь я понимаю, что это была ошибка).
Из тестов я узнал две проблемы: во-первых, пользователи сталкиваются с таким количеством проблем, что моя оценка того, сколько работы необходимо на уровне проектирования, слишком занижена. Во-вторых, нашим пользователям не нужно наше приложение. Если бы они использовали его, то сочли бы, что это слишком много работы при слишком малой отдаче. Но на самом деле они активно выступают против документирования той информации, которая нужна приложению.
На кризисном совещании я проинформировал команду о проблемах и ожидал, что мы начнем вместе работать над тем, чтобы каким-то образом исправить ситуацию и найти решение, которое можно будет реализовать за то короткое время, которое у нас осталось, сортируя другие части реального решения в список «следующий релиз». Вместо этого и мой босс, и владелец продукта сказали, что мы ничего не должны менять и просто продолжаем работать по «первоначальному плану». Они оба удивлены, что я так привержен системному успеху.
Что касается второй проблемы, владелец продукта сказал, что она создает эту базу данных для пользователей, и если они «слишком эгоистичны», чтобы вводить в нее информацию, это их проблема, и ей все равно, попадет ли в нее хоть одна запись.
Что касается первой проблемы, я сказал им, что мой первоначальный план состоял не в том, чтобы «работать над пользовательским интерфейсом до тех пор, пока он не станет похож на концепт, который у меня есть в голове», а в том, чтобы «работать над пользовательским интерфейсом до тех пор, пока у пользователей не будет достаточного количества запросов». успешность задания». Так что я не могу просто продолжать свою работу и уложиться в срок; скорее, мне, вероятно, придется вырезать некоторые из более сложных функций (которые вызывают наибольшую путаницу) и получить разрешение от владельца продукта на их удаление, а также провести мозговой штурм о том, как мы можем сохранить полезность приложения без этих сложных функций. Особенности. Она категорически отказывается урезать функции и говорит, что я должен доставлять программное обеспечение так, как она хочет, и если пользователи слишком тупы, чтобы его использовать, ей все равно. Мы оба были так задеты, что без уравновешивающей модерации менеджера проекта,
Мой руководитель проекта поддерживает идею поставки как есть, потому что она боится, что любое крупное изменение так поздно может привести к тому, что мы не уложимся в срок.
Я понимаю позицию моей начальницы, и я все равно должен делать то, что она мне говорит. Но мне очень трудно это сделать, потому что я не знаю, как это сделать. Мой критерий для объявления моей работы завершенным запрещен, и у меня нет другого. Я как-то пытаюсь приспособиться к этому, но трудно не делать то, что я считаю нужным.
Что касается владельца продукта, я не могу найти понимания ее позиции, как бы я ни старался. Если ее не волнует системный успех, то что ее волнует? Почему она вообще инициировала этот проект? К какой цели мы стремимся?
Теперь я вижу, что гораздо больше привержен системному успеху, чем я думал. это сочетание
Видя, что у меня есть четыре сильных мотиватора, я сомневаюсь, что смогу довести себя до такой степени, что буду безразличен к успеху системы, как владелец продукта и менеджер проекта. Но без такого равнодушия каждый час, который я трачу на накрашивание губ поросенка, мучителен и демотивирует. Я успокоился на выходных, но уже знаю, что в 9 утра понедельника я буду входить в зону когнитивного диссонанса.
Что я могу сделать, чтобы я мог довести этот проект до релиза, не беспокоясь о психическом расстройстве?
Добро пожаловать в рабочий мир!
Могу я предложить вам пару лозунгов?
Серьезно, это, вероятно, ваше первое знакомство с реальной системой. Самыми важными и самыми трудными для понимания компонентами реальных систем являются люди. Будет ли сложно людям, работающим с вашим программным пакетом — вашим предполагаемым пользователям — применять его? Наверное. Имеет ли значение, насколько сложно им пользоваться? Возможно, это не так. Это государственные административные работники, выполняющие свою работу, а не хипстеры, загружающие приложения на свои устройства для развлечения. Они будут использовать вашу систему, если их начальство проинструктирует их.
Изменения угрожают людям. Информация — это сила, и новые информационные системы иногда обещают перераспределение власти. Это означает неуверенность. Люди, с которыми вы проводили юзабилити-тестирование, могут реагировать на подобные вещи. И, поверьте, многие их реакции могут быть неосознанными. Проблемы с UX, которые вы наблюдаете, могут быть связаны с нежеланием принять эту новую вещь.
Никогда не позволяйте никому говорить вам перестать беспокоиться об удобстве использования. Но, в то же время, примите мудрость вашего владельца продукта (это действительно мудрость, рожденная опытом, даже если это трудно увидеть) о том, что достаточно хорошо для вашего проекта.
Вы многому научитесь, проехав на этой лошади по ипподрому. Вы можете развивать отношения с некоторыми пользователями и узнавать их мотивы. Вы можете наблюдать за развертыванием несовершенной системы и учиться на этом. Вы начнете изучать ритм развертывания и узнаете, насколько необходимо быть немного революционным, чтобы внедрить совершенство в системы.
Вы кажетесь системным мыслителем. Это очень редкая черта; пожалуйста, культивируйте его. Получите копию «Пятой дисциплины» Питера Сенге и прочитайте ее, наблюдая, как разворачивается этот проект.
Вы говорите это; акцент мой:
Мой руководитель проекта поддерживает идею поставки как есть, потому что она боится, что любое крупное изменение так поздно может привести к тому, что мы не уложимся в срок.
И скажи это; акцент снова мой:
Что касается владельца продукта , я не могу найти понимания ее позиции, как бы я ни старался. Если ее не волнует системный успех, то что ее волнует? Почему она вообще инициировала этот проект? К какой цели мы стремимся?
По вашему мнению, быть менеджером проекта означает, что кто-то также является владельцем продукта . Это не относится к делу. В качестве менеджера проекта ее критерием является не обеспечение качества, которое на самом деле является ядром того, что вас беспокоит, а общее управление проектом.
Имея в виду — и я просто привожу псевдопример — скажем, это критерии самого высокого уровня, с которыми она имеет дело:
Тогда ее работа сделана.
Теперь вы можете поморщиться от того, как это может быть завершенной работой, когда конечный продукт так плох и может быть так легко улучшен. Но опять же, это не работа менеджера проекта.
Это основная бюрократическая головоломка, с которой сталкивается любой разработчик при работе с проектом или менеджером проекта. Иногда они не понимают сути вопроса. И это никак не решить… Но одно…
Гарантия качества.
Теперь вы можете подумать, что вы — как разработчик — считаете, что включаете контроль качества в свой процесс, но я не это имею в виду.
Я имею в виду, что каким-то образом — на более высоких уровнях, чем ваш менеджер проекта, — нужно учитывать концепцию, что в процессе должен быть этап обеспечения качества. Теперь, как это сделать? Не понятно. И вот почему.
Причина, по которой так много проектов оказывается в таком дисфункциональном состоянии, заключается в следующем:
По сути, именно здесь вам придется столкнуться с суровой реальностью: хотя вы можете быть правы в вопросах качества, у вас нет реальной силы что-то изменить.
И — это ключевой момент — если вы решите работать усерднее или работать сверхурочно, чтобы решить эти проблемы, вы можете столкнуться с негативной реакцией. То есть, пока вы делали проект лучше, либо всем будет все равно в худшем случае, либо так обидятся, что вы «перешли черту», и придумают способ просто наказать вас за то, что вы осмелились сделать лишнюю работу.
Да, это звучит как чушь И да, это чушь И да, в конце концов, никто на самом деле не выигрывает. Но, к сожалению, в некоторых рабочих средах страсть к работе отходит на второй план, уступая место бюрократической чепухе и общей дисфункциональности.
Лучшее, что вы можете сделать, это быть реалистом и стараться не относиться к каждому проекту как к особому волшебному бриллианту или чему-то в этом роде. И да, это деморализует. Но знаете что? Вот почему многие люди создают сторонние проекты независимо от работы, чтобы беспрепятственно проявить свои навыки.
Для вашего собственного профессионального здоровья, возможно, лучше начать делить свою кодинговую жизнь между тем, что вы действительно делаете для работы, и тем, что вы действительно делаете для себя.
Раду Мурзеа
HLGEM
пмф
скрежет729
Егоме2003