Когда говорят о выборе подхода для организации разработки ПО, забывают о первоначальной цели. Ведь ни у кого нет цели внедрить SCRUM или Kanban: скорее всего, нужно обеспечить наиболее эффективный процесс разработки конкретного ПО в конкретной команде и экономическом окружении.

Мы с 2015 года разрабатываем Okdesk — на сегодня самую популярную (более 800 активных клиентов на подписке) help desk систему для сервисных компаний и отделов. О том, как у нас устроен процесс разработки от идеи до передачи в техподдержку, о том, от каких фич и почему нужно отказываться, о том какой объем покрывать автотестами и многом другом в нашей статье. Конечно, с кучей реальных примеров!

Формирование бэклога продукта

Самый первый шаг в разработке продукта это… нет, не сбор требований. Это определение того, кто мы, для чего мы и куда идем. Еще это называют видением продукта (product vision) — понятная как для команды, так и для внешнего мира формулировка идеи продукта и задач, которые он должен решать (в формулировках бизнеса, а не фич).

Пример определения для help desk системы

Если коротко, Okdesk — система автоматизации процессов сервиса, техподдержки и выездного обслуживания инфраструктуры, которая помогает сервисным компаниям (на самом деле не только им) сокращать себестоимость услуг и клиентский отток, а также повышать качество исполняемых работ.

Для простоты говорим, что мы "Help Desk система для сервисных компаний".

Конкретнее: Okdesk будет лучшим выбором, если у вас есть распределенная инфраструктура, которая нуждается в обслуживании, причем как операционном (инцидентные заявки), так и регулярном (ППРы, плановое ТО).

Это может быть собственная сеть точек продаж или общепита, свой крупный объект (бизнес-центр, торговый центр, крупный отельный комплекс или парк развлечений) либо инфраструктура клиентов (в том числе ПО, транспортные средства и т.д.), с которыми заключены сервисные контракты.

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

Первоначальный бэклог, по которому была разработана первая версия продукта, которую мы начали продвигать и продавать на рынке (a.k.a. MVP), мы сформировали на базе своего десятилетнего опыта работы с enterprise-сегментом и адаптировали его для компаний малого и среднего бизнеса.
После разработки MVP уже важно поставить процесс наполнения бэклога так, чтобы он максимально соответствовал рыночным ожиданиями от продукта.

Примечание: 2 из 3-х сооснователя более 10 лет занимались разработкой, внедрением и продвижением известных Service Desk решений в компании Naumen

Кстати о том, как мы формируем бэклог, есть отдельная большая статья.

Продуктовая аналитика

Бэклог — это набор идей для развития продукта: сформулированы существующие клиентские проблемы, которые продукт либо не решает вовсе, либо решает плохо. Первый шаг на пути к реализации фичи — продуктовая аналитика. 

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

Как мы это делаем? Никаких серебряных пуль и чудесных инсайдов! Напрямую общаемся с клиентами, которые были источником соответствующей записи в бэклоге.

После проведения серии интервью формируется видение фичи — по аналогии с видением продукта. Оно определяет бизнес-цели и границы фичи, чтобы не начать делать что-то крутое и классное, но не очень нужное клиенту. При этом всегда важно соблюдать баланс цены за фичу (сколько мы потратим на нее времени с учетом зарплаты всех задействованных сотрудников) и ценности для клиента.

Реальный пример или зачем нужен модуль складского учета в help desk системе?

Одна из крупных записей в нашем бэклоге на текущий момент — реализация модуля складского учета. Складской учет — очень широкое понятие, причем в самом учете есть и бухгалтерские аспекты, и финансовые, и управленческие. Проведя серию интервью с десятками наших клиентов, мы сформировали для себя границы модуля складского учета, который, с одной стороны, позволит решить задачи клиентов, а с другой — нам не нужно будет погружаться в реализацию тонкостей бухгалтерского учета движений по складам и списаний и каким-либо образом заменять существующий бухучет склада (чаще всего используется система на базе 1С). Наоборот, наш модуль складского учета будет дополнять складской учет с точки зрения бухгалтерии еще и точкой зрения сервисной службы.

Важные нюансы:

• детальность проработки продуктовой аналитики зависит от объема задачи. Для небольших улучшений можно и не проводить интервьюирование: порой запись в бэклоге уже содержит в себе проблематику, и дополнительно выяснять подробности не требуется;

• не нужно пытаться реализовать в нишевом продукте любое требование, которое хочет ваш клиент! Часто после проведения продуктовой аналитики может оказаться, что выявленная потребность выходит за рамки нашего продуктового видения и само решение проблемы является отдельным продуктом. Например, так было с запросом на реализацию расчета зарплаты сотрудникам со сдельной оплатой труда. В рамках продуктового анализа мы определили, что Okdesk должен обеспечивать сбор данных для расчета сдельной оплаты, а вот сам расчет выходит за продуктовые рамки.

