Работа с требованиями в Agile

Публикация № 1664592 24.05.22

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

Agile

Партнер и Agile Coach в компании ScrumTrek Иван Селеверстов на митапе «Сбор требований и составление ТЗ» рассказал об особенностях работы с требованиями в Agile и о том, какие инструменты помогают разруливать зависимости между задачами и не отступать от гибких подходов.

Расскажу о работе с требованиями в Agile, про то, в каких сферах заказной разработки это применимо, посмотрим, как можно визуализировать требования в Agile.

Отмечу, что применение классического подхода в проектах никуда не делось: со стадии «из нуля в единицу», когда нам нужно построить мост «из ничего» – сделать это по Agile нельзя. Но, работая с клиентом со следующих стадий: с «единицы» до «двойки», «тройки», «четверки» и каждого следующего релиза – там уже возможно применять гибкие подходы, связанные с обратной связью от пользователей.

 

Инструменты и принципы управления требованиями в гибких подходах

 

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

 

 

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

Требования – это всегда контрактование с кем-то: или команды с заказчиком, или внутреннее контрактование аналитики с разработкой.

Но чем больше деталей и нюансов описано в вашем ТЗ, тем больше костылей в своем продукте вы будете делать.

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

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

При этом контрактирование с заказчиком никуда не девается, но в Agile-команде мы с заказчиком фиксируем общие требования и затем, работая итеративно, пытаемся уточнять требования по мере их возникновения.

 

Перечислю принципы работы с требованиями в Agile.

Коммуникация лицом к лицу – самый важный принцип. Это важно при взаимодействии как внутри команды, так и с заказчиком. Если заказчик не идет на контакт и не дает обратную связь – Agile-подход разваливается. Мы должны постоянно общаться с разработчиками и потребителями, чтобы непрерывно улучшать и модифицировать продукт. Если у вас коммуникация не выстроена, заказчик просто выслал ТЗ и на контакт не идет то классический инструментарий более эффективен – фиксируем требования, реализуем их, забираем деньги и разбегаемся.

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

Заблуждение – думать, что Agile не про фиксацию требований. Мы фиксируем требования, но мы их фиксируем не на старте, а при выпуске релиза. Мы должны зафиксировать отражение требований в результате работ в виде инструкций, архитектурных и аналитических схем. Это снижает риски на случай, если ушла команда или ключевой эксперт. Agile фиксирует требования, но меняет порядок фиксации – требования фиксируются не в самом начале, а в конце каждого кусочка. При этом на каждой итерации производится обновление существующей документации, иначе в какой-то момент окажется, что она не соответствует тому, как работает продукт.

В команде появляется человек от бизнеса, который дает нам бизнес-контекст, говорит о том, что мы хотим получить, на какого пользователя мы ориентируемся. Если бизнес не знает бизнес-контекст – это странно, но такое тоже бывает, особенно если мы работаем с b2g (business-to-government).

Чтобы этот этап появления зависимостей прошел успешно, в Agile есть принцип планирования «набегающей волной» – он хорошо работает, когда в работе над продуктом задействовано много подразделений.

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

Мы обрисовываем картину, делаем высокоуровневое планирование, фиксируем фичи и зависимости между ними. И дальше крупноблочно раскидываем, что сможем сделать внутри команды за квартал.

 

 

Визуализировать зависимости между командами помогает «доска зависимостей». С помощью этой доски удобно разбираться с зависимостями и блокерами в Agile-проектах.

Если хотите познакомиться с этим инструментом подробнее, концепция принципа планирования «набегающей волной» очень хорошо описана в методологии Scaled Agile Framework (или SAFe).

 

 

Рассмотрим, как визуализируются требования в Agile.

Есть совсем высокоуровневые требования от бизнеса – эпики. Мы общаемся на уровне бизнеса только этими понятиями. Мы не знаем, что он хочет. Он не понимает, что в его системе происходит, поэтому, условно, он говорит: «Я хочу, чтобы у меня ничего не болело». А потом эта просьба разбивается на детали: фичи и истории. Это – классическая схема, которую вы наверняка видели в имплементации инструментов Jira, Team Foundation Server и т.д.

