Статья для тех, кто хочет выжать максимум из 1С с ограниченным бюджетом.
Вводная часть
«Как можно автоматизировать продажи, не вкладывая сотни тысяч рублей? У нас маленький штат и нет своей ИТ-команды».
Привет, Хабр. С вами Катя, я аккаунт-менеджер в KISLOROD. Это почти как сапер, только вместо мин — дедлайны, баги и молчаливые клиенты.
Сегодня расскажу, как один вопрос и три уровня менеджмента спасают отношения с клиентами. За год мы увеличили NPS с 47% до 57%. Это означает, что клиенты чаще готовы рекомендовать нас — не из вежливости, а благодаря реальным улучшениям в управлении проектами, коммуникации и сервисе. Рассказываю, как это сделать.
Еще пару лет назад я считал себя «классическим» продуктом. Знал пользователей, гонял дизайнеров, выкапывал инсайты, пинал разработку — все как учили. Но в последнее время начал замечать странную штуку: лента вакансий как будто перекроили. Вместо привычного Product Manager всё чаще вижу TPM. Technical Product Manager. Technical Program Manager. Technical ещё что‑то. Причём зарплаты те же или выше. А требования — местами совсем другие.
Сначала я это игнорировал. Ну подумаешь, слово «technical» прицепили. Потом — напрягся. Потому что под капотом оказалось: от тебя ждут не просто roadmap на квартал и пару фичей в прод, а полного погружения в архитектуру, понимания API, базы данных, CI/CD, пайплайнов, очередей, да ещё и умения всё это дело засинкать между 3 командами параллельно.
В какой‑то момент я начал задаваться вопросом: а я вообще кто?
Пользователь Reddit опубликовал в r/rustjerk сгенерированный ИИ пост под названием «Почему наш CTO запретил использовать Rust после одного переписывания кода». Очевидно, что этот рассказ выдуман, но у меня есть история похожая на него в том смысле, что успех проекта на Rust привёл к прекращению использования этого языка в компании.
Несколько лет назад я работал в стартапе-«единороге», во время пандемии развивавшемся невероятно быстро. Его основное приложение было написано на Ruby on Rails, а часть инструментария для работы с видео — на Node.js, но мы никак не применяли быстрые компилируемые языки наподобие Rust и Go. Через пару месяцев после моего прихода в компанию нам нужно было реализовать работающий в реальном времени сервис, который бы позволял нам получать информацию о том, кто из пользователей находится онлайн (то есть в профиле есть зелёная точка) и чем они занимаются (например: N пользователей смотрят презентацию X, M пользователей находятся в разделе маркетинга и так далее). Ничего особо сложного, но мы рассчитывали на изначальный рост до ста тысяч пользователей. Эта цель тоже не особо сложна, но большинство разработчиков согласилось, что Ruby — не лучший выбор для этого.
Когда компания только начинает свой рост, информационная безопасность почти неизбежно воспринимается как палки в колеса. Формальные согласования, запреты, новые правила — все это кажется лишним грузом. Но рано или поздно наступает момент, когда становится все сложнее стабильно и предсказуемо развиваться без системного подхода к ИБ.
Матвей Григорьев, руководитель направления ИБ в Dodo Engineering, заглянул к нам в подкаст «Все по ИБ» и поделился опытом построения ИБ-службы с нуля в компании, которая растет как на дрожжах. Он объяснил, как превратить безопасность из назойливого «контроллера с линейкой» в настоящего партнера бизнеса — и рассказал, как в Dodo внедряли подход Zero Trust. Мы собрали главные тезисы в этом конспекте — дальше слово Матвею.
Некоторое время назад у нас появилась новая должность — маркетолог‑скаутер. Это специалист, который профессионально занимается поиском и отбором новых идей и проектов на ранних стадиях.
Скаутинг — это эффективный инструмент для нахождения на рынке новых идей, которые будут потенциально прибыльными. Для стартап‑студии идеи и партнёрства‑ это главное «топливо».
Скаут отсматривает тематические сайты в Интернете, паблики акселераторов, чаты, где общаются авторы новых проектов. Его задача не просто «увидеть» идею, а сразу пропустить ее через фильтр:
📌во‑первых, собственную насмотренность,
📌во‑вторых — соответствие трендам, актуальность задумки, технологию реализации, прикинуть объем рынка.
Иногда уже на этом этапе понятно, есть ли у идеи потенциал стать продуктом или она останется на уровне «сырой» задумки. С авторами наиболее перспективных идей нужно установить контакт и поддерживать его.
Рынок автоматизации процессов сейчас переживает качественное обновление — компании самых разных масштабов стремятся минимизировать ручную работу, ускорить процессы, снизить число ошибок в цепочках передачи данных между системами и повысить управляемость бизнес-процессов в целом…
И именно на стыке этих задач возник интерес к универсальным low-code решениям, которые позволяли бы настаивать автоматизированные потоки данных быстро, а главное — без обязательного привлечения разработчика к каждой задаче. Одним из наиболее ярких представителей этого класса инструментов стал n8n — гибкая платформа для интеграции и автоматизации, получившая признание как среди энтузиастов и стартапов, так и в крупных предприятиях.
Впрочем, обо всем по порядку.
Шел 2022 год курс валют хорош и я решил обновил свой ПК. Собрал топовое i9 + 3080Ti (мне для работы :-)). Для хорошего охлаждения было установлено 9 вентиляторов. И все было бы хорошо если бы в небольшой квартире по вечерам/ночам гул вентиляторов начинал мешать семье.
Было принято решение собрать кастомное СЖО. Была собрана система на 2х трехсекционных радиаторах, количество вентиляторов уменьшилось до 6, но как оказалось зря, выдувать горячий воздух из корпуса все так же нужно и количество вентиляторов вернулось снова к 9, хотя и обороты стали меньше и стало тише.
В голову пришла идея отключать вентиляторы работающие без надобности. Ведь видеокарта если не играть особо не грелась. В ходе экспериментов установил, что в режиме работы и просмотра ютуба для охлаждения всего хватало 2х вентиляторов на одном радиаторе и одного радиатора на выдув, остальные можно было выключить. Поискав по интернету выбор пал на контроллер от Lian Li имеющий 4 независимых порта для вентиляторов, в процессе настройки понял для себя что не все вентиляторы могут останавливаться совсем в добавок софт для управления работал отвратительно. Немного пораскинув мозгами было принято решение собрать свой контроллер, ведь ничего особо сложного, думал я...
— Шеф все пропало. Аудитория отваливается. Надо ее срочно догонять. — в компании началась планерка о проблеме удержания.
Невольным свидетелем таких встреч-переговоров я был не раз и не два.
Так и хочется крикнуть:
— Господа, оглянитесь! Мы же не ковбои на диком западе, чтоб по прериям на мустангах за разбежавшимися коровами гоняться!
Давайте лучше поступим, как в том анекдоте: медленно спустимся с горы и огуляем все стадо.
Когда речь заходит о налоге на добавленную стоимость (НДС), концепция кажется элементарной, но на деле процесс может быть весьма запутанным и сложным. И тут возникает тот самый "налог на дизайн".
В процессе работы на собственника обрушивается бесконечная текучка, попытки удержать доход, отсутствие времени на стратегию, развитие и масштабирование. И как результат — начинает преследовать неудовлетворенность
и чувство, что он не на своем месте.
В этой статье я поделюсь системой 6 шагов, которые помогут вам выбраться из такого состояния.
В работе продакт-менеджера важную роль играет Product Discovery — процесс, в котором мы формируем понимание пользовательских потребностей, проверяем гипотезы и находим точки роста для продукта. Один из нестандартных способов углубить это понимание — выйти за пределы привычного рынка и погрузиться в другую среду.
В этом посте расскажем, как мы искали вдохновение и свежие идеи для 2ГИС в Китае. Мы съездили туда командой продактов и дизайнеров транспорта: изучили местные навигационные приложения, культуру и протестировали транспортные сценарии в их естественной среде обитания.
Вмире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха. Если раньше пользователи были готовы мириться с сырыми прототипами, которые «просто работали», то в 2025 году планка качества поднялась так высоко, что одной лишь функциональности уже недостаточно. Современные пользователи ожидают продуманный и приятный UX с первого касания — продукт должен не только работать, но и вызывать восторг. Здесь на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня. Разберёмся, почему MVP теряет актуальность, чем отличается MLP и как компаниям адаптироваться, чтобы завоёвывать сердца пользователей в 2025 году.
Я собрал интерактивный тест из пары десятков парных текстов и предоставил аудитории угадывать где писал человек, а где нейросеть. Было ожидание, что завсегдатаи хабра и айтишники разнесут LLM в сухую. Ан нет, результат вышел отрезвляющим.
Последние 14 лет я работаю в крупных корпорациях. Так случилось, что за это время сменил много ролей, должностей и даже локаций. И на каждой позиции я в той или иной мере вовлекался, участвовал или полностью управлял проектами.
Казалось бы, логично будет рассказать о кейсах успешных запусков, побед и какие инструменты мне пригодились (об этом я, кстати, писал). Но правда заключается в том, что любой, даже самый успешный проект делал мне, как проджект-менеджеру, больно. Несмотря на весь опыт, инструментарий, сильные команды находились слабые места, в которые злобный проект бил точно, сильно и с максимально разрушительными последствиями.
В этой статье я напишу о 5 способах проекта треснуть тебе так, что будет очень сложно подняться, и попробую рассказать, как этой боли избежать. Всем тем, кто ни разу не ошибался и всегда исключительно успешен и превращает в золото все, до чего дотрагивается, — статья будет нерелевантна, так что не тратьте нервы и силы. Для остальных — смотрим, от чего бывает особенно больно.
Хочется стремиться к здоровому рабочему балансу. Мы в Clevertec спросили коллег:
Какие личные системы помогают не выгорать?
Как они планируют время, как отдыхают?
И вообще когда можно считать себя продуктивным?
Вследствие кропотливой, многоэтапной работы проектировщиков и всей команды проекта на свет появился некий результирующий продукт - Требования к целевой Информационной системе. На каждом этапе в качестве входящих ресурсов мы использовали результаты предыдущих, наращивая шаг за шагом понимание и представление о том целевом продукте, который мы должны получить, в результате реализации проекта.
Теперь наступил момент кульминации, когда мы можем специфицировать Требования, взяв за основу все те артефакты, которые получили в процессе проектирования.
Для чего это необходимо делать?
Все полученные артефакты складываются в стройную и полную модель прототипа целевого продукта только в реальности проектировщиков. Если же взглянуть на результат проектирования отстраненным взглядом команды, которой предстоит воплощать эту модель в коде, то окажется, что в общей картине не хватает множества разъяснений, стыковок, структурированности, последовательности исполнения и тому подобного.
Опять же часто команда разработчиков не в полном объеме обладает способностью чтения диаграмм в разных нотациях. А потому их содержание должно быть переведено в более понятное представление, по возможности систематизированное в форме, близкой к структуре задач, поэтапное выполнение которых командой и приведет к тому самому целевому продукту.
Меня зовут Сергей Меркулов и я старший консультант Fix Price. Наши магазины работают уже в 10 странах мира. И это значит, что каждый товар, который представлен на наших полках в зарубежных магазинах, обязательно имеет этикетку на иностранном языке. Для понимания масштабов: в нашей сети примерно 32 тысячи наименований локальных кодов (или SKU, то есть единиц складского учета). В среднем у одного локального кода — 3 штрихкода. То есть фактически у нас 96 000 различных этикеток! И сегодня я расскажу вам о том, как мы научились эффективно работать с ними на рынке ОАЭ.
Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:
1. Когда сложившаяся архитектура подлежит масштабным изменениям.
2. Что не менее важно, когда лучше оставить, как есть.
3. Ключевые признаки проблем в архитектуре.
4. Основные способы исправления таких проблем.
Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:
1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;
2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;
3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;
4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.
Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:
1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.
2. Что маленькие команды работают буквально в разы эффективнее, чем большие.
3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.
Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».
Обзор без маркетинга, с фокусом на то, что реально нужно менеджеру: практика, широта тем, прикладные знания, релевантность, отсутствие воды и инфоцыганщины.
Как-то раз уже делался обзор по всем существующим на рынке курсам по управлению проектами, пришло время почихвостить рынок с новой, актуальной темой.