Системная аналитика

После того как проведена продуктовая аналитика и определено видение функции, начинается этап системной аналитики. Его цель — сформировать детальную техническую спецификацию новой функции. Затем по этой функции сможет работать отдел разработки и тестирования. Помимо детальной технической спецификации, в процессе системной аналитики формируются макеты интерфейсов, если это необходимо.

На этапе системной аналитики вполне нормально возвращаться на шаг назад, к продуктовой аналитике, чтобы задать уточняющие вопросы и скорректировать представление о бизнес-потребности.

Оценка задач с разработчиками

После того как будут разработаны функциональные спецификации и макеты интерфейсов, можно приступать к оценке трудозатрат на разработку. В рамках оценки производится детализация задач на подзадачи, там, где это возможно или разумно. В процессе оценки участвуют не только разработчики, но и аналитики, так как в рамках этого процесса команда ищет компромисс между сложностью разработки и ценностью того или иного принятого функционального решения. То есть идет поиск компромисса между ценой и ценностью. Что-то упрощается, что-то убирается вообще.

На этом этапе также может происходить отход на предыдущие шаги, включая продуктовую и системную аналитику.

На выходе получается оцененная спецификация с детализацией на подзадачи. В этот момент мы понимаем и цену фичи, и ее ценность для клиента. И если цена значительно превышает ценность, мы можем вообще отказаться от реализации фичи.

Планирование

После того как задача из продуктового бэклога была специфицирована (т.е. на нее были написаны спецификации и разработаны макеты интерфейсов) и оценена, она попадает в бэклог разработки. Хотя заказчики представляют это как линейный конвейер, из которого задачи берутся по порядку, внутри у нас это именно бэклог, и задачи из него берутся по своей процедуре планирования.

Реальный пример или как мы НЕ планируем на полгода вперед?

Мы можем себе позволить не строить детальные фича-планы на полгода вперед. Планируем следующим образом:

• у нас есть негласное правило, обусловленное в том числе и имеющимися ресурсами, что в работе должно находиться одновременно не более 2–3 крупных задач: это задачи, оценка которых занимает более 4–6 рабочих недель. После завершения одной крупной задачи в работу берем другую крупную задачу. Раз в неделю мы созваниваемся для обсуждения прогресса и плана работ по крупным задачам;

• небольшие задачи планируются по спринтам, спринт у нас занимает две недели, и раз в две недели мы берем в него оцененные задачи в зависимости от их текущего приоритета, наличия свободных человеко-часов на спринт в разрезе специализации (например, системы прав, UI и т.д.).

Разработка и автотесты

Структура отдела разработки выглядит следующим образом. Разработчики разбиты на команды, в каждой есть тимлидер, также есть отдельная группа QA (тестировщики), которая не привязана ни к одной команде разработки.

После планирования задачи распределяются по командам. Каждая команда обсуждает технический план решения задачи со своим тимлидером.

Разработчик пишет код и покрывает его автотестами. Надо сказать, что максимальное покрытие автотестами — наш выбор с первой строчки кода в продукте. И по прошествии семи с половиной лет мы глубоко убеждены в правильности этого выбора: мы тратим больше времени на написание фичи, но экономим колоссальное количество времени и нервов в будущем.

Некоторые сомневаются, тратить ли время на написание автотестов сейчас или отложить это до момента, когда они станут более крупной компанией с бОльшим количеством ресурсом. Наш совет: если вы хоть немного верите в свой продукт, покрывайте код автотестами как можно детальнее. Эти инвестиции очень быстро окупаются. В частности, дело не только в экономии времени, но и в репутации стабильного продукта с первых месяцев жизни.

Так, у нас, по статистике, клиенты находят не более 1–2 минорных багов в месяц, тогда как продукту уже более семи лет, а им пользуются более 800 компаний (и десятки тысяч пользователей).

После написания кода запускаются автотесты — не только написанные для новой функциональности, но вообще все, чтобы убедиться, что новый код не ломает старый (собственно, для этого автотесты и нужны). Если автотесты не проходят, задача возвращается разработчику на доработку: т.е. она не дойдет даже до тестирования, не то что до клиента.

После того как автотесты прошли, для некоторых задач запускается процедура продуктового ревью, когда продуктовый аналитик смотрит на то, что получилось, своими глазами, проверяет, все ли реализовано так, как задумано, и не нужно ли внести изменения в спецификацию, для того чтобы получить лучший результат. Этот этап позволяет избежать багов уровня аналитики, когда код вроде как написан по спецификации, но сама спецификация написана не совсем так, как нужно. То есть это тестирование кода не на наличие технических ошибок, а на наличие ошибок несоответствия бизнес-потребности.

