Проект: Microboard.io — доска для рисования в Jira  Публичный пост
26 января 2021     552   
Microboard.io - доска для рисования в Jira

В чем суть?

Рисовалка бордов типа Miro в виде плагина для Jira.

Откуда все пошло вообще?

Все началось с того, что я поставил Miro у себя на работе. Просто, чтобы рисовать схемки.
Никто не знал, что эта софтина нас так засосет. Прошел год и мы в ней накрепко погрязли.
Если раньше было ноушн, то по прошествии полугода все на него забили и начали клепать себе доски, доски досок, карточки на досках. Созваниваться с досками, делать презы на досках и вести на досках трекинг задач.

В общем, вляпались в это хуже некуда.

Все бы ничего, но меня всегда смущали две вещи:

  • Дороговато. Хотя это такое: раз используем, значит оптимально, тут им прям респект, умеют отжимать деньги. Но все равно дороговато на уровне всего остального.
  • Хреновый функционал для проектного менеджмента и прочих айтишных ребят в больших компаниях. Мы не смогли полноценно проинтегрироваться с джирой, поэтому гонять туда-сюда таски это прям боль. Формально интеграция существует, но много кривых сценариев и общее ощущение, что это сделано на отъебись. В итоге нам пришлось оставить такие богомерзкие плагины как structure и portfolio и платить за них дополнительно, хотя я бы с радостью с них съехал, если бы miro включала в себя подобный функционал.

Эти две мысли существовали со мной долго, но все это было на подкорке и я как-то не парился.

Пока в какой-то ясный летний послековидный день не наткнулся на пост Miro в блоге о том, что у них более 5 млн пользователей. В голове сразу сработал калькулятор. Взяв средний чек в 10$ и долю платящих в 20% я вывел, что они делают 10m MRR на изи, а скорее всего намного больше (MRR - monthly recurring revenue).
Т.е. в месяц это та сумма, которую я вряд ли могу заработать за жизнь, даже если буду великолепным и успешным продакт менеджером.
И вообще, это де-факто лярдовая компания уже сейчас, хотя они публично это не светят и вообще, стараются не выпячивать свой успешный успех.

ЗАВИСТЬ

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

И тут встал первоочередной вопрос.

Нет, не то, как сделать. Сделать это дело техники.

Как это продавать?

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

Значит нужно искать нишу

И тут же возникла следующая мысль.

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

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

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

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

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

В общем, нормальная гипотеза. Рабочая.

Дальнейшие азы продакт-менеджмента учат тому, что нужно пойти фигачить проблемные интервью, или рекламу там дать и половить лидов. В b2b это та еще задачка.
Поэтому к счастью, у нас обнаружился конкурент, который пронюхал ту же самую модель раньше нас и мы решили действовать иначе. "К счастью?" Я упоролся? Вовсе нет, сейчас объясню.
Знакомьтесь - Whiteboards for Jira

Они уже в продакшене и делают примерно то же самое, что подумалось сделать мне. Релизнулись в августе 2020 года.

Почему же наличие конкурента это счастье? Дело в том, что теперь не нужно тестировать спрос самим. Без лишних телодвижений нам стали более менее понятны базовые показатели спроса и монетизации.
Достаточно посмотреть число их платящих клиентов, оно открыто - 263 штуки на момент написания статьи (чуваки уже не в бете и эти клиенты платят им каждый месяц). Если в среднем там по 10 человек в команде, а человек стоит 2.5 доллара, то это 6,5k MRR. Ну, допустим в 2 раза меньше. Все равно будет 3к. Для старта нас устроит.

Чем же еще мне нравится этот конкурент?
Дело в том, что его продуктом пользоваться неприятно.
Он херово работает. Лагает, тормозит, не держит большого числа элементов на доске.
Все потому, что сделан на HTML, а не на canvas, как Miro. И даже при всем при этом, чуваки зарабатывают 6к баксов в месяц. А что, если сделать лучше, так и зарабатывать наверное можно больше?

Это стало рабочей гипотезой номер два.

И вот теперь уже можно поговорить о технологиях

Итак, гипотеза звучит так: сделать аналог miro для энтерпрайза который использует Jira и распространяться через Atlassian marketplace

