Наконец сформулировал то, что наблюдаю, когда продакты, менеджеры, даже CEO и фаундеры массово засели за claude code, codex, cursor и неистово вайб-кодят свои продукты.

Сбылась мечта: виртуальная команда, которая работает как feature-factory. Только то, что нужно бизнесу, только функционал который нужен, сразу, быстро и без нытья. Никто не ноет про технический долг, не просит остановиться и сделать рефакторинг. Не боится переработок и стоит почти бесплатно. А главное — никто, никто не сопротивляется воле и повелениям Творца!

Модель с промптом «ты крутой аналитик» ставит задачи агенту с промптом «ты senior backend разработчик» и она же с промптом «ты qa» проверяет. Великолепный театр!

Founder-driven AI feature factory.

Идеально для прототипов. Но  где догонит реальность?

А, ну да. Надо же добавить Агента с промптом «ты неудобный сеньёор и токсичный критик».
Деплой.

Пособираю сюда ссылок на истрии:

1. https://www.reddit.com/r/founder/comments/1s8ie9a/a_startup_founder_showed_me_his_mvp_today_and_he/?share_id=_j5uYaTtjUXQ0vAk5JiG1

Под руководством Gemini по-ошибке потратил TRX на 120$ на коммиссиях сети

Cпособы оценки и планирования проектов, которые сложились в индустрии софтверной разработки для планирования: стори-поинты, футболки и числа Фибоначчи хороши для тактики (планирование на 2 недели вперед), но не подходят для стратегии (сколько денег готовить на проект длиной в квартал).

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

Что, если подобный подход переложить на наши прикладные инженерные задачи?
Здесь O(…) — не алгоритмическая сложность в строгом CS-смысле, а способ описать структуру роста инженерных усилий.

Например: подключение нового эквайринга в существующую систему продажи авиа-билетов.

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

1. Основные параметры:

• P — количество платёжных сценариев
  (payment, refund, partial refund, cancel, chargeback, webhook retry и т. д.)
• C — количество валют
• M — количество методов оплаты
  (cards, Apple Pay, Google Pay, local methods, installments)
• S — количество системных интеграций в нашей системе
  (billing, orders, tickets, ledger, AML, notifications, analytics)
• E — количество edge-cases (timeouts, double spend, idempotency, retries)
• R — количество регуляторных/комплаенс-ограничений

2. Попробуем записать инженерную сложность в виде O-нотации:

O(P × (S + C + M + E) + R)

Так как каждый платёжный сценарий (P) должен быть:

1. встроен во все системы (S)
2. проверен по валютам (C)
3. поддержан по методам оплаты (M)
4. защищён от edge-cases (E)
5. соответствует регуляторным/комплаенс требованиям (R)

Часто R = 0, но иногда это большая константа, например 3DS/SCA/PCI DSS

3. Минимальная граница сложности:

Невозможно подключить эквайринг не реализовав хотя бы:

• payment
• refund
• webhook handling

O(P) — абсолютный минимум

4. Структурная сложность

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

O(S + C + M + E)

Появляются:

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

Если всё сделано правильно:

• O(1) на транзакцию
• O(n) в логах и аудите

Почему это вообще важно?
Потому что это дает ответы на вопросы: сколько времени мы будем это делать? → Time / effort
И насколько это усложнит систему навсегда? → Space / state

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

4. Зависимость от текущей архитектуры

При плохой архитектуре трудозатраты могут зависеть от сочетаний параметров (например, сценариев × сервисов × валют), что увеличивает рост усилий:

O(P × S × C) (реально больно)

Например, если нет абстракции платежей, логика размазана по сервисам, эквайринг «вшивается» напрямую (скорее всего программисты воют об огромном техническом долге)

Каждый новый эквайринг в этом случае — это комбинаторный рост потенциальных конфликтов/интеракций между компонентами.

При хорошей архитектуре, наоборот

→ O(P) (кайф)

