Приоритизировали, приоритизировали, да не выприоритизировали...

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

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

Итак, выдыхаю после конференции Infostart Event-2018 и продолжаю свой цикл статей про Agile. Меня, кстати, можно поздравить с получением сертификата PMI-ACP (Agile Certified Practitioner). Так что в своей статье опираюсь не только на свой опыт знакомства с различными проектами автоматизации и не только, но и на опыт, так сказать, мировых экспертов по проектным управлениям. Хочу сказать, что благодарна полученному обучению и подготовке - позволяет сложить картинку, что же такое этот Agile, и с чем его едят - как в проектах автоматизации, так и в разных других отраслях.  

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

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

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

Шаг 1. Исполнитель замотивирован на выдачу  ценности максимально быстро

Важно, что обе стороны (и заказчик и исполнитель) должны быть готовы действовать в парадигме Win-Win (выиграл-выиграл) - то есть, чтобы один участник получил максимально подходящий продукт, а другой - достойную оплату за оказанные услуги. А не в более привычной Win-Lose (выиграл-проиграл) - когда каждый пытается прогнуть партнера на максимально выгодные для себя условия. По моему опыту, не все компании на рынке готовы к такому стилю сотрудничества. Но их число неуклонно повышается, повышая тем самым применимость Agile. И, с другой стороны, при внутренних проектах автоматизации атмосфера сотрудничества между бизнесом и ИТ-подразделениями встречается всё чаще - с чем, вероятно, и связан тот факт, что я знаю куда больше успешных применений “фреймворков подобных Scrum” именно во внутренних проектах внедрения.

 

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

Итак, за счет чего мы можем дать максимальную ценность? Нам, очевидно, нужно требования собрать,  и дальше требования приоритизировать.
Собирать требования Agile рекомендует в виде так называемых “User stories” - пользовательских историй - сценариев пользовательского поведения на деловом языке пользователя, которые система должна позволять реализовать, и которые сразу дополняются критериями приемки.
Классическая формулировка user story выглядит следующим образом:

As ____________ I want/have to _____________ so that ________________

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

Чем удобен формат user story? Их просто сформулировать пользователю, и сразу понятно как проверять их на выходе.
В моей практике часто бывает не просто строго выдерживать именно вот такой формат. Но попытка перейти на пользовательский язык сама по себе облегчает коммуникацию между заказчиком и исполнителем.

Шаг 3. Приоритизируем требования

Мы помним, что Agile предполагает много маленьких релизов. Поэтому в первый релиз войдут не все фичи, а только самые важные. Каким образом можно их приоритизировать? Есть разные подходы:

Простые схемы приоритизации.

MoscowСамые распространенные на практике. Мы просто присваиваем фичам приоритеты, например, по трехбалльной шкале: высокий, средний, низкий.
Что здесь важно: без четких критериев, что именно мы считаем “высоким” приоритетом, мы очень быстро скатимся к тому, что практически все фичи будут получать самый “высокий” приоритет, и система потеряет свой смысл. Как, например, потеряет свой смысл идея спец. транспорта, с проблесковыми маячками и с сиренами будут все машины на дороге. 

Приоритизация MoSCoW (привет жителям нерезиновой из северной столицы!)

Пользователям предлагается разделить заявленные фичи по тому, насколько они необходимы:
Must, Should, Could, Would like to have but not this time… 

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

Метод 100% 

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

Анализ Кано

Анализ Кано по моему опыту больше подходит для маркетинговых исследований, чем для проектов автоматизации, но технически его вполне можно применять и при уточнении требований при внедрении.
Суть анализа - мы делим все потенциальные функции продукта на несколько категорий:
Threshold - Обязательные - без них продукт категорически не устраивает пользователя
Satisfiers - Ожидаемые добавление данных функций дает линейный рост удовлетворенности - чем больше функций, тем выше удовлетворенность пользователей
Exciters - Вызывающие восхищение - характеристики, превышающие ожидания клиента


