Бизнис

Beyond the MVP: How Ownership Builds Products People Can't Live Without

Надвор од MVP: Како сопственоста гради производи без кои луѓето не можат да живеат

Повеќето производи можат да преживеат со MVP. Многу малку стануваат незаменливи поради него.

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

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

Сопственоста е поширока од одговорноста

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

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

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

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

Преминете од излезни резултати кон корисни исходи

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

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

Пред да се посвети на решение, техничкиот лидер може да му помогне на тимот да праша:

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

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

Дизајнирајте за вообичаените патеки на неуспех

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

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

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

Направете ги компромисите експлицитни

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

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

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

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

Силните оддалечени тимови ја прават сопственоста разбирлива. Проектот треба да има јасен исход, именуван носител на одлуки, заедничко место за тековниот статус и запис за важните компромиси. Ова не бара тежок процес. Бара доволно писмена јасност за колега во друга временска зона да може да придонесе без да ја реконструира целата историја.

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

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

Изградете системи што им дозволуваат на луѓето да поседуваат исходи

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

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

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

Што значи ова за кариерата на програмер

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

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

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

Производот по лансирањето

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

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

Портрет на автор на блогот

Mihajlo

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