Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2026 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Очень знакомо. И самый финиш когда мсо стороны заказчика принять стратегическое решение и продавливать его не кому))
(1) katenok86 — да, история знакомая. Вообще, очень часто запрос от клиента поступает на автоматизацию бизнес-процессов. А в действительности, при первом же взгляде на ситуацию аналитику становится понятно, что процессы-то прежде чем автоматизировать нужно банально выстроить, потому что они существуют в организации весьма условно. А, как выражаются менеджеры Сбербанка «автоматизированный хаос — это быстрый хаос!»… А выстроить бизнес-процессы у компании заказчика команда внедренцев ну никак не может…
(2)
Личный опыт говорит, что попытка автоматизации хаоса приводит к хаосу. Он не лучше и не хуже первоначального. Однако, в некоторых случаях визит представителя ИТ отдела в производственное подразделение приводит к тому, что люди понимают, что им нужен регламент работы, хотя бы его концепция, т.к. любой язык программирования достаточно формализован. Вот тогда ИТ может выступить в роли эксперта со стороны и помочь решить вопрос неопределенности. ИМХО.
(3) Silenser — вы привели удачный пример, спасибо. В моей практике тоже бывали случаи, когда система была готова к большей организованности, ей не хватало только удачного инструмента — и дальше ухватившись за необходимость прописать процедуру в ходе автоматизации, в дальнейшем ей начинали следовать и все были в выигрыше. Но, к сожалению, несколько чаще приходилось встречаться со случаями, когда организация вкладывает гигантские деньги во внедрение, допустим, MS Project’а, закупается ПО, пишутся регламенты, проводится обучение… И дальше все это кончается полным провалом, увольнением ответственных за внедрение и боьшим скандалом. Ибо менеджеры пишут в проджекте, что им в голову придет, планировать продолжают на коленке (или в чем они планировали). См. комикс в аттаче…
(4) Перевод комикса для тех, кто не владеет английским:
— Привет! Я из АйТи департамента и хочу спросить, насколько наша новая CRM-система упрощает вашу работу?
— Я рад, что ты спрашиваешь. Раньше, до того как появилась новая система, мне приходилось держать все мои контакты, письма, продажи и т. п. в куче разрозненных листов Excel. Но теперь, с тех пор как мы должны использовать новую CRM-систему…
… Мне приходится каждую неделю перебивать все записи из моих листов в новую систему, чтобы сделать вид, что я ею пользуюсь…
(4) Весьма жизненно 🙂
Хм, мне показалось что «кейсы» выхватили лишь какие-то отдельные принципы Agile. Но суть Agile именно в применении всей совокупности принципов, а основная сложность внедрения — в изменении ценностей и способа мышления сотрудников. В противном случае, как пишут авторы книг по гибким технологиям, мы получаем «больше чем ничего».
(7) Да, firma111, вам совершенно правильно показалось. Даже авторы книг по гибким технологиям признают, что на практике имеет право на существование такая вещь как «гибридные методы».
(6)О да, еще как! )))
Системы это хорошо. Но почему они работают, на какие тонкие струны души и тела они давят?
(10) Ах, Manoshkin… Это всегда непростой и немного философский вопрос — почему что-то работает так, как работает?.. Или наоборот, не работает так как должно?.. Недаром японцы считают управление проектами сочетанием науки и искусства…
(11) Японцы — вообще очень странный народ…
(12) Это точно. Но впахивать они умеют, этого у них не отнимешь…
Добавлю ложечку дегтя в эту статью меда.
Если вы читали статьи отцов-основателей Agile то наверняка обращали внимание — они прямо с порога говорят:
Главное в Agile (как и любой другой) — это команда
Без нее все манифесты — это просто набор бумаги
Так вот как раз японцы к командной работе готовы из коробки и для них все Agile манифесты это просто констатация факта
Как для нормального человека сказать что суп надо есть ложкой — он это и так знает с детства
А в наших реалиях как раз отсутствие команды и превращает Agile в набор красивых бумажек наклееных на доску
(14) Угу, capitan, не могу не согласиться.
Одно из ключевых ограничений Agile — он работает в команде замотивированных профессионалов. Нет команды замотивированных профессионалов — Agile не будет работать, увы.
Но это не повод не пытаться такую команду собрать и запустить. Ибо если получается — овчинка стоит выделки, еще как!..
Внедрите нам новую систему, но чтобы всё было как в старой.
да и все 700 отчетов чтобы такие же были, они все «очень» нужны
(16) Да, Serg O. — очень знакомо. В этой ситуации заказчики, скорее всего, сами не задумываются, что же представляет для бизнеса ценность, а что нужно только «для галочки». Ну, и как результат, не могут конструктивно обсуждать это с командой внедрения…
(10) системы выстреливают (то есть работают) благодаря профи, который их внедряет (использует).
К нам-автоматизаторам часто приходят так: «скажите как правильно» и начинается самое веселое. Я сейчас (апрель 19-го года) навнедрявшись и напроваливаливавшись проектов в том числе по гибким методологиям понимаю и пытаюсь в этом убеждать руководство и Заказчиков (работаю в консалтинге), что правильно работать по следующему алггоритму: если клиент новый — предлагаем внедрение Системы по Водопаду и, сделав что-нибудь маленькое, например, экспресс-диагностику за пару недели, понимаем специфику Заказчика, а поняв можно ли на этом Заказчике (Клиенте) использовать Agile или документы — наше все.