Как избираме идеи за развитие на нашите продукти: продавачът трябва да може да чуе...

В тази статия ще споделя опита си в избора на идеи за развитие на функционалността на нашите продукти и ще ви кажа как да поддържате основните вектори на развитие.

Разработваме автоматизирана система за сетълмент (ACP) - таксуване. Срок
Животът на нашия продукт е 14 години. През това време системата еволюира от първите версии на индустриална тарифна система до модулен комплекс, състоящ се от 18 продукта, които се допълват взаимно. Един от най-важните аспекти на дълголетието на програмите е постоянното развитие. А развитието изисква идеи.

идеи

източници

Има 5 източника:

1. Основният приятел на разработчика на корпоративни информационни системи е клиент. А клиентът е сборен образ на вземащи решения, спонсори на проекти, собственици и изпълнители на процеси, вътрешни IT специалисти, обикновени потребители и голям брой заинтересовани лица в различна степен. За нас е важно всеки от представителите на клиента да бъде потенциален доставчик на идеи. В най-лошия случай получаваме само отрицателни отзиви за проблеми в системата. В най-добрия случай от страна на клиента има човек, който е постоянен източник на идеи за подобрение, предоставяйки структурирана информация за нуждите на клиента.
2. наш търговци и акаунт мениджъри са вторият по важност източник на идеи за подобрение. Те активно и екстензивно комуникират с представители на индустрията и получават запитвания от първа ръка относно функцията за таксуване от потенциални клиенти. Продавачите и акаунтите трябва да са наясно с всички значителни промени в тяхната функционалност и най-новите актуализации на софтуера на конкурентите и да могат да обосноват плюсовете и минусите на различните решения. Това са нашите служители, които първи усещат дали някои възможности за таксуване стават де факто стандарт, без който софтуерът не може да се счита за завършен.
3. Собственик на продукта — един от нашите топ мениджъри или много опитен ръководител на проекти. Поддържа стратегическите цели на компанията и коригира плановете за развитие на продукта в съответствие с тях.
4. архитект, човек, който разбира възможностите и ограниченията на избраните/използваните технологични решения и тяхното въздействие върху развитието на продукта.
   Екипи за разработка и тестване. Хора, които участват пряко в разработването на продукта.

Класификация на заявките

Получаваме необработени данни от източници - писма, билети, устни молби. всичко
жалбите са класифицирани:

• консултации със значение “Как да го направя?”, “Как работи?”, “Защо не работи?”, “Не разбирам...”. Заявките от този тип отиват на Линия за поддръжка на ниво 1. Възможно е консултацията да се преквалифицира в други видове заявки.
• Инциденти със значение „Не работи” и „Грешка”. Обработени от 2 и 3 поддържащи линии. Ако са необходими бързи корекции и пускане на корекция, те могат да бъдат прехвърлени от поддръжка директно към разработка. Възможно е да го прекласифицирате като заявка за промяна и да го изпратите в неизпълнените задачи.
• Искания за промени и развитие. Те попадат в продуктовото изоставане, заобикаляйки линиите за поддръжка. Но за тях има отделна процедура за обработка.

Има статистика за заявките: веднага след пускането броят на заявките се увеличава с 10-15% за кратко време. Има също скокове в заявките, когато нов клиент с голям брой потребители дойде в нашите облачни услуги. Хората се учат да използват нови софтуерни възможности, имат нужда от съвет. Дори малък клиент, като започне да работи в системата, лесно изгаря повече от 100 часа консултации на месец. Затова при свързване на нов клиент винаги запазваме време за първоначални консултации. Често дори избираме конкретен специалист. Наемната цена, разбира се, не покрива тези разходи за труд, но с времето ситуацията се изравнява. Периодът на адаптация обикновено отнема от 1 до 3 месеца, след което необходимостта от консултиране значително намалява.

Преди това използвахме самостоятелно написани решения за съхраняване на заявки. Но постепенно преминахме към продуктите на Atlassian. Първо прехвърлихме разработката, за да улесним работата според Agile, след това поддръжката. Сега всички критични процеси живеят в Jira SD, освен това се поддържат от различни добавки за Jira, плюс Confluence. Самостоятелно написаните решения останаха само за процеси, които не са критични за дейността на компанията. Оказва се, че нашите задачи вече са междусекторни и могат да се прехвърлят между поддръжка и разработка, без да скачате от една система в друга.