Эпики, фичи и истории – это то, над чем работает Agile-команда вне зависимости от того, как она организована (работает по Scrum, Kanban или как-то по-другому).

Но здесь есть разделение:

  • Epic – это работа с бизнесом.

  • Feature – детализация и сбор обратной связи от бизнеса по конкретному кусочку (обычно, за период квартал).

  • Story – работа с командами внутри спринтов, обычно не более двух недель. Это короткое описание небольшого компонента и желаемой функциональности понятным пользователю языком. Даже по Story мы собираем обратную связь с заказчика.

 

Формируем высокоуровневые требования

 

Если вы будете детально расписывать требования заказчика текстом – команды это читать не будут и после двух-трех страниц текста начнут разработку.

Заказчик тоже не любит читать большие требования – он попросит: «Лучше покажите мне на картинке, как это будет, а детали мне не важны – я вам доверяю».

Для наглядного формулирования требований от заказчиков есть специальные инструменты, например Impact Mapping.

 

 

В начале построения Impact Mapping мы формируем цель – зачем нам нужен проект или продукт?

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

 

 

Смотрим, как стейкхолдеры и антистейкхолдеры будут влиять на создание нашего продукта;

 

 

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

 

Формируем Story

 

 

После того, как мы вместе с заказчиком обрисовали «вид сверху» о том, как это все работает, мы спускаемся вниз, на уровень декомпозиции – формируем истории (Story) для команды.

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

 

 

Самый простой инструмент – User story mapping, где мы идем от пользователя.

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

В качестве примера возьмем публикацию сториз в Инстаграм: пользователю нужно войти в профиль, создать историю, загрузить фото и так далее.

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

Дальше говорим о том, как поддержать историю технически – по каждому действию расписываем детали технической реализации, как мы достигнем эту ценность.. Например, вход мы можем организовать с помощью OpenID, логина Facebook, Twitter и т.д. Расписываем каждый такой вариант и приоритезируем.

Первый подход к декомпозиции от бизнеса к конкретным историям – что мы будем делать на короткой итерации. У нас есть:

  • цель пользователя;

  • задачи пользователя – «хребет»;

  • MVP – «ходячий скелет», минимальные потребности, которые мы закрываем и по которым можем собрать обратную связь, нам нужно убедиться, что этот «скелет» начал «ходить».

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

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

 

 

Вот так это выглядит в жизни:

  • есть пользователь;

  • есть его потребности;

  • по каждой потребности команда детально расписывает требования.

 

 

Команда собирается вместе и клеит стикеры на доску. С приходом онлайн-инструментов сделать это можно удаленно: например, с помощью Miro или Mural, где мы можем очень быстро командой раскидать эти блоки.

 

Классический подход работы с требованиями – работаем через документы:

  • согласуем с заказчиком бизнес-концепцию,

  • бизнес-аналитик с системным аналитиком собирает бизнес-требования и системные требования.

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

 

 

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

  • для кого этого нужно;

  • что конкретно нужно;

  • зачем это нужно.

 

 

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

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

 

В работе с маленькими описаниями есть три составляющих: Card, Conversation и Confirmation.

  • сначала мы описываем концепцию – Card;

  • Обсуждаем ее – Conversation;

  • Описываем детали – Confirmation.

Эта модель называется 3Cs, когда мы от обсуждений плавно переходим к реализации.

На слайде показан пример:

  • менеджер парковки хочет получать уведомления;

  • детализируем, как он хочет получать уведомления;

  • а затем описываем критерии приемки.

 

Как выглядит концепция коммуникации? Как выглядит Story?

Если вы зайдете в любой инструмент контроля требований, например, в Jira, вы увидите, что у каждой задачи есть обязательные атрибуты:

  • название – без него непонятно, о чем эта задача;

  • шаблон контекста – можно задавать контекст в формате User Story или Job Story, мы это сейчас тоже сегодня разберем;

  • критерии приемки – на слайде они описаны в виде Gherkin (Given/When/Then);

  • приоритет;

  • оценка.

Разберемся, как формировать контент, какие есть типы формирования контента

 

Есть два известных шаблона Story: Job Story и User Story.

