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

Некоторых разработчиков иногда сравнивают со снежинками — они уникальные, выдающиеся, и, естественно, самоуверенные. Работать с «обычными» сотрудниками легко. Гораздо труднее справляться с проблемными типажами. Одинокий волк, всезнайка, перфекционист — в каждой команде есть человек, с которым сложно и руководству, и коллегам. Автор статьи, программист и сооснователь digital-агенства Mindnow, Вадим Кравченко рассказывает, как не усугубить ситуацию с трудными сотрудниками, превратить сложности в возможности для роста и продолжить успешную командную работу. Особенно, если проблемный коллега талантлив и приносит пользу компании.

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

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

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

Сто лет назад экономисты и философы предполагали, что к 2000 году в промышленно развитых странах продолжительность рабочего дня будет составлять всего 4 часа. И, хотя мы прошли долгий путь от длинного 12-14-часового рабочего дня в первой половинк XIX века, мы всё ещё даже не приблизились к этому прогнозу.

Более того, мне кажется, что большинство людей чувствуют себя так, будто они работают больше, чем когда-либо.

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

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

В этой статье на примере опыта компании Planio рассмотрим преимущества и особенности перехода на четырёхдневную рабочую неделю.

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

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

В какой-то момент дел становится так много, что невозможно все держать в голове, поэтому мы ищем помощь извне. Тут нас выручают инструменты для оптимизации времени.

Хотим поделиться с вами парочкой таск-трекеров, который помогут облегчить вам жизнь!

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 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, возрастает и комбинаторика кейсов в использовании продукта. 

Сейчас в моде слово «клиентоцентричность», которое заменило привычное мне, бумеру, «клиентоориентированность». И для меня это выглядит так: если раньше важно было делать свой продукт или сервис, ориентируясь на клиента, то сейчас надо просто пойти и сделать, как тебе приказали. И неважно, что ты думаешь, ты же должен быть клиентоцентричным. Для гос. проектов это весьма актуально, кто работал, тот знает.

Однако есть один маленький нюанс: Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять? Вот об этом и предлагаю поговорить.

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

Чаще всего инженерное проектирование связывают инженерное механическое проектирование с инструментом, станками, кораблями, ракетами, роботами и машинами. Тем не менее, его применение выходит далеко за рамки этих привычных примеров. Инженерные принципы активно задействованы в множестве неординарных областей, начиная от создания музыкальных инструментов и заканчивая дизайном одежды. Рассмотрим несколько занимательных случаев.

Привет, Хабр! На связи Дмитрий Секачев — корпоративный архитектор службы развития ИТ-архитектуры ВТБ. Я занимаюсь корпоративной архитектурой в дочерних компаниях банка. Сегодня расскажу вам про новый архитектурный продукт — «Референтная прикладная архитектура как АрхПродукт» (РПА как АрхПродукт).

Мы с коллегами готовим серию статей, в рамках которых вы узнаете, как применять данный продукт в процессах слияния/поглощения компаний, построения целевой прикладной архитектуры своей организации, как сократить объем «выборочных» процедур по выбору ИТ-решения и многие другие интересные аспекты применения референтной прикладной архитектуры. Поехали!