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

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

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

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

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

Компания 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 века, придумав диаграмму Ганта. Затем придумали компьютеры, а после — Интернет. И, казалось бы, какие тут еще могут остаться проблемы, но не всё так просто — ведь нельзя просто создать универсальный инструмент, который удовлетворял бы нуждам всех. 

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

Расскажу о календарях YouGile, Битрикс-24, Weeek, ClickUp, Wrike, Asana, Trello. Давно анализирую системы управления проектами, делаю обзоры, сравниваю функции, подкидываю идеи по продукту разработчикам. Протестировала более 50 систем. 

Все календари проектов похожи. Задачи попадают туда с досок или из списков и to-do-листов, если проставлены даты. Есть цветная маркировка и фильтрация. Можно добавить задачу, изменить сроки перетаскиванием, завершить. 

Системы расположила по порядку: от тех, что точно останутся доступны в России – до работающих с ограничениями. В конце – сравнительная таблица.

Всем привет! Меня зовут Антон, я системный архитектор отдела разработки курьерских сервисов в Почтатехе. Мы разрабатываем сложные цифровые продукты Почты России. Помогаем ей стать удобнее, быстрее, качественнее и технологичнее для вас. 

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

Прежде, чем стать системным архитектором, я успел побывать разработчиком и тимлидом. И моя работа всегда была неразрывно связана с людьми, технологиями и процессами. В этой статье я хочу рассказать, как благодаря оптимизации процессов мы ускорили time-to-market для IT-систем нашего отдела.

Все персонажи являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.

***

- Сашуля, мы все подтвердим. Присылай письмо.

Вот это да! Мы что, договорились?

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

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

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

Просматривая на следующий день почту я поняла, что драгоценные коллеги переобулись. Вместо обещанных “Окей, подтверждаю”, моя почта вопрошала:

- А почему менеджеры из коммерческого отдела получают премию сразу после подписания контракта и получения аванса от заказчика? – внезапно заинтересовался самый лучший начальник (чуть-чуть не директор). – Я предлагаю запретить это. Пусть ждут, когда вся команда получит, это пойдет им на пользу.

- А я считаю, что надо увеличить бонус за перевыполнение! - пишет директор по операциям.

- А почему мы не разобрали бонус для топ-менеджмента? Какой бонус будет у топ-менеджмента я вас спрашиваю?

- Так, а я забыл, мы контракт на год подписываем или на три? – вспоминает о важном вопросе развивающий директор.

Меня зовут Азаренко Михаил и я работаю удалённо уже 10 лет (начал ещё до того, как это стало мейнстримом). В этой статье поделюсь своим опытом и видением о работе с командой и психологическом аспекте работы в 4-х стенах. Конечно же, мой личный опыт будет через призму работы из дома и на должности управляющего владельца. Поехали.

Эта статья – о Pet project, собственных проектах, которыми многие из нас занимаются в свободное время. Поговорим о том, нужны ли такие увлечения архитектору и как Pet project может помочь в работе. Также я расскажу о своих проектах и опыте, который я с их помощью получил. Добро пожаловать под кат!

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

Обсудили волнующую многих тему на нашем митапе с Захаром Овчаровым (Respona front-end team-lead, Toptal senior front-end developer). Встреча прошла перед конференцией IT-People Conf в Казани и вызвала интересную дискуссию. Полная версия обсуждений в нашем видео. 

Дисклеймер от Захара: все персонажи выдуманы, все действия нереальны, автор не несет никакой ответственности за ваши действия, поэтому действуйте на свой страх и риск;) 

Внезапно для себя вместо фронтенд-разработчика я стал тимлидом. Казалось бы, ничего страшного. Но как результат — огромная куча проблем.

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

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