Проектирование для начинающих: Советы для начинающих проектировщиков – с чего начать работу

Содержание

Советы для начинающих проектировщиков – с чего начать работу

Архив рассылки «Непрошеные советы» для начинающих проектировщиков. Выпуск № 1.

Доброе утро! Приятно с Вами познакомиться поближе! Меня зовут Ирина, и я затеяла эту рассылку для начинающих проектировщиков, а если точнее – для всех, чья работа связана с КЖ. В 2005 году я закончила университет, работать по специальности я начала чуть раньше. И уже тогда стало ясно, насколько теория учебы отличается от практики на работе. Новичку дают самое простое – чертежи изделий, простенькие планы, незатейливые схемы. Но и это вызывает массу вопросов, сомнений. И, к сожалению, не у каждого есть возможность спросить у старшего, более опытного человека. Т.к. мне повезло с учителями, хочу поделиться своими знаниями с теми, кому повезло меньше. В этой рассылке я буду выкладывать небольшие полезные материалы для начинающих и не только. Постараюсь уделить внимание оформлению чертежей, упрощению работы и соблюдению норм. Предупреждаю сразу: я живу на территории Украины и пользуюсь украинскими нормативными документами. Ссылаться буду на них же. Иногда – на старые советские нормы (если наши современные подкачали – к сожалению, и так бывает, или просто еще не вышли).

Итак, темой первой рассылки будут непрошеные советы начинающим проектировщикам.

Мне проверять чертежи доводится постоянно, и список достоинств и недостатков начинающих (и далеко не начинающих) инженеров уже сформировался. О достоинствах поговорим позже, сейчас приведу список, чего не нужно делать грамотному инженеру в своей работе:

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

2) Не нужно игнорировать нормативные документы. Это правило номер один, хоть я и поставила его во второй пункт. Инженер, не знающий норм – это техник. Первым делом, идите в библиотеку и сгребайте все, что видите. Нет библиотеки – скачивайте и распечатывайте (распечатывать – обязательно). Если на работе Вам дадут совет завести тетрадку, в которую будете выписывать необходимую информацию из нормативных документов – не делайте этого, это тупиковый путь. Да, Вы будете знать свою тетрадку, как пять пальцев – даже во сне сможете отыскать в ней, как называется уголковый сварной шов и по какому ДСТУ он выполняется. Но если Вы один раз запишете эту информацию в свою тетрадь, то после этого ни разу не заглянете еще раз в тот самый ДСТУ, не прочитаете сносок и примечаний, не заметите множество важной и полезной информации. Да, можно говорить, что в нормах искать дольше и сложнее, что тетрадка – это краткий конспект, экономящий время. Так вот, время можно экономить на чем угодно, но не на изучении норм. При любом случае листайте нормы и изучайте написанное. Когда ищете одно, попадается много полезной информации, которая оседает в голове, а в нужной ситуации обязательно всплывет. Для начала я дам в конце этой рассылки список литературы по оформлению чертежей. Не обращайте внимание на годы издания, ничего нового с того времени не изобрели. И как только начинаете новый чертеж, заглядывайте в нормы, а не в примеры подобных чертежей, выполненных коллегами. Да, примеры полезны, но «мы всегда так делаем» — это не оправдание безграмотности.

3) Не верьте на слово своим коллегам, даже стоящим выше по должности. Я не говорю, что нужно высказывать сомнения всему, что Вы услышали. Но если к Вам пришла информация, проверьте ее, прежде чем применить в своем чертеже или расчете. Найдите подтверждение в нормах, или просто спросите у человека, где искать. Делайте так всегда. Во-первых, люди могут ошибаться, а за Вашу работу отвечаете Вы, а не советчики. Во-вторых, опять-таки Вас может подвести любимая поговорка ленивых «мы всегда так делаем», я чувствую, что не раз о ней еще вспомню. Помните: нужно быть благодарным человеку за информацию, но эту информацию всегда надо перепроверить. Пусть не сразу, а позже. Это убережет Вас от многих рисков и повысит квалификацию в разы. И еще. Не верьте проверяющим (пусть они об этом не догадываются, но не верьте). Все замечания к Вашим чертежам перепроверяйте в нормах. Ищите подтверждения или несоответствия. И умейте отстаивать свою правоту, а точнее правоту норм. Да, возможно, сразу это не получится. Возможно, придется сделать так, как говорит руководитель, даже если это противоречит сказанному в нормах. Но Вы будете знать, что так делать нельзя, и со временем (у меня на некоторые случаи уходили годы), Вы все равно будете делать правильно, а не так, как кто-то привык. Запомните: нормы – это защита инженера. Если случилась авария, а Вы сделали все согласно требованию современных норм, то Вашей вины просто нет. Поэтому учитесь защищаться своей грамотностью. И начинайте с мелочей.

4) Не молчите, если не знаете, как что-то сделать – всегда задавайте вопросы. Я сталкивалась с людьми, которые проработав год-два, стеснялись спрашивать у ведущих, как им поступить, какое решение принять. Это тупиковая позиция. Оптимальные решения находятся в обсуждении, а иногда и в дискуссии. Не смотря на опыт работы, на категорию, на годы, проведенные в этой отрасли, всегда старайтесь уточнить все вопросы в начале пути, а не тогда, когда будет уже поздно. Ведущий будет лишь рад вовремя заданным вопросам (а не будет – это его проблемы), это реальная помощь тем, кто стоит в инженерной иерархии выше по должности. Вопросы – это признак развивающегося инженера, не забывайте об этом. Задавайте их сразу, не тяните, потом будет меньше времени на выполнение работы.

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

А вот обещанный, довольно краткий список литературы по оформлению чертежей:

  • Руководство по конструированию бетонных и железобетонных конструкций из тяжелого бетона (без предварительного напряжения). Москва, 1978 г.
  • И.Н. Тихонов. Армирование элементов монолитных железобетонных зданий. Пособие по проектированию. Москва, 2007 г. (многое взято с руководства, но картинки скопированы не особо качественно).
  • ДСТУ Б А.2.4-4:2009 Основные требования к проектной и рабочей документации.
  • ДСТУ Б А.2.4-7:2009 Правила выполнения архитектурно-строительных рабочих чертежей.

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

class=»eliadunit»>
Добавить комментарий

118 обучающих уроков для проектировщиков. Как это было

Согласитесь, что весна 2020 была довольно интересным временем. В марте большая часть инженерного мира осталась дома на самоизоляции. Пока все проживали стадии «отрицание-страх-гнев-принятие», мы в «Нанософт» подумали, что мы можем сделать для наших пользователей. А затем собрали команду наших продактов, провели мозговой штурм и буквально за неделю запустили Инженерную online-школу. Мы среагировали первыми.