Если система изначально строилась для поддержки разных эквайрингов, имеется абстрактный платёжный адаптер или применяется strategy pattern, то добавление ещё одного эквайринга:

• O(P) по бизнес-логике
• O(1) по остальной системе

ПРИМЕНЕНИЕ НА ПРАКТИКЕ

Для бизнеса важны только ответы на два вопроса:

1. Сколько времени займет
2. Сколько будет стоить

Попробуем применить нашу формулу

O(P × (S + C + M + E) + R)

Где:
P — платёжные сценарии
S — системы интеграции
C — валюты
M — методы оплаты
E — edge-cases
R — регуляторные/комплаенс требования

Математическая функция O(…) показывает структуру сложности. Чтобы превратить её в сроки, нам нужно добавить весовые коэффициенты (сколько в среднем занимает одна интеграция).

В инженерной практике это превращается в аддитивную модель трудозатрат:

Total_days =
P × (
base_days
+ S × days_per_system
+ C × days_per_currency
+ M × days_per_method
+ E × days_per_edge_case
) + R × days_per_requirement

Функция O показывает как растёт, а коэффициенты — сколько стоит один шаг.

R-добавки для платежей это:
3DS / SCA → +5—10 дней
delayed capture → +3—5
split payments → +5—8
local compliance → +5—15

Считаем человеко-дни

P (payment scenaries): payment, refund, partial refund, webhook reconciliation = 4
S (systems): orders, tickets, billing / ledger, notifications, analytics = 5
C (currencies): EUR, USD = 2
M (methods): cards, Apple Pay = 2
E (edge cases): retry, timeout, idempotency, duplicate webhook, partial capture = 5
R (regulatory): SCA, Split payments = 2

Калькуляция трудозатрат:

1.Базовая реализация (P=4 сценария):

• Сами сценарии: 4 × 1.2 дня = 4.8 д.
• Интеграции (S=5): 4 × 5 × 0.8 дня = 16 д.
• Валюты (C=2): 4 × 2 × 0.5 дня = 4 д.
• Методы (M=2): 4 × 2 × 1.0 день = 8 д.
• Edge-cases (E=5): 4 × 5 × 0.3 дня = 6 д.

2.Регуляторика (R=2 требования):
-SCA + Split payments: 2 × 7.5 дней = 15 д.

Итого: 4.8 + 16 + 4 + 8 + 6 + 15 ≈ 54 человеко-дня

Итого получается
📌 ≈ 11 календарных недель одного инженера
📌 ≈ 6 недель для команды из 2—3 человек

Это только на разработку, но когда мы говорим про продакшен-решение нельзя забывать добавить QA и DevOps:

Итог 54 × 1.6 ≈ 86 человеко-дней до продакшена

Что реально уменьшает стоимость изменений в деньгах

Добавим коэффициент эффективности k (расширяемости) нашей архитектуры системы

T = k × P × (S + C + M + E)

Формула остается той же но коэффициенты падают в 2—3 раза.

Что именно снижает коэффициент (k)

1. Без абстракции (60—100 дней)

Почему k большой:

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

Каждое измерение — будь то системы (S) или валюты (C), методы (M) или edge-кейсы (E) → коэффициент растёт.

2. С адаптером (25—40 дней)

Что меняется:

• появляется интерфейс PaymentProvider
• маппинг статусов и ошибок локализован
• сценарии P переиспользуются

Что НЕ решено полностью:

• state machine может быть не единой
• идемпотентность иногда “дырявая”
• ledger/analytics всё ещё знают лишнее

коэффициент падает примерно в 2 раза.

3. Shared Payment Core (15—25 дней)

Это ключевой момент.

Что происходит архитектурно:

• есть одна state machine
• есть один источник истины
• все сервисы работают по событиям
• эквайринг — чистый адаптер

Фактически:

• S почти исчезает из формулы
• C и M становятся конфигурацией
• E решаются централизованно

