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

18.09.20

Управление проектом - Взгляд со стороны Заказчика

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

 

 

Меня зовут Иван Тягунов. Я – основатель и соучредитель группы компаний WiseAdvice.

Мы оказываем различные услуги для бизнеса, в том числе, в состав нашей группы входит достаточно крупный 1С-франчайзи с тиражными линейками Финансист и Юрайт. И еще у нас есть совместное предприятие с фирмой 1С, которое является одним из лидеров рынка аутсорсинга учетных функций.

 

 

У нас достаточно крупная компания – где-то 800 человек, расположенных в разных городах страны – в основном, в Москве.

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

 

Стыд и Scrum

 

Стыд – именно такое чувство должны испытывать те руководители ИТ-подразделений, которые бескомпромиссно утверждают: «Мы работаем по Scrum» или «У нас Agile». Я утверждаю, что 99% тех, кто об этом говорит бескомпромиссно и без всяких оговорок, на самом деле не читали эти фреймворки и концепции и вообще очень мало знают об этом. Поэтому в большинстве случаев они не используют этот фреймворк в его чистом виде, а используют что-то иное, притом чаще всего не используют то, что нужно.

 

 

Но Scrum и Agile сейчас в моде. Они в тренде, по ним хайп. Каждый хочет быть Scrum. Каждый хочет быть Agile. Эта вся история начинает передаваться от одного к другому, и уже говорить обратное как-то не модно – на тебя странно посмотрят: «Ты что, работаешь не по Scrum? Как такое может быть?»

Соответственно, это все создает некий такой «стадный инстинкт», когда все друг за другом повторяют одно и то же, но что они говорят, до конца не понятно.

 

Scrum-команда

 

 

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

Начнем с того, что команда в Scrum – это одна из самых важных частей фреймворка. На этом слайде приведены прямые цитаты из фремворка. Соответственно, в команде должны быть:

  • Преданность Scrum
  • Открытость и уважение
  • И смелость и сфокусированность.

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

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

 

 

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

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

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

 

 

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

 

Scrum-мастер

 

 

Scrum-мастер. Следующий ключевой элемент этого фреймворка.

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

Языком фреймворка – это «лидер-слуга», коучер, фасилитатор.

 

 

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

 

 

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

  • Помогает найти наиболее эффективные техники для управления бэклогом продукта,
  • Объясняет Scrum-команде необходимость кратких и понятных элементов бэклога продукта.
  • Помогает владельцу продукта упорядочить бэклог, чтобы получить максимальную ценность.

 

 

Что это означает?

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

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

 

 

Обратите внимание, Scrum-мастер должен заниматься только этой деятельностью 100% времени, без совмещений, на full time. Если вы назначили кого-то Scrum-мастером, ничего не получится. Все строится на том, что этот человек постоянно общается с коллегами из других компаний, постоянно занимается именно этой деятельностью, чтобы как можно лучше понять Scrum и научиться его применять.

Поэтому максимум, что вы можете поручить Scrum-мастеру – это работа с одной до двух-трех команд в зависимости от их масштаба и прочих контекстов.

Поэтому если вы хотите работать во фреймворке Scrum, Scrum-мастер вам нужен обязательно на full time.

 

 

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

Тогда просто забываем о фреймворке Scrum, потому что работать он в чистом виде не будет.

 

Владелец продукта

 

 

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

  • Он занимается описанием элементов бэклога продукта в понятном виде (формулирование этих элементов)
  • Управляет порядком элементов бэклога и структурой
  • И он отвечает за то, что команда разработки в достаточной степени понимает весь этот бэклог.

Это очень трудоемкая история.

 

 

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

Владелец продукта непосредственно участвует в основных событиях или встречах Scrum – т.е. в ходе планирования, при обзоре или ретроспективе спринта.

Это очень трудоемкая роль.

 

 

А теперь давайте посмотрим – кроме того, что владелец продукта управляет элементами бэклога, он должен в целом понимать долгосрочное видение продукта – куда этот продукт будет развиваться, что из него получится. Поэтому в нашем контексте владелец продукта обязан (так же, как и Scrum-мастер):

  • знать техники анализа требований и основы проектирования ИТ-систем;
  • обладать хорошим знанием автоматизируемой предметной области (без этого никакого видения продукта не получится);
  • и знать основы платформы 1С и заодно тех типовых прикладных решений, которые вы развиваете.

