Недавно наткнулся на статью о том, почему хорошие разработчики пишут плохой код в больших компаниях. Автор объяснял это высокой текучкой, тем, что большинство изменений вносят новички, а ветераны перегружены и не успевают передавать экспертизу. Меня эта статья зацепила, потому что я видел и другую картину в своей практике. Решил поделиться опытом: как в сравнительно небольшой ИТ-компании можно писать хороший код, когда собственник ратует за его качество.

Однажды фраза из к/ф "Человек с бульвара Капуцинов" навела меня на размышления о моем пути в ИТ-профессии. В отличие от Билли, мне повезло: я не просто встретил хороших людей, а прочитал умные книги, которые эти люди написали. Когда я вспоминаю годы, когда только становился программистом, отчётливо вижу те издания, которые заложили мой будущий фундамент. Это были не просто инструкции, а встречи с людьми, которые изменили мой взгляд на программирование и управление. Удивительно, насколько сильно несколько толковых книг могут повлиять на судьбу человека!

Refactoring Мартина Фаулера научил меня профессиональному отношению к коду и привычке доводить детали до совершенства. Не писать идеально с первого раза невозможно. Но постоянно улучшать, рефакторить, делать код чище и понятнее. Это не про перфекционизм, а про уважение к тем, кто будет читать этот код завтра. Фаулер однажды сказал: "I am not a good engineer, I am an engineer with good habits". Эта фраза стала для меня ключевой. Я понял, что хороший код это не про талант, а про привычки. Про то, что ты делаешь каждый день, даже когда никто не смотрит.

Представьте себе такую ситуацию. 2024 год. У меня больше ста человек. Российская продуктовая IT-компания. Кровавый энтерпрайз: куча систем в продакшене и целый зоопарк legacy-кода, который нужно поддерживать. И главный вопрос: как заставить все это двигаться быстрее? Производительность труда была серьезной проблемой, а традиционные KPI и премии работали, но не вдохновляли.

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

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

За 20 плюс с лишним лет опыта управления продуктовыми ИТ компаниями я никогда не имел личного ассистента. Не знаю, как так получилось, но мне всегда было проще самому создавать события в календаре или сортировать свою почту. Не то чтобы я этого не мог себе позволить, но так ни разу не делегировал часть своей рутины другому человеку. Тут, наверное, есть два варианта. Или я control freak или жадина, но мне приятнее думать, что первое :-)

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

За 10+ лет создания продуктов в российском enterprise я накопил... нет, не мудрость. Я накопил знания. Тонны документов, приказов, протоколов, шаблонов, процессов, ментальных моделей, контекстов решений. Всё это живёт где-то между корпоративными папками, чатами, почтой и, конечно же, моей головой.

И вот приходит тот радостный день: я могу выйти из операционки и передать дела новому наёмному менеджеру! Но радость быстро сменяется вопросом: как передать всё это богатство?

Классический сценарий:

За двадцать с лишним лет работы в области управления данными я видел всё: от Excel-таблиц вместо MDM до попыток построить Data Governance на коленке. Видел, как компании тратят миллионы на внедрение систем, которые никто не использует. И видел, как правильный инструмент меняет всё: от культуры работы с данными до скорости принятия решений.

Сегодня российский рынок Data Management активно развивается, растёт осознание важности управления данными. Но любопытство берёт своё: а что там, на западе? Какие подходы, какие фишки, какие боли они решают?