Управление проектами *

Развитие информационных технологий привело к появлению бизнес-аналитиков.
Кто это такой? В чем его основные функции?
Кто был первым бизнес-аналитиком?

Это слишком серьёзный текст, чтобы его читать человеку без чувства юмора.

Менеджеры обладают всеми возможностями, чтобы заставить команду страдать

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

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

Три секретных антипаттерна

1. «Белка в колесе»

2. «Миллион Agile-встреч»

3. «Гантаголик»

Немного теории. В любом проекте разработки и внедрении программного продукта существуют два ключевых понятия: управляющий комитет (steering committee) и интегральные характеристики хода проекта (наиболее популярный метод освоенного объёма, входит во все стандарты, прост для заучивания).

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

Выдержка из IFS ERP Implementation Methodology, которую я переводил в косматом 2005(6) году для знакомых, который неплохо знали английский, но ничего не понимали, ни в ERP, ни во внедрении тяжёлых «тиражных» продуктов.

К концу 2007 года я уже почти пять лет работал Софт-инженером в министерстве ИТ. Прошел долгий путь от джуна до сеньора и понятно, что уже примерял к себе роль тимлида. Видел себя человеком, который рулит командой и процессами.

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

«AvantajPrim» была еще молодой компанией, созданная моими друзьями из университета. Они сделали мне заманчивое предложение: перейти на работу к ним и участвовать в разработке нескольких проектов - заказов правительства РФ. Конечно же, в начале пути, как сеньор разработчик. Ну а через пару месяцев, если смогу показать себя как лидер, то получу эти долгожданные погоны тимлида. Это было именно то, чего я тогда хотел...

К читателю

Автор статьи не обладает специализированными знаниями в классическом кризисном менеджменте, единственное что он уже отличает кризисное управление (управление в кризис) от антикризисного управления, что обычно путают. Автор статьи практически всегда был вовлечен в проекты такого рода на «плохой» стадии как управленец. Часть процесса пикирования в кризис им наблюдалась без права решающего голоса. С точки зрения автора статьи чистые методы решения проблем в проектах не могут быть успешно применены в данном типе проектов, что позволяет считать любой кризисный проект проектом с высокой сложностью. Сложность кризисного проекта по мнению автора статьи определяется не стоимостью, не требованиями к качеству, не сроками. Как следствие содержание кризисного проекта зависит от решений спонсора как реагировать на проблему в проекте, которая заставила считать данный проект «особым». Автор статьи не претендует на универсальность примененных проектных решений и универсальность разработанных методов.

Данная статья подготовлена на примере антикризисного управления в проекте разработки и внедрения К(орпоративной) И(нформационной) С(истемы) для IT-дочки крупнейшего холдинга.

Тот, кто не готов внедрять новые решения, достаточно скептично относится к такой формулировке как Low Cost Engineering, считая, что создание прототипа – это огромные затраты. Опытные же инженеры все чаще используют данную концепцию как один из инструментов бережливого производства.

«Какой план на неделю? Я не знаю, чем сегодня день закончится!»

«Да зачем планировать, если все равно ничего не понятно!»

Знакомо? Наверняка! Эта та реальность, в которой мы сейчас находимся. Уровень неопределенности просто зашкаливает, и горизонт планирования сокращается, в лучшем случае, до нескольких дней, а иногда и до нескольких часов.

Но планировать можно. Более того, я скажу, что планировать НУЖНО! Это позволяет вам не только управлять ситуацией, но и значительно понижает ваш собственный уровень тревоги. Как это работает, какие есть подходы и инструменты для такого планирования - прошу под кат, все расскажу в этой статье.

Компания iSpring 20 лет разрабатывает решения для дистанционного корпоративного обучения. Клиенты находятся в 172 странах, поддержка работает в режиме 24/7 на семи языках. В месяц обрабатываем примерно 7300 обращений по всем каналам связи: по телефону, электронной почте, в чате. 

97% кейсов закрываются со статусом «Довольный клиент». Но так было не всегда: чем больше становилось клиентов, тем сильнее мы начали проседать. Особенно страдали кейсы, которые отдавались в разработку. 

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

Меня зовут Арина, я руководитель отдела технической поддержки iSpring. Расскажу, как переход к двухуровневой системе поддержки помог сократить время решения задач с трёх дней до трёх часов, снизить нагрузку на отдел и перестать дёргать разработчиков из-за лёгких задач. 

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