При этом есть конкурент, который уже работает в этой нише и подтвердил спрос реальными клиентами.
И есть миллион конкурентов самой miro - т.е. разнообразные доски для рисования.

Теперь вернемся и подумаем, почему же к miro наблюдается такое привыкание. Так, что она проникла в нашу организацию и вытеснила ноушн, а ничто другое нет?

Я вижу следующие предпосылки

  1. Скорость и удобство интерфейса. Звучит слишком по-хипстерски, но это реально самая отзывчивая и удобная софтина из всех аналогичных. Совместная работа, когда изменения от других людей подтягиваются мгновенно и без проблем. Тупо приятно работать. А когда это делаешь ежедневно - это важно.
  2. Хорошие виральные механизмы (легко шарить другим людям, одновременное редактирование досок). В общем, подсел один человек -> подсаживается вся организация.
  3. Есть не только графические примитивы, но и базовые инструменты для продакт и проджект-менеджмента, а так же создания документации. Mindmap, CJM, Jira cards, Rich text.

Что же из этого нужно реализовывать в MVP, если следующая цель - загрузить в стор какую-то минимальную версию?

Пункт 3, пожалуй, мимо. Так как требует углубления в детали. У нас просто нет столько времени. Да и вряд ли он возможен без базового функционала

Пункт 2 будет обеспечиваться самой механикой взаимодействия с джирой. Сделаем то, чтобы доску можно было эмбедить в описание issue. Таким образом все кто в нее зайдут - смогут ознакомиться с плагином и начать в нем что-то делать. Используя Jira API это сделать достаточно просто.

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

С этим мы можем пойти к клиентам и предлагать им использовать у себя в работе.

Что ж, это достаточная идейная база для старта.

Страх и ненависть Canvas

Так уж получилось, что я имею чутка опыта в написании вещей на канвасе, а так же в гибридных технологиях, типа canvas + react. Просто в свое время писал игрушки для веба в качестве хобби.

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

Почитайте, как с этим развлекались в miro.

Тем не менее, если мы хотим скорости и приятности в работе, то у канваса нет альтернатив. HTML не подходит для динамической сущности досок и начинает выдавать меньше 10 fps даже в простейших случаях. На драг&дропе, ресайзе и других динамических вещах это уже начинает серьезно бесить.

При этом сейчас не обязательно все писать на голом канвасе. Для него есть высокоуровневые библиотеки, упрощающие работу. Например Pixie.
Или Konva, которую мы пока взяли за основу, так как для нее есть экспериментальная трансляция в реакт и реализация многих высокоуровневых событий.

Ну а реакт + канвас это гораздо более благодатная комбинация для контроля сложности разработки, чем просто канвас.

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

Поиск команды

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

А вот времени писать код лично - нет совсем. Да и особых ресурсов тоже.

Поэтому сейчас я в принципе не начинаю каких-либо проектов, пока не найду людей, которые бы захотели это делать вместе.
А чтобы найти таких людей - просто вбрасываю идеи в разговоре, когда вижу, что человек может быть потенциально заинтересован или подходит по профилю.
Разговоров у меня в жизни много, так что это работает.
Так и тут.
В разговоре с одним знакомым , обмолвился идеей и рассказал подробности. Ему понравилось. Так у проекта появились seed инвестиции и потенциальный руководитель продаж :) Кстати, он есть в клубе

Осталось дело за разработкой. В первую очередь нам нужен был способный фронтендер, который смог бы выстроить скелет MVP приложения.
Не скажу, что найти человека было легко. Вастрик сносил наш пост, VC.ru сносили наш пост, походу вселенная подумала, что мы спамеры и продаем гербалайф. Под впечатлением, я даже написал тут длинное нытье о сложностях поиска людей.
Но каким-то образом мы все-таки отыскали к нам в команду третьего человека - Сашу.
И принялись пилить прототип. Точнее Саша принялся, а мы усиленно даем советы и хеджируем его жизненные риски оплачиваем доширак.

Чем можем похвастаться?

Пока еще мало чем. Shame on us, тут люди вон за три дня бизнесы запускают и выкидывают идеи, если не могут сделать прототип за 2 недели. Походу мы так не умеем и уже идет четвертый месяц, а мы все пилим.

