Этот дайджест создан совместно с телеграм-каналом PM Live | проджект и продакт менеджмент. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Как сейчас отвечу я на этот вопрос: есть формальные критерии успешности проекта, есть неформальные. Успешный проект должен соответствовать им всем. Но всем критериям, особенно изменяющимся во времени, вы соответствовать не сможете никак.
Обычно мы обрабатываем до 1500 обращений в день. Это в среднем 90 заявок на человека. А когда вводят новые правила маркировки или ломается оборудование у провайдера нагрузка вырастает в 3-5 раз.
Об импортозамещении все начали задумываться задолго до известных событий. Санкции, блокировка лицензий и отключение компаний РФ от известных западных сервисов вогнали последний гвоздь туда, где «лежал вопрос» — идти в эту историю или нет.
Но заявлять и делать – это разные вещи. Мало компаний готовы выложить миллионы просто потому, что надо пересаживаться со «старой и проверенной годами иномарки» на новенькую «Ладу».
Этот пост набрал на Medium 99 000+ лайков. Публикуем на Habr его перевод: *Несколько месяцев назад мой друг Тим устроился на новую работу по продажам в стартап на стадии С, который привлек более 60 миллионов долларов от инвесторов. Он один из лучших продавцов, которых я знаю, но вскоре после начала работы он прислал мне письмо, в котором сообщил, что у него есть трудности с продажами.
Да, у меня немного съехала крыша на этой теме. Но решение создать систему для ведения заметок три года назад — пока что лучшая из моих интеллектуальных инвестиций. В этом посте хочу поделиться, зачем я это делаю, в каком формате и какие полезные практические кейсы для себя нашел. Тема бездонная, на самом деле. Можете взять часть идей и развить у себя.
Всем привет. Меня зовут Сергей Фегон. Я ex-CТО, сейчас работаю руководителем нескольких групп разработки финтех-продуктов экосистемы компаний ВБЦ и TenChat, а также преподаю в OTUS. Делюсь своими знаниями на курсах CTO/Технический директор и Team Lead в OTUS. За время преподавательской деятельности и на основе личного управленческого опыта, я сформировал для себя несколько основных столпов подготовки IT-менеджеров.
Кажется, что совпадение целей у всех участников проекта — необходимое условие его успеха. Однако, мой опыт показывает, что это далеко не так. В этой заметке я расскажу, как различие в целях может стать двигателем успешного выполнения проекта. Вы узнаете, как определить и согласовать разные цели, чтобы они не противоречили, а дополняли друг друга, и как это может привести к достижению общей цели. Делюсь практическими примерами из своей работы и методикой целеполагания, которая помогла мне и моим партнерам добиться успеха.
В нашей работе баги неизбежны, но как именно мы справляемся с этим вызовом — вот что нас отличает. Хочу поделиться с вами историей о том, как одна из платежных команд разработки успешно решала ошибки в продуктовой среде, повышала качество разработки, боролась с легаси кодом и техдолгом.
Руководителями не становятся на пустом месте — это результат той карьерной стратегии, которой ты придерживаешься. Она может быть разной, но абсолютно всем менеджерам нужна поддержка, особенно когда ты растёшь, — кто-то же должен сказать, что всё ок. Этот короткий текст говорит тебе, что всё ок.
Очень часто IT-проекты фокусируются на разработке, настройке и внедрению информационной системы, упуская из вида вопросы трансформации существующих бизнес-процессов и обеспечения приживаемости продукта в рамках этих самых процессов. Это может привести к тому, что затраченные на разработку информационной системы ресурсы не окупятся и не принесут ожидаемого эффекта владельцу бизнеса. Сегодня в условиях значительного влияния различных факторов российским компаниям стоит переосмысливать расстановку границ IT-проектов и фокусироваться на приживаемости систем не меньше, чем на самой разработке.
Как вы отнесетесь, если я скажу, что в идеальной команде могут быть провокаторы, манипуляторы, токсичные, нервные, нерешительные, жесткие, нервозные и неконкретные люди?
Сейчас для многих организаций стоит вопрос перевода серверов с корпоративными системами (СЭД, ERP, CRM и так далее) на российские ОС и СУБД. Казалось бы, в чем может быть проблема? Существует много российских дистрибутивов Linux, а также продуктов на базе Postgres. Среди российского ПО есть выбор кроссплатформенных продуктов, которые не зависят от иностранных технологий. Однако при реализации проекта может возникнуть много сложностей.
В этой статье мы делимся историей перевода серверов крупного заказчика с Windows на Linux. Это красивый флэшбэк, из которого можно узнать про этапы подготовки к миграции, подводные камни и секреты успеха (шутка, ведь секретами никто не делится).
Но вы когда-нибудь пытались спонтанно отдохнуть с детьми или хотя бы спланировать отпуск для всей семьи так чтобы стресс не зашкаливал (внутренние дети тоже подходят) ?
Внедрение практически любой корпоративной информационной системы требует ее доработки для реализации как законодательных, так и специфических требований предприятия. Согласно [1], стандартный функционал КИС покрывает не более 30% бизнес-требований, все оставшиеся – реализуются разработками и донастройками системы. Ведение доработок ERP и ERP2-систем (ERP, Enterprise Resource Planning) – задача нетривиальная по причине того, что разрабатываемая программа должна успешно решать сформулированную бизнес-задачу, быть масштабируемой и расширяемой, а также не нарушать работу смежных модулей системы.
Иногда в жизни бывает так – вам вручают белую каску менеджера вместо привычной оранжевой или синей каски исполнителя и говорят: «Теперь ты — руководитель проекта. На тебя вся надежда». Что делать, если при этом вы не изучали, например, PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами)? Вы могли в них участвовать, но отвечали за функционал и делали работу руками. Как пересесть в другое кресло и вжиться в иную роль, по возможности гася в себе синдром самозванца?
Метрики DORA 4 взяты из книги «Accelerate», популярной книги для Инженерных лидеров.
Сегодня работа архитектора очень похожа на игру House Flipper. Процесс «игры», конечно, сложнее, но основные моменты совпадают.
Я все еще слышу от коллег мысль о том, что собирать кейсы для продакта — пустая трата времени: нужно вспоминать про старые проекты, доставать цифры, а все эти лендинги, презентации и профайлы нужны только дизайнерам.
Посмотреть:
Фактура, собранная за полтора года, как те или иные практики при внедрении в команды помогли ускорить поставки, наладить общение с заказчиками.
Антон Бевзюк, Head of Engineering в компании Mindbox.
Разбор примера многошагового процесса и построение диаграммы.
Метрики собираются во всех информационных системах, которые хотят жить и развиваться. Если вы хотите, чтобы продукт ехал, а не «шашечки», важно спроектировать метрики таким образом, чтобы они не врали. В этом процессе можно столкнуться с переусложненной архитектурой, недостаточностью данных для расчета метрик, непониманием конечным пользователем смысла собираемых событий и, как следствие, неверными выводами.
- Карты процесса-опыта ⏱1 час 40 минут
Метод продолжает и развивает идеи, появившиеся в CJM, Service Blueprint и BPMN. Схема метода — направленный граф, состоящий из ключевых точек и подробностей о происходящем в них. Строгой нотации CJM не существует, автором разработана нотация и пошаговый подход к тому, как создавать схемы процесса.
Разбор распространенных ошибок на реальных примерах.
Хорошей недели!
