Зацепила фраза, что, мол, если бы во времена СССР должным образом бы уделяли внимание применению ТРИЗ, то это помогло бы избежать дальнейшей экономической катастрофы.
На мой взгляд, если в этой точке зрения и есть зерно истины, то лишь отчасти. ТРИЗ позволяет решать творческие задачи в области техники, если быть точным, то только в некотором подмножестве. Например, классический ТРИЗ не решает задачи в области электроники.
Вторая проблема - умение решать творческие задачи - это лишь маленькая толика из того, что надо для того, чтобы разработать технически и технологически сложный продукт. Помимо творчества нужны еще и инженерные усилия. ТРИЗ никак не затрагивает этого аспекта. Более того, в своей книге "Найти идею" Генрих Саулович отвергает идею создать информационную систему для проектирования ювелирных изделий. С момента написания книги уже прошло ~35 лет. И мы можем сказать, что информационные системы, помогающие спроектировать техническую систему, получили широкое распространение (это разнообразные САПР), а вот экспертные системы, помогающие сделать изобретение, хоть и существуют, но, увы, не так широко. Реальная практика оказалась против прогноза. И помощь в конструировании (проектировании) оказалась важнее креатива.
вторник, 4 октября 2016 г.
среда, 3 августа 2016 г.
Постановка процесса разработки в отделе инструментария игровой студии
Выкладываю видеозапись моего выступления на IT Global Meetup, который проходил 23 июля 2016 года в Санкт-Петербурге. Тема выступления - процесс разработки, который мы используем.
четверг, 30 июня 2016 г.
Грубая оценка проекта
Выкладываю свою презентацию с апрельского митапа руководителей проектов о том, как делать грубую оценку проекта.
Речь пойдет о мультимодельности - для того, чтобы получить как можно более точную оценку, лучше всего использовать несколько моделей.
Речь пойдет о мультимодельности - для того, чтобы получить как можно более точную оценку, лучше всего использовать несколько моделей.
среда, 25 июня 2014 г.
Могу рекомендовать: online-лекции И.Л. Викентьева о творчестве
По многочисленным просьбам иногородних Читателей
интеллектуального портала VIKENT.RU, с осени-2014 начинаются бесплатные лекции
И.Л. Викентьева о творческих личностях / коллективах.
Параметры online-лекций:
1) В основе лекций - крупнейшая в Европе база данных по технологиям творчества, содержащая уже около 50 000 материалов;
2) Данная база данных собиралась в течение 35 лет и легла в основу портала VIKENT.RU
воскресенье, 25 мая 2014 г.
Для чего нужны ежедневные отчёты?
Контекст
1. Команда
разработчиков работает над популярной
видеоигрой.
2. Предполагаемый
тираж игры – свыше 10 миллионов копий.
3. Размер
команды – 100 человек.
4. В
разработке принимают участие команды
из трёх стран.
5. Разница
во времени между командами достигает
12 часов.
6. Сроки
выпуска игры не сдвигаются ни
на день.
7. На
проекте заняты специалисты разных – в
том числе, творческих – специальностей:
маркетологи, менеджеры, программисты,
3D моделлеры,
аниматоры, художники, дизайнеры интерфейса
и др.
Как
координировать работу всех этих людей?
понедельник, 19 августа 2013 г.
Распространённые мифы о классическом процессе разработки
Классический
процесс разработки программного
обеспечения делится на 3 этапа:
pre-production,
production и post-production.
На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.
Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.
На этапе post-production — исправляются остальные баги.
К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.
На этапе pre-production вырабатывается концепция продукта, разрабатывается его более-менее детальный дизайн, выполняется техническое проектирование и создаётся демонстрационная версия продукта, которая способна подтвердить правильность первоначальной задумки.
Во время production разрабатывается сама программа, т.е. делаются фичи (features). На этом этапе основная масса багов не исправляется – исправляются только критические баги, которые связаны с неправильным функционированием фич или которые блокируют усилия тестеров по проверке фич.
На этапе post-production — исправляются остальные баги.
К сожалению, применению такого подхода во многих российских компаниях мешают две вещи. Первая вещь – это элементарная лень руководства. (Согласитесь, куда проще говорить, что команда должна сама eliminate wastes, чем наладить процесс производства.) А вторая вещь – устоявшиеся мифы. И если с ленью я ничего не могу поделать, то мифы – постараюсь развеять.
пятница, 9 августа 2013 г.
Миф о точном планировании
Почему-то считается, что планы и оценки создаются для того, чтобы потом точно (тютелька в тютельку) в них вписаться. В этом утверждении заключается распространённая ошибка. Бытует утверждение, что если какой-либо из планов не был выполнен или время выполнения какой-либо задачи не совпало с первоначальной оценкой, то план — сорван, а прогноз — неправильный.
Такой подход считаю в корне неверным. Планы и оценки делаются совсем для другой цели
Такой подход считаю в корне неверным. Планы и оценки делаются совсем для другой цели
Подписаться на:
Сообщения (Atom)