Спасибо за тему, Иван.
1. Как мы считаем спрос на доработки.
Сам спрос считается достаточно просто, почти в лоб - по количеству запросов. Почему "почти":
а) запросы считаются не от пользователя, а от аккаунта, причем учитывается его история (старые аккаунты и аккаунты на старших тарифах имеют больший вес, чем вчера зарегистрированные);
б) мы учитываем количество с привязкой ко времени. То есть, 10 запросов, пришедшие в течение 2 дней, в общем случае значат меньше, чем 10 запросов, пришедшие за 2 месяца.
Это сделано, чтобы защитить систему от попыток накрутки: и в интересах продукта, и в интересах пользователей сделать так, чтобы бОльшим весом обладали задачи, которые реально постоянно нужны разным людям.
Технически на текущий момент каждое пожелание оформлено как задача в проекте "Очередь разработки" нашего аккаунта ПланФикса. Дополнительные запросы на эту же доработку добавляются в чек-лист этой задачи в виде ссылок. Количество пунктов в чек-листе характеризует количество запросов + ссылки помогают после реализации доработок пройтись по задачам/форуму/блогу/соцсетям где звучали запросы и сообщить тем, кто это просил, что доработка реализована.
2. На чем основывается рейтинг задачи.
У рейтинга две основные составляющие:
-
Сложность. Параметр сам по себе составной, характеризующий совокупность объема работы, который нужно провести (условно, человекочасы) и квалификацию разработчика (разработчиков), которому можно поручить эту задачу. Сейчас этот параметр имеет 3 состояния: Просто, Средне, Сложно.
-
Выгода от доработки. Она определяется спросом (т.е. сколько людей мы осчастливим, сделав эту доработку) и соображениями, связанными с развитием продукта.
Небольшое отступление по поводу развития продукта:
- Оно не всегда в явном виде имеет под собой спрос со стороны пользователей, но при этом не менее важно. Простой пример - изменения в интерфейсе. О них просят редко, но если не проводить постоянную работу в этой области, продукт будет превращаться в динозавра: и в плане накапливающихся и мешающих работе атавизмов, и в плане восприятия новыми пользователями. С этой точки зрения полезно посмотреть на
скриншоты старого интерфейса ПланФикса и сравнить его с текущим. Это постоянная работа, за которую нам редко говорят "спасибо" (хотя могут поругать), но которую нельзя не проводить.
- Другая плоскость, в которой соображения по развитию продукта влияет на рейтинг конкретной доработки: неочевидные со стороны цепочки задач задач. Достаточно часто, чтобы реализовать пользовательское пожелание Х, нам необходимо провести предварительную работу и доработать А, В и С, которые связаны с Х (и которых у нас никто не просил). Если этого не сделать, а попробовать "в лоб" изменить Х, то в долгосрочной перспективе мы получим нежизнеспособное решение, тупиковую ветвь развития, которую потом придется тяжело тянуть или очень больно и дорого вырезать и переделывать.
- Еще один момент из области развития продукта: технический долг. ПланФикс на порядок сложнее, чем большинство других систем. Это связано с тем, что ПФ это конструктор: мы не просто даем большой набор возможностей, но и позволяем применять одни возможности к другим (например, автоматические сценарии, массово изменяющие задачи с пользовательскими полями, изменение в которых вызывает срабатывание других сценариев и т.п.). Мы постоянно мониторим сами и получаем сообщения от пользователей из аккаунтов, в которых эти возможности были скомбинированы таким образом, что система недостаточно быстро отрабатывает какие-то операции. Изменения в работе системы, функционировании ее механизмов, которые призваны ускорить работу в подобных ситуациях, являются важной составной частью технического долга. Помимо этого в него входят работы по рефакторингу кода, ревизии используемого ПО более низкого уровня, перестройки системы для соответствия более новым его версиям и т.п.
- Ну и идеологический долг тоже нужно упомянуть. Когда-то на заре ПланФикс был обычной "жесткой" системой с заранее прописанной логикой работы для каждого раздела. Потом он стал мигрировать в сторону конструктора и в итоге развился именно в этой ипостаси. Но до сих пор в нем встречаются артефакты старых времен, когда все было "просто и понятно" . Самый известный из них, пожалуй, это раздел "Компания". Он должен быть фактически переписан заново, чтобы работа с сотрудниками и группами получила те же возможности, что и в других разделах - например, Задачи или Контакты: шаблоны, настраиваемые фильтры, универсальные типы пользовательских полей и т.п. Это означает большой кусок работы, который должен быть проведен на ходу "паровоза", чтобы "пассажиры" ничего не заметили. Помимо этого раздела, есть и множество других, более мелких артефактов, которые должны быть переработаны для лучшего соответствия духу и функциональности системы - хотя, как правило, запросов от пользователей на это не так уж много.
Конец отступления по поводу развития продукта, продолжаем про рейтинг.
Технически "Сложность" это поле типа "Список " в задаче-доработке. Его устанавливают специально обученные люди, один из которых - я. Мы с коллегами регулярно, 2 раза в неделю, общаемся по накопившимся вопросам, связанным с новыми предложениями по доработке и развитием продукта в принципе, оцениваем новые задачи и фиксируем сложность в этом поле, а выгоду - в более вольно формулируемой экспертной оценке.
Итак, мы имеем Сложность задачи и Выгоду от ее решения. Итоговый рейтинг задачи определяется как отношение выгоды к сложности. То есть, чем больше выгода и меньше сложность, тем выше рейтинг. Так как обе части этой "формулы" представляют собой экспертную оценку, соотношение представляет собой не некую цифру, а более сложное сочетание, которое нельзя просто выстроить в длинную цепочку по порядку. Важнее тут понимать сам принцип: первыми имеют шанс быть реализованы очень простые задачи, которые позитивно влияют на большое количество людей. А последними - очень сложные, которые мало кому нужны.
И это очень упрощенная схема. В реальном мире сюда вмешиваются дополнительные факторы, например количество разработчиков, чья квалификация позволяет выполнять задачи соответствующего уровня. Все новые разработчики начинают с уровня "Просто" и постепенно двигаются к "Средне". Именно с этим связано большое количество небольших изменений, которые мы регулярно выкладываем в новостях и
ежемесячных отчетах. К уровню "Средне" разработчик, как правило, приближается к концу первого года работы в команде. Это связано с упомянутой мной выше повышенной внутренней сложностью ПланФикса. Задачи уровня "Сложно" на текущий момент могут выполнять буквально 2-3 человека. Соответственно, очереди "простых", "средних" и "сложных" задач продвигаются с разной скоростью и задачи, которые вполне закономерно воспринимаются как менее важные, зачастую делаются быстрее. При этом команда разработчиков планомерно растет, и тренируется на простых и средних задачах, это видно даже со стороны - количество доработок, которые мы сейчас производим за месяц, перестало помещаться в формат постов в социальных сетях и с лета мы перешли на их публикацию в блоге. Соответственно, темп разработки возрастает, и продвижение по всем очередям - тоже. Просто на очереди более сложных задач это почувствуется через время.
Другой важный фактор: все задачи разбиты на определенные направления развития. Примеры таких направлений: Интерфейс, Сценарии, Фильтры, Интеграции и т.п. Направления с одной стороны независимые, но зачастую могут быть связаны между собой. Например, прямо сейчас в нескольких направлениях, связанных с Планировщиком и Фильтрами, лежат задачи, которые не могут быть реализованы до того, как мы переделаем интерфейс настроек фильтра. А этот интерфейс в свою очередь ждет переделки интерфейса настройки шаблона. Это примерно то, что я писал выше, про взаимосвязь изменения Х и предшествующих ему доработок А,В и С, но на более глобальном уровне - между направлениями, а не внутри одного направления.
Есть и другие факторы, но для начала их можно опустить - если что, расскажу о них в продолжении общения, если будут возникать вопросы, которые они хорошо иллюстрируют.
Важный вывод, который я бы хотел зафиксировать: планирование развития ПланФикса нельзя представить в виде одной линейной последовательности задач, чего-то вроде конвейера, по которому идут пожелания и на выходе с какой-то предсказуемой скоростью получаются готовые доработки. Это скорее полуавтоматический склад со множеством сложно устроенных стеллажей, по которым все время перемещаются задачи (и появляются новые, конечно). С этого склада мы достаем задачи, которые по ряду причин считаем на текущий момент наиболее подходящими - и реализуем их. До того момента, пока с этого склада не взята задача, нет никакой возможности сказать, когда она будет реализована. Именно поэтому бессмысленно задавать нам этот вопрос.
Почему просто не взять и не сделать голосование какие задачи делать?
Этот вопрос в теме не задан, но он периодически звучит, поэтому хочу сразу его затронуть. В принципе, ответ понятен из написанного выше, но еще раз, конспективно:
- Со стороны видно не все. В частности, не видна взаимосвязь задач, обычно не виден технический и не всегда идеологический долги.
- Мы любим наших пользователей и опираемся на их мнения - но решения по стратегии продукта должны приниматься ограниченным кругом лиц. И эти решения по определению выходят за рамки "очередных" задач.
- Задачи имеют разную сложность, а наша команда разработки - меняющиеся возможности по выполнению задач разной сложности.
- Линейная очередь имеет большую инерционность и плохо отражает изменяющийся спрос. Немалая часть задач теряет свою актуальность до момента реализации - обычно в результате появления альтернативных способов решить проблему. Если идти "по очереди" то пришлось бы либо расходовать ресурсы на эти, уже мало кому нужные, задачи, либо все равно действовать не по очереди, а по какой-то другой схеме на основе экспертной оценки, работающей поверх очереди.
- Маленькие задачи, актуальные только для части пользователей, в случае с очередью не решались бы никогда - их всегда перебивали бы те, которые нужны большему количеству людей. В текущей схеме они успешно решаются в процессе повышения квалификации начинающих разработчиков и радуют тех, для кого они очень актуальны.
3. Можно ли влиять на очередь доработок?
Только своими запросами на форуме или задачами в Службу поддержки. Собраться миром, навалиться и продавить ту или иную доработку - не получится (хотя это помогает получить стартовую поддержку и поместить задачу в очередь разработки). Заплатить и получить желаемую доработку - тоже. При этом эмоционально мы легко вовлекаемся в проблемы и предложения, которые высказывают наши пользователи. Нам очень хочется всем помочь, и желательно как можно быстрее. Но мы трезво оцениваем состояние очереди разработки и просто вынуждены мыслить стратегически, в рамках всего продукта и его развития. Слово "вынуждены" я использую не случайно - у нас просто нет других вариантов.
Про интеграцию с сервисом Dadata
Тут хороший пример (возможно, неочевидных) последствий оценки количества запросов с привязкой ко времени: каждый запрос все время мигрирует вверх и вниз по линии спроса. То, что год назад имело очень высокий спрос, сегодня может опуститься вниз, если не поступают новые запросы на этот функционал или их поступает мало. И наоборот, конечно. С задачей про интеграцию с dadata как раз такая ситуация - у нее был высокий спрос, но потом он снизился. И появление внешнего сервиса автозаполнения реквизитов тоже повлияло на этот показатель - мы стали получать меньше запросов. Это видно и по самой теме форума, и по количеству новых задач, поступающих в Службу поддержки.
При этом сама задача все еще имеет достаточно хороший совокупный рейтинг и постепенно продвигается к реализации. Проработана и описана логика интеграции. Разработан прототип интерфейса настройки интеграции. Так что несмотря на отсутствие четких сроков, у нее хорошие шансы быть реализованной и порадовать тех, для кого она актуальна.
Post Scriptum
- Несмотря на то, что это наиболее полное описание системы планирования разработки ПланФикса, оно существенно упрощено. Я сознательно обрубил "хвост" из кучи мелких нюансов и оговорок, чтобы сохранить хоть какую-то читабельность получившегося текста. В ходе дальнейшей дискуссии по мере необходимости буду раскрывать какие-то детали.
- Это 3-я или 4-я версия системы планирования. Вообще, это постоянно меняющаяся ткань, так что чем больше времени прошло с момента написания этого текста, тем существенней текущее положение вещей отличается от описанного. Пишу это для тех, кто попадет на этот текст через несколько лет.
- Вопросы, которые у вас будут возникать по теме планирования работы над ПланФиксом, можно и нужно задавать в этой теме. Мы со своей стороны тоже будем посылать сюда людей за ответами, чтобы не отвечать коротко и урезанно. Так что со временем получится полезная подборка информации.
