Должны ли разработчики понимать сферу деятельности или спецификации должно быть достаточно?

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

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

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

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

Должны ли мы уделять больше внимания детальной спецификации (но, как мы знаем, идеальной спецификации не существует) или мы должны обучить всех разработчиков понимать сферу бизнеса?

РЕДАКТИРОВАТЬ: помните в своем ответе, что компания может использовать внешних разработчиков и что формирование для всего домена может быть около 2 недель

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

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

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

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

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

У кого-то в проекте должно быть достаточно полное знание предметной области. Этот человек может или не может быть разработчиком.

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

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

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

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

Помните, что Эйнштейн сказал: «Мысли и идеи, а не формулы, являются началом каждой физической теории» , то есть мыслят не в терминах абстрактных формул, а в идеях ...

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

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

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

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

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

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

Я думаю, что разработчик, который знает бизнес, на вес золота.

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

1. У вас есть несколько точек отказа. Бизнес-аналитик, возможно, не полностью перевел все бизнес-требования, и / или разработчик может не полностью перевести их в техническую спецификацию. Вариант по сценарию «Тайна вокруг комнаты». Просто необходимость общения.

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

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

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

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

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

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

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

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

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

Вам не нужно, но почему бы вам не захотеть?

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

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

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

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

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

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

Я думаю, что трудно дать ответ в любом случае.

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

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

В МСП с одиночными разработчиками важно, чтобы разработчик часто обсуждал с владельцами / менеджерами, чтобы избежать неправильной реализации.

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

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

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

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

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

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

Если разработчик остается в компании / отрасли в течение длительного периода времени, он будет медленно, но верно изучать «бизнес».

Некоторые компании признают и проводят обучение «бизнесу». Финансовые компании являются хорошим примером этого.

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

Чтобы ответить на ваш вопрос, спецификация НИКОГДА не достаточна в моем опыте. Общая проблема заключается в том, что они часто не содержат достаточно информации и быстро устаревают.

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

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

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