Рубрика «управление процессами в IT»

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

5 страхов разработчиков, которые мы преодолели - 1

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

SAP Process Mining или как разобраться в своих бизнес-процессах - 1

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

Самый простой путь – обратиться к консультантам. Что сегодня предлагает рынок консалтинга для решения этой задачи? Провести интервью с сотрудниками и узнать, как они субъективно видят свои процессы. А видеть они его могут как левую тропинку на картинке. Или вообще могут не знать, какой должна быть эта тропинка. Появляется проблема: как увидеть объективную реальность, а не интерпретацию чей-то точки зрения? Это касается любых бизнес-процессов — закупки, продажи, логистика и т.д.

В линейке продуктов SAP есть отдельное решение SAP Process Mining, которое позволяет видеть «цифровые шаги» сотрудников компании. Фактически, можно увидеть любой процесс из любой информационной системы, прослеживать соответствие действий сотрудников корпоративным политикам и стандартам, различным референсным моделям. Масштаб компании тут не имеет значения — главное, чтобы сам процесс был оцифрован, а не вёлся на бумаге.

SAP Process Mining или как разобраться в своих бизнес-процессах - 2

Читать полностью »

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

Мы знаем о некоторых систематически проблемах, которые хорошо-бы решить и, по возможности, без привлечения дополнительных ресурсов:

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

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

Применение машинного обучения, в приложении к анализу содержания заявки, выглядит как реальная возможность улучшить процесс диспетчеризации.

В нашем случае задачу можно сформулировать следующими задачами классификации:

  1. Убедиться, что запрос корректно отнесен к:
    • конфигурационной единице (одна из 5 в рамках приложения или "другие")
    • категории обслуживания (инцидент, запрос информации, сервисный запрос)
  2. Оценить ожидаемое время на закрытия запроса (как высокоуровневый индикатор "сложности").Читать полностью »

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

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

Продакт и проджект — в чём разница? Мнения руководителей сервисов Яндекса - 1

Но в чём смысл разделения роли менеджера? Кто такой продакт, а кто проджект? По случаю нового набора в нашу Школу менеджеров, который завершится уже 30 апреля, мы задали этот вопрос руководителям четырёх популярных сервисов. Заодно каждый из них поделился подборкой ссылок для начинающего менеджера.
Читать полностью »

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

image
Читать полностью »

Публикуем статью на основании доклада Сергея Поволяшко (Харьков, Украина) с конференции менеджеров проектов в ІТ Software Project Managment Conference

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

Мы не будем говорить о научных методиках, так как о них можно почитать и без меня, поговорим о практическом применение. Я бы хотел вести доклад в интерактивном формате, чтобы мы вместе оценивали ситуацию. Итак, начнем.

Сергей Поволяшко. Почему размер имеет значение? — доклад с SPMConf

Читать полностью »

Как устроен процесс организации разработки в крупном интернет-проекте на всех этапах его роста? Что происходит, когда из стартапа компания перерастает в проект с более чем 190 миллионами пользователей.

В прошлом году на конференции Whalerider Алексей fisher Рыбак рассказывал о том:

  • как у нас Badoo сейчас устроена разработка;
  • как в процессе развития проекта её перестраивали;
  • какие проблемы решали;
  • как преодолевали кризисы роста;
  • на какие грабли наступали.

В секции вопросов есть интересная информация о том, как в Badoo устроена система мотивации и бонусов.
Читать полностью »

Дон Джонс. «Создание унифицированной системы IT мониторинга в вашем окружении».Глава 6.Унифицированное управление на примерах
Ну, вот наконец мы и добрались до последней главы в книге. Здесь будут рассмотрены некоторые практические примеры, ради соблюдения этики автор практически не называет никаких конкретных систем, кроме очень хорошо известных. Рассматривается состояние дел до внедрения систем унифицированного управления и после.

Читать полностью »

Дон Джонс. «Создание унифицированной системы IT мониторинга в вашем окружении».Глава 5. Превращаем проблемы в решения
В этой главе автор собирается поделиться своим видением на способы хранения и поддержания в актуальном состоянии знаний, накопленных в результате длительного хождения по граблям. Основная сложность при их хранении и поддержании массива знаний — найти людей, которые бы сочетали несочетаемое: были тщательны, креативны, усидчивы, обладали острым аналитическим умом, интуицией и не просили бы много денег.

Читать полностью »

Дон Джонс. «Создание унифицированной системы IT мониторинга в вашем окружении» Глава 4.Мониторинг: взгляд за пределы ЦОД
В этой главе речь пойдёт о способах объединения внешнего и внутреннего мониторинга. На что обратить внимание при выстраивании системы, какие при этом есть ограничения. Как не упустить мелочи и получить возможность обозревать картину не только снизу вверх, но и сверху вниз.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js