Использовали ресурсы с пользой для общества


Сначала мы взяли флагманские продукты «Нанософт». Наша школа проводила два урока в день. Спустя неделю, увидев огромный интерес аудитории, мы подключили все остальные продукты портфеля «Нанософт». Количество курсов увеличилось втрое, а число ежедневных online-лекций возросло до четырех. Мы провели обучение по всей линейке nanoCAD, Solid Edge, ARCHICAD, PADS Professional, Femap, Model Studio CS, CADLib, Spotlight, PlanTracer Pro. По окончании курсов nanoCAD слушатели получили сертификаты участников.

Мастер-классы на высоком уровне


В основе курсов лежали тест-драйвы, по которым наши технические специалисты успешно проводят обучение в компаниях, а также в авторизованных учебных центрах. Вскоре они дополнились авторскими курсами руководителей направлений. Так, например, технический директор «Нанософт» Денис Ожигин разработал на базе конструкторской модели серию уроков, посвященных моделированию, специфицированию, документированию и совместной работе в едином комплексе nanoCAD Конструкторский BIM + CADLib. Денис Ожигин и BIM-менеджер Виталина Балашенкова показали в режиме реального времени открытое информационное моделирование в связке «архитектор – конструктор»: продемонстрировали обмен данными между смежными специалистами посредством облачного хранилища, совместную настройку BIM-модели по требованиям заказчика и др. Алексей Гепта, руководитель проекта nanoCAD Машиностроение, выступил с серией 40-минутных уроков по основным инструментам 2D- и 3D- моделирования в nanoCAD.

Лидерами просмотров на YouTube стали вебинары по nanoCAD Электро и nanoCAD ОПС. Это лекции руководителей проектов Дмитрия Щурова «nanoCAD Электро. Электротехнические расчеты. Разложим всё по полочкам» и Максима Бадаева «nanoCAD ОПС. Проектирование пожарной сигнализации». Кстати, недавно авторитетный портал проектировщиков RUBEZH провел интересный опрос «А в чем проектируешь ты?». Согласно рейтингу портала, третье место среди самых популярных программ занимает специализированное решение для проектирования слаботочных систем nanoCAD ОПС.

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

Инженерная школа обросла личными историями. Пользователи делились впечатлениями и оставляли отзывы в соцсетях.

Инженерная online-школа «Нанософт» в цифрах


  • 2,5 месяца непрерывной работы
  • 118 online-уроков по ведущим САПР-системам
  • 29 профессиональных спикеров
  • 26 программных продуктов
  • Более 12 000 слушателей

Изучайте сегодня самостоятельно


Сегодня все видеоуроки с курсами компании «Нанософт» находятся в открытом доступе на нашем YouTube-канале. Это лекции для специалистов разного уровня подготовки и разных направлений проектирования. Выбирайте курс по душе и прикладной специальности и обучайтесь самостоятельно.

Гражданское строительство

  • nanoCAD Plus. Урок №1 – Всё про печать в nanoCAD Смотреть>>
  • nanoCAD Plus. Урок №2 – Работа с полями в nanoCAD Смотреть>>
  • nanoCAD Plus. Урок №3 — Учимся работать с растрами Смотреть>>
  • nanoCAD Plus для новичков. Урок №1 – Чертим простую сетку осей Смотреть>>
  • nanoCAD Plus для новичков. Урок №2 – Чертим простую деталь со штриховкой Смотреть>>
  • ARCHICAD. Урок №1 – Основные принципы работы в BIM-системе. Панель Навигатора Смотреть>>
  • ARCHICAD. Урок №2 – Работа с обновленными инструментами «Балка», «Колонна» и новым инструментом «Отверстие» Смотреть>>
  • ARCHICAD. Урок №3 – Организация коллективной работы над одним проектом с помощью BIMcloud Basic Смотреть>>
  • ARCHICAD. Урок №4 – Иммерсивная визуализация в Twinmotion Смотреть>>
  • OPEN BIM. Открытое взаимодействие между архитектором и конструктором на примере ARCHICAD и nanoCAD Конструкторский BIM Смотреть>>
  • nanoCAD Конструкторский BIM. Урок №1 – Создание пользовательского параметрического объекта Смотреть>>
  • nanoCAD Конструкторский BIM. Урок №2 – Создание пользовательских таблиц спецификаций Смотреть>>
  • nanoCAD Конструкторский BIM. Урок №3 – Создание генерируемой 2D-документации из информационной модели Смотреть>>
  • Работа над информационными моделями в команде по схеме «конструктор – конструктор» и «взаимодействие со смежными отделами» с помощью решений nanoCAD Конструкторский BIM, nanoCAD Инженерный BIM и комплекса CADLib Смотреть>>
  • Проектирование стального каркаса в nanoCAD Конструкторский BIM Смотреть>>
  • nanoCAD СПДС. Урок №1 – Оформление чертежей Смотреть>>
  • nanoCAD СПДС. Урок №2 – Работа с архитектурой Смотреть>>
  • nanoCAD СПДС. Урок №3 – Создание собственных объектов. Часть 1 Смотреть>>
  • nanoCAD СПДС. Урок №4 – Создание собственных объектов. Часть 2 Смотреть>>
  • nanoCAD СПДС Металлоконструкции. Урок №1 – Армирование фундамента Смотреть>>
  • nanoCAD СПДС Металлоконструкции. Урок №2 – Создание металлической опоры под трубопроводы Смотреть>>
  • nanoCAD СПДС Стройплощадка. Урок №1 – Менеджер проекта Смотреть>>
  • nanoCAD СПДС Стройплощадка. Урок №2 – Стройгенплан Смотреть>>
  • nanoCAD СПДС Стройплощадка. Урок №3 – Построение дорог Смотреть>>
  • nanoCAD СПДС Стройплощадка. Урок №4 – Подбор техники Смотреть>>
  • nanoCAD Конструкции – КЖ. Урок №1 – Армирование инструментами схематичного армирования. Арматурные стержни Смотреть>>
  • nanoCAD Конструкции – КЖ. Урок №2 – Армирование инструментами схематичного армирования. Арматурные сетки и каркасы Смотреть>>
  • nanoCAD Конструкции – КЖ. Урок №3 – Формирование монолитных и сборных строительных конструкций Смотреть>>
  • nanoCAD Конструкции – Фундаменты. Урок №1 – Расчет и проектирование столбчатого фундамента. Получение рабочей документации Смотреть>>
  • nanoCAD Конструкции – Фундаменты. Урок №2 – Расчет и проектирование сборного ленточного фундамента. Получение рабочей документации Смотреть>>
  • nanoCAD Конструкции – Фундаменты. Урок №3 – Расчет и проектирование монолитного ленточного фундамента. Получение рабочей документации Смотреть>>
  • nanoCAD Конструкции – Модуль «Оформление» Смотреть>>
  • nanoCAD Конструкции – Фундаменты + КЖ. Взаимодействие инструментов модулей КЖ и Фундаменты Смотреть>>
  • nanoCAD ОПС. Урок №1 – Проектирование пожарной сигнализации Смотреть>>
  • nanoCAD ОПС. Урок №2 – Проектирование оповещения и видеонаблюдения Смотреть>>
  • nanoCAD Электро. Урок №1 – Электротехнические расчеты. Разложим всё по полочкам Смотреть>>
  • nanoCAD Электро. Урок №2 – Создание задания на отверстия Смотреть>>
  • nanoCAD Электро. Урок №3 – Настройка выносок Смотреть>>
  • nanoCAD Электро. Урок №4 – Расчет освещенности. От создания элемента «Светильник» до изолиний на плане Смотреть>>
  • nanoCAD СКС. Урок №1 – Проектирование структурированных кабельных систем Смотреть>>
  • nanoCAD СКС. Урок №2 – Проектирование кабеленесущих систем Смотреть>>
  • nanoCAD ВК. Создание спецоборудования Смотреть>>
  • nanoCAD Отопление. Наполнение и обвязка радиатора отопления Смотреть>>
  • Spotlight. Урок №1 – Повышение качества сканированного чертежа Смотреть>>
  • Spotlight. Урок №2 – Векторизация сканированного чертежа Смотреть>>
  • PlanTracer Pro. Урок №1 – Знакомство с интерфейсом. Библиотека шаблонов. Создание поэтажного плана Смотреть>>
  • PlanTracer Pro. Урок №2 – Создание технического плана помещения Смотреть>>
  • PlanTracer Pro 7.0. Урок №3 – Создание технического плана здания Смотреть>>
  • PlanTracer Pro 7.0. Урок №4 – Создание технического плана многоквартирного дома (МКД) Смотреть>>
  • PlanTracer Pro 7.0. Урок №5 – Создание технического плана многоконтурного сооружения Смотреть>>