Как проводится анализ?
Мы опрашиваем заказчиков и потенциальных пользователей продукта про интересующие нас функции.

  1. Как вы отнесетесь к НАЛИЧИЮ этой функции у продукта?
  2. Как вы отнесетесь к ОТСУТСТВИЮ этой функции у продукта?

На каждый вопрос можно дать несколько вариантов ответа:

  • Мне нравится
  • Я этого ожидаю
  • Мне все равно
  • Я могу с этим работать
  • Мне не нравится


И в зависимости от ответов мы смотрим, к какой категории относится та или иная функция.

 

Анализ Кано

 

 

Шаг 4. Грамотно распределяем требования между релизами

Планирование релизовИтак, мы так или иначе приоритизировали наши функции/наши пользовательские истории.
Что же мы теперь с ними делаем?
Мы определяем последовательность релизов. 
Самый минимальный набор функционала, без которого всё не будет работать - это “хребет проекта”
Минимальный осмысленный набор, включающий в себя ключевые функции, без которых и смысла не было затевать - это “ходячий скелет проекта”
А дальше уже проект будет обрастать “мясом”, которое войдет в следующие релизы...
 

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

 

 

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

 

24

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. sloneg 44 30.10.18 19:48 Сейчас в теме
Хочу поделиться ссылкой на интересную статью по приоритизации
https://foldingburritos.com/product-prioritization-techniques/

VladimirL; +1 Ответить
11. MariaTemchina 317 31.10.18 11:17 Сейчас в теме
(1) Спасибо! Действительно, собрали основные техники в одном месте, удобно.
2. MikhailDr 31.10.18 07:55 Сейчас в теме
Вот такой вопрос есть. Есть хребет, скелет и мясо проекта. Мы сделали хребет, можно приступать к скелету, но тут понимаем, что мясо мы сделаем гораздо быстрее, буквально за пару дней, а на скелет надо потратить месяц. Как поступить в такой ситуации?

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

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

Или я просто не понимаю в чем суть разделения этапов работ и мелкие доработки сюда вообще не относятся?
7. o.kovalev 17 31.10.18 09:09 Сейчас в теме
(2) в чем смысл "мяса" для заказчка если не готов скелет проекта?
MariaTemchina; +1 Ответить
8. MikhailDr 31.10.18 09:15 Сейчас в теме
(7) Это просто удобство. Я же не говорю, что мясо важнее (работать в базе можно и без мяса и без скелета, главное хребет), просто я сделаю его за день и можно если что показать заказчику, работа идет, все в порядке
9. o.kovalev 17 31.10.18 09:22 Сейчас в теме
(8) Мне кажется тут нужно разговаривать с заказчиком, если данное "мясо" ему приоритетнее , и оно будет работать то да
Так как тут можно наткнуться в необходимость переделывать "мясо" уже после создания скелета, в таком случае кто то должен взять на себя эти затраты, и заказчик наверное подумает что это вы за свой счет все переделаете, и скорее всего это будет так либо это будет неудачный проект.
10. MikhailDr 31.10.18 09:45 Сейчас в теме
(9) Нет, именно в том и суть, что не приоритетнее. Но вот мы с заказчиком смотрим хребет и он просит сделать пару мелочей из мяса, они не в приоритете, просто попросили именно сейчас и мне чтобы это сделать надо очень мало ресурсов, но по логике статьи я должен отложить эту работу, которая займет у меня несколько часов на несколько недель, потому что приоритет там ниже.

И вроде это правильно, но как то очень непривычно.
12. MariaTemchina 317 31.10.18 11:22 Сейчас в теме
(2) Смотрите, общая идея Agile в том, что мы пытаемся как можно сильнее сократить так называемую "петлю обратной связи" - то есть выпустить промежуточный результат в опытную эксплуатацию. Это позволит увидеть нюансы и риски, которые мы не учли.
То есть фокус внимания - на получении работающего результата как можно раньше. Из этих соображений и стоит начинать с "хребта", потом переходить к "скелету", и только потом - к "мясу".

