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

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

Развиваме автоматизиран систем за порамнување (ACP) - наплата. Термин
Животот на нашиот производ е 14 години. За тоа време, системот еволуираше од првите верзии на индустриски тарифен систем до модуларен комплекс кој се состои од 18 производи кои се надополнуваат еден со друг. Еден од најважните аспекти на долговечноста на програмите е постојаниот развој. А развојот бара идеи.

Идеи

Извори

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

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

Класификација на барања

Добиваме необработени податоци од извори - писма, билети, вербални барања. Сите
жалбите се класифицирани:

• Консултации со значење „Како да го направам тоа?“, „Како функционира?“, „Зошто не функционира?“, „Не разбирам...“. Барањата од овој тип одат во Линијата за поддршка на ниво 1. Можно е да се преквалификува консултацијата за други видови барања.
• Инциденти со значење „Не работи“ и „Грешка“. Обработено од 2 и 3 линии за поддршка. Доколку се неопходни брзи корекции и ослободување на лепенка, тие може да се пренесат од поддршка директно на развој. Можно е да се прекласифицира како барање за промена и да се испрати до заостанатиот број.
• Барања за промени и развој. Тие влегуваат во заостанатиот производ, заобиколувајќи ги линиите за поддршка. Но, за нив постои посебна процедура за обработка.

Има статистички податоци за барањата: веднаш по објавувањето, бројот на барања се зголемува за 10-15% за кратко време. Исто така, има зголемени барања кога нов клиент со голем број корисници доаѓа на нашите облак услуги. Луѓето учат да користат нови софтверски способности, им треба совет. Дури и мал клиент, кога почнува да работи во системот, лесно согорува повеќе од 100 часа консултации месечно. Затоа, кога поврзуваме нов клиент, секогаш резервираме време за првични консултации. Честопати избираме и специфичен специјалист. Цената за изнајмување, се разбира, не ги покрива овие трошоци за работна сила, но со текот на времето ситуацијата се изедначува. Периодот на адаптација обично трае од 1 до 3 месеци, по што потребата за советување е значително намалена.

Претходно користевме самостојно напишани решенија за складирање на барања. Но, постепено се префрливме на атласиски производи. Прво, го префрливме развојот за да биде полесно да се работи според Agile, а потоа поддршката. Сега сите критични процеси живеат во Jira SD, плус тие се поддржани од различни приклучоци за Jira, плус Confluence. Само напишаните решенија останаа само за процеси кои не беа критични за активностите на компанијата. Излегува дека нашите задачи сега се вкрстени и можат да се префрлат помеѓу поддршката и развојот без да скокаме од еден систем на друг.

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

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

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

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

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

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

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

Класификација на барања за промени и финансии

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

Барањата за промена ги класифицираме на следниов начин: потреба од индустријата или индивидуална карактеристика на претпријатието; значителна количина на нова функционалност или мала поправка. Малите поправки и индивидуалните барања се обработуваат без никакви важничене. Индивидуалните барања се пресметуваат и се спроведуваат за конкретен клиент како дел од проектната работа со него.

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

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

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

DevOps

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

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

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

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

Извор: www.habr.com