У цій статті поділюся досвідом відбору ідей для розвитку функціоналу наших продуктів та розповімо, як утримати основні вектори розвитку.
Ми розробляємо автоматизовану систему розрахунків (АСР) – білінг. Термін
життя нашого продукту 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