Машиностроение
  • nanoCAD Механика. Урок №1 – Работа с модулем «Валы» Смотреть>>
  • nanoCAD Механика. Урок №2 – Формирование спецификации Смотреть>>
  • nanoCAD Механика. Урок №3 – Оформление чертежей, часть 1 Смотреть>>
  • nanoCAD Механика. Урок №4 – Оформление чертежей, часть 2 Смотреть>>
  • nanoCAD Механика. Урок №5 – Нанесение размеров и предельных отклонений. Часть 1 Смотреть>>
  • nanoCAD Механика. Урок №5 – Нанесение размеров и предельных отклонений. Часть 2 Смотреть>>
  • nanoCAD Механика. Урок №6 – Установка крепежа Смотреть>>
  • nanoCAD Механика. Урок №7 – Трубопроводная арматура Смотреть>>
  • nanoCAD Механика. Урок №8 – Оформление технических требований и технических характеристик чертежей Смотреть>>
  • nanoCAD 3D-модуль. Урок №1 – Основы моделирования Смотреть>>
  • nanoCAD 3D-модуль. Урок №2 – Параметрическое моделирование Смотреть>>
  • nanoCAD 3D. Урок №3 – Базовые команды 3D-моделирования в nanoCAD Смотреть>>
  • Новые возможности в среде «Листовая деталь» Solid Edge 2020 Смотреть>>
  • Проектирование трубопроводов в Solid Edge Modular Plant Design Смотреть>>
  • Solid Edge 2020 Wiring & Harness Design. Синхронизация данных электропроводки и жгута Смотреть>>
  • Симуляция движения в Solid Edge Смотреть>>
  • Solid Edge 2020 Wiring & Harness Design. Работа в связанном режиме Смотреть>>
  • Организация распределенной работы в Teamcenter и Solid Edge Смотреть>>
  • Технические публикации в Solid Edge Смотреть>>

Проектирование электроники
  • FPGA I/O Optimizer – ПЛИС на борту Смотреть >>
  • Новые возможности в релизе Xpedition VX.2.7 Смотреть>>
  • Преимущества решений Xpedition и PADS Professional по сравнению с оркад и аллегро Смотреть>>
  • Основы работы в Xpedition Designer Смотреть>>
  • Менеджмент полигонов в PADS Professional Смотреть>>
  • Основы работы в Xpedition Layout Смотреть>>
  • Советы и хитрости при настройке системы ввода ограничений Constraint Manager Смотреть>>

BIM-моделирование промышленных объектов
  • Model Studio CS. Проектирование систем отопления и вентиляции Смотреть>>
  • Model Studio CS. Проектирование строительных конструкций Смотреть>>
  • Model Studio CS. Проектирование кабельных систем Смотреть>>
  • Model Studio CS Трубопроводы. Моделирование систем вентиляции Смотреть>>
  • Model Studio CS. Проектирование технологических трубопроводов Смотреть>>
  • Model Studio CS ОРУ. Урок №1 – Создание BIM-модели ОРУ. Компоновка оборудования на площадке ОРУ Смотреть>>
  • Model Studio CS ОРУ. Урок №2 – Создание BIM-модели ОРУ. Работа с ошиновкой ОРУ Смотреть>>
  • Model Studio CS ОРУ. Урок №3 – Получение выходной табличной и графической документации Смотреть>>
  • Model Studio CS ОРУ. Урок №4 – Создание 3D- и 2D-модели высоковольтного оборудования Смотреть>>
  • Model Studio CS ОРУ. Урок №5 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
  • Model Studio CS Электротехнические схемы. Урок №1 – Проектирование схем КИПиА и АСУ ТП Смотреть>>
  • Model Studio CS Электротехнические схемы. Урок №2 – Проектирование схем электроснабжения до 1 кВ Смотреть>>
  • Model Studio CS Электротехнические схемы. Урок №3 – Проектирование схем электроснабжения выше 1 кВ Смотреть>>
  • Проектирование в Model Studio CS Электротехнические схемы Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №1 – Создание BIM-модели кабельного хозяйства. Проектирование кабельных конструкций Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №2 – Создание BIM-модели кабельного хозяйства. Проектирование кабельных трасс Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №3 – Создание BIM-модели кабельного хозяйства. Обнаружение и устранение коллизий кабельной раскладки Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №4 – Получение планов, видов, разрезов из BIM-модели кабельной раскладки Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №5 – Получение табличной документации из BIM-модели кабельной раскладки Смотреть>>
  • Model Studio CS Кабельное хозяйство. Урок №6 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
  • Model Studio CS ЛЭП. Урок №1 – Проектирование воздушных линий электропередачи 35-750 кВ Смотреть>>
  • Model Studio CS ЛЭП. Урок №2 – Проектирование воздушных линий электропередачи 0,4-35 кВ Смотреть>>
  • Model Studio CS ЛЭП. Урок №3 – Проектирование ВОЛС на ВЛ Смотреть>>
  • Model Studio CS Молниезащита. Урок №1 – Создание BIM-модели молниезащиты Смотреть>>
  • Model Studio CS Молниезащита. Урок №2 – Получение табличной и графической документации Смотреть>>
  • Model Studio CS Молниезащита. Урок №3 – Взаимодействие со смежными отделами на базе BIM-модели по технологии CADLib Проект Смотреть>>
  • CADLib Модель и Архив. Урок №1 – Получение комплексной модели из различных приложений Смотреть>>
  • CADLib Модель и Архив. Урок №2 – Проверка и анализ комплексной модели Смотреть>>
  • CADLib Модель и Архив. Урок №3 – Работа с чертежами, документами и отчетами в базе данных проекта Смотреть>>

