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

Неопределенность — одна из главных трудностей, с которой аналитик сталкивается при обработке требований в сфере информационной безопасности (ИБ). Требования часто сформулированы расплывчато и без конкретики. В процессе внедрения программных продуктов имеется классический набор требований из нормативной документации: ИАФ, УПД, ОПС, РСБ и т.д. В части реализации мер по регистрации событий ИБ (РСБ) аналитик внедрения сталкивается с несколькими группами требований:

1. Общие требования задают базовые правила для защиты данных, определяют сроки хранения и перечень источников событий, которые необходимо фиксировать. 

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

3. Состав полей событий безопасности наполнен идентификатором события, датой и временем, результатом выполнения, идентификатором субъекта, объекта или ресурса доступа и другими данными. Чтобы корректно определить состав, важно учитывать потребности инженера ИБ со стороны заказчика. 

4. Мониторинг предусматривает проработку механизмов просмотра и анализа, передачи в SIEM-систему. 

Чем меньше команда продукта, тем ниже риск того, что взгляды на реализацию разойдутся. Дополнительные согласования, как правило, не нужны, ведь все участники понимают цели и задачи одинаково.

Ситуация начинает выходить из‑под контроля, когда задачи становятся сложнее, а команда — больше. Итоговое решение может не соответствовать ожиданиям и не учитывать глобальное видение продукта.

Чтобы этого избежать, аналитики и продакты проводят приемку аналитики. Аналитик, проработав задачу и определив, как ее лучше решить, приносит свое видение продакту еще до начала разработки. В ходе обсуждения они вместе корректируют спорные моменты и приходят к общему решению. Это позволяет объединить разные взгляды и улучшить качество финального результата.

Три важных плюса приемки аналитики:

1. Два взгляда на решение — сокращается количество ошибок, команда на несколько шагов ближе к истине и идеальному решению.

2. Действия согласованы — продакт заранее знает, что именно будет реализовано и может объяснить на этапе тестирования или демонстрации продукта, почему сделано так, а не иначе.

3. Усилия команды объединены — аналитик не остается один на один с задачей и понимает, что совместная работа помогает эффективнее выполнить задачу, улучшить реализацию и повысить удовлетворенность команды и клиентов.

Бесплатно перенесем ваши проекты в Selectel 🔥

Перенесем ваши проекты в Selectel быстро, надежно и бесплатно.

• Возьмем на себя все задачи, включая планирование, логистику, подготовку стоек и прочее.

• Разместим ваши проекты на развитой инфраструктуре в шести собственных дата-центрах уровня Tier III.

• Проведем миграцию с минимальным даунтаймом — в согласованное время ночью и на выходных.

• Доверим проведение работы опытным DevOps-инженерам, архитекторам и менеджерам проектов.

Узнайте, как переезжали в Selectel компании YCLIENTS, «Гардиум» и «Экстремум».

Предпочитаете перейти сразу к делу? Просто оставьте заявку на сайте.

Здравия желаю, товарищи!

Пройдёмся-ка сегодня по гастро-увесилительному бизнесу.

Часть I.

Очень странно смотреть ещё и на представителей этой отрасли, которые считают, что они 20 лет на рынке и этим всё сказано. Товарищи-рестораторы, смена парадигмы уже идёт. Студенты ходят по заведениям, скоро будут зарабатывать и сменят ваших клиентов. Z-ы. А задними и Альфы придут. Так что не выё.

Must have:

1. провести анализ конкурентов.

Количественный:

• выручка;

• доля рынка;

• темпы роста и прироста;

• отзывы;

• количество каналов коммуникации;

• бредовые запросы;

• цены;

• другие показатели;

Отсортировать от большего к меньшему. Построить пузырьковую диаграмму по темпу прироста и доле рынка.

Качественный:

• ведение соцсетей и вовлеченность подписчиков;

• сайт;

• акции, скидки и т.д.;

• экспертность и обучение аудиторий;

• интересные решения (везде, где придумаете);

• отзывы и ответы на них;

• и так далее.

2. нанесите на карту всех своих конкурентов или наиболее сильных и "злых".

3. постройте свою EST-модель.

Всё это вам поможет увидеть свои сильные и слабые стороны, где давать рекламу в том числе наружную и давать ли её вообще. Где открывать точку, чтобы откусывать трафик. Придут другие инсайты.

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

Продолжение следует.

Delivery: между бизнесом и разработкой. Вышел новый Sravni Podcast!

В новом выпуске поговорили про менеджмент в ИТ.

Максим Ачкасов, Lead Delivery мобильной команды Сравни, рассказал о сложностях управления ИТ-проектами, балансе между потребностями бизнеса и возможностями разработки, оценке задач по сторипойнтам и координировании нескольких разных команд. 

