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

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

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

Почнете со проблем што има јасни граници

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

Разгледајте ја разликата меѓу овие две барања:

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

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

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

Направете ја сопственоста видлива во дизајнот

Софтверот станува кревок кога некоја функција е „завршена“, но никој не го поседува нејзиното однесување по објавувањето. Ова е особено често кога испораката се мери со споени pull request-и или завршени тикети, наместо со трајна корисност.

Сопственоста треба да биде вградена во производот и во процесот на испорака. За секоја значајна способност, разјаснете кој е одговорен за:

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

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

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

Вградете ги ограничувањата во системот, не само во упатството

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

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

Корисните ограничувања се конкретни:

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

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

Дизајнирајте за незгодниот пат

Среќниот пат е местото каде што живеат демо-презентациите. Незгодниот пат е местото каде што се добива или губи довербата.

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

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

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

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

На далечинските тимови им е потребна пишана меморија за производот

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

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

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

Користете ВИ како засилувач на расудувањето

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

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

Едно едноставно прашање помага: Дали тимот би можел уверено да го одржува ова ако генерираниот резултат исчезне утре? Ако одговорот е не, резултатот сè уште не е средство. Тој е само непотврдена забрзаност.

Направете софтвер за кој вреди да се грижите

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

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

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