Абстракция и сложность

Всем известная картина.

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

Начнем с определений.

Абстрагирование — это процесс выделения общих правил и концепций из примеров и методов.

Абстракция — это результат процесса, то есть концепция, которая соединяет в себе все подчиненные концепции.

В процессе анализа я хочу получить ответы на следующие вопросы:

  1. Как изменялся уровень абстракции в различных областях с развитием человечества?
  2. Какая связь абстракции со сложностью и мощностью системы?
  3. Чем это нам всем помогает или мешает в разработке программ?

Если вам интересны только выводы — пройдите вниз. А начнем мы издалека.

Живопись

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

Реализм

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

Василий Перов. Охотники на привале. 1871

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

Все понятно. Никакой абстрактности.

Импрессионизм

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

Клод Моне. Впечатление. Восходящее солнце. 1872

Размытые силуэты гавани, странное сочетание цветов, неясность. В то время критики довольно едко высказывались о картинах импрессионистов. Например, так: «Обои, и те смотрелись бы более законченно, чем это „Впечатление“!» Сейчас импрессионистов любят все.

Абстракционизм

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

Пит Мондриан. Композиция с синим, красным и желтым. 1921

С одной стороны, мы видим просто прямоугольники разных цветов и размеров. С другой стороны, пространство интерпретаций картины огромно. Кто-то увидит в ней витражи католического собора, кто-то казнь Карла I, а кто-то неровность линии слева. Здесь высокий уровень абстракции увеличивает мощность системы.

Абстракционизм нравится далеко не всем. Многие люди его не понимают.

Поэзия

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

Начнем с какого-нибудь эпоса. Кусочек из Старшей Эдды.

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

Так нить судьбы
пряли усердно,
что содрогались
в Бралунде стены;
нить золотую
свили и к небу –
к палатам луны –
ее привязали.

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

Импрессионизм

Федерико Гарсия Лорка обычно писал не столь прямолинейные стихи. Вот, скажем, стихотворение Перекресток.

Восточный ветер.
Фонарь и дождь.
И прямо в сердце
нож.
Улица –
дрожь
натянутого
провода,
дрожь
огромного овода.
Со всех сторон,
куда ни пойдешь,
прямо в сердце –
нож.

1921

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

Футуризм

Чем дальше, тем меньше однозначности. Возьмем раннего Маяковского и его стихотворение “А вы могли бы?”

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

1913

И рассмотрим пару возможных трактовок данного стихотворения. Я приведу только небольшие отрывки:

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

И другой вариант, который лично мне кажется гораздо более близким к действительности:

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

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

Математика

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

Все началось с необходимости подсчитать количество нападающих волков и сравнить их с количество защищающихся людей, так что натуральные числа это счетные числа: 1, 2, 3, 4 и так далее. Надо сказать, что число 3 само по себе достаточно абстрактное понятие. На самом деле, его не существует в природе. Есть 3 дерева или 3 барана, но числа 3 нет.

Далее умные индусы придумали число ноль. Долгое время 0 вообще в Европе не считали числом, а каким-то условным символом. Даже в 17 веке находились господа, которые ноль знать не хотели. Отрицательные числа ввели, чтобы было удобно записывать долги и решать некоторые уравнения. В итоге получили целые числа: -2, -1, 0, 1, 2

Все бы хорошо, но иногда хочется что-то измерить. Например, длину отрезка. Для этого целых чисел будет недостаточно. На самом деле, если мой эталонный отрезок помещается в другом отрезке больше 1 но меньше 2 раз, то какая длина-то? На помощь приходят дроби. Делим один отрезок на другой и получаем дробь n/m. Такие числа называют рациональными.

Дальше сложно. Выяснилось, что есть числа, которые дробями не представишь. Например, число “пи”, или квадратный корень из двух. У древних Греков данный факт выносил мозг и они старательно не замечали таких чисел. Они называются иррациональными. Дать точное определение оказалось не так-то просто, вот Дедекинд смог.

Иррациональные числа гораздо сложнее представить, чем целые. В самом деле, что же такое Pi?

Но и это еще не все. Мы дошли до комплексных чисел, которые описываются в виде z = x + iy, где i — мнимая единица. К счастью, в наш просвященный век комплексные числа учат в школе. Но, к несчастью, понимает их примерно 5% учеников.

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

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

Физика

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

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


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

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

Функциональное программирование

Быстро пробежимся по верхам, не заглядывая в теорию категорий.

Самым примитивным уровнем является присваивание. Например var n = 1. Какой-то абстрактный символ n у нас будет равен 1. Все довольно просто.

Далее, появляются функции f(x) -> y. Принимаем на вход значение какого-то типа, отдаем другое значение какого-то типа. Скажем, эта функция добавляет единицу:

function addOne(a) {return a+1}

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

Повышаем уровень абстракции и добавляем функции высшего порядка. Тут мы уже можем принимать другие функции и возвращать функции f(g(x)) -> h(x). Тут уже мощность системы повышается и мы можем делать крутые штуки, замечать, что некоторые функции похожи и писать более абстрактные функции.

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


Мы создаем много таких абстрактных операций над списками (map, filter, group, skip, take, etc.), а потом замечаем, что на самом деле все они могут быть реализованы через ещё более абстрактную функцию reduce/fold.


А потом мы видим, что эту операцию reduce можно применять не только к спискам, но и к чему угодно, что имеет какую-то структуру (например, к дереву). Тут уже вступает в игру класс типов Foldable, на котором определены методы вроде fold. Если какой-то объект инстанциирует этот класс типов, определяя для себя реализацию fold, то такой объект сразу можно использовать с операциями map/filter/etc., которые были ранее определены через reduce.

Повышение уровня абстракции снова дает нам все более и более мощные решения.

Визуализация данных

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

Цены на хлеб, общий оборот, экспорт и размер долга на одном графике! Умное использование одной оси Y с пояснением, что цена на хлеб измеряется в фартингах, долг — в десятках миллионов, а оборот и экспорт — в сотнях миллионах. Интересно изучать корреляции. William Playfair. 1824

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

Excel. Выбираем график. Вообще stacked bar charts обычно плохи. Особенно трехмерные.

Кажется, на этом все? Конечно же нет! Жак Бертен совершил небольшой подвиг, написав великолепную книгу Semiology of Graphic. Он обобщил принципы построения визуалиций данных и открыл дорогу к совершенно новому уровню абстракции, который не только включает в себя все существующие известные диаграммы, но и позволяет легко придумывать новые.

Идеи Бертена развил Лиланд Вилкинсон, создав грамматику графики (grammar of graphics). Если вкратце, то каждая диаграмма состоит из следующих элементов:

Data
Algebra
Scales
Statistics
Geometry
Coordinates
Aesthetics

И мы можем комбинировать их для получения практически любых диаграмм. Например, фасетные диаграммы, которые не умеет строить практически ни одна js-библиотека (кроме taucharts и plot.ly), описываются крайне просто:

Фасетная диаграмма

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

Как видим, и в этой области решения становятся все более общими и мощными.

Пользовательский интерфейс

Переходим в гораздо более молодые и менее изученные сферы. Можно ли обобщить интерфейс, сделать его более абстрактным?