Землеустройство
  • nanoCAD Геоника. Урок №1 – Возможности использования функционала модуля «Топоплан»: от подготовки исходных данных до получения выходной документации Смотреть>>
  • nanoCAD Геоника. Урок №2 – Возможности использования функционала модуля «Генплан»: от подготовки исходных данных до получения выходной документации Смотреть>>

А если вам нужно прокачать навыки с опытным инструктором, то обращайтесь в наши учебные центры nanoCAD.

Выводы и предложения


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

А вы проходили обучение в Инженерной online-школе? Нам очень интересна обратная связь. Пишите свои комментарии, рассказывайте понравилось ли, каких тем не хватило, что еще хотели бы изучить?

Проектирование ПО для начинающих методом снежинки / Хабр

Публикация может быть полезной скорее начинающим программистам, чем тем, кто знаком с разработкой и проектированием ПО (не нужно знать каких либо продуктов для проектирования ПО).

Я думаю, знающие согласятся, что их первый опыт программирования реального приложения (не Hello World) свелся с простому вопросу: с чего, собственно, начать? Как начать проектирование программы? Что писать-то?!

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

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

И вот, однажды утром, мне пришла в голову простая мысль: а что, если программу проектировать по методу снежинки?

Что я сделал:

1. Нарисовал на листке бумаги, как выглядит программа (для консолей особой разницы нет, поймете по ходу повествования). Для примера, возьмем калькулятор.

2. Условно разделил лист бумаги на две части, в одной я начну описывать интерфейс, в другой — что собственно программа умеет делать, ее модель (бизнес-логика). Уже на этом этапе видно, что мы разделили программу на 2 части: представление и логику. При этом, если программа консольная, в представление у нас попадут команды, на которые реагирует программа и вывод, который она возвращает.
Контроллер же — это связь между частью интерфейса и моделью программы.

3. Для описания интерфейса первым делом перечисляются все однотипные элементы (например, кнопки, лейблы и прочее). Получается, уже на этом этапе мы описываем классы-родители. Например, калькулятор:

Красным я обвел одинаковые элементы, это меню, лейбл, текстовое поле, кнопки и радио.

Дальше я смотрю, можно ли разбить эти элементы на более конкретные? (Что, естественно, можно, так как у нас не одна кнопка). Соответственно, от кнопки я стараюсь образовать как можно меньше общих групп или, чтобы было понятнее, классов: это число-буквенные (не вычисляют, только вводят данные) и оперативные (нажатие на них может привести к вычислениям или иным операциям). Чем меньше мы образуем одновременных классов, тем больше уровень абстракции получаем, что весьма полезно может быть в будущем, я думаю все согласны с этим (удобнее будет дополнять функционал, всегда есть от чего наследовать).

Продолжая дальше разбивать на группы, мы придем к определению каждого окончательного класса, когда разбиение уже невозможно. А цепочка от него до нашей начальной программы будет цепочкой наследования. Если нас что то не устраивает, например, куда деть кнопку стирания последнего символа — мы всегда можем пройтись по дереву наследования и изменить ветвление или деление на классы. Описав интерфейс — мы получим шпаргалку для дальнейшего проектирования(мы же, в конце концов, не будем лепить пустые элементы на форму).

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

Получится что-то вроде этого:

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

Если программа очень большая, сложная — всегда можно взять отдельный элемент и описать по вышеуказанному методу. Например, для многооконного приложения можно нарисовать снежинку для каждого окна. Для сложной логики — выделить глобальные операции, и поступить аналогично. К тому же, подобный метод работает не только от общего к частному, но и наоборот. Сперва мы набираем всё, что нам придет в голову, в виде кирпичиков или небольших деревьев. Если можем объединить во что то общее — мы получаем родительский класс. Если можем разбить на категории, мы получаем подклассы. И так, пока не останется кирпичиков без связей, не будет возможности разбить на подклассы и не получится снежинка.

Когда все будет сделано — можно начинать писать код. Но как его писать, это уже другая история… Впрочем, еще на этапе проектирования уже можно давать имена классам и кратко описывать их функционал.

P.S.

Из плюсов — ничего не надо знать, нужны только лист бумаги, ручка (или векторный редактор) и базовые знания языка, на котором будет писаться программа (я опирался на Java). Получается очень наглядно и довольно легко, особенно для начинающих.

Из минусов — упрощенность, возможно некоторые особенности проектирования теряются, но это уже вопрос к тем, кто этим занимается давно и может что-либо подсказать или дополнить.

Советы начинающим проектировщикам | Проектирование электроснабжения

Мне порой пишут начинающие проектировщики с различными вопросами и советами, на которые хочу ответить в этой теме. Если вы решили заняться проектированием, то наверняка возникнут вопросы: как научиться проектировать, куда пойти работать, где брать заказы?

В проектирование я попал случайно. У меня уже около 10 лет стажа проектировщика-электрика, поэтому я понимаю и знаю, с какими трудностями сталкиваются начинающие проектировщики.

Основная проблема начинающих проектировщиков – отсутствие знаний и опыта работы. Должен сказать, что проектировщиком может стать практически каждый, даже если у вас не совсем профильное образование.

Главная задача любого проектировщика – научиться учиться. Этому нас учат в любом университете. Выйдя из университета вы, возможно, ничего не соображаете в проектировании, но вы должны уже понимать, как найти ответ или решение на поставленную задачу.

Как проектировать?

Где взять знания и  опыт?

Знания и опыт можно получить:

Бесплатно. Самый долгий путь. Для этого у вас должны быть базовые знания по проектированию и вы должны понимать, что вы ищите. Далее открываете интернет и читаете все, что относится к вашей теме, читаете нормативные документы и пытаетесь делать простейшие проекты, например, частные дома и квартиры. Более сложные объекты вам вряд ли дадут.

