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

Размышлял на тему стартапа в 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.

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

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

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

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

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