#custdev #продукт #мысливслух #капитаннеочевидность #мойопыт #гос
Кастдев в гос продуктах.
Меня спросили, что такое кастдев в гос продуктах. Я задумалась. Мне всегда казалось, что эти два слова не совместимы. Глубинное интервью, исследования и гос продукты.
Начала расспрашивать людей вокруг и сама делать выводы. Из опыта могу сказать, что часто были интервью именно сбора требований. И ведь действительно аналитик, работая бок-о-бок с заказчиком понимает и боль, и что необходимо сделать, хотя и не знает, что такое кастдев. И имеет совсем другое мышление.
Но если говорить про кастдев в госах, то он возможен и он есть. Но в строго определенных условиях:
1. Это продукты, где есть явный пользователь, которому можно позвонить и узнать "боль". Пример, госпорталы. Если мне, как пользователю госулуг, зададут вопрос, что не так? Боль польётся рекой!
2. Сложно говорить про пользователей, если это сотрудники компаний. Они понимают, что говори не говори, всё тлен. У них регламент и жёсткие правила поведения. Поэтому их разговорить крайне трудно. Один из моих однокурсников в ВШЭ (респект ему) научился собирать обратную связь путем проведения вебинаров для сотрудников. И из этого делать выводы про реальную боль. Часто хватает прочтения регламента и наблюдения за тем как работают люди.
3. И самый интересный пункт. Это понимание боли руководства и не только, которую можно уложить в виде инициативы запуска новой разработки. Это же возможность запустить что-то новое и получить новый бюджет. Но обычному аналитику это может и неподвластно, а вот руководителю проекта, продакту или кто выше, вполне. Единственное тут было бы здорово, чтобы аналитика слышали. А ведь этот пункт самый правильный, потому что по факту руководитель с той стороны говорит о боли и может её лабировать в решение в виде разработки, если является лицом принимающим решения. Конечно при условии возможности получения бюджета и всех других ограничений.
Вывод у меня получился такой: в госах есть кастдев, но со своими нюансами и ограничениями, которые накладывает регулятор, среда, организация. И вцелом это очень интересно, если на Аналитика на госпроектах смотреть как на источник развития бизнеса, и немного изменить его мышление и точку зрения. Чтобы он всё таки не только опросом занимался, как и что автоматизировать один к одному, или как улучшить бизнес-процесс, а как развить цифровой продукт так, чтобы ты самая боль была закрыта. Кажется это уже уровень "высшего пилотажа".
Кастдев в гос продуктах.
Меня спросили, что такое кастдев в гос продуктах. Я задумалась. Мне всегда казалось, что эти два слова не совместимы. Глубинное интервью, исследования и гос продукты.
Начала расспрашивать людей вокруг и сама делать выводы. Из опыта могу сказать, что часто были интервью именно сбора требований. И ведь действительно аналитик, работая бок-о-бок с заказчиком понимает и боль, и что необходимо сделать, хотя и не знает, что такое кастдев. И имеет совсем другое мышление.
Но если говорить про кастдев в госах, то он возможен и он есть. Но в строго определенных условиях:
1. Это продукты, где есть явный пользователь, которому можно позвонить и узнать "боль". Пример, госпорталы. Если мне, как пользователю госулуг, зададут вопрос, что не так? Боль польётся рекой!
2. Сложно говорить про пользователей, если это сотрудники компаний. Они понимают, что говори не говори, всё тлен. У них регламент и жёсткие правила поведения. Поэтому их разговорить крайне трудно. Один из моих однокурсников в ВШЭ (респект ему) научился собирать обратную связь путем проведения вебинаров для сотрудников. И из этого делать выводы про реальную боль. Часто хватает прочтения регламента и наблюдения за тем как работают люди.
3. И самый интересный пункт. Это понимание боли руководства и не только, которую можно уложить в виде инициативы запуска новой разработки. Это же возможность запустить что-то новое и получить новый бюджет. Но обычному аналитику это может и неподвластно, а вот руководителю проекта, продакту или кто выше, вполне. Единственное тут было бы здорово, чтобы аналитика слышали. А ведь этот пункт самый правильный, потому что по факту руководитель с той стороны говорит о боли и может её лабировать в решение в виде разработки, если является лицом принимающим решения. Конечно при условии возможности получения бюджета и всех других ограничений.
Вывод у меня получился такой: в госах есть кастдев, но со своими нюансами и ограничениями, которые накладывает регулятор, среда, организация. И вцелом это очень интересно, если на Аналитика на госпроектах смотреть как на источник развития бизнеса, и немного изменить его мышление и точку зрения. Чтобы он всё таки не только опросом занимался, как и что автоматизировать один к одному, или как улучшить бизнес-процесс, а как развить цифровой продукт так, чтобы ты самая боль была закрыта. Кажется это уже уровень "высшего пилотажа".
#конфархитекторов #моемнение #развитие #гос #рассуждения #мирвокруг
В прошедшую пятницу мне посчастливилось послушать выступления архитекторов разных компаний на конференции, которую устраивали scrum track.
Зафиксирую свои #мысливслух
Начну с госов))
Я не люблю гос разработку. Потому что для меня гос проекты не про бизнес. Но в госах настолько интересные бывают задачи, которые ты не найдёшь нигде. И конечно все современные слова и тенденции в виде "блокчейн, искусственный интеллект и цифровые двойники" присутствуют. Под них выделяются бюджеты и хочется верить в то, что эти технологии реально реализуются. Иногда кажется, что подобные технологии пихают куда надо и куда не надо. Но речь сегодня не про это)
Итак, меня поразили два доклада. Про ЕМИАС и про Почту. От каждого из этих слов меня бросает в мелкую дрожь. И хочется закричать "никогда"!! Но! Представляете какие безумные вещи выстроили архитекторы этих компаний? Всё дословно мне сложно рассказать. Записи выступлений в открытом виде, насколько я поняла, будут в декабре.
Но цифровая трансформация работает. Почта сделали конвейер по разработке. И удивили меня тем, что начали проверять требования ещё на ранних стадиях проектирования. Сразу же прилетел вопрос, а как же agile, на что их архитектор сказал, что это и есть agile. Чёткие границы всех этапов, проектирование, чёткие задачи на разработку. И внимание!) они внедряют в свой процесс Enterprise architect. Я всё чаще и чаще произношу это название. Но по сути, кроме как автоматизировать процесс постановки задач на разработку, ускорение не добиться. И их преобразование увеличило разработку в 10 раз!! Только вдумайтесь в 10 раз! Если мы говорили, о том, что наличие аналитика увеличивает скорость разработки в 2 раза, то автоматизация проектирования и работы архитектора/аналитика приводит к увеличению в 10 раз!
На самом деле всё к этому и идёт. Появление микросервисов, быстрая скорость разработки, предъявляет требование и к автоматизации работы аналитика. Тут вангую, что должна появиться среда, где из слов можно создавать диаграммы и наоборот. Возможно уже что-то есть, а я и не в курсе. Я не про Enterprise architect, visual paradigm или им подобное. А что-то типа gerkin, когда ты пишешь псевдо код из требований это превращается, например, в активити (имхо это самое простое) и дальше уходит в проектирование.
При этом почта практически не имеет аналитиков, но зато у них системные архитекторы, solutions архитекторы и ещё какие-то, всех не запомнила))) Но смысл такой, что архитектор стал проектировщиком. А аналитик же тоже проектирует!! Но почему - то многим это не очевидно.
Что касаемо ЕМИАС, то тут мощь в распределение системы. И тоже прозвучали слова Enterprise architect!
На самом деле у многих в докладах звучало правило - что всё должно документироваться по одному шаблону в компании. Чтобы можно было шарить ресурсы и спокойно переключать разработчика с задачи на задачу. Хотя я сторонник подхода - да как угодно опиши, главное донеси правильно задачу команде разработки. Но чёткие правила игры дают возможность и масштабироваться и внедрять такие инструменты как EA.
Небольшой подитог. Не знаю как вы, а я долго находилась под впечатлением того, во что превратился емиас и почта. Даже для меня, как для пользователя, сервис стал лучше. И мне тут сложно сравнивать с другими странами, но с 2017 до 2021 год у подобных сервисов случился скачок. Хотя для нас это скачок, а по сути нормальное развитие. Выход на качественный уровень, при цифровой трансформации, быстро не происходит, как раз 3-4 года. Хоть нам и кажется, что должно быть быстро и здесь и сейчас. Но нет. Естественное развитие живёт по своим законам.
Отрадно думать о том, как все государственные или около государственные сервисы могут улучшаться в будущем. Но думаю до пика развития они всё таки когда-то дойдут.
В прошедшую пятницу мне посчастливилось послушать выступления архитекторов разных компаний на конференции, которую устраивали scrum track.
Зафиксирую свои #мысливслух
Начну с госов))
Я не люблю гос разработку. Потому что для меня гос проекты не про бизнес. Но в госах настолько интересные бывают задачи, которые ты не найдёшь нигде. И конечно все современные слова и тенденции в виде "блокчейн, искусственный интеллект и цифровые двойники" присутствуют. Под них выделяются бюджеты и хочется верить в то, что эти технологии реально реализуются. Иногда кажется, что подобные технологии пихают куда надо и куда не надо. Но речь сегодня не про это)
Итак, меня поразили два доклада. Про ЕМИАС и про Почту. От каждого из этих слов меня бросает в мелкую дрожь. И хочется закричать "никогда"!! Но! Представляете какие безумные вещи выстроили архитекторы этих компаний? Всё дословно мне сложно рассказать. Записи выступлений в открытом виде, насколько я поняла, будут в декабре.
Но цифровая трансформация работает. Почта сделали конвейер по разработке. И удивили меня тем, что начали проверять требования ещё на ранних стадиях проектирования. Сразу же прилетел вопрос, а как же agile, на что их архитектор сказал, что это и есть agile. Чёткие границы всех этапов, проектирование, чёткие задачи на разработку. И внимание!) они внедряют в свой процесс Enterprise architect. Я всё чаще и чаще произношу это название. Но по сути, кроме как автоматизировать процесс постановки задач на разработку, ускорение не добиться. И их преобразование увеличило разработку в 10 раз!! Только вдумайтесь в 10 раз! Если мы говорили, о том, что наличие аналитика увеличивает скорость разработки в 2 раза, то автоматизация проектирования и работы архитектора/аналитика приводит к увеличению в 10 раз!
На самом деле всё к этому и идёт. Появление микросервисов, быстрая скорость разработки, предъявляет требование и к автоматизации работы аналитика. Тут вангую, что должна появиться среда, где из слов можно создавать диаграммы и наоборот. Возможно уже что-то есть, а я и не в курсе. Я не про Enterprise architect, visual paradigm или им подобное. А что-то типа gerkin, когда ты пишешь псевдо код из требований это превращается, например, в активити (имхо это самое простое) и дальше уходит в проектирование.
При этом почта практически не имеет аналитиков, но зато у них системные архитекторы, solutions архитекторы и ещё какие-то, всех не запомнила))) Но смысл такой, что архитектор стал проектировщиком. А аналитик же тоже проектирует!! Но почему - то многим это не очевидно.
Что касаемо ЕМИАС, то тут мощь в распределение системы. И тоже прозвучали слова Enterprise architect!
На самом деле у многих в докладах звучало правило - что всё должно документироваться по одному шаблону в компании. Чтобы можно было шарить ресурсы и спокойно переключать разработчика с задачи на задачу. Хотя я сторонник подхода - да как угодно опиши, главное донеси правильно задачу команде разработки. Но чёткие правила игры дают возможность и масштабироваться и внедрять такие инструменты как EA.
Небольшой подитог. Не знаю как вы, а я долго находилась под впечатлением того, во что превратился емиас и почта. Даже для меня, как для пользователя, сервис стал лучше. И мне тут сложно сравнивать с другими странами, но с 2017 до 2021 год у подобных сервисов случился скачок. Хотя для нас это скачок, а по сути нормальное развитие. Выход на качественный уровень, при цифровой трансформации, быстро не происходит, как раз 3-4 года. Хоть нам и кажется, что должно быть быстро и здесь и сейчас. Но нет. Естественное развитие живёт по своим законам.
Отрадно думать о том, как все государственные или около государственные сервисы могут улучшаться в будущем. Но думаю до пика развития они всё таки когда-то дойдут.