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

Помните, как компания Microsoft завоевывала рынок? Они выпускали программное обеспечение, которое шло в дополнение к компьютерам. Но ведь с их точки зрения, — это компьютеры дополняли ПО. Они стремились сделать компьютеры взаимозаменяемыми, что снижало бы их стоимость и в свою очередь способствовало росту цен на софт и его распространению.

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

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

Проблемы разработки

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


Читать дальше →

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

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

1. Кто будет работать с модулем? — нужно найти людей, которые непосредственно будут использовать инструмент и с ними решать дальнейшие вопросы
2. Какие именно действия будет совершать пользователь? нужно понять, что должен делать модуль приложения. От этого сильно зависит интерфейс пользователя.
3. Будет ли пользователю удобно работать, при определенной раскладке окон и элементов интерфейса? — Очень важный вопрос, которому очень часто вообще не уделяют внимания.

Читать дальше →