Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.
Эта формула имеет геометрический смысл: R×π×e,
где R - число требований, число π в этой показывает круг, который нужно пройти для каждого согласования, а число e - скорость, с которой заказчики придумывают новые требования.
При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.
В среднем получается ~8.54, что очень похоже на большинство проектов.
Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...
Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.
Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.
Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:
e^iπ + 1 = 0.
Смысл его прост: если проект долго рос с воображаемыми (мнимыми) требованиями, добавление реального стейкхолдера сводит все предыдущие усилия к нулю...
Эта формула имеет геометрический смысл: R×π×e,
где R - число требований, число π в этой показывает круг, который нужно пройти для каждого согласования, а число e - скорость, с которой заказчики придумывают новые требования.
При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.
В среднем получается ~8.54, что очень похоже на большинство проектов.
Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...
Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.
Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.
Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:
e^iπ + 1 = 0.
Смысл его прост: если проект долго рос с воображаемыми (мнимыми) требованиями, добавление реального стейкхолдера сводит все предыдущие усилия к нулю...
1😁50🔥23🤩1💊1
Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).
Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.
Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:
0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры
Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):
* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.
* Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт).
* Операционная поддержка: так как система включает технику и людей, должно быть две роли — поддерживающая технику и поддерживающая людей. Это может быть служба поддержки и люди, занимающиеся обучением.
2 слой ("содержащая система"):
* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.
* Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях.
* Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан.
* Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер.
3 слой ("широкое окружение"):
* Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта.
Он даже предлагает выделять специальную роль:
* Враждебный агент. Те, кто совершенно точно станут активно вредить или использовать продукт не по назначению. С определенным уровнем хитрости и креативности. Например, вопросы для любого открытого продукта с хостингом пользовательского видео: как вы будете бороться с порно-контентом, а для продуктов с комментариями или отзывами: как бороться с размещением спамерских ссылок.
* Политический бенефициар. Кто получит выигрыш с точки зрения власти, влияния или престижа от создания вашей системы? Мой любимый тип стейкхолдеров. Пользоваться системой они не будут, может быть даже функциональными бенефициарами не будут, а вот власть и влияние их очень интересуют. В государственных организациях (и некоторых крупных бизнесовых) это чуть ли не основной смысл существования некоторых систем, а за контроль над ними ведутся жестокие битвы. Политические бенефициары могут быть и негативными — активно противодействовать созданию систем, или создавать свою альтернативную, или запрещать/затруднять интеграцию. Чем выше вы заходите в управление корпоративными продуктами, тем больше там политики.
* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.
* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)
Вот такая классификация. У меня из головы получилась похожая, напишу следующим постом.
Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.
Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:
0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры
Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):
* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.
* Оператор технического обслуживания: обеспечивает и следит за работоспособностью системы. Требования: наблюдаемость (время поиска неисправности), ремонтопригодность (возможность и время на ремонт).
* Операционная поддержка: так как система включает технику и людей, должно быть две роли — поддерживающая технику и поддерживающая людей. Это может быть служба поддержки и люди, занимающиеся обучением.
2 слой ("содержащая система"):
* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.
* Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях.
* Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан.
* Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер.
3 слой ("широкое окружение"):
* Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта.
Он даже предлагает выделять специальную роль:
* Враждебный агент. Те, кто совершенно точно станут активно вредить или использовать продукт не по назначению. С определенным уровнем хитрости и креативности. Например, вопросы для любого открытого продукта с хостингом пользовательского видео: как вы будете бороться с порно-контентом, а для продуктов с комментариями или отзывами: как бороться с размещением спамерских ссылок.
* Политический бенефициар. Кто получит выигрыш с точки зрения власти, влияния или престижа от создания вашей системы? Мой любимый тип стейкхолдеров. Пользоваться системой они не будут, может быть даже функциональными бенефициарами не будут, а вот власть и влияние их очень интересуют. В государственных организациях (и некоторых крупных бизнесовых) это чуть ли не основной смысл существования некоторых систем, а за контроль над ними ведутся жестокие битвы. Политические бенефициары могут быть и негативными — активно противодействовать созданию систем, или создавать свою альтернативную, или запрещать/затруднять интеграцию. Чем выше вы заходите в управление корпоративными продуктами, тем больше там политики.
* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.
* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)
Вот такая классификация. У меня из головы получилась похожая, напишу следующим постом.
👍30🔥6❤3
Что-то перерывы между постами стали совсем длинными. Надеюсь в ближайшее время вернуться в ритм, и поставлять вам неочевидные приемы и темы, про которые вы вряд ли у кого-то ещё прочтете.
Но сначала продолжение предыдущего поста.
Итак, я сел выписывать список заинтересованных сторон. Требования ведь берутся только от заинтересованных сторон, больше неоткуда.
Получился вот такой список:
💻 те, кто непосредственно работают с системой (пользователи);
🪪 те, кто приводят систему в работоспособное состояние, устанавливая настройки и наполняя контентом (прикладные администраторы);
🎁 те, кто получает пользу от работы системы (заказчики, клиенты);
💸 те, кто выделяет ресурсы и несет риски в связи с созданием и работой системы (топ-менеджмент, инвесторы, юристы, специалисты по безопасности);
🏢 те, кто будет создавать, обеспечивать работоспособность и изменять систему (разработчики, администраторы, инженеры по эксплуатации, служба поддержки пользователей);
📁 те, кто обеспечивает организационные меры по созданию, запуску и развитию системы (руководитель проекта, юристы, маркетинг, отделы обучения и HR);
📲 те, на кого непосредственно повлияет создание системы, как-то изменит их деятельность (сотрудники, клиенты, поставщики);
📝 те, кто задает “правила игры”, обязательные требования и ограничения (регуляторы, методологи, нормировщики и т.п.);
📰 те, кого почему-то заботит создание системы (медиа, общественные организации, активисты, инфлюенсеры, депутаты).
Эту "китайскую классификацию" ("...нарисованные тончайшей кистью из верблюжьей шерсти...") хочется как-то упорядочить. Вообще упорядочивание и систематизация — один из главных инструментов анализа, позволяющий найти пробелы. Как таблица Менделеева, в которой вначале было много дыр — не открытых, но предсказанных элементов.
Для человеческой деятельности такой общепризнанной модели пока нет, но есть некоторые теории. Интересно, что теория деятельности появилась в СССР (Выготский, Леонтьев...), и это одна из признанных в мире не технических и не естественно-научных советских теорий. Впрочем, развивает её в последнее время ученый из Финляндии, и придумал уже 4 поколение этой теории (1 - Выготский, 2 - Леонтьев, 3 и 4 - Энгестрём). У Выготского речь шла об обучении человека, а у Энгестрёма — про организационный дизайн и обучение организаций/команд. Ну и про проектирование взаимодействия людей и компьютеров в очень широком смысле.
Энгестрём рисует сложный треугольник: субъект (кто действует), объект (над чем производится действие), инструменты (чем производится действие). Это база от Выготского. Ниже — окружение: правила, сообщество, система разделения труда. Отдельно от треугольника — результат, измененный объект. Посмотрим на наших стейкхолдеров — они понятным образом раскладываются по этим элементам. Вот только системы деятельности у них оказываются разными.
Пользователь уже имеет какую-то свою сложившуюся систему деятельности (с объектом и инструментами, и всеми остальными элементами), и в эту деятельность мы пытаемся вставить нашу систему. Система — это инструмент для пользователя. Меняется инструмент — начинает меняться вся система деятельности, ну или хотя бы вибрировать, как паутина, ведь всё со всем связано. Пользователю важно, чтобы инструмент был не хуже предыдущего, и результат тоже был не хуже (я уже не буду говорить, что объект должен быть тем же, иначе это другая деятельность).
И вот у нас есть пользователи и сообщества, а члены сообществ, с одной стороны, формируют нормы и правила (они могут быть разными, и правила могут иметь разную степень обязательности), а с другой — участвуют в системе разделения труда. Ещё есть производители инструментов и потребители результата деятельности.
У них всех свои интересы, но все они хотят примерно одного: чтобы им точно не стало хуже, а желательно — стало лучше.
Соответственно, вы обязательно столкнетесь с этими стейкхолдерами, если ваша система потребует изменения правил, разделения труда, ослабит или усилит какие-то сообщества, потребует изменения объекта или результата.
Но сначала продолжение предыдущего поста.
Итак, я сел выписывать список заинтересованных сторон. Требования ведь берутся только от заинтересованных сторон, больше неоткуда.
Получился вот такой список:
Эту "китайскую классификацию" ("...нарисованные тончайшей кистью из верблюжьей шерсти...") хочется как-то упорядочить. Вообще упорядочивание и систематизация — один из главных инструментов анализа, позволяющий найти пробелы. Как таблица Менделеева, в которой вначале было много дыр — не открытых, но предсказанных элементов.
Для человеческой деятельности такой общепризнанной модели пока нет, но есть некоторые теории. Интересно, что теория деятельности появилась в СССР (Выготский, Леонтьев...), и это одна из признанных в мире не технических и не естественно-научных советских теорий. Впрочем, развивает её в последнее время ученый из Финляндии, и придумал уже 4 поколение этой теории (1 - Выготский, 2 - Леонтьев, 3 и 4 - Энгестрём). У Выготского речь шла об обучении человека, а у Энгестрёма — про организационный дизайн и обучение организаций/команд. Ну и про проектирование взаимодействия людей и компьютеров в очень широком смысле.
Энгестрём рисует сложный треугольник: субъект (кто действует), объект (над чем производится действие), инструменты (чем производится действие). Это база от Выготского. Ниже — окружение: правила, сообщество, система разделения труда. Отдельно от треугольника — результат, измененный объект. Посмотрим на наших стейкхолдеров — они понятным образом раскладываются по этим элементам. Вот только системы деятельности у них оказываются разными.
Пользователь уже имеет какую-то свою сложившуюся систему деятельности (с объектом и инструментами, и всеми остальными элементами), и в эту деятельность мы пытаемся вставить нашу систему. Система — это инструмент для пользователя. Меняется инструмент — начинает меняться вся система деятельности, ну или хотя бы вибрировать, как паутина, ведь всё со всем связано. Пользователю важно, чтобы инструмент был не хуже предыдущего, и результат тоже был не хуже (я уже не буду говорить, что объект должен быть тем же, иначе это другая деятельность).
И вот у нас есть пользователи и сообщества, а члены сообществ, с одной стороны, формируют нормы и правила (они могут быть разными, и правила могут иметь разную степень обязательности), а с другой — участвуют в системе разделения труда. Ещё есть производители инструментов и потребители результата деятельности.
У них всех свои интересы, но все они хотят примерно одного: чтобы им точно не стало хуже, а желательно — стало лучше.
Соответственно, вы обязательно столкнетесь с этими стейкхолдерами, если ваша система потребует изменения правил, разделения труда, ослабит или усилит какие-то сообщества, потребует изменения объекта или результата.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21❤4
Дальше культурно-историческая теория деятельности (в изложении Энгестрема) говорит о противоречиях — contradictions, или о напряжениях — tensions. Зачастую эти противоречия уже существуют, сложились исторически ещё до внедрения ИТ-системы, а система может их гасить или усугублять, или вводить новые напряжения.
Эти же напряжения являются на самом деле движущей силой для эволюции системы деятельности, в том числе для создания ИТ-систем. Интересный вопрос — какое напряжение, какое противоречие стало поводом создать вашу систему?
Энгестрем выделяет структурно 4 уровня противоречий:
1. Противоречие в одном узле деятельности: например, правила противоречат друг-другу, или инструменты несовместимы/делают принципиально разное, в разделении труда одна задача назначена двум ролям, у деятельности несколько разных объектов и целей.
2. Противоречие между узлами: инструменты не соответствуют правилам, не подходят для достижения цели, разделение труда конфликтует со сложившимися сообществами, и т.д.
3. Противоречие между существующей системой деятельности и новой. Это когда мы пытаемся что-то менять.
4. Противоречие между смежными системами: теми, что соединены через общий результат, теми, кто пользуются результатом, кто дает вам правила, инструменты, сообщества, да и самих субъектов (привет, HR!)
Весь этот анализ, конечно, ближе к бизнес-анализу и в частности к анализу организационных изменений, но и для системного аналитика (особенно если он считает себя системным инженером) важно иметь инструмент для понимания — почему система может не стать успешной.
У противоречий есть 4 проявления:
1. Дилемма
2. Конфликт
3. Критический конфликт
4. Двойное послание
Ситуация двойного послания является причиной изменения системы деятельности, Энгестрем называет это "экспансивным обучением" организации. Сначала возникают первичные противоречия, участники постоянно сталкиваются с дилеммами, выбором, неэффективностью; изобретают разнообразные обходные маневры, разделяют формальные правила и реальную деятельность. Нарастает фрустрация, но всё это может продолжаться очень долго, годами. Пока не произойдет явный критический конфликт, или все участники не попадут в ситуацию постоянной двойственности, которую не смогут выдерживать (потому что каждое действие ощущается как ошибка, какой бы вариант вы не выбрали).
Тут должно произойти экспансивное обучение, система деятельности должна "переизобрести себя", предложив какой-то выход из ситуации двойного послания. По идее, новая система должна выйти на более высокий культурно-исторический уровень.
Впрочем, это оптимистичный взгляд — бывает и по-плохому:
* система деятельности может застрять в бесконечных воркэраундах, а люди начнут просто сгорать из-за двойных посланий;
* сообщество может фрагментироваться и поляризоваться: все начнут обвинять друг-друга, и без способности объединиться никакого обучения происходить не будет, а будет происходить политический паралич;
* руководство (особенно бюрократическое) может начать усиливать давление: раз правила не работают, значит, их плохо соблюдают. Давайте введем больше правил и строже штрафовать! Система сваливается в раскручивающуюся петлю обратной связи
* вместо усложнения деятельности система может деградировать и вернуться к более простым, но энергетически более выгодным формам
В общем, это всё ужасно интересно, и особенно — какова во всем этом роль ИТ-систем, какое перераспределение информации и власти они создают, и это, на мой взгляд, и есть самый настоящий бизнес-анализ. Только я такого ни в одной учебной программе по БА не видел.
Эти же напряжения являются на самом деле движущей силой для эволюции системы деятельности, в том числе для создания ИТ-систем. Интересный вопрос — какое напряжение, какое противоречие стало поводом создать вашу систему?
Энгестрем выделяет структурно 4 уровня противоречий:
1. Противоречие в одном узле деятельности: например, правила противоречат друг-другу, или инструменты несовместимы/делают принципиально разное, в разделении труда одна задача назначена двум ролям, у деятельности несколько разных объектов и целей.
2. Противоречие между узлами: инструменты не соответствуют правилам, не подходят для достижения цели, разделение труда конфликтует со сложившимися сообществами, и т.д.
3. Противоречие между существующей системой деятельности и новой. Это когда мы пытаемся что-то менять.
4. Противоречие между смежными системами: теми, что соединены через общий результат, теми, кто пользуются результатом, кто дает вам правила, инструменты, сообщества, да и самих субъектов (привет, HR!)
Весь этот анализ, конечно, ближе к бизнес-анализу и в частности к анализу организационных изменений, но и для системного аналитика (особенно если он считает себя системным инженером) важно иметь инструмент для понимания — почему система может не стать успешной.
У противоречий есть 4 проявления:
1. Дилемма
2. Конфликт
3. Критический конфликт
4. Двойное послание
Ситуация двойного послания является причиной изменения системы деятельности, Энгестрем называет это "экспансивным обучением" организации. Сначала возникают первичные противоречия, участники постоянно сталкиваются с дилеммами, выбором, неэффективностью; изобретают разнообразные обходные маневры, разделяют формальные правила и реальную деятельность. Нарастает фрустрация, но всё это может продолжаться очень долго, годами. Пока не произойдет явный критический конфликт, или все участники не попадут в ситуацию постоянной двойственности, которую не смогут выдерживать (потому что каждое действие ощущается как ошибка, какой бы вариант вы не выбрали).
Тут должно произойти экспансивное обучение, система деятельности должна "переизобрести себя", предложив какой-то выход из ситуации двойного послания. По идее, новая система должна выйти на более высокий культурно-исторический уровень.
Впрочем, это оптимистичный взгляд — бывает и по-плохому:
* система деятельности может застрять в бесконечных воркэраундах, а люди начнут просто сгорать из-за двойных посланий;
* сообщество может фрагментироваться и поляризоваться: все начнут обвинять друг-друга, и без способности объединиться никакого обучения происходить не будет, а будет происходить политический паралич;
* руководство (особенно бюрократическое) может начать усиливать давление: раз правила не работают, значит, их плохо соблюдают. Давайте введем больше правил и строже штрафовать! Система сваливается в раскручивающуюся петлю обратной связи
* вместо усложнения деятельности система может деградировать и вернуться к более простым, но энергетически более выгодным формам
В общем, это всё ужасно интересно, и особенно — какова во всем этом роль ИТ-систем, какое перераспределение информации и власти они создают, и это, на мой взгляд, и есть самый настоящий бизнес-анализ. Только я такого ни в одной учебной программе по БА не видел.
🔥8❤3👍2
Знаю, что в Яндексе работает много аналитиков данных, или BI-аналитиков — тех, кто перемалывает массивы данных и извлекает из них всякие интересные инсайты.
В принципе, роль смежная — я и сам неоднократно решал задачи построения хранилищ для аналитики и обеспечения бизнеса актуальными и интересными данными. Но я не считаю себя крутым экспертом именно в таком анализе. Тем интереснее послушать, как это устроено в больших масштабах. Ну а заодно посмотреть на то, как ребята осваивают ИИ.
У Яндекса есть подкаст от аналитиков для аналитиков "Доверительный интервал" — это регулярные встречи, где они обсуждают свои задачи и актуальные боли. Последний выпуск там был про ИИ: у них тоже идёт освоение, adoption, есть сомневающиеся, есть и ментальные блоки "ой, я попробовал, ничего эти агенты не умеют".
Интересно, что все с разных сторон заходят — кто-то начал с кода, кто-то с презентаций, кто-то с разговоров с ИИ, как с оппонентом или партнером по размышлениям. А потом люди втянулись, и теперь просто каждый день используют в штатном режиме.
Интересная мысль там была про агентов. Я сам где-то с весны работаю не в отдельных чатах, а в Cursor'е. Какие там агенты, где там агенты — ну, где-то внутри они есть, для меня это всё равно выглядит, как чат. Но! Этот чат (через агентов) имеет доступ к файлам на диске, к браузеру, к интерпретатору python или node, MCP, и может запускать разных агентов для разных задач. Если вы видели ИИ только в виде чата в браузере — попробуйте. Это вообще другой уровень. Те же презентации агентами гораздо удобнее собирать, в чате у меня ни разу нормально не получалось, а тут один агент думает над содержанием, другой пишет код, генерирующий pptx, и запускает его, третий думает про оформление, четвертый проверяет. А когда у вас есть подключенные системы и данные, всё вообще начинает выглядеть, как магия.
В том числе и для пользователей. Я помню, как давно зрела идея, что бизнес сам сможет получать нужные данные. SQL продвигали под этим соусом, конструкторы дашбордов — ничего не срабатывало, всё равно заказчику нужно было или звать разработчиков/аналитиков, или самому становиться таким разработчиком. И вот, наконец, с ИИ — вроде начало получаться. Можно сказать, чего ты хочешь, и ты получишь это. НО! Проблема в том, чтобы убедиться, что данные достоверны. Вот это сомнение важно в заказчика заложить (и ребята в видео как раз об этом говорят), а то часто все принимают на веру.
Куда в таком случае деваются аналитики, и нужны ли они? Ну, во-первых, остаются всё-таки сложные задачи (которые всё равно теперь можно делать в разы быстрее); а, во-вторых, и это даже важнее — аналитики становятся архитекторами инфраструктуры. Чтобы ИИ всё сделал, нужно ему подготовить качественные данные (и убедиться, что они качественные), описания этих данных (чтобы понял смысл) и ограничители/валидаторы (харнесс), чтобы быть уверенными, что ИИ выдал не ерунду.
И это интересное свидетельство о том, какие формы применения ИИ зарождаются в индустрии: 1) усиление себя, делегирование своих задач, получая ускорение в разы или даже десятки раз; 2) передача своих функций заказчикам, оставляя за собой построение архитектуры и контроль качества. Две разных стратегии, но в обеих получается делегирование, только разное — ИИ-агентам или своим же заказчикам. А вы посередине, как царь горы 🤩
В принципе, роль смежная — я и сам неоднократно решал задачи построения хранилищ для аналитики и обеспечения бизнеса актуальными и интересными данными. Но я не считаю себя крутым экспертом именно в таком анализе. Тем интереснее послушать, как это устроено в больших масштабах. Ну а заодно посмотреть на то, как ребята осваивают ИИ.
У Яндекса есть подкаст от аналитиков для аналитиков "Доверительный интервал" — это регулярные встречи, где они обсуждают свои задачи и актуальные боли. Последний выпуск там был про ИИ: у них тоже идёт освоение, adoption, есть сомневающиеся, есть и ментальные блоки "ой, я попробовал, ничего эти агенты не умеют".
Интересно, что все с разных сторон заходят — кто-то начал с кода, кто-то с презентаций, кто-то с разговоров с ИИ, как с оппонентом или партнером по размышлениям. А потом люди втянулись, и теперь просто каждый день используют в штатном режиме.
Интересная мысль там была про агентов. Я сам где-то с весны работаю не в отдельных чатах, а в Cursor'е. Какие там агенты, где там агенты — ну, где-то внутри они есть, для меня это всё равно выглядит, как чат. Но! Этот чат (через агентов) имеет доступ к файлам на диске, к браузеру, к интерпретатору python или node, MCP, и может запускать разных агентов для разных задач. Если вы видели ИИ только в виде чата в браузере — попробуйте. Это вообще другой уровень. Те же презентации агентами гораздо удобнее собирать, в чате у меня ни разу нормально не получалось, а тут один агент думает над содержанием, другой пишет код, генерирующий pptx, и запускает его, третий думает про оформление, четвертый проверяет. А когда у вас есть подключенные системы и данные, всё вообще начинает выглядеть, как магия.
В том числе и для пользователей. Я помню, как давно зрела идея, что бизнес сам сможет получать нужные данные. SQL продвигали под этим соусом, конструкторы дашбордов — ничего не срабатывало, всё равно заказчику нужно было или звать разработчиков/аналитиков, или самому становиться таким разработчиком. И вот, наконец, с ИИ — вроде начало получаться. Можно сказать, чего ты хочешь, и ты получишь это. НО! Проблема в том, чтобы убедиться, что данные достоверны. Вот это сомнение важно в заказчика заложить (и ребята в видео как раз об этом говорят), а то часто все принимают на веру.
Куда в таком случае деваются аналитики, и нужны ли они? Ну, во-первых, остаются всё-таки сложные задачи (которые всё равно теперь можно делать в разы быстрее); а, во-вторых, и это даже важнее — аналитики становятся архитекторами инфраструктуры. Чтобы ИИ всё сделал, нужно ему подготовить качественные данные (и убедиться, что они качественные), описания этих данных (чтобы понял смысл) и ограничители/валидаторы (харнесс), чтобы быть уверенными, что ИИ выдал не ерунду.
И это интересное свидетельство о том, какие формы применения ИИ зарождаются в индустрии: 1) усиление себя, делегирование своих задач, получая ускорение в разы или даже десятки раз; 2) передача своих функций заказчикам, оставляя за собой построение архитектуры и контроль качества. Две разных стратегии, но в обеих получается делегирование, только разное — ИИ-агентам или своим же заказчикам. А вы посередине, как царь горы 🤩
🤔10💯8🔥6👍1
Должен вам сказать, на самом деле я не отношусь к ранним последователям. Я даже скорее тормоз в этом смысле. Вот и с ИИ я только весной этого года добрался до Cursor. И вот что советую: если вы пробуете что-то делать в свой работе через чаты — бросайте эту ерунду. Это работает только в режиме "спросить что-то очень быстро" или "сгенерить очередную одноразовую картинку". Для настоящей работы над сколь-нибудь большим проектом нужно использовать среду разработки со встроенными агентами — Cursor, Claude Code, OpenCode и т.п.
Мне нравится Cursor, потому что у него знакомый интерфейс VSCode (и интерфейс в принципе есть, а не просто консоль, я не консольный чувак), есть выбор из разных моделей и встроенные агенты. Это не вайбкодинг, это так сейчас программирование выглядит. Я, кстати, впервые с 2012 года взялся за написание чего-то большего, чем скрипт для анализа или парсинга данных, и сейчас в одиночку строю проект, на который раньше понадобилась бы команда из 3-5 человек.
В принципе, мне даже хватает встроенных в Cursor агентов, но есть несколько скиллов, которыми я активно пользуюсь. Скиллы — это ещё один аргумент к использованию ИИ в таком варианте, а не в онлайн-чате. (Другой — что можно закинуть кучу документов в проект, и не париться ограничениями, агент их сам найдет и изучит, сколько бы их у вас там ни было).
Что у меня из скиллов в постоянной работе:
grill-me от Matt Pocock (https://github.com/mattpocock/skills). Скилл делает ровно то, что в названии — качественно прожаривает вашу идею, иногда прямо очень жестко. Работает он в режиме интервью, то есть задает вам вопросы. Аналитика, который бы задавал такие вопросы, любой заказчик сам бы прожарил из огнемета. А когда они исходят от тупой машины, вроде и не так обидно. На выходе получается план проекта с основными техническими решениями (grill-with-docs формирует документацию, в которой, в том числе, задан язык, которым вы описываете проблемную область). У Мэтта там целый пак скиллов, которыми можно дальше генерить проект по спеке после прожарки, но я использую в основном для обкатки идей проектов и документов.
spec-kit для Cursor (https://github.com/madebyaris/spec-kit-command-cursor). Вы знаете, какое самое последнее новшество в разработке? SDD — Spec-Driven Development, разработка, управляемая спецификациями. Вот неожиданность, правда? Оказывается, ИИ лучше всего разрабатывает по детальным спецификациям, вот так новость! Скиллы от Мэтта — это тоже SDD, но я пока не придумал, как их объединить. SpecKit хорош тем, что содержит цельный воркфлоу, от написания этих самых спецификаций до их реализации. Он тоже сначала проводит с вами интервью, но более поверхностно, без прожарки. Если мне не нужно сильно вникать, я беру его. Он генерит большие объемы спецификаций (сотни задач), а потом так же неутомимо их реализует. Фактически, это таск-трекер на основе файлов, со статусами и ссылками на спецификацию (у меня в одном из проектов оно сделало сходу 61 задачу, и это только MVP!)
adversarial-editorial-review (https://github.com/Halfofthesky/adversarial-editorial-review) — это тоже прожарка, но для статей (очень мне помог при написании магистерской, правда результата от людей-ревьюверов я пока не видел 😅). Он берет ваш текст и дает трем разным "ревьюверам": один считает, что доказательная база слабее, чем вы преподносите, второй — что в аргументации есть логические изъяны, третий — что вы упускаете точку зрения кого-то из вовлеченных лиц, или слишком вольно трактуете теорию, на которую опираетесь. Для научных публикаций мне очень понравился (хинт: можно не только свои брать, но и чью-то готовую опубликованную подсунуть!), нужно бы такой сделать для проектных аналитических документов — чтобы с разных сторон критиковали, а потом редактор сводил общий результат.
В общем, это всё совершенно другой уровень качества, и если вы пробовали только чаты — советую попробовать и такой инструмент (в бесплатной версии он позволяет пощупать, но токены очень быстро кончаются). Я уже включил в свои ежемесячные расходы подписку, ну что же теперь делать, отказываться от этого инструмента не хочется (и, честно говоря, за многие задачи я бы просто не взялся без него).
Мне нравится Cursor, потому что у него знакомый интерфейс VSCode (и интерфейс в принципе есть, а не просто консоль, я не консольный чувак), есть выбор из разных моделей и встроенные агенты. Это не вайбкодинг, это так сейчас программирование выглядит. Я, кстати, впервые с 2012 года взялся за написание чего-то большего, чем скрипт для анализа или парсинга данных, и сейчас в одиночку строю проект, на который раньше понадобилась бы команда из 3-5 человек.
В принципе, мне даже хватает встроенных в Cursor агентов, но есть несколько скиллов, которыми я активно пользуюсь. Скиллы — это ещё один аргумент к использованию ИИ в таком варианте, а не в онлайн-чате. (Другой — что можно закинуть кучу документов в проект, и не париться ограничениями, агент их сам найдет и изучит, сколько бы их у вас там ни было).
Что у меня из скиллов в постоянной работе:
grill-me от Matt Pocock (https://github.com/mattpocock/skills). Скилл делает ровно то, что в названии — качественно прожаривает вашу идею, иногда прямо очень жестко. Работает он в режиме интервью, то есть задает вам вопросы. Аналитика, который бы задавал такие вопросы, любой заказчик сам бы прожарил из огнемета. А когда они исходят от тупой машины, вроде и не так обидно. На выходе получается план проекта с основными техническими решениями (grill-with-docs формирует документацию, в которой, в том числе, задан язык, которым вы описываете проблемную область). У Мэтта там целый пак скиллов, которыми можно дальше генерить проект по спеке после прожарки, но я использую в основном для обкатки идей проектов и документов.
spec-kit для Cursor (https://github.com/madebyaris/spec-kit-command-cursor). Вы знаете, какое самое последнее новшество в разработке? SDD — Spec-Driven Development, разработка, управляемая спецификациями. Вот неожиданность, правда? Оказывается, ИИ лучше всего разрабатывает по детальным спецификациям, вот так новость! Скиллы от Мэтта — это тоже SDD, но я пока не придумал, как их объединить. SpecKit хорош тем, что содержит цельный воркфлоу, от написания этих самых спецификаций до их реализации. Он тоже сначала проводит с вами интервью, но более поверхностно, без прожарки. Если мне не нужно сильно вникать, я беру его. Он генерит большие объемы спецификаций (сотни задач), а потом так же неутомимо их реализует. Фактически, это таск-трекер на основе файлов, со статусами и ссылками на спецификацию (у меня в одном из проектов оно сделало сходу 61 задачу, и это только MVP!)
adversarial-editorial-review (https://github.com/Halfofthesky/adversarial-editorial-review) — это тоже прожарка, но для статей (очень мне помог при написании магистерской, правда результата от людей-ревьюверов я пока не видел 😅). Он берет ваш текст и дает трем разным "ревьюверам": один считает, что доказательная база слабее, чем вы преподносите, второй — что в аргументации есть логические изъяны, третий — что вы упускаете точку зрения кого-то из вовлеченных лиц, или слишком вольно трактуете теорию, на которую опираетесь. Для научных публикаций мне очень понравился (хинт: можно не только свои брать, но и чью-то готовую опубликованную подсунуть!), нужно бы такой сделать для проектных аналитических документов — чтобы с разных сторон критиковали, а потом редактор сводил общий результат.
В общем, это всё совершенно другой уровень качества, и если вы пробовали только чаты — советую попробовать и такой инструмент (в бесплатной версии он позволяет пощупать, но токены очень быстро кончаются). Я уже включил в свои ежемесячные расходы подписку, ну что же теперь делать, отказываться от этого инструмента не хочется (и, честно говоря, за многие задачи я бы просто не взялся без него).
1👍17❤13❤🔥3
Как облегчить работу ИТ-аналитика уже сейчас — без долгосрочных перестроек процессов?
Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады:
— Как эффективнее использовать возможности мозга
— Какие навыки развивать аналитику и как выстроить план роста
— SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика
📆 29 сентября
📍 Офис Сбера (Кутузовский пр-т, 32) и трансляция онлайн
Выбирайте удобный формат и регистрируйтесь по ссылке
Обсудим на IT-analyst Meetup от Сбера! В программе — прикладные доклады:
— Как эффективнее использовать возможности мозга
— Какие навыки развивать аналитику и как выстроить план роста
— SDD на практике: подводные камни внедрения и новые зоны ответственности аналитика
Выбирайте удобный формат и регистрируйтесь по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Музей бессмысленных метрик: число строк кода, стори-поинты, число пулл-реквестов. И наш новый экспонат: расход токенов! А у вас измеряют активность сотрудников по внедрению ИИ? Про токены, кстати, не шутка — многим моим знакомым в западных компаниях действительно выделяют бюджет в токенах на месяц, и следят за его расходованием. Причем сейчас уже пошел откат: самым активным число токенов стали подрезать, слишком дорого.
В российских компаниях пока видел, как измеряют число обращений к локальным моделям, развернутым в контуре компании (только к локальным! никаких облачных провайдеров!), число вызовов определенных скиллов. Ну да, для локальных моделей число токенов не так важно, свои же.
Про измерение результатов пока не слышал. Ну вот такого, чтобы кто-то рассказывал про то, как в разы ускорили подготовку документов, или уменьшили время согласования, или число уточнений спецификации на этапе разработки. Какие у нас ещё есть разумные метрики аналитического процесса?
Я тут исследовал образовательные организации, и как в них внедряют ИИ. Там у них всё жестко и безальтернативно — если уж руководство решило использовать генеративный ИИ, так будут такие методы: планы развития и отчеты о работе теперь принимаются только в виде ссылок на чат с ИИ, в последнем случае — с навыком расчета премий. Вот сколько тебе ИИ рассчитал, столько и получишь. Туда же — планы занятий, генерация репортов об успехах учащегося. Мимо ИИ их просто запрещено делать. На некоторых дисциплинах в качестве ответа на задание от группы принимается тоже ссылка на чат (там, где раньше попросили бы презентацию).
Такой вот подход, а не какое-то там мямление — ну хочешь, используй, не хочешь не используй, но хотя бы попробуй, а? ну разочек?..
К этому, конечно, по-хорошему должен быть прикручен контур обратной связи и постоянного совершенствования промптов, скиллов и т.п., но мотивирует этим заниматься внешнее жесткое распоряжение. Вот такие у нас механизмы управления бывают.
А как у вас это устроено? Добровольно ли применение ИИ? Есть ли метрики и KPI? Есть ли безальтернативное и обязательное использование инструментов? Или наоборот всё запрещено до сих пор?
В российских компаниях пока видел, как измеряют число обращений к локальным моделям, развернутым в контуре компании (только к локальным! никаких облачных провайдеров!), число вызовов определенных скиллов. Ну да, для локальных моделей число токенов не так важно, свои же.
Про измерение результатов пока не слышал. Ну вот такого, чтобы кто-то рассказывал про то, как в разы ускорили подготовку документов, или уменьшили время согласования, или число уточнений спецификации на этапе разработки. Какие у нас ещё есть разумные метрики аналитического процесса?
Я тут исследовал образовательные организации, и как в них внедряют ИИ. Там у них всё жестко и безальтернативно — если уж руководство решило использовать генеративный ИИ, так будут такие методы: планы развития и отчеты о работе теперь принимаются только в виде ссылок на чат с ИИ, в последнем случае — с навыком расчета премий. Вот сколько тебе ИИ рассчитал, столько и получишь. Туда же — планы занятий, генерация репортов об успехах учащегося. Мимо ИИ их просто запрещено делать. На некоторых дисциплинах в качестве ответа на задание от группы принимается тоже ссылка на чат (там, где раньше попросили бы презентацию).
Такой вот подход, а не какое-то там мямление — ну хочешь, используй, не хочешь не используй, но хотя бы попробуй, а? ну разочек?..
К этому, конечно, по-хорошему должен быть прикручен контур обратной связи и постоянного совершенствования промптов, скиллов и т.п., но мотивирует этим заниматься внешнее жесткое распоряжение. Вот такие у нас механизмы управления бывают.
А как у вас это устроено? Добровольно ли применение ИИ? Есть ли метрики и KPI? Есть ли безальтернативное и обязательное использование инструментов? Или наоборот всё запрещено до сих пор?
❤7👍3😱2
Короткая заметка: ещё весной я проводил курс по применению ИИ для системных аналитиков. Ну и до этого в нескольких вариантах: курсы, лекции, мастер-классы.
Но уже летом я начал думать, как его менять. И, в общем, многое, что я там рассказывал, не особо уже актуально.
Раньше в курсах ведь что рассказывали: вот есть такие модели, вот так нужно составлять промпты, такие вот формулировки использовать... Но сейчас это всё уже ушло в прошлое. Если модель вас не понимает — возьмите нормальную топовую модель, перестаньте есть кактус. Не нужно уже растолковывать модели каждый шаг и расписывать роли. Всё это ушло в системные инструкции, rules.md и скиллы. И занимаются этим специальные люди — ну, впрочем, те, кто до этого экспериментировал с промптами. Хитрые промпты были нужны, когда модель вообще не понимала, чего от неё хотят. Сейчас такого у верхних моделей уже почти не встречается.
Сейчас горячие темы — управление контекстом, харнесс, гардрейлы, цепочки вызовов и проверок. Как кормить LLM контекстом и какие промежуточные артефакты она должна генерировать, чтобы и самой не запутаться, и человек мог быстро проверить, вот основные вопросы. Но ответов на них пока нет, потому что мы — сюрприз! — не до конца понимаем, что именно и как делает системный аналитик. В чем его основаная польза? Как проверить качество его работы? Где граница деятельности? Кто умеет на это отвечать, тот сможет построить ИИ-пайплайн, включающий задачи аналитика. Ну или будет пользоваться готовыми spec-kit или OpenSpec.
Вот только эти SDD-инструменты пришли с запада, а там, как мы знаем, организация разработки несколько отличается, и аналитиков уже давно нет. Ну и как работать с требованиями они, значит, тоже уже забыли. Программистам это всё тоже не нужно и не интересно, они приниципиально не понимают: "На первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны." (это цитата из рандомной статьи программиста про SDD с Хабра). Требования, наверное, зачем-то нужны, ну пусть будут. Разработчика интересует, как всегда, другое — чтобы тесты были, чтобы стиль кода соблюдался, чтобы миграции нормально сформировались и применились.
В этом есть очевидный (нам с вами) риск: всё сделано, как положено с точки зрения программиста, но в результате получилась какая-то фигня. Потому что требования толком никто не проверял и не анализировал.
Дальше возникает интересный вопрос: нужно ли нам всё ещё сохранять две отдельные роли аналитика и разработчика (которые обе проверяют работу ИИ, но проверяют в ней разное), или у нас возникнут новые фулл-стеки, как броненосцы в сказке Киплинга — разработчики научатся видеть смысл в требованиях, а аналитики начнут понимать нюансы разработки? Или всех их просто сметет, и все эти вопросы через пару итераций погрузятся так глубоко, что только узкие специалисты будут знать, как так внутри устроены спеки/код/релизные пайплайны, как сейчас мало кто задумывается об устройстве конвейера и ветвлений в процессоре?
История разделения труда дает нам двоякие примеры: с одной стороны, углубление разделения труда, с другой — наоборот, поглощение чисто навыковых профессий. Когда-то ретушер, линотипист и чертежник были отдельными профессиями, но цифра их съела. И все просто чертежники стали чертежниками-конструкторами. Кем станут аналитики, вот вопрос.
Но уже летом я начал думать, как его менять. И, в общем, многое, что я там рассказывал, не особо уже актуально.
Раньше в курсах ведь что рассказывали: вот есть такие модели, вот так нужно составлять промпты, такие вот формулировки использовать... Но сейчас это всё уже ушло в прошлое. Если модель вас не понимает — возьмите нормальную топовую модель, перестаньте есть кактус. Не нужно уже растолковывать модели каждый шаг и расписывать роли. Всё это ушло в системные инструкции, rules.md и скиллы. И занимаются этим специальные люди — ну, впрочем, те, кто до этого экспериментировал с промптами. Хитрые промпты были нужны, когда модель вообще не понимала, чего от неё хотят. Сейчас такого у верхних моделей уже почти не встречается.
Сейчас горячие темы — управление контекстом, харнесс, гардрейлы, цепочки вызовов и проверок. Как кормить LLM контекстом и какие промежуточные артефакты она должна генерировать, чтобы и самой не запутаться, и человек мог быстро проверить, вот основные вопросы. Но ответов на них пока нет, потому что мы — сюрприз! — не до конца понимаем, что именно и как делает системный аналитик. В чем его основаная польза? Как проверить качество его работы? Где граница деятельности? Кто умеет на это отвечать, тот сможет построить ИИ-пайплайн, включающий задачи аналитика. Ну или будет пользоваться готовыми spec-kit или OpenSpec.
Вот только эти SDD-инструменты пришли с запада, а там, как мы знаем, организация разработки несколько отличается, и аналитиков уже давно нет. Ну и как работать с требованиями они, значит, тоже уже забыли. Программистам это всё тоже не нужно и не интересно, они приниципиально не понимают: "На первый взгляд может показаться, что эти требования и сценарии слишком очевидны. Но, во-первых, очевидные вещи тоже нужно где-то зафиксировать. Во-вторых, OpenSpec сгенерировал их самостоятельно — видимо, они ему всё-таки нужны." (это цитата из рандомной статьи программиста про SDD с Хабра). Требования, наверное, зачем-то нужны, ну пусть будут. Разработчика интересует, как всегда, другое — чтобы тесты были, чтобы стиль кода соблюдался, чтобы миграции нормально сформировались и применились.
В этом есть очевидный (нам с вами) риск: всё сделано, как положено с точки зрения программиста, но в результате получилась какая-то фигня. Потому что требования толком никто не проверял и не анализировал.
Дальше возникает интересный вопрос: нужно ли нам всё ещё сохранять две отдельные роли аналитика и разработчика (которые обе проверяют работу ИИ, но проверяют в ней разное), или у нас возникнут новые фулл-стеки, как броненосцы в сказке Киплинга — разработчики научатся видеть смысл в требованиях, а аналитики начнут понимать нюансы разработки? Или всех их просто сметет, и все эти вопросы через пару итераций погрузятся так глубоко, что только узкие специалисты будут знать, как так внутри устроены спеки/код/релизные пайплайны, как сейчас мало кто задумывается об устройстве конвейера и ветвлений в процессоре?
История разделения труда дает нам двоякие примеры: с одной стороны, углубление разделения труда, с другой — наоборот, поглощение чисто навыковых профессий. Когда-то ретушер, линотипист и чертежник были отдельными профессиями, но цифра их съела. И все просто чертежники стали чертежниками-конструкторами. Кем станут аналитики, вот вопрос.
👍18😢8❤2
Знаете ли вы про добродетели хорошего программиста?
Лень, нетерпение и высокомерие.
Лень заставляет программиста не делать никакую работу дважды: как только появился похожий случай, нужно придумать универсальный способ для общего решения.
Нетерпение вызывает раздражение, когда программа тормозит, и приводит к желанию искать эффективные и быстрые решения и хитрые хаки.
Высокомерие (гордыня, самомнение) заставляет стремится к идеалу, чтобы никто не мог покритиковать решения, а только восхищаться ими.
Эти "добродетели" свойственны людям-программистам, но можно их привить и LLM-кодеру:
Эти качества придумал Ларри Уолл, создатель языка Perl. Собственно, в языке это всё как раз и проявляется: можно очень быстро решить любую проблему коротким скриптом. Лень: не нужно придумывать имена переменным, часто их даже не нужно указывать. Прямо в язык встроены регулярные выражения.
There's More Than One Way To Do It, TMTOWTDI — можно одну и ту же вещь сделать совершенно разными способами, как удобно именно сейчас. Нетерпение: никакой компиляции, всё работает сразу из командной строки (помним, что это конец 80-х, и программы вообще-то компилировались, иногда десятками минут).
Гордыня: на Perl можно было писать программы, которые выглядели, как произведение искусства (абстрактное, постмодернистское). Говорили, что программы на Perl write-only, разобраться в них другой программист не может; говорили, что программа на Perl выглядит одинаково до и после обфускации.
В общем, язык для избранных. Или для хакеров в старинном смысле.
Но в массовом производстве Perl проиграл другим подходам, например — Python. В некотором смысле Python по философии противоположен Perl'у. Есть 'Дзен Python', набор принципов разработки:
1. Красивое лучше, чем уродливое
2. Явное лучше, чем неявное
3. Простое лучше, чем сложное
4. Сложное лучше, чем запутанное
5. Плоское лучше, чем вложенное
6. Разреженное лучше, чем плотное
7. Читаемость имеет значение
8. Особые случаи не настолько особые, чтобы нарушать правила
9. Хотя практичность побеждает чистоту
10. Ошибки никогда не должны замалчиваться
11. Если не отключены специально
12. Встретив двусмысленность, отбрось искушение угадать
13. Должен быть один — и, желательно, только один — очевидный способ сделать это
14. Хотя он поначалу может быть и не очевиден, если вы не голландец (отсылка к Гвидо ван Россуму).
15. Сейчас лучше, чем никогда
16. Хотя никогда зачастую лучше, чем прямо сейчас (нетерпение, помним?)
17. Если реализацию сложно объяснить — идея плохая
18. Если реализацию легко объяснить — идея, возможно, хорошая
19. Пространства имен — отличная штука! Давайте делать их больше!
Как видите, принципы местами прямо противоположны. Вероятно, это и обеспечило значительно большую популярность и распространенность Python: легче понять, легче учить, проще поддерживать. Если всё всегда делается одинаково и явно — любой разработчик может легко разобраться, подхватить чужой код. Да и не-разработчик быстро поймет и сможет использовать для своих задач. Стабильность, предсказуемость, одинаковость (чуть-чуть туповатость, может быть) — вот то, что нужно этому миру.
И это тоже может быть подходом для инструктажа LLM. Не выдумывай, не извращайся, пиши в расчете на то, чтобы кто угодно потом мог легко разобраться.
Программная индустрия решила в пользу простоты и понятности против эффективности и искусства. Сейчас все опасаются вайб-кодинга, но может нужно просто задать ИИ верные ориентиры?...
Лень, нетерпение и высокомерие.
Лень заставляет программиста не делать никакую работу дважды: как только появился похожий случай, нужно придумать универсальный способ для общего решения.
Нетерпение вызывает раздражение, когда программа тормозит, и приводит к желанию искать эффективные и быстрые решения и хитрые хаки.
Высокомерие (гордыня, самомнение) заставляет стремится к идеалу, чтобы никто не мог покритиковать решения, а только восхищаться ими.
Эти "добродетели" свойственны людям-программистам, но можно их привить и LLM-кодеру:
Ты — опытный инженер-программист, руководствующийся тремя добродетелями:
1. Ты ЛЕНИВ: Ты ненавидишь рутину и дублирование. Пиши переиспользуемый код (по приницпу DRY), автоматизируй всё, что можно, и создавай лаконичную архитектуру.
2. Ты НЕТЕРПЕЛИВ: Ты не терпишь медленный код. Оптимизируй алгоритмы (минимизируй Big O complexity), используй кэширование и асинхронность, чтобы система работала мгновенно.
3. Ты ГОРД: Ты пишешь код так, чтобы им гордиться перед сообществом. Он должен быть чистым, безопасным, задокументированным, снабженным тестами и устойчивым к любым ошибкам. Не выдавай "просто рабочий" код, выдавай шедевр.
Эти качества придумал Ларри Уолл, создатель языка Perl. Собственно, в языке это всё как раз и проявляется: можно очень быстро решить любую проблему коротким скриптом. Лень: не нужно придумывать имена переменным, часто их даже не нужно указывать. Прямо в язык встроены регулярные выражения.
There's More Than One Way To Do It, TMTOWTDI — можно одну и ту же вещь сделать совершенно разными способами, как удобно именно сейчас. Нетерпение: никакой компиляции, всё работает сразу из командной строки (помним, что это конец 80-х, и программы вообще-то компилировались, иногда десятками минут).
Гордыня: на Perl можно было писать программы, которые выглядели, как произведение искусства (абстрактное, постмодернистское). Говорили, что программы на Perl write-only, разобраться в них другой программист не может; говорили, что программа на Perl выглядит одинаково до и после обфускации.
В общем, язык для избранных. Или для хакеров в старинном смысле.
Но в массовом производстве Perl проиграл другим подходам, например — Python. В некотором смысле Python по философии противоположен Perl'у. Есть 'Дзен Python', набор принципов разработки:
1. Красивое лучше, чем уродливое
2. Явное лучше, чем неявное
3. Простое лучше, чем сложное
4. Сложное лучше, чем запутанное
5. Плоское лучше, чем вложенное
6. Разреженное лучше, чем плотное
7. Читаемость имеет значение
8. Особые случаи не настолько особые, чтобы нарушать правила
9. Хотя практичность побеждает чистоту
10. Ошибки никогда не должны замалчиваться
11. Если не отключены специально
12. Встретив двусмысленность, отбрось искушение угадать
13. Должен быть один — и, желательно, только один — очевидный способ сделать это
14. Хотя он поначалу может быть и не очевиден, если вы не голландец (отсылка к Гвидо ван Россуму).
15. Сейчас лучше, чем никогда
16. Хотя никогда зачастую лучше, чем прямо сейчас (нетерпение, помним?)
17. Если реализацию сложно объяснить — идея плохая
18. Если реализацию легко объяснить — идея, возможно, хорошая
19. Пространства имен — отличная штука! Давайте делать их больше!
Как видите, принципы местами прямо противоположны. Вероятно, это и обеспечило значительно большую популярность и распространенность Python: легче понять, легче учить, проще поддерживать. Если всё всегда делается одинаково и явно — любой разработчик может легко разобраться, подхватить чужой код. Да и не-разработчик быстро поймет и сможет использовать для своих задач. Стабильность, предсказуемость, одинаковость (чуть-чуть туповатость, может быть) — вот то, что нужно этому миру.
И это тоже может быть подходом для инструктажа LLM. Не выдумывай, не извращайся, пиши в расчете на то, чтобы кто угодно потом мог легко разобраться.
Ты — ИИ-архитектор программного обеспечения, чей главный приоритет — чистота, читаемость и поддерживаемость кода. Ты строго следуешь философии "The Zen of Python":
1. ЯВНОСТЬ: Пиши код без "магии" и скрытых смыслов. Обязательно используй строгую типизацию (Type Hinting) и давай переменным говорящие, понятные имена.
2. ПРОСТОТА: Избегай оверинжиниринга. Выбирай самое простое решение из возможных. Держи структуру плоской, минимизируй вложенные циклы и условия.
3. ЧИТАЕМОСТЬ: Форматируй код идеально (по стандартам PEP 8 / Clean Code). Код должен читаться как хорошая проза.
4. ЧЕСТНОСТЬ С ОШИБКАМИ: Никогда не скрывай и не "приглушай" ошибки. Перехватывай только точечные исключения, пиши информативные логи, чтобы код не маскировал ошибки, а максимально их подсвечивал.
5. ПИШИ ДЛЯ ЧИТАТЕЛЯ: Рассчитывай, что твой код должен будет изучать, понимать и изменять кто-то другой. Помоги ему быстро во всем разобраться.
Программная индустрия решила в пользу простоты и понятности против эффективности и искусства. Сейчас все опасаются вайб-кодинга, но может нужно просто задать ИИ верные ориентиры?...
👍10🔥7👏1
"Вся цифровая инфраструктура держится на библиотеке, которую в одиночку с 2003 года поддерживает рандомный чувак из Небраски"
А вы знаете, что эта картинка — ни разу не преувеличение? И вот тут ребята сделали классный сайт с неизвестными героями, на которых держатся все наши технологии: https://sheets.works/data-viz/holding-up-the-internet
Пол Эггерт, преподаватель из UCLA, с 2005 года поддерживает tz database — набор файлов с актуальным описанием часовых поясов во всех странах. На эту базу опираются все функции, связанные со временем — расписание поездов, билеты на самолеты, календари, включение фонарей по вечерам и всякое такое. Три миллиарда телефонов на Андроиде и миллиард на iOS, большинство серверов и почти все языки программирования.
Лассе Коллин в одиночку поддерживает xz — архиватор для всех серверов на Линуксе. Однажды он пустил к исходникам некоего китайца, немедленно встроившего в архиватор бэкдор, с тех пор не рискует.
Тодд Миллер, поддерживающий sudo. Неизвестный чел DRC, чья библиотека используется в каждом телефоне и браузере для открытия файлов jpg. Анонимная команда, разрабатывающая SQLite без внешнего финансирования, но с одним триллионом установок. zlib. bash. libxml2. curl. core-js.
Инфраструктура реально очень хрупкая. Bus-фактор многих проектов равен 1. Сделать с этим особо ничего нельзя, про это вообще никто не задумывается. sudo? curl? это же встроенные утилиты, разве нет? Разве их кто-то специально написал?
Я когда-то писал про бездумное использование общественных серверов точного времени (https://t.me/systemswing/528)
Мы привыкли, что инфраструктура... ну, просто есть. Как вода.
И это, кстати, интересный вопрос про видимость работы, в том числе и аналитика. Я когда-то в шутку предложил как критерий качества работы аналитика число восклицаний "О, об этом мы как-то не подумали!" в ответ на вопрос аналитика. Это шутка лишь отчасти. Я вижу — особенно в последнее время — много претензий к аналитикам, мол, а зачем вы нужны? Что вы делаете, какая от вас польза? Только задерживаете разработку. И многие аналитики даже не знают, что ответить на эту претензию (да даже и руководители анализа зачастую теряются).
Так нужно сделать видимой свою работу!
Как сертифицированный аудитор ISO 9000, говорю вам: записи первичны! Записи — всему голова! Что не записано, того и не было.
Вот у архитекторов есть ADR — записи архитектурных решений. Ну, должны быть. Они, конечно, для памяти, чтобы не забыть, почему у нас всё так криво устроено и кто это придумал. Но и для фиксации работы архитектора.
Так и для аналитика можно такие записи завести: EСR, Edge Case Record. Запись о выявленном граничном кейсе. Структура примерно такая: ID, дата, что нашли, предотвращенные последствия (что было бы, если бы не аналитик), принятое решение (тут можно дописать, сколько новых требований появилось и насколько это расширило скоуп; при желании можно даже выгоду посчитать — был ли выигрыш от исправления относительно риска потерь).
Соответственно, по этим записям для руководства считаем Shift-Left Index (Индекс раннего обнаружения): Количество критических логических ошибок и конфликтов интеграции, обнаруженных на этапе анализа, деленное на общее количество багов, найденных суммарно на всех стадиях разработки и в продакшене за тот же период. Ваш вклад — четверть или 70%? Можно ещё цену исправления прикинуть, в часах работы аналитика и остальной команды + простой.
Ну и заодно можно (и нужно!) считать снижение того самого bus-фактора (описали за квартал столько-то скрытых зависимостей и восстановили документацию к X легаси-компонентам и интеграциям).
И красивую инфографику со своими достижениями.
А вы знаете, что эта картинка — ни разу не преувеличение? И вот тут ребята сделали классный сайт с неизвестными героями, на которых держатся все наши технологии: https://sheets.works/data-viz/holding-up-the-internet
Пол Эггерт, преподаватель из UCLA, с 2005 года поддерживает tz database — набор файлов с актуальным описанием часовых поясов во всех странах. На эту базу опираются все функции, связанные со временем — расписание поездов, билеты на самолеты, календари, включение фонарей по вечерам и всякое такое. Три миллиарда телефонов на Андроиде и миллиард на iOS, большинство серверов и почти все языки программирования.
Лассе Коллин в одиночку поддерживает xz — архиватор для всех серверов на Линуксе. Однажды он пустил к исходникам некоего китайца, немедленно встроившего в архиватор бэкдор, с тех пор не рискует.
Тодд Миллер, поддерживающий sudo. Неизвестный чел DRC, чья библиотека используется в каждом телефоне и браузере для открытия файлов jpg. Анонимная команда, разрабатывающая SQLite без внешнего финансирования, но с одним триллионом установок. zlib. bash. libxml2. curl. core-js.
Инфраструктура реально очень хрупкая. Bus-фактор многих проектов равен 1. Сделать с этим особо ничего нельзя, про это вообще никто не задумывается. sudo? curl? это же встроенные утилиты, разве нет? Разве их кто-то специально написал?
Я когда-то писал про бездумное использование общественных серверов точного времени (https://t.me/systemswing/528)
Мы привыкли, что инфраструктура... ну, просто есть. Как вода.
И это, кстати, интересный вопрос про видимость работы, в том числе и аналитика. Я когда-то в шутку предложил как критерий качества работы аналитика число восклицаний "О, об этом мы как-то не подумали!" в ответ на вопрос аналитика. Это шутка лишь отчасти. Я вижу — особенно в последнее время — много претензий к аналитикам, мол, а зачем вы нужны? Что вы делаете, какая от вас польза? Только задерживаете разработку. И многие аналитики даже не знают, что ответить на эту претензию (да даже и руководители анализа зачастую теряются).
Так нужно сделать видимой свою работу!
Как сертифицированный аудитор ISO 9000, говорю вам: записи первичны! Записи — всему голова! Что не записано, того и не было.
Вот у архитекторов есть ADR — записи архитектурных решений. Ну, должны быть. Они, конечно, для памяти, чтобы не забыть, почему у нас всё так криво устроено и кто это придумал. Но и для фиксации работы архитектора.
Так и для аналитика можно такие записи завести: EСR, Edge Case Record. Запись о выявленном граничном кейсе. Структура примерно такая: ID, дата, что нашли, предотвращенные последствия (что было бы, если бы не аналитик), принятое решение (тут можно дописать, сколько новых требований появилось и насколько это расширило скоуп; при желании можно даже выгоду посчитать — был ли выигрыш от исправления относительно риска потерь).
Соответственно, по этим записям для руководства считаем Shift-Left Index (Индекс раннего обнаружения): Количество критических логических ошибок и конфликтов интеграции, обнаруженных на этапе анализа, деленное на общее количество багов, найденных суммарно на всех стадиях разработки и в продакшене за тот же период. Ваш вклад — четверть или 70%? Можно ещё цену исправления прикинуть, в часах работы аналитика и остальной команды + простой.
Ну и заодно можно (и нужно!) считать снижение того самого bus-фактора (описали за квартал столько-то скрытых зависимостей и восстановили документацию к X легаси-компонентам и интеграциям).
И красивую инфографику со своими достижениями.
❤16👍8💯3