Условно-бесплатно. Самый оптимальный вариант. Такой путь прошел я. Мне повезло, что меня взяли в серьезный проектный институт моего города, где был огромный электротехнический отдел. Я всегда мог получить бесплатную консультацию у своих коллег, которые обладали огромным проектным опытом и знаниями. Сейчас многие из них ушли на повышение, кто-то ушел на пенсию, а кто-то еще работает. Как правило, в таких организациях не самые высокие зарплаты. Если бы я там зарабатывал больше, то, не исключено, я бы все еще работал бы в той организации. Когда у тебя нет ничего, ты вынужден искать работу с большей зарплатой, чтобы можно было накопить денег на квартиру. На самом деле, я работу не искал, меня сами нашли и предложили лучшие условия работы. Было очень тяжело переходить на новую работу, расставаться с коллективом, на тот момент я еще не был таким специалистом, как сейчас

Платно. Самый быстрый вариант получения знаний и опыта, но, требует финансового вложения. Я считаю 50-300$ потратить на обучение – не большие деньги, которые окупаются очень быстро.

Если вы решили стать проектировщиком-электриком, то советую вам начать с проектирования частных домов и квартир. Для этого вам подойдет мой курс по проектированию частного жилья.  Пройдя этот курс, вы с легкостью сделаете свой первый проект. Также советую, хорошо изучить программу AutoCAD.

Для проектирования наружных кабельных сетей и наружного освещения подойдет «Практический курс проектирования кабельных сетей 0,4/10кВ – All Inclusive».

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

Вы спросите, а какой опыт могут дать такие курсы? Мои курсы основаны на моем личном опыте проектирования и кроме теоретических знаний, я даю практику и делаю обзоры всех проектов, которые делал и делаю лично. В одно видео можно вложить опыт, который накапливался годами. За 20 мин вы получите то, к чему будете идти месяцами и годами.

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

Поиск работы

Как искать работу?

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

Пройдитесь по всем проектным организациям, возможно, повезет. Спросите у знакомых, вдруг помогут.

Также не стоит пренебрегать объявлениями в газетах и в интернете.

Можно попытаться найти работу удалено, но, будете осторожны.

Где брать заказы?

Если вы работаете в проектной организации, то работой вас обеспечит работодатель.

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

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

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

Делайте свою работу качественно и сарафанное радио само будет находить вам заказы и дополнительную работу.

7 раз подумай, прежде чем стать проектировщиком 

Вот так выглядит проектировщик

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

Советую почитать:

Вы можете пролистать до конца и оставить комментарий. Уведомления сейчас отключены.

С чего лучше начать проект или как сделать так, что бы не было потом мучительно больно

Доброго всем времени суток. Настала очередь поговорить о проектировании проектов. По собственному опыту знаю, что иногда сложнее создать проект с нуля, чем привести в порядок то, что уже есть. Во многом это связано с тем, какое наследие Вы или Вам, оставляют после себя. В этой статье постараюсь рассказать на что стоит обратить особое внимание и предложить краткий план следования.


Понимание проекта


Прежде чем что-то планировать, вам необходимо понять какой проект нужно реализовать. Для себя я выделил несколько категорий проектов, таких как:
  • Одноразовая поделка — это проект, нацеленный на создание какого-то графического концепта и его дальнейшей продажи инвесторам. Отличительными особенностями данного типа проектов являются:
    1. Невменяемая документация. Основная идея понятна, но в бизнес-кейсах творится полный хаос, а логических дыр не счесть.
    2. Сжатые сроки. До 3-х месяцев от написания документации до прототипа.
    3. Нет планов развития и не планируется дальнейшая поддержка.
    4. Маленькая команда. Обычно до 5 человек, включая дизайнеров.
    5. Отсутствие бизнес процессов. Всё взаимодействие сумбурное, основанное на межличностном общении, уточнении принципиальных моментов и/или придумывании на ходу.
    6. Роли размыты. Нет четкого разграничения полномочий и зон ответственности.
    7. Нет настоящих данных. Все данные сгенерированы для “красоты” и подогнаны для наилучшего отображения.
    8. Для ускорения разработки во всю используются внешние зависимости.

  • Стартап — это проект, который настроен на реализацию конкретной идеи, с последующим развитием. Обычно, данные проекты развиваются по спиралевидной модели и, по этой причине, имеют почти такие же отличительные особенности, что и первый тип (одноразовая поделка):
    1. Чёткое разбиение на этапы. Минимально: сроки и перечень функционала, который необходимо в заданный период времени реализовать.
    2. Относительно вменяемая документация. Проведена аналитика, выставлены ориентиры по этапам сдачи, уточнения зачастую приходят во время спринта. Чаще всего используют waterfall, несмотря на то, что заявлен Agile.
    3. Средние сроки сдачи основного функционала. В среднем от 6 до 12 месяцев.
    4. На начальных этапах используют внешние зависимости, которые со временем меняются на собственную реализацию.
    5. Маленькая команда. Обычно до 7-10 человек.
    6. Есть разграничение ролей, но ответственность размыта.
    7. Проект может мутировать. На одном из этапов, возможно, изменится концепция или подход к реализации. Обычно это связано с требованиями инвесторов, изначально провальной идеи или ошибках в архитектуре.
    8. Условно живые данные. Происходит обкатка на фокус-группах или парсинг живых данных со сторонних ресурсов. Правда так бывает не всегда…

  • Информационная система — это проект, реализующий идею с планами по интеграции в сторонние сервисы.
    1. Есть план развития.
    2. Четко написанная документация. Минимально: задокументировано описание API.
    3. Возможно, потребуется проводить интеграцию со сторонними сервисами, ставить “костыли” или перестраивать части системы.
    4. Есть промежуточные релизы, хот-фиксы.
    5. Команда средней величины. Обычно от 10 до 20-30 человек.
    6. Чёткое разделение зон ответственности.
    7. Требования безопасности: после проведения аналитики созданы кейсы, которые могут привести к краху системы.
    8. Уделяется время тестированию.
    9. Используется Agile.
    10. Почти всегда есть backlog.
    11. Используются только внешние зависимости, дорогие в реализации собственными силами. Практикуется наравне с проприетарными.

  • Замкнутая система — это объемный проект, предназначенный для обслуживания конкретных потребностей Заказчика, с дальнейшей доработкой.
    1. Конкретный заказчик.
    2. Есть план развития.
    3. Проектная документация по разработке. В помощь пользователям написана отдельная документация по требованию Заказчика.
    4. Разграничение прав пользователей.
    5. Почти всегда есть backlog.
    6. Размер команды обычно больше средней. Как правило от 10 человек и до потери пульса.
    7. Используется Agile. Периодически прилетают дополнительные задачи, которые необходимо реализовать во что бы то ни стало.
    8. Неожиданные показательные выступления. По требованию вышестоящего руководства происходят показы, поэтому работоспособный тестовый контур никогда не будет лишним.

  • Saas решение — это объемный проект с гибкой настройкой и дальнейшей кастомизацией под конкретного заказчика.
    1. Многомодульная система. Система разбита на несколько частей. Которые можно использования по отдельности, даже за рамками конкретного проекта.
    2. Чёткое планирование. Минимально: осуществляется оценка трудозатрат на реализацию фич. Закладывается время на модернизацию и рефакторинг.
    3. Объемная документация. Описано, как правило, почти всё, включая тест-кэйсы.
    4. Как правило, отсутствуют внешние зависимости и пишутся свои реализации частей системы. Даже если есть сторонние реализации.
    5. Несколько команд разработки. Каждый отвечает за свою часть разработки будь-то бэк или же фронт.
    6. Покрытие тестами всего и вся. Применяются авто-, юнит-, регресионое-, интеграционные тесты.

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

Для определения типа проекта, ниже я привел вопросы, получив ответ на которые вам станет понятно, чего от Вас хотят:


  • Цель проекта?
  • Полный перечень того что надо реализовать?
  • Есть ли документация?
  • Какие сроки? Желательно точные даты.
  • Планируется внешнее взаимодействие со сторонними системами, или будет ли у проекта внешнее API
  • Есть ли наработки?
  • Размер команды?
  • Кто за что отвечает? Кто ставит задачи, кто принимает, кто имеет права вето.
  • Есть ли планы на развития и какие они?
  • Кто заказчик?
  • Есть ли бюджет на покупку готовых решений?
  • По какой методологии планируют работать
  • Есть ли аналоги?

Как вы видите, перечень не такой уж и большой. Правда, по какой-то неведомой причине, мало кто задаётся подобными вопросами до того, как начать что-либо делать. Вы спросите зачем мне понимать тип проекта?! Всегда надо делать так, чтобы проект жил вечность?! По большому счёту, вы правы, но есть нюансы, как в скабрезном анекдоте. Эти нюансы — ресурсы и сроки. Не стоит забывать, что мы трудимся на благо бизнеса и выполняем поставленные задачи. Когда вам известен тип проекта, вы можете без зазрения совести чем-то пожертвовать для достижения поставленных задач.


Выбор технологий

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


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

Данный перечень проблем актуален не только относительно технологий, но и к сторонним зависимостям. Всё вышеперечисленное может похоронить проект на корню.

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

Данный пример составлен для вымышленного проекта:


Название  функционала проекта.

Коэффициент важности для проекта

Работа с формами

3

Роутинг


1

Простота написания анимации


0,3

Как видно из таблицы, важными критериями отбора являются “работа с формами” и “роутинг”. Простота создания анимации для данного проекта не существенна. Далее модернизируем таблицу путем добавления новых столбцов-технологий. В нашем случае их будет два.


Название  функционала проекта.

Коэффициент важности для проекта

Технология 1


Технология 2


Работа с формами

3

+

±

Роутинг


1

+

±

Простота написания анимации


0,3

+

—

Исходя из данных таблицы, мы понимаем, что у “Технология 2” работа с формами и роутинг хромают, а создание анимации подобно вызову Сатаны. В итоге, удельный вес данной технологии составляет 2. Вы спросите почему 2? Всё просто! Если вы ставите ±, то в данной технологии конкретный функционал реализуем, но с какими-то “костылями”, либо же более трудозатратный. В нашем сравнении выгоднее будет “Технология 1 “, с итогом 4,3. Думаю пояснения по образованию сумм излишни. Данная таблица работает не только с технологиями, но и со всем, что требует сравнения и выбора из списка. Главное — не забывать, что чем больше критериев напишите, тем проще вам будет сделать выбор.


Архитектура

В настоящее время есть возможность выбрать из многообразия различных сервисов, предоставляющих инструменты для проектирования архитектуры. Правда у любого из них есть недостатки, для кого-то критичные, а для кого-то нет. Так как я “oldfag”, то предпочитаю листочек и ручку или доску и маркер.

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

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

Восходящий — разработчики отталкиваются от мелких частей и идут к более крупным. Смысл архитектуры в том, что сначала создается много мелких компонентов, а уже из них собираются более крупные.

Монолит — архитектура неделимая на части, зачастую именуемая “legacy”. По факту это жесткая структура, изменение которой, требует решений без “костылей”. Это самый плохой вариант, но, как и всё в нашем мире, имеющий право на существование. Монолит применяют для реализации конкретного функционала и не планируют в дальнейшем его поддерживать. По сравнению с остальными, скорость такого подхода в разы быстрее. Ну просто потому, что можно на многое закрыть глаза.

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

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

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


Планирование

Так называемая “Дорожная карта” поможет вам выполнить работу эффективнее. По сути это график, с условными сроками сдачи того или иного функционала. Даты могут переноситься, но, как показывает практика, при грамотном выполнении вышеизложенных пунктов, поправка составит до 30%. На практике это обычно 10-15%. Планирование позволит вам отслеживать прогресс проекта, видеть провисания, вносить коррективы в виде ресурсов или сдвига сроков, и т.д.


За что Вам потом скажут спасибо

Любой проект начинается с документации, и чем её больше, тем лучше! Так что не надо лениться — документируем ВСЁ. Да, это займет время, но впоследствии может спасти Вас от гнева руководства, если что-то пойдет не так, не по Вашей вине. Также не стоит забывать, что после Вас на проекте появятся люди, которым придётся разбираться в том, что вы создали. А без документов сделать это будет не просто.


Выводы

В данной статье описано, как следует действовать и на что обратить внимание при старте проекта. Данные этапы универсальны для фронта, бэка, тестирования или всего вместе. Я нарочно избегал конкретики по технологиям, для того чтобы не вводить в заблуждение.

Когда перед вами встаёт выбор какой использовать стек технологий, архитектуру и необходимо определить временные рамки для реализации проекта, вам может помочь таблица, приведённая ниже:


Типа проекта / признаки

Одноразовая поделка

Стартап

Информационные системы


Замкнутые системы

Saas решения

Какие-то другие проекты

Кол-во людей до 5


 X
 X
 X
 X

Кол-во людей  от 7 до 10

Кол-во людей от 10 до 30


 X

Кол-во больше 30


 X
 X

Срок сдачи  до 3х месяцев


X
 X
 X
 X

Срок сдачи  от 6 до 12 месяцев


Срок больше 12 месяцев


 X

Документация

Требования интегрирования с  другими системами

Конкретный заказчик известен

Планируется дальнейшая поддержка