формула по факту становится ближе к: T ≈ k × P, все зависимости по-прежнему существуют, но коэффициенты при них близки к нулю. Это и есть цель любой инженерной команды — сделать так, чтобы стоимость новой фичи зависела только от её бизнес-сути (P), а не от сопротивления старой системы

Итого: Что этот подход дает бизнесу и менеджменту

1. Математическое обоснование сроков. Вместо гадания на кофейной гуще мы получаем прозрачную формулу. Если задача занимает 80 дней — это не потому, что разработчики медленные, а потому что у нас S = 5 (много интеграций) и R=2 (сложная регуляторика).

2. Цена архитектуры становится осязаемой. Мы наконец-то можем в деньгах оценить стоимость «плохого кода». Плохая архитектура — это коэффициент k = 1.0, хорошая — k = 0.3. Инвестиции в платформу (Shared Core) снижают стоимость каждой следующей фичи в 3 раза.

3. Калькулятор вместо абстракций. Эту модель можно превратить в простой Excel-калькулятор. Менеджер может сам прикинуть: «Если мы добавим еще одну валюту (C), срок вырастет на X дней». Это переводит разговор в конструктивное русло.

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

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

А. Объем работы
Б. Срок исполнения

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

Прочитав данное сообщение вы прошли краткий курс подготовки по программе PMI PMP.

1. Долго думать перед тем как взяться дело — бывает полезно.
2. Иногда по результатам раздумий не браться за дело — весьма разумно.
3. Некоторые цели и задачи закрываются сами собой, нужно только ждать и ничего в связи с этим не предпринимать. С некоторыми так не работает.
4. У некоторых людей работает долгосрочное планирование, а у некоторых оно отбивает охоту действовать, все разные.
5. Моя жизнь управляется Google-календарем. Всё, что в него внесено, происходит с гораздо большей вероятностью, чем то, что туда не попало. Остается только выбирать, чем его наполнять.
6. Самая действенная схема краткосрочного и результативного планирования.

Интересно, что сейчас, в эпоху post-agile, когда все перестали использовать ритуалы scrum и повально канбанизировались, этот текст выглядит опередившим свое время лет на десять:
https://evil-frees.livejournal.com/290185.html

Периодически на разных проектах сталкиваюсь с тем, что у Google Cloud заблокировано создание Service Accounts. Проблема с iam.disableServiceAccountKeyCreation

Выходит сообщение:

Troubleshooting URL: console.cloud.google.com/iam-admin/troubleshooter;permissions=orgpolicy.constr
Missing permissions: 
    orgpolicy.constraints.list 
    orgpolicy.policies.list

Ни одно из решений через интерфейс Google Cloud не срабатывает.

Есть решение через Google Cloud Console:

1. Выбрать проект
2. Вызвать Google Cloud Console

3. Выполнить две команды:

cat > key-creation.yaml << ENDOFFILE
name: projects/$(gcloud config get-value project)/policies/iam.disableServiceAccountKeyCreation
spec:
  rules:
  - enforce: false
ENDOFFILE

gcloud org-policies set-policy key-creation.yaml 

rm key-creation.yaml

«У корпоративного самурая нет результата, есть только процесс».

Очень давно писал про вопрос-индикатор на собеседованиях «Два раза вовремя или один раз правильно?».

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

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

Если человек постоянно называет сроки, а потом они постоянно съезжают, человек — балабол (человек, дающий пустые обещания). Постоянно подводит, верить ему — нельзя.

Работать с такими не хотят. Промоутить таких не хотят. С таким работают, с отношением «так уж и быть» — просто терпят.

Почему так?
Да если до сих пор не очевидно, по тому, что на твоем слове я даю свои обещания.
А на моих обещаниях дает свое слово мой шеф. А уже на них и владелец компании.
Поэтому когда/если, это все начинает сыпаться, все бегают с «раскаленной кочергой». Потому что если не деливеришь то, что обещал — вся компания пойдет с рынка.

Короче, когда работаешь — будь молодцом!

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

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

У меня есть несколько историй.

