Crow

Объяснение абстрактных проблем нетехническим менеджерам


Управление Работодатель-отношения Работа

Я работаю инженером с полным стеком. Часто менеджер (нетехнический) спрашивает: «Покажите мне, над чем вы работали» , или «Покажите мне демонстрацию того, что вы делаете» .

Теперь это проблема. Мой общий ход работы выглядит следующим образом:

  • Гипотеза теоретического решения проблемы
  • Изучите возможные решения и найдите те, которые соответствуют нашему варианту использования
  • Протестируйте исследуемые решения и посмотрите, какой из них наиболее полезен
  • Внедрить функциональность выбранного решения
  • Записать единичные и интеграционные тесты для функциональности
  • наконец , связать его вместе с пользовательским интерфейсом

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

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

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

Есть ли лучший способ справиться с этим?

nvoigt
Как долго длится процесс от начала до конца? Ваш менеджер просто появляется в кратчайшие сроки, или это больше похоже на «можете ли вы показать мне демо в пятницу»?

Crow
Обычно он говорит мне в течение 3 часов, что ему нужна демонстрация. Для более сложных проблем решения могут занимать около двух или трех дней

HorusKol
Просто объясните им, что это проблема 2 или 3 дня, у вас уже есть 1 день, и она не будет готова к демонстрации еще на один-два дня ...

Ответы


Xavier J

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

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

Удачи.


teego1967

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

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

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

Сохранение пользовательского интерфейса для мертвых в прошлом старомодно. Вы будете более убедительны, если сможете дать своим владельцам акций то, что они могут видеть, и рассуждать о РАНЬШЕ в жизни проекта. Это не значит, что вы должны сначала реализовать пользовательский интерфейс. Просто сообщите так или иначе, как это будет на ранней стадии процесса.

gazzz0x2z
Мудрый ответ. Общение является частью работы. Joel Spolsky опубликовал известную запись в блоге об этом давно: joelonsoftware.com/articles/fog0000000356.html - он считает, что с современным интерфейсом лучше всего общаться с боссами.

bobo2000
Я не думаю, что это решает проблему - менеджер хочет увидеть конечный продукт.

Walfrat
Я не согласен, когда клиент видит, как работает ваш конечный пользователь, он просто сыграет карту, why does it take so long to finish . Макетный интерфейс в этом случае может быть окончательно полезен вне процесса тестирования, чтобы обеспечить параллелизацию работы между несколькими разработчиками.

simbabque

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

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

    Вот пример: использование хранилища key-value было бы неплохо, потому что это быстро, но все остальные ребята знают только mysql, и нет системного администратора, чтобы помочь настроить Redis. Вы бы застряли, поддерживая это, и на самом деле преимущество не очень велико. Он чувствует себя лучше, но мы должны были вырасти примерно на 500%, прежде чем mysql-решение начнет быть заметно медленнее.

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

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

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

    Зная процесс и визуализируя его, он говорит менеджеру, что вы потратили время, чтобы подумать об этом . Выполнение этого пользовательского или бизнес-фокуса помогает менеджеру следовать визуализации.

  • Объясните, в каком порядке вы собираетесь создавать детали на этой диаграмме. Какие из них являются существующей инфраструктурой. Какие из них новы. Кто собирается строить какие.

  • Объясните, что еще нужно сделать. Существуют ли зависимости в других отделах? Обслуживание клиентов должно быть рассказано об этой новой кнопке, о которой могут спросить клиенты, и вы уже создали задачи для этого, как только новый продукт можно использовать при тестировании.

  • Спросите, думают ли они, что вы что-то забыли? Дайте менеджеру ручку, пусть они рисуют диаграмму, если захотят.

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

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


Dan

Я считаю, что ваш сценарий трудно себе представить. Вы работаете над очень технической проблемой, но ваш босс не является техническим или понимает, над чем вы работаете?

Похоже, вы можете работать над нанотехнологиями, и ваш босс не понимает об этом. Почему вы не могли сказать что-то в ответ: «Я сейчас на стадии X, и у меня есть Y, чтобы показать. Если вы подождете, пока ZI покажет вам A, B и C?» Почему это объяснение должно быть настолько сложным и трудным, что его нельзя объяснить ни в какой форме или форме даже на стадии гипотезы?

Я также предлагаю включить в трекер проблемы. Таким образом, ваш босс может видеть ваш прогресс и может знать, когда что-то может быть представлено. Вы можете сказать: «У меня есть это в Джире и оценка будет готова через 3 недели». Возможно, он не понимает код, но, может быть, он может понять проблему.

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

Loren Pechtel
В какой-то момент должен существовать технический тип, управляемый нетехническим типом, если генеральный директор не является техническим типом. Парень в верхней части технической иерархии будет в этой лодке в большей или меньшей степени.

keshlam

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

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

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

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

Chris E

было бы невозможно объяснить ему глубину решения и то, над чем я работаю.

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

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

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

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

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

Patricia Shanahan
Я категорически не согласен с этим ответом. Я смог объяснить действительно трудные, тонкие ошибки в прототипе компьютерного оборудования для менеджеров. Избегайте ненужного жаргона с самого начала. Определите и объясните термины, которые помогут в общении. Убедитесь, что вас понимают, когда вы идете вперед, не дожидаясь вопросов. Хорошее общение намного сложнее, чем ослепить кого-то с жаргоном, но, скорее всего, приведет к лучшему принятию управленческих решений.

Mike Robinson

Также полезно поделиться своим прогрессом и ожидаемым графиком.

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

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

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


HLGEM

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

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

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

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

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

Смотри также