Продвижение в очереди разработки

[Иван Козловский]

Уважаемый Planfix, объясните,

1. Как вы считаете спрос на доработки?
2. На чем основывается рейтинг?
3. Можно ли влиять на очередь доработок?

Например, тема Интеграции с сервисом Dadata viewtopic.php?f=32&t=4542 была создана 04.12.2017, является самой просматриваемой, но откладывается по непонятным причинам с последующей пролонгацией обещаний.
Свои мысли от такого подхода отразил тут: https://blog.planfix.ru/post/#comment-11930.

[Dmitry Goncharenko]

Спасибо за тему, Иван.

1. Как мы считаем спрос на доработки.
Сам спрос считается достаточно просто, почти в лоб - по количеству запросов. Почему "почти":
а) запросы считаются не от пользователя, а от аккаунта, причем учитывается его история (старые аккаунты и аккаунты на старших тарифах имеют больший вес, чем вчера зарегистрированные);
б) мы учитываем количество с привязкой ко времени. То есть, 10 запросов, пришедшие в течение 2 дней, в общем случае значат меньше, чем 10 запросов, пришедшие за 2 месяца.

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

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


2. На чем основывается рейтинг задачи.
У рейтинга две основные составляющие:

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

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

Небольшое отступление по поводу развития продукта:
- Оно не всегда в явном виде имеет под собой спрос со стороны пользователей, но при этом не менее важно. Простой пример - изменения в интерфейсе. О них просят редко, но если не проводить постоянную работу в этой области, продукт будет превращаться в динозавра: и в плане накапливающихся и мешающих работе атавизмов, и в плане восприятия новыми пользователями. С этой точки зрения полезно посмотреть на скриншоты старого интерфейса ПланФикса и сравнить его с текущим. Это постоянная работа, за которую нам редко говорят "спасибо" (хотя могут поругать), но которую нельзя не проводить.
- Другая плоскость, в которой соображения по развитию продукта влияет на рейтинг конкретной доработки: неочевидные со стороны цепочки задач задач. Достаточно часто, чтобы реализовать пользовательское пожелание Х, нам необходимо провести предварительную работу и доработать А, В и С, которые связаны с Х (и которых у нас никто не просил). Если этого не сделать, а попробовать "в лоб" изменить Х, то в долгосрочной перспективе мы получим нежизнеспособное решение, тупиковую ветвь развития, которую потом придется тяжело тянуть или очень больно и дорого вырезать и переделывать.
- Еще один момент из области развития продукта: технический долг. ПланФикс на порядок сложнее, чем большинство других систем. Это связано с тем, что ПФ это конструктор: мы не просто даем большой набор возможностей, но и позволяем применять одни возможности к другим (например, автоматические сценарии, массово изменяющие задачи с пользовательскими полями, изменение в которых вызывает срабатывание других сценариев и т.п.). Мы постоянно мониторим сами и получаем сообщения от пользователей из аккаунтов, в которых эти возможности были скомбинированы таким образом, что система недостаточно быстро отрабатывает какие-то операции. Изменения в работе системы, функционировании ее механизмов, которые призваны ускорить работу в подобных ситуациях, являются важной составной частью технического долга. Помимо этого в него входят работы по рефакторингу кода, ревизии используемого ПО более низкого уровня, перестройки системы для соответствия более новым его версиям и т.п.
- Ну и идеологический долг тоже нужно упомянуть. Когда-то на заре ПланФикс был обычной "жесткой" системой с заранее прописанной логикой работы для каждого раздела. Потом он стал мигрировать в сторону конструктора и в итоге развился именно в этой ипостаси. Но до сих пор в нем встречаются артефакты старых времен, когда все было "просто и понятно" . Самый известный из них, пожалуй, это раздел "Компания". Он должен быть фактически переписан заново, чтобы работа с сотрудниками и группами получила те же возможности, что и в других разделах - например, Задачи или Контакты: шаблоны, настраиваемые фильтры, универсальные типы пользовательских полей и т.п. Это означает большой кусок работы, который должен быть проведен на ходу "паровоза", чтобы "пассажиры" ничего не заметили. Помимо этого раздела, есть и множество других, более мелких артефактов, которые должны быть переработаны для лучшего соответствия духу и функциональности системы - хотя, как правило, запросов от пользователей на это не так уж много.

Конец отступления по поводу развития продукта, продолжаем про рейтинг.

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

