Записки системного архитектора

в прошедшую субботу мы с Алиной закончили очередной курс по нашей методике бизнес-анализа с добавлением ИИ

курс резко вырос в объёме с 8 до 16 часов, но всё равно было видно по участникам, что нужно больше времени, поэтому будем выходить на 24 часа

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

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

у нас конечно другой подход, поэтому зашло не всем и до конца курса из 10 человек доплыли только 7.

напомню основные онтологические позиции нашего курса:

1. бизнес-требования — это НЕ цели конкретной инициативы (как у Вигерса и в BABOK) и само собой не любые высказывания, которые говорит «бизнес», а утверждения о свойствах бизнеса, включая его части, которые выдвигают уполномоченные организации и люди:

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

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

в) требования к участникам деятельности (оргролям) — «менеджер по продажам должен связаться с клиентом после получения заявки». авторы: владельцы процессов, эксперты-технологи. источники: рабочие инструкции, регламенты бизнес-процессов

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

3. в проекте по улучшению ситуации на каком-либо участке бизнеса должны изучаться и приниматься во внимание все бизнес-требования, относящиеся к участку (15-30-50 требований), а не только цели изменений

4. важнейший источник потенциальных требований к решению — потребности исполнителей. в ответ на требования, которые предъявляет к их роли организация «логист должен планировать маршрут грузоперевозки» эксперт-технолог бизнес-процесса вместе в исполнителями может предложить технологию работы, а из неё уже конкретные потребности «логисту нужно видеть список подходящих под условия заказа маршрутов, чтобы выбрать целевой. при этом это не «пользовательские требования», тк пользователи как таковые не вправе требовать ничего сверх того, что им уже обещано в законах и договорах. это скорее идеи о необходимых свойствах решения, но сформулированные на языке информации и данных, а не на языке функций и интерфейсов.

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

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

подробнее можно почитать у Алины в статье про её методику ЛЮСТРА

#пилоты #курсы

цитата

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

Интересно. Буквально недавно думал на эту тему, похожие мысли возникали.
https://t.me/mtsepkov/959

Пошли в вестибюль, сделаешь мне кастдев

При проведении кастдевов для нашего обучения выяснилось, что некоторым опытным инженерам непонятны наши тексты с описанием курсов, поскольку они написаны жаргонно, как будто для тех, кто уже “в теме”, а не для тех, кто хочет стать “в теме”. Поэтому я решил написать несколько заметок про темы, которые мы сейчас “качаем” благодаря сотрудничеству с Мишей Курмаевым: производительность бекендов и телеметрию. Начнем с заметки с определениями.

Телеметрия — фонарик в тёмном подвале твоего продакшена, помогает найти «неведомую херню» до того, как она найдёт тебя. Сбор, передача и анализ данных о работе системы.
Трейсы — это следы, оставленные запросом по всей системе, чтобы не заблудился и не потерялся в клубке твоих микро-сервисов. Последовательность событий, показывающая путь запроса через систему.
Распределенный трейсинг — это как гео-метка твоего девайса, но для запросов, показывающая, как они путешествуют через все сервисы, не заблудившись и не застряв в пробках. Отслеживание пути запроса через несколько сервисов в распределенной системе.
Спан — это как одна остановка в путешествии запроса, запись в дневнике, где фиксируются время, важные детали и связь с соседними станциями. Одна операция в трейсе, содержащая временные метки, метаданные и связи с другими спанами.
OpenTelemetry — это стандарт для телеметрии (трейсы, метрики, логи). За стандарт OpenTelemetry отвечает Cloud Native Computing Foundation (CNCF) при участии сообщества разработчиков и компаний.
APM — это аббревиатура для Application Performance Monitoring
Основные инструменты, предоставляющие возможности для сбора и анализа трейсов: OpenTelemetry Collector, Jaeger, Zipkin, Signoz, Elastic APM, Datadog APM, New Relic, Lightstep, Honeycomb
Кастдев (Customer Development) — это изучение клиентов и их потребностей.
Вестибюль (“vestibulum” , на латыни означает “прихожая” или “передняя комната”) — входное помещение здания перед основными комнатами или залами. Школьники на перемене мчались в вестибюль делать кастдев.

