Насколько важны знания предметной области и технические знания?

Я работаю над приложением «Управление трейдингом и рисками», и хотя из C # я получил приглашение работать с пакетами служб SSIS. Теперь я могу жить с этим. Беда в том, что слишком много внимания уделяется пониманию бизнеса. Торговля (энергетическая торговля, если быть точным) является ОГРОМНОЙ областью, и понимание каждой ее части ошеломляет. Но в течение последних двух месяцев я работал над пониманием бизнес-терминов - «Маркетинг на рынок», «Метрики риска», «Позиции», «PnL», «Греки», «Инструменты», «Структура книги» ... каждая мелочь (суть вопроса). Теперь ИМХО, это работа бакалавра. Конечно, для разработчиков очень важно понять бизнес, но где вы проводите черту?

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

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

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

Бенджол и ваш менеджер правы, но позвольте мне уточнить:

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

в этом разница между программистом-программистом и разработчиком кода

Есть высказывание, которое пришло из факультета компьютерных наук моего университета:

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

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

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

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

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

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

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

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

На мой взгляд, вы не правы и слишком наивны.

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

Очевидно, что если вы обнаружите, что этот конкретный бизнес скучно, он может искать что-то другое. Но если ваша идея о рае взламывает маленькие php-сайты, будьте осторожны: тысячи сценаристов будут делать это тоже.

Серьезно, «я просто кодировщик, не путайте меня с фактами», просто не урежет это.

Я также работаю в сфере торговли энергией. Знание бизнеса - это 90% работы. Вы не можете обойти это - это сложный бизнес.

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

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

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

Используемые технологии и их внедрение находятся на втором месте.

Парень выше, который сделал комментарий в Excel, не знает, насколько уместен его комментарий. Трейдеры часто создают свои собственные небольшие торговые приложения в Excel / VBA (это все, что они знают), а затем ИТ-специалисты в конце концов наследуют эту путаницу программ.

Я бы хотел перестроить некоторые из этих приложений на «правильный» язык, но это не всегда является приоритетом.

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

Ваша реакция может быть «Но что делают бизнес-аналитики?»

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

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

Обновить

Комментарий Гаурава:

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

Я не думаю, что вы можете провести черту где-либо вообще. Если нет частей приложения / домена, к которым вам не нужно прикасаться (то есть понимать) никогда. Что ИМХО очень редко в реальной жизни, в долгосрочной перспективе. Любая часть приложения, которая находится в активном использовании, получит отчеты об ошибках и запросы функций. Меняются и домены, так как меняется соответствующее законодательство, налоговые правила, политика, привычки - короче говоря, реальный мир. Это должно следовать в программном обеспечении тоже.

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

Update2

Что, если [...] разработчик часто меняет бизнес-домен, над которым он работает?

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

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

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