Может ли быть ситуация, когда по каким-то причинам целесообразнее сделать сначала "мясо", потом "скелет" (например, потому что для "скелета" недостаточно информации собрано)? - Может. Вообще, любая ситуация может случиться, да и Agile - не панацея.

Суть рекомендаций в том, что мы по возможности стремимся реализовывать принцип "Дельфины вместо китов" - то есть вместо больших громоздких проектов делать маленькие - это позволяет минимизировать риски, уточнять требования, уменьшать шансы долгостроя, и так далее. Ключевое слово - "по возможности".
16. MikhailDr 31.10.18 11:44 Сейчас в теме
(12) Так понятнее, спасибо
MariaTemchina; +1 Ответить
3. 1c-intelligence 5994 31.10.18 08:07 Сейчас в теме
13. MariaTemchina 317 31.10.18 11:32 Сейчас в теме
(3)
1. Матрица Эйзенхауэра - мне хорошо, спасибо.
2. Стратегический эквалайзер - интересно, прочитала с любопытством. Финал статьи почему-то напомнил историю про обезьянку прокрастинации...
Но это про принятия решения исходя из личных мотивов разработчика... А я скорее разбираю мотивы пользователей, которые задачи ставят.
23. 1c-intelligence 5994 31.10.18 12:32 Сейчас в теме
(13) про личные мотивы разработчика там просто для понятности приведено. Вообще, метод, который лежит в основе, рассчитан на ранжирование задач согласно интересам компании, а не исполнителей этих задач.
Кто именно двигает ползунки эквалайзера - не важно.

Но вообще, проблема приоритетов, по моему опыту, всегда в одном - никто не хочет париться с их постоянной расстановкой, независимо от выбранной системы координат. Это же область регулярного менеджмента - неважно, проекта, отдела, организации или тех.поддержки.
24. acanta 45 31.10.18 12:44 Сейчас в теме
(23) Интересы компании - это интересы девушки, которая вышла из отпуска по уходу за ребенком через 9 лет.
Она не может двигать никакой эквалайзер, и она единственная кто заинтересован вернуться на свое место работы на зарплату с уровнем рыночной при реальной утрате квалификации. Все остальные в этом не заинтересованы, даже регулярный менеджмент.
25. 1c-intelligence 5994 31.10.18 12:46 Сейчас в теме
(24) звучит красиво, но не знаю, как это применить на практике - метафору вашу, в смысле.
Вот я пользуюсь эквалайзером для управления и компанией, и проектами, и задачами.
Со мной что-то не так?
28. dm_romanov.idm 01.11.18 10:14 Сейчас в теме
(23)
Но Мария пишет не о приоритизации текучки, а о проектах. Во всех проектах в которых участвовал, то что войдет в первый и последующие релизы, являлось бурной темой для обсуждения. Заинтересованные люди очень активно принимали участие в установке приоритетов. Проблемы что кто-то "парился" с их расстановкой не было.

А вот на текучку никто не хочет расставлять приоритеты. Пользователи, принимают приоритет по умолчанию или ставят самый высокий, низкий на моей памяти никто из пользователей никогда не ставил)). Начальство и программисты делают это чаще всего бессистемно.
30. 1c-intelligence 5994 01.11.18 10:19 Сейчас в теме
(28) проект ведь быстро в текучку превращается, и все приоритеты, расставленные на старте, уплывут в неизвестном направлении.
К тому же, речь вроде в контексте agile идет. А там что-то определять в самом начале и надеяться, что так оно и останется - фу.
35. dm_romanov.idm 01.11.18 10:55 Сейчас в теме
(30)
проект ведь быстро в текучку превращается

Превращать проект в "текучку" это прямой путь к провалу проекта.

А там что-то определять в самом начале и надеяться, что так оно и останется - фу.