В выпуске:

• Кому и зачем стоит идти в delivery-менеджмент?

• Где пересекаются команды продуктов и технологий?

• Как Server-Driven UI помогает делать успешный продукт?

• Можно ли войти в ИТ, если не знаешь, чем бэк отличается от фронта?

Подкаст доступен здесь:

• YouTube

• RUTUBE

• VK

• Яндекс Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах можно в тг-канале Sravni Tech.

После 24.02.2022 понял что зарубежный рынок будет закрыт и начали разработку своей системы управления проектом (open source&free).

Когда то жил не тужил и работал с зарубежными системами, работал, разрабатывал и зарабатывал. А потом бац! И рынок оказался практически закрыт. Недавно мой основной вендор вообще прекратил работу с Россией.

Так что пришлось пилить свое так как на нашем рынке нет решений которые бы мне пришлись бы по вкусу после того как я успел поработать с забугорными решениями.

Я не говорю что у нас все плохо, но как есть как есть.

Так что начали пилить и запилили не только систему управления проектом и поддержкой, но и CRM, MRP, ecommerce и несколько других вещей. Все бесплатное и свободное, написано на Drupal 10. Все как вы любите.

PS: Статью не стал писать так как времени пока что нет.

Не судите строго, делали все от души и долго, но ограниченными силами и без оплаты (система бесплатная).

Так получилось, что я испытываю нежные чувства к настольно-ролевым играм в целом и Dungeons & Dragons в частности. Всегда казалось логичным, что их пытаются применять в работе.

Вот один из победителей прошлого Технотекста @iktash пишет о том, как D&D помогает тимлидить.

У партии в D&D и рабочего проекта действительно много общего:

• и там, и там люди выполняют определённые роли

• часто перед игроками и сотрудниками стоит понятная задача (иногда задачи нет, но тогда они придумывают её сами)

• без командной работы решить задачу очень трудно

Когда в очередной раз думал об этом, стало интересно: что будет, если как есть перетащить некоторые практики ролевых игр в рабочие процессы?

Обсуждать алаймент на ревью — это, конечно, шиза. Но в D&D есть такая штука, как степень успеха — игрок выполнил задачу, но вместе с результатом получил негативный эффект, потому что не проявил достаточного мастерства. Или наоборот — выложился сверх необходимого и результат получился лучше, чем ожидалось.

На следующем ретро попрошу ребят оценить так проект. Кажется, что будет проще выискивать подводные камни:

Эпик закрыт без особых проблем, но в процессе мы затронули старый кусок функциональности, который может стать проблемой в будущем — надо переписать.

Почему разработчики секси, а продакты не нужны

Разраб рассказал, как у него проходят собеседования. Похоже на экзамен в формате беседы с преподом.

Кандидата гоняют по теории, пару задачек просят решить, а если понравитесь друг другу — можно и за жизнь поболтать.

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

Спрашивали, что я сделал.

Вот почему популярно мнение, что продакты не нужны. Следите за руками:

• разраб и продакт вместе пилят 10 проектов

• в среднем выстреливает 1 проект из 10

• на выходе у разраба опыт реализации 10 (!) проектов, а у продакта 1 успешный проект

Прошаренные наниматели спрашивают и про неудачи. Но только если успехи в наличии 🙂

Получается, что продакты становятся крутыми в 10 раз медленнее, чем разрабы. А вероятность встретить бесполезного продакта выше, чем бесполезного разраба (джунов в расчёт не берём).

Вебинар: «Новое проектное управление — полная замена MS Project»

Кто проводит: Максим Тимонов, дизайн-директор. Отвечает за развитие BPM-системы «Первая Форма».

Кому полезно: руководителям IT‑отделов, руководителям проектов, финансовым и операционным директорам, бизнес‑аналитикам.

Почему это важно:

MS Project, Wrike и ClickUp больше не доступны в России. Большая часть отечественных решений не позволяет реализовать привычные сценарии работы над проектами. Например:

• инлайн создание задач;

• управление сроками, порядком исполнения, группировкой задач на графическом визивиге Ганта; 

• автопланирование задач со связями и условиями; 

• управление овербукингом;

• утверждение планов и подписание;

• сохранение базовых планов и создание версий.

«Первая Форма» обновила проектное управление, чтобы соответствовать запросу заказчиков на полную замену Microsoft Project. Решение позволяет планировать и выполнять проектные задачи в единой цифровой среде. 

Что узнают участники:

• как реализовать планирование и исполнение проекта в одной системе;

• какие функции проектного управления можно автоматизировать;

• как можно вписать проектное управление в сквозные бизнес-процессы компании. 

Подробнее о программе ➡️

Как попасть:

Участие бесплатное, по предварительной регистрации. Вебинар состоится 1 октября в 11:00.

Спросить пользователя недостаточно

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

Результаты опросов ненадёжны. Принимать решения только по ним — это лотерея.

Выборка может не соответствовать аудитории. Даже если участников много — по какой-то причине core-аудитория может игнорировать опросы, а заранее узнать об этом нельзя.

Опрошенные могут не знать, чего они хотят. Никто не хотел айфон, пока Apple не показали айфон (простите).

Может проявиться эффект Брэдли. Иногда люди выбирают вариант, который выставляет их в выгодном свете.

В 1982 году на выборах губернатора Калифорнии по опросам с огромным отрывом лидировал чернокожий кандидат Том Брэдли. Он уже готовился войти в должность, но после реального голосования его обошёл белый оппонент.

Оказалось, что в опросах некоторые избиратели врали, чтобы их не посчитали расистами.

Отчасти с эффектом Брэдли помогает бороться тайное голосование. Но и анонимно человек может выбирать варианты с позитивной окраской.

Yonote не справляется с нагрузкой

Недавно мы, как и многие, начали переходить с Notion, не торопились, потому что объём информации невелик, в основном, задачи. Импорт небольшого архива был в очереди двое суток. В техподдержке сказали, что нагрузка большая, импорт может быть до 3 суток. Что ж, трое суток тоже к результату не привели, импорт архива на 25 МБ так и не прошёл...

За вчерашний день заполнили сами почти всё заново, оставили неперенесёнными лишь несрочные задачи и уже готовые, документы тоже пока не стали заливать. И вот сегодня yonote с утра: Не удалось загрузить конфигурацию.

Кое-кто оказался не готов. А вот Notion ещё работает. Пока ушли на Affine.

А как у вас?

Причины выгорания. Опрос.

Не так давно, я опубликовал статью-мнение с обзором причин выгорания и мер которые превентивно не дадут команде проволиться туда.

Статья была встречена довольно холодно, что заставило меня доработать её.

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

Что по вашему мнению является причиной выгорания?

1. Атмосфера в коллективе

2. Не компетентный менеджмент

3. Work-Life balance

4. Методология и/или процессы

5. Легаси решение и/или инструменты

6. Отсутствие возможности профессионального роста

7. Оклад

8. Другое

Допускается выбор нескольких вариантов. Расскажите о них в порядке важности для вас.

Большое спасибо!

Notion уходит из РФ, удаляя все мои данные 9 сентября.

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

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

Notion сказал, что 9 сентября просто удалит под чистую все данные без возможности восстановления. Невероятно удобно и надежно и вызывает огромное доверие! Как у них на баннере написано "Write. Plan. Organize." и забыли добавить "... and we'll destroy it".

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

Теперь это все время стоит иметь в виду и не воспринимать "Облачный сервис" как что-то надежно. Удобное — да, а вот надежное оно лишь пока я для него буду оставаться удобным в ответ.

“Практическое руководство ИТ лидера” Раду Спатару - коротко о книге.

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

О книге:

Достоинства:
🟢Книга кратко (193 стр.) рассказывает о комплексе задач и процессов, с которыми может столкнуться IT-менеджер/лидер/директор/руководитель, от знакомства с текущим ИТ-ландшафтом в организации и до управления проектами и использования AI.
🟢Большое количество “примеров из жизни”
🟢 Много чек-листов и других инструментов самопроверки.

Недостатки:
🚫 Минималистичный объем для такого предмета - это “галопом по Европам”. Увы, ни одна из тем не получает нужного освещения, и получается “карманный справочник”, к которому вряд ли захочется вернуться. Весь текст выглядит как реферат, набор общеизвестных принципов, собранных в одном месте.
🚫 Ужасный перевод, в худших традициях “промпта”: множество опечаток и ошибок, корявый синтаксис, суконный язык.
🚫 Часть терминов, диаграмм и таблиц осталась без перевода с английского.

В целом, не рекомендую эту книгу никому - разве что вы захотите найти негативный ("как-не-надо") пример профессиональной литературы. Если тема “ИТ-менеджмента” вам интересна, лучше почитайте “Карьера Software Engineering Manager”.

Подробнее - в канале "Проектный дайджест".

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

📅 Дата: 22.08.2024

⏰ Время: 15:00-16:00 (Мск)

На вебинаре:

✔️ Постановка задачи и ее проблемы.

✔️ Что такое BPMN.

✔️ Уровни моделирования.

✔️ Сущности BPMN.

✔️ Основные концепции моделирования процессов.

✔️ Рекомендации по разработке диаграмм.

👨‍🎓 Спикер: Бирюков Андрей более 15 лет работает в области информационной безопасности и информационных технологий.

🔥 Зарегистрироваться 🔥

