Прототипирование *

Компания «Ретех» показала решения по керамической 3D-печати на выставке «Металлообработка-2026»

Компания Ретех под брендом "Прокерамика" выпускающее специализированные 3D-принтеры для печати керамическими пастами, демонстрирует оборудование и образцы, изготовленные на собственном 3D-принтере «Прокерамика-170»

Как мы ранее упоминали, наша компания разрабатывает лазерные стереолитографические (SLA) 3D-принтеры, заточенные под работу с высоковязкими керамическими пастами. На сегодняшний день это единственное отечественное решение в своем классе, способное закрыть нишу, образованную уходом с российского рынка европейских производителей 3DCeram и Lithoz и конкурировать с их китайскими копиями.

3D-принтер «Прокерамика 170» использует ультрафиолетовый лазер с длиной волны 355 нм, способен выращивать изделия длиной до 165 мм. Комплекс включает отечественный слайсер Triangulatica, внесенный в реестр российского программного обеспечения, а ключевые компоненты аппаратной составляющей производятся в Санкт-Петербурге. Оборудование рассчитано на применение в исследованиях и мелкосерийном производстве.

Лазерная стереолитография — что это такое.

Установки для печати керамикой на основе стереолитографической технологии состоят из:

- УФ-лазера со сканирующей системой;

- Платформы, на которой строится объект. Она может подниматься и опускаться;

- Системы подачи пасты;

- Ракеля для размазывания пасты по платформе;

- Платформы, на которой строится объект.

Для работы с такими 3D-принтерами необходима керамическая паста с оптимальными реологическими свойствами. Процесс печати производится слой за слоем. После завершения процесса печати объект подвергается процессу спекания (высокотемпературному обжигу). Это делает изделие прочным и устойчивым к окружающей среде эксплуатации.

Напечатать изделие - лишь часть процесса

Этапы постобработки:

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

Сушка: Напечатанная «сырая» деталь осторожно сушится для удаления влаги.

Отжиг в печи: Изделие помещается в специализированную печь для отжига, температуры достигают 1000-1100 С. На этом этапе удаляется органическое связующее (дебиндинг).

Спекание: На этом этапе происходит усадка (которая должна быть точно просчитана на этапе моделирования) и спекание частиц, что придает керамике ее прочность и другие физ-мех свойства. Температуры спекания достигают 1400-1800 С.

Именно из-за этих этапов термической пост-обработки общее время изготовления готовой керамической детали значительно превышает время печати пластиком и достигает 72-96 часов.

Сферы применения: от медицины до аэрокосмической отрасли

Выдающиеся свойства напечатанной керамики — термостойкость, химическая инертность, биосовместимость и диэлектрические характеристики — открывают двери для самых требовательных отраслей.

Медицина и стоматология: с помощью керамических 3D-принтеров изготавливают индивидуальные имплантаты, костные скаффолды (каркасы для восстановления тканей) и стоматологические протезы.

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

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

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

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

Ещё немного для ищущих ассиметричное превосходство.
Сколько стоит случайная идея vs годная реализуемая идея. Начнем с аксиомы: воображение бесконечно, это было доказано уже многими философами, и можно просто представить в теории любую математическую формулу в голове. То есть количество идей тоже бесконечно, можно выдумать что угодно, ценность каждой идеи в среднем стремится к нулю. Окей, вроде даже с корпоративными юристами согласились, Америку не открыли.

Однако, объективная реальность, в которой мы хотим применить те или иные идеи только одна. Неверных представлений об объективной реальности - бесконечное множество, так и неверных неприменимых идей.

Поиск же верных применимых идей, которые позволят той или иной системе работать эффективнее, а то и вовсе перевернут всё с ног на голову, даже полностью разрушат устаревшие системы - поиск таких идей может оказаться бесконечно труден в зависимости от того, насколько далеко мы уходим от объективной реальности R.
Насколько близко к R мы находимся влияет не только сам процесс мышления/склад ума, но также и входные данные о реальности, которыми мы располагаем, которые мы не игнорируем.
Существует если не бесконечное, то огромное множество данных о реальности, в том числе, неизмеряемых людьми на постоянной основе. Большую часть этих данных мы не охватываем сознательно за ненадобностью, да и невозможностью. Допустим два программиста мыслят очень схоже, почти одинаково, но смотрят в совершенно разные стороны, один до чего-то догадался, другой догадался до чего-то другого. Ввиду фундаментальной ограниченности внимания, в лучшем случае мы близки к сабсету R, некоторому маленькому кусочку r. Соответственно, поиск применимой годной идеи теперь дополнительно ограничен вектором и интенсивностью внимания. Явно сложнее, чем может показаться

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

Самым очевидным способом приблизиться к r - следовать консенсусу экспертов, однако понимая, что консенсус экспертов по своей природе ленив, постоянно атакуем новыми, не обязательно разумными идеями, и соответственно неизбежно утрачивает бдительность со временем. Это касаясь реального мира. А что же насчёт виртуальных строго конечных миров и строго конечных систем?

CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки

Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.

Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.

Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.

CASE: скелет

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

Vibe Coding: энергия

Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.

MSF: спираль

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

ИИ: мост

ИИ становится универсальным переводчиком. Он умеет:

• превращать вайб в CASE-модель;

• разворачивать CASE в рабочий код;

• делать обратный ход — извлекать архитектуру из существующего кода;

• проверять целостность пирамиды при каждом изменении.

Что это даёт

1. Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.

2. Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.

3. Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.

4. Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.

5. Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.

Эффект для индустрии

• Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.

• Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.

• Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.

Заключение

CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.

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

И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.

Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.

Челлендж для HR, тимлидов и скептиков!

Привет! Перед вами нечто среднее между стеком разработчика / резюме. Попробуйте оценить:

• Junior, Middle или Senior? (или вообще кто это?)

• Во сколько такие люди оцениваются нынче?

• Взяли бы в команду? Или сразу в бан?)

⚠️ Некоторые детали с подвохом.

💻 HARD SKILLS

Языки программирования
Python, JavaScript, Java, Kotlin, C++, C#, SQL, AutoIt, Assembly, Go

Технологии, форматы, API
HTML, CSS, JSON, GeoJSON, DOM, Canvas API, WebGL, REST API, WebSocket, Bash/PowerShell

Базы данных
MariaDB, SQLite, Redis, PostgreSQL, Oracle,, MS Access

Фреймворки и библиотеки
Web Backend: Django, Flask, FastAPI, Node.js, Celery
Desktop GUI: PyQt, Tkinter, Lazarus
Mobile: Android SDK, Gradle
Визуализация и 3D: Three.js, OpenCV
Data Science: NumPy, Pandas, Matplotlib
GIS: QGIS
Медиа: FFmpeg

Frontend / Web-разработка
React, адаптивная верстка, интерактивные карты, кастомные UI-компоненты, работа с большими изображениями, клиентская логика, мини-движки визуализации

Backend / Сервисы
REST API, парсинг веб-данных, обработка данных, файловые пайплайны, работа с БД, deployment на localhost

Desktop-разработка
Многооконные приложения, панельные интерфейсы, файловые менеджеры, рендереры, конвертеры, кастомные инструменты, собственный табличный редактор (CSV/JSON/Excel)

Mobile / Android
Нативные проекты на Kotlin/Java, работа с ресурсами, манифестами, базовые UI-компоненты

Data / Computer Vision / ML
Обработка изображений, сравнение фото, фильтры, контуры, цветовые анализаторы, DPI/масштабирование, нейросетевые модели, работа с датасетами

GIS / Картография
Разбиение карт на тайлы, кастомные HTML/JS-карты, координатные системы, управление слоями, визуализация геоданных, интерактивные схемы

3D / Графика
Визуализация объектов, базовый шейдинг, анимации, работа с 3D-сценами, астрономические симуляции

Audio / Video обработка
Конвертация, рендер, аудиоэффекты, VST, визуализация звука

Automation / Инструменты
200+ кастомных утилит: пайплайны, GUI-редакторы, конвертеры, парсеры, визуализаторы, сборщики, веб-автоматизация (Selenium, ChromeDriver)

Build / DevOps
Сборка проектов, Git (локальный контроль версий), Firefox/Chrome DevTools, отладка