Планирование

Роли четко разграничены

Разрешено использовать внешние зависимости

Есть живые данные для тестирования и анализа


Требования  по безопасности

Требуется тестирование

Требуется написание  документации по продукту или инструкция

Требуются модульная реализация

Несколько команд разработки

Всего

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

практическое руководство. Часть 1 / Блог компании Pechkin.com / Хабр

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

Введение в проектирование UX

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

Юзабилити – это область, которая считается чрезвычайно важной при разработке цифрового продукта, но при этом для многих она остается таинственной в силу своей относительной новизны и постоянного развития. Для новичка даже получение навыков для успешного проектирования интерфейсов может показаться непосильной задачей.

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

Проектирование UX – это не только увлекательное, но и просто хорошее дело.  

Раскрываем тайны проектирования UX

В этом материале есть не только теоретические положения, но и практические советы, которые помогут вам стать юзабилистом. Мы начнем с азов и, прежде всего, ответим на базовые вопросы, например «Что такое проектирование UX?». Позже мы углубимся в процесс профессионального проектирования интерфейсов и коснемся таких тем, как Исследование пользовательской аудитории, Дизайн и Тестирование. Чтобы дать более четкое представление о том, как стать юзабилистом, мы подготовили для вас несколько практических заданий, которые вы сможете выполнить самостоятельно.
Что такое проектирование юзабилити?

Официальное определение пользовательского опыта это:

«Восприятие, возникающие у человека при использовании и/или предполагаемом использовании продукта, системы или при получении услуги» (ISO 9241-210:2010, подраздел 2.15).

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

Визуальный дизайн – это то, как продукт выглядит, а юзабилити – то, как он воспринимается. Но это еще не всё. Юзабилити включает в себя все аспекты взаимодействия пользователя с компанией – от обслуживания клиентов до качества продукции. Имейте в виду, что многие UX-дизайнеры используют термины «продукт» и «услуга», как взаимозаменяемые.

Википедия определяет проектирование UX как:

«Процесс повышения уровня удовлетворенности пользователя от взаимодействия с продуктом за счет повышения его удобства, простоты использования и доступности».

Каждый раз, когда вы взаимодействуете с продуктом, программным обеспечением или каким-либо объектом, вы воспринимаете его как пользователь. А значит, ключевая задача проектирования UX заключается в том, чтобы сделать этот опыт настолько успешным, насколько это возможно. Юзабилист должен, помимо прочего, быть тем «клеем», на котором держится вся команда, передавая проекты разработчикам, которые затем претворят их в жизнь.

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

Для чего мы занимаемся проектированием интерфейсов?

Проектирование интерфейсов дает компании два главных преимущества:
  1. Оно положительно влияет на восприятие продукта пользователем.
  2. Успешный пользовательский опыт повышает уровень принятия продукта.

Таковы основные цели проектирования интерфейсов:
  1. Понять цели потенциальных клиентов и контекст использования продукта.
  2. Исходя из целей клиентов и контекста использования, разработать продукт, услугу или приложение в рамках ограничений бизнеса и технологий.

Таким образом, мы занимаемся проектированием интерфейсов, чтобы добиться обозначенных целей – довольные клиенты и высокие продажи.

Первое, о чём думает юзабилист – это то, как объединить цели пользователя с целями бизнеса. Например, если целью пользователя является покупка продукта, то компания должна сделать эту покупку полезной, удобной и приятной.

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

Если целью пользователя является получение информации, то компания должна предоставить достоверные данные, внушая тем самым доверие покупателю, а персонал должен вежливо отвечать на задаваемые по телефону вопросы. Довольный клиент, получивший всю интересующую его информацию, вернется, а разочарованный – нет.
  1. Если цель клиента достигнута (т.е он легко и быстро нашел то, что искал), то у него остается приятное впечатление от вашего продукта.
  2. Если у клиента осталось хорошее впечатление, то он с большей вероятностью совершит покупку или порекомендует продукт своим друзьям.
  3. Когда клиент возвращается на сайт, покупает ваш продукт или рассказывает о нем друзьям, объем продаж и уровень конверсии растут.

Краткая история UX

За последние годы термин «Проектирование UX» стал близок по значению к технологиям и программному обеспечению, но так было не всегда. Изначально под «пользовательским опытом» понималось просто переживание, возникающие у человека при использовании системы.

Термин «Проектирование UX» был введен в употребление в 1995 году Дональдом Норманом (Don Norman), который в то время занимал пост вице-президента группы разработки продвинутых технологий в Apple. Он сказал:

«Я изобрел этот термин поскольку считал, что «интерфейс для человека» (human Interface) и «юзабилити» были слишком узкими терминами. Я хотел задействовать все аспекты пользовательского опыта взаимодействия с системой, в частности с промышленный дизайн продукта, его графику, интерфейс и физический контакт».

Кроме того, Норман написал книгу «Дизайн привычных вещей», в которой впервые удобство и функциональность были поставлены выше эстетики. Его работа до сих пор весьма популярна в дизайнерских кругах. Интерес к проектированию UX вырос, а сам термин стал обобщающим для ряда разных областей, таких, как Исследование пользовательской аудитории, Информационная архитектура, Разработка юзабилити, Дизайн сервиса и т.д.
Что такое юзабилити?

Юзабилити – это простота использования и освоения объекта, созданного человеком.
Это понятие напрямую связано с причинами, по которым мы занимаемся проектированием интерфейсов – поскольку юзабилити положительно влияет на пользовательский опыт. Чем проще освоить и использовать продукт, тем лучший опыт получает пользователь. Но продукт должен быть не только удобным в использовании – он должен решать проблему клиента. И в большинстве случаев работа юзабилиста состоит в том, чтобы выяснить, что нужно пользователям.
Как проектировщик интерфейсов видит мир

Изучая основные принципы проектирования UX, вы можете «залезть в голову проектировщика интерфейсов» и увидеть мир его глазами.

Художник и юзабилист Эллисон Хаус (Allison House) так рассказывает о своем подходе к работе:

«Когда я занимаюсь проектированием UX, я повторяю мантру: «Мысли шире, расставляй приоритеты, смотри глубже. Изучи обстановку, определи, что важно, и начинай решать задачи в порядке очередности».

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

Эмпатия – способность понимать, почему люди поступают тем или иным образом. Для того, чтобы заниматься проектированием юзабилити, нужно уметь ставить себя на место других людей. Вероятно, это наиболее важное качество для работы в этой области, и вам необходимо научиться понимать поступки других людей. Вопреки расхожему мнению, этой способностью не каждый обладает от природы.

Любознательность – желание узнать, почему люди поступают тем или иным образом.

