Open source профессиональный и любительский — взять лучшее от двух миров? [Что думают эксперты и лидеры индустрии]

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

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

(далее…)

Equity «на салфетке»: как договориться с партнёром в стартапе и не пожалеть

Что важнее: 10 строк кода или договорённость на берегу? Истории конфликтов, судебные кейсы и гигиена договорённостей, которую игнорируют почти все фаундеры

Мы договорились устно. Всё по-братски. Что может пойти не так?

Всё. Абсолютно всё.

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

(далее…)

Почему попытка изменить поведение людей редко работает в сфере маркетинга и коммуникаций

Привет, друзья! 👋

Сегодня хочу что-нибудь о штуке, которая вызывает у меня когнитивный диссонанс уже не первый год. Чем глубже я погружаюсь в маркетинг и поведенческие проблемы, тем яснее становится: попытка напрямую изменить поведение людей через убеждения — почти всегда неудача. Почему так происходит? Давайте разберёмся. Без воды, только факты и чуть-чуть личные наблюдения.

(далее…)

Зачем и как писать ТЗ

Зачем и как писать ТЗ - 1

Эта статья написана для заказчиков разработки, в основном касается IT-продуктов на ранних стадиях. Цель статьи — дать понимание, что писать в ТЗ, как и главное, зачем.

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

Зачем писать ТЗ

    (далее…)

200 000+ снимков мусора: что мы узнали о датасетах

В нашей работе хватает безумных задач. Мы создали первого в России цифрового PR-менеджера, разрабатывали виртуальную примерочную и делали много чего еще, о чем не всегда можно рассказать. Но когда мы взялись за создание ИИ-сортировщика мусора MARQUS, поняли — будет совсем жестко.

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

(далее…)

Когда «ускорить разработку» — значит всё сломать

Почему скорость команды — это не всегда про людей, а про инфраструктуру

https://t.me/+7-m11XS2SFQwNjk6

«У нас горят сроки, надо быстрее!»
«Почему вы делаете задачу уже вторую неделю?»
«Давайте подключим ещё одного разработчика — точно ускоримся».

(далее…)

Как мы переходили с UiPath на PIX RPA

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

Меня зовут Олег, я разработчик в АШАН ТЕХ. 

В 2023 году наша команда приняла стратегическое решение — перейти с UiPath на российскую платформу PIX RPA. Это была не просто смена софта, а комплексный процесс миграции, адаптации и доработки роботизированных процессов под новые реалии. И всё это — в крайне сжатые сроки, всего за 2 недели!

Рассказываю, как мы справились и с какими вызовами столкнулись. 

(далее…)

У разработчиков не должно быть сроков

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

Сроки — это миф

(далее…)

Программирование «в уме»

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

Что такое дизайн расширения?

(далее…)

Программирование «в уме» или дизайн расширения как ключевой инструмент управления функционального архитектора

Вытаскиваем максимум пользы из привычного проектного артефакта в условиях внедрения систем с высоким уровнем кастомизации

Что такое дизайн расширения?

Давайте для начала разберемся с названием. Функциональный дизайн разработки, технический проект, описание доработок и т.д. У разных интеграторов я встречал разные названия этого проектного артефакта, но поскольку я апологет внедрения одинэсочки по методологии ЭЙМ, то далее в этой статье я буду называть этот проектный артефакт так как это принято в ЭЙМе – дизайн расширения (см. MD.050, MD.060 и MD.070).

 

(далее…)