Куда двигается Targetprocess / Компания и продукт

Куда двигается Targetprocess / Компания и продукт


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

Компания

Проблема большинства современных компаний в том, что они созданы для единственной цели — заставлять людей работать (в лучшем случае, давать им возможность работать). Любому руководителю я рекомендую познакомиться с Russell L. Ackoff, который часто говорит прекрасное:

Perhaps the most costly disassembly in which our culture has been engaged is disaggregation of life itself into work, play, learning and inspiration. Each of these aspects of life has been separated from the others by creating institution for engaging in only one at a time, excluding the other three as much as possible. Business are designed for work, not play, learning, or inspiration. • Russell L. Ackoff

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

Обучение

Обычно считается, что люди должны учиться сами. Конечно, это так, но компания может им помочь. Учиться нужно всю жизнь без перерывов. Легко достигнуть каких-то высот и сказать себе “я знаю уже достаточно много, можно переключиться на детективы Марининой и спокойно работать по накатанной дорожке”. Так начинается путь к ДТП (диван, телевизор, пиво по вечерам). Так заканчиваются мечты.

“Единственный способ выжить — это постоянно ставить перед собой новые задачи” • Персиваль Бейли

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

Если чуть подробнее, то:

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

Компания может помочь во всем этом. Давайте посмотрим, как именно:

  • Покупать любые книги по заявке из любых источников; вручить каждому сотруднику Kindle с годовой подпиской;
  • Организовывать семинары и тренинги; оплачивать хорошие конференции;
  • Создавать зоны, где люди неизбежно пересекаются и беседуют (совместные обеды); приглашать экспертов для Q&A сессий; организовывать митапы;
  • Устраивать внутренние конференции, где люди делают презентации друг другу; стимулировать людей выступать на внешних конференциях, выделяя для этого время;
  • Уговаривать писать блог посты и статьи; лестью и обманом привлечь к написанию книги;
  • Предоставлять 10–20% времени на собственные проекты; организовывать хакатоны; давать возможность стартовать новые бизнес-юниты;

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

Вдохновение

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

Потолок Сикстинской капеллы. На картинке, может, и ничего особенного, но живьем неплохо.

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

Для вдохновения людей могут работать (или не работать) следующие вещи:

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

Компания должна давать возможность и помогать сотрудникам найти то, отчего их прёт. Если вдруг окажется, что человеку захотелось стать художником вместо программиста — это же прекрасно, пусть становится. Вместо среднего программиста, возможно, человечество получит гениального художника.

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

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

Я считаю, что компания должна в идеале:

  • оплачивать посещение ведущих конференций в разных странах
  • предоставлять раз в несколько лет длительный оплачиваемый отпуск на 2–3 месяца
  • выделять 10–20% времени на свои проекты
  • поощрять и спонсировать хобби и увлечения людей, организовывать кружки по интересам (рисование, спорт, whatever)

Свобода и доверие

В идеальной компании человек может делать то, что хочет без всякого контроля со стороны руководства. Руководство доверяет сотрудникам и надеется, что они будут тратить свое время на благо компании и общей цели. Главная идея — объединить людей, которым нравится работать вместе для достижения единой цели. Практически невозможно собрать 100+ человек с единой целью вместе, но крайне важно, чтобы была критическая масса таких людей. Я бы сказал, что 20–30% достаточно.

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

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

Возьмем программиста в нашей компании и представим, что ему никто не говорит, что делать. Как ему решить, какую задачу взять? Какая проблема важна для клиентов, а какая — нет? Внезапная свобода выбора не приведет к хорошим последствиям. Оказывается, нужно погрузиться в домен управления проектами, разобраться с процессами типа Scrum, Kanban, SAFe, понять, какие недостатки есть в Targetprocess, посмотреть запросы пользователей, посмотреть другие похожие продукты, изучить рынок и так далее. Без хороших доменных знаний просто нереально требовать от разработчика хороших решений и хорошего выбора. Свобода выбора задачи в контексте незнания домена просто вредна.

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

