.limbo
Надо быстро запустить новую систему, чтобы уже начать ей пользоваться. Очень нужны единые правила, целостность и прослеживаемость данных. Удается запустить её за несколько месяцев, но, кроме концепции границ со списком желаемых функций, на вход в разработку не было передано больше контекста. На приемке ключевыми пользователями было отмечено, что требования из документа идеально реализованы в ПО, но есть загвоздка: для полноценной работы в бизнес-процессах возможностей системы недостаточно
Каждый участник начинает докладывать в бэклог свой опыт, привычки и вкус. Каждый кусочек по приоритету появляется в системе последовательно.
Система быстро превращается в лоскутное одеяло, где причина странно "сшитой" конструкции очевидна: никто не оценивает совместимость всех кусочков между собой. Это не интересно разработке, не является задачей пользователей, а у менеджера не хватает времени подумать обо всём
Бэклог растёт, релизы продолжаются, но всё те же целостность и прослеживаемость данных, потребности, ради которых система появилась, не становятся ближе. Наоборот, система обрастает багами и коллизиями, которые начинают "врастать" в бизнес-процессы. Люди работают не от целей и задач, а от возможностей системы.
Теперь релиз и фиксы могут остановить работу отделов на недели. Онбординг в базовое поведение системы и ее возможностей занимает от 6 до 8 месяцев. Пользователи начинают работать в офисном пакете программ, чатах, на бумаге или просто на звонках, а переносят данные в систему только когда они уже полностью в них уверены. Таблица и электронный лист понятен всем и позволяют исправлять свои ошибки, а не наказывают за них.
К стейкхолдерам приходят узнать, почему они медленно справляются, а ошибок не становится меньше.
Они подробно рассказывают, почему система плохая.
К разработчикам приходят спросить, почему же система не удовлетворяет пользователей, хотя есть бэклог и обратная связь. Разработчики очень подробно объясняют, что стейкхолдеры не рассказывают о своей работе, но диктуют как разработке делать свою.
Нанимают аналитика исследовать потребности, описывать процессы, управлять требованиями, ставить задачи в разработку и визуализировать данные. Всё становится ещё чуточку хуже.
Онбординг в компании — 3 месяца, онбординг в системе — 6–8 месяцев, онбординг в процессы разработки и стейкхолдеров — ещё время. Но релизы продолжаются, бэклог растёт.
Аналитик учит контекст компании и профильные навыки по ночам, чтобы утром своими действиями не увеличивать технический долг.
Менеджер почти сразу передает свою ответственность аналитику, потому что устал еще 3 года назад. Полномочия не передались, поэтому разработка из набора требований от аналитика делает только то, что ей легче сделать, а не что действительно нужно стейкхолдерам. Техдолг растет всё равно. CSAT продолжает падать.
Выпуск релизов замедлился, стейкхолдеры злятся. Пользователям слишком тяжело поддерживать процессы и в системе, и в своих файлах одновременно.
Нанимаются новые сотрудники, чтобы снизить нагрузку с ключевых опытных специалистов. Времени передавать знания и компетенции нет. Всё становится ещё чуточку хуже.
Бюджет испаряется, появляются предпосылки реструктуризации и "мягких" сокращений. Каждый отдел старается загрузить опытных сотрудников работой больше, потому что только они завозят результат. Носители знаний и компетенций не выдерживают. Остались недавно нанятые и давно уставшие. Ничего не понятно, очень нужны единые правила, целостность и прослеживаемость данных.
Надо быстро запустить новую систему, чтобы уже начать ей пользоваться. Очень нужны единые правила, целостность и прослеживаемость данных. Удается запустить её за несколько месяцев, но, кроме концепции границ со списком желаемых функций, на вход в разработку не было передано больше контекста. На приемке ключевыми пользователями было отмечено, что требования из документа идеально реализованы в ПО, но есть загвоздка: для полноценной работы в бизнес-процессах возможностей системы недостаточно
– Доработаем!
Каждый участник начинает докладывать в бэклог свой опыт, привычки и вкус. Каждый кусочек по приоритету появляется в системе последовательно.
Система быстро превращается в лоскутное одеяло, где причина странно "сшитой" конструкции очевидна: никто не оценивает совместимость всех кусочков между собой. Это не интересно разработке, не является задачей пользователей, а у менеджера не хватает времени подумать обо всём
– Будем стараться лучше!
Бэклог растёт, релизы продолжаются, но всё те же целостность и прослеживаемость данных, потребности, ради которых система появилась, не становятся ближе. Наоборот, система обрастает багами и коллизиями, которые начинают "врастать" в бизнес-процессы. Люди работают не от целей и задач, а от возможностей системы.
Теперь релиз и фиксы могут остановить работу отделов на недели. Онбординг в базовое поведение системы и ее возможностей занимает от 6 до 8 месяцев. Пользователи начинают работать в офисном пакете программ, чатах, на бумаге или просто на звонках, а переносят данные в систему только когда они уже полностью в них уверены. Таблица и электронный лист понятен всем и позволяют исправлять свои ошибки, а не наказывают за них.
К стейкхолдерам приходят узнать, почему они медленно справляются, а ошибок не становится меньше.
Они подробно рассказывают, почему система плохая.
К разработчикам приходят спросить, почему же система не удовлетворяет пользователей, хотя есть бэклог и обратная связь. Разработчики очень подробно объясняют, что стейкхолдеры не рассказывают о своей работе, но диктуют как разработке делать свою.
– Исправим!
Нанимают аналитика исследовать потребности, описывать процессы, управлять требованиями, ставить задачи в разработку и визуализировать данные. Всё становится ещё чуточку хуже.
Онбординг в компании — 3 месяца, онбординг в системе — 6–8 месяцев, онбординг в процессы разработки и стейкхолдеров — ещё время. Но релизы продолжаются, бэклог растёт.
Аналитик учит контекст компании и профильные навыки по ночам, чтобы утром своими действиями не увеличивать технический долг.
Менеджер почти сразу передает свою ответственность аналитику, потому что устал еще 3 года назад. Полномочия не передались, поэтому разработка из набора требований от аналитика делает только то, что ей легче сделать, а не что действительно нужно стейкхолдерам. Техдолг растет всё равно. CSAT продолжает падать.
Выпуск релизов замедлился, стейкхолдеры злятся. Пользователям слишком тяжело поддерживать процессы и в системе, и в своих файлах одновременно.
Нанимаются новые сотрудники, чтобы снизить нагрузку с ключевых опытных специалистов. Времени передавать знания и компетенции нет. Всё становится ещё чуточку хуже.
Бюджет испаряется, появляются предпосылки реструктуризации и "мягких" сокращений. Каждый отдел старается загрузить опытных сотрудников работой больше, потому что только они завозят результат. Носители знаний и компетенций не выдерживают. Остались недавно нанятые и давно уставшие. Ничего не понятно, очень нужны единые правила, целостность и прослеживаемость данных.
– Надо быстро запустить новую систему!