Это очень сложная роль.

 

 

Один владелец продукта может вести от одного до двух-трех продуктов максимум, в зависимости от объема команд разработки.

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

 

 

И тут возникает интересный вопрос – кто бы мог быть владельцем продукта?

  • Сотрудник ИТ-службы? Ему не хватит видения продукта, знаний предметной области, маловероятно, что ему будут даны полномочия на приоритезацию задач (элементов бэклога).
  • Если же это будет бизнес-заказчик, ему не хватит времени, у него будет недостаток ИТ-компетенций.

Поэтому владелец продукта – это очень сложная роль во фреймворке Scrum.

 

 

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

В данном случае:

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

И в этом случае вообще не понятно, как все эти роли совместить в одном человеке. Это должна быть какая-то очень уникальная личность – 100% занятый только этим.

 

 

Проектирование. Владелец продукта должен

  • четко снять видение от собственника в данной ситуации;
  • снять знание предметных областей с руководителя пользователей;
  • и все еще вовремя давать обратную связь.

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

 

Команда разработки

 

 

Команда разработки – следующий важный элемент Scrum. В чем суть? Тут показаны формулы:

1 бэклог = 1 владелец продукта

1 владелец продукта = 1-3 продукта

1 команда разработки = 1 бэклог

Это такая система уравнений, которая дает нам итог – одна команда разработки должна заниматься одним (максимум до трех) продуктом при условии, что у них один владелец. То есть команда разработки не может работать с двумя владельцами продуктов. Поэтому 2-3 продукта еще может быть, но владелец у них должен быть один.

 

 

И тут начинается ситуация – команда разработки, если мы посмотрим на фреймворк, должна состоять от 3 до 9 человек. Менее трех считается, что все это бессмысленно. Более 9 считается, что там резко падает эффективность.

Напомню, что в эти 3-9 человек не включается ни владелец продукта, ни Scrum-мастер. То есть, если мы посмотрим на общий масштаб всей этой истории, в контексте которой она должна нормально работать, то общая численность коллектива должна быть от 5 до 11 человек. Это – одна команда, включая дополнительные роли в виде Scrum-мастера и владельца продукта.

 

Дополнительные требования к команде разработки

 

 

Команда разработки должна быть самоорганизующейся и кроссфункциональной.

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

Поэтому очень важное требование к команде разработки – что она должна быть самодостаточная и кроссфункциональная.

 

 

Идем дальше. Исходя из требований по кроссфункциональности что у нас получается?

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

 

Продукт

 

Тут начинается самое интересное – что же такое продукт в терминах Scrum? Это вообще самый мутный и сложный вопрос.

 

 

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

Я утверждаю, что прикладных решений на основе типовых 1С:УТ и выше (выше по широте и сложности функциональности) не может быть всего одного владельца продукта. Особенно, когда речь идет о многих десятках и сотнях пользователей. Это слишком крупные системы, чтобы один человек управлял бэклогом вплоть до его формулирования, а это – неотъемлемая, неделегируемая обязанность владельца продукта.

Хотел бы я увидеть такого владельца, который сформулирует весь бэклог на систему с 200 пользователями, которые работают в десятке функциональных областей (10 отделов различных компаний). И какой-то абстрактный человек формулирует бэклог на всю эту историю? Мне кажется, это нереально.

 

 

Поэтому в мире 1С продуктом будет являться зачастую только часть прикладного решения.

 

 

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

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

Это очень сложный вопрос – выделить внутри одного прикладного решения границы.

 

 

Если же мы еще вспомним, что у нас под прикладным решением низом идет БСП, а БСП – это тот код, с которым нам тоже приходится работать, получается, что это крайне сложно. Получается, что нам нужно еще и саму БСП поделить. Это же часть решения, мы же ее касаться будем. Поэтому в мире 1С такие сложные большие корпоративные системы автоматизации формирования продукта, описание его границ и его взаимодействие с другими продуктами – это очень сложная история на практике.

 