А никто и не надеется)). Проект это живой организм и в своем развитии он меняется.
Детально планировать релизы которые выйдут через пару месяцев это ИМХО пустая работа. Но вот текущий и следующий релиз можно и нужно планировать детально
Фичи могут добавляться и удаляться из релиза это совершенно нормально. Но команде просто необходимо видеть фичи которые нужно реализовать, их взаимосвязи между собой, примерное распределение фич между людьми и т.д. Без этого проект действительно превратиться в "текучку".
.
36. 1c-intelligence 5994 01.11.18 11:00 Сейчас в теме
(35)
Но вот текущий и следующий релиз можно и нужно планировать детально

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

Можно, конечно, пользоваться теми приоритетами, которые были расставлены в начале проекта, но это не agile.

И расставлять приоритеты придется постоянно, ну или периодически. И на старые фичи, и на новые. И появляется ненавистный регулярный менеджмент, которым никому не охота заниматься. И главным приоритетом станут голоса куриц.
40. dm_romanov.idm 01.11.18 12:30 Сейчас в теме
(36)
Приоритеты в спринте обычно ставятся без проблем. Просто потому что в спринте 80 процентов взаимосвязанной функциональности, что диктует определенную последовательность выполнения.

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

Для этого есть электронные доски, у менеджера это отнимает меньше 3 минут в день, не каждый день)
41. 1c-intelligence 5994 01.11.18 12:35 Сейчас в теме
(40) ок, ладно, раз трудностей нет, то и спорить не о чем.
4. genayo 31.10.18 08:10 Сейчас в теме
Иногда сделанное не всё сразу остаётся как есть (а в худшем случае и вовсе выбрасывается), тогда мы просто минимизировали бесполезную работу.
14. MariaTemchina 317 31.10.18 11:35 Сейчас в теме
(4) Иногда "сделанное всё" тоже выбрасывается. В этом случае, остановившись на полпути мы действительно минимизировали бесполезную работу.
В идеальной вселенной "сделанное не всё сразу" обкатывается и продолжает доделываться.
История, что "нет ничего более постоянного, чем временное решение" - тоже имеет место быть. Здесь (как и во многих других местах) многое зависит от управленческой воли - оставить "тяп-ляп", или "доделать как следует".
5. VmvLer 31.10.18 08:59 Сейчас в теме
6. Крококот 31.10.18 09:07 Сейчас в теме
Очень интересную тему затронули.
Я лично многократно сталкивался с тем, что рядовому пользователю программа нужна как собаке пятая нога. В самом простом случае ему банально лень переучиваться и покидать зону комфорта.
Поэтому сбор требований вещь важная, но... не будет среднестатистический рядовой пользователь адекватно отвечать на потребность функций. Или ему "все очень надо" (использовать в реальной работе не будет и треть того, что затребовал), или "все равно" (и потом будет устраивать истерики по поводу "совершенно ничего не работает, вот раньше все работало идеально"). На самом деле в момент опроса ему надо чтобы от него отстали побыстрее.
Можно опрашивать некоего "ключевого ответственного пользователя", но он 1.не всегда есть, 2.не всегда достаточно мотивирован на взаимодействие, 3. не всегда владеет информацией в полном объеме.
И все бы ничего, но, как в одной из статей было показано, иногда один только неверный перечень требований заводит внедрение в тупик.
15. MariaTemchina 317 31.10.18 11:43 Сейчас в теме
(6)
программа нужна как собаке пятая нога. В самом простом случае ему банально лень переучиваться и покидать зону комфорта.
Поэтому сбор требований вещь важная, но... не будет среднестатистический рядовой пользователь адекватно отвечать на потребность функций. Или ему "все очень надо" (использовать в реальной работе не будет и треть того, что затребовал), или "все равно" (и потом будет устраивать истерики по поводу "совершенно ничего не работает, вот раньше все работало идеально"). На самом деле в момент опроса ему надо чтобы от него отстали побыстрее.