Сделаем онлайн-встречу про телеметрию на следующей неделе, напишу про это отдельно.

Блокировки при работе с СУБД

Badoo (нынче Bumble, единственный серьезный конкурент Tinder на мировом рынке) когда-то был полноценной социальной сетью. Например, у меня в профайле были сотни фотографий. Лента обновлений была полна всяких событий, по разнообразию совсем не уступающих Фейсбуку, особенно в теперешние времена (кто с кем подружился, что поделал, кого полайкал - с кучей свистоплясок вокруг privacy настроек). И конечно, был мессенжер, и с мессенжером была куча проблем. Мы всё делали на базах, и одна из типичных проблем подобных проектов - битые денормализованные счетчики непрочитанных сообщений. Мы избегали частых операций count и старались все счётчики денормализовать. Бывало, где-то косячили, счетчики начинали биться, а отлаживать большую систему, в которой обновления могут прийти из разных кусков – непросто. Косячили не так чтобы много, и вроде работали достаточно стабильно, но время от времени счетчики всё равно бились. Это не только была наша проблема - хорошо помню минимум два крайне неприятных косяка с битыми счетчиками в Телеграме и мессенжере Фейсбука, на которые напарывался сам как юзер.

Есть несколько способов побороть такие проблемы, и самый простой и прямолинейный - оптимистичные блокировки в начале транзакции (select get_lock(), например). Первая транзакция получает блокировку, а вторая транзакция просто не стартует, тк вначале попытается получить блокировку на уже заблокированй ресурс.

А ещё есть метод оптимистичных блокировок через версионирование. Кажется, мы его использовали редко, хотя метод прикольный. Суть в следующем. Куда-то в базе добавляется версия, и обновление идёт не просто по ключу, а по ключу с дополнительным условием, которое гарантирует, что транзакция изменяет “свою” версию. После обновления можно проверить количество обновленных рядов, и если 0 - обработать эту ситуацию как ошибочную.

Однако, вдумчивый читатель мог насторожиться: у СУБД бывают разные уровни изоляции. И действительно, описанная выше логика не универсальна. Уровень READ UNCOMMITTED рассматривать несерьезно. Если у нас уровень изоляции READ COMMITTED, то оптимистичные блокировки работают, как описано выше: вторая транзакция, которая пытается обновить данные с указанием устаревшей версии, не сможет этого сделать, так как версия уже поменялась. В этом случае никаких ошибок нет, но количество обновленных строк равно 0, и вот эту ситуацию (0 affected rows) нужно поймать и обработать. Но READ COMMITTED default уже не у всех баз, у MySQL в отличие от PostgreSQL, уровень по умолчанию – REPEATABLE READ. А вот если у нас уровень изоляции REPEATABLE READ или даже SERIALIZED, то ситуация совсем другая. На этом уровне движок базы самостоятельно отслеживает конфликты, и просто не даст обновить данные, которые успела обновить другая транзакция. И скорее всего в таком случае вся транзакция откатится, нужно будет её повторять. Поэтому оптимистичные блокировки будут работать по-разному для уровней изоляции READ COMMITTED, REPEATABLE READ или SERIALIZED, и это нужно учитывать.

Пишу не проверяя, так что не является финансовой рекомендацией. Кстати, насчет финансов: именно в биллинге постоянно ловили проблемы с блокировками в MySQL, и там был смешной косяк. Старые версии движка блокировок get_lock() не поддерживали множественные блокировки, но это полбеды. Настоящая беда была в том, что предыдущие блокировки просто сбрасывались молча, что могло приводить к неприятным косякам с деньгами на проде. Мы тогда просили Костю Осипова исправить это поведение, причем я изначально просил Костю не просто пофиксить поведение, но и “пропушить” его в апстрим Оракла, так как самостоятельно поддерживать кастомные сборки базы ну совсем не хотелось. Дело было давно (см. скрин), но с тех пор вроде в MySQL get_clock() работает корректно.

На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".

Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)

Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.

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

Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.

Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.

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

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

И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.

Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.

Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?

Очень интересное наблюдение. Факт, что продуктовая/заказная/внутренняя разработка устроены очень по разному.

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