Другие значимые элементы Scrum

 

 

Какие еще есть элементы Scrum?

Scrum опирается на три кита:

  • прозрачность;
  • инспекция;
  • адаптация.

Предполагается, что:

  • есть некий спринт – отрезок времени продолжительностью обычно от одной недели до 4-5 недель (Scrum не рекомендует длительность спринта более одного месяца);
  • Scrum-команда поставляет продукт итеративно, инкрементально, используя обратную связь и все такое;
  • к концу спринта инкремент должен быть готов к эксплуатации – для каждого элемента бэклога требуется сформулировать критерии готовности, они должны быть понятны не только команде разработки, но и всем заинтересованным лицам.

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

 

 

Что же происходит в реальном мире автоматизации бизнеса на платформе 1С?

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

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

 

Можно ли в мире автоматизации бизнеса выполнять вышеуказанные требования Scrum?

 

 

Вопросы по бэклогу.

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

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

Это – вопросы. Некоторые ответы на них мы сейчас получим.

 

 

Что важно понимать? Роли, артефакты, правила и события Scrum не подлежат изменению. Это означает (прямая цитата из Scrum), что «Scrum является цельным фреймворком. Если вы оттуда взяли только некоторые элементы или какие-то элементы видоизменили, то это уже не будет считаться Scrum».

Scrum сам про себя говорит именно так – что его можно использовать только в неизменном виде по ключевым моментам. Его можно развивать, но не менять или выбрасывать что-либо. Это очень важный вопрос.

 

 

Итоговый чек-лист по применимости фреймворка Scrum.

  • Возможность установления границ продукта.
  • Кросс-функциональная команда на срок от года.
  • Компетентный и уполномоченный владелец продукта как выделенная роль.
  • Компетентный Scrum-мастер как выделенная роль.
  • И четкая определенность по другим ключевым и взаимосвязанным вопросам.

При этих условиях Scrum у вас может взлететь в чистом виде. Если же эти условия не будут выполняться, то вы будете использовать не Scrum в чистом виде, а отдельные его элементы.

 

 

Конечно, можно модифицировать Scrum до неузнаваемости, нарушив его базовые принципы и снизив тем самым его целостную эффективность, но вопрос – зачем?

Потому что эта эффективность может стать отрицательной.

 

 

Что же делать, если Scrum у вас все-таки не применим, и вы не соответствуете тем критериям, которые были указаны в чек-листе?

  • во-первых, не расстраиваться – вы не одиноки, в мире 1С Scrum в чистом виде применим в редких случаях;
  • потом нужно не забыть изучить другие фреймворки, методологии, стандарты, библиотеки лучших практик;
  • взять из них то, что требуется вам для создания собственного внутреннего фреймворка;
  • и не забыть взять самое ценное из Scrum.

 

Что ценного можно взять из Scrum

 

 

Что же самое ценное в Scrum?

  • Устойчивые кросс-функциональные команды.
  • Принцип формулирования задач через критерии готовности.
  • Декомпозиция работ на предельно короткие этапы (итерации), минимально достаточные для получения частой обратной связи от заинтересованных лиц.
  • Коучинг и фасилитация как наиболее эффективный способ и стиль руководства.
  • Ретроспективы как способ организованной рефлексии и анализа происходящего в целях устранения препятствий и поиска резервов для роста продуктивности.

В Scrum есть что взять.

 

Что самое главное стоит заимствовать из общих ценностей и принципов Agile

 

 

Вы знаете, что в Agile у нас четыре ценности и 12 ключевых принципов, которые мало кто читал. Я рекомендую брать в работу следующие принципы:

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

 

 

Какие еще принципы Agile я рекомендую использовать в работе?

  • Работающий продукт важнее исчерпывающей документации. Что я рекомендую? В части пользовательской документации использовать видео и записывать его только при первичном обучении (эффективнее всего обучать по ролям, основываясь на user story).
  • Еще интересный принцип – строить документацию от обратного – от частых запросов на Service Desk. Ну и, соответственно, желательно в формате видеоинструкций.
  • В части анализа требований рекомендую документировать только то, что реально важно. Не нужно использовать какие-то чужие шаблоны (если не понимаете, зачем). Формулировать в документированном виде нужно только самое главное, как можно короче.

 