Самый нижний уровень — это конкретное решение конкретной проблемы. Так как мне ближе системы управления проектами, возьмем несколько примеров из Targetprocess. Нужен нам, к примеру, список багов. Мы берем и делаем отдельный экран, который решает только эту задачу.

Список багов в Targetprocess 2

Каждый экран в системе в чем-то уникален. Конечно, есть общие принципы. Но в целом это отдельные страницы со своим кодом.

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

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

  • List — иерархичные списки, знакомые всем.
  • Board — группировка данных по двум осям. Kanban борды например.
  • Timeline — данные во времени. Диаграмма Ганта или родмэпы.
  • Calendar — обычный календарь по дням или месяцам, бывает удобно.
  • Network — визуализация зависимостей сущностей.
  • Single Entity View — карточка одной сущности.
  • Single Entity Edit/Add — добавление и редактирование одной сущности.
  • Report — любые графические отчеты. Слово “любые” сразу делает этот компонент очень сложным.
  • Dashboard — композиция разных представлений в одном месте для удобства быстрого доступа.

Весь набор высокоуровневых UI компонент, на которых можно построить практически любое Enterprise приложение.

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

Я называю это динамическим UI. В Targetprocess 3 мы именно его и делаем. Например, у нас можно создать List, Board или Timeline любых сущностей.

Enterprise приложения

Как развивались и будут развиваться Enterprise приложения?

Разработка на заказ

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

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

Продукты

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

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

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

Какое же идеальное Enterprise приложение? Оно должно подстраиваться под любую компанию без вовлечения программистов.

Представьте себе, выбираете вы софт для управления проектами и вам говорят: “Для начала мы должны выяснить, как вы работаете. Потом мы помогаем вам установить и настроить систему именно так, как вам нужно. Там будут только нужные вам сущности, с нужными свойствами и правилами, в привычной вам терминологии, только полезные экраны и ничего лишнего”.

Как вообще можно достичь такой нирваны?

Грамматика домена

Я думаю, нам нужно изобрести грамматику домена. Она может состоять примерно из таких вещей:

  • Entities — можно создавать любые сущности, с любыми полями.
  • Relations — сущности можно связывать между собой.
  • Metrics — в системе можно вычислять любые метрики. Например, прогресс по проекту в разных компаниях считается очень по разному.
  • Rules — в системе можно определять любые правила. Например, закрыть задачу, если закрыты все баги и все подзадачи. Правила в разных командах очень специфичны.
  • Events — использование событий для для уведомлений внешних и внутренних систем, каналов коммуникаций (емейл, SMS) и так далее.
  • Actions — в системе можно определять действия над сущностями: объединение, изменение типа, удаление и тп.
  • Workflow — гибкая конфигурация состояний любых сущностей.
  • Permissions — настройка прав доступа к любым сущностям и полям.

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

Создание такой системы крайне непростая задача, на которую не жалко потратить 10 лет жизни. Мне она кажется возможной и практически реализуемой.

В итоге у нас будет сложное ядро, но простые и быстрые решения.

Выводы

Для начала, занимательная объединяющая таблица по всем областям, которые мы рассмотрели. Слева у нас конкретные вещи, а справа — довольно абстрактные.

Сразу можно отметить, что колонка слева понятна любому школьнику. Центральная колонка понятна школьнику одаренному. А вот с правой колонкой все гораздо сложнее, наслаждаться ей могут не более 5–10% населения Земли.


Настала пора синтеза!

Сложность

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

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

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

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

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

B2C решения должны работать с нижними уровнями абстракции, потому что большинство людей просто не будет врубаться во что-то сложнее Instagram. B2B решения чуть более свободны в этом плане, но все же не нужно надеяться, что бизнес-пользователи все сплошь гении или находятся в top 20%.

Мощность

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

Зависимость свойств программных систем от уровня абстракции.

Если применять все это к разработке ПО, то абстрактные системы делать сложнее и дольше. Выбор правильного уровня абстракции для построения системы — критически важная задача. Высокий уровень — медленно, сложно и мощно, низкий уровень — быстро, просто и конкретно. Заметим, что почти практически все решения в custom software development работают на нижнем уровне.

Создание полезных и глубоких абстрактных понятий — искусство, доступное немногим.

Эволюция

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

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

Изменение восприятия абстрактных концепций со временем.

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

Изменение

Вот у меня есть еще один открытый тезис, который любопытно обсудить.

Абстрактные системы проще модифицировать и развивать.

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

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

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

Итог

Будущее за более абстрактными системами. Вся история говорит нам об этом.

P.S. Спасибо Андрею Хмылову за ценные рекомендации по разделу “функциональное программирование”. Ну фактически это он его и переписал, потому что мои примеры были слишком абстрактными.

Enterprise software vendors have no taste

Alex Votsmush has it.

Enterprise software vendors have no taste

Every time I research some domain related to enterprise and check various products in it, my eyes bleed. I just can’t embrace unsightly screenshots on product pages and ugly tours. Why is that? We have so many beautifully designed products, web sites and services on the mass market, but if the product is designed for other companies (especially large) it is almost inevitably looks terrible.

Sprint board in Polarion software. Italic, strike through, bullet points — total mess.

My current theory is that enterprise software vendors have no taste. CEO, VP of development, Product managers that focus on enterprise market — all of them have no fucking taste. There is no taste in companies DNA, nobody cares about design and aesthetic. Profits, revenue, sales and new features — yes! Beautiful design — no.

I have a very simple criteria to check how good the solution is: If I can demo it to the potential customer and be proud about what I show — it is good. If I can’t imagine demoing it — it sucks.

Sometimes initial look is not so bad, but when you start to run real cases you feel a constant pain caused by delays, missed UI patterns, unintuitive ways to do things and lack of hints… stop, it is more about user experience and we are talking about taste.

Rational Team Concert has home icon in top corner. Why?

Why so few enterprise vendors praise good design and spend time on polishing it? Is it so hard to add correct spaces between form element and labels? No, it is not, but nobody cares.

DevSuite has classical UI with overwhelming amount of details, gradients, embarrassing lack of spaces in a form and total lack of taste.

You may argue that it is economically unwise to spend much time on design, train people to differentiate good design from bad design, train yourself to spot shit as an executive. I can agree with this argument for B2B markets, but I personally can’t create products that look like they were designed without passion. Every product should be created with passion and it spreads to every little detail in the product. Period.

Rally Software not the worst example, but still many small details uncover the truth — lack of taste.

Is there any opportunity to companies that value good design on B2B markets? Several years ago I’d said no, but with all latest trends I think design is becoming more and more important. Mobile surge and great B2C products slowly change people expectations from all software products. When you use an iPhone or even a Galaxy S and then switch to Salesforce on your laptop—you feel the difference.

Famous Salesforce is not an exception. Totally successful business has outdated and tasteless product. At least I know they are improving in other areas.

This feeling accumulates with time. You start to notice small glitches and overall clutterness. Eventually, when you’ll see a good looking B2B product you’ll want to give it a chance.

Another argument I hear often is about utility. It is easy to burry utility under the beautiful picture. But good design has both:

