В какой-то момент дел становится так много, что невозможно все держать в голове, поэтому мы ищем помощь извне. Тут нас выручают инструменты для оптимизации времени.
Хотим поделиться с вами парочкой таск-трекеров, который помогут облегчить вам жизнь!
Есть в Айти стандартные грейды: Джун, Мидл, Синьор.
И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊
Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.
В мире победившего эджайла, SCRUM, как один из наиболее популярных фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков она стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах scrum-мастеров (речь не обо всех, но о об очень многих). В посте попытался обобщить все проблемы SCRUM, как "фреймворка" для проектного управления и создания продуктов.
Планируем поход в магазин по методике MoSCoW, чтобы на реальном примере разобрать, как формировать бэклог, можно ли брать срочные задачи в закрытый спринт и почему бэклог лучше не заполнять на 100%.
Привет, меня зовут Алексей Лобзов, я руководитель направления развития компетенции системного анализа в Альфа-Банке. В прошлом году мы в банке проводили Analyze IT Meetup. Кроме интересных докладов у нас был круглый стол, куда мы пригласили Лидера компетенции из Сбера, Solution архитектора из СИБУР Digital и Product Owner’а из Альфа-Банка.
Что их всех объединяет? Они все в прошлом были системными аналитиками. Наши герои поделились тем, как из системных аналитиков (СА) перешли на новую позицию. Тема оказалась животрепещущей — было много вопросов как на митапе, так и после, поэтому позже мы той же компанией и на ту же тему записали подкаст в СИБУР Digital.
И если для вас вопрос «А куда расти дальше, если я уже сеньор?» стоит «на повестке дня», то приглашаю почитать статью, подготовленную по материалам круглого стола.
Привет! Меня зовут Адель Давлетшин, я занимаюсь роботизацией процессов в компании «Лента». Сегодня я хочу поделиться историей о том, как наше чрезмерное увлечение RPA привело к остановкам и сбоям в критическом процессе, и как этот случай побудил нас перейти от вопроса «Можно ли это сделать с помощью RPA?» к более важному вопросу: «А почему это стоит делать именно с помощью RPA?».
Темпы изменений внешней и внутренней среды компаний высоки, поэтому стратегия должна быть простой, быстрой и соответствовать современным технологиям. Все больше стратегий разрабатывается и управляется с использованием Agile-подхода. Однако доклады про Аджайл хорошо звучат на конференциях, в реальности компании, особенно из IT-сектора, продолжают использовать каскадный подход, основанный на анализе и расчетах.
Несмотря на необходимость быстрых решений и гибкого подхода к тактическим задачам, стратегия все равно важна, так как руководители компании сталкиваются с проблемой высокой энтропии. Потребность управленцев определить основные направления работы и планировать будущее не исчезла.
Стратегию не выкинуть, но она становится более технологичной, гибкой и учитывает человеческий фактор. В этой статье мы рассмотрим инструменты для создания первого, портфельного, уровня стратегии.
Базовая проблема любого бизнеса сводится к тому, что задач всегда больше, чем ресурсов. И если вы находите дополнительный источник ресурса, то получаете еще больше входящих идей, задач и предложений — даже если до этого казалось, что больше некуда.
В Lamoda Tech приходят самые разные инициативы: одни коллеги просят внедрить электронный документооборот, другие — оптимизировать доставку товаров на склад. Как без погружения в их процессы понять, на что распределить ресурс?
Прежде всего, определимся с терминами. Что такое аудит? Это проверка бухгалтерской отчетности юридических (в отдельных случаях и физических лиц) на предмет достоверности данных. Причем эти данные должны соответствовать как показателям бухгалтерских регистров в электронной базе (например, та же 1С), так и сведениям из первичных документов [1].
Осуществлением аудита занимаются представители профессии под названием «аудитор». Этапы процесса проведения аудиторской проверки показаны на рис.1.
Если между отделами поддержки и разработки нет взаимопонимания, страдать от этого будут в первую очередь продукт и его пользователи. В статье рассказали о том, что может провоцировать напряжённость между разработчиками и агентами поддержки и что мы сделали для того, чтобы максимально её снизить.
Привет! Я - Катя Леханова, менеджер проектов в компании iSpring.
В компании iSpring одна из главных ценностей - удовольствие клиента от использования наших продуктов.
В статье про двухуровневую техподдержку мы делились опытом построения процессов для решения сложных клиентских задач. При такой организации - саппортовые специалисты разделены на 2 группы: первая и вторая линия. Первая линия работает с обращениями клиентов, оформляет в задачи запросы, которые нужно решать разработчику. Эти задачи проходят контроль второй линии и передаются в дежурную команду через менеджера саппорта.
Такой процесс действует до сих пор и упрощает обработку поступающих запросов.
Вместе с тем бизнес постоянно развивается, растет количество клиентов, растет количество активных пользователей LMS, возрастает и комбинаторика кейсов в использовании продукта.
Сейчас в моде слово «клиентоцентричность», которое заменило привычное мне, бумеру, «клиентоориентированность». И для меня это выглядит так: если раньше важно было делать свой продукт или сервис, ориентируясь на клиента, то сейчас надо просто пойти и сделать, как тебе приказали. И неважно, что ты думаешь, ты же должен быть клиентоцентричным. Для гос. проектов это весьма актуально, кто работал, тот знает.
Однако есть один маленький нюанс: Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять? Вот об этом и предлагаю поговорить.
Руководители организаций регулярно сталкиваются с новыми вызовами и всё возрастающими ожиданиями относительно эффективности работы. В то же время они теряются в попытке выбрать подходящие управленческие идеи, инструменты и методы, которые действительно помогут им решить организационные проблемы и повысить общую производительность. В отчаянной попытке найти решение неразрешимых проблем, менеджеры могут поддаться соблазну новых техник и подходов, которые обещают дать простые ответы на сложные вопросы. Но новейшая управленческая причуда приносит лишь временное облегчение: те же самые проблемы снова всплывают, просто в другой части организации.
Чаще всего инженерное проектирование связывают инженерное механическое проектирование с инструментом, станками, кораблями, ракетами, роботами и машинами. Тем не менее, его применение выходит далеко за рамки этих привычных примеров. Инженерные принципы активно задействованы в множестве неординарных областей, начиная от создания музыкальных инструментов и заканчивая дизайном одежды. Рассмотрим несколько занимательных случаев.
Привет, Хабр! На связи Дмитрий Секачев — корпоративный архитектор службы развития ИТ-архитектуры ВТБ. Я занимаюсь корпоративной архитектурой в дочерних компаниях банка. Сегодня расскажу вам про новый архитектурный продукт — «Референтная прикладная архитектура как АрхПродукт» (РПА как АрхПродукт).
Мы с коллегами готовим серию статей, в рамках которых вы узнаете, как применять данный продукт в процессах слияния/поглощения компаний, построения целевой прикладной архитектуры своей организации, как сократить объем «выборочных» процедур по выбору ИТ-решения и многие другие интересные аспекты применения референтной прикладной архитектуры. Поехали!
Система координаций — базовый инструмент управления сотрудниками, без которого сложно развивать бизнес.
Например, можно даже отложить развитие сотрудников (если нет ресурсов или потребности), можно отложить разработку регламентов и инструкций, но координации и планерки откладывать нельзя.
Всем привет! Сегодня я постараюсь раскрыть плюсы и минусы работы по найму и собственного бизнеса в сфере ИТ, как разработчик может организовать свое дело и что ему для этого потребуется. Выбор между наймом и собственным бизнесом является одним из самых сложных. Оба варианта имеют свои преимущества, и выбор зависит от индивидуальных целей и способностей.
Что интересного писали на этой неделе про управление проектами? Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Посвящается тем немногим руководителям проектов, кто действительно смог сформировать эффективные рабочие команды, которые не развалились и не переругались в процессе реализации проекта.
Третья часть посвящается "Управлению Командами" на проекте. В ней я также расскажу про "лайфхаки", которые помогут вам спланировать работы, сформировать команды и управлять ими немного лучше, чем те, кто делает это "по-классике".