🧠 SOFT SKILLS
Системное мышление, архитектурное проектирование, UX/UI дизайн, rapid prototyping, постановка задач, анализ требований, визуализация идей, техническое чутьё, структурирование проектов, документация, логическое мышление

ИНСТРУМЕНТЫ РАЗРАБОТКИ И ДИЗАЙНА
Notepad++ (+ собственный редактор (пока Python syntax)), VS Code, Sublime Text, Android Studio, QGIS, Blender, Unity, Figma, Photoshop, Illustrator, CorelDRAW, Audacity, FL Studio, Adobe Premiere Pro, After Effects, Magix, Postman, curl, Total Commander, VirtualBox

МЕТОДОЛОГИИ И ПОДХОДЫ К РАЗРАБОТКЕ
Итеративная разработка (Rapid Prototyping), контроль версий, архитектурные паттерны (MVC, MVVM), модульное проектирование, рефакторинг кода, оптимизация производительности, отладка (логирование, DevTools), структурирование проектов, документирование кода

Дополнительный вопрос:

За какое время можно пройти путь от «Чёрное окошко — это какая-то магия, F12 — это что-то страшное...» до реального применения всего перечисленного выше в прототипах и рабочих проектах? Минимум по одному разу.

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

Размышлял на тему стартапа в HRTech и вот к чему пришел:

Веб.сервисы, моб.приложения, чат‑боты — это по сути автоматизация процессов.

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

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

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

Продолжим:

В противоположность этому, есть смысл автоматизировать процесс что реально существует и стабильно дает хорошие результаты (читай как — процесс который реально решает задачу).

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

(Из ТРИЗ вроде: лучшая система та которой нет, а задача решается за счет того что уже и так есть (тогда работа проделывается без особых затрат на выстраивание системы, как говорится: и волки не ругаются и овцы улыбаются 😁).)

Ок, давайте посмотрим на то как происходит наем в других сферах?

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

2. Нанимая такси для себя я ориентируюсь на то надо мне куда-то ехать или нет, какие машины для меня доступны, как скоро может прибыть машина, могу я ждать дольше или тороплюсь, могу позволить себе ехать с комфортом или экономлю и т.д.

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

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

Список можно продолжить. И будет плюс-минус так же.

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

Зашел на хедхантер\хабркарьеру нашел тех кто матчится по стеку, запросил 10-30 портфолио, прозвонил рассказал про задачу, побеседовали пригласил на свидание.. Тьфу ты, на свидание говорю мальчишка, на работу конечно же.

И никакой стартап не нужен, все уже есть 😁

А если захочется сделать мега-супер-дупер-сервис то можно сделать сайт с витриной разработчиков, их стеком и портфолио, и статусом свободен-занят, готовность выйти на работу и цену поездки.. «машина приедет через 10-минут, поездка займет пол.часа», можно даже что‑то типа Uber замутить (или типа Tinder). А с другой стороны сервиса разработчикам будут прилетать заказы.

Если же компания захочет нанять себе «личного водителя», то можно пригласить «водителя» прямо во время поездки. Аналогия с сервисом знакомств еще интереснее 😁

Делюсь идеей — пользуйтесь, и обязательно пригласите меня на тест-драйв если сделаете, буду рад!

Можете считать что я ваш первый клиент, так что рынок есть :)

P.S. Я кстати говоря сейчас в ленивом поиске, открыт для предложений и новых возможностей, так что пишите в тг если что, обсудим сотрудничество: @alex_ku_san

P.P.S. Говорят что я изобрел Mercor. Из поиска: Стартап ИИ-рекрутинга Mercor привлек первые $100 млн и получил оценку в $2 млрд. Значит идея в целом интересная :)

На сайте Сколково вышла история о том, как мы перестраиваем культуру от проектной к продуктовой.
Главный инсайт — технологии сами по себе мало чего стоят. Важно проверять спрос, быстро тестировать идеи и выводить на рынок только то, что реально нужно клиентам.
В итоге мы выстроили систему R&D, научились работать с гипотезами и запустили собственные продукты. Это не только про рост бизнеса, но и про смену культуры внутри команды.