The most elegant solution will yield a design that is gracefully tempered with restraint and precision — both useful and beautiful.

I hope enterprise vendors that focus on design and put significant effort into it will win eventually. Unfortunately, this strategy doesn’t bring significant additional revenue right now. But money is not everything in this world. I value passion, craftsmanship and quality more.

P.S. Hacker News thread https://news.ycombinator.com/item?id=9190195

Create

I’m 35 and only recently I truly nailed what drives my life — it’s “creation”. When I create something meaningful I feel really great. My creations are not tangible in most cases, like poems, songs, design solutions, new product features, articles, books and blog posts. In general I think creation of anything that lasts is a good way to spend your life.

http://mashable.com/2013/02/13/amazing-minecraft-creations/

Deep immersion into a working process turns off everything around. You suddenly ignore all external sounds, you don’t feel how minutes and even hours passing by, you don’t notice poor lighting and reject timid body requests. Then you wake up and check the result. Maybe it’s not perfect, maybe it’s just a start of something significant, maybe you will throw it away in several days after critical examination, but nevertheless you have a sense of achievement. You’ve just completed a thing that may be a part of your legacy.

Can you write? Can you invent a software that changes people lives? Can you build a house? You never know till you try. Your life passion is not “programmed”, it should be “discovered” via experiments and achievements. Moreover, public recognition in many cases is not a good indicator of your achievements. Your personal feelings do matter. When you achieve something and enjoy the process, it is a good signal that your experiment was successful and you should keep going. When you spent quite a lot of time on, let’s say, quantum physics with no clear results and theoretical constructions bored you to death, maybe you should try something else (or maybe you just have a depression, but it’s curable).

Any startup and any ambitious mature company should hire as many creators as it can. These people are enthusiastic, active and relentless. They are the engine of a company. They keep learning, experiment a lot and failures are just a part of their working process. Every team desperately needs at least one creator, otherwise it will be mediocre at best.

How to discover a creator? It is relatively easy to do. Usually they can have something from the list below:

  • Side products (frameworks, apps, whatever)
  • Blog, articles, books, whatever
  • Hobbies related to creation (painting, robots construction, fancywork)
  • They usually like LEGO and Minecraft (this option alone is not 100% proof that a person is a creator)

Consumers are all around. We all consume books, movies, TV shows, cars, food, etc. How many of us transform all these consumed information, experiences and skills into something meaningful? Surprisingly, creators are quite rare. It’s incredibly hard to find one and align his goals with company goals. Sometimes they are not polite and hate everything that blocks or slow downs acts of creation. They will not tolerate political games and bureaucracy. Most attempts to cheat them and exploit them will fail in the long run.

We need to build companies that promote honesty, creation and learning. I’m here to create. You?

Бег и разработка продуктов

Что нам могут дать аналогии

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

Недавно я прочитал одну тяжелую книгу — Surfaces and Essences. Дуглас Хофштадтер оттянулся по полной и сделал так, что после первых 50 страниц читать книгу просто не хочется. Я буквально заставлял себя осваивать пару десятков страниц в неделю, пока не дошел до последней трети книги — и там все стало очень круто.

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

Хорошая книга. Стоит прочитать. Source: http://birdschmidt.blogspot.com/2013/10/more-dandy-looking-books-in-mail.html

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

Для начала посмотрим, какие свойства есть у бега и какие аналогии можно провести с разработкой. У меня получилась такая табличка:

Медиум не позволяет вставлять таблицы, приходится выкручиваться…

Может, у вас появились вопросы, вроде “что этот странный чувак имеет ввиду под направлением разработки?” и “какие нахрен травмы у программистов?” Это очень хорошо, значит интрига присутствует и вы хотя бы пробежите глазами картинки.

Какая цель бега вообще? Я бы сказал, такая:

Бежать как можно быстрее как можно дальше без травм

Бегун на стометровке рассмеется мне в лицо, потому что бежать дальше ему не надо. Но любой бегун на средние и дальние дистанции одобрительно кивнет. Если вы начинали бегать, то знаете, как это бывает. Сначала вы пробегаете 2 километра с темпом 6:50. Со временем 5 километров с темпом 5:30. Потом 10 с темпом 4:50 и наконец перестаете бегать из-за проблем с коленом/ахилом/пяткой/голеностопом. Каждый раз, выходя на пробежку, вы хотите пробежать чуть дальше и чуть быстрее, чем в прошлый раз.

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

Разрабатывать как можно быстрее как можно дальше без травм

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

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

Направление

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

Однако, это довольно часто случается в разработке продуктов. В мире созданы десятки тысяч продуктов, которые оказались никому не нужными. Практически в каждом продукте есть фичи, которыми почти никто не пользуется. Возможно, они имеют внутри великолепный код и блестящую архитектуру, но nobody cares. Разработчики этих продуктов и фич бежали не в ту сторону.

Выбор верного направления в разработке продуктов — невероятно сложная штука. Ошибаются все. Интуиция не работает. Коллективный разум выдает удивительно неверные решения. Формальную модель построить сложно. Даже опыт помогает далеко не всегда. Если мы побежали не в ту сторону, становится совершенно неважно, с какой скоростью мы бежим. Ну разве что мы окажется в неправильном месте быстрее. И там нас никто не ждет.

Что можно сделать, чтобы выбирать правильное направление? Делать быстрые прототипы и проверять концепции. Строить простые модели и учитывать паттерны поведения пользователей. Обложить систему статистикой и научиться понимать, какие фичи используют, а какие не очень. Решений много и все они несовершенны. Крайне важно понять, что выбор направления — это самая важная штука в разработке. Если направление верное — мы рано или поздно будем наслаждаться солнышком и морем. Если нет — нас ждут дождливые ночи в жопе мира.

Дистанция

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

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

Спринтеры

  • Делают очень быстро, не думают о поддержке
  • Пишут крутой непонятный другим код
  • Прыгают с проекта на проект

Стайеры

  • Делают медленно, сопровождение важно
  • Пишут простой и понятный код
  • Долго работают на одном проекте

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

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

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

Реальные бегуны.

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

Наша цель — исключить длинные релизы.

Живая легенда разработки продуктов.

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


Скорость

Люди бегают довольно медленно. Выдающиеся личности могут бежать со скоростью 38 км/ч, но очень недолго. Другие выдающиеся личности могут бежать со скоростью 20 км/ч два часа. А некоторые могут бежать сутки со скоростью 12 км/ч. Вообще люди отличаются необычайной выносливостью, и вполне могут загнать антилопу за несколько часов непрерывного преследования.

Source: http://en.wikipedia.org/wiki/Running

На длинной дистанции мы не можем бежать очень быстро. Что будет, если пытаться это делать?


И вот начинается забег на пять километров. Знаменитый спринтер Григорий Колодкин возглавляет забег и бежит в гордом одиночестве. Вот он преодолевает первые круги дистанции с невероятным отрывом. Он наращивает темп и ему кажется, что финиш вот-вот наступит. Григорий с удивлением выясняет, что до финиша еще 4 километра, а бежать дальше организм отказыватся. У организма есть существенные аргументы, он вообще удивлен, как смог пробежать целый километр в таком темпе. Григорий переходит на бег трусцой, восстанавливая дыхание и мышцы. Пелотон настигает Григория на третьем километре дистанции, последний бегун пелотона дружески хлопает Григория по плечу и легко устремляется вперед.