Соглашусь, есть такая буква в этом слове. Простого и изящного решения я не предложу. Что тут можно сказать?
Во-первых, ищем разнообразные способы мотивации. Готовим сотрудника, чтобы он зарезревировал для нас какое-то время, объясняем ему в чем его профит и т. п.
Во-вторых, вместо того, чтобы говорить красивые слова, даем "пощупать ручками". Скажем, та же 1С в описании Технологии быстрого результата рекомендует начинать с презентационного семинара - то есть показывать возможный функционал, и сразу на месте прикручивать, как это будет выглядеть? Та же технология "Design Thinking" призывает нас моделировать и пробовать решения. Нарисованный интерфейс с кнопочками существенно нагляднее нескольких страниц ТЗ...
20. Крококот 31.10.18 12:15 Сейчас в теме
(15)
Простого и изящного решения я не предложу

Простое решение есть. Не изящное, правда, скорее наоборот.
Требования хорошо актуализируются в реальной работе. Есть такой метод внедрения: запуститься на типовой (ну или несколько адаптированной к наиболее очевидным потребностям предприятия), а потом допиливать то, насчет чего раздаётся больше всего воплей.
Плюсы: требования собираются быстро и эффективно, обратной связи хоть отбавляй.
Минусы: сильный стресс как для работников, так и для внедренцев.
dgoncharova; +1 Ответить
26. dm_romanov.idm 01.11.18 09:32 Сейчас в теме
(20)
После запуска таким способом, внедренцы рискуют оказать погребенными под завалами всплывающих проблем. Что в свою очередь может вызвать неприятие системы и возврат на прошлую систему с соответствующими оргвыводами.

"Все очень надо" - хорошо рубится бюджетом и сроками. Когда руководителю показывают "все очень надо" с расписанным бюджетом этих надо и сроками превышающие запланированные раза в три, очень быстро приходит понимание, что надо не всё, что можно часть отложить и допилить (потом, своими силами, вести в Excel и т.п.). И тут вот как раз Agile помогает максимально быстро выкатить MVP, и затем на MVP уточнить и дособрать требования.
29. Крококот 01.11.18 10:15 Сейчас в теме
(26)
внедренцы рискуют

Есть такая проблема, я о ней написал. Способ сам по себе экстремальный, спору нет.

очень быстро приходит понимание, что надо не всё, что можно часть отложить и допилить

Может получиться примерно схожая ситуация: начальник отбросил реально нужные фичи (вполне реальная ситуация) -> пользователи не могут/не хотят работать без этих фич -> истерика "ничего не работает, мы вам говорили что нам надо, а вы нас игнорировали, нам надо работать - кто ответит за срыв рабочего процесса" -> неприятие системы.
31. dm_romanov.idm 01.11.18 10:36 Сейчас в теме
(29)
Способ начать с типовой тоже применим, но только когда автоматизируемый процесс новый или процесс не устоялся.
Если процесс "устоялся", то уже как минимум есть не типовые отчеты и печатные формы. Могут быть инструменты которые желательно реализовать или предложить им замену в новой системе.

начальник отбросил реально нужные фичи (вполне реальная ситуация)

1. Обязательно собирать требования с сотрудников, которые непосредственно заносят данные в систему. Линейные начальники знают не знают тонкости реального процесса. Сами на это накалывались.
2. Собирать требования под подпись.
3. Если начальник отбрасывает требования необходимые для работы его подчиненных, выносить вопрос на проектный комитет с присутствием более высокого руководства, начальника и подчиненных.

Обычно этот не хитрый алгоритм очень выручает.
33. MariaTemchina 317 01.11.18 10:51 Сейчас в теме
(31) Дополню, что, по моему опыту, когда команда внедренцев демонстрирует, во-первых компетенции в внедряемом продукте, а во-вторых, искреннюю мотивацию сделать продукт действительно нужный заказчику (иногда немного вопреки тому, что он на первом этапе просит) - то решение чаще всего найти получается...
dm_romanov.idm; +1 Ответить
34. Крококот 01.11.18 10:51 Сейчас в теме
(31)
Обычно этот не хитрый алгоритм очень выручает