Колян, просто Колян

Лет десять назад в одном финтех-стартапе была очень молодая и задорная команда. Все работали в офисе, в редкие дни кто-то подключался и работал из дома. Работал там залихватский джун-Николай, который брался за всё что ему дают, усердно трудился. Иногда давал неплохой результат, а иногда получалась полная фигня, но в целом — терпимо. Работал он иногда из офиса, иногда из дома, бывало что пропадал из чатиков в течение дня на несколько часов, но потом объявлялся.

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

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

Так что Колян делал это, еще тогда, когда это не стало мейнстримом.

Рома Звезда

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

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

Даня Халява

Даниил, молодой, талантливый студент, прошел интервью у рекрутера, у технического менеджера команды и меня на позицию Manual QA. Рассказал, что пару лет работал в беттинге, но не захотел переходить на новый проект по моральным принципам.
Очень быстро думал. Ответил на массу заковыристых вопросов, о том как тестировать финансовые приложения, великолепно разложил все корнер-кейсы по представленным примерам. Показал свой годовалый профиль на leet-code с кучей решенных задач. Порадовались, что наконец-то пришла свежая кровь (зумер!) с головой на плечах.

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

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

Денис-Тройничок

Денис — зрелый разработчик, пришел на собеседование к нам, объясняя тем, что не сработался с коллегами в каком-то НИИ. Плюс вел курсы по программированию в ВУЗе. Наше собеседование прошел на высоком уровне и достаточно легко, очень понравился команде. За месяц вкатился в сложный проект, закрыл пять задач среднего размера. А потом позвонил мне и сказал что увольняется, т. к. не вытягивает. Оказалось, что он не уволился не только с предыдущей работы, выходя к нам. Он не уволился и с еще более ранней компании, т. е. у парня было три работы! :-)

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

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

1. Необъяснимое снижение (или изначально низкий) перформанс — долгие сроки исполнения, низкое качество работы

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

3. Нестандартное время активности и использование рабочих инструментов — раннее утро/поздний вечер/выходные/ вне рабочего времени

4. Перекрёстные чаты — ошибки пересылок сообщений, то, что должно было быть переслано в одну компанию, отправляется в другую. Или не тем людям/не в те чаты.

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

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

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

Когда работа на две компании всё же может быть приемлемой и этичной

1. Если сотрудник открыто информирует обе компании о своих намерениях работать в фулл-тайм или частично в двух местах и получает разрешение от обеих. У нас было несколько случаев, когда хорошие специалисты «уходили за мечтой» в другие компании, при этом оставаясь парт-таймить у нас. И да, их новая компания была изначально в курсе этих договоренностей.

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

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

Чего делать с «волками» и как от них защищаться?

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

2. Использовать договора о неразглашении (NDA), трудовые договора с положениями о раскрытии параллельной занятости. Не факт что помогут, но разумные люди могут сообщить что работают в другом месте. Или не смогут принести трудовую книжку, так как она лежит на предыдущем месте работы!

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

4. Использовать тайм-трекеры, просить фиксировать время работы над задачами и отслеживать активность вне рабочих часов (в рабочих чатах, таск-трекерах, репозиториях, серверах).

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

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

7. Некоторые компании ввели запрет на удаленную работу. Работать из офиса на сторонние проекты — крайне сложное мероприятие.

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

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

— Юридические (нарушения условий договора, конфликт интересов между компаниями)
— Риски по достижению долгосрочных целей компании (если спец сфокусирован на сторонней работе, а не на интересах работодателя)
— Влияние на командную работу (коллегам, возможно, придется компенсировать недостаток вовлеченности сотрудника)
— Возможные последствия для карьеры и репутации специалиста (ладно я про них просто так написал, а мог бы и ссылки на Linkedin приложить)
— Качество жизни (может просто не остаться времени на личную жизнь, семью или отдых)
— Выгорание и стресс (в следствие невозможности поддерживать здоровый work-life balance)

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