А теперь давайте возьмем команду программистов. Она спокойно, в своем темпе работает над релизом. Тут приходит менеджер проекта и говорит “ребята, надо быстрее! У нас важный дедлайн!” Команда говорит “надо, значит надо” и прибавляет темп. Через пару месяцев оказывается, что к дедлайну не успеть. Менеджер проекта произносит яркую мотивационную речь, после чего команда работает по воскресеньям, ночует в офисе, кушает пиццу, запивая ее Burn’ом, и колбасит код с невероятной скоростью. Но в один прекрасный момент наступает fuck it point. Менеджеру очень повезет, если fuck it point наступит после дедлайна. Достигнув этой знаменательной точки, команда работает в предельно низком темпе, с отвращением глядит на код, с омерзением исправляет новые баги и старается сделать все, чтобы не работать.

Чтобы бежать быстрее долго — нужна выносливость

Возникает вопрос, как в беге тренируется выносливость? Один из хороших подходов — это интервальная тренировка.

Интервальная тренировка

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


Можно ли применить что-то похожее в разработке продуктов? Конечно же да. И это мы назовем интервальной разработкой.

Интервальная разработка.

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

Фаза 1. Обычный темп (2 месяца)

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

Фаза 2. Ускоренный темп (1 месяц)

Цель этого режима — фокус.

  • Команда убирает все собрания, которые не посвящены непосредственно фиче. Ежедневные стендап собрания, статус репорты и прочие собрания. Вы сможете прожить без них месяц. Точно сможете.
  • На время работы выключатся все мессенджеры: Skype, ICQ (да ладно?), IRC и так далее. Если есть удаленные работники, канал оставляется только с ними. Можно выделять время на проверку почты и сообщений, но все равно нужно все минимизировать.
  • Если людей из команды привыкли отвлекать представители других команд — вежливо попросите их подождать месяц. Пусть найдут себе других. Повесьте на дверь табличку “не беспокоить” и не отзывайтесь на мольбы о помощи.
  • Попробуйте парное программирование. Когда сидишь в паре с другим человеком, не особенно овлечешься. Фокус будет держаться сам по себе.
  • Никаких овертаймов!

Можете пробовать все, что угодно, но главная цель — сконцентрированно работать над фичей. Долой многозадачность! Долой все устоявшиеся рутинные дела! Через пару недель вас будет распирать от достигнутого. Чертовски приятно уходить домой, ощущая хороший прогресс и объем сделанных задач.

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

Фаза 3. Неделя релаксации (1 неделя)

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

Отдохнули? А теперь самое время взять новую фичу.

Такой режим работы имеет несколько теоретических преимуществ:

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

Фартлек

Кроме ритмичной интервальной тренировки есть еще и неструктурированная. Фартлек придумали в Швеции для тренировки бегунов по пересеченной местности. Все очень просто:


В простейшей форме можно выделить 3 фазы: разогрев (бег в очень медленном темпе), быстрый бег и скоростной бег.

А что будет, если это применить к разработке?

Фартлек разработка.

Фазы немножно отличаются от тех, что были в простой интервальной тренировке.

Фаза 1. Медленная (1 месяц)

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

Фаза 2. Умеренная (2 недели)

Начинаем разработку в обычном темпе, разве что попытавшись немного притушить второстепенные активности.

Фаза 3. Ускоренная (2 недели)

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

Дальше мы пару раз чередуем фазы 2 и 3. И на выходе получаем готовую фичу.

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

Травмы

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

У разработчиков тоже есть свои травмы. Логическая цепочка будет такая:

Баги и малоподвижный образ жизни > Эмоциональное выгорание > Печеньки и кофе > #безысходность.

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

Что же делать? “Ага, раньше же все бегали босиком. Почему бы нам не вернуться к истокам?” — подумали люди. И появилась техника бега босиком.

Source: http://www.healthynomics.com/2010/02/running-barefoot-and-barefoot-alternatives/

Кажется, решаются многие проблемы. Шаг становится короче и нет такой нагрузки на ноги. Босиком приземляться на пятку очень больно, так что приходится приземляться на носок. Кажется, всё прекрасно! Но не тут-то было. Оказалось, что бег босиком увеличивает вероятность травм ахилла, голени и плюсневых костей стопы. Не говоря уже о мозолях.

Избавившись от одних проблемы, мы приобрели другие проблемы.

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

Забавные кроссовки.

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

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

Ничего не напоминает? Давайте проведем аналогию с разработкой.


В самом деле, почти все разработчики не особенно любят тестировать. “На это есть тестировщики, чего нам тут возиться?” — резонно заявляют они. Это все прекрасно, но часто ведет к наплевательскому отношению. “Ну вот вроде все готово, сейчас отдадим тестерам, пусть поищут баги. Позитивные сценарии самим проходить некомильфо. Я лучше пойду почитаю про скалу”. В результате фича прыгает от тестировщика к разработчику несколько раз, пока все баги не поправят. Это увеличивает время разработки и снижает скорость (кстати, бег на носок на 5% быстрее, чем бег на пятку).

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

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

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

Резюме

Давайте подведем итог. Мы провели четыре аналогии между бегом и разработкой.

  1. Направление — выбор правильных фич
  2. Сокращение дистанции — мелкие релизы и фичи
  3. Увеличение скорости и выносливости — интервальная разработка
  4. Снижение травматичности — выбор правильных практик

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

P.S. Меня можно добавить в друзья в фейсбуке, следить за мной в твиттере. И я буду рад любому фидбеку по нашему продукту управления проектами.

P.P.S. За этот абзац ^ выше пост забанили на хабре.

Visual Management Software

Targetprocess 

Existing project management tools have several serious flaws. They hide data inside and give the perception that you are in control. You are not. You don’t see the important things and have to dig through endless lists and reports in order to squeeze out the information you need. When you finally find something, it is not easy to change data you need. You have to navigate away, and visit several screens to achieve what you need. What a pain.

The real problem is that all existing project management tools are bad at information visualization.

Information Visualization

Many think that information visualization consists of fancy infographics, dashboards, and reports. That is far from true. There are many definitions, but I like this one:

Information visualization utilizes computer graphics and interaction to assist humans in solving problems. [Purchase et al., 2008, p. 58]

In a nutshell, you should be able to extract the data you want, present it any way you want, and manipulate it right away any way you want.

Problem #1. Find

It is quite easy to add data into software: projects, tasks, people, plans. It is not as easy to get this data back. Quite often you have limited filtering options and can’t narrow down lists, for example, of user stories in order to see just user stories you want. So you have to dig through the list, change pages to find a single story, do something with it, and repeat.

What if you can extract anything without limitations? Zoom and focus on things? Find exactly what you need?

Problem #2. See

Even if you can extract something, you can’t always see information in a way you want. Most tools rely on lists heavily and provide little options to see things better. Lists, some predefined boards, some predefined reports — that is all.

