С наступившим Новым годом!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
❤29🎉7🔥5👍1
Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО".
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
🔥10❤8👏7
Так, что-то каникулы канала неожиданно затянулись. Уже и новый год прошел, и старый, и день святого Валентина, и китайский Новый год начался, совмещенный с Масленицей. Кажется, такой паузы я ещё не делал.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногуразбирать ёлку восстанавливать ритм публикаций. Нести свет просвещения в области системного анализа. Надеюсь, вы скучали.
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногу
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
👍23❤4🕊3
Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом?
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
👍27❤6
Меня иногда спрашивают — откуда я беру темы и как ищу неожиданные ракурсы. В основном из смежных областей. Всегда бывает интересно послушать, какие нашли решения похожих проблем в других индустриях.
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
👍26❤13🔥6💯2👏1
Помните карту с 162 атрибутами качества программных систем? У нас для качества требований столько не наберется, но вот ученые в эмпирических исследованиях обнаружили 111 (не знаю, как они считали, у меня получилось 89, но всё равно впечатляет!)
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
1🔥14👍4👏2❤1
Залез в mermaid.js по какой-то надобности, а он теперь mermaid.ai, весь такой ИИ-интегрированный.
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
1🔥7❤6👍1
Я в последнее время в связи с использованием ИИ заметил вот что: можно, конечно, загонять в него формальные промпты по какой-то структуре (многие из которых упомянуты тут), но вообще он итак неплохо работает, в режиме обычного человеческого диалога, а не вот этих формальных рамок.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
То есть, знать про них конечно нужно и полезно, но чтобы все время применять... Это скорее для режима работы изолированного узконаправленного агента.
А вот что на самом деле важно, и чего нет во всех этих шаблонах — это теоретическая или концептуальная рамка, из который вам модель отвечает. При правильно подобранной рамке выдача может отличаться разительно, в том числе по глубине ответа!
Нам про это вообще мало где рассказывают, ну может быть в аспирантуре, кому повезло, при написании статей и диссертаций. Или у кого образование было плотно связано с наукой и исследованиями — особенно у социологов, психологов и экономистов-ученых. Инженеров такому не учили, у них из рамок только физика.
Примеры, из недавнего: если попросить сгенерировать программу учебного курса, она будет, ну, какая-то. Усредненно-похожая на типичный MOOC: видео в записи, тесты, capstone проект. Собственно, это калька с типового западного университетского курса. А вот если сказать ИИ действовать из рамки PBL (Project Based Learning), или Inquiry-Based Learning, или опираться на теорию Выготского, или 4С/ID (которая как раз по Выготскому построена, в его современном понимании), и вообще задуматься о scaffolding'е — как это на русском-то будет? вроде его даже не переводят, скаффолдинг и говорят — или о когнитивной нагрузке при выполнении заданий, то результаты будут совсем другие!
Задавая определенные рамки мы провоцируем модель выдавать что-то осмысленное именно в этих рамках, и тут может даже возникнуть интересный эффект на пересечении рамок — это как ученый-теоретик у тебя под рукой!
А теперь к нашим задачам. Проблема в том, что мы и сами не знаем, на какие теоретические рамки опираемся. Есть требования или нет? Как устроено принятие решений при проектировании систем? Как мы смотрим на деятельность, которую автоматизируем?
Нет, ну что-то есть, конечно. Не теоретические, а скорее именно концептуальные. Структурный анализ. Объектный анализ. Функциональное моделирование. Моделирование бизнес-процессов.
Если покопаться, можно, наверное, нарыть теоретические истоки — научная организация труда, тейлоризм, бихевиоризм, всякое такое. Но напрямую эти связи почти никогда не проговариваются. Получается, что рамки-то нет, с какой точки зрения на это смотреть?
При этом в СССР были очень интересные наработки как раз в области теории деятельности: начиная с Выготского, продолжая Леонтьевым. Эта рамка как раз могла бы многое объяснить с точки зрения автоматизации деятельности, вот только линия исследований прервалась. Современная теория деятельности — 3 поколения — называется Cultural-historical activity theory (CHAT), разрабатывается в Финляндии (Финская школа теории деятельности) и используется, например, при проектировании пользовательского опыта. На русском языке в Википедии даже статьи такой нет.
Главный у них там Yrjö Engeström, профессор Хельсинкского университета. Удивительно, но одна его книга таки была переведена на русский в 2024 году (хотя написана в 2008), и даже до меня доехала. называется "От команд к узлам", и задает очень интересную оптику для анализа командной работы. А есть ли вообще команды?.. Или взаимодействие людей над решением задачи на самом деле устроено как-то хитрее?
Пока в первой главе прочел, что работа командой противоречит бережливой организации производства (Toyota Management System), потому что первая ориентирована вовнутрь, на отношения, распределение полномочий, власти и знаний внутри команды, а вторая — вовне, на внешнее качество продукции.
А та деятельность, которой вы управляете или которую автоматизируете, на что направлена? Не пытаетесь ли вы воткнуть несвойственный инструмент (ту же жесткую модель процесса) в неподходящие условия?
Уже интересное наблюдение, посмотрим, что ещё будет.
1❤26👍14🔥3👎1
Если вы думаете, что ИИ победно шествует по рынку труда, то нет. Свежий анализ Anthropic показывает, что ещё толком ничего не началось.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
На этой картинке изображены потенциальные возможности LLM в каждой отрасли и реальное использование на сегодняшний день. Так, небольшие подергивания в области ИТ, финансов, продаж и администрирования.
Как считали потенциальный эффект: это картинка на основе исследования Eloundou, Tyna, Sam Manning, Pamela Mishkin, and Daniel Rock (2023) "Gpts are gpts: An early look at the labor market impact potential of large language models", препринт: https://arxiv.org/abs/2303.10130
Что они сделали: взяли базу американского бюро трудовой статистики O*NET, в которой перечислены все виды рабочих занятий в США и описаны их основные рабочие задачи (DWA - Detailed Work Activities). Потом каждую задачу оценили по уровню потенциального замещения LLM. Было три категории:
1. Эту задачу LLM не может выполнить с должным качеством или быстрее, чем человек
2. Эту задачу LLM может выполнить на 50% быстрее или ещё быстрее без потери качества и без дополнительной обвязки
3. Эту задачу LLM сможет выполнить, если ей дать дополнительную обвязку — например, подключить к корпоративной базе данных, дать возможность выполнять какие-то действия в Интернете, приделать глазки (запись и распознавание изображений и видео) и ручки.
Всего они вытащили из базы O*NET 19265 рабочих задач и 2087 DWA (они повторяются в разных задачах).
Потом каждую DWA оценивал человек и GPT-4, эти оценки сравнивались. В целом, где-то на уровне 65-80% оценки человека и GPT совпали.
Так получилась потенциальная оценка. Красная область — это фактически измеренные задачи, для которых люди применяют Claude. Например, в области Computer & Math сейчас Claude решает 33% типов задач, а может 94%.
Оценка потенциально решаемых задач оптимистичная, да и данные O*NET довольно специфические — я, например, не нашел там бизнес-аналитиков, а системные аналитики (Computer Systems Analyst) у них по задачам скорее "техподдержка для сложных случаев".
В общем, всё пока выглядит, как распространение Интернета и веба на ранних стадиях: не взрыв, а скорее затопление. Вроде только что научился электронную почту отправлять и искать информацию, смотришь — прошло несколько лет, и ты уже весь день в этом Интернете торчишь, у тебя там и работа, и учеба, и покупки, и фотографии, и общение, и развлечения.
Кажется, ИИ идёт примерно по такому пути — понемногу, по чуть-чуть, оглянуться не успеем, как везде и всё будет ИИ.
1👍18🤔5
8 марта я традиционно пишу про великих женщин в ИТ.
И сегодня, чем дольше я изучал материалы о героине поста, тем чаще у меня в голове вертелись фразы: "Офигеть!", "Так не бывает!" и, наконец: "Возможно всё!"
Итак, знакомьтесь: Каринэ Назарян. Или Джоанна Хоффман, на западный манер.
Родилась в 1955 году в Польше, в семье режиссера Ежи Гоффмана, и с 9 месяцев жила с матерью в Армении (родители познакомились в Москве). Родственники Каринэ работали в кино, например, с Параджановым — в доме висели раскадровки его фильмов. Но киношные люди казались ей слишком суматошными, и она с детства мечтала стать физиком, вдохновляясь двоюродным братом-астрономом.
С 10 до 13 лет жила в Польше у дедушки с бабушкой, а потом переехала в США к матери, которая уехала чуть раньше (это отдельная трагическая история — как это, эмигрировать из Советского Союза в США в конце 60-х? Оказывается, Сталин после войны приглашал армян со всего мира приезжать в СССР, вот только места в советской Армении для всех не хватило, поэтому большинство репатриантов отправили... в Сибирь. Вернуться обратно в свои страны им удалось лишь при Хрущеве).
США оказались не таким клёвым местом, как виделось из СССР, ещё и язык нужно было учить, но Джоанну после двух месяцев в американской школе в бедном районе перевели сначала в из 7 в 8 класс, ещё через два месяца — в 9, а потом посоветовали пойти в частную школу и готовиться к поступлению в колледж. Джоанна учила английский, а бабушка из Польши присылала ей советские учебники по математике.
В итоге она попала в MIT на свою любимую физику, и обнаружила себя полностью в своей среде. Однако к концу обучения поняла, что физика всё-таки слишком сложная, и науки о людях её интересуют не в меньшей степени. В поисках области, совмещающей эти два направления, она занялась археологией и древней историей, но с точки зрения технологий обработки и изготовления материалов — идеальное сочетание физики и гуманитарных наук!
В качестве объекта исследований выбрала Урарту — древнее государство между современными Арменией, Турцией и Ираном. По туристической визе въехала в СССР, пошла к Борису Пиотровскому — директору Эрмитажа, академику и крупнейшему специалисту по Урарту, и договорилась с ним об исследованиях. Он поддержал американку и направил её на раскопки в Армению. 9 месяцев в Джоанна жила в СССР с просроченной визой, притворялась 15-летним подростком без паспорта и занималась археологией.
По возвращении в США она защитила диссертацию и поехала в Иран, чтобы продолжить исследования, но по дороге заехала к бабушке в Польшу, а в Иране в это время как раз началась исламская революция. Так что Джоанне пришлось вернуться в США и думать, что делать дальше.
Ещё в MIT она тусила с ребятами из BBN (компания, которую называли "третьим университетом" в Кембридже, после MIT и Гарварда), дружила с дочерью "отца искусственного интеллекта" Марвина Минского и Синтией Соломон — создательницей обучающего языка Logo (вместе с Сеймуром Пейпертом). Кто-то из них позвал её в Xerox PARC, подработать тестировщиком интерфейсов их компьютера Alto — первого компьютера с GUI.
На семинаре в PARC она вскоре познакомилась с Джефом Раскиным, и долго обсуждала принципы и способы применения персональных компьютеров. В результате он позвал её в свой новый проект Apple Macintosh, 5-м участником. Приходилось делать все понемногу, даже паять, но в основном Джоана работала над интерфейсами в широком смысле — от клавиатуры до GUI, и составила первую версию Macintosh User Interface Guidelines — инструкцию, заложившую основные принципы построения интерфейсов приложений на Маках.
А потом как-то раз в офис команды зашел Стив Джобс, и сказал — ты кто? Будешь заниматься маркетингом. С тех пор Джоана Хоффман известна, как руководитель маркетинговой команды Macintosh, NeXT, "правая рука" Стива Джобса и единственный человек, который мог "выстоять перед Стивом и вразумить его".
Вот такая история великой женщины. С праздником! Помните: возможно всё!🌷 🌷 🌷
И сегодня, чем дольше я изучал материалы о героине поста, тем чаще у меня в голове вертелись фразы: "Офигеть!", "Так не бывает!" и, наконец: "Возможно всё!"
Итак, знакомьтесь: Каринэ Назарян. Или Джоанна Хоффман, на западный манер.
Родилась в 1955 году в Польше, в семье режиссера Ежи Гоффмана, и с 9 месяцев жила с матерью в Армении (родители познакомились в Москве). Родственники Каринэ работали в кино, например, с Параджановым — в доме висели раскадровки его фильмов. Но киношные люди казались ей слишком суматошными, и она с детства мечтала стать физиком, вдохновляясь двоюродным братом-астрономом.
С 10 до 13 лет жила в Польше у дедушки с бабушкой, а потом переехала в США к матери, которая уехала чуть раньше (это отдельная трагическая история — как это, эмигрировать из Советского Союза в США в конце 60-х? Оказывается, Сталин после войны приглашал армян со всего мира приезжать в СССР, вот только места в советской Армении для всех не хватило, поэтому большинство репатриантов отправили... в Сибирь. Вернуться обратно в свои страны им удалось лишь при Хрущеве).
США оказались не таким клёвым местом, как виделось из СССР, ещё и язык нужно было учить, но Джоанну после двух месяцев в американской школе в бедном районе перевели сначала в из 7 в 8 класс, ещё через два месяца — в 9, а потом посоветовали пойти в частную школу и готовиться к поступлению в колледж. Джоанна учила английский, а бабушка из Польши присылала ей советские учебники по математике.
В итоге она попала в MIT на свою любимую физику, и обнаружила себя полностью в своей среде. Однако к концу обучения поняла, что физика всё-таки слишком сложная, и науки о людях её интересуют не в меньшей степени. В поисках области, совмещающей эти два направления, она занялась археологией и древней историей, но с точки зрения технологий обработки и изготовления материалов — идеальное сочетание физики и гуманитарных наук!
В качестве объекта исследований выбрала Урарту — древнее государство между современными Арменией, Турцией и Ираном. По туристической визе въехала в СССР, пошла к Борису Пиотровскому — директору Эрмитажа, академику и крупнейшему специалисту по Урарту, и договорилась с ним об исследованиях. Он поддержал американку и направил её на раскопки в Армению. 9 месяцев в Джоанна жила в СССР с просроченной визой, притворялась 15-летним подростком без паспорта и занималась археологией.
По возвращении в США она защитила диссертацию и поехала в Иран, чтобы продолжить исследования, но по дороге заехала к бабушке в Польшу, а в Иране в это время как раз началась исламская революция. Так что Джоанне пришлось вернуться в США и думать, что делать дальше.
Ещё в MIT она тусила с ребятами из BBN (компания, которую называли "третьим университетом" в Кембридже, после MIT и Гарварда), дружила с дочерью "отца искусственного интеллекта" Марвина Минского и Синтией Соломон — создательницей обучающего языка Logo (вместе с Сеймуром Пейпертом). Кто-то из них позвал её в Xerox PARC, подработать тестировщиком интерфейсов их компьютера Alto — первого компьютера с GUI.
На семинаре в PARC она вскоре познакомилась с Джефом Раскиным, и долго обсуждала принципы и способы применения персональных компьютеров. В результате он позвал её в свой новый проект Apple Macintosh, 5-м участником. Приходилось делать все понемногу, даже паять, но в основном Джоана работала над интерфейсами в широком смысле — от клавиатуры до GUI, и составила первую версию Macintosh User Interface Guidelines — инструкцию, заложившую основные принципы построения интерфейсов приложений на Маках.
А потом как-то раз в офис команды зашел Стив Джобс, и сказал — ты кто? Будешь заниматься маркетингом. С тех пор Джоана Хоффман известна, как руководитель маркетинговой команды Macintosh, NeXT, "правая рука" Стива Джобса и единственный человек, который мог "выстоять перед Стивом и вразумить его".
Вот такая история великой женщины. С праздником! Помните: возможно всё!
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉66🔥38❤22👏4🤩3
Systems.Education закрывается. 15 лет учили аналитиков!
Можно сказать, сформировали этот рынок и, хочется верить, оказали определённое влияние.
Очень жаль. Такие дела.
Можно сказать, сформировали этот рынок и, хочется верить, оказали определённое влияние.
Очень жаль. Такие дела.
😭34🤯3🥱1
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Школа Systems Education закрывается
Спасибо, что были с нами: приходили на обучение, оставляли отзывы, читали наш канал и статьи на сайте, смотрели вебинары и участвовали в конференциях. Вместе с вами мы развивали индустрию и повышали уровень проектирования систем.
До конца марта на этом канале вас ждут интересные посты, которые подготовили наш маркетолог Алёна Кудрявцева, карьерный коуч Кристина Годовых и авторы, с которыми мы сотрудничаем.
Поддержите нас: прямо сейчас оплатите участие на курсе, воркшопе или лабораторной. Тем более что они будут последние. Мы проводим учебные потоки до начала июня — и на этом всё. Это позволит нам выплатить зарплаты и закрыть школу без долгов.
Перейти в расписание
Перешлите, пожалуйста, друзьям, коллегам и в свои блоги
Денис Бесков, Основатель, Владелец
Спасибо, что были с нами: приходили на обучение, оставляли отзывы, читали наш канал и статьи на сайте, смотрели вебинары и участвовали в конференциях. Вместе с вами мы развивали индустрию и повышали уровень проектирования систем.
До конца марта на этом канале вас ждут интересные посты, которые подготовили наш маркетолог Алёна Кудрявцева, карьерный коуч Кристина Годовых и авторы, с которыми мы сотрудничаем.
Поддержите нас: прямо сейчас оплатите участие на курсе, воркшопе или лабораторной. Тем более что они будут последние. Мы проводим учебные потоки до начала июня — и на этом всё. Это позволит нам выплатить зарплаты и закрыть школу без долгов.
Перейти в расписание
Перешлите, пожалуйста, друзьям, коллегам и в свои блоги
Денис Бесков, Основатель, Владелец
systems.education
Школа системного анализа и проектирования информационных систем Systems.Education
Более 14 лет обучаем проектированию информационных систем. Бизнес-анализ, инженерия требований, системный анализ и проектирование для разработки и интеграции информационных систем, веб-сервисов и мобильных приложений. Мы авторы профстандартов системного аналитика…
💔58😭30😢8😱4👀2
Собираетесь ли вы в этом году проходить обучение?
Anonymous Poll
21%
Да, на курсах за свои деньги
5%
Да, с ментором за свои деньги
9%
Да, компания оплачивает внешние курсы
13%
Да, на внутренних курсах компании
52%
Собираюсь учиться самостоятельно по статьям, книгам, видео
40%
Собираюсь учиться самостоятельно с помощью ИИ
16%
Нет, в этом году учиться не планирую
Этот день в истории:
12 марта 1455 года — будущий Папа Пий II в письме упоминает Библию Гуттенберга — первую печатную книгу. Это первое свидетельство о существовании такой диковины.
12 марта 1989 года — Тим Бернерс-Ли представил проект WWW ("день рождения Интернета, как мы его знаем").
12 марта 2006 года — организация "▒▒▒▒▒▒▒▒▒ без ▒▒▒▒▒▒" (объявлена нежелательной организацией в РФ) объявила этот день Днем протеста против ▒▒▒▒▒-▒▒▒▒▒▒▒.
В общем, всё одно к одному, всё про свободный обмен информацией и распространение знаний.
12 марта 2026 года — у меня сегодня день рождения, надеюсь, я в русле этого движения, и приношу вам новую интересную информацию!
12 марта 1455 года — будущий Папа Пий II в письме упоминает Библию Гуттенберга — первую печатную книгу. Это первое свидетельство о существовании такой диковины.
12 марта 1989 года — Тим Бернерс-Ли представил проект WWW ("день рождения Интернета, как мы его знаем").
12 марта 2006 года — организация "▒▒▒▒▒▒▒▒▒ без ▒▒▒▒▒▒" (объявлена нежелательной организацией в РФ) объявила этот день Днем протеста против ▒▒▒▒▒-▒▒▒▒▒▒▒.
В общем, всё одно к одному, всё про свободный обмен информацией и распространение знаний.
12 марта 2026 года — у меня сегодня день рождения, надеюсь, я в русле этого движения, и приношу вам новую интересную информацию!
3🔥38🍾33❤18🎉8👍1
Наблюдаю интересный дрейф в функциях аналитиков. Уже в нескольких крупных компаниях вижу, что бизнес-аналитиков всё больше и больше нагружают техническими деталями: спецификацией данных, описанием исключений и краевых случаев, обработки ошибок. Ну потому что системный аналитик не может сказать, что нужно делать при возникновении такой ошибки. Бизнесу-то как нужно? Вы расскажите. И дайте примеры данных в виде json.
Задачи системных аналитиков при этом тоже смещаются в сторону техники: описания интеграций, структур и форматов данных — как для транспорта, так и для хранения, стратегии надежности обмена и повторных вызовов.
В результате такой работы у системного аналитика получается техническая спецификация, практически непригодная для чтения обычным человеком — формальные спеки API, схемы данных.
Но и у бизнес-аналитиков получается не лучше — в деталях теряется общая картина, и, например, тестировщики уже перестают понимать — а как и для чего оно должно работать? При такой степени проработки теряется описание бизнес-возможности и потребностей. А схемы бизнес-процессов, которые ещё где-то сохраняются как форма, по содержанию отражают скорее взаимодействие систем при интеграции.
Поэтому описание потребностей бизнеса всё чаще возлагают... на сам бизнес. А так как они этого никогда не делали и не владеют инструментами, получается, ну, так. С помощью ИИ даже ещё смешнее — объем большой, а акценты расставлены почти случайно. За что стат.модель зацепилась, о том и говорит. Проконтролировать это у бизнес-заказчиков не хватает квалификации и понимания, что эти слова вообще-то должны что-то означать и для чего-то в дальнейшем использоваться. Возникает синдром студента: "а мы думали, вам просто какой-то текст по теме нужен, ну вот ИИ какой-то сгенерил, разве это не подходит?"
Так как с потребностями бизнеса всё-таки нужно разбираться (ну, хотя бы иногда), БА на это уже не способны, а СА вообще к людям не пускают, эта задача отъезжает к... UX-исследователям.
Ну правда, им же по роли положено разговаривать с пользователями!
Вот пусть и расскажут, что этим пользователям, в конце концов, нужно.
Поэтому процесс становится примерно таким:
* СА находит в постановке непрописанный вариант, просит БА его описать.
* БА идёт к UX-ресерчеру и спрашивает — как пользователям будет удобно в этом случае, что им нужно? Ну ты же с ними говорила уже, выясни этот момент тоже. И дай сразу макет интерфейса, я вставлю в документ.
* UX действительно говорил с пользователями, но совершенно по другим вопросам и по рандомизированной выборке. А делать ещё одно исследование из-за такого мелкого вопроса довольно накладно. Кроме того, переворачивается ответственность: БА просит принести уже готовый макет (принятое решение), который нужно сделать совместно с дизайнером. То есть, не дизайнер получает постановку задачи от БА, а наоборот — БА хочет готовое решение, которое откуда-то извне возьмется, а он только зафиксирует.
В этой ситуации функция управления и координации фактически перекладывается на UX-исследователя, который вообще говоря исследователь, а не менеджер. Иногда в этой цепочке всё-таки возникает какой-то младший продакт (если такая роль вообще есть), фактически — фича-оунер.
Но если нет — ситуация решается случайным образом. Так как фичу кто-то всё же должен дотащить до прода, но никто не хочет принимать решения, всё превращается в игру "горячая картошка" с перебрасыванием ответственности друг-другу до первого, кто сдастся и возьмет функцию ситуационного лидера на себя. Это может быть кто угодно — UX, БА, дизайнер, кто-то из менеджеров, иногда даже тестировщик. Я даже видел лида поддержки в этой роли.
Или же фича так и останется бесхозной, и в каком-то виде доедет до прода без хозяина. Решения в этой ситуации, скорее всего, будут приняты случайными людьми и без надежных оснований. Оценку решений получит опять же либо поддержка, либо UX в ходе очередного скрининга.
Такой вот процесс, сталкивались с таким? И что делать, если в команде не предусмотрен UX?
Задачи системных аналитиков при этом тоже смещаются в сторону техники: описания интеграций, структур и форматов данных — как для транспорта, так и для хранения, стратегии надежности обмена и повторных вызовов.
В результате такой работы у системного аналитика получается техническая спецификация, практически непригодная для чтения обычным человеком — формальные спеки API, схемы данных.
Но и у бизнес-аналитиков получается не лучше — в деталях теряется общая картина, и, например, тестировщики уже перестают понимать — а как и для чего оно должно работать? При такой степени проработки теряется описание бизнес-возможности и потребностей. А схемы бизнес-процессов, которые ещё где-то сохраняются как форма, по содержанию отражают скорее взаимодействие систем при интеграции.
Поэтому описание потребностей бизнеса всё чаще возлагают... на сам бизнес. А так как они этого никогда не делали и не владеют инструментами, получается, ну, так. С помощью ИИ даже ещё смешнее — объем большой, а акценты расставлены почти случайно. За что стат.модель зацепилась, о том и говорит. Проконтролировать это у бизнес-заказчиков не хватает квалификации и понимания, что эти слова вообще-то должны что-то означать и для чего-то в дальнейшем использоваться. Возникает синдром студента: "а мы думали, вам просто какой-то текст по теме нужен, ну вот ИИ какой-то сгенерил, разве это не подходит?"
Так как с потребностями бизнеса всё-таки нужно разбираться (ну, хотя бы иногда), БА на это уже не способны, а СА вообще к людям не пускают, эта задача отъезжает к... UX-исследователям.
Ну правда, им же по роли положено разговаривать с пользователями!
Вот пусть и расскажут, что этим пользователям, в конце концов, нужно.
Поэтому процесс становится примерно таким:
* СА находит в постановке непрописанный вариант, просит БА его описать.
* БА идёт к UX-ресерчеру и спрашивает — как пользователям будет удобно в этом случае, что им нужно? Ну ты же с ними говорила уже, выясни этот момент тоже. И дай сразу макет интерфейса, я вставлю в документ.
* UX действительно говорил с пользователями, но совершенно по другим вопросам и по рандомизированной выборке. А делать ещё одно исследование из-за такого мелкого вопроса довольно накладно. Кроме того, переворачивается ответственность: БА просит принести уже готовый макет (принятое решение), который нужно сделать совместно с дизайнером. То есть, не дизайнер получает постановку задачи от БА, а наоборот — БА хочет готовое решение, которое откуда-то извне возьмется, а он только зафиксирует.
В этой ситуации функция управления и координации фактически перекладывается на UX-исследователя, который вообще говоря исследователь, а не менеджер. Иногда в этой цепочке всё-таки возникает какой-то младший продакт (если такая роль вообще есть), фактически — фича-оунер.
Но если нет — ситуация решается случайным образом. Так как фичу кто-то всё же должен дотащить до прода, но никто не хочет принимать решения, всё превращается в игру "горячая картошка" с перебрасыванием ответственности друг-другу до первого, кто сдастся и возьмет функцию ситуационного лидера на себя. Это может быть кто угодно — UX, БА, дизайнер, кто-то из менеджеров, иногда даже тестировщик. Я даже видел лида поддержки в этой роли.
Или же фича так и останется бесхозной, и в каком-то виде доедет до прода без хозяина. Решения в этой ситуации, скорее всего, будут приняты случайными людьми и без надежных оснований. Оценку решений получит опять же либо поддержка, либо UX в ходе очередного скрининга.
Такой вот процесс, сталкивались с таким? И что делать, если в команде не предусмотрен UX?
🤯20💯14🤔9🔥6👍3