Мне кажется, хорошее решение — создание кластеров с четким фокусом на определенный под-домен. Кластер может состоять из 6–50 человек, среди которых должны быть все роли: сейлс, разработчики, тестировщики, дизайнеры, специалисты поддержки. Тогда свободой выбора обладает сам кластер, а не отдельный человек в нем. И важно иметь в каждом кластере компетентное ядро из 5+ человек, которому реально интересен этот домен.

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

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

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

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

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

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

Работа

Компании никогда не создаются с целью “обеспечить обучение и вдохновение сотрудников, дать им свободу и независимость”. Обычно цели другие — либо создать что-то новое и полезное, либо просто заработать денег. Для достижения таких целей надо работать, так что работа (сюрприз!) является самым важным в компании. Для меня лично важны следующие подходы к работе:

  1. Работа должна нравиться. Человек должен работать с удовольствием, перемежая сложные задачи на грани своих способностей с более простыми и рутинными задачами. Компания должна сделать все возможное, чтобы интересы человека совпадали с задачами компании. Если это невозможно—есть два выхода: расстаться с человеком или дать ему возможность запустить что-то свое.
  2. Работа должна справедливо оплачиваться. Что это значит? С одной стороны, компании нет смысла переплачивать сотруднику, если рынок труда имеет определенный размер зарплаты. С другой — у компании есть желание избавить человека от мыслей о дополнительных источниках дохода. Поэтому в целом зарплата должна быть немного выше рыночной и нужен механизм распределения части прибыли между всеми сотрудниками.
  3. Карьерный рост не должен быть привязан к зарплате. Если в компании в целом отсутствует иерархия, меняться может только круг обязанностей, продуктивность и экспертиза, вот это и должно оцениваться.

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

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

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

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

Размер и структура

На текущий момент наша компания состоит из 100 человек. Мы хотим сделать классную платформу для управления работой, для этого по самым скромным прикидкам нужно человек 200–300. Дальше возможен рост и до 1000+ человек, если платформа окажется хорошей и на базе нее можно будет делать решения в разных областях.

Рост компании неизбежно влечет структурные изменения. Мне нравится вот такая схема:


Что изменится, когда в компании будет 200+ человек? Кросс-функциональные команды будут объединены в доменные кластеры, которые будут развивать направления платформы. В некоторых кластерах будет около 10 человек, а в других может быть и до 30. Примерный список кластеров такой (но можно и другое разбиение придумать):

  • Visualization and BI — how to make visual and smart
  • Integration — how to integrate into company ecosystem
  • Solution Units (PPM, QA, Help Desk, Kanban, SAFe)
  • Design — how to make usable and simple
  • Infrastructure and Performance — how to make things fast
  • Communication — how to share and exchange information
  • Domain Core — how to make flexible and configurable
  • Mobile

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

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

Как же будут формироваться новые кластеры и закрываться ненужные существующие? Тут есть много вариантов, которые в целом завязаны на общую стратегию продукта. Это может решать один человек (CEO/CTO), экспертный совет из ключевых людей из разных кластеров, либо вся компания на общем собрании

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

Руководители

Все чаще делаются попытки создавать компании без менеджеров. Главный вопрос — зачем?