Есть демка с зумом доски, трансформером текста и отсутствием сохранения состояния и синхронизации (в движке это уже есть, но с багами и не допилено).

https://microboard.io/public/selectMode.html

Вообще же, сейчас делаем MVP, в котором будет следующее:

  1. Возможность рисовать текст, стрелочки и прямоугольные примитивы, с "бесконечным" зумом и произвольным масштабированием элементов. Важное условие - не должно быть заметных глазу/мешающих лагов интерфейса. WYSIWYG для текстовых полей. В общем, смотрим как работает miro и пытаемся сделать 5% оттуда, но чтобы эти 5% были не хуже.
  2. Реализовать базовые сценарии взаимодействия с джирой. Линковка тасок, синхронизация туда-сюда, показывание снэпшотов доски в самой джире. Вот это все.
  3. Синхронизация стейта доски между клиентами в реальном времени. Чтобы два синьора могли что-то набрасывать прямо во время митинга.

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

Какие технические грабли уже успели собрать (до бизнесовых пока не добрались)

  • Рич текст на канвасе оказался реально сложным. Убили месяц и решили дальше пока не усугублять, оставив только обычный текст.
  • Сложной оказалась синхронизация стейта досок между клиентами. Мы используем библиотеку fluid от MIcrosoft. Она работает, но ловили ряд непонятных багов. Хотя в принципе - работает, уже хорошо. Пока отставили в сторону, но будем доделывать дальше.

Бизнесовая цель у нас выйти на 10к-100к MRR. По нашей оценке это должно быть реально.
Мы понимаем, какой функционал нам нужен для старта и далее. Есть деньги на еду для разработчика и на команду в дальнейшем.

Зачем этот пост?

Сюда я хочу постить апдейты, чтобы осталось для истории. Ну и получать обратную связь, если будет что показать.

Так же приветствуются мнения, что мы дураки, все делаем не так и у нас ничего не получится :) Но за конструктивные комментарии заранее спасибо.

13 комментариев 👇
Gleb Kudriavtcev, Руководитель продуктов автор 1 февраля в 20:18

Апдейт за неделю с 25 января (хотели уже делать примитивы, но провозились с работой тачпада, корректным скроллом и масштабированием).

Слово Саше:

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

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

Вот к примеру несколько относительно не сложных вопросов. Дебаггер для ответа на них не нужен. Как узнать когда пользователь крутит колесо мыши? Двигает по тачпаду двумя пальцами вверх/вниз? А вправо/влево? Двигает пальцем вдоль правого края тачпада? Вдоль нижнего края? Масштабирует щипком?

Нужно слушать события. Какие? Вот несколько правдоподобных вариантов на выбор: wheel mousewheel touchstart touchmove touchend scroll DOMMouseScroll MozMousePixelScroll msContentZoom gesturestart gesturechange gestureend MSGestureStart MSGestureChange MSGestureEnd

Лучший вариант - wheel, для всего кроме щипка. Последние 9 - не стандартные и работают не во всех браузерах. scroll мы отключим, так как экран мы прокручиваем по-своему по-особому.
Тач-события - не смотря на название, не срабатывают для тачпада, они для тачскрина, а тачпад для браузера - это как мышь, жесты на тачпаде - это прокрутка колеса. mousewheel - нестандартное, хотя 5 лет назад им все пользовались, но теперь его заменило стандартное событие wheel.

Значит слушаем мы только wheel, а как мы отличаем жесты? Читаем свойства события. Если MouseEvent.ctrlKey - значит пользователь масштабирует щипком на тачпаде. Ну или с зажатым ctrl крутит колесо мыши, двигает двумя пальцами вверх/вниз по тачпаду, двигает вдоль левого края тачпада. События в браузере такие же загадочные многозначные и открытые для интерпретации как фильмы Дэвида Линча.
Если MouseEvent.shiftKey - значит пользователь двигает двумя пальцами вправо/влево по тачпаду или двигает вдоль нижнего края тачпада. Ну или с зажатым shift делает всё, что может вызвать wheel событие. Кстати, как можно определить, что использует пользователь: мышь или тачпад? - Никак, спросить у пользователя.

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