Ясность выражения – способность объяснить сложные понятия в доступной форме для тех, кто не знаком или мало знаком с данной областью.
Проектировщик прототипов в лаборатории RED компании Manulife Аль Рушдан Тарик (Ali Rushdan Tariq) объясняет так:

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

Процесс проектирования UX

Исследование пользовательской аудитории

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

Исследование пользовательской аудитории – это основополагающий элемент проектирования UX. Независимо от того, работаете ли вы в крупной корпорации, где специальная команда проводит это исследование для вас, или являетесь единственным юзабилистом в стартапе, пропустить эту часть процесса проектирования никак нельзя. Будучи UX-дизайнером, вы по определению должны знать всё о своем продукте. Однако ваша интуиция не всегда может безошибочно определить, что понравится пользователям, поэтому проведение исследования с реальными пользователями так важно для успешного дизайна.

Нейт Болт (Nate Bolt), основатель лаборатории по исследованию пользовательского опыта Ethnio, делится советом:

«Не бойтесь применять творческий подход не только к самому процессу проектирования, но и к исследованию пользовательской аудитории. То, как вы проводите интервью, работаете с командой и представляете полученные результаты – всё это возможности мыслить творчески. Мы привыкли считать проектирование частью творческого процесса, но и исследование должно быть не менее творческим».

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

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

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

Питер Мерхольц (Peter Merholz), юзабилист и менеджер по продукту компании PeterMe.com, дал такой совет, чтобы лучше понимать пользователей:

«Не путайте сам процесс с результатом – знать такие элементы проектирования UX, как персоны (персонажи), «потоки» (flows) и макеты UI важно, но этого не достаточно для формирования успешного пользовательского опыта. Более важен образ мышления – вы должны смотреть на мир глазами пользователей и делать всё возможное, чтобы ваша работа имела для них смысл».

Почему исследование пользовательской аудитории так важно

«Исследование не имеет смысла, если оно не проводится должным образом. Переход от изучения результатов исследования к проектированию – это наиболее важная часть работы юзабилиста», – Гарри Бригналл (Harry Brignull), специалист по проектированию UX в 90percentofeverything.com.

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

Чтобы стать юзабилистом, вы должны всегда смотреть на продукт с позиции пользователя; и научиться этому можно только при работе с реальными пользователями во время глубинного изучения аудитории.

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

В ходе исследования проектировщик интерфейсов будет собирать информацию, используя различные источники и средства, для создания положительного пользовательского опыта. Мы рассмотрим некоторые из этих методов далее.
Вот, что сказал автор методологии Lean UX Джефф Готелф (Jeff Gothelf) об исследовании пользовательской аудитории:

«За последние пять лет природа программного обеспечения перешла в состояние постоянного и последовательного улучшения. Благодаря этому у дизайнеров появилась замечательная возможность постоянно поддерживать связь с аудиторией. Непрерывное общение – небольшие исследования, проводимые часто и регулярно – помогает слышать голос клиента в процессе принятия решений. По сути, оно гарантирует, что это исследование, равно как и разработка, проектирование или сбор требований, займет свое место в процессе итеративного формирования дизайна и развития продукта».

Почему мы начинаем с исследования пользовательской аудитории

Мы начинаем процесс проектирования UX с исследования пользовательской аудитории, поскольку в противном случае наша работа будет основываться лишь на собственном опыте и предположениях. А это помешает добиться объективности, ведь наше мнение может отличаться от мнения клиентов. Исследование пользовательской аудитории предоставляет нам данные, необходимые для создания продукта. Без этих данных мы не можем приступить к работе.

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

По мнению Нила Тернера (Neil Turner), автора блога UxfortheMasses, хорошая основа – ключ к успешному проектированию:

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

Что включает в себя исследование пользовательской аудитории

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

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

Онлайн-опросы

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

Создание персон

Персоны – это не ваши желаемые клиенты. Это те клиенты, которые у вас есть или могут быть. В рамках веб-дизайна персона определяется как описание вымышленного человека в рамках определенной пользовательской аудитории. Мы разрабатываем персоны пользователей на основе качественных и количественных данных исследования пользовательской аудитории, а также на основе полученной веб-аналитики.

Использование персон эффективно, если они:

  • По-настоящему отражают мотивы, цели и потребности реальных людей
  • Дают ясную картину об ожиданиях пользователей
  • Показывают, как пользователи взаимодействуют с сайтом
  • Представляют подавляющее большинство пользователей сайта

Питер Морвилль (Peter Morville), известный как основоположник Информационной Архитектуры, дал совет касательно создания персон:
«Портреты и профили типов пользователей (а также их цели и стереотипы поведения) напоминают всем нам о том, что мы не являемся пользователями, и служат компасом при осуществлении проектирования и разработки».

Тестирование пользователей

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

В своем высказывании юзабилист и специалист по вопросам стратегии из Берлина Хани Рицк (HanyRizk) подчёркивает важность исследования пользовательской аудитории в процессе проектирования UX:

«Проектирование без проведения исследования пользовательской аудитории полностью противоречит понятию проектирования UX. Данное исследование помогает UX-дизайнерам и другим заинтересованным лицам понять пользователей и их потребности, а также определить их требования к продукту. Проще говоря, оно заменяет предположения в процессе проектирования на конкретные данные».

Процессы в проектировании UX: Дизайн

Юзабилити в дизайне

Как однажды сказал Стив Джобс:
«Дизайн — это не то, как продукт выглядит и воспринимается. Дизайн — это то, как он работает».

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

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

Безусловно, эстетические свойства продукта усиливают его привлекательность. Однако, занимаясь проектированием UX, вы быстро придёте к выводу, что если продукт не работает должным образом, то его внешний вид мало волнует пользователя. При этом не стоит забывать, что конечный успех продукта зависит не только он вашего дизайна, но и от его воплощения разработчиками, а также от управления проектом. Это ещё один ключевой навык, необходимый для юзабилиста – умение работать в команде. Подробнее об этом мы поговорим в последнем разделе.

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

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

Не забывайте, что любое действие клиента должна быть полезным, удобным и приятным. Если вы не решаете проблему пользователя, он не посмотрит ни на цвета, ни на картинки.
Дэн Сэффер (Dan Saffer), специалист по дизайну взаимодействия и писатель, поделился другим советом. Он сказал:

«Никогда не забывайте почему: почему вы занимаетесь дизайном этого продукта, почему люди будут им пользоваться, почему вы приняли то или иное решение в процессе проектирования. Запишите эти причины на бумаге. Расскажите о них любому, кто будет слушать. Внесите их в свои макеты и презентации. Это «почему» должно задавать направление всему процессу, поскольку именно оно определяют значение, историю и тему (оформление) продукта».

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

Продолжение следует…

Проектирование Домов и Коттеджей онлайн