Како бирамо идеје за развој наших производа: продавац мора бити у стању да чује…

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

Развијамо аутоматизовани систем поравнања (АЦС) – наплату. Термин
Животни век нашег производа је 14 година. За то време, систем је прошао пут од првих верзија индустријског мерача до модуларног комплекса који се састоји од 18 производа који се међусобно допуњују. Један од најважнијих аспеката дуговечности програма је континуирани развој. А за развој су потребне идеје.

Идеје

izvori

Постоји 5 извора:

1. Главни пријатељ програмера корпоративних информационих система је клијент. А клијент је збирна слика доносилаца одлука, спонзора пројеката, власника и извршилаца процеса, интерних ИТ стручњака, обичних корисника и великог броја људи који су заинтересовани у различитом степену. За нас је важно да сваки од представника клијента буде потенцијални добављач идеја. У најгорем случају, добијамо само негативне повратне информације о проблемима у систему. У најбољем случају, на страни клијента постоји особа која је стални извор идеја за побољшање, пружајући структуриране информације о потребама клијента.
2. Наш продавци и менаџери налога су други најважнији извор идеја за побољшање. Пуно и активно комуницирају са представницима индустрије, примају из прве руке захтеве за функционалност наплате од потенцијалних купаца. Трговци и налози морају бити свесни свих значајних промена у својој функционалности и најновијим ажурирањима софтвера конкурената, бити у стању да оправдају предности и недостатке различитих решења. Управо ови наши запослени први осећају да ли неке карактеристике наплате постају де фацто стандард, без којег се софтвер не може сматрати комплетним.
3. Власник производа један од наших топ менаџера или веома искусан менаџер пројекта. Има у виду стратешке циљеве компаније и у складу са њима прилагођава планове развоја производа.
4. Архитекта, особа која разуме могућности и ограничења изабраних/коришћених технолошких решења и њихов утицај на развој производа.
   Тимови за развој и тестирање. Људи који су директно укључени у развој производа.

Класификација погодака

Добијамо сирове податке из извора – писма, карте, усмене захтеве. Све
жалбе су класификоване:

• Консултације са значењем "Како то да урадим?", "Како то ради?", "Зашто не ради?", "Не разумем...". Позиви овог типа иду на линију подршке првог нивоа. Могуће је преобучити консултације у друге врсте жалби.
• Инциденти са значењем „Не ради“ и „Грешка“. Руковано са 2 и 3 линије подршке. Ако је потребно брзо поправити и ослободити закрпу, она се може пренети са подршке директно на развој. Могуће га је рекласификовати у захтев за промену и послати у заостатак.
• Захтеви за промене и развој. Уђите у заостатак производа, заобилазећи линије подршке. Али за њих постоји посебан поступак обраде.

Постоји таква статистика о погоцима - одмах након објављивања, број погодака за кратко време расте за 10-15%. Има и рафала позива када нови клијент са великим бројем корисника дође на наше услуге у облаку. Људи уче да користе нове функције софтвера, потребан им је савет. Чак и мали клијент, када почне да ради у систему, лако потроши више од 100 сати консултација месечно. Због тога, приликом повезивања новог клијента, увек резервишемо време за иницијалне консултације. Често чак издвајамо одређеног специјалисте. Трошкови закупнине, наравно, не плаћају ове трошкове рада, али се временом ситуација изједначава. Период адаптације траје, по правилу, од 1 до 3 месеца, након чега се потреба за саветовањем значајно смањује.

Раније смо користили самописна решења за чување позива. Али постепено прешао на Атлассиан производе. Прво је пренет развој да би се олакшао рад на Агиле-у, затим подршка. Сада сви критични процеси живе у Јира СД, плус имају различите додатке за Јира, плус Цонфлуенце. Самонаписана решења остала су само на процесима који нису критични за делатност компаније. Испоставило се да су наши задаци сада с краја на крај, могу се преносити између подршке и развоја без скакања са једног система на други.

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

Обрада захтева за измене

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

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

Управљање карактеристикама производа

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

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

Класификација захтева за промене и финансија

Развој је скуп. Стога ћемо вам одмах рећи које опције можемо имати ако је захтев за промену дошао од клијента, а не од запосленог.

Захтеви за измене се класификују на следећи начин: потребе специфичне за индустрију или индивидуалне карактеристике предузећа; значајну количину нове функционалности или малу исправку. Мале исправке и индивидуални захтеви се обрађују без икаквих додатака. Појединачни захтеви се обрачунавају и реализују за конкретног клијента у оквиру пројектног рада са њим.

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

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

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

ДевОпс

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

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

Поред система за издавање, постоји и формат брзих исправки грешака тако да купци не живе са грешкама шест месеци. Овај средњи формат ће вам омогућити да брзо одговорите на инциденте првог приоритета и испуните наведени СЛА.

Све наведено важи првенствено за корпоративни сектор и он-премисе решења. За услуге у облаку фокусиране на сегмент малих и средњих предузећа, не постоје тако широке могућности да корисници учествују у развоју производа. Формат закупа за СМБ то чак ни не сугерише. Уместо захтева за промену у виду јасних захтева од стране компаније, постоје само уобичајене повратне информације и жеље за услугу. Трудимо се да слушамо, али производ је огроман и жеља једног клијента да донесе нешто познато из свог старог историјског система може бити у супротности са стратегијом развоја система у целини.

Извор: ввв.хабр.цом