Каждая идея проходит определённые этапы: исследования, прототипирование, планирование продукта и реализация MVP. Идеи "отваливаются" на каждом этапе и это позволяет сделать процесс более дешевым и не "тащить" за собой идеи, которые в последствии не примет рынок.
Таким образом, повышается вероятность продукта на рынке.
На картинке ниже схематично представлена воронка идеи от этапа к этапу. Из 100 идей до вывода на рынок доходят примерно 7, это среднее значение по акселераторам крупных компаний.

Ссылка на публикацию: https://lnkd.in/ez3Qx26y

Развлекся и собрал калькулятор окупаемости автоматизации

Ты можешь указать как часто делаешь рутину, сколько на это уходит, а калькулятор расскажет выгодно ли автоматизировать или нет.

Было это так: покекал с залежавшегося выдержанного мема от xkcd про "сколько времени уходит на рутину за 5 лет" и задумался... Понял, что калькулятор окупаемости не помешает.

Ведь автоматизировать надо, когда:

1. Регулярно/часто выполняешь однотипную задачу
2. Каждый раз на эту задачу уходит время (даже если минута)
3. Понимаешь как можно автоматизировать хотя бы часть этой задачи
4. Зависимость от непостоянности человека может навредить
5. Есть готовность поддерживать свою автоматизацию, а не рутину :)

Потратил месяц на автоматизацию и ускорение деплоя в staging.
Теперь деплой занимает 30 секунд вместо 5 минут.
Окупится через... 2 года 😭
(с) DevOps в курилке

🛏 Робот Lume от SyncereAI — это будущее вашего дома!

📌 Стартап из Стэнфорда представил устройство, которое выглядит как настольная лампа, но умеет гораздо больше. Эта робо‑лампа способна самостоятельно складывать одежду и заправлять кровать — аккуратно, без складок и усилий с вашей стороны.

🤖 Что умеет лампа

🔹 Складывает любую одежду — футболки, рубашки, брюки
🔹 Разглаживает ткань в процессе — помогает избежать замятостей
🔹 Заправляет постель — равномерно натягивает простыню и покрывало
🔹 Работает как роботизированный ассистент: мягко, точно и бесшумно

💬 Управление — с телефона или голосом. Можно задать сценарий «утро»: кровать заправляется и одежда аккуратно складывается за пару минут, пока вы пьёте кофе.

💸 Сколько стоит и когда ждать

🔹 Сейчас открыт предзаказ по цене $49 (~4000 рублей)
🔹 Точная дата массовой поставки не объявлена, но интерес уже высокий — устройство активно обсуждают в соцсетях
🔹 В России пока не представлено официально, но, вероятно, аналогичные решения не заставят себя ждать

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

LLM в разработке: Практические вопросы к сообществу

Привет, Хабр!

LLM уже не просто стучатся — они локтями расталкивают наши привычные рабочие процессы. За последний год я много экспериментировал c LLM в разработке, пытаясь найти эффективный и осознанный способ применения, который я для себя назвал «выращиванием кода». Это подход, основанный на декомпозиции, качественном контексте и итеративной доработке, как антидот слепой генерации или «вайб‑кодингу».

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

1. Как вы используете LLM в своей работе? Только для автодополнения и поиска решений, или пробовали полноценно «выращивать» компоненты и модули? Какие модели дают лучший результат для вашего стека?

2. Насколько важен контекст при работе с LLM? Замечали ли вы разницу между запросами типа «напиши X» и «вот существующий код, создай Y, который интегрируется с ним»? Как вы подбираете релевантный контекст?

3. Трансформировалась ли ваша роль как разработчика? Заметили ли вы изменение в процессе работы — больше времени на архитектуру и меньше на написание кода? Или LLM пока остается вспомогательным инструментом?

4. Какие новые навыки потребовались? Как вы формулируете запросы? Разрабатывали ли особые техники промпт‑инжиниринга для программирования? Какие приемы повышают качество генерируемого кода?

5. В каких областях LLM справляется лучше всего, а где хуже? UI/UX, бизнес‑логика, алгоритмы, тесты? Есть ли паттерны или типы задач, где вы полностью полагаетесь на LLM, и где предпочитаете писать руками?

6. Как вы проверяете сгенерированный код? Какие методы и практики помогают выявлять потенциальные проблемы? Меняется ли подход к ревью LLM‑кода по сравнению с человеческим? Приходилось ли сталкиваться со специфическим «LLM‑долгом»?