Сегодняшний билд -https://microboard.io/public/trackpad.html, прикрутили корректную работу с тачпадом (выбор режима тачпад или мышь скрыт за шестеренкой справа-вверху).

  Развернуть 1 комментарий

@glebkudr, Не ожидал, что в 2021 году программисту надо смотреть, как реагирует софт на прокрутку скролла.

  Развернуть 1 комментарий
Nikita Tanygin, Technical Product Manager 26 января в 17:54

Классная статья, спасибо :)

Дальнейшие азы продакт-менеджмента учат тому, что нужно пойти фигачить проблемные интервью, или рекламу там дать и половить лидов.

Меня всегда такой подход очень веселит при мыслях b2b, удачи любителям нарисовать lean canvas и "покастдевить".

Пара вопросов (не доебаться, а почелленджить):

  1. Вы учитывали ограничения JIRA API при проработке юзкейсов?
  2. Я не очень понял пойнт про конкуренцию с Miro. То есть теоретически вменяемая интеграция с Джирой в их исполнении если не убивает ваш продукт, то точно откусывает часть пользователей. Насколько велики шансы, что она не случится? И если случится, то чем соревноваться? Ценой и заточенностью под проектный менеджмент?
  Развернуть 1 комментарий

@angelooooook,

  1. Пока мельком глянули, кажется что у нашего конкурента (whiteboards for jira) все получается из того, чтобы мы хотели делать. Т.е. как минимум основной функционал взлетабелен.
  2. Я ребятам из Миро рассказывал про свои хотелки еще пару лет назад =) Они до сих пор не сделали ничего в эту сторону и судя по их развитию приоритеты совсем другие. Они, кажется, идут сейчас вширь. Но даже крутая интеграция миро в джиру не ломает нам сценарий stand alone инсталляции для крупняка, который боится за безопасность данных. Миро так не умеет и вряд ли в это пойдет, а мы можем предоставить такой продукт на рынке.
  Развернуть 1 комментарий

@glebkudr, удачи! Кейс хороший.
В современных интернетах можно заработать, выпустив абсолютно все что угодно, тем более что вы таргетите не price-sensitive рынок :) Озвученная экономика звучит правдоподобно, мне кажется, что точно можно больше.

  Развернуть 1 комментарий

Это может полететь в варианте self-hosted, когда хочется использовать Миро, но нельзя, потому что данные окажутся где-то в неизвестном облаке.

То есть вам скорее всего имеет смысл первым делать и продвигать плагин для Jira Server и ориентироваться на те компании, где безопасники запрещают Миро, ибо всё должно быть под своим контролем. Все эти банки и т.п. Там сразу будут тысячи пользователей, а не единицы-десятки тех, кто в облачной Джире.

Потому что если Миро разрешено (у нас тоже Jira + Miro), то я не вижу смысла пристраивать какой-то очередной плагин. Вообще для Джиры почти нет годных плагинов, по моему опыту: 9 из из 10 это ограниченные поделки. Потому у меня сразу предубеждение: я лучше буду использовать полноценное Миро и ставиты ссылку в Джире на доску из описания тикета или даже из отдельного поля и это будет good enough. Зато я использую полноценный Миро и не заморачиваюсь с очередным корявым плагином.

  Развернуть 1 комментарий

@zahhar, ставиты ссылку в Джире на доску из описания тикета

Конечно, в итоге все так и делают. И даже карточки линкуют. Но это супер-неудобно. И миро стоит в 2 раз дороже, чем сама джира :) Поэтому даже при наличии миро, в джире есть ему конкурент.

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

Вообще для Джиры почти нет годных плагинов, по моему опыту: 9 из из 10 это ограниченные поделки

Знаю несколько команд, которые при этом делают на них от 100к до миллиона долларов в год. Понятно, что это микробизнес, но и даже это уже приятно :) У нас используется больше десятка разнообразных плагинов.

  Развернуть 1 комментарий
Gleb Kudriavtcev, Руководитель продуктов автор 9 февраля в 07:54

Результаты к 8 февраля.

Глеб:

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

