Привет Хабр! Я отвечаю за производственный процесс от бэклога до выпуска релиза клиенту в одном из трёх крупных банков, и мой календарь в среднем выглядит вот так. Если твой календарь выглядит похоже, то тебе тоже есть, что менять. Я расскажу о своих девяти правилах, которые помогают справиться с нагрузкой, оптимизировать календарь, перестать уставать и выгорать на работе.
🔥 Серия: Чем болен средний бизнес? Диагностика и лечение управленческих болезней. Статья 4 Миллионы на ветер: как не купить IT-систему, которая вас разорит
[💼 Бизнес-модели*] [📊 Управление проектами*] [💻 IT-инфраструктура*] [📈 Аналитика*]
❓ Почему 9 из 10 IT-проектов превращаются в «черную дыру» для денег? И как попасть в те 10%, у которых все получилось?
😩 Вы устали от обещаний интеграторов и бесконечных счетов за «доработки». Вы видите, как дорогая ERP-система превращается в дорогую иконку на рабочем столе, которой никто не пользуется. Знакомо?
⚠️ Проблема не в том, что вы выбрали «не ту» систему. Проблема в том, что вы играете в игру с заведомо проигрышными правилами.
📉 В этой статье мы разбираем всю цепочку провала - от выбора системы до саботажа сотрудников:
🚫 «Прокрустово ложе» для бизнеса: Как коробочные решения ломают ваши уникальные процессы.
💸 Скрытые затраты: Почему реальная стоимость проекта в 5 раз выше той, что вам показывают в смете.
🧠 Когнитивная ловушка: Почему сложные схемы BPMN и архитектура «1С» обречены на провал на уровне человеческого мозга.
🚀 Но главное - мы поговорим о выходе. В статье я покажу альтернативный путь, основанный не на выборе «модного» софта, а на построении системы, понятной всем — от директора до кладовщика. Узнайте, как язык ДРАКОН и архитектура на базе метамодели меняют правила игры и позволяют, наконец, получить от IT то, чего вы ждали — порядок и управляемость.
🛠️ Хватит латать дыры. Пора строить мосты. Инструкция - внутри.
Грамотная оценка ниши — одно из важнейших исследований для развития стартапа. Часто случается, что проект получает много позитивной обратной связи на самых ранних этапах, однако потом следует большой провал. Почему так происходит?
Людям интересно новое. Часто к новым проектам приковано большое внимание, особенно если фаундер активно продвигает его. Первые пользователи — родственники, друзья, неравнодушные люди, такие же авторы стартапов — готовы охотно давать обратную связь и хвалить продукт. Однако их поведение не отражает реальный спрос. Первые пользователи мотивированы интересом, возможно даже «хайпом», если продукт отражает актуальный тренд. Но на перспективу это работать не будет.
Как понять, что ваши пользователи не испытывают реальную потребность в продукте?
📌 Они «пришли» с площадок, где обсуждаются стартапы. Скорее всего, это такие же фаундеры, которым просто интересно все, что есть на рынке.
📌 Они воспользовались продуктом единожды и больше не возвращаются к нему.
📌 В результатах интервью вы часто читаете такие фразы как «классно», «прикольно», «это в тренде». Это говорит о том, что продукт отражает актуальный тренд, но это не даст стартапу буста.
Признаки долгосрочного спроса на продукт:
📌 Среди пользователей появляются люди, которых вы не просили тестировать продукт. Они приходят органически и по «сарафанному радио».
📌 Потребность в продукте у людей возникает часто. В идеале — каждый день.
📌 Пользователи готовы платить, хотя бы немного. Как правило, если аудитория видит ценность, она готова потратить деньги.
📌 На рынке есть другие возможности закрывать боль ЦА. Это всегда является маркером того, что проблема не надумана вами, а есть у большого числа людей.
Позитивная обратная связь с первых дней приятна и укрепляет веру в успех. Однако всегда стоит смотреть на нее под критическим углом: любопытство, вежливость, желание прикоснуться к тренду — это не есть реальный спрос. Лучше всего увидеть это на ранних этапах и скорректировать продукт, его маркетинг, особенности или даже переопределить ЦА проекта.
В ИТ есть три роли, которые часто путают: Project Manager (PM), Product Manager (PdM) и Program Manager (PgM). Звучат они похоже, но задачи и фокус у каждой разные. Встречаясь с каждой из них в своей карьере, каждый раз возникало ощущение "дежавю". Оказалось "Вы не понимаете, это другое!" - разница есть. Понимание этой разницы помогает компаниям эффективнее выстраивать процессы, а специалистам правильно строить карьеру и лучше ориентироваться в сообществе.
В современном IT-мире часто возникает путаница между различными ролями. Одним из примеров является роль Delivery Manager, которая имеет некоторые сходства с Project Manager. Хотя обе позиции связаны с управлением проектами, их обязанности и зоны ответственности существенно различаются. В этой статье мы рассмотрим на примерах, что должен делать каждый из этих специалистов в конкретных ситуациях.
Курс Олега Якубенкова по Масштабированию продукта давался долго - год. Причины: высокая нагрузка на работе, материал, над которым надо много рефлексировать, но и манера подачи знаний у Олега Якубенкова, откровенно, иногда отталкивала. И я прокрастинировал. Недавно закончил и решил подвести итоги. Нашел всего один развернутый отзыв и множество коротких на сайте у Олега. Далее честное мнение - стоит или не стоит вкладываться в получение заветного сертификата от Go practice. Статья будет полезна владельцам продуктов по компетенциям выше среднего, а так же начинающим продуктоводам так как в ней много ссылок на прочие программы обучения. Может быть, до неё доберётся кто-то из владельцев бизнеса, высшего менеджмента и в мире станет немного меньше неожиданных разочарований.
Автоматизация обслуживания клиентов — важный фактор работы компании, помогающий отстроиться от конкурентов, повысить производительность труда, снизить затраты и удерживать лидерство на рынке в своей сфере.
В статье расскажем, что дает компании цифровизация услуг и какие для этого используются инструменты. Приведем примеры решений для автоматизации обслуживания клиентов.
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. В статье расскажу о проблеме, с которой сталкивается большинство ИТ-компаний: они тратят миллионы на разработку функций, которыми никто не пользуется.
На собеседованиях HR-специалисты часто используют метод STAR. Соискателям его тоже полезно знать: метод помогает структурировать рассказ о себе и понять, что хочет услышать от вас интервьюер. Расскажу, как адаптировать его под себя, чтобы структурировать опыт и подчеркнуть вашу ценность перед нанимающим специалистом и продуктовым менеджером.
Привет, Хабр! Меня зовут Лера, я технический писатель в Авито, и я обожаю разбирать книги, которые помогают иначе смотреть на привычные вещи — будь то управление командами, формирование привычек или работа с культурой. В этой статье разберем книгу Малкольма Гладвела Tipping Point — исследование о том, как идеи, тренды и социальные явления внезапно «взрываются» и начинают распространяться, словно эпидемия.
Это очередная статья на тему «как прокачаться продакту». Однако рекомендовать в ней книги, подкасты или «100% работающие» фреймворки я не буду.
Привет, меня зовут Юля! В этой статье я поделюсь навыками, которые стоит развивать всем желающим качаться в продукте.
Решили как-то предприниматели ИТ-фирму организовать. Офис открыли, дорогим оборудованием обставили, всё по-модному и современному. Тут тебе и чай с печеньками, и комнаты отдыха, и психолог молодая и красивая. Не фирма, а заглядение.
Нашли заказчика — и появился у них новый проект. Чтобы его реализовать, решили нанять одного программиста, такого, чтоб потолковее да по-покладистее, и платить ему решили побольше. В помощь ему взяли дешёвого менеджера проектов. От него требовалось, чтобы выглядел прилично и любую прихоть заказчика выполнял.
И вот нашли менеджера и программиста. Программист весь такой «семь пядей во лбу», рвётся в бой и готов писать хоть сутками. Менеджер — приветливый, дружелюбный и амбициозный. Одна только небольшая проблема — в программировании он полный ноль. Настолько ноль, что когда его спрашиваешь: «Что такое метод пузырька?» — он в ответ загадочно улыбается, достаёт стакан и пол-литра.
И вот начинаются рабочие будни. На любое совещание менеджер берёт с собой программиста. Надо же как-то задачи ставить, а разбираться в том, как и что писать — это не его забота. Его дело — «проект к успеху двигать». Программист же и по совещаниям бегает, и работу работает. Работы становится всё больше и больше, количество совещаний и их длительность тоже постоянно увеличиваются. Чтобы всё успеть, приходится писать в спешке. Местами уже не до идеального кода.
Заказчику, конечно же, промежуточные результаты не показывают. Зачем ему знать внутреннюю кухню? Вдруг заподозрит чего или разочаруется. Как итог, на первом релизе получают кучу замечаний, недовольного заказчика, и менеджер обещает всё переделать, и, конечно же, за счёт фирмы, в которой он работает. Они ведь сделали не то, что он ожидал. В итоге программист работает круглые сутки, чтобы всё исправить, а менеджер его ещё и дёргает по нескольку раз на день, а то вдруг он опять «дров наломает». Худо ли, бедно, всё доделывают-переделывают и показывают заказчику. Он недоволен, но так и быть запускает проект у себя и продолжает оплачивать дальнейшую разработку. А так как объём работ увеличивается и хочется, чтобы качество было получше, он соглашается увеличить финансирование.
Проработав почти 25 лет в ИТ, у меня накопилось то, о чём хотелось бы рассказать. Я изучил множество технологий, участвовал в массе проектов. Работал как в мелких фирмах, так и у мировых гигантов. Общался с разными людьми из разных стран и континентов. Основным моим мотивом всегда был успех проекта. Я всегда пытался сделать работу на максимуме своих возможностей. Много читал и изучал, анализировал, писал на разных языках и платформах. Всегда было стремление сделать проект как можно лучше. Но далеко не всегда это получалось. Когда давали возможность, что-то выходило, хотя не всегда. Иногда возникали обстоятельства, которые ставили крест на проекте.
Факторов, приведших проект к успеху или, наоборот, к провалу, всегда было много. Анализируя свой опыт, у меня возник вопрос: а почему так получалось? Почему один проект выстрелил, а другой нет? Почему с одной командой мы буквально горы свернули, а с другой так ничего и не добились? Вспомнив все эти ситуации и проанализировав их, я написал две книги, в которых рассказываю о том, что может негативно повлиять на команду разработчиков и в итоге привести к провалу проекта, над которым они работают, либо к её распаду.
В книге «Лоу-перформеры в ИТ: кто тянет команду вниз» я рассказываю о сотрудниках, которые делают вид, что работают. С такими приходилось очень часто встречаться, и я пришёл к выводу, что они негативно влияют и на проект, в котором задействованы, и на команду, частью которой являются.
Я описал шесть типов поведения таких людей и дал рекомендации, как с ними работать и минимизировать их негативное влияние. Также поделился собственным опытом и собрал рекомендации из различных публикаций, в которых описывается данная проблема.
Тимлид бывает отличным техническим специалистом, но плохим руководителем, если в одиночку тащит проект на себе. Он закрывает чужие задачи, пишет документацию, подключается к каждому созвону и один следит за дедлайнами. Такой режим превращает его в «бутылочное горлышко» — человека, от которого зависит движение проекта.
Раньше я тоже был «горлышком». Однажды руководил сервисом для банка, но заболел ковидом и три дня не мог работать. Проект замер: разработчики ждали указаний, тестировщики сидели без дела, аналитики не могли ничего согласовать. Пришлось с температурой выйти с больничного и вести процесс самому, потому что кроме меня никто не понимал, как в банке устроена работа сервиса регистрации бизнеса.
Меня зовут Степан Сорокин, я delivery manager в Outlines Tech. Ниже поделюсь мнением, как перейти от роли пожарного к роли стратега: научиться делегировать, развивать команду и автоматизировать рутину, чтобы не переписывать код за разработчиков ночью и не выходить на созвоны с температурой. Ещё поделюсь своими артефактами, которые разгружают операционку и оставляют время на стратегию.
На каждом созвоне слышно одни и те же правильные слова:
Надо думать наперед,
Архитектура должна быть мощной,
Давайте писать с запасом на рост.
А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно.
Машинное зрение работает, и работает хорошо. За год количество проектов выросло с 5 до 36. Мы привлекли много подрядчиков и знатно пробежались по граблям.
А теперь я хочу рассказать про эти самые грабли.
Первые же серьёзные — проверка качества решений. Как оценить чужое решение и работает ли оно так, как надо нам? Тут много подходов и способов, например, использовать скрытые выборки, оценка на потоке и базовое — проверка кода и всего пайплайна, от разметки до метрик обученной модели.
Вторые — что не стоит оставаться наблюдателем на протяжении всей разработки. Если вы начинаете изучать систему только на приёмке, вас наверняка ждёт дивный мир сюрпризов. Включаемся сразу, ещё и раньше разработчиков (ТЗ никто не отменял).
А самая большая для меня боль года — донести и согласовать фразу «понятный и читаемый код» с каждой командой со своим чувством «прекрасного», и это не только про длину строк или формат докстрингов, но и про общие понятия в разработке.
Но давайте по порядку.
Привет, Хабр!
Сегодня разберём на практике один из самых недооценённых, но при этом максимально полезных инструментов в арсенале любого тимлида — Delegation Poker из подхода Management 3.0. Это не игра ради фасилитации, а вполне рабочая методика, чтобы прозрачно и конструктивно обсудить распределение ответственности в команде. Без «угадай, чего я от тебя жду», без абстрактного «будь проактивным» и без пассивной агрессии на ретро.
Исповедь замученного директора: почему ваш главный враг — не хаос, а собственный образ мыслей
Статья из серии "Чем болен средний бизнес? Диагностика и лечение управленческих болезней"
Вы - самый занятой и самый уставший человек в своей компании. Хватит.
Вы - тот самый "пожарный", "нянька" и "арбитр", который лично разруливает каждый затык. А в это время ваш бизнес, как тот воз из басни, тянут в разные стороны. Знакомо?
Проблема не в ленивых сотрудниках и не в сложных клиентах. Проблема в том, что мы пытаемся лечить симптомы, а не болезнь - болезнь нашего управленческого мышления.
Я начинаю серию статей, где без воды разбираю, чем на самом деле болен средний бизнес. В первой статье - жесткий, но честный диагноз. Я покажу 4 симптома, которые есть у 80% руководителей, и дам одно простое упражнение, которое вскроет истинные причины вашего хаоса.
Готовы посмотреть правде в глаза и начать строить систему, а не латать дыры?
Первая статья из серии уже ждет вас. Осторожно, может быть больно.
**#бизнеспроцессы #управление #менеджмент #хаос #стартап #дракон
Ведение сложных международных переговоров в условиях кризисной ситуации с учётом менталитета заказчика.
В некоторых командах важнее видимость работы: апдейты, движ в задачах, созвоны. Я устал тащить всё сам и попробовал выглядеть занятым.
Через три месяца меня повысили, но теперь мне нужно вычислять таких, как я.