Всім заправляє бізнес

Дейв Мурхед

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

Перш ніж братися за проект з розробки програмного продукту, комерційна компанія зазвичай планує і озвучує бажаний показник окупності інвестицій (ROI – Return on Investment) Архітектор повинен прийняти цей показник і витікаючі з нього обмеження цінності створюваного продукту для компанії Це допоможе уникнути таких технічних рішень, які здатні привести до перевитрати коштів Показник окупності повинен служити важливим компонентом цільового контексту як при спілкуванні з керівництвом (в ході пошуку компромісу між цінністю тієї чи іншої функції і витратами на її реалізацію), так і при обговоренні технічної архітектури та реалізації з командою розробників Зокрема, перед командою розробки архітектор повинен представляти інтереси бізнесу, не погоджуючись на вибір технології з неприйнятно високими вартістю ліцензії і витратами на підтримку у фазі тестування або реальної експлуатації продукту

Одна зі складних завдань, що виникають, коли всім заправляє бізнес, – надавати достатній обсяг відомостей якісного характеру про те, як рухається розробка продукту, щоб бізнес-керівництво могло приймати обгрунтовані ділові рішення Тут найважливішу роль відіграє прозорість Архітектор разом з керівництвом проекту повинен створити і вдосконалити засоби отримання регулярної, оперативної зворотного звязку Цієї мети можна досягти, застосовуючи різні прийоми ощадливої ​​розробки ПЗ (lean software development): великі, помітні діаграми, безперервна інтеграція, часті випуски робочих версій продукту та їх передача бізнес-керівництву вже на самих ранніх стадіях проекту

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

У довгостроковій перспективі інтереси команди розробки найкраще дотримуються тоді, коли біля керма стоїть бізнес

Дейв Мурхед (Dave Muirhead) – ветеран в галузі мистецтва програмування та бізнес-технологій, власник і провідний консультант Blue River Systems Group, LLC (BRSG) – розташованої в Денвері компанії, що надає консультаційні послуги в сфері ощадливої ​​розробки програмного забезпечення і технічних стратегій

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*