Владислав Тимофеев

Владислав Тимофеев

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

  • 10+ е-ком проектов;
  • помог 4+ стартапам;
  • 3+ страховые компании в качестве разработчика;
  • обучил 50+ мидлов и синьор;
  • 10+ тимлидов и техлидов.
TIMOFEEV Tech Talk
112 участников
20 апреля
DX (DevEx) — то же самое, что UX, только для разработчиков.

Насколько удобно, продуктивно и приятно инженеру работать с проектом.

Обычно закладывают в это понятие онбординг, документацию, качество API/интерфейсов/контрактов, мониторинг системы, инструменты, которые оплачивает компания и которые используются в проекте (линтеры/hot reload/итд), CI/CD и так далее.

Хороший DX — разработчик тратит время на бизнес-задачу, а не на борьбу с инструментами.

В рф-компаниях я редко встречаю, чтобы об этом сильно беспокоились. Или чтобы даже была выделена отдельная роль под это дело.

Но мало того, что этим почти никто не занимается — так он теперь ещё и нахер не нужен))

Потому что пришли агенты, и пора пилить AX (Agent Experience) — дать агенту руки (MCP) и обучить его:

• доступность контента с сайтов через внедрение llms.txt / llms-full.txt

• MCP — доступ к БД / логам / трейсам / документации и т.д.
понятные коды ошибок

• markdown-first docs — документация, которая нормально парсится

• skills — навыки для агента. Как писать код, как его декомпозировать и упаковывать, и многое другое. У меня, например, полный набор по DDD в скиллах лежит



Классный опыт из моей практики: мы начали делать MCP-тулы прямо в приложении, которые дают доступ на чтение к БД / трейсам / Temporal.

Это дало очень крутой буст:

• Для разработчиков: локально дебажить фичу. Что-то пошло не так — скидываешь id агенту, тот идёт сам, всё проверяет: что где упало, с какой ошибкой, что пошло не так.
Оч круто работает на разработке агентских систем, когда нужно проследить трейс, чтобы понять, где агент свернул не туда, и предложить улучшения по промптам и инструментам.

• Для продактов: прямо в проде смотрят стату по продукту, аналитику, разбирают фидбек юзеров.
Кстати, отсюда же, по фидбеку, можно проработать негативные сценарии и получить предложения по улучшению кейсов. Интеграция с Claude/OpenCode — изи.

• Для саппорта/инцидентов: можно одним походом найти проблему — вместо 15-минутного серча руками.
А самый прикол — AX не заменяет DX, а развивает его.



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

Ну и для онбординга разработчика агент может стать классным AI Buddy по проекту 😉
🔥
8
💯
2
👏
1
👨‍💻
1
54
18:32
Читать в телеграме
27 марта
Наткнулся на классное объяснение как устроен Claude Code , но по факту это про то, как работает любая агентская система

https://github.com/shareAI-lab/learn-claude-code
🔥
8
❤
3
👍
3
⚡
1
143
15:54
Читать в телеграме
21 ноября 2025 г.
Чаще всего в проектах встречаю загрузку файлов в S3 через бекенд.

В типичном проекте в прод окружении файл проходит следующие этапы:


frontend -> reverse proxy -> backend -> S3


Если предполагается часто используемый функционал с загрузкой файлов, то это решение может стать узким горлышком. Особенно если речь заходит о больших файлах. В такой конфигурации большой latency за счет большого кол-во узлов, через которые проходит файл, сюда может добавить API Gateway, например, KrakenD или kong. Если проект на php-fpm - может забиться пул. И в целом приложение начинает потреблять больше ресурсов инфры

Этот подход называется Backend File Uploads.



Есть и второй -- Frontend File Uploads

В этом подходе, загрузка файлов происходит с фронта напрямую в S3 bucket. А для достижения безопасности используется Presigned Url (подписанная ссылка).

В этом подходе файл загружается в два этапа:
1) получение подписанной ссылки на бекенде
2) загрузка в S3 по подписанной ссылке


Преимущества подхода:

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

- снижение latency -- файл проходит меньшее кол-во узлов

- открывается возможность загружать файлы до 5 ТБ

- скорость загрузки ограничивается клиентом и сервером S3. В backend upload нужно учитывать сетевые задержки + ограничение скорости между узлами в зависимости от их сети. Например, провайдер выделяет только 100 МБит/с



Реализацию можно поизучать в opensource, например, как в outline/outline загружаются прикрепляемые к документу файлы

