Продукциябызды өнүктүрүү үчүн идеяларды кантип тандайбыз: сатуучу угушу керек...

Бул макалада мен өнүмдөрүбүздүн функционалдуулугун өнүктүрүү үчүн идеяларды тандоо боюнча тажрыйбам менен бөлүшөм жана өнүгүүнүн негизги векторлорун кантип сактоо керектигин айтып берем.

Биз автоматташтырылган эсептешүү тутумун (АСП) иштеп жатабыз - биллинг. Мөөнөтү
Биздин буюмдун колдонуу мөөнөтү 14 жыл. Бул убакыттын ичинде система өнөр жайлык тарифтик системанын биринчи варианттарынан бири-бирин толуктап турган 18 продукциядан турган модулдук комплекске чейин өзгөрдү. Программалардын узак мөөнөттүүлүгүнүн эң маанилүү аспектилеринин бири - бул дайыма иштеп чыгуу. Ал эми өнүгүү идеяларды талап кылат.

пикирлер

булактар

5 булак бар:

  1. Корпоративдик маалыматтык системаларды иштеп чыгуучунун негизги досу болуп саналат кардар. Ал эми кардар - бул чечимдерди кабыл алуучулардын, долбоордун демөөрчүлөрүнүн, процесстердин ээлеринин жана аткаруучуларынын, ички IT адистеринин, катардагы колдонуучулардын жана ар кандай деңгээлдеги көп сандагы кызыкдар адамдардын жамааттык образы. Биз үчүн кардардын ар бир өкүлү потенциалдуу идеялардын жеткирүүчүсү экендиги маанилүү. Эң начар учурда, системадагы көйгөйлөр тууралуу терс пикирлерди гана алабыз. Эң жакшы учурда, кардардын муктаждыктары жөнүндө структураланган маалымат менен камсыз кылуу, жакшыртуу үчүн идеялардын туруктуу булагы болгон кардар тарапта адам бар.
  2. биздин сатуучулар жана эсеп менеджерлери жакшыртуу үчүн идеялардын экинчи маанилүү булагы болуп саналат. Алар жигердүү жана кеңири тармактын өкүлдөрү менен баарлашып, потенциалдуу кардарлардан эсеп-кысап функциялары жөнүндө биринчи сурамдарды алышат. Сатуучулар жана аккаунттар өздөрүнүн функцияларындагы бардык олуттуу өзгөрүүлөрдү жана атаандаштардын программалык камсыздоосунун акыркы жаңыртууларын билип, ар кандай чечимдердин жакшы жана жаман жактарын актай алышы керек. Булар биздин кызматкерлер, алар эсептешүү мүмкүнчүлүгүнүн кээ бирлери де-факто стандартка айланып калганын биринчи сезишет, ансыз программалык камсыздоону толук деп эсептөө мүмкүн эмес.
  3. Продукт ээси — биздин топ-менеджерлердин бири же абдан тажрыйбалуу долбоордун менеджери. Компаниянын стратегиялык максаттарын эсинде сактап, аларга ылайык продукцияны өнүктүрүү пландарын түзөтөт.
  4. архитектор, тандалган/колдонулган технологиялык чечимдердин мүмкүнчүлүктөрүн жана чектөөлөрүн жана алардын продуктуну өнүктүрүүгө тийгизген таасирин түшүнгөн адам.
    Иштеп чыгуу жана сыноо топтору. Продукцияны иштеп чыгууга тузден-туз катышкан адамдар.

Сурамдардын классификациясы

Биз булактардан чийки маалыматтарды алабыз - каттар, билеттер, оозеки өтүнүчтөр. Баары
кайрылуулар классификацияланат:

  • кеп "Кантип жасоо керек?", "Кантип иштейт?", "Эмне үчүн иштебейт?", "Түшүнбөйм ..." деген маанини билдирет. Мындай түрдөгү суроо-талаптар 1-деңгээл колдоо линиясына өтөт. Консультацияны суроо-талаптын башка түрлөрүнө кайра даярдоого болот.
  • Окуялар "Иштебейт" жана "Ката" дегенди билдирет. 2 жана 3 колдоо линиялары менен иштетилген. Тез оңдоолор жана патчты чыгаруу зарыл болсо, аларды колдоодон түз иштеп чыгууга которууга болот. Аны өзгөртүү өтүнүчү катары кайра классификациялоо жана артта калууга жөнөтүү мүмкүн.
  • Өзгөртүүлөрдү жана өнүктүрүүнү талап кылуу. Алар колдоо линияларын айланып өтүп, продукциянын артта калышына киришет. Бирок алар үчүн өзүнчө иштетүү процедурасы бар.

