Привет! Я Давид Асатрян — создатель Креативного Хаба [Alcor] и руководитель по запуску продуктов и управлению изменениями.

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

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

Меня зовут Валерий Студенников, я программист, и вершиной моей IT-карьеры стала компания REG.RU, где я был сооснователем, техническим директором и руководителем разработки.

За 10 лет REG.RU стала №1 в России по количеству зарегистрированных доменных имен, а затем вошла в тройку лидеров по web-хостингу и VPS. В 2021 году мы с партнером продали компанию, я ушел «на пенсию» и с тех пор занимаюсь преподаванием в Самарском университете, обучая студентов различным IT-предметам.

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

Привет! Я Давид Асатрян — создатель Креативных Хабов (Alcor Hub и Camp Tattoofeel) и парочки проектов для HNWI, UHNWI, UHNWI+ – Darwini Wortex и Mary Frank. И это моя статья о том, как разрабатывать продукты по методу Passion-Driven Decision Making.

Порой я сталкиваюсь с фидбэком от инвесторов в стиле: «Мне пофиг, я так чувствую и хочу вот это и это в своем продукте. Ну и что, что противоречит рынку. Вот деньги – идите делайте». Кошмар классического прожекта… Но если такие проекты существуют, то неужели они не приносят деньги?  

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

Если же после запуска продукт работает не так, как ожидалось (например, его никто не покупает) – тогда данные показывают нам, что пошло не так, что нужно изменить в разработке и/или продажах.

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

«LADA Цифра» — это стартап «Лада-Имидж», одной из дочерних компаний группы «АвтоВАЗ». А еще это уникальный микс из талантов разных людей, которые приняли вызов создать цифровое будущее в автомобильной индустрии. Команда успела поработать в крупных проектах и знает про IT не из учебников. 

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

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

Привет, меня зовут Юрий Москалев, я руководитель разработки в «LADA Цифра». Расскажу, как мы внедрили Kaiten и организовали цикл разработки с его помощью.

Аксеникс внедряет или разрабатывает продукты для клиентов в сегменте крупного бизнеса: банки, ритейл, FMCG, страхование, тяжелая промышленность, для которых остро стоит вопрос импортозамещения.

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

Привет, я Евгений Иванченко, лидер Web QA Гильдии в Dodo Engineering. При иных обстоятельствах я мог бы оказаться главой отдела тестирования, но у нас нет такого отдела. Нет, это не результат техногенной или юридической катастрофы. Мы его просто распустили.

Разумеется, это не значит, что мы перестали тестировать наши продукты. Мы только избавились от выделенной команды тестирования. Как в Dodo Engineering провели глобальную перестройку процессов и чем в этом помог Kaiten — читайте под катом.

Фокус-группы, исследования целевой аудитории, оценка конкурентов — всё это не дает гарантии того, что ваш продукт действительно нужен пользователям. Это прогнозы, которые могут не сбыться. Чтобы узнать наверняка, нужно создать и выпустить на рынок минимально жизнеспособный продукт. Привет, я Артём Трубин, CPO компании ActiveCloud. В этой статье расскажу, в чем разница между PoC, MVP и MLP и как, при запуске нового продукта, снизить риски с их помощью.

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

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

В команде продукта не проводят исследования и действуют «по ощущениям»? Не понятно как создавать продукты, которые соответствовали бы ожиданиям клиентов или превышали их? Как встроить исследования в регулярные процессы своими силами, не нанимая новых сотрудников и без большого бюджета?

В кейсе вы найдете ответы на все эти вопросы!

Asana скоропостижно ушла из России, не оставив своим пользователям достаточно времени на поиск альтернативных решений. Имеем что имеем. Но по протоптанным тропам идти проще, чем прокладывать их самому. Поэтому мы решили поделиться историей компании, которая перешла из Asana в Kaiten заблаговременно. Возможно их опыт поможет вам сделать выбор.

Это кейс бэк-офиса онлайн-школы «Академия Йоги». HR-специалисты, юристы, IT-поддержка, бухгалтерия обрабатывают ежемесячно более 240 заявок, и с помощью Kaiten смогли автоматизировать рутинные процессы и увеличить скорость обработки задач. 

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

Привет, Хабр! Я Ирина Бобрихина, один из скрам-мастеров IT-компании RDP. Хочу поделиться подробным кейсом проведения PI-планирования в крупной компании с помощью сервиса Kaiten.

Ещё больше интересных материалов читайте в нашем блоге.

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

Меня зовут Артём Трубин, я директор продуктового портфеля в облачном провайдере ActiveCloud. Расскажу, как мы наладили пополнение продуктового бэклога идеями от коллег из разных департаментов компании, дали им почувствовать свою важность и сэкономили силы продакт-менеджеров с помощью Kaiten.

У продуктового отдела нет выстроенных процессов? Задачи ставятся через почту? Приоритеты по задачам не очевидны и команда ощущает фоновый стресс? Руководство не устраивала скорость выполнения инициатив? Что же делать...? Об этом читайте в статье!

Привет! Я Лиза, специалист службы поддержки Канбан-сервиса Kaiten. Ежедневно я и мой коллега получаем около 40 запросов от наших пользователей: помогаем разобраться в продукте, найти неизвестные для них функции, устранить проблемы. Рассказываю, как мы организовали свою работу внутри нашего же сервиса с помощью модуля Service desk.

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

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

Ситуация: в Scrum-команде процессы работают как по книжке — задачи закрываются за 1–2 спринта, метрики отличные, все работают. Но, как говорится в анекдоте, есть один нюанс: продукт не приближается к заветному релизу. Что делать? Посмотреть на процессы с точки зрения пользовательских задач и оптимизировать контроль метрик.

Меня зовут Артур Нек, я управляющий партнер Kaiten, а в прошлом Scrum-мастер команд разработки. Расскажу, как простая ошибка в интерпретации метрик может сильно тормозить работу команды и как нам всё-таки удалось ускорить развитие продукта, пересобрав текущие процессы.

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

Если руководитель ставит WIP-лимиты без аналитики, не объясняет команде и заказчикам, зачем нужны ограничения, всё может пойти наперекосяк. Сотрудники будут сидеть без дела или начнут брать задачи в обход менеджера. Я Андрей Сидоренко, сооснователь компании Neogenda, эксперт и тренер по Канбан методу. В статье расскажу, как грамотно ограничить количество задач и не навредить команде.

Привет! Меня зовут Артур Нек, я Kanban-консультант и управляющий партнер Kaiten. Как руководителю, мне важно знать, как идут дела в проекте и есть ли какие-то проблемы. Постоянно спрашивать об этом у сотрудников в чатах или на почте неэффективно, а на просмотр досок и карточек проекта уйдет много времени.

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

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

Привет, Хабр. Меня зовут Артур Нек. Я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В этой статье поделюсь опытом компании Kaiten в поиске работающего способа оценки времени выполнения задач: с чего начинали, с чем столкнулись и что выбрали в итоге.

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

Меня зовут Артур Нек, я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В статье расскажу, как управлять изменениями, чтобы не получить поток заявлений на стол.