Оба шаблона применяются, любой из них помогает в коммуникации и в финализации ваших требований.

Классический формат шаблона User Story выглядит так:

Как <Роль>
Я хочу <Действие>
Для того чтобы <Цель>

И есть формат Job Story

Когда <ситуация>
Я хочу <мотивация>
Чтобы <результат>

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

В этих шаблонах есть два различия.

  • в шаблоне User Story мы больше фокусируемся на роли, описываем роль и персону, которая будет работать с нами;

  • в шаблоне Job Story мы описываем ситуации и то, что мы с этой ситуацией хотим сделать или что хочет сделать пользователь, и где мы ему должны помочь.

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

 

Формируем критерии приемки

 

 

В конце работы с историей мы формируем для нее критерии приемки. Здесь есть известный шаблон: Given, When, Then.

  • мы описываем, что у нас дано – начальная история;

  • когда, в каких случаях возникают какие-то действия;

  • что мы получаем в результате реализации.

Возьмем пример со светофором.

  • Дано: горит красный сигнал светофора

  • Когда проходит определенное количество времени

  • Что мы должны сделать? – переключить сигнал светофора на желтый.

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

 

Непрерывные исследования

 

Agile – это не только работа в команде, но и непрерывный процесс исследования и коммуникации. Мы постоянно работаем с заказчиком, с потребителями, с командой – коммуницируем со всеми ролями, вовлеченными в процесс создания продукта.

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

Agile подталкивает к трем следующим активностям:

  • мы должны непрерывно подготавливать требования, взаимодействуя с заказчиком (непрерывное исследование);

  • непрерывно реализовывать эти требования (непрерывная реализация);

  • непрерывно выпускать этот процесс вовне (непрерывный выпуск).

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

Основная концепция Agile в том, что мы наряду с непрерывной реализацией ценности непрерывно работаем над уточнением требований, постоянно взаимодействуем с заказчиком, ищем узкие места, делаем все, чтобы на выходе требования были понятны нашим исполнителям.

 

 

Вот так этот цикл исследований выглядит в Agile – у нас появляется цикл работы с требованиями до попадания в разработку:

  • появляется гипотеза;

  • происходит коллаборация с менеджментом;

  • уточнение у архитектора;

  • выявление зависимостей с командами;

  • и потом синхронизация в процессе реализации.

Например, диаграмма Ганта – это один из способов применения того, как мы эту фичу будем реализовывать совместно с другими нашими подразделениями.

 

Вопросы

 

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

Да, Agile – это недешевая технология, нужно собрать команду вместе, выделить ее на 100% для реализации работы с заказчиком – недешевая история на старте.

Но если вы хотите сделать что-то на коленке, вам не нужна Agile-команда, вы можете взять одного разработчика. У меня был проект, когда я даже без разработки, с помощью одного тестировщика выпустил первый MVP. У нас в компании было достаточно технологий, и он из этих технологий собрал прототип. Интересно, что этот прототип после сборки продали 4-м заказчикам. Когда мы провалидировали спрос, что это интересно и действительно требуется на рынке, мы начали масштабировать эту историю. Поэтому мы идем от потребности.

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

Если вы четко понимаете, что вам достаточно MVP, вам проще точечно за счет микроменеджмента раскидать задачки по исполнителям и найти эксперта, который сможет собрать это в кучу и отдать заказчику. Но этот подход, к сожалению, не масштабируемый. Первое MVP вы соберете, но как только вам нужно будет его быстро масштабировать, вы столкнетесь с тем, что у вас продукт собран на костылях. Вам нужно будет все-таки собирать команду, которая будет системно работать с заказчиком. Когда у вас возникает потребность системной работы с заказчиком на удовлетворение его ценностей, вы приходите к Agile-подходу.

Тогда, по сути, в Agile не важна технология, а важна слаженность команды? А классические технологии позволяют неслаженной команде получить хоть какой-то результат?

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

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

Так же, как и постановка задач. Если я знаю, что я хочу получить мост, знаю, как он выглядит, знаю, какую цель он будет преследовать – тут не важно, работаете ли вы Agile-командой или классическим проектным управлением. Здесь важны компетенции, с которыми вы будете это делать, потому что задача понятна.

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

