Менеджмент

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

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

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

Этот фреймворк — не просто очередной чек-лист: он синтезирует лучшие практики мировых стандартов (COBIT, ISO 27001, NIST, DNB/BIO) и позволяет провести оценку по пяти уровням зрелости с однозначными, понятными критериями для каждой практики. 

Эта статья про историю SDLC — System (Software) Development Life Cycle. Он принадлежит далёкому прошлому, но на него тем не менее продолжают ссылаться на конференциях и пытаются использовать.

Итак, в далеком 1981 году менеджеры задумались о регламенте для ведения ИТ-проектов, ведь софта требовалось всё больше, его разработка перестала быть частью научных исследований, а становилась частью развития бизнеса и даже развития государства. А это значит, что необходима методика, на которую, если что-то пошло не так, можно кивнуть «мы всё делали правильно». Если кто не знает, то основное назначение именно в этом, а вовсе не в том, чтобы успешно делать проекты.

Менеджеры посмотрели, что пишут специалисты, увидели водопад Ройса (1970) — простую и понятную схему. И наплевать, что сам Ройс в сопровождающей статье писал, что так работать не будет.

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

Меня зовут Ирина Колесникова — я тимлид в финтех-компании Точка. В этой статье расскажу, как мы столкнулись с «зоопарком» при переезде с Vue на React, и что помогло превратить хаос в систему. 

Всем привет. Меня зовут Михаил и на данный момент времени я работаю тимлидом в крупной IT‑Компании.

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

Я капитально прихерел при работе с одним руководителем, благо его успешно из компании попёрли. Но вот осадочек остался. Вот вам список его золотых цитат и действий, которые он регулярно исполнял. Это пример того, как не надо работать в компании и ставить себя в команде. Ну поехали.

Ни для кого не секрет, что в нашей стране практически любой руководитель в сфере IT начинал свою профессиональную карьеру рядовым сотрудником. Причины, побуждающие специалиста начать двигаться в сторону руководящих позиций, могут быть разными, и в зависимости от причин скорость этого пути также может существенно различаться. Однако сам процесс становления «молодого» руководителя почти всегда сопряжён с одними и теми же проблемами. Основываясь на личном опыте и опыте наших коллег и подчинённых (которые тоже руководители), мы хотим коротко разобрать проблемы, особенно беспокоящие и мешающие вчерашним разработчикам, выбравшим сегодня путь своего развития в качестве руководителя группы или отдела. Более высокопоставленным руководителям эта статья также может быть полезна при менторстве «младшего командного состава».

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

Для начала давайте разберёмся, что именно мы собираемся сочетать — дадим определения. Может быть, уже одно это хорошо прояснит некоторые вопросы.

Я думаю каждый сотрудник IT‑компании, где есть эта выделенная роль, особенно проектный менеджер, сталкивался с этим: есть отдельный мир конфигураций и скриптов, где изолирована коммуникация и технический тикет основное средство общения. Обычно CTO ставит их под свой колпак, изолируя от остальных команд и создавая эффект «касты избранных». Простые запросы превращаются в бесконечные уточнения, а работа стоит в ожидании»благословения». Я уверен, ты догадался о ком я.

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

Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:

Вы ставите таймер на 25 минут, делаете перерыв и уверены, что стали продуктивнее. А что если это не так? Изучаем, что говорят реальные исследования.

«То, как команда играет в целом, определяет её успех. У вас может быть самая лучшая в мире команда звёзд, но если они не будут играть вместе, клуб не будет стоить и гроша».
— Бейб Рут

«Если вы хотите идти быстро — идите в одиночку. Если хотите идти далеко — идите вместе».

— Африканская пословица

«Талант выигрывает игры, но команда выигрывает чемпионаты».
— Майкл Джордан

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

Меня зовут Яна, и у меня за плечами 13+ лет в ИТ, десятки проектов, международные операторы, интеграции, продуктовые команды, устройства, и сейчас — низкоорбитальная спутниковая система для высокоскоростной широкополосной передачи данных (более детально рассказывала о себе в Скрам‑мастер vs мастер реальности). С таким багажом у меня есть чёткое ощущение: где бы ты ни был, без команды ты не создашь ничего действительно крутого. И вот почему.

Большой проект. Сложная система. Куча требований. Первое, что приходит в голову любому инженеру: «Надо декомпозировать!» Разложим по модулям, разделим на команды, каждый займется своим куском. Большую сложную задачу превратим в набор простых понятных подзадач. Так учат делать везде. Так делают все. Это основа основ. Но никто не говорит о том, что происходит дальше. Никто не предупреждает о скрытых ловушках, которые ждут на этом пути. А их там... много.

Когда ты запускаешь SaaS‑продукт для селлеров на Wildberries, особенно в формате Telegram‑бота, кажется, что главная задача — фичи, код и отчёты. На практике же — главное это команда. Делюсь опытом: от первых кик‑оффов и прозрачности задач до one‑to‑one и управления конфликтами. Всё — на основе реального опыта и с учётом скорости, с которой живёт любой стартап.

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

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

Курс состоит из шести разделов, и каждая статья будет охватывать один раздел. Вот их список:

Привет всем! Меня зовут Артур Арсёнов, я Product Design Lead в Garage Eight. За свою карьеру я успел и побыть владельцем лаборатории, внутри которой было собственное мини-агентство, и в корпорациях поработать. И сегодня уже знаю: каждый из этих форматов задаёт не только стиль работы, но и разную степень вовлечённости в контекст клиента. Это влияет на то, какие задачи вы решаете, как быстро растёте и что в итоге отдаёте пользователю.

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

Как сделать так, чтобы система KPI действительно работала на бизнес? Этим вопросом задаются все менеджеры, эффективные и действительно эффективные. Меня зовут Юлия Чикурина, и уже несколько лет я работаю в Innostage над сложными проектами управления эффективностью в госсекторе. Теперь расскажу, как наши наработки адаптировать под бизнес и работать с KPI не для галочки, а для реальных результатов.

Несколько лет назад я решил испытать себя и поехал в горный массив Хибины, чтобы пересечь его в одиночку. Через четыре дня я оттуда вышел, но не там, где планировал, и не в том состоянии. Часть вещей была утеряна, я был мокрый, голодный, злой — своего рода аll-inclusive наоборот.

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

Привет, Хабр! Я Александр Фокин, лидер по стратегии в МТС и участник TeamLeadConf. Уже 15 лет работаю в IT-индустрии в управлении продуктами и проектами, выстраивании процессов, кризис-менджменте и траблшутинге.

Сегодня поговорим о том, как применять стратегические подходы в жизни и начать управлять ею осмысленно. На работе мы почему-то более ответственны, в то время как жизнь со многими «случается», от события к событию. Я уверен, что это можно изменить даже применив всего несколько предлагаемых инструментов.

Разобрали приложения крупных фэшн-ритейлеров. Рассказали, как ЦУМ, ТВОЕ, Shein и Farfetch убивают UX и что они делают реально круто.

Представьте, что ваш пользователь нажимает «Установить» — и уже через минуту кидает коллеге ссылку на готовую инструкцию. Никаких «позже разберусь», форм авторизации и лишних вкладок. Это и есть оптимальный он-бординг, за которым сегодня охотится каждый продукт.

Меня зовут Алексей, я делаю Steppo — расширение, превращающее клики в наглядные гайды. Последние полгода я усердно измеряю Time‑To‑Value (TTV): сколько секунд проходит между установкой и ценностью, когда человек говорит «Вау, оно работает!». Всё, что дольше 60 секунд, статистически превращается в болотце, где тонут конверсии.