ВИ може да создаде уверлив план за производ во минути: листа со функции, шема на база на податоци, API рути, екрани, па дури и план за распоредување. Таа брзина е корисна. Таа не е сопственост.

Тешкиот дел од градењето траен дигитален производ е да се одлучи што треба да постои, што мора да остане флексибилно, на кои ризици треба да им се посвети внимание сега и кој ќе ги сноси последиците кога првиот план со уреден изглед ќе се соочи со вистински клиенти. Техничкото лидерство започнува таму каде што завршува генерираната сигурност.

Планот може да го забрза размислувањето. Не може да го замени расудувањето потребно за деловната потреба да се претвори во производ што останува разбирлив, управлив и вреден шест месеци подоцна.

Користете ја ВИ како нацрт, а не како носител на одлуки

Архитектурата генерирана од ВИ често изгледа целосна бидејќи наведува познати компоненти: фронтенд, API, автентикација, релациска база на податоци, позадински задачи, мониторинг и распоредување во облак. Сите тие компоненти може да бидат соодветни. Неодговорените прашања се поважни.

Кој проблем на клиентот оправдува асинхрона обработка? За кои дејства е потребна ревизорска трага? Што се случува кога давателот на услуги за плаќање ќе истече по наплатата на картичката? Кому му е дозволено да брише податоци и може ли тоа бришење да се поништи? Како персоналот за поддршка ќе разбере неуспешен работен тек без да побара од инженер да ги прегледа продукциските логови?

Ова се прашања за производот и работењето маскирани како технички детали. Тим што прифаќа план без да ги испита може брзо да испорача, а потоа да открие дека изградил скапа збирка претпоставки.

Подобра почетна точка е да се побараат алтернативи и компромиси од ВИ. Побарајте да ги идентификува начините на откажување, да ги наведе претпоставките и да објасни што би се променило ако употребата порасне, регулативите се заострат или зависност од трета страна стане ненадежна. Сметајте го нејзиниот одговор за материјал за дизајнерска ревизија, а не за самата дизајнерска ревизија.

Архитектурата е низа обврски

Секој технички избор го обврзува производот на идна форма. Некои обврски се евтини за ревидирање: ознака на копче, внатрешен помошник, барање за извештај. Други брзо стануваат скапи: модели на идентитет, сопственост на податоци, јавни API, граници на закупците, текови на плаќање и договори за настани меѓу услугите.

Искусните технички лидери разликуваат одлуки што бараат прецизност сега од одлуки што можат да останат отворени. Целта не е да се предвиди секое идно барање. Таа е да се избегне случајно донесување неповратни избори.

Одделете ги обратливите избори од темелните

• Одржувајте ги раните интерфејси тесни. Мал API дизајниран околу вистински работен тек полесно се развива отколку широк API замислен според листа на посакувани функции.
• Направете ја сопственоста експлицитна. За секое важно парче податоци, идентификувајте го изворот на вистина, кој смее да го менува и на што може да се потпрат потрошувачите.
• Дизајнирајте за набљудлив неуспех. Системот не станува сигурен затоа што грешките се ретки. Тој станува управлив кога неуспесите може да се откријат, објаснат и безбедно да се повторат.
• Претпочитајте едноставни граници пред модерна декомпозиција. Добро структуирана модуларна апликација може да му служи на раниот производ подобро од неколку услуги со распределена оперативна сложеност.

Разгледајте производ што им овозможува на менаџерите да одобруваат трошоци на вработените. Генериран план може да предложи одделни услуги за сметки, одобрувања, известувања, извештаи и корисници. Пред да ги создадете, утврдете го основното правило: кога е одобрен трошокот, од кого и кој запис го докажува тоа? Ако доставата на известувањето не успее, статусот на одобрување сепак треба да биде точен. Ако менаџер одобри двапати, системот не треба да надомести двапати. Овие правила поефикасно обликуваат кохерентен дизајн отколку дијаграм полн со полиња.

Направете го размислувањето за производот дел од инженерството

