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

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

Работата на техничкиот лидер не е да ја заштити секоја одлука од ВИ. Таа е да обезбеди луѓето да останат поврзани со одлуките што се важни.

ВИ може да подготви одговор; не може да го преземе исходот

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

Разгледајте препорака генерирана од ВИ нова услуга да се подели на неколку компоненти што се распоредуваат независно. Предлогот може да спомне скалабилност и јасни граници. Тим што има сопственост поставува попрактични прашања: Дали независното распоредување е навистина потребно сега? Кој ќе ги набљудува и поддржува овие компоненти? Дали организацијата има сигурна автоматизација за распоредување? Кој начин на откажување станува потежок за дијагностицирање во 2 часот наутро?

Прашањето не е дали архитектурата е елегантна. Прашањето е дали тимот може одговорно да ја управува.

Почнете со изјава за проблемот што луѓето можат да ја оспорат

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

• Кој е корисникот и што се обидува да постигне?
• Кое тековно триење или деловен ризик ја прави работата вредна?
• Што мора да биде точно за производот да се смета за корисен?
• Кои ограничувања се реални: приватност, буџет, сигурност, време, интеграции или капацитет за поддршка?
• Кои претпоставки сѐ уште се неизвесни и бараат потврда?

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

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

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

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

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

Доделете сопственици на прашања, не само на тикети

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

Ова спречува вообичаен образец на неуспех: сите претпоставуваат дека планот генериран од ВИ опфатил одредена грижа, а никој всушност не ја проверил.

Задржете ги луѓето во циклусот на преглед таму каде што последиците се најголеми

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

Практичен разговор за преглед прашува:

• Кои докази ја поддржуваат оваа препорака?
• Кои делови беа генерирани, а кои делови беа проверени?
• Што би можело да откаже во продукција и како би го забележале?
• Можеме ли безбедно да го вратиме ова назад?
• Кој разбира доволно за да го одржува ова по првичната имплементација?

Овие прашања не се бирократско триење. Тие се начинот на кој тимот ја претвора брзината во одржлива испорака. Брза имплементација што никој не може да ја дебагира не е кратенка; тоа е одложена работа со поскап рок.

Користете ВИ за да го подигнете минимумот на тимот, а не да ги намалите неговите стандарди

Една од најсилните употреби на ВИ е да им помогне на луѓето кога ќе заглават. Помлад развивач може да побара објаснување за непознат потсистем. Продукт-менаџер може да претвори груби белешки во сценарија што може да се тестираат. Искусен инженер може да генерира прв нацрт на тест-случаи пред да примени проценка врз покриеноста што е важна.

Но лидерите треба да се спротивстават на претворањето на ВИ во автомат за одговори. Барајте од членовите на тимот да ја објаснат промената со свои зборови, да ги идентификуваат нејзините претпоставки и да опишат како ја тестирале. Во преглед на код, коментари како „Зошто ова е безбедно?“ или „Што се случува кога оваа зависност не е достапна?“ градат подобри инженерски инстинкти отколку едноставно да се одобри веродостоен diff.

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

Мерете го напредокот преку учење и сигурност

ВИ ја прави активноста лесна за производство: повеќе прототипови, повеќе тикети, повеќе документација, повеќе код. Тоа не се автоматски знаци на напредок. Продуктовите тимови треба да бараат докази дека ја намалуваат неизвесноста и испорачуваат доверливо искуство.

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

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

Трајната предност е одговорното расудување

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

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