Сурамдар боюнча статистика бар: чыгарылгандан кийин дароо суроо-талаптардын саны кыска убакытка 10-15% га көбөйөт. Биздин булут кызматтарыбызга колдонуучулардын саны көп жаңы кардар келгенде да суроо-талаптар көбөйөт. Адамдар жаңы программалык мүмкүнчүлүктөрдү колдонууну үйрөнүп жатышат, аларга кеңеш керек. Кичинекей кардар да системада иштей баштаганда айына 100 сааттан ашык консультацияларды оңой эле күйгүзөт. Ошондуктан, жаңы кардарды туташтырууда, биз ар дайым баштапкы консультациялар үчүн убакытты сактайбыз. Көбүнчө биз атайын адисти тандайбыз. Аренда баасы, албетте, бул эмгек чыгымдарды жабууга эмес, бирок убакыттын өтүшү менен кырдаал түзүлөт. Адаптация мезгили, адатта, 1 айдан 3 айга чейин созулат, андан кийин консультацияга муктаждык кыйла азаят.

Мурда биз суроо-талаптарды сактоо үчүн өз алдынча жазылган чечимдерди колдончубуз. Бирок биз акырындап Atlassian продукциясына өттүк. Биринчиден, биз Agile боюнча иштөөнү жеңилдетүү үчүн өнүгүүнү өткөрүп бердик, андан кийин колдоо көрсөттүк. Азыр бардык критикалык процесстер Jira SDде жашайт, ошондой эле алар Jira үчүн ар кандай плагиндер, плюс Confluence тарабынан колдоого алынат. Өз алдынча жазылган чечимдер компаниянын иши үчүн маанилүү болбогон процесстер үчүн гана калды. Көрсө, биздин милдеттерибиз азыр кайчылаш болуп, бир системадан экинчи системага өтпөстөн колдоо менен өнүгүүнүн ортосунда өтсө болот экен.

Бул шилтемеден биз бардык тапшырмалар, пландаштырылган жана иш жүзүндөгү эмгек чыгымдары боюнча маалыматтарды ала алабыз, кардарлар үчүн ар кандай баа варианттарын колдоно алабыз жана ички муктаждыктар үчүн документтерди жана кардарларга отчетторду түзө алабыз.

Өзгөртүү өтүнүчтөрү иштетилүүдө

Адатта, мындай суроо-талаптар функциялык талаптар түрүндө келет. Биздин аналитик суроо-талапты изилдеп, спецификацияны жана жогорку деңгээлдеги техникалык мүнөздөмөлөрдү түзөт. Бул суроо-талапты жактыруу үчүн тапшырган адамга спецификацияны жана техникалык мүнөздөмөлөрдү өткөрүп берет - биз кардар менен бир тилде сүйлөшүбүзгө ишенишибиз керек.

Кардардан бири-бирибизди туура түшүнгөнүбүздүн ырастоосун алгандан кийин, талдоочу суроо-талапты продукттун артта калган тизмесине киргизет.

Продукт функционалдуулугун башкаруу

Артта калган өзгөртүүлөр жана өнүгүүлөр боюнча келип түшкөн суроо-талаптар топтолот. Директор, колдоо, өнүктүрүү, сатуу жетекчилери жана системанын архитекторунан турган техникалык кеңеш ар бир жарым жылда чогулат. Талкуу форматында кеңеш артта калган тиркемелерди талдап, приоритеттерди белгилейт жана кийинки чыгарылышта ишке ашыруу үчүн өнүктүрүүнүн 5 тапшырмасын макулдашат.

Чынында, техникалык кеңеш арыздарда айтылган керектөөлөрдү карап чыгуу менен өнөр жай жана рыноктун талаптарына жооп берет. Анча-мынча мааниге ээ болбогондун баары артта калып, өнүгүүгө жетпейт.

Өзгөртүү өтүнүчтөрүнүн классификациясы жана каржы