What if you can switch between different representations in a single click? What if you can see information in a one dimensional list, a two dimensional board, or a timeline with a single click?

Problem #3. Change

Even if some tools do provide visualizations, they are static. You can see a report, but can’t do anything with the data. You can see a timeline, but rarely can change it right away.

What if you could see something important and change data right there?

If you take any project management tool, you’ll see that it doesn’t follow information visualization principles. Everything is fragmented. Lists are here, boards are there, timelines are rare and often are not interactive. There are many limitations with finding exact data you need. There are even more limitations with changing data.

Targetprocess 3 was built to solve these problems in the roots in project management domain.

Targetprocess 3

Targetprocess 3 is a tool that has information visualization principles in its core. It removes many of the limitations that other tools have and gives you the freedom to handle data the way you want.


Solution #1. Find

In Targetprocess 3 you can find anything using powerful filters. There is almost zero limitations and you can create very clever filters. When you have no limitations, you can extract exactly what you want and narrow down the data to see.

Solution #2. See

In Targetprocess 3 you can select data and quickly switch between various views in a single click: Boards represent two-dimensional views, Lists show hierarchies and Timelines show progress of things.

Boards

You can create any board in a minute: Kanban Board, Task Board, Work by Person, Roadmap and many, many others. The Board UI handles huge data easily via collapsing, focusing and zooming.

Ben Shneiderman stated a Visualization mantra:

Overview first, zoom and filter, then details-on-demand.

Views in Targetprocess take this mantra seriously. You can see the whole picture on board, zoom and filter when you want, and dig into details when you need.

Projects by Teams board in Targetprocess

Lists

Sometimes you need to work with hierarchical data. For example, product backlog. Lists in Targetprocess 3 are really good at it. You can use filters and flexible settings to see exactly what you need on all levels, update anything in a snap.

Hierarchical backlog view

Timelines

Most tools can’t give you a sense of Time. Any data in Targetprocess can be seen on a Timeline. Progress tracking on all levels is a breeze. You can track releases and iterations, see people’s workload, spot long tasks and delays, discover unexpected patterns in your development flow. Moreover, you can create projects portfolios, product roadmaps, plan releases and iterations. Visually.

Features Roadmap

Solution #3. Change

When you see something, you often want to change that. Targetprocess 3 helps you add entities quickly, select any entities you want and manipulate them via batch drag and drop. Lists provide beautiful experience in adding and editing data. Timelines enable visual manipulations to create roadmaps, plan releases and iterations.

In fact, Targetprocess 3 is a domain-specific visualization software. It focuses on project management domain and provides not static reports, but interactive visualizations. And that makes a big difference. Now information is at your fingertips and you can really find it, see it and change it on the spot.

Targetprocess is free for teams of 5 people. Go see for yourself.

Краткая история продукта Targetprocess

http://www.targetprocess.com

Рассказчик — Михаил Дубаков

Простой рассказ о том, как создавалась система управления проектами Targetprocess с 2004 по 2014 год.

2004

Все началось в 2004 году. В это время про аджайл в Беларуси слышали единицы, а применял почти никто. Итеративная разработка? Парное программирование? TDD? Однако в одной компании был внутренний проект, на котором я и Женя попробовали экстремальное программирование. Нам оно понравилось. А руководству компании — не очень. Как совершенно побочный эффект, нам нужен был инструмент для управления таким проектом. На тот момент было несколько ужасных бесплатных инструментов, и пару жутко дорогих. “А почему бы не сделать свой инструмент управления проектами в стиле XP?” — наверное, похожие вопросы задавали себе все программисты, но этот конкретный вопрос превратился в идею продукта Targetprocess (рабочее название было SWIPE — Sprint Web Integrated Process Environment).

Идея варилась с мая по июнь 2004 и превратилась в 20 страничный документ. Работа над продуктом стартовала в июле и велась исключительно по вечерам и выходным дням.

Мощная рабочая станция с открытой Visual Studio.

Над первой версией работал я практически в одиночку, остальные ребята по разным причинам не могли участвовать. Продукт под названием TargetProcess:Planning 1.0 увидел свет 14 ноября 2004.

Первый веб сайт

TargetProcess:Planning был бесплатный и реализовывал минимум функционала. Сейчас бы сказали, что я пользовался Lean методологией и выпустил Minimal Viable Product. Тогда таких понятий не было, а был просто здравый смысл. Работая по вечерам и выходным довольно сложно в одиночку выпустить что-то с офигенным функционалом, так что минимальный продукт был необходим. Можно было планировать итерации, строить burn down и видеть свой список задач.

Планирование итераций в первой версии системы

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

2005

Постепенно к разработке подключились Олег, Женя и Вадим. Первая платная версия называлась TargetProcess:Suite 1.1, а выпущена она была 20 января 2005 года. Самой крутой фишкой в этой версии являлся интегрированный баг-трекер. В то время вообще не было никаких agile инструментов, где можно было управлять user stories и багами одновременно.

Его можно было купить всего за $799 без всяких ограничений по пользователям. Само собой, о SaaS модели тогда мало кто слышал, поэтому софт надо было скачать и поставить на свой сервер.

Функционал рос и развивался. В системе появился интегрированный тайм-трекинг. В апреле выкатили версию TargetProcess:Enterprise с полным сорс-кодом, кастом-девелопментом и “премиум-суппортом”.

Управление тест кейсами. Первый ajax-функционал в системе!

Продукт стал получать хорошие отзывы

“I would like to say that TargetProcess has been working out great for our development process. It has been very easy for our development team to adopt and fit into our process. It is really efficient software. Great work!”

Больше сказать особо нечего. Разве что были введены лицензии по пользователям и увеличена цена. Продукт набирал обороты.

2006

К этому времени начали сказываться технические ограничения системы. В свое время я неудачно выбрал O/R mapper, а NHibernate уже более-менее окреп и позволял делать интересные штуки. Код, написанный мной, был не самым хорошим в мире (скорее всего, он был просто плохим). Так что мы решили полностью переписать систему с нуля. Переписывание началось в январе 2006 года.

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

Первым офисом была моя квартира. Женя приезжал с ноутбуком и мы программировали в парах.

Спокойное начало очередной дискуссии

Обсуждения функционала и UI были очень горячими. Моя жена иногда думала, что скоро мы начнем бить друг друга в лицо. Но до этого ни разу не доходило. Вообще за 10 лет так ни разу никто никого и не ударил.

Олег лучше всех знал .NET, чем неоднократно пользовался.

В основом архитектуру TargetProcess 2.0 придумал он. Там была генерация кода, NHibernate и всякие модные (на то время) штучки.

Офис часто использовался не по назначению

Попутно была выпущена последняя версия TargetProcess первого поколения (1.7). И еще мы неожиданно выиграли Jolt Productivity Award (типа второе место) в категории Quality Project Management. Пришлось просить одного из наших клиентов слетать за наградой на церемонию награждения — это был известный многим Bruce Onder.

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

Первый реальный офис

В ней и закипела работа над Targetprocess 2.0. У нас появился новый логотип

