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

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

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

Недавно я прочитал одну тяжелую книгу — 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