Что произойдет, если вы не можете решить проблему? [закрыто]

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

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

Так что для тех, кто был в промышленности в течение более длительного периода времени, что бы произошло, если бы вам сказали, чтобы решить проблему, которую вы не могли? Случилось ли это, и если да, что случилось? Они просто уронили его и сказали: «Ну что ж, думаю, мы можем обойтись чем-то другим»? Были ли последствия? Вам сделали выговор или даже уволили?

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

1. Вы понимаете проблему?
2. Знаете ли вы, что проблема неразрешима (в пределах ваших временных / бюджетных ограничений)?
3. Вы просто не знаете, как решить проблему?
4. Ваш клиент / начальник просит невозможного.
5. Стоит ли оно того? (ROI),
6. Это НАСТОЯЩАЯ проблема?

1) Прежде всего, убедитесь, что вы понимаете проблему. Там нет глупых вопросов. Понимаете ли вы, что ваш клиент / начальник спрашивает вас против того, что им нужно?

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

3) Если проблема понятна и ограничения в пределах разумного, и есть технология, которая может решить проблему, но вы просто не знаете достаточно ... для этого и нужен StackOverflowИнтернет. Убедитесь, что вы делаете свое исследование в первую очередь. Попробуйте задать четкие вопросы, на которые есть количественные ответы. Спроси своих сверстников. Проведите сеанс дизайна.

4) Это вариант ответа № 2. Похоже, ваш клиент / начальник спрашивает невозможное. Проводить некоторые исследования. Никогда не говорите, что проблема неразрешима, если вы точно не знаете, почему и не можете уточнить.

5) ROI означает возврат инвестиций. Это относится к инвестициям во времени. Твое время!. Является ли проблема достаточно важной, чтобы ее решить, чтобы гарантировать количество времени, которое потребуется вам для исследования и решения проблемы. Обсудите это с вашим клиентом / боссом

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

Надеюсь, что эти рекомендации помогут вам.

Две вещи, которые нужно запомнить, если вы застряли с, казалось бы, неразрешимой проблемой:

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

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

Я иду в StackOverflow ;)

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

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

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

Посмотрите на это с разных сторон

Я сталкивался с этим много раз, обычно происходит следующее:

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

Наконец вы выбираете то, что вы не хотели делать ->

"Грязный хак"

Это работает, но вы чувствуете себя грязным ...

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

Это зависит от причины, по которой вы не можете ...

• логически невозможно: обсудить это с тем, кто написал требования, возможно, есть недоразумение. Пример: в одном месте спецификация говорит, что приложение должно выглядеть и чувствовать себя нативно на всех платформах (Windows / Linux / Mac), а в другом месте говорится, что программа должна выглядеть точно одинаково на всех платформах

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

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

• Вы просто не знаете, как это сделать: спросите своих коллег, спросите stackoverflow, поищите в Интернете. Обратитесь в службу поддержки используемого вами инструмента / lib. Обсудите это с менеджером проекта.

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

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

Суть в том, что вы будете FINE, даже если вы не решите проблемы своевременно. Жизнь идет.

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

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

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

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

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

Тем не менее, у меня было пару раз, когда я сталкивался с довольно специфическими обстоятельствами:

1. Во время работы в большом канадском банке в Торонто меня попросили сделать все, что я не знал, как делать, когда мне дали задание. Например, меня попросили проверить этот метод для защиты ноутбуков, где клавиши «Esc» и «Enter» менялись при загрузке, и с правильной последовательностью клавиш ноутбук можно было бы снова использовать, что просто показалось странным, чтобы попытаться выяснить, out, "Будет ли это работать? Как я знаю, что это будет или не будет в порядке с пользователями?" Были другие задачи, которые у меня либо просто не было ни оборудования, ни других ресурсов, чтобы это сделать. В то же время это было довольно познавательно, так как это дало мне много замечаний по поводу любой будущей ситуации с занятостью, чтобы избежать неприятностей. Такие вещи, как обеспечение, когда мне платят, как мое время отслеживается,

2. Во время работы в сервис-провайдере приложений в Калгари мне был дан проект по созданию копии другого веб-сайта в рамках нашего внутреннего приложения, которое мы продали в качестве услуги. Ключевым моментом здесь является то, что мне не дали временную шкалу или предложения о том, что делать в первую очередь, только общее исследование, и через месяц меня попросили о демонстрации, так как у меня была плохая реакция на некоторые обезболивающие препараты. Эта реакция длилась неделю, когда я внезапно прекратил работу, а на следующей неделе я отправился на мероприятие Microsoft, которое стало своего рода последней каплей, так как меня уволили на следующий день. Здесь следует отметить, что у меня были довольно плохие отношения с моим боссом, так как каждый раз, когда он приближался к моему району, я сразу же подумал: «Что теперь не так?»

