Адель Шигабутдинов

Про AI-агентскую разработку

Адель Шигабутдинов — Sat, 04 Apr 2026 12:15:50 +0300

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

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

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

Founder-driven AI feature factory.

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

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

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

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

Gemini по-человечески, по-братски!

Адель Шигабутдинов — Tue, 03 Mar 2026 19:41:36 +0300

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

Инженерный подход к оценке сроков: формула вместо гадания

Адель Шигабутдинов — Sun, 04 Jan 2026 17:34:10 +0300

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) должен быть:

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

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

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

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

payment
refund
webhook handling

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

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

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

O(S + C + M + E)

Появляются:

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

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

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

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

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

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

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

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

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

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

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

→ O(P) (кайф)

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

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

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

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

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

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

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 показывает как растёт, а коэффициенты — сколько стоит один шаг.

параметр	значение
base_days	1.0—1.5 дня
days_per_system	0.5—1 день
days_per_currency	0.3—0.7 дня
days_per_method	0.7—1.5 дня
days_per_edge_case	0.2—0.5 дня
days_per_requirement	5-8 дней

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:

Блок	% от development
QA	+30-50%
DevOps / Infra	+10-20%
Product / Docs	+10%

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

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

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

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

k	Архитектура	Человеко-дни	Почему такие цифры
1.0	Без абстракции	60—100	каждое измерение усиливает остальные
0.4-0.5	С адаптером	25—40	переиспользование сценариев и тестов
0.2-0.3	С shared payment core	15—25	линейность по сценариям + конфиг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фактически:

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

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

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

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

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

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

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

Важное для менеджеров

Адель Шигабутдинов — Wed, 31 Dec 2025 09:37:51 +0300

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

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

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

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

Срок — сегодня

Адель Шигабутдинов — Wed, 31 Dec 2025 09:23:23 +0300

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

Пиши код

Адель Шигабутдинов — Tue, 16 Dec 2025 15:38:20 +0300

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

Решение iam.disableServiceAccountKeyCreation

Адель Шигабутдинов — Mon, 30 Jun 2025 18:40:22 +0300

Периодически на разных проектах сталкиваюсь с тем, что у 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:

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

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

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

Коротко о результатах

Адель Шигабутдинов — Tue, 11 Mar 2025 17:39:24 +0300

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

Важное для сениоров

Адель Шигабутдинов — Mon, 04 Nov 2024 09:32:27 +0300

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

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

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

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

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

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

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

Про «волков» — как люди устраиваются на две работы и получается не норм

Адель Шигабутдинов — Sat, 05 Oct 2024 18:36:20 +0300

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

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

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

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

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

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

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

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

Рома Звезда

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

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

Даня Халява

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про ошибки

Адель Шигабутдинов — Fri, 20 Sep 2024 20:26:00 +0300

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

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).
Например, не сданная вовремя платёжка или отчет. Не сделанный или не проверенный бекап. Там, где нет неизвестности и ожидается безупречное исполнение.
Здесь ошибки неприемлемы.

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

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

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

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

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

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

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

Влёт в облака

Адель Шигабутдинов — Fri, 20 Sep 2024 19:11:36 +0300

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

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

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

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

Про стресс и продуктивность

Адель Шигабутдинов — Fri, 20 Sep 2024 16:47:29 +0300

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

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

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

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

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

Это очень коррелировало с теми вещами которые я до этого писал про выгорание (Burnout).

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

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

Как-нибудь я расскажу о совершенно лютом проекте, на котором весь менеджмент и команда разработки набрала в среднем +15-20 кг, заедая стресс.
Проект был крутой, с агрессивными сроками, огромным количеством фич и высокими рисками.

Полезные ссылки
Тест Бойко (Диагностика уровня эмоционального выгорания)

Как не коммитя и не теряя изменения переключиться на другую ветку Git.

Адель Шигабутдинов — Fri, 13 Oct 2023 09:17:48 +0300

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

Бывает удобно, когда нужно быстро пофиксить баг и вернуться.

1. Способ через git stash

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

Вот шаги:

Сохраните изменения с помощью stash:

git stash

Переключитесь на другую ветку:

git checkout [имя_ветки]