Не всегда.
Из реального проекта:
1. Собрали требования у линейных сотрудников. Список получился более чем внушительный. Все, что смогли вспомнить, даже если эта фича требовалась один раз года 3 назад.
2. Подписи... разумеется, как же без них. Только потом, когда работать не будет, наличие подписей поможет не сильно. Проверено. "Не работает же..." (с)
3. Бюджет и сроки получились раздутыми. Отбрасывали требования в составе "высокое руководство + начальник". Сотрудников всех звать нереально. Их много, требований очень много, разбирать и анализировать каждое требование со всеми потребует очень много времени и превратится в базар.
В итоге, конечно, были вопли.
38. dm_romanov.idm 01.11.18 12:08 Сейчас в теме
(34)
Тоже из реального проекта:
Разбили требования на блоки. Состав блоков согласовали с высшим руководством. Требования в блоках принимали уже с линейными руководителями и их подчиненными. Накололись: один из линейных руководитель сказал я всё знаю, я всё расскажу. Сделали как рассказал пришлось переделывать.

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

Работает только с теми, кто хочет работать в новой программе и имеет возможность (читай "время") ознакомиться с прототипом. Таких - единицы процентов.
Типовая же ситуация: развернули базу с прототипом и никто туда даже и не думает заходить. Если надавить с помощью руководства - зайдут, потыркают мышкой 5 минут и скажут "все хорошо". Потом, разумеется, начнутся вопли. Подписи не помогут.
Главная проблема тут - мотивация линейного персонала заказчика. Решается крайне тяжело.
42. dm_romanov.idm 01.11.18 12:53 Сейчас в теме
(39)
Типовая же ситуация: развернули базу с прототипом и никто туда даже и не думает заходить.

Естественно, мало кому охота нагружать себя лишней и малопонятной работой.
Даже без должной мотивации у сотрудников, решалось просьбой проверить при нас. Так вы снимаете у человека стресс перед новым, ведь вы рядом, вы выслушаете и объясните. Показываете что будете его контролировать, с него не "слезете" и отвертеться уже не получится. Обычно после двух-трех таких сеансов люди уже тестируют без постоянного контроля.
Сами тоже получаете профит через диалог с пользователем и возможностью посмотреть как он реально работает в вашей системе. Устанавливаете контакт с ним, что улучшает обратную связь.
43. acanta 45 01.11.18 13:13 Сейчас в теме
(42) Нужно уточнить в чем именно работа малопонятна?
45. dm_romanov.idm 01.11.18 14:36 Сейчас в теме
(43)
У пользователя обычно уже есть система (Excel, бумажные документы или старая система), он в неё в носит данные. Тут ему от руководство приходит приказ, зайди посмотри, проверь как там в новой.

И тут у пользователя возникают вопросы:
Что проверять?
Как проверять?
На что обратить внимание?
Сколько проверять?
Что тут вообще творится? (Обычно про незнакомый интерфейс или измененный бизнес-процесс)))

Результат: работа по тестированию воспринимается как малопонятная.
17. acanta 45 31.10.18 11:57 Сейчас в теме
Имхо "все надо" = "оставьте меня в покое".
Ценность Agile не в том, что он дает клиенту нечто ценное, а в том, что это позволяет ему в любой удобный момент избавиться от назойливых внедренцев. Делайте. Сделали - уходите. Понадобитесь - позовут. Позвали - делайте как можно быстрее и уходите не задерживайтесь.
Внедренцы на предприятии - это чужие люди, посторонние. Своими они никогда не станут, что бы ни говорили о лояльности и постоянных клиентах. И это не просто зона комфорта - это безопасность.
Это главное чего не дает водопад.
18. MariaTemchina 317 31.10.18 12:04 Сейчас в теме
(17)

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