7. Как LLM влияет на вашу продуктивность? Замечаете ли реальное ускорение разработки? В каких типах задач выигрыш наиболее заметен? Изменилось ли качество конечного продукта?

8. Как вы решаете проблему «разрыва интерпретаций» между нечеткими человеческими намерениями и точными машинными инструкциями при работе с LLM? Какие техники помогают сузить пространство возможных интерпретаций в промптах?

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

10. Как вы видите будущее этой практики? Считаете ли «выращивание кода» (или похожие осознанные подходы) временным трендом или фундаментальным изменением в разработке программного обеспечения?

Буду рад услышать ваши мнения, опыт и конкретные примеры из практики!

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

Всем привет! Руководитель нашего отдела дизайна @julyakey09опубликовала статью-кейс про то, как мы разработали дизайн для MVP стартапа всего за 7 дней. Это был тот еще челлендж)) В статье Юля рассказывает о нетипичном подходе к UX/UI дизайну, использовании открытых библиотек и работе без формального ТЗ. Получилось интересно, будем рады прочтениям!

В два или три года я столкнулся с великой несправедливостью

Я самостоятельно застегнул все пуговки своей зимней курточки. Снизу-вверх. И когда добрался до самой верхней пуговицы, для неё не нашлось петельки.

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

Ох, сколько эмоций я испытал! Это что же мне теперь всё заново расстёгивать и застёгивать? Может, оставить так?

В итоге принял волевое решение переделать. Это было несправедливо! Я так старался, а теперь приходится всё переделывать!

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

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

Эмоции — те самые, из детства. И чем больший участок нужно переделывать — тем больше эмоций. Но я всё так же принимаю решение не оставлять всё, как есть (и не пытаться исправить с помощью костылей), а переделать нормально с нуля. И с каждым таким случаем я становлюсь умнее и осторожнее и уточняю и проверяю всё больше моментов перед началом работы.

Всем привет. Меня зовут Тирайр, я ведущий процессный аналитик в Спортмастер Лаб и менеджер проекта Со-Общество - базы знаний в Telegram с полезными материалами из области бизнес-анализа, цифровых технологий и менеджмента.

Наша команда провела очередную онлайн-трансляцию с разбором Figma. В качестве спикера пригласили Никиту Берникова, продакт-менеджера Группы цифровых продуктов для сотрудников Спортмастера, который знает о Figma всё (мы проверяли). Получилось очень здорово и насыщено, хоть ребята и волновались: прямой эфир – это вам не шутки! Запись будет особенно полезна начинающим специалистам.

Таймкод:
01:23 О спикере сегодняшней трансляции
02:21 Что такое Figma и для чего она нужна
05:12 Инструмент улучшения взаимодействия со стейкхолдерами
08:47 Насколько необходимо бизнес-аналитику уметь пользовать Figma
09:51 Источники вдохновения и полезной информации
13:58 Уникальный дизайн vs Сложившийся паттерн
14:35 Разбор кейса Lamoda
19:15 Важные правила при создании прототипов
22:43 О тестировании интерфейсов
33:27 О сложностях и набитых шишках
35:08 Знакомство с интерфейсом и возможностями
42:37 Инструмент не только для создания прототипов: опыт Спортмастера
44:37 Антипаттерны и их полезность

Перейти к просмотру

Подписывайтесь на канал Со-Общество и следите за выходом новых трансляций! А мы пошли готовить для вас онлайн-воркшоп, на котором мы покажем, как быстро и просто создавать прототипы интерфейса при помощи Figma.

Для меня в любой работе самое сложное — начать.

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

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

Садясь за создание документа, я иду в гугл.доки, создаю новый файл, даю ему название в привычном формате, пишу заголовок, автора. Если этого не достаточно, начинаю записывать все мысли подряд. Даже такие: «Блин, совершенно не понимаю, с чего начать. Быть может, расскажу о том, для кого этот документ, чтобы открывший его незнакомец мог легче въехать в суть? Точно! Документ предназначен для разработчиков информационной системы такой-то…» Пожалуй, если бы я не умел быстро печатать вслепую, этот способ был бы для меня неприменим.

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