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

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

За техничките лидери, прашањето повеќе не е едноставно: „Можеме ли да додадеме ВИ?“ Туку: „Можеме ли одговорно да управуваме со оваа способност додека производот, тимот и очекувањата на клиентите се развиваат?“

Одговорноста е способност на производот

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

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

Во пракса, ова значи дека функционалноста не е завршена кога нејзиниот pull request е споен. Таа е завршена кога тимот одговорил на прашања како:

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

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

ВИ ја зголемува цената на нејасната одговорност

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

Разгледајте функционалност на производ што сумира повратни информации од клиенти. Прототипот може да испрати текст до модел и да го прикаже одговорот. Верзијата подготвена за продукција бара повеќе размислување. Што се случува ако повратните информации содржат чувствителни информации? Може ли резимето да се проследи назад до изворниот материјал? Како корисникот коригира неточно толкување? Дали резимето е јасно претставено како помош, наместо како конечен запис?

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

Дизајнирајте за ограничена корисност

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

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

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

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

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

Архитектурата треба да ја зачува способноста за одлучување

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

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

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

Ова е истото размислување зад добрите интерфејси во секој систем: изолирајте ја променливоста, откријте ја намерата и направете го оперативното однесување видливо.

На оддалечените тимови им треба експлицитна одговорност, не повеќе состаноци

Дистрибуираната работа брзо ја открива двосмисленоста. Кога одлуката постои само во разговор, соиграчите во друга временска зона наследуваат неизвесност. Кога одговорноста е нејасно доделена на „инженерингот“ или „ВИ-тимот“, итните проблеми може да останат недопрени додека секој претпоставува дека некој друг се занимава со нив.

Решението не е календар полн со состаноци за статус. Тоа е појасен оперативен модел.

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

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

Одржливата испорака е конкурентска предност

Брзината не е бројот на ставки испорачани во спринт. Таа е стапката со која тимот може да прави корисни промени без да создава растечка трага од страв, преработка и скриена оперативна работа.

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

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

Градете производи на кои луѓето можат да им веруваат

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

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

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