Но я согласен, что классные крутые команды, которым «море по колено», могут успешно сделать проект с любой технологией.

Единственное, что Agile помогает вырастить сильную команду. В Agile есть принципы Inspect и Adapt, которые помогают даже в слабой команде.

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

Если вы цикл Шухарта-Деминга (цикл PDCA) применяете внутри команды, она учится и развивается. Это основной принцип Agile – мы должны постоянно модифицировать свои методы, инструментарий и скилы. Т.е. если вы в этом направлении двигаетесь, можно сказать, что вы уже удовлетворяете принципам и ценностям Agile, даже если вы не называете это Agile.

В PMBoK тоже есть итеративный подход – это тот же цикл Шухарта-Деминга, только дольше по времени. PMBoK не предлагает все сразу спланировать и идти по водопаду, он предлагает вносить коррективы по итогам работы и перепланировать в рамках исполнения тоже. Но в Agile цикл гораздо более короткий, обучение гораздо более эффективное, и команда может расти гораздо быстрее.

Согласны ли вы, что «Водопад» очень часто – средство прикрытия «пятой точки»? Процесс Waterfall направлен не на решение проблемы, а на соблюдение процесса.

Да, именно так. Но не всегда. Действительно, Waterfall был создан, чтобы сформировать некие правила игры и показать прозрачность работы над проектом или продуктом. Он был предназначен для прозрачности. Но, к сожалению, многие менеджеры интерпретируют это так: есть требования, я по ним делаю. Если вы работаете с госзакупками – это очень частый пример, когда в ТЗ прописано какое-то условие, и пока оно не будет выполнено, заказчик проект не примет.

Но даже в классическом проектном управлении для фиксации требований есть инструменты, которые позволяют изменять ТЗ в процессе работы. Например, в b2g у нас есть ФЗ, по которому мы контрактуемся, но в то же время многие заказчики хотят работать по Agile. Поэтому, несмотря на то, что у нас на этапе контрактования были зафиксированы определенный Scope и четкая описанная архитектура, мы в процессе разработки для нашего ТЗ выпускаем допсоглашения.

С какими проблемами можно столкнуться, если работать с User Story или с Job Story?

Я очень много работаю с продуктовыми менеджерами – я их постоянно учу. И в процессе обучения я их постоянно заставляю перекладывать свои дорожные карты в формат User Story или Job Story. И каждый раз для них самая большая проблема – сформулировать цель (в User Story) или результат (в Job Story).

Почему-то мы этот момент очень часто упускаем. Запускаем Agile-команду, пишем, что надо сделать вот это, а для чего – забываем. Через какое-то время команда начинает сбавлять скорость, мотивация теряется, мы становимся молотилками маленьких фич и не понимаем, зачем это делать.

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

Пример: в команду пришел человек от бизнеса и говорит: «Нужно сделать новый отчет». Команда говорит: «Чтобы его разработать, нужно собрать данные здесь и здесь – полгода времени уйдет». Так получилось, что я был на этой встрече, помогал фасилитировать, поэтому я спросил: «Зачем вам этот отчет?» – «Старый отчет нас не устраивает, потому что в нем нет таких данных». Ребята сразу: «Но мы же можем колонку в старый отчет вставить – вас это устроит?» – «В принципе, да» – «Тогда это плевое дело, два дня, и мы сделаем».

Когда мы рассказываем про цель, зачем нам это нужно, мы меняем технические возможности реализации. У нас бизнес чаще всего начинает мыслить за команду – что нам нужно сделать, и мы рынок воспитали таким образом, что заказчик должен диктовать нам техническую реализацию. Это, к сожалению, проблема рынка. Заказчик должен говорить, что он хочет, а команда должна подгонять технические возможности, которые у нее есть. Эта прослойка, к сожалению, теряется.

Бизнесу очень трудно объяснить, что не нужно диктовать команде, как делать, это должна решать команда сама. Но убедить не всегда получается. Бизнес начинает говорить ИТ-шными терминами: «Сделайте Push-уведомление о событии». Начинаешь разбираться, оказывается, что там не нужно Push-уведомление. И таких вещей очень много. Это – та лазейка или баг, которая существует при переходе от классического управления к управлению требованиями в Agile. В идеале должно быть так: бизнес говорит, что хочет делать, а команда говорит, как она может помочь, поддержать эту потребность.

 