https://github.com/outline/outline/blob/0d1c8490b5ffd0823a1f9ae7c5fa3438ed112eee/server/routes/api/attachments/attachments.ts#L137
🔥
8
❤
7
👍
4
💯
1
334
14:19
Читать в телеграме
6 ноября 2025 г.
Наверное никто так сильно не бесит чем ии-агент, который не может решить задачу, если она чуть сложнее чем просто заменить текст 😠

Ну а что, интроверты мои, нужно выйти из зоны комфорта и попиздеть 1-1 с машиной

Вот простой алгоритм действий для формирования задачи для ии-агенту:


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

Тут если что, мы не на "вы", а имеется в виду ты и агент, мини-тимворк)

2) Четко сформулируйте ожидаемый результат. Определите, что именно должно получиться на выходе: какие файлы будут созданы или изменены, как они должны называться, и как проверить, что всё сделано правильно

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

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

5) Включаем проверки каждого шага. Чтобы гарантировать, что задача выполнена правильно, добавьте способы проверки результатов. Агенты хорошо справляются с curl запросами, неплохо пишут юниты или e2e тесты, с которыми можно проверить работу

Ну и всё, запускаем план в работу и идем наливать кофе, ведь впереди отладка на 100 часов 😁

P.S. Если нужно, могу сделать более короткий или более технический вариант.
🔥
14
😁
6
❤
5
👍
3
301
20:10
Читать в телеграме
25 июля 2025 г.
А знаете, в чем парадокс?

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

Внедрить DDD оч сложно, сопротивление ждет на каждом уровне, от разработчиков, экспертов и начальства. Не смог продать? -- Сидишь юзаешь тактические паттерны в свое удовольствие, и спросишь с тимлидом о решениях, вот и всё -- типичное внедрение. Тут же от тебя DDD требует и дисциплину, добавляет огоньку в жаркие споры и ссоры с коллегами, а также задачу ещё вчера нужно было сдать. А ещё, а ещё -- реализовали крутой тактический паттерн, а он дал тебе оверхед и нагрузку на инфу, ну счастье 🙂

Поэтому внедрение DDD затягивается или не внедряется.

LLM сейчас активно внедряется в разработку, 25% стартапов имеют 95% кода, написанного AI, 60% разработчиков юзают ллм, ттм растет, а время внедрять ддд, обучаться и обучать команду стало ещё меньше. Код генерится быстрее, чем ты успеваешь подумать.

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

Вот такой парадокс, ддд зашел с другой стороны
🔥
12
👍
7
🤔
4
😢
1
👀
1
344
16:35
Читать в телеграме
17 февраля 2025 г.
Я не использую LLM, потому что она украдёт мой код


Только этот код никому не нужен, кроме меня/заказчика/работодателя. Заказчику даже нужен не код, а решение проблемы.

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

Код является важной частью бизнеса, особенно в технических компаниях. Но помимо кода, нужно ещё уделять кучу времени на другие вещи. Возьмём аренду квартиры и коммерческих помещений. Представь, я получил код Airbnb. Я готов запустить его уже сегодня и стартовать свою площадку по объявлениям аренды квартир. Это лишь 10%. Нужно подумать о следующем:

1) как привлекать клиентов? Сразу все рванут в аналог Airbnb?
2) как заполучить доверие клиентов?
3) как регулировать юридические вопросы?
4) как регулировать конфликты между арендодателями и арендаторами?
5) как наладить операционные процессы?
6) как выстроить команду разработки, поддержки, маркетинга, продаж, бухгалтерии и т.д.?

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

Поэтому код без продукта не имеет особой ценности.

Вот пару примеров:

Хабр Фриланс - моё мнение, он обрёл популярность, потому что было создано определённое комьюнити вокруг основного продукта - Хабра. Но оказался невыгоден, его закрыли. Сложно ли реализовать такую площадку с точки зрения кода? -- Нет. Простой CRUD на Ларавеле.

Яндекс - слили огромную кодовую базу, такси, маркет, почта, диск, трекер. Был ли взращён на этом новый конкурент? -- Нет. К нам в город заходил DiDi и Ситимобил. Они активно развивались в моём городе, но сейчас я про них уже не слышу. Помог ли им код Яндекса? -- Нет.

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

Провайдеры LLM только и ждут, когда я солью им свою кодовую базу регионального интернет-магазина, реализацию витрины и доски объявлений, или очередную "уникальную" задачу.