Первый дизайнерский лототип. Как оказалось потом, он очень похож на логотип Colgate-Palmolive, но мы об этом еще не знали.

Заодно начал появляться и новый дизайн системы. Его делал Дима Болашев.

Самый первый вариант дизайна Targetprocess 2

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

И вот 10 октября 2006 года вышел первый превью-релиз версии 2.0. После этого релизы стали вылетать как горячие пирожки. Каждый месяц в системе появлялись новые крутые фичи. UX фаза состояла из обсуждения, рисования скетчей и создания вайрфреймов в Visio. И вперед в разработку.

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

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

Планирование итераций

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

TP.Tray v.1 — утилита для быстрого сабмита багов в Targetprocess, написанная Вадимом. Была всеми любима.

Уже тогда в систему были заложены процессы, так что можно было делать разные проекты по разным процессам. И это сделало TargetProcess самым кастомизируемым инструментом на рынке.

Первый веб-сайт с версией 2.0. Дизайн by Michael Dubakov ☺

В компании работало 4 человека.

2007

В этом году продукт двигался вперед с отличной скоростью, наращивая функционал. Мы познакомились с Андреем, и он стал продвигать продукт в США. Вклад Андрея в развитие компании огромен. В Орландо мы впервые презентовали продукт на конференции.

Андрей готовится к демонстрации продукта

В продукт добавлялись довольно инновационные по тем временам фичи. Мы первые сделали интеграцию с Subversion и одновременно с V1 выпустили Help Desk Portal. Появилась хорошая интеграция с емейлами и терминология.

За 7 лет дизайн Help Desk Portal к сожалению практически не изменился… Зато его написали за месяц.

В июне 2007 года был запущен TargetProcess On-Demand с ценой $25 за пользователя в месяц. Как видите, цена лицензии не менялась уже 7 лет.

Команда стала расти. Кроме Андрея к нам присоединились 2 отличных разработчика — Андрей и Саша, первый тестировщик — Тоня, а также Катя, которая писала тексты. Никто из них уже не работает в компании.

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

Офис стал больше. Никаких бесплатных обедов не было. Был магазин с булочками и столовая с котлетами. По праздникам еду привозили из макдональдс. Тогда все радовались.

Женя весел


Вообще год был очень драйвовый. Мы выпустили 6 больших релизов.

2008

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

Попытка использовать Task Board

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

Посиделки по поводу выпуска нового релиза

Сайт вновь изменился. В лучшую сторону. Этот дизайн и сейчас смотрится вполне нормально.

Дизайн by Dmitry Bolashev

В этом году мы занимались интеграциями с JIRA, Selenium и пр. Улучшали Getting Started. Вообще скорость разработки существенно замедлилась, по сравнению с прошлым годом.

Обсуждение легкого старта в Targetprocess v.2

Мы работали по итерациям, планировали релизы, оценивали юзер стори в поинтах через planning poker (да!). Короче, у нас был полноценный Scrum с элементами XP.

Продукт выиграл еще одну Jolt Productivity Award. А на новый год на сайте висела такая картинка

Новый год 2008

К концу года в компании было 16 человек. Из них 2 — в США.

2009

Стартап превратился в бизнес. Захотелось выпустить новую версию продукта 3.0. Мы уже вовсю обсуждали новый Help Desk Portal (хаха!), новую навигацию и все остальное.

Обсуждение новой навигации

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

Список юзер сторей. Можно выделить сложное многоуровневое меню и проработку деталей. Никаких концептуальных изменений нет.

Как видите, главный фокус был на самом дизайне, а не на контенте. Все выглядит довольно красиво, но вряд ли эффективно. Это называется Lipstick on a pig. Сейчас бы мы такой дизайн не выпустили.

А вот новые Views выглядели довольно хорошо.

К счастью, концепция так и осталась концепцией. Конференция Agile 2009 изменила все. На ней я услышал доклад Джареда Спула о UX. Тема в то время была довольно новая. Этот доклад перевернул во мне все представление о том, как надо делать софт. Ну вот бывает так, сидишь, слушаешь и перед тобой открывается вся бездна твоей некомпетентности и ты четко понимаешь, сколько тяжелых проблем накопилось в продукте, насколько он некрасивый и неудобный. Этот же доклад год спустя показался мне довольно средним. Так что никогда не угадаешь, что произведет на тебя впечатление и повернет компанию в другую сторону. Я даже слайды фоткал, чего никогда раньше не делал.

После этого, прочитав несколько книг и множество статей, я подготовил презентацию по UX для всей компании. Ее и сегодня можно найти и посмотреть.

На Agile Conference 2009 у нас был стенд и мы конкурировали с VersionOne и Rally.

Андрей показывает Targetprocess


Вернувшись, мы решили найти дизайнера и заняться UX по взрослому. Нашим первым дизайнером стал всеми любимый Саша Цаюн.

Мы вновь сменили офис. На этот раз переехали поближе к радиаторному заводу на Орловскую.

Все, конечно, заметили хреновые стулья и столы. Вот так у нас было в 2009 году.

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


В этом году мы одними из первых сделали поддержку Kanban. Все было замешано на ExtJS и работало довольно медленно на больших данных. В системе появилась возможно трекать Cycle Time, строить CFD диаграмму (очень медленно работала из-за неправильно выбранного подхода) и работать с багами и юзер сторями на канбан доске.

Самая первая Канбан доска. Выглядит все угрожающе.

Да и сами мы со Scrum перешли на Kanban. Хотелось выпускать каждую фичу отдельно, а итерации Scrum этому мешали. Оказалось, что Subversion очень плохо работает с бранчами, поэтому перешли на Git. Переход был тяжелый и сопровождался коммитами с форсом. Но ничего, потом почти все наладилось.

У нас появился довольно большой и настырный клиент, который просил много всяких фич, иначе грозился не купить систему. Мы согласились их сделать, о чем потом многократно жалели. Больше мы не делаем таких ошибок. Если система не подходит — мы не добавляем десяток фич, а просто рекомендуем ее не покупать.

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

Иногда собрания были очень веселыми

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

Постановка проблемы многих команд

План был такой. Сначала делаем поддержку многих проектов (в то время можно было выбирать в контексте только 1 проект), а потом делаем поддержку многих команд.

И родмэп под это дело сделали:

  • Январь 2010 — новая навигация и поддержка многих проектов
  • Июнь 2010 — новый вьюшки, новые листы и поддержка многих команд
  • Декабрь 2010 — Машапы, REST API, новый модуль емейлов, новый Help Desk Portal (!)

Это все мы собирались назвать TargetProcess v.3 (опять! Я не шучу!) Сразу скажу, что новую навигацию мы выпустили в марте 2010, поддержку многих проектов в середине лета 2010, а все остальное — гораздо позже (кроме Help Desk Portal, само собой).

Что интересно, по большому счету мы шли по этому родмэпу целых два года, но отвлеклись на Teams Board (об этом чуть позже).

Отдел QA сильно укрепился с приходом Нади Булыни и Оли Костюкевич (вы ее знаете под фамилией Ихелис). Андрей Васьковский и Сергей Трухтанов пополнили ряды разработчиков.