*************

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

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

*************

Специальные предложения

Оставьте свое сообщение

См. также

ТРИЗ. Решение нерешаемых проблем в бизнесе Промо

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    820    user1576201    6    

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    7533    Evil Beaver    14    

Технология вялых проектов

Управление проектом Бесплатно (free)

Не все ж такие молодцы.

11.05.2022    4225    1c-intelligence    48    

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

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

02.02.2022    5274    denisgalimoff    3    

Стратегия выживания в корпоративных войнах Промо

Управление проектом Бесплатно (free)

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    14319    GSoft    21    

7-ой PMBOK® Guide: Есть ли там что-то действительно полезное?..

Управление проектом Бесплатно (free)

Честно скажу, я всегда с некоторой настороженностью открываю разные "чересчур умные" книжки. Особенно их переиздания (в данном случае аж 7-ая версия). Ибо очень часто разрыв между высокими концепциями и реальностью оказывается чересчур огромным (особенно в этом плане меня позабавил катастрофический непонятный вебинар на тему понимания).

07.09.2021    7710    MariaTemchina    0    

Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

Управление проектом Бесплатно (free)

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    8026    MariaTemchina    12    

Как приручить драконов. История построения экосистемы на основе 1С

Управление проектом Бесплатно (free)

Многие задачи интеграции и мониторинга не имеют стандартных решений в среде 1С. О том, как команда 1С-ников смогла организовать успешный симбиоз учетной системы и системы тысяч внешних устройств, на INFOSTART MEETUP Новосибирск.Online рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.

14.05.2021    4277    G.Shatrov    6    

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

Управление проектом Бесплатно (free)

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    11263    user809424    11    

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

Управление проектом Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    7423    MariaTemchina    86    

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

Управление проектом Бесплатно (free)

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

16.02.2021    4157    MariaTemchina    45    

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

Управление проектом Бесплатно (free)

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    4289    MariaTemchina    17    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    33766    1СERP    175    

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

Управление проектом Бесплатно (free)

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

10.02.2021    5765    andironenko    15    

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

Управление проектом Бесплатно (free)

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

09.12.2020    2725    MariaTemchina    3    

Что почитать про Agile для чайников?

Управление проектом Бесплатно (free)

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    5817    MariaTemchina    9    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    35208    1СERP    189    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

Управление проектом Бесплатно (free)

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    6690    MariaTemchina    9    

Как создать коробочный программный продукт

Управление проектом Бесплатно (free)

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

05.10.2020    4010    primat    2    

Стыд и Скрам: взгляд глазами собственника из IT-шников

Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    5228    IvanAT1981    5    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

Недавно была написана статья о том, как работает мотивация персонала. Материал получил активный отклик у читателей Инфостарта, на форуме развернулась дискуссия, которая в итоге была достаточно далека от содержимого исходной статьи и свелась к критике самой идеи работы во франчайзи. Чтобы как-то ответить на эту критику, хотелось бы более подробно рассказать о том, что такое современный франчайзи и как он устроен. Но начнем мы с истории этого вида бизнеса, глазами рядового специалиста. Автор статьи Андрей Мироненко.

10.04.2017    35275    1СERP    107    

Советы начинающим РП: Подводим итоги шляпной вечеринки 

Управление проектом Бесплатно (free)

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

15.09.2020    3119    MariaTemchina    5    

Как стать исполнителем в проекте от Инфостарта

Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    4190    alexandr.blinov    17    

Как продвигать авторские конфигурации 1С

Управление проектом Бесплатно (free)

Конфигурации 1С продвигать на рынке самостоятельно нелегко. Мало того, что нужно развивать продукт, чтобы удовлетворять потребности клиентов и выгодно отличаться от конкурентов, нужно еще заниматься его популяризацией, продажами и поиском проектов для внедрений. Большую часть этой работы готов взять на себя Инфостарт. Авторам останется только разработка, развитие и внедрение. Чем именно готов помочь Инфостарт, рассказал руководитель корпоративного отдела компании Рамин Курбанов. 

