"Не вредные советы для РП". Как подготовиться к встрече с Волан-де-Мортом и защититься от Дементоров в проекте. Часть 1.
Это анти-статья для тех, кто сталкивался с "граблями" и двойными стандартами в управлении проектов и для тех, кто хочет об этом узнать. Получить подсказки как застраховаться от "скрытых граблей" и ловушках в темном лесу Волан-де-Морта до того, как войти в него, а также подготовиться к схватке с проектными Дементорами и суметь себя защитить.
Большое количество статей посвящено обеспечению безопасного доступа к информационным ресурсам посредством различного оборудования и ПО. Однако, без грамотного построения физической безопасности на предприятии сложно говорить об эффективном обеспечении информационной безопасности, ведь если посторонний может пройти в серверную, то он без проблем может подключить какое-то свое устройство, выдернуть диск из “зеркала” или что похуже. По сути, физическая безопасность и контроль физического доступа - это основа любой системы защиты в организациях и в этой статье мы поговорим о том, как все это лучше организовать.
Контроль физического доступа основан на совокупности организационных и технических мер. Недостаточно просто установить оборудование, настроить камеры и раздать карточки. Важно выстроить процесс управления доступом. Этот процесс должен быть разделен на различные задачи, решаемые соответствующими подразделениями.
Привет, Хабр!
On-premise, private cloud, и public cloud — это три основные модели развертывания IT-инфраструктуры, каждая из которых предлагает различные уровни контроля, управления и масштабируемости.
Выбор между этими моделями часто ставит в тупик. Как выбрать подходящую платформу? Сегодня мы рассмотрим все плюсы и минусы этих трех подходов.
Качество программного обеспечения (ПО) напрямую зависит от многих факторов: от требований и спецификаций, проектирования и архитектуры, процессов разработки и тестирования ПО. Естественно, в процессе тестирования часто возникают проблемы и «узкие горлышки», которые могут существенно затруднить успешное завершение проекта.
Специалист по тестированию “Лаборатории качества” Александр Черняков написал об основных проблемах, с которыми сталкиваются команды специалистов по тестированию, и рассмотрел возможные пути их решения. Все актуально.
Code review решает такие проблемы частично, всегда присутствует человеческий фактор, и раз за разом подобные проблемы проходят через проверки. Но решение есть — это концепция Code Ownership, которую мы применили в нашем проекте.
Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.
В этой статье я поделюсь алгоритмом, который я использовала в собственной практике, как тимлиду выбраться из рутины и сделать команду автономной.
Про сбор требований написано очень много, но в этой статье я хочу сосредоточиться на нескольких важных аспектах проведения встречи по сбору требований. Есть несколько моментов, которые не являются первостепенными, но которые существенно повышают успех встречи.
От устройств IoT до облачной инфраструктуры, от веб-приложений и межсетевых экранов до VPN-шлюзов: количество принадлежащих компаниям активов, подключенных к Интернету, увеличивается в геометрической прогрессии. Они обеспечивают доступ к данным, датчикам, серверам, интернет-магазинам, веб-сайтам и другим приложениям. Но с каждым дополнительным активом поверхность внешних атак растёт, а вместе с ней и риск успешных вторжений.
Судьба забрасывала ездовых котов не только на севера и отправляла на край света за приключениями, но бывало подбрасывала возможность погреться под южным солнышком, заниматься пусконаладкой очередной системы контроля доступа или установкой охраны периметра на важных и не очень объектах нашей необъятной родины.
Как и в любом деле, все что зависит от людей, в конечном счете, в них же и упирается и если вы каким-то чудным образом вы вдруг не поладили с парой трудяг-смежников, ну максимум что будет - это "неприятности" в виде завареной двери в подсобку или забетонированных штанов у всей группы, а вот все сверх может получить развитие в виде докладных и чревато вылетом с проекта всей команды шутников. Другое дело если не подружились с начальником участка или принимающей стороной, что грозит совсем уж интересными приколами и приключениями, а почему у вас изолента зеленая на стыках, когда мне нравится синяя, или поменяйте муфты на герметик в обжиме - а мы так привыкли, и приходилось менять, потому что люди важнее любых железок.
Привет, Хабр!
Как Frontend-разработчик, я в одной из своих прошлых работ столкнулся с проблемой неэффективной постановки задач в моей команде. Это привело к потере времени, недопониманию и снижению качества работы. Например, однажды мы потратили целую неделю на разработку функциональности, которая в итоге оказалась не той, что ожидал заказчик из-за неполного описания требований. В другой раз из-за отсутствия четких критериев приемки мы трижды возвращались к доработке уже "готовой" задачи.
В этой статье я поделюсь результатами своего исследования и практическими рекомендациями по улучшению процесса постановки и ведения задач, которые мы теперь применяем в работе.
Шаблоны и примеры задач будут в конце статьи.
Как разработать регламент?
Почему они часто не работают и не используются?
Какая должна быть структура регламента?
Кто их должен писать?
Об этом я расскажу в данной статье.
Начнем с того, что тема команды в целом, довольно сложный и многогранный вопрос, Который требует развития разных граней человека каждого члена команды, и в особенности, её лидера. От Эмоционального интеллекта и эмпатичности, до самокритики и самообладания.
Но современная культура корпоративного обучения и управления начала использовать это явление (команды), исключительно для манипуляций людьми.
«Мы же команда» заявляет ктоугодновышестоящий с целью вовлечь вас в решение задач компании, без уточнения, а нужно ли вам это, вообще. Особенно если задачи и начинания, о которых говорят, выходят за рамки должностных обязанностей.
Так вот ответственно заявляю, – нифига мы не команда, пока мы её не построили. Кто этим должен заниматься, и как? Этим должен заниматься руководитель, он же, по совместительству, лидер команды. Как конкретно этим заниматься, это тема для отдельной статьи, сегодня расскажем некоторые инструменты которые можно использовать и внедрять в рабочие процессы и правила команды, чтобы начать повышать эффективность коммуникации, и очерчивать границы командной работы.
Думаю, наверняка многие задумывались, зачем музыкантам, которые знают свои ноты, которые знают, что и как играть, нужен человек, который машет палочкой? Давайте я коротко расскажу, какие функции выполняет дирижёр, а вы попробуете догадаться, какую аналогию я приведу в конце.
Дирижёр в оркестре выполняет сразу несколько важных функций. Первая — руководство темпом и метром. Чтобы все музыканты вместе вступили, чтобы все играли в одном темпе и не расходились. Вторая - дирижёр показывает музыкантам время их вступления (например, после долгой паузы). Третья - дирижёр сообщает музыкантам динамику и громкость игры. Четвёртая - дирижёр отвечает за построение общей формы произведения. Одна и та же композиция у разных дирижёров может звучать по-разному.
Фактически дирижёр отвечает за всё происходящее. Он вдохновляет музыкантов на эмоционально заряженное исполнение, помогает им почувствовать себя единым целым. Он — лидер, он — объединяющий интеллектуальный и эмоциональный центр.
Догадались с кем я хочу сравнить дирижёра в корпоративном мире? Конечно же с руководителем проектов.
Руководитель проектов, так же, как и дирижёр, сам не играет на инструментах. Результатом работы РП не является написанный код или разработанная документация. Однако, он как раз и отвечает за то, чтобы этот код появился в нужный момент, чтобы он соответствовал согласованной документации, чтобы аналитик вовремя сделал то, что он умеет, а разработчик не сидел без работы и так далее. Точно также, как и дирижёр, РП является лидером своей команды. Он тот, кто объединяет коллектив, поддерживает их эмоциональное состояние, мотивирует в трудные моменты.
Всем привет! Этой статьёй я открываю серию постов из моего личного опыта, которого у меня больше 25 лет, из которых 20 — в управлении проектами.
Я заметил, что в моей ежедневной работе, работе моих менеджеров, постоянно происходят ситуации, которым очень мало обучают на тренингах, но которые в жизни любого РП случаются регулярно. И я начал их записывать, чтобы потом делиться с новичками в проектном управлении.
Что делать, если сроки срываются, а вы не виноваты? Что делать, если заказчик требует невозможного, а сказать «нет» нельзя? Что делать, если вы чувствуете, что вы везде крайний, а никаких инструментов повлиять на ситуацию у вас нет? Ничего этого нет в PMBoK или Agile Manifest. Как сделать действительно качественный продукт, как принести прибыль компании, а себе заработать денег, вас не научат на курсах владения MS Project. Но вам может помочь опыт других РП, которые уже прошли то все сами и понимают, почем фунт лиха.
Так что надо делиться.
Ну и терапевтический эффект тоже важен: как известно, со своими проблемами лучше не оставаться наедине, думая, что именно ты какой‑то не такой, ужасный неудачник, а кругом одни удачники. Это не так, лажают все, просто рассказывают не все (особенно в сети).
Я расскажу 😊
Обычно мы обрабатываем до 1500 обращений в день. Это в среднем 90 заявок на человека. А когда вводят новые правила маркировки или ломается оборудование у провайдера нагрузка вырастает в 3-5 раз.
Материал подготовлен по мотивам интервью с Юлией Харитоновой, руководителем службы поддержки МоегоСклада.
Меня зовут Северов Михаил, и уже третий год я занимаюсь электронным документооборотом (ЭДО) в федеральной торговой сети «Лента». Сегодня я расскажу, как внедрение машиночитаемых доверенностей (МЧД) оказалось для нас шагом к импортозамещению в ЭДО и заодно помогло оптимизировать процессы управления разрозненным документооборотом.
Об импортозамещении все начали задумываться задолго до известных событий. Санкции, блокировка лицензий и отключение компаний РФ от известных западных сервисов вогнали последний гвоздь туда, где «лежал вопрос» - идти в эту историю или нет.
Но заявлять и делать – это разные вещи. Мало компаний готовы выложить миллионы просто потому, что надо пересаживаться со «старой и проверенной годами иномарки» на новенькую «Ладу».
Препятствия на уровне компаний и проектов, «мешающие танцевать» в импортозамещение:
Этот пост набрал на Medium 99 000+ лайков. Публикуем на Habr его перевод.
Несколько месяцев назад мой друг Тим устроился на новую работу по продажам в стартап на стадии С, который привлек более 60 миллионов долларов от инвесторов. Он один из лучших продавцов, которых я знаю, но вскоре после начала работы он прислал мне письмо, в котором сообщил, что у него есть трудности с продажами.
В моей базе знаний 4 000 заметок.
Да, у меня немного съехала крыша на этой теме. Но решение создать систему для ведения заметок три года назад — пока что лучшая из моих интеллектуальных инвестиций. В этом посте хочу поделиться, зачем я это делаю, в каком формате и какие полезные практические кейсы для себя нашел. Тема бездонная, на самом деле. Можете взять часть идей и развить у себя.
Привет! Эта статья о том, как правильно входить в хату, проходить онбординг на новом месте работы. Этот гайд будет полезен как тем, кто нашел первую работу, так и тем, кто уже работает, но испытывает стресс перед сменой работы.
Всем привет. Меня зовут Сергей Фегон. Я ex-CТО, сейчас работаю руководителем нескольких групп разработки финтех-продуктов экосистемы компаний ВБЦ и TenChat, а также преподаю в OTUS. Делюсь своими знаниями на курсах CTO/Технический директор и Team Lead в OTUS. За время преподавательской деятельности и на основе личного управленческого опыта, я сформировал для себя несколько основных столпов подготовки IT-менеджеров:
