Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем в Первой грузовой компании. Сегодня разберем с вами, чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста. Статья будет полезна менеджерам, продуктам, руководителям проекта. Всем кому надо объяснять, или кто сам хочет разобраться, в чем отличие бизнес и системных аналитиков. 

Часто всем участникам проекта хочется оптимизировать трудозатраты и бюджет. И очень светлая мысль, которая возникает у каждого второго продукта или РП: “А давайте у нас будет один аналитик, который сделает всё!”. У руководителей более высокого уровня, топов и собственников это идея возникает в 9 случаев из 10. В результате сроки сорваны, бюджет превысили в два раза. Почему так происходит и будет происходить разберем ниже. 

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

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

С отвесной скалой все понятно. Точнее понятно, что ничего не понятно – нужны подготовленные спецы, которые быстро заберутся наверх и при этом не разобьются в лепешку. Поэтому профессионального скалолаза берем в команду 100%. А вот с равниной и озером не все однозначно – ведь плавать и бегать все умеют. Есть большой соблазн взять в команду одного спортсмена, а на сэкономленные деньги и время еще и интерфейс в синий покрасить. Вот так и формируются команды разработки, где есть выделенные разработчики (скалолазы) и аналитики (бизнес и системный анализ в одном флаконе). 

В предыдущей публикации мы с вами рассмотрели основные проблемы бюджетирования.

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

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

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

Есть у нас такая традиция – начальство не любить. А как быть, если начальство – ты сам? Хочется ж быть хорошим, всегда и для всех. Но получается так, увы, редко.

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

1. Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
2. Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
3. Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
4. Сделать систему простой в развертывании и администрировании.

В данной статье мы рассмотрим пример подхода для создания инфраструктуры 1С в зависимости от количества пользователей.

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

Менеджер: Эта задача готова?
Разработчик: Да.
Менеджер: Давайте катить на пользователей?
Разработчик: Давайте.
Менеджер: Что‑то не вижу функциональности на продакшене?
Разработчик: Ну, нам нужно еще пару дней — пройти код‑ревью, подождать, чтобы QA протестировали, собрать и выкатить релиз в прод, сделать несколько миграций данных, и потом мы откроем фичу для пользователей.
Менеджер: Но ты же сказал, что задача готова?
Разработчик: Да.

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

Сумрачная картинка: большое помещение, мало света. Стол и рядом стул, на котором сидит человек. Он работает за ноутбуком. Чувствую его усталость: он сегодня уже долго работает. Его что-то отвлекает: письмо. Электронное письмо. Он нажимает на ссылку, но ничего не появляется на экране. Всё в порядке. Но на сетевом уровне уже поселилось зло: ЧЕРВЬ!!! Спустя неделю червь выкачает данные, из-за чего компания потеряет десятки-сотни миллионов рублей.

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

Эта статья будет полезна и крута всем: узнаете, как помочь своим коллегам узнать больше об информационной безопасности в незанудной форме! На одном из мест работы я смог за пару лет повысить общий уровень знаний сотрудников в 5 раз! Меня зовут Маг Владони Миша, и теперь я занимаюсь Security Awareness в Ozon. Инциденты информационной безопасности, возникающие из-за человеческой ошибки, — самые распространённые (по данным РТ). Для минимизации количества таких инцидентов необходимо повышать осведомлённость в вопросах ИБ, т.е. заниматься Security Awareness.

В статье пойдёт речь о самом базовом управлении устройствами умного дома Яндекс - а именно функции включения/выключения, т.к. ничего больше мне не нужно, но из базы довольно легко с помощью документации, научиться управлять и другими свойствами. Может этот материал не на статью вовсе, но вот захотелось поделиться. За код не ругайте сильно - я не настоящий программист. Код будет на простейшем PHP.

Scrum, Kanban и другие «‎эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.

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

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

19 ноября 1942 года началась операция "Уран": контрнаступление с целью окружения и уничтожения нацистской группировки около Сталинграда.

В итоге операции "Уран" войска стран "Оси" потеряли более 900 тысяч человек, а в Великой Отечественной Войне начался перелом. Перелом, который был бы невозможен, если бы СССР не был в состоянии произвести и поставить на фронт десятки тысяч артиллерийских орудий и миллионы снарядов к ним. Если бы СССР не развернул военную промышленность. Если бы уже для неё не была обеспечена ресурсная и кадровая база. Если бы не запустили в своё время I пятилетку и ГОЭЛРО, Их-то я и собираюсь разобрать в качестве выдающихся примеров стратегического планирования.

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

Первая часть.

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

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

Привет! К определению сущности ИТ-бизнес-партнёра зачастую возникает больше вопросов, чем к названиям большинства других должностей. Для рядового сотрудника порой куда понятнее, чем занимается тот же scrum-мастер или agile-коуч. А вот с ИТ-бизнес-партнёром всё иначе: кто-то думает, что это такой аналог классического продуктолога, который просто чуть более вхож в руководящие круги. Другие считают, что это просто перемычка между бизнесом и чистым ИТ, мол, коммуникации такого рода не автоматизируешь, так что вот, пусть должность будет для живого человека.

В этом посте мы постараемся объяснить, чем же именно занят ИТ-бизнес-партнёр на работе, что входит в его обязанности, какими качествами он должен обладать. И сделаем мы это на живом примере: меня зовут Светлана Евстигнеева, я ИТ-бизнес-партнёр блока розничного бизнеса Московского кредитного банка (МКБ).

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

Начнём разбор с простого экрана загрузки фотографии паспорта.

При развертывании информационных систем на базе 1С до 2022 года многие компании шли проторенной дорожкой. Брали Windows Server, MS SQL, терминальный сервер Citrix/RDS. Запирали с этим всем админа на недельку, и всё готово.

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

— На какой операционной системе сейчас строить информационные системы 1С?

— Какую базу данных взять?

— Какие компоненты выбрать, чтобы не потерять в производительности и надежности?

— Есть ли жизнь без Microsoft?

В этом посте предлагаю рассмотреть все компоненты инфраструктуры информационных систем на базе 1С и выбрать оптимальные решения.

В сети множество материалов по гибким методологиям управления проектами. Моя цель – дать конкретику в подходе, скомбинировав лучшие практики современного проектного менеджмента на основе существующих Agile практик. Секрет состоит в том, что используемые подходы – отлично дополняют друг друга.