Всем привет! Меня зовут Владимир Тутынин, я методолог продуктового подхода и сегодня расскажу о своем методе планирования. Вы увидите, какие шаги я выполняю и какими инструментами пользуюсь для достижения результата.

Нам понадобятся две программы:

1.      Evernote – это система заметок, которые хранятся в блокнотах и помечаются метками. Очень похожа на Confluence.

2.      Trello – это доска задач с определенными правилами, на которой мы отображаем движение задачи по этапам. 

Представим, что наше движение к достижению цели – это движение ракеты. Сначала мы находимся на высоте 0 метров, далее 10 000м, через минуту 20 000м, далее 30 000м и 40 000м. Эти отметки мы будем использовать как ориентиры и начнем наш маршрут в «космос». 

Формирование меток

Заходим в Evernote и создаем 4 метки так, как показано на рисунке. Этими метками мы будем ориентироваться в пространстве заметок. В скобках после названия метки показано количество заметок, имеющих такую метку. Например, у меня есть 36 заметок с меткой «20.000м Цели».

Какими качествами должен обладать «хороший» PM и должен ли он быть для своей команды «мамой» или «папой»? На этот вопрос во время дискуссии «Современный Project Management» проекта «Техпора» от компании *instinctools попробовали ответить приглашенные ведущие эксперты. Каждый из них прошел свой уникальный путь в IT-бизнесе и руководил большими проектами и большими командами. Мы предлагаем вам выдержки из дискуссии, которая длилась больше часа и, по признанию слушателей, оказалась очень полезной как для начинающих PM, так и для опытных менеджеров.    

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

Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.

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

Привет, Хабр!

Наша коллега Алеся Кондрашова из экосистемы Сбера (СберЗдоровье) написала статью о том, как почистить бэклог и посмотреть на продукт по-новому. Делимся с вами!

Привет! Меня зовут Иван Аксенов, я Ruby-разработчик в компании Домклик. Расскажу о своём подходе к анализу причин выпуска неудачных релизов.

Человек склонен совершать ошибки в любой деятельности. Иногда ошибки совсем незаметны и ни на что не влияют, иногда — неизбежны. А бывает, что они настолько глупые, что стыдно признаться в их совершении. В начале карьеры в IT я тяжело переживал каждый свой неудачный релиз, требовавший выпуска хот-фикса. Я корил себя за невнимательность, и лишь спокойствие более опытных коллег позволяло охладить голову и вернуться к нормальной работе. Со временем я стал понимать, что собственная внимательность — лишь один, и далеко не главный фактор на пути к стабильной работе системы. 

В повседневной деятельности тимлида ИТ-сервис менеджеров я часто сталкиваюсь с запросами на назначение специалиста на проект. На первый взгляд – вполне себе тривиальная процедура, но с ростом числа сотрудников и ростом количества запросов появилась потребность просто и понятно для всех сторон структурировать спрос / предложение. Придумывать свой формат представлялось слишком трудоемкой задачей: использовать, например, подход Agile-племён слабо заходило в наш фреймворк, а околопсихологические/астрологические/эзотерические практики (нужное подчеркнуть) смотрелись откровенно бесполезными. На помощь пришёл ITIL, а если конкретнее, LACMT. Итак, как последователь культуры постоянных улучшений, я решил поделиться небольшими наработками по части адаптации лучших практик в управлении ITSM-командой.

Привет Habr, добро пожаловать в ад проект-менеджмент. Вместо Данте сегодня я буду разбирать свои грехи (а их много) как руководитель и заказчик на каждом этапе разработки ПО, а вы можете за компанию. Вергилий присоединиться, к сожалению, не сможет, у него омикрон. По ходу разберемся.

Я работаю в IT-сфере относительно недолго, но ошибок накопилось много, причем таких, которые вполне возможно было предотвратить, если кто-нибудь своевременно сказал бы перестать страдать фигней. Заказчик как правило в позиции власти, так что мотивации у него признать свою неправоту мало, а проект-менеджеру часто неловко это объяснить. В этой статье хочу обсудить многочисленные грабли, на которые пришлось наступить, как избежать это самим заказчикам, и что могут сделать проект менеджеры, чтобы с этим справиться.

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

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

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

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

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