Автоматизираното генерирање код може да направи способен тим да изгледа побрз речиси преку ноќ. Груб интерфејс се појавува за неколку минути. Шаблонскиот код исчезнува. Развивачот може да премине од идеја до работен прототип со невообичаено малку пречки.

Тоа е корисно. Исто така, лесно е да се помеша со испорака на производ.

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

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

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

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

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

Таа изјава е покорисна од „изгради контролна табла за задоцнети барања“. Таа му дава простор на тимот да ги преиспита претпоставките. Дали на менаџерите им треба контролна табла, известување, дневен преглед или промена на правилата за доделување? Интерфејсот е предложено решение, а не самиот проблем.

Поставете неколку прашања пред да претворите барање во поттик, тикет или план за имплементација:

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

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

Користете го генерираниот код како нацрт, а не како одлука

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

Корисен работен принцип е едноставен: генерираниот код може да предлага; одговорните луѓе одлучуваат.

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

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

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

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

Претворете ја брзината во учење

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

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

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

Едно издание треба да биде поврзано со одлука. „Дали луѓето кликнаа на него?“ често е премногу површно. Подобрите прашања се поврзани со првобитниот проблем: Дали менаџерите за поддршка преземаа дејство порано за заглавените барања? Дали корисниците ја завршија задачата без да им треба објаснување? Дали новиот процес намали избегливо предавање?

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

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

Вградете одговорност во работата од далечина

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

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

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

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

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

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

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

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

Водете кон исходи што луѓето можат да ги почувствуваат

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

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