Другие источники для создания собственного фреймворка

 

Что еще вы обязаны знать на уровне кругозора? Что и откуда можно заимствовать, чтобы сделать собственный фреймворк в тех случаях, когда Scrum вам не подходит?

 

 

Рекомендую использовать:

  • Концепцию MVP (минимально-жизнеспособный продукт, minimum viable product). Рекомендую использовать методологию разработки через прототипирование интерфейсов – в данном случае мы сможем как можно быстрее показывать заинтересованным лицам и владельцам продукта систему глазами, а визуальный канал восприятия самый эффективный.
  • Рекомендую канбан-доски.
  • Рекомендую принцип WIP для устранения узких мест.
  • Для крупных проектов рекомендую составление плана управления рисками и плана управления коммуникациями.
  • Хочу обратить ваше внимание – чтобы быть более Agile и при этом проектным, существует Agile Practice Guide – это совместный труд PMI и Agile Aliance, который рассказывает о том, как быть более гибким при проектном управлении. Этот труд надо прочесть. Он очень маленький, но в нем заложены важные принципы.

 

 

Для этапа сбора и анализа требований (эти этапы вообще никак не формализованы во фреймворке Scrum) рекомендую:

  • Использовать mind-карты, как impact-технику (технику извлечения знаний).
  • Рекомендую ознакомиться с набором лучших практик BABOK – этот фреймворк содержит техники сбора требований с менеджмента.
  • На стыке этапов анализа требований и проектирования системы очень рекомендую ознакомиться с фреймворком SWEBOK. Его мало кто знает, но если вы его загуглите и почитаете, вас он, я думаю, очень заинтересует. Наверное, это наиболее полный фреймворк на этапах анализа требований к проектированию системы.
  • Для укрупненного планирования, если вам так нравится слово Scrum, рекомендую ознакомиться с методологией Scrumban, потому что она хорошо закрывает более длительные этапы и их декомпозицию по принципу так называемых «ведер». Ознакомьтесь с ней подробнее – в данных доклад это не уместится.

 

Что необходимо знать для этапа проектирования системы

 

 

Что еще из нашей практики рекомендую использовать?

  • Для бизнес-процессов – там все понятно, BPMN или Aris.
  • Для пользовательских интерфейсов – прототипы на основе user story или JTBD.
  • Для отчетов тоже есть несколько хороших техник – они описаны на слайде.
  • Для интеграций тоже есть свои различные нотации, диаграммы и т.д. Надо просто копать и делать свои правила использования лучших практик и других знаний.

 

 

 

Если кому-то эта тема интересна, отвечу на вопросы, дам концы, как с этим жить дальше.

 

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. 

 

10 - 12 октября 2024 года состоится конференция INFOSTART TECH EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Приемы, методы разработки и тестирования
  • DevOps-практики, управление инфраструктурой разработки
  • Интеграция и обмен данными
  • Идеи и тренды в разработке 
  • Администрирование серверов 1С и СУБД. HighLoad оптимизация  
  • Развитие технической команды. Личная эффективность разработчика 

INFOSTART TECH EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    2264    0    user1270271    0    

13

Взгляд со стороны Заказчика Бесплатно (free)

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

05.12.2023    1321    0    user1851969    0    

4

Взгляд со стороны Заказчика Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

22.08.2023    1587    0    user1642712    0    

13

Взгляд со стороны Заказчика Бесплатно (free)

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

20.07.2023    1315    0    user1642712    0    

6

Взгляд со стороны Заказчика Бесплатно (free)

В семнадцатом выпуске подкаста Радио “Аналитик“ обсудили, как представители сфер foodtech и e-com определяют, что пора автоматизировать процессы, на что обращают внимание при выборе подрядчика, что ценят в коммуникациях и как определяют, успешно выполнена автоматизация или нет.

01.05.2023    630    0    Radio_Analyst    0    

1