Но когда это всё же оправдано, код - это core домен, например:
- алгоритм сжатия данных
- алгоритм шифрования
- алгоритм машинного обучения, разработчики DeepSeek разработали алгоритм для дешёвого обучения моделей, было бы странно, если бы они эту кодовую базу слили в OpenAI, используя ChatGPT.
- военная промышленность
- и т.п.



Короче, никому ваш код не нужен, а вот ассистент ускорит вашу работу в множество раз.
👍
11
🔥
7
💯
4
🤓
3
❤‍🔥
1
507
10:38
Читать в телеграме
17 января 2025 г.
Tech generation gap

Или старая школа против новой школы


1950-1960

В 50-х случилась первая революция в программировании — появился Fortran. Олды, привыкшие писать на ассемблере и колдовать с перфокартами, были в шоке: "Высокоуровневый язык? Серьёзно?" Они считали, что настоящий программист обязан понимать каждый байт и такие абстракции убьют всю производительность. В те времена айтишники были реально как небожители — попасть в профессию стоило космических денег, а знания передавались чуть ли не из рук в руки. Но всё резко изменилось с появлением пк, и началась новая эра программирования.


1970-1980

70-е принесли C и Pascal, и снова началось: "Слишком много абстракций!" Олды были уверены, что эти языки превратят программирование в детскую игру в конструктор. "Как можно писать код, не зная, что происходит на уровне железа?" — возмущались они. И конечно, все были уверены, что производительность упадёт в пропасть. Знакомо звучит, да?

1990

90-е: на сцену выходят Java и .NET, и С/С++ разработчики хватаются за голову: "Виртуальная машина? Сборщик мусора? Да вы издеваетесь!" По их мнению, garbage collection был костылём для ленивых кодеров, которые не хотят разбираться с управлением памяти. "Настоящие программисты сами освобождают память!" — звучало со всех сторон. История повторялась, только теперь уже C++ разработчики оказались в роли консерваторов.

2000

Нулевые встретили Python, Ruby и PHP громким "фейспалмом" от корифеев: "Интерпретируемые языки? Серьёзно?" Опытные разработчики крутили пальцем у виска: "Какие большие системы? Это же просто игрушки для джунов!" Но мир менялся — open source движение набирало обороты, и молодёжь чувствовала себя в нём как рыба в воде. Старая гвардия, годами строившая закрытые системы, с трудом принимала новую философию разработки, а их богатый опыт внезапно стал казаться менее релевантным.

2010

2010-е принесли мобильную революцию и облака. "Какой еще Swift? React Native? Да на нативном Android/iOS писать надо!" — ворчали опытные разработчики. А молодежь уже вовсю запускала стартапы на AWS и Azure, пока старая гвардия недоверчиво косилась на "эти ваши облака" и продолжала держаться за собственные сервера. "Доверить данные третьей стороне? Да вы с ума сошли!" — и снова история повторялась, теперь уже с новыми технологиями.

2020

2020-й ворвался в нашу жизнь ковидом и тотальной удалёнкой. "Какая эффективность на удалёнке? Как вообще можно командой работать через Zoom?" — паниковали олды, привыкшие к опенспейсам и личным стендапам. А молодёжь уже вовсю гоняла код через GitHub, чилила в Дискорде и успевала фрилансить между стендапами. "Офис — это место силы!" — настаивали менеджеры старой школы, пока их команды доказывали обратное, разбежавшись по домам и коворкингам. И снова одни топили за стабильность и традиции, а другие — за новые подходы к работе.

2022

2022-й принёс нам ChatGPT, и понеслось: "Какой ещё AI-ассистент? Нормальные программисты сами пишут код!" — возмущались опытные разрабы, видя как джуны генерируют целые функции одним промптом. Но пока одни причитали про "деградацию профессии", другие уже вовсю использовали нейронки для рутины и прототипирования. "Это не настоящее программирование!" — кричали хардкорщики, наблюдая как их младшие коллеги решают за час те задачи, на которые раньше уходили дни. И снова знакомая картина: старая гвардия защищает традиционный подход, пока новое поколение осваивает инструменты будущего.


По-любому, лет через 10 мы сами будем те самые олды, которые ворчат на очередную революционную технологию


Ну что, почитали? пойдемте тогда работать , кто байтики перекладывать, кто массивы в дтоошки и обратно, или может с ноги в AI?
🔥
15
❤
5
💯
5
👍
2
🆒
1
385
09:15
Читать в телеграме
10 января 2025 г.
В одном из предыдущих постов я писал про упаковку кода.

