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)

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

Есть два вида ошибок.

1. Ошибки инноватора.
Когда ошибка, это обратная связь на проверку гипотезы.
«Не ошибается только тот, кто ничего не делает» — отсюда.
Здесь ошибки ожидаемы и приемлемы и должны превращаться в lessons learned.

"Failure is an option here. If things are not failing, you are not innovating enough" — Elon Musk pic.twitter.com/5tc7yGFAOd

— Curiosity (@MAstronomers) September 20, 2024

2. Ошибки плохого исполнения (Bad execution).
Например, не сданная вовремя платёжка или отчет. Не сделанный или не проверенный бекап. Там, где нет неизвестности и ожидается безупречное исполнение.
Здесь ошибки неприемлемы.

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

— Что делать?
— Выяснить причину.
— Как?
— Спросить человека напрямую!

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

Если инструкции кривые — переписать, точнее, пусть сам и перепишет понятно.

Если сотрудник перегружен — разобраться, что там за аврал, почему он возник и решить эту проблему

Если не хочет (!) — выяснить в чем причина и найти способ чтобы сам захотел.

Вопрос со звездочкой, кстати. Что нужно, чтобы сотрудники сами хотели?

Наконец-то встретил баг на фронтенде, который привел к потерям в $$.

На скриншоте рост костов за Google Cloud Storage за одну неделю.

На одном из проектов предварительный кост за Google Cloud вырос в четыре раза.

Выяснилось: криво поставленный скрипт продуктовой аналитики на сервисе с огромным траффиком вызывал множественные повторные загрузки огромного числа файлов из Google S3.