Програмерите ја вршат својата најдобра работа кога ја разбираат последицата од функцијата, а не само описот на задачата. „Додадете копче за извоз“ е барање. „Овозможете му на финансиите да ги усогласат одобрените трошоци без рачно копирање податоци“ е изјава за проблемот. Второто повикува на подобри прашања за формати, дозволи, целосност на податоците, перформанси и поддршка.

Размислувањето за производот не значи дека секој инженер мора да стане менаџер на производ. Тоа значи дека техничката работа треба да остане поврзана со задачата на корисникот и деловниот исход. Таа поврзаност ги прави тимовите подобри во препознавањето лажни кратенки.

На пример, барањето за ажурирања во реално време всушност може да значи дека корисниците не се сигурни дали нивното дејство успеало. Врска во живо може да го реши тој проблем, но истото можат да го направат јасна состојба на потврда, временска линија на активности и предвидливо однесување при освежување. Поедноставното решение може да биде поотпорно и полесно за поддршка.

На далечинските тимови им е потребно писмено инженерско расудување

При далечинска работа, претпоставките патуваат подалеку од разговорите. Одлука донесена на состанок може да исчезне за луѓето во друга временска зона, за колега фокусиран на испорака или за лицето што подоцна ќе се приклучи на проектот. Документацијата не е бирократија кога зачувува контекст што инаку би се изгубил.

Корисните пишани артефакти се мали и конкретни: краток запис за одлука, дефиниција на завршеност, API договор, прирачник за позната оперативна задача или белешка што објаснува зошто кратенката била прифатлива. Најдобрите документи одговараат на практични прашања без да бараат од читателите да реконструираат аргумент од историјата на разговорите.

Лесен запис за одлука може да вклучува:

• проблемот што се решава;
• одлуката и разгледаните алтернативи;
• претпоставките зад неа;
• последиците, вклучително и што тимот ќе треба повторно да разгледа подоцна.

Оваа навика исто така ја подобрува употребата на ВИ. Кога тимот има јасни ограничувања и одлуки, може побезбедно да користи генериран излез. Поттикот станува втемелен во вистински контекст на производот, наместо во генерички технички речник.

Изградете системи за испорака што можат да одржат внимание

Одржливата испорака не е бавна испорака. Таа е испорака што не бара херојски напори за да се повтори. На тимовите им се потребни доволно автоматизација и дисциплина за да објавуваат со доверба, да учат од продукцијата и да закрепнат кога нешто ќе се расипе.

Тоа обично значи мали промени, pull request-и што може да се прегледаат, автоматизирани проверки пропорционални на ризикот и процес на распоредување што овозможува враќање назад или ублажување. Тоа исто така значи заштита на време за одржување. Игнорирањето на ажурирања на зависности, нејасна сопственост, кревки тестови и бучни предупредувања не ја елиминира работата; ја пренесува цената во поитен момент.

Техничките лидери треба да го направат ова видливо при планирањето. Работата на сигурноста не е одвоена од работата на производот кога ненадежен производ ги прекинува клиентите. Ниту рефакторирањето не е автоматски вредно; добива приоритет кога намалува конкретен ризик за испорака, точност или работење.

Сопственоста е трајната предност

Највредните програмери нема да бидат оние што можат да генерираат најмногу код. Тоа ќе бидат луѓето што можат да обликуваат проблем, да оспорат привлечна, но слаба претпоставка, да изберат соодветно ниво на сложеност и да му помогнат на тимот да учи од резултатот.

ВИ може да ги прошири опциите на тимот. Сопственоста им дава насока на тие опции. Таа претвора генериран план во производ на кој клиентите можат да му веруваат, колегите можат да го менуваат и врз кој бизнисот може да продолжи да гради.

Тоа е иднината што вреди да се архитектуира: не систем што изгледа целосен на првиот ден, туку систем чии одлуки остануваат читливи, чии неуспеси се преживливи и чии луѓе остануваат способни да го подобруваат.