Это маленькая, но полезная ретроспектива двух профессиональных конференций по интеграции процессов разработки, тестирования и эксплуатации. До совместного мероприятия DevOps&TechLead Conf 2022 осталась всего пара месяцев, поэтому самое время восстановить в памяти то, что было раньше.
Менеджеры обладают всеми возможностями, чтобы заставить команду страдать
Как менеджеры, мы находимся в наилучшем положении, чтобы погрузить в уныние наши команды. Если вы менеджер, стремящийся действительно максимально причинить боль своим людям, обратите внимание! Мы рассмотрим три самых популярных способа.
Правда, мы сфокусируемся только на антипаттернах управления проектами, при том, что есть много других возможностей сделать людей в вашей команде несчастными.
Три секретных антипаттерна
1. «Белка в колесе»
2. «Миллион Agile-встреч»
3. «Гантаголик»
И сразу ссылка:
С вами так бывало? Послушаешь новый альбом и так зацепит, что обязательно нужно со всеми поделиться. Примерно это случилось со мной и книжкой «Shape Up». У меня за плечами десяток лет работы продуктовым дизайнером, и я не раз видел, как проекты проваливаются, поскольку никто так и не смог точно понять, что нужно сделать.
Я также видел, как чёткое понимание цели и жёсткие решения на пути к ней позволяли команде добиться результатов. Хочу, чтобы этого добилось как можно больше людей. Мой посильный вклад — этот перевод.
Приятного чтения и успешных проектов!
В последние годы стало очень модно противопоставлять проектному подходу продуктовый. Мол, проекты — это когда зафиксированы результаты, сроки, бюджеты, и потому всё жёстко и неудобно, а продукты — это когда ничего на старте непонятно, но будем стараться создавать ценность по мере движения вперёд. Управление проектами теперь не в фаворе, управление продуктами — наоборот.
Однако многие, кто заменяет (у себя или у клиента) проектный менеджмент на продуктовый, не утруждают себя анализом границ применимости, а «приклеивают» управление продуктами и к месту, и не к месту.
Приведу примеры, связанный с информационными технологиями: предположим, у нас есть идея какой-то ИТ-системы, закрывающей очень существенную потребность определённой аудитории или устраняющей очень неприятную «боль», при этом аудитория является внешней по отношению к нашей организации и, как нам кажется, готовой платить за закрытие потребности и устранение боли. Мы до конца не понимаем, что за ИТ-система получится, как именно она будет закрывать и устранять, куда она будет развиваться, как её позиционировать, как монетизировать. На верхнем уровне идея нам ясна, а в реализации, понятное дело, будет миллион вопросов и миллиард вариантов. Пригодился бы в таком случае продуктовый подход, применённый к разработке ИТ-системы? Очень вероятно.
Теперь посмотрим на другую ИТ-систему: почти готовую, сторонней разработки, нами приобретённую и теперь кастомизируемую для автоматизации внутренних бизнес-процессов нашей компании. Да, здесь тоже есть разработка и развитие, и даже немножко неопределённости. Стоит ли в этом случае применять продуктовый подход? Совсем не очевидно, ведь продукта как такового у нас нет. Однако очень многие зачем-то пытаются играть в продуктовый менеджмент и в таких вот кейсах.
Много лет мы в ITGLOBAL.COM использовали ServiceNow в качестве инструмента автоматизации управления услугами. Эта платформа де-факто является отраслевым стандартом на рынке ITSM-систем. Но все течет, все изменяется — и в 2019 году мы приняли решение мигрировать на альтернативное решение. Меня зовут Дмитрий Семин, и сегодня я расскажу, как нам удалось сделать это без нарушения внутренних процессов и, что немаловажно, незаметно для клиентов. Возможно, в свете последних событий наш опыт окажется вам полезен.
Многие сталкиваются с проблемой оценки эффективности работы отдельной команды. Как понять куда двигается команда? На что она должна влиять, а на что может? Как её работа улучшает всю компанию?
Эти вопросы задавали и мы себе в команде Каталога приложения «Кошелёк». Поначалу ответы нам казались очевидными — выбираем метрику и по ней делаем все выводы.
В этой статье я расскажу, почему всё оказалось не так просто. Как мы прошли путь от одной метрики до продуктовых исследований, опросов и формирования системы метрик. И как сделать так, чтобы дашборды с показателями и графиками были не просто красочной картинкой, а приносили пользу команде и влияли на её планы и вектор развития.
Немного теории. В любом проекте разработки и внедрении программного продукта существуют два ключевых понятия: управляющий комитет (steering committee) и интегральные характеристики хода проекта (наиболее популярный метод освоенного объёма, входит во все стандарты, прост для заучивания).
Приведу пример, что если данные понятия не на словах, не на бумаге в уставе проекта или в project definition, то в данном проекте не может быть кризиса.
Выдержка из IFS ERP Implementation Methodology, которую я переводил в косматом 2005(6) году для знакомых, который неплохо знали английский, но ничего не понимали, ни в ERP, ни во внедрении тяжёлых «тиражных» продуктов.
Что ни говори, российское общество устало от откровенного “фейкового лухари” и регулярных попыток перекладывания любых новых издержек на клиента. Потребитель не верит в причины повышения цен и все чаще видит несоответствие соотношения цены и качества.
Всё - от совершенно примитивного в массе своей и безграмотного подхода к ценообразованию, помноженного на весьма либеральное антимонопольное регулирование.
Но ведь бизнес не может работать себе в убыток, воскликнут многие в праведном гневе. Что делать продавцу, если поставщик повысил цены? Похоже, и до покупателей, и до продавцов, и до государства начинает доходить, что так дальше не может продолжаться.
Что делать?
Изучим возможности, которые уже сегодня есть у бизнеса работать по честной цене.
К читателю
Автор статьи не обладает специализированными знаниями в классическом кризисном менеджменте, единственное что он уже отличает кризисное управление (управление в кризис) от антикризисного управления, что обычно путают. Автор статьи практически всегда был вовлечен в проекты такого рода на «плохой» стадии как управленец. Часть процесса пикирования в кризис им наблюдалась без права решающего голоса. С точки зрения автора статьи чистые методы решения проблем в проектах не могут быть успешно применены в данном типе проектов, что позволяет считать любой кризисный проект проектом с высокой сложностью. Сложность кризисного проекта по мнению автора статьи определяется не стоимостью, не требованиями к качеству, не сроками. Как следствие содержание кризисного проекта зависит от решений спонсора как реагировать на проблему в проекте, которая заставила считать данный проект «особым». Автор статьи не претендует на универсальность примененных проектных решений и универсальность разработанных методов.
Данная статья подготовлена на примере антикризисного управления в проекте разработки и внедрения К(орпоративной) И(нформационной) С(истемы) для IT-дочки крупнейшего холдинга.
Привет! Недавно мы разработали для российского банка и запустили сервис, который помогает пользователям при получении финансовых услуг. Как и всегда в финтехе, сервис должен был отвечать требованиям безопасности, отказоустойчивости и надежности. А для его внедрения нужно было решить еще одну интересную задачу – разобраться в бизнес-процессах банка и улучшить их автоматизацию, используя движок Camunda BPM.
Изучая задачу, мы выяснили, что материалов об автоматизации бизнес-процессов в Camunda немного, особенно на русском языке. Поделимся своим опытом реализации проекта на Camunda, Java и Spring Boot.
Материал будет полезен в первую очередь тем, кто начинает новый процесс на Camunda, а также тем, кто находится в поиске свежего взгляда на реализацию процессов в условиях кластера с микросервисами. Планируем далее продолжить эту тему и рассказать о тестировании моделей процессов.
Этот туториал поможет разобраться в этапах проектирования продукта.
Обзор доступных инструментов для исследований в небольших студиях или для фриланс-специалистов.
Как найти пользователей для тестирования? Как создать профиль пользователя?
Какими способами тестировать гипотезы и важно ли это вообще
Тот, кто не готов внедрять новые решения, достаточно скептично относится к такой формулировке как Low Cost Engineering, считая, что создание прототипа – это огромные затраты. Опытные же инженеры все чаще используют данную концепцию как один из инструментов бережливого производства.
Ранее мы уже рассматривали, что такое репутация в интернете, кому и зачем она нужна, а также то, какие инструменты, помогают представить продукт в интернете в выгодном для нас свете. Сегодня же мы посмотрим на работу репутационных агентств через другую призму, а именно, призму морали. Попытаемся разобраться: является ли работа репутационных агентств безнравственной или же методы репутационщиков могут быть оправданы?
Мораль в сфере маркетинга и рекламы
Небольшая ремарка вместо вступления:
Давайте немного разберемся с определениями, и сразу отметим, что мы не будем углубляться в философию и прочие области человеческого знания, а определим мораль - как некоторую совокупность представлений о хорошем и плохом, о добре и зле, правильном и неправильном, принятую для большей части абстрактного общества. Аморальным будем считать нечто лживое и фальшивое, нечто, оставляющее неприятный осадок, нечто, идущее вопреки нашему представлению о добром и правильном. А моральное определим, соответственно, как противоположность первому.
Представим ситуацию: вы работаете Pr-менеджером, рекламным агентом, интернет-маркетологом, называйте как хотите (утрирую), - вашей основной задачей является продажа, вы должны составить такой образ/упаковку продукта, благодаря которому его захочется купить. Если товар имеет непрезентабельный вид - можно заказать профессиональную фотосессию и воспользоваться фоторедакторами, если товар не обладает выдающимися характеристиками - можно написать красивый и складный продающий текст, если продукт мало узнаваем - можно влиться в хайповый инфоповод или привлечь медиаперсон для рекламы.
Всем привет. Как и обещал, публикую вторую часть статьи на тему того, кто приносит больше пользы, Business Product Manager или Technical Product Manager.
Напомню, что первую часть статьи, где я рассказываю, какая ситуация сложилась у меня в бизнесе и какой управленческий эксперимент мы запустили в результате разногласий СРО (меня) и СЕО, вы можете найти по ссылке.
Какими качествами должен обладать «хороший» PM и должен ли он быть для своей команды «мамой» или «папой»? На этот вопрос во время дискуссии «Современный Project Management» проекта «Техпора» от компании *instinctools попробовали ответить приглашенные ведущие эксперты. Каждый из них прошел свой уникальный путь в IT-бизнесе и руководил большими проектами и большими командами. Мы предлагаем вам выдержки из дискуссии, которая длилась больше часа и, по признанию слушателей, оказалась очень полезной как для начинающих PM, так и для опытных менеджеров.
Продолжаем делиться опытом нашего коллеги Алексея, который после 7 лет программирования на зарубежном проекте неожиданно для себя возглавил службу поддержки третьей линии. В этой статье расскажем про первые семь кейсов, которые были найдены и устранены только за последний год.
Материал может быть полезен разработчикам, аналитикам и QA для того, чтобы по-новому взглянуть на бизнес-процессы и предотвратить некоторые баги.
...Был отличный зимний день, ничего не предвещало беды. Внезапно данные от одного госпиталя перестали приходить. Прошло 5 минут, мы были спокойны – ранее такое случалось несколько раз по 10-15 минут из-за проблем в сети госпиталя.
10 минут. Начинаем испытывать легкое беспокойство, на всякий случай откладываем задачи, чтобы быть готовыми срочно переключиться на проблему. Госпиталь молчит.
Привет, Хабр!
Наша коллега Алеся Кондрашова из экосистемы Сбера (СберЗдоровье) написала статью о том, как почистить бэклог и посмотреть на продукт по-новому. Делимся с вами!
Всем привет. Хотел бы в рамках данной статьи рассмотреть такой вопрос, как построение команды продакт-менеджеров и выбор правильной конфигурации навыков у тех специалистов, которых мы бы хотели видеть в своей команде.
Надеюсь, что данная статья будет полезна руководителям продуктов, которые имеют в своей команде несколько продакт-менеджеров по разным направлениям.
Расскажу о календарях YouGile, Битрикс-24, Weeek, ClickUp, Wrike, Asana, Trello. Давно анализирую системы управления проектами, делаю обзоры, сравниваю функции, подкидываю идеи по продукту разработчикам. Протестировала более 50 систем.
Все календари проектов похожи. Задачи попадают туда с досок или из списков и to-do-листов, если проставлены даты. Есть цветная маркировка и фильтрация. Можно добавить задачу, изменить сроки перетаскиванием, завершить.
Системы расположила по порядку: от тех, что точно останутся доступны в России – до работающих с ограничениями. В конце – сравнительная таблица.
В большинстве компаний одним из этапов отбора является выполнение тестового задания. И чтобы повысить свои шансы на успех, особенно для ребят без опыта или уровня Junior, необходимо заранее прорешать типичные тестовые задания. Так ты на собеседовании будешь чувствовать себя увереннее и с реальным тестовым справишься гораздо быстрее, т.к. часто время на его выполнение строго ограничено.
Собрал подборку из 30 тестовых заданий для Product Manager и Product Marketing Manager от реальных IT, EdTech и FinTech компаний России и мира. Уровень вакансий Junior и Middle.