Если автотесты прошли успешно, либо после автотестов успешно прошло продуктовое ревью, задача передается тимлидеру команды для ревью кода. На этом этапе проверяется соответствие кода принятым стандартам, осуществляется выявление потенциальных проблем с производительностью, соответствие принятым паттернам проектирования и архитектуре системы. Этот этап также влияет на долгосрочное качество и стабильность продукта. Кроме того, обязательность этапа код-ревью помогает избежать ситуации, когда код продукта превращается в кашу с разными паттернами и подходами, которую невозможно поддерживать. По результатам ревью задача может быть отдана назад разработчику на доработку с повторным прохождением автотестов и ревью либо переведена на тестирование.

Тестирование новой функциональности по спецификации

Заключительный перед доставкой клиенту этап — скрупулезное тестирование новой функциональности по спецификации. Задача не только в том, чтобы проверить, что все работает в соответствии со спецификацией, но и протестировать различные неочевидные и не лежащие на поверхности сценарии и сценарии, которые лежат на стыке использования новой и старой функциональности.

Если проводить только поверхностное тестирование или тестирование по очевидным сценариям для продукта, которым пользуются десятки тысяч пользователей каждый день, вероятность таки нарваться на неочевидные баги велика. Поэтому мы тестируем досконально. Иногда даже настолько досконально, что, проводя анализ найденных багов, продуктовый аналитик может принять решение оставить какую-то часть из них как «известные ошибки» (они так и висят в таком статусе, т.к. клиенты с ними не сталкиваются в реальной жизни, но если столкнутся, мы сразу же их исправим). После тестирования задача либо возвращается на доработку и проходит все этапы до тестирования, либо идет на релиз и доставляется клиенту.

Документирование и информирование

Но на самом деле тестирование — не самый последний этап. Сразу после успешного тестирования начинается этап документирования. Не технического, которое делается до разработки и корректируется в процессе: речь о разработке пользовательской документации. После релиза мы анонсируем новую фичу в нашем телеграм-канале и в новостной ленте внутри системы, а также анонсируем фичу в специальном канале в нашем корпоративном мессенджере для сейлов и технической поддержки.

Раз в две недели мы делаем демо для всей компании с рассказом о новинках, поэтому и маркетинг, и продажи, и техническая поддержка всегда в курсе всех новинок, для чего они нужны, какие бизнес-задачи решают и как ими пользоваться.

А еще раз в 5-6 месяцев мы проводим отчетные вебинары для всех желающих, но в первую очередь для наших клиентов, с ретроспективой новинок. Записи таких вебинаров мы потом выкладываем на нашем Youtube канале и, кстати, ближайший будет 13 декабря.

Действительно классная техподдержка

С первого дня существования Okdesk мы используем свою систему для организации технической поддержки наших клиентов: было бы странно, если бы мы использовали другой продукт или работали по электронной почте (само собой, мы принимаем заявки и по e-mail, но вся работа с обращениями ведется в централизованной системе).

Важно отметить, что правильнее называть нашу техническую поддержку консультационной поддержкой, потому что к нам нет вопросов, например: «Как работает А?» или «Как добавить Б?». Продукт нужно разрабатывать так, чтобы это было понятно и без дополнительных разъяснений. В нашем случае наибольшее количество вопросов связано с решением существующих процессных проблем или бизнес-задач. Они формулируются так: «В нашей компании есть задача А: как ее решить с помощью вашего продукта?»

Поэтому сотрудники консультационной поддержки должны одновременно хорошо знать продукт, предметную область и отраслевую специфику большинства наших целевых потребителей. Собственно, они выступают в роли консультантов по автоматизации. К сожалению, у подавляющего большинства вендоров (а мы, конечно, в своей ежедневной работе используем и другие решения) техподдержка — самое слабое звено. Ответы шаблонные и без вникания в суть. Но еще хуже, когда её роботизировали через чат-боты.

В процессе работы над заявкой на консультационной поддержке вначале разбираются аналитики поддержки с подключением тимлида поддержки, если решить задачу на своем уровне им не удается. В случае сложных кейсов подключаются продуктовые аналитики. Цель — решить задачу клиента либо найдя решение на текущей функциональности, либо добавить в продуктовый бэклог потребность клиента, которую мы пока не реализуем, чтобы решить ее в будущем.

Стоит сказать об уровне удовлетворенности: за первую половину 2022 года у нас 92% заявок оценены как «отлично», 6,5% — «нормально» и 1,5% — «плохо». По всем «плохим» заявкам мы делаем анализ причин и составляем отчет. Руководитель продукта раз в две недели делает анализ всех негативных оценок и причин этих оценок.

Надеемся наш опыт, пусть и без каких-то прорывных инсайдов (сложно принять факт, что их особо нет), поможет читателям в самое ближайшее время разработать новые массовые продукты или, как минимум, улучшить текущие процессы. Ну а если вам нужен серьезный продукт для автоматизации техподдержки и сервиса, то есть help desk, то вы, конечно, знаете где его найти!