Хочу ещё обратить внимание на папку utils в проектах.

Ставь 💊 , если в вашем проекте есть папка utils и она похожа на солянку после новогоднего стола.

utils/common/base - набор бессмысленных названий пакетов и модулей, которые открываешь со словами из мема "ЧТО У ВАС ЗДЕСЬ ПРОИСХОДИТ?"

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

Но не нужно бездумно выносить его в "utils", как "нужную" вещь на балкон.

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

Вот пример

❌ 

utils/
    - Floats.php
    - Integers.php
    - ChunkHelper.php
    - RequestHelper.php
    - Masker.php
    - TimezoneShiftInterface.php
    - UuidUtils.php
    - Pagination.php
    - Config/
        - Parser.php
        - ParseException.php


Декомпозированный вариант, с выделением пакетов по смыслу:

✅ 

math/
    - FloatOperations.php
    - IntegerOperations.php

  http/
    - CreateRequest.php
    - ErrorHandler.php

  datetime/
    - TimezoneShiftInterface.php

   uuid/
    - UuidFactory.php

  crud/
    - Pagination.php

  config/
    - Parser.php
    - ParseException.php


Бессмысленное название пакетов прямой путь к складированию кода, нарушению SRP, запутыванию кода и поиску нужных вещей.

Если у вас был опыт с такой папкой, встречали ли вы две одинаковые функции в ней, написанные разными разработчиками?

У меня было и такое, но одна и та же функция по смыслу, написана дважды разными способами один разработчиком. Не потому что у него биполярка, просто
когда utils разрастается, там реально хер что найдешь 🙂
👍
15
💊
7
🔥
6
❤
5
286
09:52
Читать в телеграме
20 декабря 2024 г.
Ставь лайк, если любимый релиз - это вечерний пятничный релиз 🍺
🔥
11
😁
9
❤
5
😱
2
🤯
1
🌚
1
297
17:12
Читать в телеграме
29 ноября 2024 г.
package by feature Упаковка кода

Хотел написать пост про package by feature, но когда начал собирать фактуру, понял, что проблема, которую я хотел обозреть, куда глубже. Поэтому сегодня поговорим про упаковку кода в целом.

На своей практике я чаще всего вижу 2 варианта упаковки кода:

1. Package by type - когда проект состоит из таких папок, как Controllers, Services, Repositories, Entities, DTOs и т.д. Обычный скелетон, который предлагает любой фреймворк.

2. Package by layer - когда проект состоит из папок, как App, Domain, Infra и т.д. Те, кто только начинают практиковать DDD, часто используют этот вариант.

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

3. Package by feature - когда проект делится на фичи: Feature1, Feature2, Feature3 и т.д.

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



А вот какой подход лучше?


Каждый подход хорош, пока кодовая база небольшая.

Package by type -- считаю самым отвратительным способом. Можно сказать, одна фича размыта по 5 или 6 папкам, между которыми приходится постоянно переключаться.

Package by layer -- супер, мы выделили слои, но у нас по-прежнему каждый слой содержит кучу функциональности, файлов и папок. Весь проект просто разделен на технические слои, а не по функциональности.

Package by feature -- код фичи инкапсулирован, но вероятно, фич может быть также много, они могут быть связаны между собой и использовать одни и те же сущности. Разбухает количество shared классов. Также несколько фич может относиться к какой-то определенной зоне функциональности продукта.



Что делать?

Забирать лучшее от каждого подхода.

В DDD есть понятие домена. В рамках такого домена существует своя модель, термины и свои правила. Каждый домен развивается независимо друг от друга. И это хорошая точка для начала упаковки. Таким доменами могут быть, например, billing, catalog, users и т.д. Здесь прослеживается подход package by feature. Домены могут быть простыми и сложными, например, billing может быть очень сложным, включать в себя оплату, выплаты, счета и т.д. И такой домен можно ещё покомпозировать и поделить на поддомены. Продолжаем делить по типу package by feature.

Код домена/поддомена можно поделить по-разному, всё зависит от его сложности. Если домен состоит из пары файлов, то смысла делить вообще нет. Если домен типа support или generic, то можно использовать package by type. Если домен сложный и/или core, то стоит поделить на слои App, Domain, Infra, UI, получив все преимущества чистой архитектуры.