Вот к примеру. В профессиональной ИТ-среде много внимания уделяется технологиям, инструментарию. Всякие протоколы, базы данных, брокеры и прочие архитектуры. И обучение программистов, архитекторов и даже аналитиков крутится, во многом, вокруг технологий. Это все, безусловно, важно, ценно и полезно. Некорректное или неуместное применение технологий приводит к проблемам и с надежностью, и с производительностью. Иногда мы упираемся в границы возможностей технологии и нам приходиться искать альтернативные решения, в том числе и качественно новые архитектурные подходы. Но, объективно говоря, это все случается довольно редко. Технологический стек и архитектурные подходы задаются на старте проекта и потом довольно долго эксплуатируются AS IS. Какие-то значимые изменения делаются от силы раз в год. А основные проблемы и сложности, которые возникают в повседневной работе, связаны не с технологией, а с пониманием того, что и как должна делать программа, а потом с реализацией этого понимания в коде. А вот про то, как жить с этой повседневной трудностью, толком никого не учат. Потому что это повседневно, "это очевидно", и это, в конце-концов, скучно (по сравнению с тем же System Design-ом). Но влияние на эффективность работы как команд, так и создаваемых ими систем, эта повседневность оказывает чуть ли не большее, чем System Design и архитектура вместе взятые.

Труднее всего объяснять очевидные вещи.
Они же очевидные - что тут объяснять?

Когда я начинал работу в сфере информационной безопасности, мне выдали кучу документации по IBM-овским средствам "по ИБ". Я целыми днями пробивался через многочисленные White Papers, Manual и прочее унылое чтиво. Было ощущение, что там написана какая-то невнятная дичь и муть, было множество подробностей и деталей, а суть ускользала. 🤯
Я чувствовал себя, как крестьяне из анекдота:

На заре коллективизации во вновь образованный колхоз привезли трактор и механик битых пять часов объяснял крестьянам принципы его работы. Закончил, спрашивает: «Вопросы есть?» «Нет, нет, всё понятно» — загомонили крестьяне. А один мужик встаёт и говорит: «Спасибо, всё отлично объяснили, ВСЁ ПОНЯТНО!!! Одно неясно — КУДА ЛОШАДЬ ЗАПРЯГАТЬ?»

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

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

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

Вы конечно можете не думать про архитектуру этого всего. В общем-то, можете не думать и про архитектуру самой системы. 😉 Просто про ИТ архитектуру уже много написано. И рассказано, как плохо и вредно её игнорировать. Но что-то мне подсказывает, что игнорирование архитектуры "всего остального" обладает примерно такими же последствиями. И тоже приводит к образованию Big Ball of Mud в соответствующем месте. Со всеми, как говорится, вытекающими. 💩

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

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

- Разбиение по репозиториям в смысле места хранения кода, управления доступом к коду.

- Разбиение по конструктивным элементам деплоя - контейнерам/сервисам, которые могут быть независимо развернуты в среде исполнения

- Разбиение по функциональным подсистемам, взаимодействующим друг с друг в рантайме. Это одно из самых сложно понимаемых разбиений, поскольку часто границы функциональных подсистем проходят поперек других, более интуитивно понятных разбиений. Для иллюстрации функционального разбиения часто в качестве примера приводят ножницы - тут есть три конструктивные части (два ручколезвия и скрепляющий их винтик), и две функциональные части - режущая и управляющая.

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

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

- В конце концов, разбиение по ограниченным контекстам в соответствии с моделированием бизнес-доменов.

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

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

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

Еще несколько слов про требования к документации, в ответ на комментарий. Действительно, требования к документации не "висят в воздухе", они привязаны к контексту, к цели проекта, продукту, зависят от текущей стадии ЖЦ, объемов инвестиций/финансирования и т.п. Я хотел акцентировать внимание на том, что часто встречающееся требование "полноты" документации бессмысленно и даже вредно.

Вот к примеру, масштабная цель - выпустить на рынок B2E продукт, который будет использоваться в больших организациях и внедряться усилиями интеграторов-партнеров. Какие требования к документации предъявляются? Внедренцы хором говорят - нам нужна полная документация по возможностям продукта. Что это, блин, такое? Продавцы, вы не поверите, говорят те же самые слова. Но имеют в виду совсем другое. Правда, ни одни, ни другие не могут объяснить что именно им нужно.

