Рубрика «управление проектами» - 109

Как оценить длительность IT-проекта, а когда это вообще не стоит делать - 1

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

Селеста чувствовала давление. Её менеджер Барри хотел составить квартальный прогноз работы её команды. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём. Каждый из них являлся частью другого проекта.

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

Селеста решила признаться Барри и посмотреть, к чему они придут. Она назначила встречу на следующий день и собрала данные.
Читать полностью »

Если верить экспертам, то в ближайшее время прогнозируется укрупнение рынка операторов связи. Но, как показывает история, стоит верить только базовым оценкам ситуации экспертами, а не их прогнозам, ибо эти прогнозы сбываются в лучшем случае в 30% случаев. Особенно в сфере рынка и экономики.

Рассуждения о перспективах в Телекоме - 1

Читать полностью »

Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций по докладам о технической стороне стриминга. Но сегодня пред вами расшифровка доклада Евгения на TeamLead Conf о том, как отражается Agile-трансформация на лидерах команд.

Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода - 1

Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:

  • бизнеса,
  • скорости разработки,
  • time to market;
  • других интересных метрик.

Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.

Читать полностью »

Страх и ненависть Threat Intelligence или 8 практических советов по работе с TI - 1

У нас было две коммерческих APT-подписки, десять информационных обменов, около десяти бесплатных фидов и список exit-node Тора. А еще пяток сильных реверсеров, мастер powershell-скриптов, loki-scanner и платная подписка на virustotal. Не то чтобы без этого центр мониторинга не работает, но если уж привык ловить сложные атаки, то приходится идти в этом увлечении до конца. Больше всего нас волновала потенциальная автоматизация проверки на индикаторы компрометации. Нет ничего более безнравственного, чем искусственный интеллект, заменяющий человека в работе, где надо думать. Но мы понимали, что с ростом количества заказчиков мы рано или поздно в это окунемся.
Читать полностью »

Дополнение (2 июля 2018 г): сотрудники поддержки Google Cloud Platform (GCP) заверили, что такое больше не повторится. Их слова: «Многие люди (в рамках GCP) заинтересованы в том, чтобы улучшить ситуацию не только для вас, но для всех клиентов».

Примечание: это пост не о качестве облачных сервисов Google. Они превосходны, наравне с AWS. Речь идёт о «резких движениях без предупреждения», когда они полностью отключают все ваши системы, если сотрудники (или машины) вдруг решили: что-то не так. C нами это случилось второй раз.

Предыстория

Наш проект в продакшне использует GCP для мониторинга сотен ветроэнергетических установок (ВЭУ) и десятков солнечных электростанций, разбросанных по восьми странам. У нас центры управления с экранами на всю стену: там приборные панели, набитые метриками, за которыми следят круглосуточно. Менеджеры объектов используют эту систему для контроля в реальном времени состояния отдельных ВЭУ и солнечных установок. Если требуется вмешательство, оно производится немедленно. Команды разработки и прогнозирования используют систему для отработки алгоритмов на данных в BigQuery. Все действия непосредственно транслируются в нашу прибыль. Мы имеем дело с ветровой/солнечной энергией — скоропортящимся товаром. Если мы генерируем излишек, то не можем сохранить его и продать позже. Если генерируем недостаточно, то платим штрафы. По этой причине объекты нужно отслеживать 24/7, чтобы не выходить за рамки потребностей энергосистемы и заключенных соглашений о покупке электроэнергии.
Читать полностью »

«Что за бред? Разве бывают менеджеры по счастью?» – спросит пессимист, прочитав название статьи. «А ведь идея вполне реальная! В ОАЭ давно настоящий министр счастья работает!» – парирует оптимист.

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

Вопросами оптимизации бизнес-процессов с применением сервисного подхода я активно занимаюсь последние 10 лет. И мне всегда интересно общаться с коллегами на эту тему.

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

Читать полностью »

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

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

На основе этого плана мы ставим задачи разработчикам и «аудиторам» — коллегам из других отделов, которые проводят ревью решения. (Да, это тоже лайфхак). Надеемся, эта шпаргалка пригодится для подготовки к релизу продукта в прод.

Рецепт гладкого релиза: PMy на заметку - 1
Читать полностью »

Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Definition of Ready — то, о чем нам забыли рассказать - 1

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

Читать полностью »

Всем привет. Я работаю в московском офисе Технологического Центра Дойче Банка. Для тех, кто не знает, — мы занимаемся разработкой приложений для CIB (Corporate and Investment Banking) бизнеса в Нью-Йорке, Лондоне, Франкфурте, Токио, Сингапуре, Чикаго, Сиднее. В России в Техцентре работают более 1000 человек — это примерно 130 команд. Всего в мире таких центров у Дойче Банка четыре: в России (Москва и Санкт-Петербург), США, Румынии и Индии.

Офис под Agile: где разместить тысячу разработчиков? - 1

Примерно полтора года назад стало понятно, что мы перестали помещаться в наш офис и нам надо искать себе новый дом.
Читать полностью »

Вступление

Одна из основных проблем, с которой сталкивается большинство технических специалистов — это общение с заказчиком. Причем эта проблема стоит настолько остро, что была придумана специальная профессия «Системный аналитик», т.е. по сути человек, который выступает некой прослойкой или переводчиком между обеими сторонами. И все бы было ничего, но большинство системных аналитиков выходят из той же технической среды, потому что им необходимо знать мат часть. Вот для них, по большей части, и написана эта статья.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js