Записал видяшку, чем мне, например, не нравится работа с тасками в миро.
Декомпозируешь маиндмэп. В какой-то момент решаешь разбить задачи на таски и засунуть их в джиру. Все ок, только теперь они никак не привязаны к структуре и работать с этим нереально. Получается просто доска для рисования, а не инструмент для ведения проектов (не будешь же вручную выравнивать таски после любого изменения дерева).
https://gyazo.com/285f763ab229542671a603ed4954bf73

Саша:

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

Вот например добавили на доску текст и логику для его перетаскивания. Добавили фигуры, логика перетаскивания - такая же. Скоро нужно будет добавить группы фигур и текстов. К ним опять нужно будет добавить такую же логику. Тут возникает вопрос - если и текст, и фигуры можно перетаскивать в группе, так зачем на них нужна логика перетаскивания? Для группы достаточно и одного элемента. Теперь любой элемент на доске находиться как минимум в своей собственной группе, и перетаскивается вместе с ней.

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

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

  Развернуть 1 комментарий
Gleb Kudriavtcev, Руководитель продуктов автор 17 февраля в 16:07

Апдейт от 15 февраля.

  1. Сделали фигуры состоящие из безье кривых. Новые фигуры оказалось можно задать и сохранить прямо в интерфейсе. Интерфейс рисования минимальный, кривые рисуются автоматически через последовательность точек, редактировать кривые нельзя (передвигать или удалять точки нельзя, масштабировать стандартным трансформером можно будет, см. п. 5). Такой инструмент разработчика.
  2. Сделали базовые стрелки между фигурами. Стрелка ищет кратчайшее расстояние от своей конечной точки до фигуры (перпендикуляр к касательной). Когда все фигуры заданы безье кривыми, то поиск ближайшей точки на кривой - всего одна функция, которую мы взяли готовую из библиотеки для расчёта безье кривых. Это оказалось сильно проще, чем прописывать всю логику для каждого типа фигур отдельно. Та же библиотека рассчитывает квадрат вмещающий фигуру, а у него мы берём центр.
  3. Стрелки из одной кубической кривой (там 4 точки, концы плюс 2 контроля, которые нужны, чтобы линия подходила к фигуре перпендикулярно). Точно пока не пишем стрелки из нескольких кривых.

...Мы здесь

Далее планы:

  1. Дописываем стандартный трансформер (поведение для фигур, поведение для групп фигур и текста) с прошлой среды. Из всех работ трансформер оказался самым сложным. Это пока закончит работу над фигурами и стрелками.
  2. Нужно заменить textarea на contenteditable div, чтобы держать фокус редактора текста в пределах экрана. Тогда же можно заполнить контекстную плашку.
  3. Включаем синхронизацию с сервером.
  4. Делаем сущность - карточка из джиры. Рендер карточки делаем из уже написанных элементов (текста и фигур), и помещаем её в стандартный контейнер (группу), положение карточки (на самом деле положение группы) сохраняется на доске, как обычно - через флюид, но содержание карточки для рендера, подгружаем отдельно от флюида. В результате содержание карточки на доске одновременно может редактировать только один пользователь и содержание загружается и сохраняется в соответсвии с правами пользователя в джире, но контейнер карточки видят и могут передвигать все - во флюиде у нас нет прав пользователей.
  5. Делаем сущность перетаскивания карточки на сущности доски и назад. Добавляем возможность сворачивать группу в значок и разворачивать при нажатии на него. Добавляем возможность объединять группы перетаскиванием друг на друга.
  6. Релизим альфу/тестим имеющийся функционал на живых пользователях
  Развернуть 1 комментарий

формальная интеграция Miro с Jira это ты про https://miro.com/marketplace/jira/ или про https://help.miro.com/hc/en-us/articles/360017572414-Jira-Add-on?

  Развернуть 1 комментарий

@Kir,

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

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

  Развернуть 1 комментарий

@glebkudr, я там еще ссылку докинул=)
https://help.miro.com/hc/en-us/articles/360017572414-Jira-Add-on тоже кривота?

  Развернуть 1 комментарий

@Kir, откаментил =)

  Развернуть 1 комментарий
Рустам Хафизов, Предприниматель, продаю керамическую плитку 1 февраля в 20:29

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб