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

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

Почнете со проблемот, не со моделот

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

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

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

Забележете ја заедничката нишка: системот ја поддржува работата на корисникот наместо да се преправа дека ја заменува проценката. Токму тука ран ВИ-производ често може да заслужи доверба и да испорача вредност без да носи неразумен ризик.

Дефинирајте сопственост пред да градите

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

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

Овие прашања не се бирократија. Така тимот претвора експеримент во продуктна способност.

Направете ја границата јасна за корисниците

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

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

Вградете евалуација во испораката

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

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

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

• Чувајте репрезентативен сет сценарија од реалниот свет, со соодветно ракување со чувствителниот материјал.
• Тестирајте ги промените во промптовите, логиката за пронаоѓање, моделите и текстот во интерфејсот во однос на тој сет.
• Прегледувајте ги неуспесите по категории, наместо секоја грешка да ја третирате како изолирана.
• Мерете ги продуктните исходи, како времето за завршување или стапката на корекции, паралелно со квалитетот на излезот на моделот.
• Одржувајте едноставен пат за враќање назад или оневозможување при инциденти во продукција.

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

Дизајнирајте за човечка контрола, не за човечко чистење

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

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

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

Водете ги далечинските тимови со писмена јасност

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

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

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

Заштитете одржлива испорака

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

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

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

Тестот за лидерство

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

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