Потрібно, щоб розробники розуміли бізнес-домен чи специфікація повинна бути достатньою?

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

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

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

З іншого боку, навчити кожного розробника до всіх бізнес-аспектів може бути дуже тривалим і складним.

Чи варто надавати більшого значення детальній специфікації (але, як ми знаємо, досконалої специфікації не існує) чи ми повинні навчити всіх розробників розуміти ділову сферу?

EDIT: майте на увазі у своїй відповіді, що компанія могла використовувати зовнішніх розробників і що формування всього домену може становити близько 2 тижнів

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

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

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

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

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

ДЕЯКІ в проекті повинні мати досить повні знання про домен. Ця особа може бути, а може і не бути забудовником.

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

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

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

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

Пам'ятайте, що Ейнштейн сказав: "Але думка та ідеї, а не формули, є початком кожної фізичної теорії" , тобто те, що мислимо не через абстрактні формули, а на ідеї ...

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

Специфікація - це спроба перевести "японську" вимоги домену на "англійську" вимог програмування. Коли ви отримаєте якість перекладу, порівнянна з якістю Google translate, це ваш щасливий день; більшу частину часу якості просто немає, тож вам не обійтися якнайменше деякими знаннями про домен. З деякою наполегливістю це робить вас гідним «перекладачем» до кінця проекту, тому ваша цінність для вашої компанії значно зростає. Більшу частину часу вам також дуже цікаво в процесі, тому це безпрограшна ситуація.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам не доведеться, але чому б ви цього не хотіли?

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

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

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

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

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

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

Я думаю, що це важко дати відповідь у будь-якому випадку.

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

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

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

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

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

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

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

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

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

Якщо розробник перебуватиме в компанії / галузі протягом тривалого періоду часу, вони повільно, але впевнено навчаться "бізнесу".

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

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

Щоб відповісти на ваше запитання, специфікація НІКОЛИ не достатня для мого досвіду. Поширена проблема полягає в тому, що вони часто не містять достатньої кількості інформації та швидко застарівають.

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

З особистого досвіду, специфікації достатньо, якщо у вас є хтось із команди, яка працює з вами, яка має знання про домен.

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