Взгляд со стороны Заказчика Бесплатно (free)

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

17.04.2023    649    0    Radio_Analyst    0    

2

Взгляд со стороны Заказчика Руководитель проекта Бесплатно (free)

Зачем вообще нужно управление проектом? Надо ли заказчику показывать стоимость управления проектом? И должен ли руководитель проекта сам внедрять 1С параллельно с управлением? На эти вопросы в рамках митапа «Инструментарий РП» ответила руководитель проектов ВЦ «Раздолье» Вера Пикурен.

02.07.2021    3297    0    VeraPikuren    4    

13
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. AntoShiK86 32 01.10.20 08:41 Сейчас в теме
Есть ли шаблон, или законченный демо проект реализованный с применением этий концепции? Например у нас был УТ11, руководство поставило задачу сделать "ЧудоПланирование", и разложено, что какие этапы будут, какие технологии в этои этапе..
2. DYN71 28.10.20 12:07 Сейчас в теме
Многие поддались новомодным течениям не осознавая основы необходимости внедрения тех или иных технологий и походов.

Если посмотреть глубоко то, принципы, по которым осуществляется создание программного продукта в новомодных технологиях Agile/Scrum строятся в общем-то на концентрации и ПЕРЕНОСЕ ВЗГЛЯДА со стороны команды разработчика на ВИДЕНИЕ процесса изготовления и сдачи продукта СО СТОРОНЫ ЗАКАЗЧИКА. Так как заказчик, как правило, осознает высокие риски не попадания в сроки и получения "плохого" продукта. Как следствие происходит отказ от фиксации времени выполнения проекта, перенос акцентов от жесткого документирования, следования иным принципам "водопадной" системы (но не отказ от них) к получению качественного продукта в глазах заказчика за меньшее время.

Поэтому у заказчика желания:

1. Так организовать процесс , чтобы непрерывно и как можно раньше устранять основные риски
2. Чтобы команда максимально концентрировалась на управлении требованиями заказчика
3. Иметь возможность вносить изменения в первоначальные требования к продукту в процессе разработки основываясь на соответствии части продукта изготовленной на предыдущем этапе
4. Возможность обеспечивать максимальное качество на всех этапах разработки проекта
5. Обеспечение сплоченности команды и ключевой роли архитектора

Отсюда рождается спиральная модель разработки:

а) Инструменты должны быть нацелены на минимальное время разработки
б) Необходимо создание прототипов для уточнения требований заказчика
в) Каждая новая версия продукта основывается на оценке предыдущей версии продукта
г) Команда разработчиков должна тесно сотрудничать и каждый участник должен быть готов выполнить несколько обязанностей
д) Управление проектом должно минимизировать время разработки

Есть еще и другой "глубинный" взгляд на способы управления проектами.

Чем более высокая компетенция руководителя проекта (для него - это ТИПИЧНАЯ деятельность), тем более жесткий подход в управлении - понятно что и как, когда делать! Чем более НЕ ТИПИЧНА для вас деятельность/область работ, тем более гибкий подход вы используете. Чем больше прибавилось компетенции тем больше переходим к проектному управлению, чем более рутинной становится ваша деятельность тем больше мы переходим у операционному управлению.
kirinalex; +1 Ответить
3. papche 614 07.04.21 11:03 Сейчас в теме
Спасибо за статью/доклад! Поддерживаю спокойный и взвешенный подход к scram/agile - изучать и брать применимое в нашей отрасли и смотреть по сторонам в плане методологий управления.
4. kirinalex 15 13.06.21 17:31 Сейчас в теме
Спасибо, интересно и полезно
5. alex_sayan 14.07.21 08:58 Сейчас в теме
Изначально Agile был придуман айтишниками-практиками:
https://ru.wikipedia.org/wiki/Agile_Manifesto
его сформулировали известные программисты, такие как Мартин Фаулер, Кент Бек, Роберт Мартин и другие. А потом Agile попал под менеджерское мракобесие, и оброс всякими менеджерскими методиками успешной успешности и эффективной эффективности. Думаю, со скрамом произошло что-то подобное
Оставьте свое сообщение