Өнүгүү кымбатка турат. Ошондуктан, өзгөртүү жөнүндө өтүнүч кызматкерден эмес, кардардан келсе, бизде кандай варианттар болушу мүмкүн экенин дароо айтып беребиз.

Биз өзгөртүү өтүнүчтөрүн төмөнкүдөй классификациялайбыз: тармактык муктаждык же ишкананын жеке мүнөздөмөсү; жаңы функциялардын олуттуу көлөмү же кичине оңдоо. Майда оңдоолор жана жеке суроо-талаптар эч кандай бурмалоосуз иштетилет. Жеке суроо-талаптар аны менен долбоордук иштин алкагында белгилүү бир кардар үчүн эсептелинет жана ишке ашырылат.

Эгерде бул масштабдуу тармактык муктаждык болбосо жана функционалдуулуктун көлөмү чоң болсо, анда негизги функцияга кошумча сатыла турган жаңы өзүнчө модулду иштеп чыгуу чечими кабыл алынышы мүмкүн. Эгерде кардардан мындай суроо-талап түшсө, модулду иштеп чыгууга кеткен чыгымдарды жаап, кардарга модулду бекер же жарым-жартылай төлөп берип, модулдун өзүн сатыкка коё алабыз. Мындай кырдаалда кардар методикалык жүктүн бир бөлүгүн алат жана модулдун пилоттук ишке ашырууну өз алдынча жүргүзөт.

Эгерде бул чоң тармактык муктаждык болсо, анда негизги продуктка жаңы функцияларды киргизүү чечими кабыл алынышы мүмкүн. Бул учурда чыгымдар толугу менен биздин мойнубузга жүктөлөт жана жаңы функция программалардын учурдагы версиясында пайда болот.
Эски кардарларга жаңыртуу берилет.

Ошондой эле бир нече кардарлардын ушундай муктаждыгы болушу мүмкүн, бирок бул массалык продукт үчүн талаптарга жооп бербейт. Бул учурда, биз бул кардарларга спецификацияны жөнөтө алабыз жана алардын ортосунда иштеп чыгуу чыгымдарын бөлүштүрүүнү сунуштайбыз. Акыр-аягы, бардыгы утат: кардарлар функционалдык мүмкүнчүлүктү арзан баада алышат, биз продуктуну байытып жатабыз, ал эми бир нече убакыт өткөндөн кийин рыноктун башка катышуучулары да аларды колдонуу үчүн функцияларды ала алышат.

тамтык

Иштеп чыгуу жылына эки негизги релиздерди даярдайт. Ар бир чыгарылышта техникалык кеңештен алынган 5 тапшырманы аткарууга убакыт бөлүнөт. Ошентип, күнүмдүк иштердин ортосунда, биз продукт өнүктүрүү жөнүндө эч качан унутпа.

Ар бир чыгарылыш тиешелүү тестирлөөдөн жана документтердин топтомунан өтөт. Андан кийин, бул релиз тиешелүү кардардын сыноо чөйрөсүндө орнотулат, ал өз кезегинде бардыгын кылдаттык менен текшерет жана андан кийин гана чыгаруу өндүрүшкө өткөрүлөт.

Чыгаруу системасынан тышкары, кардарлар алты ай бою каталар менен жашабашы үчүн каталарды тез оңдоо форматы бар. Бул орто формат биринчи артыкчылыктуу инциденттерге тез жооп берүүгө жана айтылган SLAларды аткарууга мүмкүндүк берет.

Жогоруда айтылгандардын баары биринчи кезекте корпоративдик секторго жана жергиликтүү чечимдерге тиешелүү. SMB сегментине багытталган булут кызматтары үчүн кардарлар үчүн продуктуну иштеп чыгууга катышуу үчүн мындай кеңири мүмкүнчүлүктөр жок. SMB ижара форматы муну ойлобойт. Корпоративдик тараптан так талаптар түрүндөгү өзгөртүү өтүнүчүнүн ордуна, бул жерде кызматка карата жөнөкөй пикир жана каалоолор гана бар. Биз угууга аракет кылабыз, бирок продукт массалык жана бир кардардын эски тарыхый тутумунан тааныш нерсени алып келүү каалоосу бүтүндөй системанын өнүгүү стратегиясына карама-каршы келиши мүмкүн.

Source: www.habr.com

Комментарий кошуу