Если вы захотите вернуть свои изменения на текущей ветке, используйте:

git stash apply

Если у вас несколько сохраненных изменений в stash, вы можете увидеть список всех stash с помощью:

git stash list

И применить конкретный stash с помощью:

git stash apply stash@{номер}

Учтите, что `git stash apply` применяет изменения, но оставляет их в stash. Если вы хотите применить изменения и удалить их из stash, используйте:

git stash pop

2. Способ через git worktree

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

Добавление новой рабочей директории для другой ветки

Например, вы работаете над функцией в ветке `feature-x`, но вам также нужно срочно внести изменения в `master`.

git worktree add ../worktree-master master

Это создаст новую рабочую директорию `worktree-master`, где активной будет ветка `master`.

Создание новой ветки в новой рабочей директории

Если вы хотите начать работу над новой функцией и хотите, чтобы у нее была своя рабочая директория:

git worktree add ../worktree-feature-y feature-y

Если ветка `feature-y` еще не существует, она будет создана автоматически.

Просмотр списка рабочих директорий

git worktree list

Это покажет вам все текущие рабочие директории и их связанные ветки.

Удаление рабочей директории
Если вы закончили работу в дополнительной рабочей директории и хотите ее удалить

rm -rf ../worktree-feature-y
git worktree prune

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

3. Самый не технологичный способ: сделать клон проекта в соседней дирректории

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

Немного про Agile и Agile Manifesto, качество, бюджет, сроки

Адель Шигабутдинов — Sun, 01 Oct 2023 07:36:50 +0300

Интересный факт, что в 12 принципах лежащих в основе Agile, пункт про техническое совершенство идет четверым с конца. Даже развернулась небольшая дискуссия в Linkedin на этот счет.

Если читать их по порядку, может сложиться представление, (в духе манифеста) что несмотря на то, что мы ценим нижние 4 пункта, верхние четыре мы ценим все-таки больше. Так ли это?

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

(попалась картинка в тему)

Agile Manifesto очень гибко обходит вопросы сроков и бюджетирования, так что вот два обоснованных мнения на этот счет от ChatGPT:

A. While there is value in meeting deadlines, we value technical excellence more.

By emphasizing technical quality, we ensure the foundation for resilient and adaptable solutions. A fixation on deadlines might risk the integrity and sustainability of our work. We believe that by striving for excellence today, we reduce the risk of future setbacks and rework, leading to better outcomes in the long run. Even in the face of time constraints, our commitment to quality remains paramount.

B. While there is value in technical excellence, we value meeting deadlines more.

In a rapidly evolving environment, delivering on our commitments in a timely manner ensures trust, momentum, and immediate value. Technical quality is vital, but we believe that it should not compromise our ability to meet the expectations set with our stakeholders. Balancing excellence with timeliness, we ensure both immediate impact and a foundation for continuous improvement. In our journey, the punctuality of our deliveries stands at the forefront.

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

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

Автомобиль не начинается со скейтборда

Адель Шигабутдинов — Sat, 03 Sep 2022 19:51:40 +0300

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

Здесь две проблемы:

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

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

Мы всегда идем от автомобиля. Он должен быть самым простым, хоть как повозка на колесах, но это всегда автомобиль, на каждом шаге.
Вот правильная картинка про Agile:

Reference: Allen Houb

Переболевшим Agile

Адель Шигабутдинов — Sun, 28 Aug 2022 14:06:26 +0300

Наткнулся на блестящий комментарий к видео с беседой о проблемах скрам и том почему аджайл все-таки не работает. Если нет времени смотреть все 1.5 ч интервью:

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

Пост про ошибки в платежных системах

Адель Шигабутдинов — Wed, 24 Aug 2022 09:09:34 +0300

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

Ссылка на хабр: 20 лет проблем приема платежей

Документ по GDPR

Адель Шигабутдинов — Wed, 24 Aug 2022 09:02:30 +0300

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

Скачать документ

О монолитах

Адель Шигабутдинов — Sat, 30 Jul 2022 14:52:00 +0300

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

Пара статей по этому поводу, не теряющих актуальность на сегодняшний день
https://m.signalvnoise.com/the-majestic-monolith/ от 2016г
https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ и от 2020