По ходу Жизни, мы развиваемся, у нас раскрывается определенное Мировоззрение и мы что то делаем в своей Жизни согласно нее.
В моем случае, мое Мировоззрение привело к тому, что я реализовываю один Проект через два Стартапа. Об этом Проекте и будет речь в этой статье.
За год команда разработки Kaiten выросла в 3 раза, и привычные процессы перестали работать: доска переполнилась, потерялась прозрачность, а чтобы узнать, на каком этапе работа, приходится проваливаться в каждую карточку.
Вместе с Юрой Юрковым, Delivery Manager Kaiten, расскажем, как мы прошли путь трансформации, какие решения сработали и как не потерять управление в момент масштабирования. Если вы в похожей ситуации — читайте статью и используйте наш опыт, чтобы быстрее навести порядок.
Когда хирург сказал «ампутация», мой мозг выдал исключение LifeCriticalInterrupt. Как Python-инженер, дообучавший трансформеры, я столкнулся с фатальным сбоем в базовой платформе — собственном теле. Потеря ноги казалась крахом pipeline’а жизни. Но год спустя я понял: это не баг, а требование к пересборке архитектуры.
Изначально я не собирался так делать. Хотел обойтись списком в телефоне и парой заметок. Но через неделю невеста намекнула (наорала), что либо помогаешь, либо прощаемся.
Тогда я открыл таск-трекер «просто, чтобы разгрести бардак» — и втянулся больше, чем в собственный стартап. В статье — наша история, фейлы и результат.
Привет, Хабр!
Внутренние продукты умирают чаще, чем живут. Причём гибнут не на проде, не из-за кривого кода и не от того, что разработка пошла не по плану. Они разваливаются на самом старте — когда гипотеза ещё не успела обрести форму, но уже обросла Jira-задачами. Где-то я видел, что 9 из 10 новых инициатив не переживают первую встречу с пользователем. Почему? Потому что команды бегут в реализацию, не удостоверившись: а надо ли это вообще кому-нибудь?
Классический двухнедельный Scrum здесь не спасёт. Он хорош, когда вы уже уверены в направлении. А вот когда на старте всё зыбко и туманно, нужен отдельный, чётко спланированный discovery-конвейер. Такой, в котором каждые три недели появляется не слайд, а артефакт — проверенный, валидированный, готовый к следующему шагу. И вот хорошо вписывается 5D Discovery.
Пандемия заставила нас работать из дома, но перенесла в Zoom все офисные проблемы. Бесконечные стендапы, тотальный контроль и выгорание от видеозвонков — классический Agile даёт сбой. Но его можно спасти асинхронными практиками.
Читайте в статье:
✔️ Почему 80% митингов можно заменить письменной коммуникацией?
✔️ Как GitLab добиться результатов без ежедневных созвонов?
✔️ Чек-лист перехода на async-работу без потери эффективности.
Привет, Хабр! Меня зовут Дмитрий Волков, я Head of Product Design в MANGO OFFICE.
Недавно мы провели внутренний митап на тему универсального языка работы SCRUM-команды при проектировании пользовательского опыта. Решил поделиться выводами и практическими инструментами, которые помогают решить проблему коммуникации в продуктовых командах.
В компаниях часто ищут агента изменений: «сильного менеджера», который возьмёт весь хаос на себя и решит проблемы, накопленные годами. Но когда менеджер выходит на работу, оказывается, что нет ни целей, ни ответственности, ни бюджета. Зато слышит фразу: «Мы тебя наняли — ты и решай». Вместо изменений менеджер тушит пожары, берёт на себя чужие задачи и пытается доказать, что перемены вообще нужны. В итоге его увольняют за то, что тот «не оправдал ожиданий», а ситуация в компании остаётся прежней.
Меня зовут Степан Сорокин, я Delivery-менеджер в Outlines Tech и руководитель проектов с опытом более 10 лет. Запускал процессы в стартапах и корпорациях. Почти в каждом проекте сталкивался с одной и той же проблемой: компания хочет внедрить Agile или другую методологию, но не готова действительно менять процессы и вкладывать в это ресурсы. От менеджера ждут, что он изменит всё сам, без поддержки сверху.
Ниже расскажу, почему изменения срываются, и покажу три рабочих инструмента, которые помогают запускать перемены. А ещё подскажу, как распознать на собеседовании компанию, которой на самом деле изменения не нужны.
Полагаю, каждый Product Manager хотел бы стать Senior Product Manager и на эту тему написано множество статей. Поэтому эта статья не о том, как получить повышение до старшего руководителя, а о том, как улучшить свое мышление и стать лучшим руководителем. Любой человек может мыслить как старший PM, независимо от его должности - и если у кого-то есть должность старшего PM, это еще не значит, что он ее заслуживает.
Привет, Хабр!
Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми.
8 лет я работаю QA, совмещаю ручное и автоматизированное тестирование. Недавно я начала осваивать бэкенд-разработку и задумалась, как тестировщикам и разработчикам не просто сосуществовать, а эффективно работать вместе. В какой-то момент моя команда столкнулась с похожей ситуацией, и я подняла вопрос на уровне команды, это было совместное решение.
В ходе обсуждений и экспериментов мы пришли к новой для нас практике — совместному тестированию. Это сработало. Об этом подходе я и хочу рассказать.
Когда ломается система продаж, первый вопрос от бизнеса часто звучит так: «Когда уже ИТ все наладят» или «Почему опять не работает?». Но редко кто задаётся другим — более фундаментальным — вопросом: из чего состоит стабильность цифрового контура?
В реальности, если ИТ не работает — бизнес останавливается. Но в восприятии большинства сотрудников/менеджеров/агентов, ИТ по-прежнему выступает как вспомогательная функция, а не как ядро операционного процесса.
Это подтверждает и внутренняя диагностика, проведённая нами через анкетирование бизнес-заказчиков. Вот что мы увидели:
Путь из продактов в прогеры: выясняю, почему кодеры "гады" такие, делают только баги и плохо соблюдают сроки
Статья будет полезна для тех, кто менторит стажеров/джунов-программистов, и для самих смельчаков-новичков в этом нелегком деле.
Привет, Хабр!
Иногда кажется, что команда вроде бы стабильная, спринты идут по плану — а под конец снова в панике жмёмся к дедлайну, выкидываем фичи и дорабатываем вечерами. Чтобы такого не происходило, я хочу рассказать про простую и очень рабочую модель — 3–3–3. Она помогает прогнозировать скорость команды без гаданий на story points и держать реалистичный фокус: сколько мы реально успеем, а не сколько хочется.
Наверняка тебе знакома ситуация: начинается утренний синк, и ты задаёшься вопросом: «А что вообще сейчас происходит с задачами?». Кто‑то что‑то делал, кто‑то ждал ревью, у кого‑то что‑то зависло, а кто‑то вообще сидит без работы. На расспросы команды уходит много времени, а картина всё равно остаётся неполной. И самое важное не про все вспомнишь в момент синка.
Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.
Agile — только для IT? Точно нет. Команда Kaiten поговорила с экспертами из разных сфер и выяснила, как принципы Agile работают за пределами разработки: какой эффект они приносят и какие сложности вызывают.
Рассказываем истории других команд, которые помогут пересмотреть подходы в своем отделе и сделать процессы эффективнее.
Приложения для планирования и управления проектами призваны помочь нам успешно разрабатывать и поддерживать проекты в рамках нашего бизнеса. Сегодня, в эпоху цифровых технологий, когда все больше отраслей уходит в онлайн и все больше людей работают дистанционно, на рынке программного обеспечения для управления проектами царит настоящие изобилие. Но как понять, какие продукты действительно хороши, а от каких лучше держаться подальше?
«Подчинение авторитету» — книга не о менеджменте, но она как нельзя лучше расскажет про базовые психологические процессы, происходящие в людях, которыми управляют. На стыке психологии и философии в ней рассказывается про эксперимент, где выявляли предел, до которого может дойти человек, подчиняясь другому человеку.
Создателей эксперимента вдохновили преступники нацистской Германии, и они задались вопросом: «Почему обычные люди выполняли чудовищные приказы?». Чтобы на него ответить, они провели серию экспериментов, в которых обычные люди попадали в ситуацию подчинения.
Изменения в управлении часто ассоциируются с громкими заявлениями, трансформациями, реструктуризациями и, конечно, внутренним сопротивлением. У нас всё случилось иначе.
За последние несколько лет мы практически полностью перешли от принципов менеджмента 2.0 к менеджменту 3.0. Но интереснее всего то, что сотрудники этого почти не заметили — просто потому, что всё происходило естественно. Делюсь своими наблюдениями, как и почему это получилось.
Всем привет!
Сразу оговорюсь, что это моя первая статья на Habr. Надеюсь, что она окажется полезной для команд, сталкивающихся с проблемой вовлеченности и ответственности новых участников. Желание написать ее появилось внезапно. Мне захотелось поделиться успешным опытом преодоления проблемы, с которой мы в нашей команде внезапно столкнулись. Но обо всем по порядку.