Ну почему же никогда? Часто их переманивают остаться в штате у заказчика ))))
19. acanta 45 31.10.18 12:12 Сейчас в теме
Завуалированный конкурсный отбор (тестовое задание этак на годик другой) - иллюзия. Бытует мнение то что человек для себя будет делать более качественно, чем для других (в колхоз) и что если РП/архитектор внедренцев делает что-то хорошо, то он это обязательно рассчитывает после завершения проекта "осесть" на этом теплом месте в виде ИТ-директора или на худой конец программиста в штат.
На моем опыте наиболее качественно делают для того чтобы никогда больше не пересекаться с этими клиентами. Это подход продажи готовой продукции.
Любые доработки в дальнейшем - это работа по претензии, даже если это штатное обновление. Чем реже, тем лучше для всех.
21. MariaTemchina 317 31.10.18 12:18 Сейчас в теме
(19)
На моем опыте наиболее качественно делают для того чтобы никогда больше не пересекаться с этими клиентами.

Жизненно, спасибо.
22. acanta 45 31.10.18 12:28 Сейчас в теме
К сожалению, даже из докладов на Инфостарте вырисовывался странный подход. Функциональное моделирование (типовая/отраслевая конфигурация из коробки) преподносится как конечный продукт, и мы начинаем работу с клиентом с фразы "к пуговицам претензии есть?". Это для меня непонятно.
Внедрение больше не продается как продукт/услуга?
Стоимость коробочного решения включает в себя стоимость внедрения минимального? полного? первый этап Agile? разработку ТЗ на водопад?
Это непонятно клиенту.
27. acanta 45 01.11.18 09:56 Сейчас в теме
Взаимосвязи. Курица или яйцо. Если для того чтобы сделать небольшой участок требуется отработать всю цепочку, то как часть цепочки этот участок может быть незначительным и стоить недорого. А если заявить это как цель проекта и собрать на него стоимость внедрения всех взаимосвязей, то может оказаться что вообще зря пришли.
32. MariaTemchina 317 01.11.18 10:47 Сейчас в теме
(27) Всё-таки обычно целесообразно заявлять как финальную цель полную картинку, даже если она входит не в первый, а в двадцать пятый релиз. И отдавать себе отчёт, что вкладываясь на старте в проектирование и архитектуру всей системы, мы держим в голове конечную цель, а не только самый первый участок, который мы будем делать в первую очередь. Тогда экономическая целесообразность становится очевиднее.
37. acanta 45 01.11.18 11:33 Сейчас в теме
Уточнение. Команда внедренцев не делает продукт, действительно нужный заказчику. Команда внедренцев в лучшем случае ударным трудом создает удовлетворение потребностей заказчика при помощи какого либо продукта. Если это будет калькулятор и пачка бумаги значит калькулчтором и пачкой бумаги.
44. Rustig 1020 01.11.18 13:19 Сейчас в теме
(0)
Меня, кстати, можно поздравить с получением сертификата PMI-ACP (Agile Certified Practitioner).

Поздравляю! Вы настоящий Профи! Сужу по изложению мыслей и содержанию статей.
46. acanta 45 01.11.18 14:44 Сейчас в теме
Адвокат не должен задавать вопросы, на которые он не знает ответа (с)
А какие вопросы возникают у консультанта?
Открываем журнал документов "...". Открываем "табличку 1 EXСEL"
Вносим ВРУЧНУЮ данные от сих до сих.
У нас с вами в результате должна получиться табличка "вот этот отчетик" в 1с ПОХОЖАЯ на вашу Табличку 2 EXСEL и мы проверяем итого.
Если в вашей табличке выведена аналитика и остатки, то копия отчетика из 1с сохраняется в EXСEL и методом это-минус-это получаем где не сошлось.
Случай, когда методом это-минус-это нельзя найти ошибки означает неправильную постановку задачи и мы начинаем все сначала.

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

Простенько, примитивно. Между вопросом 1 и вопросом 2 консультанта может пройти несколько дней. Но если он не будет задан, ответа точно не получим.
Вопрос 1 может быть исключен переносом данных если они есть и сразу консультант переходит к отклонениям.
Проблемы ручного ввода данных останутся другим консультантам после фактического перехода.

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