Итак, мы имеем Сложность задачи и Выгоду от ее решения. Итоговый рейтинг задачи определяется как отношение выгоды к сложности. То есть, чем больше выгода и меньше сложность, тем выше рейтинг. Так как обе части этой "формулы" представляют собой экспертную оценку, соотношение представляет собой не некую цифру, а более сложное сочетание, которое нельзя просто выстроить в длинную цепочку по порядку. Важнее тут понимать сам принцип: первыми имеют шанс быть реализованы очень простые задачи, которые позитивно влияют на большое количество людей. А последними - очень сложные, которые мало кому нужны.

И это очень упрощенная схема. В реальном мире сюда вмешиваются дополнительные факторы, например количество разработчиков, чья квалификация позволяет выполнять задачи соответствующего уровня. Все новые разработчики начинают с уровня "Просто" и постепенно двигаются к "Средне". Именно с этим связано большое количество небольших изменений, которые мы регулярно выкладываем в новостях и ежемесячных отчетах. К уровню "Средне" разработчик, как правило, приближается к концу первого года работы в команде. Это связано с упомянутой мной выше повышенной внутренней сложностью ПланФикса. Задачи уровня "Сложно" на текущий момент могут выполнять буквально 2-3 человека. Соответственно, очереди "простых", "средних" и "сложных" задач продвигаются с разной скоростью и задачи, которые вполне закономерно воспринимаются как менее важные, зачастую делаются быстрее. При этом команда разработчиков планомерно растет, и тренируется на простых и средних задачах, это видно даже со стороны - количество доработок, которые мы сейчас производим за месяц, перестало помещаться в формат постов в социальных сетях и с лета мы перешли на их публикацию в блоге. Соответственно, темп разработки возрастает, и продвижение по всем очередям - тоже. Просто на очереди более сложных задач это почувствуется через время.

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

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

Важный вывод, который я бы хотел зафиксировать: планирование развития ПланФикса нельзя представить в виде одной линейной последовательности задач, чего-то вроде конвейера, по которому идут пожелания и на выходе с какой-то предсказуемой скоростью получаются готовые доработки. Это скорее полуавтоматический склад со множеством сложно устроенных стеллажей, по которым все время перемещаются задачи (и появляются новые, конечно). С этого склада мы достаем задачи, которые по ряду причин считаем на текущий момент наиболее подходящими - и реализуем их. До того момента, пока с этого склада не взята задача, нет никакой возможности сказать, когда она будет реализована. Именно поэтому бессмысленно задавать нам этот вопрос.


Почему просто не взять и не сделать голосование какие задачи делать?
Этот вопрос в теме не задан, но он периодически звучит, поэтому хочу сразу его затронуть. В принципе, ответ понятен из написанного выше, но еще раз, конспективно:
- Со стороны видно не все. В частности, не видна взаимосвязь задач, обычно не виден технический и не всегда идеологический долги.
- Мы любим наших пользователей и опираемся на их мнения - но решения по стратегии продукта должны приниматься ограниченным кругом лиц. И эти решения по определению выходят за рамки "очередных" задач.
- Задачи имеют разную сложность, а наша команда разработки - меняющиеся возможности по выполнению задач разной сложности.
- Линейная очередь имеет большую инерционность и плохо отражает изменяющийся спрос. Немалая часть задач теряет свою актуальность до момента реализации - обычно в результате появления альтернативных способов решить проблему. Если идти "по очереди" то пришлось бы либо расходовать ресурсы на эти, уже мало кому нужные, задачи, либо все равно действовать не по очереди, а по какой-то другой схеме на основе экспертной оценки, работающей поверх очереди.
- Маленькие задачи, актуальные только для части пользователей, в случае с очередью не решались бы никогда - их всегда перебивали бы те, которые нужны большему количеству людей. В текущей схеме они успешно решаются в процессе повышения квалификации начинающих разработчиков и радуют тех, для кого они очень актуальны.


3. Можно ли влиять на очередь доработок?
Только своими запросами на форуме или задачами в Службу поддержки. Собраться миром, навалиться и продавить ту или иную доработку - не получится (хотя это помогает получить стартовую поддержку и поместить задачу в очередь разработки). Заплатить и получить желаемую доработку - тоже. При этом эмоционально мы легко вовлекаемся в проблемы и предложения, которые высказывают наши пользователи. Нам очень хочется всем помочь, и желательно как можно быстрее. Но мы трезво оцениваем состояние очереди разработки и просто вынуждены мыслить стратегически, в рамках всего продукта и его развития. Слово "вынуждены" я использую не случайно - у нас просто нет других вариантов.


Про интеграцию с сервисом Dadata

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

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