И вот, чтобы процесс создания документации был как-то связан с заявленной целью, мы вместо неприличных неявных требований, формулируем явные требования к документации. Сначала высокоуровневые, аналог НФТ.

Документация должна быть:
1. Полезна для .... — тут вставляем для кого и чего пишем документацию
2. Своевременна — первый полезный вариант должен быть не позже чем ...
3. Посильна по ресурсам — ограничения на объем и ресурсы, которые можем потратить

ну и так далее, в зависимости от заинтересованных сторон (привет системное мышление и учет интересов ролей/стейкхолдеров) учитываем разные характеристики документации, например размер(например, необходимость уместить документ на одном листочке), доступность онлайн и т.п.

А уже дальше, под каждым пунктом будут прорастать более детальные требования и ограничения - по структуре, формату и т.п.
И тут очень важна прослеживаемая трассировка Цель — характеристика — конкретное требование
Например,

Делаем продукт для B2E
документация должна быть полезна для инженеров внедрения
Нужен документ "Руководство по развертыванию и настройке"
Структура документа: .....
Доступен онлайн
Поддерживает поиск по ключевым словам

все еще #документация

P.S. А если самим требования к документации формулировать лениво - используйте ГОСТы и не жужжите :) Некоторые заказчики так и делают.

Простой #рецепт как делать полезную документацию на основе сценариев:

1. Определиться с адресатами документации - кто, зачем и как будет её использовать. Наивно думать, что пользователям, администраторам и, скажем, продавцам программного продукта нужен один и тот же документ. Это будут разные документы и по структуре, и по содержанию. Хотя, конечно, в них могут быть общие части.

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

3. Составить структуру документа на основе выявленных вопросов и постепенно наполнять документ по этой структуре. Каждый заполненный раздел увеличивает количество ответов на вопросы и тем самым увеличивает полезность документа. И не стоит даже пытаться покрыть документацией все возможные детали - это долго, сложно и невозможно поддерживать.

#документация

Мне видится, что целесообразно делать документацию из двух частей - справочной, содержащей перечисление и описание каких-то элементов системы (функций, экранов, кнопок, методов API и т.п.) и сценарной , описывающей как с помощью продукта решаются пользовательские задачи. Сценарная часть пишется более-менее вручную (сейчас, наверное, можно с помощью ИИ) и ссылается на упоминаемые разделы справочной части, а справочная часть по большей части генерируется автоматически, чтобы поддерживать её согласованность с кодовой базой. Сценарные части для разных категорий пользователей могут быть разные.

Например, когда мы проектировали структуру документации для IdM решений, то выделяли документы для простых пользователей системы, где описывали как посмотреть на свои права и создать заявку на доступ, для руководителей, где описывали как посмотреть права подчиненных и провести сверку, для сотрудников ИБ, где описывали как узнать, кто имеет доступ к определенным ресурсам и т.п. А справочная часть, описывающая главный экран, мастер создания заявки и другие элементы системы, была общая.

#документация

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

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

😭 Нихуя не просто

Ловушка индустрии №1 — думать, что должно быть просто.

«Просто используй golang»
«Просто перейди на микросервисы»
«Просто тебе нужен kubernetes»
«Просто используй фреймворк»
«Просто найми аналитика»
«Просто покрой всё тестами»
«Просто перейдите на kanban»
«Просто подключи left-pad в npm»

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

Просто было в детском саду.
Покушал, поспал, покакал, проснулся.

#сракигорят | Предложка

Судя по реакциям, эта мысль требует пояснения.

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

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

И еще #цитата в тему

Экзамены, сэр, – это чистейшая чепуха, от начала до конца. Если ты джентльмен, так тебя учить нечему, тебе достаточно того, что ты знаешь. А если ты не джентльмен, то знания тебе только во вред.
О.Уайльд, "Портрет Дориана Грея"

превращается в ...

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

Channel photo updated

Пока читал статью, #анекдот вспомнился.

Чувак выпал из окна 20-ти этажного дома. Пролетая мимо 10-го этажа думает: "пока все идет нормально...".

Захотелось перефразировать:

Менеджер начал управлять по #Agile проектом, который сдавать через 20 недель. На 10-й неделе смотрит на диаграммы в jira и думает "пока все идет нормально...".