Эта статья будет представлять собой анализ нескольких уроков по UX/UI, которые мы получили, внимательно наблюдая на выставке за парой сотен людей, занимавшихся плейтестингом ранней сборки нашей игры Steamhounds.


Для понимания контекста скажу, что Steamhounds — это пошаговая игра, смесь JRPG и тактического боя на сетке. Игроки могут сражаться против ИИ, но мы по возможности стремились мотивировать их играть друг против друга, сидя рядом за разными мониторами.

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

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

Оригинал: Starting out on Game Programming

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

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

Руководства хороши для обучения чему-то шаг за шагом, например тому, как перемещать изображение точки по экрану. Для того чтобы собрать игру воедино, вам нужны навыки решения возникающих проблем, приобретаемые лишь с опытом. Это не то, чему можно научиться из руководств. Лучший способ научиться делать игры — это начать их делать.

Разработка мобильных игр — отрасль с очень высокой конкуренцией. Миллионы игр в Google Play и Apple Store, позабытые пользователями сразу после запуска, и редкие истории успеха тому свидетельство. В очередном посте блога «Менеджмент игровых интернет-проектов» мы перевели статью разработчика игр Росса Пшибыльски (Ross Przybylski) о расчёте потенциального дохода мобильных игр F2P. За свою десятилетнюю карьеру Росс успел набраться опыта и в инди-студиях (D20Studios), и в крупных AAA-компаниях (EA).

Сегодня я расскажу о больной теме как для покупателей программного обеспечения, так и для провайдера этой услуги – себестоимости разработки. Понятно, что сейчас не самое лучшее время для того, чтобы разбрасываться бюджетами. Только это не значит, что производители должны работать себе в убыток. Многие говорят о жадности предпринимателей, но я вам вот что скажу: нет ничего постыдного в том, чтобы делать честный бизнес и адекватно считать свои косты.

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

В моем списке чтения накопилось немало интересных ресурсов (какие-то из них более известны, какие-то нет), так что я решил поделиться им с аудиторией Хабра.

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

Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

Сегодня публикуем статью нашего коллеги Дмитрия Коткина, уже полюбившегося хабровчанам по теме противостояния давлению в переговорах.

Признаться, мы долго думали, публиковать ли этот материал, потому что тема денег — крайне неоднозначна, и всегда поляризует аудиторию. Более того, статья была написана не для ИТ-шников. Но в конце концов решили статью запостить, потому что приемы там изложены, как нам показалось, достаточно универсальные, и в конце концов там не предлагается вести себя на собеседовании как здесь:

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

Больше года я занимаю должность технического лидера в своей компании, и хочется поделиться наработками по теме. Имеет смысл уточнить: я веду отдел iOS-разработки из 10 человек в компании-аутсорсере. В моём случае должность подразумевает оптимизацию работы отдела, распределение задач между разработчиками и активности, связанные с программированием. Расскажу немного о своём опыте, наработках и умозаключениях. Статья может быть полезна прежде всего новичкам на аналогичной должности, либо тем, кто на неё метит. Какие-то практики и принципы могут быть переносимы на обычную разработку, на другие платформы или даже другие специальности.

Взявшись за этот пост, автор полностью отдает себе отчет. И в том что «набило оскомину». И что «только ленивый не кинул камень». И про то что «хватит уже, достали». Однако, вдоволь начитавшись доморощенных и не очень аналитиков, автор решил все-таки выразить собственное мнение, которое отличается от того общепринятого, что с некоей мазохистской истомой доселе перепечатывалось здесь и тут различными авторами, интерпретаторами и переводчиками. Вероятно кому-то будет интересно его прочитать.

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

Вступление

К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:

• выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
  
• и презентацию Сергея Бережного
  «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.
  

Статья содержит такие разделы:

• Украинские реалии при выполнении проекта
• Проблемы и их решения
• Подготовка к оценке
• Перечень работ для оценивания
• Оценка работ по написанию кода
• Цифры и коэффициенты из практики
• Пример расчета

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

Здесь изложена суть книги в объеме меньшем 1% объема книги, по моей оценке. Все вопросы освещены так, как я их понял, что необязательно совпадает с тем, как их хотел донести автор.

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?