07.09.2020    3020    RKurbanov    3    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

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

03.04.2017    46717    1СERP    233    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    4716    MariaTemchina    30    

Матрица СКГ как инструмент разработки деловой модели

Управление проектом 1С:Франчайзи, автоматизация бизнеса Россия Управленческий учет Бесплатно (free)

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

24.07.2020    3174    Soliton    10    

Видеозаписи открытых вебинаров Марии Темчиной

Управление проектом Бесплатно (free)

В этой публикации решила собрать здесь видеозаписи открытых вебинаров с моим участием. Чтобы были в одном месте, ибо их не всегда просто найти на Инфостарте. "Всё, что вы хотели узнать...", "Лучшие морковки проектов внедрения...", "Путь джедая в управлении проектами..." и так далее.

21.07.2020    4044    MariaTemchina    1    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

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

17.06.2016    42123    raiml    37    

Управление в стиле Догвилль

Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    5544    1c-intelligence    17    

Наиболее типичные ошибки при оценке работ в проектах 1С

Управление проектом Бесплатно (free)

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

13.06.2020    3446    Koder_Line    9    

Как воспитать в себе РП? Часть 2. Растим ведущего руководителя проектов

Управление проектом Бесплатно (free)

Теперь поговорим про роль ведущего руководителя проектов, задающего и формирующего политику управления проектами в компании.

08.06.2020    7822    MariaTemchina    0    

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

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    47227    CheBurator    66    

Как воспитать в себе РП? Часть 1

Управление проектом Бесплатно (free)

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

01.06.2020    9074    MariaTemchina    4    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    6914    sapervodichka    1    

Почему Scrum не работает в проектах 1С

Управление проектом Бесплатно (free)

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

18.05.2020    13355    MariaTemchina    33    

Практика пуска склада продуктов питания Промо

Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    37506    axxell    15    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Бесплатно (free)

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

23.03.2020    7991    MariaTemchina    26    

Визуализация фич Vanessa Automation в StoryMapper

Управление проектом ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

21.03.2020    4857    oleynik.dv    7    

Как завершать проекты в срок

Управление проектом Бесплатно (free)

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

10.03.2020    5525    VLikhobabin    6    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Управление проектом Управленческий учет Бесплатно (free)

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

13.11.2014    28739    raiml    236    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    9875    VLikhobabin    44    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Бесплатно (free)

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

23.01.2020    43855    MariaTemchina    12    

CVP - анализ как инструмент принятия управленческих решений Промо

Управление проектом Управленческий учет Бесплатно (free)

В данной статье хотелось бы акцентировать внимание читателей, которым близка тема управленческого учета, на вопросах CVP – анализа («затраты-объем-прибыль») и маржинального учета.

13.05.2014    140667    Evgen.Ponomarenko    5    

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

Управление проектом Бесплатно (free)

Статья, продолжающая цикл публикаций по классификации внутренних проектов, а вернее сказать, их отправная точка. Ибо ведение проектов происходит не в вакууме, а во вполне конкретной организации, со своим уставом и иерархией отношений. А что будет с тем, кто сунется со своим укладом в чужой монастырь, нам напомнили как раз в предновогодний вечер: "Да на кол его посадят, всего и делов." Чтобы этого не произошло с вами - присмотритесь к предполагаемому месту работы, а я с вами поделюсь очень интересной классификацией организаций от признанных гуру в этой области. Из-за этого статья пригодится как HR-менеджерам, так и из соискателям. Прошу под кат...

04.01.2020    6906    capitan    52    

BDDSM-практики, или 50 оттенков желтого

Управление проектом ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    12732    Mistress_A    28    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    7594    1c-intelligence    33    

Как продавать, не продавая? Сарафан для 1с-ника Промо

Управление проектом Бесплатно (free)

Измышления на тему управляемого запуска сарафанного радио и создания очереди клиентов в применении к сфере 1с-услуг.

27.10.2013    54363    nurpoz    157    

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе"

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

14.10.2019    6557    chavalah    16    

Незакрытый проект на 1000 часов

Управление проектом Россия Бесплатно (free)

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    14658    ogroup    165