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

Я працюю над програмою «Торгівля та управління ризиками», і, хоча з C #, мене попросили працювати над пакетами SSIS. Тепер я можу з цим жити. Больовим моментом є те, що занадто багато акцентується на розумінні бізнесу. Торгівля (Торгівля енергією, якщо бути точною) - це ВЕЛИЧЕЗНА область, і розуміння кожної її дрібниці є надзвичайною. Але останні два місяці я працюю над розумінням бізнес-термінів - "Марк до ринку", "Метрики ризику", "Позиції", "PnL", "Греки", "Інструменти", "Книжкова структура" ... кожну дрібницю (ви розумієте). Зараз ІМХО, це робота бакалавра. Впевнені, що розробникам дуже важливо розуміти бізнес, але де ви проводите лінію?

Коли я говорив зі своїм менеджером про це, він майже знущався з мене, кажучи, що хтось може навчитися технології за тиждень. Це важче для бізнесу. Моє довготривале прагнення - залишатися на технічній стороні, ймовірно, стати архітектором (якщо можливо). Якби я хотів так зосередитися на бізнесі, я би здобув ступінь МВА!

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

Завдання програміста - переводити вимоги природної мови до машинних мов. Ви не можете зробити це ефективно, якщо вільно володієте з одного чи іншого боку. Якщо ви не пишете компілятори чи програмне забезпечення для управління версіями, майже кожна робота з програмування потребує значної кількості знань, які не програмують.

Бенжол і ваш менеджер мають рацію, але дозвольте мені детальніше:

вивчення ділового домену - це те, як ви додаєте цінність процесу та збільшуєте свою цінність для бізнесу

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

Є приказка, що надійшла з кафедри комп’ютерних наук мого університету:

Якщо ви хочете створити програмне забезпечення для геологів, спершу потрібно розібратися в Geology. Якщо ви хочете створити програмне забезпечення для фізиків, то спочатку слід зайнятися питаннями фізики. Якщо ви хочете зрозуміти бізнес, то спочатку ви повинні навчитися говорити про бізнес.

Я постійно чую, як люди тут говорять, що розробка програмного забезпечення - це творче поле. Я вважаю, що це до певної міри вірно. Він передбачає творчість у тому, що його потрібно бачити поза коробкою, щоб вирішити низку проблем.

Що це не означає, що ви можете просто сісти і так творчо будувати все, що завгодно. Це не клас мистецтва, це інженерія, і ваші клієнти та зацікавлені сторони очікують, що ви створите щось, що вирішить їхні проблеми, а не те, що просто "круто".

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

Незалежно від того, що ви будуєте програмне забезпечення для фінансів, маркетингу, продажів, геології, фізики чи будь-якого іншого поля, яке програмне забезпечення підтримує, ви повинні стати частиною цього поля.

Саме з цієї причини, крім ступеня комп'ютерних наук, я також здобув ступінь бізнес; це зробило величезний вплив на мою здатність передавати потенційні рішення та постачати успішні продукти.

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

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

На мою думку, ти неправий і занадто наївний.

Як сказав ваш менеджер (трохи легковажно), кожен може навчитися технології за тиждень. Єдине, що вас відзначить і зробить корисними для вашої компанії - це знання вашого бізнесу. І чим важче це, тим більше ти будеш вартий.

Очевидно, якщо ви виявите, що цей конкретний бізнес притаманно нудний, ви можете шукати щось інше. Але якщо ваша ідея раю зломлює маленькі веб-сайти на PHP, будьте обережні: знайдуться тисячі малюків сценаріїв, які теж це роблять.

Серйозно кажучи, "Я просто кодер, не плутай мене з фактами" просто не виріжеш.

Я також працюю в торгівлі енергією. Знання бізнесу - це 90% роботи. Ви не можете обійти це - справа складна.

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

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

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

Фактичні технології, що використовуються та впроваджуються, наближаються до секунди.

Хлопець вище, який зробив коментар Excel, не знає, наскільки вдалий його коментар. Торговці часто будують свої власні невеликі торгові програми в Excel / VBA (це все, що вони знають), а потім ІТ в кінцевому підсумку успадковує ці помилки програм.

Я хотів би відновити деякі з цих додатків "належною" мовою, але це не завжди є пріоритетним.

Якщо ви розвиваєтесь для бізнесу, у вас з’явиться чіткіше і детальніше уявлення про правила ведення бізнесу, ніж будь-хто інший в компанії. Це необов'язково, тому що ви розумніші за всіх, це відбувається, тому що це єдиний спосіб зробити цю роботу.

Ваша реакція може бути: "Але що роблять бізнес-аналітики?"

Бізнес-аналітики сидять на тривалих зустрічах із клієнтами, намагаючись вийти з них вимоги, які є достатньо зрозумілими для роботи розробника. Я дивлюся на те, як вони мають справу з клієнтами, і відчуваю вдячність, що мені не потрібно цього робити.

Мені подобається проводити аналогії між розробкою програмного забезпечення та архітектурою. Обидва - це прикладне мистецтво. І те й інше вимагає продуманого моделювання всередині розуму. Аспект, що стосується цього питання, полягає в тому, що писати програмне забезпечення без ділових знань - це як проектування будівлі без розуміння способу життя та потреб мешканців. Я думаю, що багато хто з нас бачили (або навіть жили / працювали в) будівлі, які можуть виглядати красиво і сучасно, а що ні зовні, просто не використовуються зсередини. (У гіршому випадку вони навіть не приємні: - ((()

Оновлення

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

що мені цікаво - це в якій мірі розробник повинен докладати зусиль для розуміння ділової сфери. Чи повинен він пройти весь шлях, або є якась лінія, яку потрібно провести.

Я не думаю, що ти можеш взагалі малювати лінію де завгодно. Якщо немає частин програми / домену, вам не потрібно ніколи торкатися (таким чином розуміти). Що є ІМХО дуже рідкісним у реальному житті, у довгостроковій перспективі. Будь-яка частина програми, яка активно використовується, отримуватиме звіти про помилки та запити щодо функцій. Домени теж змінюються, оскільки відповідне законодавство, податкові правила, політика, звички - коротше кажучи, реальний світ - змінюються. Цього потрібно дотримуватися і в програмному забезпеченні.

Але навіть без зовнішніх запитів на зміни, тестування блоку та рефакторинг застарілого коду вимагає розуміння відповідних областей домену. Інакше ви просто «заморожуєте» поточну поведінку програми, не знаючи, чи це насправді правильно.

Оновлення2

що робити, якщо [...] розробник часто змінює бізнес-домен, над яким працює?

Це, звичайно, означає, що велика частина інвестицій (вашого часу та грошей роботодавця) для отримання ваших знань про бізнес втрачається :-( Якщо ви знаєте, що це відбудеться, звичайно, можливо, не варто заглиблюватися занадто глибоко Зауважте, однак, що домени не є абсолютно різними, є основи, які можна використовувати повторно між різними доменами. І найголовніше, що підхід до дизайну, керований доменом, є багаторазовим.

Я працюю в банківському секторі більше десяти років, розробляючи торгові програми і погоджуюся, що розробникам важливо добре розуміти бізнес. Але знову і знову, під час процесів інтерв'ю, якщо людина не має добрих знань про бізнес, він не пробирається через двері.

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