Ну ответ довольно прост: если компания без менеджеров может работать хотя бы так же успешно, как компания с привычной иерархией, то можно иметь на 20–30% меньше людей и создавать те же штуки, что и раньше.

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

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

  • Наем и увольнение. Доменный кластер сам нанимает себе людей и увольняет тоже сам. Собеседования программистов должны проводить сами программисты (трех обычно достаточно). С увольнением немного сложнее. Тут может помочь механизм peer review и командные ретроспективы. Но увольнение всегда тяжелый и неприятный процесс, я пока не знаю хорошего решения.
  • Зарплата. Я думаю, в компании должен присутствовать profit-sharing и прозрачные механизмы установления зарплаты. Есть примеры Buffer и FogCreek, где зарплаты прозрачны и всем известны. Неясно пока, насколько все это работает в культурном контексте Беларуси, но в целом должна быть унификация и прозрачность. То есть процесс заменяет индивидуальное решение менеджера.
  • Разрешение конфликтов. Наверное, самое сложное для самой команды. Очень нелегко бывает решать конфликт, когда люди равноправны и ни у кого нет последнего слова. У нас в компании пока этим занимаются руководители. В целом могут работать ретроспективы и привлечение третьей стороны. Есть примеры компаний, где конфликты решаются без руководителей.
  • Менторинг. Тут все довольно просто — опытные сотрудники могут быть хорошими менторами. Могут и не быть, но какой-то нужный процент таких людей обычно имеется. Так что в целом программистам в менторы нужны просто более хорошие программисты.
  • Улучшение процессов. В целом, сотрудники сами должны улучшать свои процессы. На первых этапах им нужна помощь в методиках и практиках, но после пары лет все работает уже само. У нас с этим стало гораздо лучше в последнее время.
  • Видение и стратегия. Еще один сложный вопрос. Как мне кажется, обычно видением обладает один человек, а не группа менеджеров. Поэтому теоретически в компании может быть всего один человек, который задает стратегию развития (CEO или CTO) и убедительно доказывает всем, что стратегия верная. Эту роль может играть и группа экспертов. Другой интересный вопрос, а может ли видение формироваться эмерджентно, как результат независимой работы нескольких кластеров? Я думаю — может. Именно по этому пути шла эволюция живых организмов. Почему бы и компании не следовать таким путем?

Люди vs. Продукт

Компания начинается с людей или с продукта? На первом этапе все же обычно с продукта. Люди, которые работают на первых этапах, посвящают себя одному продукту. Постепенно компания растет в размерах, начинают появляться идеи других продуктов, и на этом этапе возрастает значение культуры и людей. Вообще формирование культуры происходит не сразу, а через несколько лет после основания компании. И если этот момент упустить, то потом изменить базовые принципы компании будет невероятно сложно. Я с трудом могу себе представить, как изменить культуру и развернуть компанию, где работает 1000 человек. Это может привести к массовым увольнениям, серьезным потерям продуктивности и даже к гибели компании.

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

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

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

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

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

Управление работой. Как меняется мир.

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

  1. Скорость обмена информацией возрастает. Медленные каналы заменяются на быстрые (Slack vs. Email). Люди хотят получать важную информацию мгновенно. С другой стороны, растет информационная нагрузка и становится сложно контролировать все потоки.
  2. Экспоненциальный рост данных порождает проблемы их обработки и извлечения полезной информации. Это касается всех рынков без исключения. BigData, Visualization, Business Intelligence входят во все рынки.
  3. Изменяются подходы к организации труда и быстро видоизменяются рабочие процессы. Scrum, Kanban, SAFe, Holacracy, Lean, Teal Organizations. Традиционные методики становятся все менее релевантными.
  4. Инструменты становятся более интеллектуальными, автоматизируя многие действия и стирая из экономики некоторые специальности. AI выходит на заметные роли практически во всех рынках. Простой микс AI+Domain скоро будет работать везде.
  5. Сложность проектов возрастает. Распределённость, тысячи людей, быстро меняющие технологии — все это усложняет управление проектами. Кажется, что это можно решить через разбиение больших проектов на маленькие и трансформацию структуры компаний.

Продукт/ы

Любой продукт, претендующий на решение проблем управления проектами ближайшего будущего, должен обладать следующими свойствами:

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

Рабочий процесс удобно представлять классическим циклом Деминга (PDCA)

PDCA цикл с ключевыми аспектами

Если посмотреть на все современные продукты управления работой, то мы получим примерно такую картину (Targetprocess — не исключение):

Зеленым выделено функциональное покрытие фаз работы современными инструментами ALM

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

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

PLAN

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