Как уже говорили другие, общение имеет решающее значение - сообщать людям (которые будут затронуты), когда вы застряли: ваш начальник, члены команды, клиенты и т. Д.

Один проницательный сотрудник однажды внушил мне, что успех коренится в двух вещах:

1. Отношения
2. ожидания

Хорошие отношения, я полагаю, являются функцией хорошего общения и предвосхищают ожидания.

Я следую принципу Поли:

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

Георгий Поля

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

Ответы « искать помощь », безусловно, правильные. Маловероятно, что вы первый человек, который когда-либо сталкивался с определенной проблемой.

Но как бы эксперимент, что если помощи нет? Что делать, если вы должны решить проблему самостоятельно? Самая важная способность решать проблемы - это способность определять и оспаривать свои собственные предположения . Если вы можете перечислить свои предположения о проблеме один за другим и устранить каждое из них по очереди, вы в конечном итоге столкнетесь с ошибочным предположением, и в результате откроются новые возможности для решения.

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

Обращение за помощью - действительно лучший ответ, но вот еще немного, что может быть полезно.

Так что для тех, кто был в промышленности в течение более длительного периода времени, что бы произошло, если бы вам сказали, чтобы решить проблему, которую вы не могли? Случилось ли это, и если да, что случилось? Они просто уронили его и сказали: «Ну что ж, думаю, мы можем обойтись чем-то другим»? Были ли последствия? Вам сделали выговор или даже уволили?

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

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

Что на самом деле происходит, когда твой менеджер говорит: «Я бы хотел, чтобы ты сделал X, как ты думаешь, что это займет?» И вы можете дать много ответов. Хорошие включают в себя:

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

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

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

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

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

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

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

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

Как правило, вы найдете путь к вещам, так или иначе. Это пугает, но как только вы в нем, вы всегда можете найти выход.

Лучше всего просто нарисовать слова «Не паникуйте» на внешней стороне вашего ноутбука. И не забудь свое полотенце.

Моя последовательность решения задач (каждый следующий спет выполняется только в том случае, если предыдущий не сработал):

1. Попробуй гуглить
2. Спроси кого-нибудь
3. Поиск ТАК напрямую (в обход Google)
4. Думать
5. Дым (== умница)
6. Задайте вопрос по SO
7. Подожди до утра (== умница еще больше)
8. Используйте этот грязный хак и плохо себя чувствую :(

Противные проблемы решаются на шагах 5-6.

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

И только потом наступает 8-й шаг.

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

Здесь есть отличный совет! Мои два цента стоит; Не ошеломляйтесь БОЛЬШОЙ проблемой, не забывайте, что захватывающая и сложная часть решения проблемы разбивает ее на ряд управляемых и, что более важно, понятных подзадач, которые, в свою очередь, снова и снова разбиваются на более мелкие подзадачи. Любой хороший программист, как правило, делает это каждую минуту, пока он создает код (используя функции, методы, подпрограммы и т. Д., Чтобы уменьшить общую сложность раздела кода), и эта методология обычно применяется к любой БОЛЬШОЙ проблеме, с которой вы работаете. лицо в жизни (не только на работе).

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

1. Найти обходной путь / замену
2. Купите коммерческое решение, приближенное к тому, что вы хотите
3. Не сдавайтесь и продолжайте работать над этим столько, сколько вам нужно, пока вы не добьетесь успеха .

Номер 3 может потребовать свободного времени от проблемы и повторного ее рассмотрения через несколько недель или месяцев. Это часто помогает.

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

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

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

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

Что помогает:

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

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

Мой совет: используйте их. Если вы не знаете, как решить проблему, или если вы хотите знать, идет ли ваше решение в правильном направлении, обсудите это с ними. И если вы чувствуете, что застряли где-то, возьмите одного из опытных парней, объясните свою проблему и попросите о помощи.

Чаще всего простое объяснение вашей проблемы покажет решение, а объяснение вашего решения может также выявить недостатки в ней.

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

Проблема только в том, что вы наблюдаете, а не в том, что вы себе представляете.

«Моя кровавая машина не заводится» - это проблема. «Батарея разряжена». является предвзятым решением проблемы запуска автомобиля. Даже тестирование аккумулятора не доказывает, что это единственная причина проблемы. Если вы на самом деле не зарядили или не заменили аккумулятор и не запустили автомобиль, у вас нет никаких доказательств того, что аккумулятор является причиной проблемы.

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