Приглашаем на новый бесплатный вебинар «Качество требований к ПО: как понять что требование плохое не на основании ощущений». Разберем проблемы, которые могут возникать из-за плохой проработки требований и их некачественного описания на примере реальных проектов. Узнаем, как можно комплексно оценить большое количество требований и оценить, насколько хорошо поработали аналитики.

📅 Дата: 20.08.2024

⏰ Время: 16:00-18:00 (Мск)

На вебинаре:

✔️ Критерии качества требований.

✔️ Последствия плохой проработки качества.

✔️ Пример комплексной оценки качества требований на крупном проекте.

👨‍🎓 Спикер: Политыко Сергей — архитектор информационных систем в IBS.

👉 Зарегистрироваться 👈

Про количественные и качественные показатели сотрудников

Замер и контроль личных количественных показателей превращает управление персоналом в подобие RPG-игры, где мы прокачиваем персонажа. Руководитель видит «характеристики» каждого сотрудника, и это помогает ему принимать верные стратегические решения. Вот основные плюсы такого подхода:

• легко контролировать эффективность каждого сотрудника и принимать кадровые решения на основе данных;

• каждый сотрудник, зная свои целевые KPI, стремится к хорошему финансовому результату;

• иерархическая система самоуправляема. Топ-менеджменту не обязательно контролировать каждого сотрудника. Достаточно следить за показателями на уровне ниже, например, у руководителей департаментов. Те в свою очередь видят, кто из их специалистов справляется хорошо, а кто наоборот — обуза.

Кажется, это универсальное решение всех проблем. Но в реальности без качественных метрик не обойтись. Примеры:

1. Сильный тимлид плохо перформит. По цифрам его надо уволить, но если копнем глубже, то выясним, что его подвела провальная менеджерская команда или непобедимое легаси.

2. Слаженная команда показывает хорошие Throughput и Lead time. Через полгода выясняется, что они хакнули систему и накрутили красивые метрики, не поставляя бизнес-ценности.

Замер количественных метрик дает стратегическое видение. Но их недостаточно для принятия конкретных тактических мер на местах, поэтому нужно добавлять и качественные метрики сотрудников.

Больше об управлении IT-командами рассказываем здесь.

«Теория болтовни»: результаты исследования о том, кого выбирают лидером в малых группах

В исследовании, проведенном сотрудниками нескольких американских университетов, собрали 33 группы численностью от четырех до десяти человек в каждой. В качестве командного задания нужно было выполнить миссию в военной компьютерной игре (BCT Commander) или в деловой (CleanStart).

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

Исследователи дважды опрашивали участников: первый раз — после обсуждения и второй — после самой игры. Они просили назвать от одного до пяти человек, которые подошли бы на роль лидера.

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

Главным фактором выбора на позицию лидера стало то, как долго участник говорил.

Спасибо, что прочитали. Если решите поставить минус, то напишите в комментарии, что нужно улучшить. Я стараюсь писать много и интересно. Анонсы выкладываю в тг-канале.

Легенда инфобеза Мокси Марлинспайк обвинил Agile в торможении инноваций в области программного обеспечения. По его словам, «магия» разработки ПО была утрачена за 20 лет из-за того, что разработчиков запихнули в «чёрные ящики абстракций», и это лишило их свободы, необходимой для инноваций.

«У любого, кто управляет инженерной организацией, будет некая философия управления, которая в некотором роде является нижестоящей или производной и как-то связана с гибкой методологией», — сказал Марлинспайк. Он считает, что гибкие команды в конечном итоге оказываются изолированными.

С ним согласился и генеральный директор Thistle Technologies Виндоус Снайдер.

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

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

«Безопасность — это процесс изучения абстракций, чтобы на самом деле понять, как всё работает, что за этим стоит, и иногда понимать процессы лучше, чем те, которые кто их создали», — утверждает он.

«Работники кибербезопасности — это те, кто сидели в библиотеке, изучали заклинания, на самом деле понимали, как все это работает… как в мире Гарри Поттера. Единственное, что нужно, чтобы использовать эти знания, — это компьютер. И он даже не обязательно должен быть хорошим», — заключил Марлинспайк.

Мне было 14, когда в 2007 году вышел первый Assassin's Creed. Для обработки толп NPC на улицах нужен был нормальный комп, поэтому я смог оценить игру только у друга (позже закрыл гештальт и таки выбил платины во всех классических частях).

Само кредо легко западало в душу школьнику: ничто не истинно, всё дозволено. Фразу толковали по-разному.

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

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

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

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

Мысль позитивная, иногда продакту не грех воспользоваться чуйкой. Но покажи это неопытному продакту или CEO и он тут же найдёт оправдание очередному неподготовленному запуску. Его не смутит, что официальной религией в его компании является lean, который вполне себе metric-based.

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