От този линк можем да получим данни за всички задачи, планирани и реални разходи за труд, да използваме различни ценови опции за клиенти и да генерираме документация за вътрешни нужди и отчетност към клиентите.

Обработване на заявки за промяна

Обикновено такива заявки идват под формата на функционални изисквания. Нашият анализатор проучва заявката, създава спецификация и технически спецификации от най-високо ниво. Прехвърля спецификацията и техническите спецификации на лицето, подало това искане за одобрение - трябва да сме сигурни, че говорим на един и същи език с клиента.

След като получи потвърждение от клиента, че сме се разбрали правилно, анализаторът въвежда заявката в продуктовия архив.

Управление на функционалността на продукта

Закъснението натрупва входящи заявки за промяна и развитие. Техническият съвет, състоящ се от директора, ръководителите на поддръжката, развитието, продажбите и системния архитект, заседава на всеки шест месеца. Във формат на дискусия съветът анализира и приоритизира приложенията от изоставането и се споразумява за 5 задачи за разработка за изпълнение в следващото издание.

На практика техническият съвет отговаря на нуждите на индустрията и пазара, като преглежда нуждите, изразени в приложенията. Всичко, което е малко актуално, остава в изоставането и не достига развитие.

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

Развитието е скъпо. Затова веднага ще ви кажем какви опции можем да имаме, ако искането за промяна е от клиент, а не от служител.

Ние класифицираме заявките за промяна, както следва: нужда от индустрията или индивидуална характеристика на предприятието; значително количество нова функционалност или незначителна корекция. Незначителните поправки и индивидуалните заявки се обработват без никакви излишни средства. Индивидуалните заявки се изчисляват и изпълняват за конкретен клиент като част от работата по проекта с него.

Ако това не е масова нужда на индустрията и обемът на функционалността е голям, тогава може да се вземе решение за разработване на нов отделен модул, който да се продава в допълнение към основната функционалност. При постъпило такова искане от страна на клиент, ние можем да покрием разходите за разработване на модула, да предоставим на клиента модула безплатно или с частично заплащане и да обявим самия модул за продажба. В такава ситуация клиентът поема част от методическото натоварване и по същество провежда пилотно внедряване на модула върху себе си.

Ако това е огромна нужда от индустрията, тогава може да се вземе решение за включване на нова функционалност в основния продукт. Разходите в този случай са изцяло наши, а новата функционалност се появява в текущата версия на програмите.
На старите клиенти се предоставя актуализация.

Възможно е също няколко клиента да имат подобна нужда, но тя не отговаря на условията за масов продукт. В този случай можем да изпратим спецификацията на тези клиенти и да предложим да разделим разходите за разработка между тях. В крайна сметка всички печелят: клиентите получават функционалност на ниска цена, ние обогатяваме продукта и след известно време други участници на пазара също могат да получат функционалността за своя употреба.

DevOps

Разработката подготвя две големи версии годишно. Във всяко издание се запазва време за изпълнение на 5 задачи, получени от техническия съвет. Така, в рутината, ние никога не забравяме за разработването на продукта.

Всяка версия преминава през подходящ набор от тестове и документация. След това тази версия се инсталира в тестовата среда на съответния клиент, който от своя страна щателно проверява всичко и едва след това версията се прехвърля в производството.

В допълнение към системата за освобождаване има формат за бързи корекции на грешки, така че клиентите да не живеят с грешки в продължение на шест месеца. Този междинен формат ще ви позволи бързо да реагирате на инциденти с първи приоритет и да изпълните посочените SLA.

Всичко по-горе важи предимно за корпоративния сектор и локалните решения. За облачните услуги, насочени към SMB сегмента, няма толкова широки възможности за клиентите да участват в разработването на продукта. Форматът за наемане на SMB дори не предполага това. Вместо искане за промяна под формата на ясни изисквания от корпоративното парти, тук има само обикновена обратна връзка и желания за услугата. Опитваме се да слушаме, но продуктът е масов и желанието на един клиент да донесе нещо познато от старата си историческа система може да противоречи на стратегията за развитие на системата като цяло.

Източник: www.habr.com