Мы впервые культурно встретили новый год в небольшом коттедже.

Компания выросла не особенно сильно, всего на 5 человек. Так что нас стало 21. В этом же году от нас ушел первый человек — отличный разработчик Саша Радзиванович. Он занялся своим проектом.

2010

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

Начался год как обычно. Мы начали делать настоящий UX. Придумали персон и описали их юз кейсы. Люди стали активно участвовать в UX процессах.

Персона автоматического тестировщика.

Первой реальной ласточкой нового UX была верхняя навигация. Мы придумали несколько решений, сделали два прототипа, провели юзабилити-тесты и выбрали решение, которое и сейчас есть в v.2.

Много усилий было потрачено на переделку ToDo. Дальше UX ничего не пошло, но было интересно. Мы выписывали кейсы по персонам, делали разные прототипы. Для прототипов пробовали много всего: PDF, javascript, Flex.

Прототип ToDo страницы. Развили идею карточек.

Пробовали даже делать бумажные прототипы.

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

Мы начали больше ездить по конференциям. Самая первая была в Кракове.

Надя в Кракове.


Весной мы вновь сменили офис. На сей раз это был офис на Шаранговича, многие из вас его помнят. В офисе было целых 340 квадратных метров! Казалось, что мы в нем очень надолго и пространства просто море. “Очень надолго” превратилось в 2 года.

Саша и Алла обсуждают, как лучше поставить мебель в комнате.

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

Картинг 2010.

А осенью началось веселье — состоялся первый HEAD Retreat. С тех пор они проводятся каждый год и существенно влияют на будущее компании.

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

Мы сделали презентацию новой концепции всей команде.

Пирамидка taucraft

Оглядываясь назад можно сказать, что это в целом удалось. Мы — офигенная команда. Не все получается на 100% хорошо, но фундаментальные принципы, мне кажется, у нас есть. У компании появился стержень, свой стиль и свое будущее.

С несколькими людьми пришлось расстаться. В тот момент компанию покинуло 4 человека.

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

Расстановка столов в разгаре

Компания серьезно занялась обучением. Появились внутренние конференции, люди стали делать различные воркшопы и доклады.

Вот программа нашей первой внутренней конференции

У каждого появилась возможность посетить хорошую конференцию за рубежом. С десяток человек поехали на QCon в Лондоне. Несколько человек посетили OOP в Германии. Мы были на UX конференциях в Лондоне и Лиссабоне.

Появились так называемые Friday Shows. Мы смотрели какое-то интересное видео и устраивали открытое обсуждение. Некоторые дискуссии были очень интересными. Вообще хороший был формат. Можно вернуть.

Анонс Friday Show

Изменились подходы к хайрингу. Отбор стал гораздо более тщательным и большинство из вас с ним столкнулось ☺ Первопроходцем был Саша Фомин, которому пришлось за часок придумать систему плагинов. А также Алла Погоцкая, которая полдня программировала в паре (было и такое…)

С точки зрения продукта мы выпустили поддержку многих проектов в первой половине года, а всю вторую половину посвятили двум вещам: новым плагинам и Teams Board. Фактически, Teams Board был прототипом наших крутых бордов в Targetprocess 3. Тогда мы разбились на две или три UX команды, которые придумывали новую концепцию пользовательского интерфейса. Лучшая концепция была у команды Олега и презентацию можно посмотреть тут.

Очень ранний прототип бордов


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

Накопилось много багов, и мы попробовали ввести специальные дни, когда вся команда занимается багфиксингом (включая меня). Так появились субботники. Обычно за субботник исправлялось 20-30 багов. Конечно, к концу дня билд выкатить не удавалось (хотя пытались). Но в целом инициатива была неплохая.

Постепенно улучшались процессы. Появились внятные функциональные тесты.

Вот так выглядел прадедушка нашего билд борда.

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

Также, усилиями Антона Марченко, был сформирован отдел поддержки, он назывался Customer Care Team. Мы первыми из всех конкурентов стали оказывать поддержку по чату. Это очень тяжелая работа, принимать все проблемы и уметь транслировать эту боль дальше, в команды разработки.

С клиентами Антон был предельно вежлив, а вот разработчикам приходилось несладко

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

Ничто не остается без ответа. Top-notch!

Новый год прошел крайне весело. Мы сняли большой коттедж и даром время не теряли: пейнтбол, баня, фейерверк и все дела.

Команда “синих” готова к выходу на позиции

За 2010 год компания не выросла численно, в ней было 22 человека. Но заложила фундамент для качественного рывка вперед. Что и произошло совсем скоро.

2011

После фундаментальных изменений прошлого года, компания стала постепенно входить в рабочий ритм. Мы запустили первую хайринговую компанию, сделав инфографику на девбае. Они была встречена на ура. И даже Андрей Щёткин прислал резюме.

Наш рабочий процесс в 2010 году

На кухне появилась визуализация всех фич, которая ярко указала на грустное количество выпускаемых релизов.

Потом там появилась еще линия Fuck ups и вскоре на ней было довольно много карточек. Визуализация факапов была отличной идеей.

Roadmap фич на кухне. Ранний вариант.

Доделали и выпустили в люди Teams Board. Реакция на него была положительной, людям нравилось.

– One of the best features are the user rows. This is very helpful at dispatching work.

– Very intuitive and interactive

– Far better than the Kanban-Board

Teams Board поддерживал схлопывание рядов, группировку колонок In Progress, переключение размера карточек и драг энд дроп.

После выпуска Teams Board мы занялись переделыванием Views. Собрания были интенсивными.

Обсуждение архитектуры новых Views

Почему мы не начали делать реальный UI для v.3? Первая причина была собрать больше фидбека от Teams Board и сделать паузу. Фидбека собрали много и очень полезного. А вот пауза затянулась. Вьюшки переделывали год.

Команда JS тролит команду Backend

За это время, конечно, наступили на много граблей, которые помогли сделать новые борды лучше. Но могли бы и раньше начать, чего уж там. Вторая причина — обкатать JS получше. Ну так себе причина, прямо скажем.

UX процессы стали более серьезными. Мы пару раз пробовали Design Studio — довольно интересная методология придумывания решений.

Design Studio. Саша что-то увлеченно рассматривает на листике


Пробовали внедрить сбор идей на общей доске. Идея особо не прижилась.

Пожелания и идеи по новому веб-сайту

Билд борд стал гораздо более функциональным и весело светился красным на большом телевизоре.

Телевизор на кухне не пропадал даром

Летом все поехали на пикник с катанием на лошадях и без ночевки. С тех пор выезды на природу летом стали традицией. Но уже с ночевкой.

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

Тут мы намиксовали идеи 2009 года про поддержку многих команд, идею многомерного борда с зумом, которую проверили в Teams Board, полученные знания о визуализации и DSL язык.

Самый первый прототип v.3

Эту концепцию я показал нескольким клиентам и получил хорошие отзывы. Так что было решено воплотить ее в жизнь.

Сайт сильно не изменился, но стал немного легче.


Команда выросла на 11 человек и нас стало 35.

2012

