Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2025 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Хочу поделиться ссылкой на интересную статью по приоритизации
Вот такой вопрос есть. Есть хребет, скелет и мясо проекта. Мы сделали хребет, можно приступать к скелету, но тут понимаем, что мясо мы сделаем гораздо быстрее, буквально за пару дней, а на скелет надо потратить месяц. Как поступить в такой ситуации?
Ну например, пишем конфигурацию, основной функционал готов — справочники, документы, регистры, это наш хребет. Следующим этапом надо реализовать обмены, это наш скелет. Но есть мелкие доработки, вроде автоматического заполнения цен в документах, каких-то печатных форм и прочей мелочи.
И вот я понимаю, что на обмены потрачу много времени, но при этом могу до этой работы доделать сначала всякую мелочь и вроде как получается, что я мясо делаю раньше скелета.
Или я просто не понимаю в чем суть разделения этапов работ и мелкие доработки сюда вообще не относятся?
как вам:
1. Матрица Эйзенхауэра;
2. .
Иногда сделанное не всё сразу остаётся как есть (а в худшем случае и вовсе выбрасывается), тогда мы просто минимизировали бесполезную работу.
маркетолог детектед
Очень интересную тему затронули.
Я лично многократно сталкивался с тем, что рядовому пользователю программа нужна как собаке пятая нога. В самом простом случае ему банально лень переучиваться и покидать зону комфорта.
Поэтому сбор требований вещь важная, но… не будет среднестатистический рядовой пользователь адекватно отвечать на потребность функций. Или ему «все очень надо» (использовать в реальной работе не будет и треть того, что затребовал), или «все равно» (и потом будет устраивать истерики по поводу «совершенно ничего не работает, вот раньше все работало идеально»). На самом деле в момент опроса ему надо чтобы от него отстали побыстрее.
Можно опрашивать некоего «ключевого ответственного пользователя», но он 1.не всегда есть, 2.не всегда достаточно мотивирован на взаимодействие, 3. не всегда владеет информацией в полном объеме.
И все бы ничего, но, как в одной из статей было показано, иногда один только неверный перечень требований заводит внедрение в тупик.
(2) в чем смысл «мяса» для заказчка если не готов скелет проекта?
(7) Это просто удобство. Я же не говорю, что мясо важнее (работать в базе можно и без мяса и без скелета, главное хребет), просто я сделаю его за день и можно если что показать заказчику, работа идет, все в порядке
(8) Мне кажется тут нужно разговаривать с заказчиком, если данное «мясо» ему приоритетнее , и оно будет работать то да
Так как тут можно наткнуться в необходимость переделывать «мясо» уже после создания скелета, в таком случае кто то должен взять на себя эти затраты, и заказчик наверное подумает что это вы за свой счет все переделаете, и скорее всего это будет так либо это будет неудачный проект.
(9) Нет, именно в том и суть, что не приоритетнее. Но вот мы с заказчиком смотрим хребет и он просит сделать пару мелочей из мяса, они не в приоритете, просто попросили именно сейчас и мне чтобы это сделать надо очень мало ресурсов, но по логике статьи я должен отложить эту работу, которая займет у меня несколько часов на несколько недель, потому что приоритет там ниже.
И вроде это правильно, но как то очень непривычно.
(1) Спасибо! Действительно, собрали основные техники в одном месте, удобно.
(2) Смотрите, общая идея Agile в том, что мы пытаемся как можно сильнее сократить так называемую «петлю обратной связи» — то есть выпустить промежуточный результат в опытную эксплуатацию. Это позволит увидеть нюансы и риски, которые мы не учли.
То есть фокус внимания — на получении работающего результата как можно раньше. Из этих соображений и стоит начинать с «хребта», потом переходить к «скелету», и только потом — к «мясу».
Может ли быть ситуация, когда по каким-то причинам целесообразнее сделать сначала «мясо», потом «скелет» (например, потому что для «скелета» недостаточно информации собрано)? — Может. Вообще, любая ситуация может случиться, да и Agile — не панацея.
Суть рекомендаций в том, что мы по возможности стремимся реализовывать принцип «Дельфины вместо китов» — то есть вместо больших громоздких проектов делать маленькие — это позволяет минимизировать риски, уточнять требования, уменьшать шансы долгостроя, и так далее. Ключевое слово — «по возможности».
(3)
1. Матрица Эйзенхауэра — мне хорошо, спасибо.
2. Стратегический эквалайзер — интересно, прочитала с любопытством. Финал статьи почему-то напомнил историю про обезьянку прокрастинации…
Но это про принятия решения исходя из личных мотивов разработчика… А я скорее разбираю мотивы пользователей, которые задачи ставят.
(4) Иногда «сделанное всё» тоже выбрасывается. В этом случае, остановившись на полпути мы действительно минимизировали бесполезную работу.
В идеальной вселенной «сделанное не всё сразу» обкатывается и продолжает доделываться.
История, что «нет ничего более постоянного, чем временное решение» — тоже имеет место быть. Здесь (как и во многих других местах) многое зависит от управленческой воли — оставить «тяп-ляп», или «доделать как следует».
(6)
Поэтому сбор требований вещь важная, но… не будет среднестатистический рядовой пользователь адекватно отвечать на потребность функций. Или ему «все очень надо» (использовать в реальной работе не будет и треть того, что затребовал), или «все равно» (и потом будет устраивать истерики по поводу «совершенно ничего не работает, вот раньше все работало идеально»). На самом деле в момент опроса ему надо чтобы от него отстали побыстрее.
Соглашусь, есть такая буква в этом слове. Простого и изящного решения я не предложу. Что тут можно сказать?
Во-первых, ищем разнообразные способы мотивации. Готовим сотрудника, чтобы он зарезревировал для нас какое-то время, объясняем ему в чем его профит и т. п.
Во-вторых, вместо того, чтобы говорить красивые слова, даем «пощупать ручками». Скажем, та же 1С в описании Технологии быстрого результата рекомендует начинать с презентационного семинара — то есть показывать возможный функционал, и сразу на месте прикручивать, как это будет выглядеть? Та же технология «Design Thinking» призывает нас моделировать и пробовать решения. Нарисованный интерфейс с кнопочками существенно нагляднее нескольких страниц ТЗ…
(12) Так понятнее, спасибо
Имхо «все надо» = «оставьте меня в покое».
Ценность Agile не в том, что он дает клиенту нечто ценное, а в том, что это позволяет ему в любой удобный момент избавиться от назойливых внедренцев. Делайте. Сделали — уходите. Понадобитесь — позовут. Позвали — делайте как можно быстрее и уходите не задерживайтесь.
Внедренцы на предприятии — это чужие люди, посторонние. Своими они никогда не станут, что бы ни говорили о лояльности и постоянных клиентах. И это не просто зона комфорта — это безопасность.
Это главное чего не дает водопад.
(17)
Внедренцы на предприятии — это чужие люди, посторонние. Своими они никогда не станут, что бы ни говорили о лояльности и постоянных клиентах.
Ну почему же никогда? Часто их переманивают остаться в штате у заказчика ))))
Завуалированный конкурсный отбор (тестовое задание этак на годик другой) — иллюзия. Бытует мнение то что человек для себя будет делать более качественно, чем для других (в колхоз) и что если РП/архитектор внедренцев делает что-то хорошо, то он это обязательно рассчитывает после завершения проекта «осесть» на этом теплом месте в виде ИТ-директора или на худой конец программиста в штат.
На моем опыте наиболее качественно делают для того чтобы никогда больше не пересекаться с этими клиентами. Это подход продажи готовой продукции.
Любые доработки в дальнейшем — это работа по претензии, даже если это штатное обновление. Чем реже, тем лучше для всех.
(15)
Простое решение есть. Не изящное, правда, скорее наоборот.
Требования хорошо актуализируются в реальной работе. Есть такой метод внедрения: запуститься на типовой (ну или несколько адаптированной к наиболее очевидным потребностям предприятия), а потом допиливать то, насчет чего раздаётся больше всего воплей.
Плюсы: требования собираются быстро и эффективно, обратной связи хоть отбавляй.
Минусы: сильный стресс как для работников, так и для внедренцев.
(19)
Жизненно, спасибо.
К сожалению, даже из докладов на Инфостарте вырисовывался странный подход. Функциональное моделирование (типовая/отраслевая конфигурация из коробки) преподносится как конечный продукт, и мы начинаем работу с клиентом с фразы «к пуговицам претензии есть?». Это для меня непонятно.
Внедрение больше не продается как продукт/услуга?
Стоимость коробочного решения включает в себя стоимость внедрения минимального? полного? первый этап Agile? разработку ТЗ на водопад?
Это непонятно клиенту.
(13) про личные мотивы разработчика там просто для понятности приведено. Вообще, метод, который лежит в основе, рассчитан на ранжирование задач согласно интересам компании, а не исполнителей этих задач.
Кто именно двигает ползунки эквалайзера — не важно.
Но вообще, проблема приоритетов, по моему опыту, всегда в одном — никто не хочет париться с их постоянной расстановкой, независимо от выбранной системы координат. Это же область регулярного менеджмента — неважно, проекта, отдела, организации или тех.поддержки.
(23) Интересы компании — это интересы девушки, которая вышла из отпуска по уходу за ребенком через 9 лет.
Она не может двигать никакой эквалайзер, и она единственная кто заинтересован вернуться на свое место работы на зарплату с уровнем рыночной при реальной утрате квалификации. Все остальные в этом не заинтересованы, даже регулярный менеджмент.
(24) звучит красиво, но не знаю, как это применить на практике — метафору вашу, в смысле.
Вот я пользуюсь эквалайзером для управления и компанией, и проектами, и задачами.
Со мной что-то не так?
(20)
После запуска таким способом, внедренцы рискуют оказать погребенными под завалами всплывающих проблем. Что в свою очередь может вызвать неприятие системы и возврат на прошлую систему с соответствующими оргвыводами.
«Все очень надо» — хорошо рубится бюджетом и сроками. Когда руководителю показывают «все очень надо» с расписанным бюджетом этих надо и сроками превышающие запланированные раза в три, очень быстро приходит понимание, что надо не всё, что можно часть отложить и допилить (потом, своими силами, вести в Excel и т.п.). И тут вот как раз Agile помогает максимально быстро выкатить MVP, и затем на MVP уточнить и дособрать требования.
Взаимосвязи. Курица или яйцо. Если для того чтобы сделать небольшой участок требуется отработать всю цепочку, то как часть цепочки этот участок может быть незначительным и стоить недорого. А если заявить это как цель проекта и собрать на него стоимость внедрения всех взаимосвязей, то может оказаться что вообще зря пришли.
(23)
Но Мария пишет не о приоритизации текучки, а о проектах. Во всех проектах в которых участвовал, то что войдет в первый и последующие релизы, являлось бурной темой для обсуждения. Заинтересованные люди очень активно принимали участие в установке приоритетов. Проблемы что кто-то «парился» с их расстановкой не было.
А вот на текучку никто не хочет расставлять приоритеты. Пользователи, принимают приоритет по умолчанию или ставят самый высокий, низкий на моей памяти никто из пользователей никогда не ставил)). Начальство и программисты делают это чаще всего бессистемно.
(26)
Есть такая проблема, я о ней написал. Способ сам по себе экстремальный, спору нет.
Может получиться примерно схожая ситуация: начальник отбросил реально нужные фичи (вполне реальная ситуация) -> пользователи не могут/не хотят работать без этих фич -> истерика «ничего не работает, мы вам говорили что нам надо, а вы нас игнорировали, нам надо работать — кто ответит за срыв рабочего процесса» -> неприятие системы.
(28) проект ведь быстро в текучку превращается, и все приоритеты, расставленные на старте, уплывут в неизвестном направлении.
К тому же, речь вроде в контексте agile идет. А там что-то определять в самом начале и надеяться, что так оно и останется — фу.
(29)
Способ начать с типовой тоже применим, но только когда автоматизируемый процесс новый или процесс не устоялся.
Если процесс «устоялся», то уже как минимум есть не типовые отчеты и печатные формы. Могут быть инструменты которые желательно реализовать или предложить им замену в новой системе.
1. Обязательно собирать требования с сотрудников, которые непосредственно заносят данные в систему. Линейные начальники знают не знают тонкости реального процесса. Сами на это накалывались.
2. Собирать требования под подпись.
3. Если начальник отбрасывает требования необходимые для работы его подчиненных, выносить вопрос на проектный комитет с присутствием более высокого руководства, начальника и подчиненных.
Обычно этот не хитрый алгоритм очень выручает.
(27) Всё-таки обычно целесообразно заявлять как финальную цель полную картинку, даже если она входит не в первый, а в двадцать пятый релиз. И отдавать себе отчёт, что вкладываясь на старте в проектирование и архитектуру всей системы, мы держим в голове конечную цель, а не только самый первый участок, который мы будем делать в первую очередь. Тогда экономическая целесообразность становится очевиднее.
(31) Дополню, что, по моему опыту, когда команда внедренцев демонстрирует, во-первых компетенции в внедряемом продукте, а во-вторых, искреннюю мотивацию сделать продукт действительно нужный заказчику (иногда немного вопреки тому, что он на первом этапе просит) — то решение чаще всего найти получается…
(31)
Не всегда.
Из реального проекта:
1. Собрали требования у линейных сотрудников. Список получился более чем внушительный. Все, что смогли вспомнить, даже если эта фича требовалась один раз года 3 назад.
2. Подписи… разумеется, как же без них. Только потом, когда работать не будет, наличие подписей поможет не сильно. Проверено. «Не работает же…» (с)
3. Бюджет и сроки получились раздутыми. Отбрасывали требования в составе «высокое руководство + начальник». Сотрудников всех звать нереально. Их много, требований очень много, разбирать и анализировать каждое требование со всеми потребует очень много времени и превратится в базар.
В итоге, конечно, были вопли.
(30)
Превращать проект в «текучку» это прямой путь к провалу проекта.
А никто и не надеется)). Проект это живой организм и в своем развитии он меняется.
Детально планировать релизы которые выйдут через пару месяцев это ИМХО пустая работа. Но вот текущий и следующий релиз можно и нужно планировать детально
Фичи могут добавляться и удаляться из релиза это совершенно нормально. Но команде просто необходимо видеть фичи которые нужно реализовать, их взаимосвязи между собой, примерное распределение фич между людьми и т.д. Без этого проект действительно превратиться в «текучку».
.
(35)
вот это я и называю «превращать в текучку». Другими словами, рутинная, периодическая работа по управлению проектом. И в этой рутинной, периодической работе есть такой пункт — «определение приоритетов» и, соответственно, «выбор задач на спринт» (исходя из приоритетов).
Можно, конечно, пользоваться теми приоритетами, которые были расставлены в начале проекта, но это не agile.
И расставлять приоритеты придется постоянно, ну или периодически. И на старые фичи, и на новые. И появляется ненавистный регулярный менеджмент, которым никому не охота заниматься. И главным приоритетом станут голоса куриц.
Уточнение. Команда внедренцев не делает продукт, действительно нужный заказчику. Команда внедренцев в лучшем случае ударным трудом создает удовлетворение потребностей заказчика при помощи какого либо продукта. Если это будет калькулятор и пачка бумаги значит калькулчтором и пачкой бумаги.
(34)
Тоже из реального проекта:
Разбили требования на блоки. Состав блоков согласовали с высшим руководством. Требования в блоках принимали уже с линейными руководителями и их подчиненными. Накололись: один из линейных руководитель сказал я всё знаю, я всё расскажу. Сделали как рассказал пришлось переделывать.
Также помогает: показывать прототипы как можно раньше тем кто будет с ним работать. Тут всплывают недомолвки, непонимания, удаляются хотелки которые не нужны.
(38)
Работает только с теми, кто хочет работать в новой программе и имеет возможность (читай «время») ознакомиться с прототипом. Таких — единицы процентов.
Типовая же ситуация: развернули базу с прототипом и никто туда даже и не думает заходить. Если надавить с помощью руководства — зайдут, потыркают мышкой 5 минут и скажут «все хорошо». Потом, разумеется, начнутся вопли. Подписи не помогут.
Главная проблема тут — мотивация линейного персонала заказчика. Решается крайне тяжело.
(36)
Приоритеты в спринте обычно ставятся без проблем. Просто потому что в спринте 80 процентов взаимосвязанной функциональности, что диктует определенную последовательность выполнения.
Для этого есть электронные доски, у менеджера это отнимает меньше 3 минут в день, не каждый день)
(40) ок, ладно, раз трудностей нет, то и спорить не о чем.
(39)
Естественно, мало кому охота нагружать себя лишней и малопонятной работой.
Даже без должной мотивации у сотрудников, решалось просьбой проверить при нас. Так вы снимаете у человека стресс перед новым, ведь вы рядом, вы выслушаете и объясните. Показываете что будете его контролировать, с него не «слезете» и отвертеться уже не получится. Обычно после двух-трех таких сеансов люди уже тестируют без постоянного контроля.
Сами тоже получаете профит через диалог с пользователем и возможностью посмотреть как он реально работает в вашей системе. Устанавливаете контакт с ним, что улучшает обратную связь.
(42) Нужно уточнить в чем именно работа малопонятна?
(0)
Поздравляю! Вы настоящий Профи! Сужу по изложению мыслей и содержанию статей.
(43)
У пользователя обычно уже есть система (Excel, бумажные документы или старая система), он в неё в носит данные. Тут ему от руководство приходит приказ, зайди посмотри, проверь как там в новой.
И тут у пользователя возникают вопросы:
Что проверять?
Как проверять?
На что обратить внимание?
Сколько проверять?
Что тут вообще творится? (Обычно про незнакомый интерфейс или измененный бизнес-процесс)))
Результат: работа по тестированию воспринимается как малопонятная.
Адвокат не должен задавать вопросы, на которые он не знает ответа (с)
А какие вопросы возникают у консультанта?
Открываем журнал документов «…». Открываем «табличку 1 EXСEL»
Вносим ВРУЧНУЮ данные от сих до сих.
У нас с вами в результате должна получиться табличка «вот этот отчетик» в 1с ПОХОЖАЯ на вашу Табличку 2 EXСEL и мы проверяем итого.
Если в вашей табличке выведена аналитика и остатки, то копия отчетика из 1с сохраняется в EXСEL и методом это-минус-это получаем где не сошлось.
Случай, когда методом это-минус-это нельзя найти ошибки означает неправильную постановку задачи и мы начинаем все сначала.
Возникли ли ошибки/проблемы в режиме ввода данных, все ли данные есть? Совпало итого или нет?
Включаем фильтр по отклонениям. Сколько их и почему они возникли?
Простенько, примитивно. Между вопросом 1 и вопросом 2 консультанта может пройти несколько дней. Но если он не будет задан, ответа точно не получим.
Вопрос 1 может быть исключен переносом данных если они есть и сразу консультант переходит к отклонениям.
Проблемы ручного ввода данных останутся другим консультантам после фактического перехода.
Самое сложное это заставить пользователей думать о проблемах консультантов. Я бы даже сказала что это невозможно.
А вот определиться чья конкретно это проблема вполне возможно, на уровне руководства.
(42)
Даже без должной мотивации у сотрудников, решалось просьбой проверить при нас. Так вы снимаете у человека стресс перед новым, ведь вы рядом, вы выслушаете и объясните. Показываете что будете его контролировать, с него не «слезете» и отвертеться уже не получится. Обычно после двух-трех таких сеансов люди уже тестируют без постоянного контроля.
Вот да, надежный способ! Поддерживаю…