У гэтым артыкуле падзялюся вопытам адбору ідэй для развіцця функцыяналу нашых прадуктаў і раскажам, як утрымаць асноўныя вектары развіцця.
Мы распрацоўваем аўтаматызаваную сістэму разлікаў (АСР) - білінг. Тэрмін
жыцця нашага прадукта 14 гадоў. За гэты час сістэма прайшла шлях ад першых версій прамысловага тарыфікатара да модульнага комплексу, які складаецца з 18 прадуктаў, якія дапаўняюць адна адну. Адзін з найважнейшых аспектаў доўгага жыцця для праграм - пастаяннае развіццё. А для развіцця патрэбны ідэі.
ідэі
крыніцы
Можна вылучыць 5 крыніц:
- Галоўны сябар распрацоўніка карпаратыўных інфармацыйных сістэм - гэта кліент. А кліент - гэта зборны вобраз з ЛПРаў, спонсараў праекта, уладальнікаў і выканаўцаў працэсаў, інхаус айцішнікаў, радавых карыстальнікаў і яшчэ вялікай колькасці ў рознай ступені зацікаўленых асоб. Для нас важна, што кожны з прадстаўнікоў кліента патэнцыйна з'яўляецца пастаўшчыком ідэй. У горшым выпадку мы атрымліваем толькі негатыўную зваротную сувязь аб праблемах у сістэме. У лепшым - з боку кліента знаходзіцца чалавек, які з'яўляецца пастаяннай крыніцай ідэй для паляпшэння, які прадстаўляе структураваную інфармацыю аб патрэбах кліента.
- Нашы прадаўцы і акаўнт-мэнэджары з'яўляюцца другой па важнасці крыніцай ідэй для паляпшэння. Яны шмат і актыўна маюць зносіны з прадстаўнікамі галіны, з першых рук атрымліваюць запыты аб функцыянале білінгу ад патэнцыйных кліентаў. Прадаўцам і акаўнтам даводзіцца быць у курсе ўсіх значных змен свайго функцыяналу і апошніх абнаўленняў софту канкурэнтаў, умець абгрунтаваць плюсы і мінусы розных рашэнняў. Менавіта гэтыя нашы супрацоўнікі першымі адчуваюць, калі нейкія магчымасці білінгу становяцца дэ-факта стандартам, без якога софт нельга лічыць паўнавартасным.
- Уладальнік прадукта - Адзін з нашых топ-мэнэджараў або вельмі дасведчаны кіраўнік праектаў. Трымае ў галаве стратэгічныя мэты кампаніі і карэктуе ў адпаведнасці з імі планы па развіцці прадукта.
- архітэктар, чалавек, які разумее магчымасці і абмежаванні абраных/выкарыстоўваных тэхналагічных рашэнняў і іх уплыў на развіццё прадукта.
Каманды распрацоўкі, тэсціравання. Людзі якія непасрэдна займаюцца развіццём прадукта.
Класіфікацыя зваротаў
Ад крыніц мы атрымліваем сырыя дадзеныя - лісты, цікеты, вусныя запыты. Усё
звароты класіфікуюцца:
- Кансультацыі з сэнсам "Як зрабіць?", "Як гэта працуе?", "Чаму не атрымліваецца?", "Я не зразумеў…". Звароты гэтага тыпу сыходзяць на Лінію падтрымкі 1 узроўня. Магчыма перакваліфікацыя кансультацыі ў іншыя тыпы зваротаў.
- Інцыдэнты з сэнсам "Не працуе" і "Памылка". Апрацоўваюцца 2 і 3 лініямі падтрымкі. Пры неабходнасці аператыўнага выпраўлення і выпуску патча могуць быць перададзены з сапарта адразу ў распрацоўку. Магчымая перакваліфікацыя ў запыт на змяненне і адпраўка ў бэклог.
- Запыты на змены і развіццё. Пападаюць у бэклог прадукта, абыходзячы Лініі падтрымкі. Але для іх існуе асобная працэдура апрацоўкі.
Ёсць такая статыстыка па зваротах - адразу пасля рэлізу колькасць зваротаў вырастае на 10-15% на непрацяглы час. Таксама ўсплёскі зваротаў бываюць, калі ў нашы хмарныя сэрвісы прыходзіць новы кліент з вялікай колькасцю карыстальнікаў. Людзі вучацца карыстацца новымі магчымасцямі софту, ім патрэбны кансультацыі. Нават невялікі кліент пры пачатку працы ў сістэме лёгка спальвае больш за 100 гадзін кансультацый у месяц. Таму пры падключэнні новага кліента мы заўсёды рэзервуем час на першасныя кансультацыі. Часта нават вылучаем канкрэтнага спецыяліста. Кошт арэнды, вядома, не акупляе гэтыя працавыдаткі, але з часам сітуацыя выраўноўваецца. Перыяд адаптацыі займае, як правіла, ад 1 да 3 месяцаў, затым запатрабаванне ў кансультаванні істотна змяншаецца.
Раней для захоўвання зваротаў мы выкарыстоўвалі самапісныя рашэнні. Але паступова перайшлі на прадукты Atlassian. Спачатку перавялі распрацоўку, каб было прасцей працаваць па Agile, пасля саппорт. Цяпер усе крытычныя працэсы жывуць у Jira SD, плюс забяспечваюцца рознымі плягінамі да Jira, плюс Confluence. Самапісныя рашэнні засталіся толькі на некрытычных для дзейнасці кампаніі працэсах. Атрымалася, што задачы ў нас зараз скразныя, могуць перадавацца паміж падтрымкай і распрацоўкай без пераскоквання з адной сістэмы ў іншую.
З гэтай звязкі мы можам атрымаць дадзеныя па ўсіх задачах, планавых і фактычных працавыдатках, выкарыстоўваць розныя варыянты тарыфікацыі для кліентаў і фармаваць дакументацыю для ўнутраных патрэб і справаздачы перад кліентамі.
Апрацоўка запытаў на змену
Звычайна такія запыты прыходзяць у выглядзе патрабаванняў да функцыяналу. Наш аналітык вывучае запыт, фармуе спецыфікацыю і ТЗ верхняга ўзроўню. Перадае спецыфікацыю і ТЗ таму, хто аформіў дадзены запыт на ўзгадненне - мы павінны быць упэўненыя, што гаворым з заказчыкам на адной мове.
Атрымаўшы ад заказчыка пацверджанне, што мы адзін аднаго зразумелі правільна, аналітык заносіць запыт у бэклог прадукта.
Кіраванне функцыяналам прадукта
У бэклог назапашваюцца запыты на змяненне і развіццё, якія паступілі. Раз у паўгода збіраецца тэхнічная рада, які складаецца з дырэктара, кіраўнікоў суправаджэння, распрацоўкі, продажаў і архітэктара сістэмы. У фармаце абмеркавання рада разбірае і прыярытэзуе заяўкі з бэклога і ўзгадняе 5 задач па развіцці для рэалізацыі ў бліжэйшым рэлізе.
Фактычна тэхнічная рада рэагуе на патрабаванні галіны і рынка, разглядаючы запатрабаванні, зафіксаваныя ў заяўках. Усё, што мае малую актуальнасць, застаецца ў бэклогу і не даходзіць да распрацоўкі.
Класіфікацыя запытаў на змены і фінансы
Распрацоўка абыходзіцца дорага. Таму адразу раскажам, якія варыянты могуць быць у нас, калі запыт на змяненне паступіў ад кліента, а не супрацоўніка.
Запыты на змяненне класіфікуем наступным чынам: галіновае запатрабаванне або індывідуальная асаблівасць прадпрыемства; істотны аб'ём новага функцыяналу ці дробны фікс. Дробныя фіксы і індывідуальныя запыты апрацоўваюцца без нейкіх вынаходстваў. Індывідуальныя запыты пралічваюцца і рэалізуюцца для канкрэтнага кліента ў рамках праектнай работы з ім.
Калі гэта не масавае галіновае запатрабаванне і аб'ём функцыяналу вялікі, тое можа быць прынята рашэнне аб распрацоўцы новага асобнага модуля, які будзе прадавацца дадаткова да асноўнага функцыяналу. У выпадку паступлення такога запыту ад кліента мы можам узяць на сябе выдаткі на распрацоўку модуля, кліенту падаць модуль бясплатна або з частковай аплатай, а сам модуль выставіць у агульны доступ на продаж. Кліент на сябе ў такой сітуацыі бярэ частку метадалагічнай нагрузкі і ў сутнасці праводзіць на сабе пілотнае ўкараненне модуля.
Калі гэта масавае галіновае запатрабаванне, тое можа быць прынята рашэнне аб уключэнні новага функцыяналу ў базавы прадукт. Выдаткі ў гэтым выпадку кладуцца поўнасцю на нас, а новы функцыянал з'яўляецца ў актуальнай версіі праграм.
Старым кліентам прадастаўляецца абнаўленне.
Яшчэ можа быць так, што ў некалькіх заказчыкаў ёсць падобнае запатрабаванне, але на масавы прадукт яна не цягне. У гэтым выпадку мы можам выслаць спецыфікацыю гэтым замоўцам і прапанаваць падзяліць выдаткі на распрацоўку паміж імі. У выніку выйграюць усё: заказчыкі атрымліваюць рэалізацыю функцыяналу за нізкі кошт, мы ўзбагачаем прадукт, праз некаторы час астатнія ўдзельнікі рынка таксама могуць атрымаць функцыянал у сваё карыстанне.
DevOps
Распрацоўка рыхтуе два буйныя рэлізы ў год. У кожным рэлізе забраніраваны час на рэалізацыю 5 задач, якія паступілі ад тэхнічнай рады. Такім чынам за цякучкай мы ніколі не забываем аб развіцці прадукта.
Кожны рэліз праходзіць адпаведны комплекс тэсціравання і дакументавання. Далей дадзены рэліз усталёўваецца ў тэставае асяроддзе які адпавядае замоўца, той у сваю чаргу ўсё скурпулёзна правярае і толькі пасля гэтага рэліз перакладаецца ў прадакшн.
Дадаткова да рэлізнай сістэмы існуе фармат хуткіх багфіксаў, каб кліенты не жылі з памылкамі па паўгода. Гэты прамежкавы фармат дазволяць аператыўна рэагаваць на інцыдэнты першых прыярытэтаў і выконваць заяўленыя SLA.
Усё вышэйсказанае справядліва ў першую чаргу для карпаратыўнага сектара і on-premise рашэнняў. Для хмарных сэрвісаў, арыентаваных на SMB сегмент, такіх шырокіх магчымасцяў для кліентаў па ўдзеле ў развіцці прадукта няма. Фармат арэнды для SMB гэтага нават не мяркуе. Замест change request у выглядзе дакладных патрабаванняў ад карпаратыву тут толькі звычайная зваротная сувязь і пажаданні па сэрвісе. Мы стараемся прыслухоўвацца, але прадукт масавы і жаданне аднаго кліента прынесці са сваёй старой гістарычнай сістэмы нешта звыклае можа супярэчыць стратэгіі развіцця сістэмы ў цэлым.
Крыніца: habr.com