Год начался с очень крутого события — мы наконец-то официально стартовали разработку настоящего Targetprocess 3. Дизайнеры обсуждали общий вид досок и как все будет работать.

Обсуждение общего лэйаута нового интерфейса

Программисты придумывали slice

“А тут у нас будут монады”

Мы хотели успеть выпустить первую публичную версию летом, чтобы успеть на конференцию Agile 2012 в США. Оказалось, что мы успеваем на конференцию летом, но только в 2014 году.

Roadmap двух команд разработки. На этом плане вы видите, что у нас было разделение на JS и Core команды.

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

Новый сайт с минимумом страниц и максимумом деталей

Прошла наша третья внутренняя конференция. Все ждали анекдоты от Щё, но они почему-то не попали в программу.


В офисе появился Kinect. Сначала он пользовался популярностью, но через пару месяцев все затихло.


Мы чудесно отпраздновали 23 февраля и 8 марта.

Сережа сделал эпичный плакат.


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

В апреле мы знатно троллили хабр своими методами работы.

Невыносимые условия труда наших программистов

Но потом признались, что на самом деле у нас все немного не так.

Невыносимые условия труда 2. Как же можно работать без вискаря?

В мае я написал свою лучшую статью Our Development Process: 50 Months of Evolution.

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

Первый рабочий внутренний релиз Targetprocess 3

Количество людей в офисе на Шаранговича росло довольно быстро. Мы взяли в аренду кусочек второго этажа, но больше нам площадей предложить не могли. Нам понадобился новый офис и осенью мы его нашли. Другие варианты были либо очень дорогие, либо не очень удобные. Так что остановились на Sky Towers.

Пустынный второй этаж с грустными стеклами.

Этот год принес нам самого крупного клиента CAT (800 лицензий и работы по кастомизации Targetprocess). С ними была довольно интересная история. Targetprocess 2 им не особо понравился, и на уходящем флажке Андрей попросил меня показать им Targetprocess 3. Когда они увидели эстимейшн борд (Саша Фомин специально запилил его за пару дней для этого демо) — они просекли всю концепцию и влюбились в нее. На тот момент у нас была довольно сырая бета версия, так что фактически они купили видение, а не готовый продукт.


Была создана специальная команда, которая сделала для CAT много хорошего (и продолжает этим заниматься).

Олег сделал систему сбора статистики использования Targetprocess. Она уже помогает нам принимать решения, а скоро будет помогать еще больше. Мы лучше понимаем, как используется продукт, какие области важны, а какие — не очень.

График отклика Targetprocess 3. Видно, что производительность не особенно хороша пока

На новый год девчонки сделали отличное видео. К концу года в компании работало 48 человек.

2013

Год начался несколькими серьезными изменениями в работе компании. Появились комитеты (борды) и оранжевые пятницы. Кроме того, было решено убрать разделение на back-end / front-end команды, а вместо них образовались Feature Teams.

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

Схема работы комитетов и продуктовых команд

Комитет по продукту любит хороший UX, сразу видно.

Сергей вынужден отличаться

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

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

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

План зеленой башни (в идеале)


Мы старались все делать правильно, вложили в отделку кучу денег, но строители (как обычно) сорвали все сроки и… нам пришлось переехать вот так:

“Практически” завершенный ремонт

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

Daily meeting в уютной башенке

Новый офис был в 3 раза больше старого. И вновь нас охватило чувство, что его мы заполним нескоро. Прошло чуть больше года, а свободных мест уже почти не осталось…

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

Деление на Feature Teams прошло не особенно гладко. Одна команда получилась хорошая, а одна не сложилась. Поэтому после пары месяцев работы две команда были переформированы. Сейчас у нас три Feature Teams, и скоро появится четвертая.

Также летом мы ввели дежурство — Emergency Team. Дежурство прожило полгода, после чего было решено все же сделать стабильную Emergency Team, потому что частые переключения контекста плохо сказывались на фокусе продуктовых команд. В целом ротация работала бы на ура, если бы у нас было хотя бы 6 команд. Тогда каждая команда ротировалась бы раз в 3 месяца, а этого времени в целом достаточно, чтобы выпустить среднюю фичу.

Летом мы отлично оттянулись на базе “Экспедиция”. Водные мотоциклы, веревочки, костер, баня, купание, гитара и палатки.

Девчонки обмениваются впечатлениями

Разработчики начали использовать Git Flow. Прижился.

“А вот тут у вас всегда баги”

К Егору присоединился Оле, и в Берлине у нас появился реальный офис из двух человек. Стив с Оле приехали к нам в гости.

Оле, Стив и Андрей смотрят на Егора

В октябре мы вернули Features Demo — собрание, где команды показывают свой прогресс за последние 3 недели. С ними не все гладко, но без них еще хуже.

Мы определились с позиционированием и продвижением продукта. Наша цель — создать нишу Visual Management систем. По большому счету, все текущие усилия компании направлены именно на это. Timelines, Boards и Lists — только начало. Очень важно добавить в систему графические отчеты и дашборды, только тогда можно будет заявлять о серьезном прорыве.

Торжественное возвращение оранжевых пятниц

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

Мы запустили iOS приложение Targetprocess. Сейчас им пользуется около 600 человек ежемесячно, это примерно 5% от всех пользователей ондеманд.

“Мы уже опять все переделываем”

В сентябре усилиями Оли Ихелис и Егора Свириденко прошёл первый митап в Лондоне, который собрал пару десятков наших клиентов. С тех пор митапы проводятся регулярно.

Лондон. Все разбились на группки и обсуждают проблемы Targetprocess

Новогоднее поздравление в этом году было скромным — все свое время дизайнеры тратили на подготовку к выставкам и переделку веб-сайта.

Все любят веселые шапочки и рожки на новый год

К концу года нас было 65.

2014

После долгого перерыва мы начали активно участвовать в конференциях. Первая ласточка — OOP в Мюнхене.

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

Появился еще один комитет — Office Board. Он занимается улучшением офиса и решением всех вопросов по питанию, соцпакетом, и тп. В целом работа комитетов оказалась неплохой, но есть еще над чем работать.

Пожалуй, в этом году праздники 23 февраля и 8 марта были самыми веселыми, за всю историю компании.

Ассоциации


Конференция в Москве тоже прошла хорошо. Раздали много маек, познакомились со многими людьми, привезли новых идей.

Аня Ковалева на стенде.

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


Впервые у нас был стенд на беларуской конференции. IT Spring в этому году оказалась неожиданно хорошей.

Наташа Ядренцева показывает Targetprocess 3. Фото украдено https://www.facebook.com/media/set/?set=a.844381965574653.1073741829.322075841138604&type=1

Мы наконец запускаем Targetprocess 3 и начинаем его активное продвижение. Мы потратили на это два с половиной года. Очень тяжело работать столько времени без существенного прорыва. Уже почти все готово. Маркетинговый бюджет выделен. Все ждут.

Timeline в Targetprocess 3

Сейчас в компании работает 80 человек.

В ноябре продукту исполнится 10 лет…

http://www.targetprocess.com

P.S. Нам нужны хорошие программисты: Javascript, .NET, Android, iOS — http://crew.taucraft.com