DO

  • сейчас / очень мало автоматизации работы, очень слабая нотификация и довольно слабая интеграция в информационные потоки компании.
  • будущее / полная автоматизация рабочих процессов. Человек должен фокусироваться на value-added вещах, а все прочее должно происходить по возможности автоматически. Например, когда мы делаем юзер стори, работа над ней требует взаимодействия с GitHub, Build Board / Jenkins, Slack, Help Desk, IDE (Visual Studio), Targetprocess, Google Docs, Dropbox. Определенные события могут запускать цепочки действий, экономя время людей (Zapier выглядит неплохим шагом в эту сторону).
  • пример / на закрытие юзер стори посылается сообщение в Slack, закрывается реквест и нотифицируются реквестеры, удаляется бранч в гитхабе, обновляется change log.

CHECK

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

ACT

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

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

  • Process mapping and improvement software (Targetprocess)
  • Information visualization software (VizyDrop)
  • Work automation software
  • Communication automation software
  • Work intelligence software

Тесная интеграция продуктов позволит заходить в компании с самых разных сторон (подобную стратегию успешно использует Atlassian, но с другим набором продуктов). Наша ошибка была в том, что мы изначально не думали о тесной интеграции Targetprocess и VizyDrop. Правда, мы все равно пришли к этой идее и начали её воплощать.

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

Сервисный подход

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

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


Если кратко, то в следующие 2–3 года нам предстоит решать следующие задачи:

  • Разработка гибкой доменной модели, которая позволит создавать свои сущности, связи между ними и бизнес-правила.
  • Замена (эволюционная либо революционная) всего серверного слоя.
  • Разработка единого центра сообщений.
  • Унификация UI компонентов и разработка новых (mind map, например).
  • Разработка новой среды для интеграции и реализации своих приложений (apps).

Резюме

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

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

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

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

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

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

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

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

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

  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. Спасибо Андрею Хмылову за ценные рекомендации по разделу “функциональное программирование”. Ну фактически это он его и переписал, потому что мои примеры были слишком абстрактными.

Agile is Poisonous

I don’t believe in agile development anymore.

Our company applied agile practices from day one. We’ve started agile usage in 2006. We tried almost everything: Extreme Programming, Scrum, Kanban and many many small practices. Did it stick? Hell no. Let’s review the lessons.

Daily Meetings

They are just worthless. We used to gather together at 11 am in a single room and report what was completed, what is not, whether there are some blockers. Well, when there are about 30 people in a room these meetings are not fun. They took up to 10 minutes usually, but sometimes they took as long as 15 minutes (I think this duration just can’t be tolerated). After the meeting, people go and grab coffee, chat about problems, chat about ideas… These useless activities distract people and they spend less time on coding. 

We’ve replaced daily meetings with a weekly status reports sending via email. The format is very simple with just 7 questions like “Please, enumerate all tasks you’ve completed last week” and “How you estimate your personal productivity on a scale from 1 (low) to 10 (exceptional)”. We collect all emails, process them and have a real stats per person, per week, per project, etc. Really cool!

Iterations

We tried 1 week and 2 weeks iterations. Neither worked out. With short iterations there was a constant pressure to get shit done and technical debt accumulated like a huge garbage heap. It is impossible to squeeze a good solution into a short timeframe. There’re so many meetings like iteration planning, planning poker sessions, iteration demo, iteration retrospective… These meetings are killing productivity, you know. 

QA were struggling with short iterations as well. It is impossible to test a user story thoroughly in few days. We tried mini-waterfall in a single iteration — didn’t work, testing phase started just 2 days till the end of the iteration with miserable outcome. We tried to write many unit tests and acceptance tests — didn’t help, since requirements were changing so rapidly. We tried to force developers run manual tests… Well, we lost some very cool developers as a result and removed this practice.

The last nail in the coffin was a loss of a Scrum Master. He fed up with constant rants and got back to coding. He refused to play a Scrum Master role. Without a Scrum Master everything was doomed. Developers reverted to hack-and-fix mode, QA reverted to post-bugs-and-forget mode. Chaos replaced everything. Then we decided to try Kanban.

Kanban

