Кога демото е доказ, а кога не е

Демото е моќно затоа што апстрактните идеи ги претвора во нешто на кое луѓето можат да реагираат. Текот на работа што во белешка изгледа разумно може на телефон или во складиште веднаш да покаже вистинско триење.

Тоа е добрата страна на демото.

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

Зошто прототипите стануваат случаен авторитет

Видливите работи се убедливи. Екран што работи често добива повеќе неформален авторитет од запишано правило, дури и кога настанал само како експеримент.

Тоа е разбирливо. Луѓето му веруваат на она што можат да го видат.

Но во продуктна работа, особено во работа поддржана со AI, тој инстинкт може брзо да создаде забуна.

Демото може да прикаже:

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

Ништо од тоа само по себе не значи дека демото треба да го редефинира производот.

Кога демото е добар доказ

Демото е вреден доказ кога помага да се одговори на прашања како:

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

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

Таквиот вид доказ е исклучително корисен.

Кога демото не е авторитет

Демото не треба тивко да ја надвладее продуктната спецификација.

Тоа не е правилниот примарен авторитет за прашања како:

• дали овој тек е официјално во обемот
• дали тоа е привремена кратенка или продуктна обврска
• дали тоа однесување поништува постоечко правило
• дали јавната документација треба да го опише како целен систем

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

Правилото на Let Books е добар модел

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

Тоа правило е важно затоа што спречува случајно управување преку прототип.

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

Зошто ова е уште поважно со AI

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

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

Може и брзо да рашири привремени претпоставки кога не е.

Затоа тимовите треба да имаат видлив ред на авторитет.

Практичен синџир на авторитет

За ваков вид работа, корисен редослед е:

1. продуктна спецификација
2. имплементациски насоки
3. документација за тековна состојба
4. демо или прототип
5. тестови и валидација

Демото и понатаму е важно. Само е важно внатре во документиран систем, наместо да го замени.

Што да се направи кога демото ќе ве научи на нешто ново

Понекогаш прототипот е во право, а спецификацијата е погрешна, нецелосна или премногу апстрактна.

Тоа не е неуспех. Токму тоа е една од причините зошто се градат демоа.

Правилниот одговор е:

1. да се забележи откритието
2. да се одлучи дали новото однесување треба да стане намерно
3. да се ажурираат спецификацијата и документацијата
4. потоа и понатаму да се зачува усогласеноста

Погрешен одговор е документацијата да остане непроменета и сите да се надеваат дека ќе запомнат оти демото сега е вистинскиот извор на вистина.

Зошто ова треба да ги засега институциите и студентите

Институциите мора да знаат дали оценуваат концепт, прототип или одобрен модел на работен тек.

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

Трајна лекција

Демата се вредни затоа што ги прават продуктните идеи проверливи. Стануваат опасни кога тивко стануваат политика.

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