Post Scriptum
- Несмотря на то, что это наиболее полное описание системы планирования разработки ПланФикса, оно существенно упрощено. Я сознательно обрубил "хвост" из кучи мелких нюансов и оговорок, чтобы сохранить хоть какую-то читабельность получившегося текста. В ходе дальнейшей дискуссии по мере необходимости буду раскрывать какие-то детали.
- Это 3-я или 4-я версия системы планирования. Вообще, это постоянно меняющаяся ткань, так что чем больше времени прошло с момента написания этого текста, тем существенней текущее положение вещей отличается от описанного. Пишу это для тех, кто попадет на этот текст через несколько лет.
- Вопросы, которые у вас будут возникать по теме планирования работы над ПланФиксом, можно и нужно задавать в этой теме. Мы со своей стороны тоже будем посылать сюда людей за ответами, чтобы не отвечать коротко и урезанно. Так что со временем получится полезная подборка информации.

[Михаил Храпунов]

Отличное описание процесса. Будем ждать исполнения хотелок :)

[Александр Лещинский]

Спасибо за тему, Иван.

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

[Dmitry Goncharenko]

Спасибо, Александр. Пока зафиксировал ссылку на этот топик в легкодоступном месте, на главной странице справки:

[А.А. Сахоненко]

Дмитрий, спасибо за такую подробность в описании того, что и для чего вы делаете.
Я получил просто интеллектуальный оргазм, знакомясь с твоими мыслями )

А можно попросить "хотелку" по мотивам написанного тобой? :)

Очень хотелось бы (хоть как-то) понимать (хотя бы примерное) место интересующей задачи в очереди.

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

И из этого было бы понятно - что делать.
Сейчас ведь когда я получаю от поддержки ответ типа
"мы обсудили в команде и поставили задачу в очередь".
просто совсем неясно, что делать:
то ли радоваться,
то ли искать альтернативный способ реализации )

А учитывая, что у вас есть такой справочник доработок и... можно ведь (чисто теоретически) выдавать к элементам этого справочника тем страдальцам, кто (как и я) не может понять, что же делать )))

Можно рассчитывать на появление такого?

[Dmitry Goncharenko]

Не думаю, что это реально, т.к.:
- Большая часть задач находится в статусе №2 "ваша задача в очереди, но когда мы ей займёмся - пока неясно"
- При этом простые задачи постоянно выдергиваются из этой очереди и достаточно быстро реализуются (в срок от нескольких часов до нескольких дней) - т.е. еще вчера был "статус №2" а сегодня автор получил сообщение "Мы сделали это, проверьте пожалуйста все ли работает так, как вы ожидали"

Получается, что предсказательной силы у такой системы примерно 0,0 - а затраты на ее поддержание были бы ненулевыми. Что делает ее очень далекой от реализации, согласно описанной выше системе :)

[Пятин Андрей]

Коллеги, приветствую.

видео и скрины размещены здесь: https://disk.yandex.ru/d/eDklc6TAYHYVIg

Суть проблемы в том, что раньше все непрочитанные напоминания и сообщения системы отображались не только количественно в хронике (хроника+2.png), но и в карточке самой задачи, подсвеченные желтым цветом (все комментарии.png).
Сейчас в карточке задачи отображается следующим образом (только последнее.png)
То есть не отображаются события типа «Задача создана» и напоминания.

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

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

В видео "ПФ события.mp4" приведен упрощенный пример. В реальной работе данный функционал доставляет большое неудобство, особенно в рамках проектной деятельности (где в одной задаче идет активная переписка с разными сотрудниками + используются напоминания). Помимо напоминаний не отображается событие «Задача создана», что крайне неудобно для работы продаванов, т.к. у них большой постоянный поток новых заявок, где первое событие всегда «Задача создана». То есть при наличии более поздних событий они реагируют на событие, подсвеченное желтым в карточке задачи, ставят его прочитанным и потом в хронике находят его и ставят прочитанным событие Задача создана и опять ставят прочитанным. Или вообще забивают на второе событие и потом, как дойдут в хронике до события по этой задаче, заново анализируют заявку и только в процессе работы с ней понимают, что уже ответили на эту заявку и достаточно проставить галку «Задача создана»

Проблема решается настройкой вида отображения: Отображать все действия. Но в таком случае отображаются все системные события, что отвлекает внимание при работе (усложняет процесс работы).

[Федоров Илья]

+

[Юрий Смирнов]

То есть не отображаются события типа «Задача создана» и напоминания.

Андрей, спасибо. А то я чувствовал, что что-то изменилось в последнее время. Но никак не мог понять, что именно.
Пожалуйста, верните, как было