We draw a very cool board with 23 states and placed everything into it. It looked awesome. We used color coding, we used real photos and some clever rules. For example, when a user story stayed too long in some state, we stick some funny blame words above the assigned person’s photo (like “stupid snail” or “you’ll never complete this task, hahaha!”). This really motivates to get shit done faster, you know. 

With Kanban you have a luxury to implement feature as slowly as needed. No pressure at all. Well, we didn’t like the overall velocity though and decided to bring deadlines back. Deadlines were set by top management.  All features started before the deadline should be completed and released. It lead to quite a few games between developers and managers: developers resisted to take new features when deadline was close, managers tried to put as many features as possible before the deadline. Sometimes developers had to work 100 hours per week to make a release. And that is NOT a joke! 

We tried to put limits in states and review the flow (23 states are too many). It helped a little, but managers decided that limits restrict them and removed the limit from the In Progress state. A month later everything was In Progress. 

So Kanban didn’t help us as well. However, we learnt that visualization is good and tried to apply it everywhere. We’ve tried various visualization techniques to increase transparency and productivity. For example, we tried to visualize builds statuses, work progress, future plans and roadmaps — without any success.

Here are the things that are really helpful:

Wall of Blame

We had a nice and visual “Wall of Blame”. Developers with the worst individual velocity for the last month were mentioned in a Dilbert-like comic strips. It was updated every 1st Friday of the month and this day even got a special name in our company: ”Blame Day”. People that appeared on a Wall of Blame were no rights to defend themselves in a Nerf Battle this day. Oh, these days were so funny!

Wall of Heroes

This board was right opposite the Wall of Blame. Naturally, top coders and top performers occupied this board. Their photos were very professional (we hired a good photographer to make them). The photos were in gold frames with engraved titles like “Jonny Summer. Top Lead Developer. March 2012”. Well, some photos required a serious makeup, it is hard to look good after a 100 hours work-week.

Curses Chart

We invented Curses Chart to measure fuck ups in projects. Every room has a recording device. We record everything. Speech analyzing software is used to extract curses from all records. These records are accumulated and a day-by-day chart shows how many curses there were. This chart is displayed on a large TV in the kitchen. Also it rotates recent exceptional curses. We found out that the correlation between curses and fuck ups is perfect.

Pair Programming

We tried to enforce pair programming and decide how good it is. Did it work? Nope. People were constantly arguing about things, trying to find the best solution. In the end they we reluctant to talk to each other at all. There was a case when a lead developer hit his teammate with a Microsoft keyboard and broke his nose. After this incident we replaced all Microsoft keyboards with Logitech keyboards (with soft keys) and banned pair programming practice forever. Now people can’t talk near a workstation, they have to walk into the meeting room and talk there, sitting in soft chairs.

We tried many more other practices, but this post is already too long. I’ll post more exactly a year later.

UPD: Hacker News Discussion

UPD: OK, it was 1st April post. Truth is here.

tau-conf #4

We run internal conferences every 6 months. Next one is big enough to have 2 days conference. Here is the program:

tau 4 #all (10 sessions) / day 1
10:00 Gamification. Using game elements in management, marketing, etc. Personal experience from support team / S. Gnedin
10:30 Professional deformation / A. Kovaleva
10:50 coffee break
11:00 Feedback Loops / U. Petriko
11:45 Value-Driven Development (How I run my cozy project using tp3). How to do the right things / A. Parasiatsyeu
12:30 lunch
13:30 Probability Theory for Dummies / A. Shnyukova
14:30 coffee break
14:45 Agile Portfolio Management / D. Borovsky
15:15 Enneagram as a tool of right communication / N. Yadrentseva
16:15 coffee break
16:30 Intro into Game Development / V. Gaidukevich
17:15 coffee break
17:30 How to choose the right chart for your data / O. Seriaga
18:00 Visual Specifications. Why most specifications suck and how to improve them / M. Dubakov