Каждый слой также требует декомпозиции. Возьмем слой Domain, который может быть достаточно большим, классы в нём захочется упаковать по папочкам. И тут снова стоит поделить на фичи. Например, Order, Customer, Product. Не стоит делить по типу: Entity, Repository, ValueObject и т.д. Иначе это снова приведет к тому, что код, относящийся к одной функциональности, будет разделен по разным каталогам.



Комбинация этих подходов к упаковке кода даст хорошо структурированный проект, с независимыми модулями, каждый из которых может применять ту архитектуру, которая будет приносить максимальную пользу для конкретного домена.
🔥
16
✍
4
❤
3
👏
1
368
06:54
Читать в телеграме
Ещё больше в телеграме
Кейсы
Каталог ИМ электротоваров nda

Интернет-магазин в стандартной связке Bitrix — 1C, управление каталогом происходит в 1С, ежедневный обмен между сайтом и 1С, проблема: во время импорта ИМ начинает тормозить, 1С тяжело работать с товарной базой, 1С долго загружает каталог, из-за чего менеджер тратит 15-20 минут на составления одного документа (накладная, акт и т.д.).
Моя задача была провести аналитику, разработать архитектуру, собрать и организовать команду разработки.
Мы внедрили и доработали под нужды клиента PIM, за основу взяли один из продуктов Ensi, адаптировали схемы кафки под проект. Разработали микросервис «Витрина» с использованием elasticsearach, для отображения, полнотекстового и фасетного поиска товаров на стороне интернет магазина. Реализовали отдельный микросервис для импорта товаров из 1С и RAEC.
Результат: загрузка страницы каталога меньше секунды с товарной базой в 1,5 млн товара. Удобный интерфейс управления товаром. Автоматическое масштабирование сервисов при больших объемах обмена товарами между системами. Техническое задание для 1С разработчиков для интеграции с системой PIM.
Роль: Teamlead, Архитектор
Технологии: PHP 8.1, Symfony, PostgreSQL, Kafka, Redis, Grafana, Elasticsearch, Docker, Filebeat, S3, Roadrunner, DDD

Отдел разработки веб-приложений аутсорс-компании

Руководил отделом разработки аутсорс компании с оборотом 50+ млн в год.

HR и рекрутинг

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

Обучил HR-менеджера стеку компании и взаимозаменяемым технологиям.

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

Проработали ограничивающую мотивацию, она включала в себя кодекс поведения, например, где разрешено курить, а где нет и чем это карается, рекомендации по коммуникациям (например, тл, не любят, когда их отвлекают оффлайн, они могли готовиться к собеседованиям или созвону с клиентам, им комфортнее, когда им предварительно пишут в личку), соблюдение порядка на кухне и т.д. Это позволило быстрее адаптироваться новым сотрудникам, а старые сотрудники меньше испытывали дискомфорт от пополнения команды. После этого, мы разработали Playbook, куда вошла ограничивающая мотивация, а также информация о компании, кейсы компании, раздел who is who, вопросы ЗП, больничных и отпусков, FAQ. Что способствовало ещё скорой адаптации новых сотрудников и знакомству с компанией.

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

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

Программа обучения для стажеров

Курировал программу обучения стажеров направление Bitrix:

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

Разработал программу обучения Laravel.

Курировал разработку программы обучения фронтенд-разработчиков React , и запустил 3 потока стажеров.

People management
  • занимался организацией внутренних митапов, выступал сам;
  • разработал систему грейдов и организовал аттестацию сотрудников по защите грейдов;
  • составлял ИПР;
  • проводил one-to-one встречи;
  • отвечал за ЗП и премии;
  • отвечал за мотивацию сотрудников и климат в командах;
  • менторил тимлидов;
  • внедрил roadmap для тимлидов и менторов.
Инженерная культура

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

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

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

Проектное управление
  • занимался построением цикла разработки (прием задач/оценка/сроки/сдача/раскатка/приёмка), внедрял в команды готовые решения Kanban/Scrum, упрощенные и смешанные типы на их базе;
  • занимается генерацией бэклога и его приотизацией;
  • интегрировал клиентов в процесс разработки, чтобы сделать процесс прозрачнее, помогал с продуктовой стратегией как технический специалист, участвовал в составлении роадмапа продукта;
  • управлял рисками проектов;
  • занимался подбором команды под проект.
