🦇Создание продукта Targetprocess 3

Targetprocess — это система управления проектами с фокусом на скрам, канбан и прочие гибкие процессы. Системе много лет, начиналась она в 2004, переписывалась с нуля в 2006, и дожила до наших дней. Я расскажу, как мы сделали новую версию.

Это заняло 17 месяцев упорного, ежедневного, терпеливого труда. Некоторые вещи переделывались по нескольку раз (да, я знаю, что это плохо). Некоторые остались доделанными не до конца (и тут я тоже в курсе, что это нехорошо). Мне не стыдно за промежуточный результат.

Переписать с нуля

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

Хочу заметить, что крайне опасно переписывать систему всю целиком. Это может пройти с небольшим продуктом типа Basecamp, но это будет очень опасная инициатива для проекта уровня JIRA или там Evernote. Поэтому лучше переписывать по частям. Мы начали с фронт энда.

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

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

Прототип и основные идеи

Итак, в ноябре 2011 я зафигячил прототипчик, где заложил основы нового подхода и нового UI. Основная идея — создание любых двумерных бордов (Олег придумал), а также визуализация информации в любом нужном виде. Нужно тебе борд — пожалуйста. Хочешь обычный лист — нате. Таймлайн? Тоже вот. Так что делаешь ты выборку того, чего тебе надо, и смотришь на эту выборку с любого ракурса.

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

Много команд и проектов

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

Другие фундаментальные решения были такие.

DSL

У нас появится свой DSL, с помощью которого мы будем фильтровать данные, добавлять данные и изменять данные (пока только фильтрование сделано). Фильтр сейчас выглядит например так

?RequestType is "Issue" and EntityState.IsFinal != true and CreateDate > today - 30(days)

Comet

Ну и очень хотелось сделать асинхронный апдейт, чтобы не рефрешить страничку, когда что-то меняется (Comet). Сразу скажу, это заняло ГОРАЗДО больше времени, чем думали. Но мы его все же сделали.

Идеальный План (never happens)

Вот он, первый родмэп, сбацанный в самом начале 2012 года. Как видите, в Августе 2012 мы хотели иметь первый публичный релиз. Ошиблись всего-то раза в два с половиной (но сделали из этого плана не все, даже сейчас, правда кое-что другое сделали).

Тут у нас было четкое разделение на две команды: Ядро (бэк энд), и JS (фронт энд). Дружили они через API, которое согласовывали не щадя сил.

Решено было начать с бордов. Потому что листы делать скучно, их и так в текущей версии навалом. А борды интереснее и полезнее для канбана. Там же и DSL недалеко был, а на Comet сгоряча выделили месяц (на самом деле потратили 5).

Дизайн

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

Вообще мы любим скетчить. И обсуждать. Сейчас у нас есть дизайнерский чат, в котором обсуждаются всякие идеи и доработки. Если коротко не получается обсудить, собираемся вместе и обсуждаем лично. Вот пример очень свежего чата:

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

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

А вот немного другой вариант, с табами сверху. Зато борд на всю ширину.

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

Вам, наверное, интересно (на самом деле нет), как выглядел первый рабочий дизайн системы. Да вот он. Тут пока еще слишком много лишних линий, слишком навязчивые карточки, слишком яркие цвета. Ну все слишком сырое конечно. Потом было много-много всяких правок.

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

Вот, к примеру, первый прототипчик:

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

А тут у нас идет горячий спор по поводу архитектуры (январь 2012):

Планы и реальность

Поговорим о планах. Ни один из наших планов не был выполен.

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

Январь 2012

Планы выпустить первую публичную версию в августе.

Апрель 2012

Как видим, уже отложено изменение модели и запаздывает DSL. Но в целом особых поводов для беспокойства как бы и нет. В команде JS сильно затянулись доделки Views и наметилось опоздание на 1 месяц (это за 3 месяца работы).

Начало июня 2012

Неожиданно пришлось серьезно переделывать поддержку команд. Вскрылось очень много разных новых кейсов, которые вообще не были предусмотрены сначала. Quick Add хотели закончить в июне (на самом деле совсем закончили только в декабре!). Комету хотели сделать за полтора месяца (закончили в декабре!).

Август 2012

Все сдвинулось и немного изменилось. К этому времени уже вышел довольно стабильный билд, который мы использовали сами и потихоньку начали показывать клиентам. То есть вместо публичного билда в августе вышла можно сказать альфа. Ну, тоже результат. Batch actions, Encoding и Timeline — все крайне, крайне оптимистично. Они так и не начались до сих пор.

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

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

Планирование по кварталам — то что надо. Мы выбираем 3-5 приличных фич, которые в данный момент наиболее важны (как мы определяем важность — отдельный разговор), и запускаем UX фазы этих фич. У каждой фичи есть Feature Owner, который ответственен за выработку решения. Он собирает UX команду, проводит собрания, документирует результат, и так далее.

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

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

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

А в ноябре вся команда вошла в режим SUBBOTNIK и работала в нем полтора месяца. Тут и сказке конец.