Бережливое производство.
#мысль #бутылочное_горлышко

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

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

Для такой равномерной работы я применяю принцип который я условно называю заглушечное програмирование.
Идея в том, чтобы в каждый момент времени была работающая программа. Понятно, что по началу это будет просто одна заглушка. Даже Hello world.
Потом мы эту заглушку усложняем, то есть делаем хорошо очерченную небольшую задачу (от-SMART-ованную). Дыра , которую закрывала заглушка, при этом превращается в несколько более мелких дыр.

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

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

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

Ораторское искусство, ключевые задачи и KPI.
#бутылочное_горлышко #kpi #история

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

В частности, я много слышал про ораторское искусство, и что что полководцы перед битвой давали речь, и она помогала воевать. Оказалось, что так и есть, но смысл был не в витиеватых выражениях, а в том, что полководец четко формулировал ключевую задачу перед боем и выставлял KPI ключевым участникам (или давил на нужные психологические кнопки). Варианты были например такие (цитирую по памяти, так что немножко напеваю Карузо):

1. У врага очень сильная конница и нашей коннице будет тяжело. Сейчас решается судьба Рима. Вы должны продержаться несколько часов, пока пехота не сделает свое дело. Если хотя бы кто-то дрогнет всё посыпется. Помните, что вы защищаете честь Рима. Отличившиеся сегодня прославят свой род на сотню лет.

2. Враг нас боится, главное его побыстрее сломить, венок тому коннику (патрицию), кто первый добудет флаг врага.

3. Мы долго воевали, и мы знаем, что пехота (плебеи) сильно устала и не успела заниматься хозяйством (обеднела). Удвоенная доля добычи пехоте.

4. Этот город нас предавал, лишний день на разграбление.


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

По сути, это соответствует «формуле изобретения» в заявке, или «описании стартапа в одной строке» или просто постановке задачи.

#ии #кейс
Я форсирую, чтобы народ максимально использовал chat боты в работе.
А они пользуются редко, да и я сам не часто. Выявили два критерия, которые мешают:

1. Проверяемость задачи.
Задачи для чатбота должны быть хоть и простенькими, но еще легче проверяться.
Например человек просил написать набор линейных ограничений чтобы если есть 3 дискретные переменные x1 x2 x3 то надо сделать так, чтобы переменная y была равна 1 если хотя бы одна из x1, x2,x3 равна одному.
Чат-бот радостно делает очень похожие но не верные варианты.
Тут я посоветовал сразу же просить сделать таблицу истинности для задачи и для решения, которое предлагает сам чат бот. По такой табличке проверить будет уже гораздо легче.



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

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


P.S. Кстати такая несимметричность - проверить проще чем сделать штука интересная и проявляется в других сферах жизни. В математике соответствует NP-полноте, а в жизни искусству.

#выступление
Попросили выступить для NoML community @noml_community. 9 октября буду выступать рассказывать про алгоритм огранки бриллиантов. Чего-то теряются записи выступлений, там по идее останется. Выложу позже сюда.

#текучка
Перешел на работу по тикетам, даже в мелких проектах. Формально, чтобы навести порядок, что очень полезно. А на самом деле ради кайфа, когда ты тикет закрываешь.😍

Автоматизированные тесты пока в только крупных проектах. Но тоже надо бы :)

Про протечку абстракций и високосную секунду.
#история
Недавно писал про протечку абстракций. Напишу одну прохладную историю о протечке, которая случилась в моем прошлом стартапе.

Мы делали систему расписаний для пилотов авиакомпаний, с парком порядка 10-20-50 самолетов.
Система вполне хорошо работала для 10-20 самолетов (это где то 300-500 пилотов и до тысячи бортпроводников).

Когда к нам приходили на тест компании покрупнее наш код начинал тормозить. И приходилось расшивать тормозные места. Саму модель ЦЛП мы вполне эффективно улучшали по мере необходимости. Но в конце концов уперлись в сам питон, который очень медленный язык программирования.

В итоге мы созрели и стали переходить на pypy то есть на компилированный питон. Для этого надо было, чтобы все модули компилировались на pypy. Мы заменили все неподходящие модули кроме одного – datetime. Оказалось, что он на pypy не компилируется. Хотя казалось бы, что сложного во времени. Стали разбираться и ужаснулись.

Не буду останавливаться на часовых поясах и на других очевидных сложностях, а просто поговорим о сутках и годе.
В юниксе время считается количеством секунд от 1970 года до текущего момента. Например, 12 сентября 2024 года 10:00 это 1726124400 секунда. И чтобы перегонять время туда-сюда, надо знать и все високосные дни с 1970 года.
Все знают про високосные дни и про отличия Юлианского и Григорианского календарей. В Юлианском календаре високосный год был каждые 4 года.
В Григорианском високосный год каждые 4 года, но пропускается каждые сто лет, но делается каждые 400 лет. То есть в 1900 был обычный год, а в 1996 и 2000 високосные.
За пару тысяч лет разница набежала в 2 недели. Юлианский всё-таки неточный.
Для современных нужд уже григорианский недостаточно точен. Поэтому помимо високосных дней ввели, так же високосные секунды. Они добавляются с 1972 30 июня или 31 декабря.
Так что теперь не только в сутках бывает не 24 часа, но и в минуте может быть не 60 секунд. Это значительно усложняет код и замедляет его работу.

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