tau 4 #dev (6 sessions) / day 2
11:00 Nature of concurrent and distributed programming. Basic principles of concurrent and distributed programming, their formal foundation, examples on programming languages / A. Shotkin
12:00 coffee break
12:15 Applicative Functors, Monoids and Monads — who are they? With examples in haskell / S. Truhtanov
13:00 lunch
14:00 JavaScript VM / K. Krivlenia
14:45 coffee break
15:00 Intro to Lambda-calculus. Theoretical foundations of functional programming / U.Abramchuk
16:00 coffee break
16:15 New APIs in your browser. Less known features of modern browsers (DOM traversing without jQuery, CSS selectors, Web Components, a little of ES6) / A. Shytkin
17:00 coffee break
17:15 Formal verification. How to write programs to verify other programs / A. Famin

Great Things Take Time

Great things take time. Evolution and complexity are two sides of the nature development. Let’s take cars. Cars are becoming more and more complex. At the same time, cars are becoming more reliable, faster, more efficient, safer and better. It took humankind a century to get there. The progress pace is impressive, but incomparable with software development.

Things change in software development world with an astonishing  “never seen before” speed. 10 y.o. technologies are history. 10 y.o. software without major upgrades is dead. While 10 y.o. cars are quite good and decent. 

We, software developers, are blessed with a gift that makes our industry truly different — we can upgrade working systems on the fly. To have a new car you should sell an old one and buy the new car. To have a new version of SaaS application you don’t have to move a finger. Software developers have a luxury to iterate fast, fail fast and emerge viable, efficient solutions. 

Software development industry is not so young, it is about 50 years old. It took us 50 years to reach the point where “software is eating the world”. 

Companies: Hedgehogs and Foxes

OK, back to the main point of this essay. There are two types of companies: Hedgehogs and foxes. Hedgehog company takes one area and digs deep. It usually create a single software application for a single market (no matter if niche or wider). Fox company builds many applications for various markets, it constantly tries many new things and never stick to a single thing.

I don’t like foxes. In most cases they can’t create something significant. However, let’s check some examples. Rovio created 50 or so games till the Angry Birds slam-dunk  It’s a hedgehog company. It was fully focused on game development. They tried various models and various gameplays.   They iterated and failed many times.

Apple is a hedgehog company (well, there were different times at Apple, but now this statement is correct). Apple launches new products with care. No rush jumps to find a hit, but careful and passionate immersion to the roots of people’s problems and great solutions. 

Salesforce is a hedgehog company that pushed the SaaS model into enterprise and without doubts has the best CRM solution on the market.

What about fox companies? Many (not most) service companies are foxes. They take various projects without clear focus. They use diverse technologies and ready to work with almost any industry. They tend to grow huge, make good money, but they’ve close to zero chances to create something significant, something disruptive. I’m not aware of foxes in product development. Maybe there are plenty, but most of them are quite unknown and “not on the radar”. Maybe this “fox” strategy is devastating to product-oriented company success.  

Definitely it is not enough to focus on a single thing. You need great people, good strategy, real passion and so on and so forth. There’s one more thing you have to know and think about — time. With some luck your first solution of a problem may be exceptional, but it’s an extraordinary event. Time can be your worst enemy or your best ally. You should learn how to master time. 

Time: Patience and Persistence

Patience is good. Without patience you will cut corners and provide superficial solutions. You will rush and deliver something of a poor quality. I still can’t master patience. I’ve been trying hard last year with some promising results, so we’ll see.

Patience and passion help you to solve the same problem again and again, bringing in new experience, new technologies, new people, new ideas. Someday your n-th solution will be precise and sharp, it will touch the right chords and resonate with people. It may happen in 3 years, in 5 years or in 20 years. Many companies explored promising areas, but failed due to lack of patience, lack of persistence. 

However, there are times when you have to run full throttle, forcing everything and everyone to squeeze the last drops of energy. Usually this mode is required to overcome a crisis. You just can’t slack when situation is harsh and uncertain. 

Balancing between these two modes is hard. I personally like to run fast, but it burns out energy and decompression period is inevitable afterwards. I still can’t master the balance.

I believe patient and passionate hedgehog companies can put a ding in the universe

Hacker News discussion