Продажи
  • участвовал в пресейлах, составлении сметы, изучение требований и рисков;
  • составлял роадмап проекта;
  • занимался подготовкой коммерческого предложения и проводил его защиту;
  • внедрил систему критериев оценки лидов;
  • развивал аутстаф канал, общение и знакомство с партнерами, подбор разработчиков.
Экосистема аутсорс-компании

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

Корпоративный портал

Корп. портал предоставлял функционал для управления списками сотрудников, создание учетных записей сотрудников при найме, и блокировки при увольнении; интеграция с Yandex360 для создания корпоративной почты. На базе Btirix 24 оцифровал бизнес-процесс для стажировки разработчиков в компании, включал в себя автоматическое создание задач, трек времени, контрольные точки и сбор метрики для повышения качества стажировки, интеграция с gitlab для автоматического создания шаблонного репозитория стажера. Основной функционал реализован на базе Bitrix 24. Мы с командой придумали как внедрить React-компоненты в стандартные шаблоны битрикса, это позволило нам получать обновления битрикса без проблем. Проектом занималась команда из 4 человек: Тимлид, два Backend и один Frontend разработчики. Ну и я пятый, в качестве Product owner.

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

Технологии: Bitrix24, ReactJs

Outstaff направление
  • я спроектировал микросервис для оформления резюме сотрудников, команда реализовала сервис с помощью laravel + react, в команда было 3 человека: TL, Backend и Frontend разработчики;
  • мы разработали телеграмм-бота, который собирал запросы поиска разработчиков из телеграмм каналов и добавлял задачи в jira. Это помогло аккаунт-менеджеру и сейлеру не пропускать актуальные заявки из большого числа чатов.
Планирование и учет прибыли

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

С командой разработчиком создали MVP планирование на базе Bitrix24.

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

Внедрил SSO на базе Keycloak для всех сервисов компании.

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

Внедрил Outline для ведения документации компании.

Outline/Outline - крутой инструмент для документации, использовали его как для проектной документации, так и для внутренних регламентов.

Внедрил Jira для отдела разработки и сейлеров
YouTravel.me - площадка для организации путешествий

С этим проектом я познакомился в начале своей карьеры, занимался разработкой и сопровождением площадки, работал над локализацией проекта, автоматическим переводом контента через deepl, выполнил интеграцию телефонии Vox Implement, принимал участие в разработке функционала платежей и мини crm для турооператоров. Разработал интеграцию с MailChimp.
Сегодня я консультирую разработку бекенд части одного из сервисов YouTravel.me. Мы решаем вопросы распила монолита на битрикса, способы коммуникации между сервисами, работаем над качеством проекта. Помогаю подобрать сотрудников и построить крутой skillmap для развития компетенций разработчиков в штате.
Роль: Консалтинг
Технологии: Vue, Laravel, RabbitMQ, Bitrix, MySql, VoxImplant, Stripe, Deepl

Калькулятор расчета пошлин nda

Клиент обратился за помощью запустить MVP для показа инвесторам. Я занимался сбором требований, функциональный и нефункциональных требований, мы с командой разработали прототипы, реализовали базовый функционал и уложились в 2 недели.
Роль: Teamlead
Технологии: PHP 8.1, Laravel, Docker, ReactJs, PostgreSQL

CRM для торговых сетей по продаже бытовой техники и электроники nda

У заказчика две торговых сети и два интернет-магазина. Задача нашей команды была разработать модуль интеграции с интернет-магазинами для обмена данными по B2B сегменту: контакты, заказы, сделки. Все сущности проходили этапы валидации, а компании проверяли в реестре ЕГРЮЛ. Я выступал в качестве техлида, занимался архитектурой модуля, интеграцией с репликой и кафкой. В моменте мы выгрузили около 180к действующих компаний и 800к контактов.
Роль: Techlead
Технологии: PHP, Битрикс 24, Kafkа, MySql

Интернет-магазин электроники, цифровой и бытовой техники федерального уровня nda

Я принимал участие в проекте в качестве бекенд-разработчика, занимался развитием жизненного цикла заказа, системой лояльности покупателей, поддержкой механики скидок, интеграции с CRM и системой управления заказами. Принял участие в разработке API для мобильного приложения. Одна из интересных задач - необходимо было перевести проект с PHP 7.4 на 8.0.
Роль: Developer
Технологии: PHP 8, 1С-Битрикс, RabbitMQ, Kafkа, REST, SOAP, Rector

© Владислав Тимофеев 2026
😎