Понятно, что это все создает сложности при создании модуля и синхронизации различных часов между собой. ГЛОНАСС когда-то от этого падал, GPS работает по своему времени, отличающемуся на 19 секунд и т.п.
А питон получил медленный и некомпилирующийся модуль datetime.
Мы пришли к выводу, что при необходимости мы сделаем свою версию этого модуля, где время будет загрублено до 5 минут (этого достаточно для наших нужд). После чего он и сам по себе станет быстрее работать и сможет компилироваться через pypy.
Крупных клиентов с живыми данными на горизонте не было, потому руки до этого не дошли, но мы были близки.

Вот такая протечка абстракций. Расчет расписания пилотов упирается в плохой прогноз землетрясений.

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

Пара клиентов.
#бизнес #размышления

Одному сделали два проекта. Денег еще не видели, я начал делать проекты раньше заключения договора (потому что срочно). В договоре были пункты, по которым я денег вообще могу не увидеть. Если в первом еще могут быть претензии, то по второму я четко и быстро сделал все что нужно. Теперь жду денег.

Второй клиент предложил оплатить этап до его формального окончания. Очень в кассу.

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

1. Торопиться и работать без договора я больше не буду.
2. Надо внимательно следить за репутацией клиента. Репутация первого клиента была мне известна.
3. Как проводить ABC сегментацию клиентов тоже понятно.

У нас неделя искусственного интеллекта.
#текучка #ии

Во-первых, стартовал микропроект с использованием ИИ. До этого мы только ТЗ формировали и проекты ждут в очереди. Но скоро таких проектов будет больше.

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

Язык R очень удобная штука. Задачи которые на нем надо решать понятны как и методы. А сам язык незнаком. В результате удобней писать запросы в чат бот, час писать код самому. И я так освоил чат бот и вот сотрудник пошел. А сейчас я и на питоне активно уже использую ИИ.

#мысль #ии
Заказчики попросили посмотреть один проект, работает или нет. Результатов еще не увидел но и так понятно, что не сработает. Просто потому что задача в проекте решается неверным способом.
Там просто спрашивают чатбот: отсортируй некоторый список по критерию важно/не важно. При этом обучающая выборка не передана, то есть критерии что именно важно или не важно чат бот просто не знает.
Да и если передавать, там чат бот будет лишним звеном излучающим шум. Лучше бы просто статистическую модель запилили. Две ключевые ошибки.

Под каждую задачу надо сначала понять, каким методом её делать.

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

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

Анализировал свою ценность в проекте. И она получается вообще не связана с объемом работ, которые я делаю. И даже наоборот есть обратная корреляция. То есть, самое ценное, что я делаю - понимаю каким путем идти и время от времени придумываю хорошие идеи (или подхватываю предложенные хорошие идеи других).
Штука рандомная, но важная.
Надо будет думать, как в других проектах с учетом этого выставлять и объяснять стоимость работ.
Видимо, надо просто брать какую-то величину на моё кураторство в проекте просто ни почему. Размер этой доли должен зависеть от объема исследовательской составляющей в проекте.

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

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

Я был вундеркиндом и математику загружал в голову в бешенной силой еще с детского сада. И потому я сразу вижу математику, в том что говорит заказчик, и какой метод сработает или нет.

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

#выступление
Буду сегодня выступать, приходите послушать кому интересно.

Семинар про огранку бриллиантов

▫️ 9 октября (среда), 17:00 МСК
▫️ Подключение→

Выступает: Алексей Тарасов (к.ф.-м.н., Разумное Расписание)

Тема: Алгоритм огранки бриллиантов на основе методов нелинейной оптимизации

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

Уровень сложности: средний, ключевые слова: мат. моделирование, нелинейная оптимизация, IPOPT.

Если кому интересно, то прямо сейчас идет магнитная буря и видно полярное сияние вплоть до Ростова. В Москве по идее тоже должно быть видно. Облачность низкая. Главное отъехать куда то в темное место и можно увидеть.
UPD. Облачность все таки достаточно высокая.

Готова запись про алгоритм огранки алмазов с выступления в сообществе NoML

Запись семинара

Алексей Тарасов, Алгоритм огранки бриллиантов на основе методов нелинейной оптимизации. YouTube | Дзен | RuTube (~1 час 20 минут).

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

Заказчик отказался.

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

Наконец-то. :)

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