Так получилось, что наш R&D в 2018 году сформировался по большей части из разработчиков и технических менеджеров, поэтому у нас исторически бóльший уклон в сторону Development, нежели в Research. И любая входящая задача, прошедшая валидацию на наличие проблемы, часто расценивается нами в первую очередь с позиции инженера:
А не с позиции аналитика или продуктового менеджера, которые обычно задаются такими вопросами:
А точно ли нужно решать именно эту проблему?
Не следствие ли это какой-то более корневой причины?
А делал ли уже кто-то, что-то подобное?
А у них получилось? А какой итог? Что сработало хорошо/а что нет?
Какие есть способы сделать это совсем без разработки?
А действительно ли мы выбрали наилучшее решение?
А можно ли сделать это в 2 раза дешевле? А ещё в 2 раза дешевле?
В общем, с использованием всех тех техник, о которых рассказывают зрелые продуктОлоги и популярные течения.
Примерно так произошло и в этот раз, когда проблема была идентифицирована и описана примерно так:
Снижается операционная эффективность бизнеса: увеличивается время на получение достоверной информации о текущем состоянии бизнес-процессов (проблема прозрачности и скорости), себестоимость услуг растёт (проблема со структурой затрат), производительность процессов компании падает (проблема эффективности).
В мозгу включился “внутренний аналитик”, который понял, что быстро собрать какие-то данные, подтверждающие или опровергающие вышеобозначенные проблемы невозможно, а в долгую – нецелесообразно. Дальше, конечно же, подключился “инженер”, которому вторили и другие инженеры, мы ведь больше про D, техническая экспертиза ого-го, сейчас быстренько всё соберём, оцифруем и полетим!
А победил как обычно “менеджер”, который поддался модным течениям и прогнозам :)
Но всё же что-то подсказывало, что в классическом треугольнике (содержание, скорость, стоимость, качество) мы выбрали не самую лучшую комбинацию: собрать MVP, быстро, дешево и на Power Platform.
И вот на этом стыке размышлений аналитика и инженерного сольфеджирования и возникла идея проекта Link.One. Платформы, которая позволит оцифровать все внутренние взаимодействия и даст нам пищу для размышления относительно того, где же скапливается незавершённое производство и сколько нам эти простои по факту стоят.
1. Да что там делать, Microsoft уже всё давно сделал!
Я давно (ну как давно), года с 2017, слежу за no/low-code движением инструментов и платформ, но активно знакомиться с ними начал только в 2019-ом.
Сначала это были робкие попытки автоматизации поступления новых постов с читаемых блогов через IFTTT (2017), далее не менее робкие и часто безуспешные попытки создания корпоративного мобильного приложения на PowerApps (2018), а потом моя ботомания привела к таким сервисам, как botmother, autofaq и just-ai (2019), и всё ради ускорения time-to-market и выдачи нагора бизнес-результата с очередной ценностью для внутреннего или внешнего клиента.
И вот 2020-ый, мы (dentsu) активно высаживаемся в Teams, но, как и многие компании, по-прежнему используем только 5% всей мощи Office 365 и Power Platform, которая в рамках E3 лицензии даёт довольно обширные возможности по автоматизации. Т.е. тут мы “как бэ” экономим на стоимости лицензий, потому что они у нас уже есть и для нашей задачи вполне подходят.
Отлично, Power Platform достался нахаляву, осталось найти разработчиков на Power Platform
Беглый обзор рынка, несколько коммерческих предложений, и выбор пал на ребят из Awara-IT. Мне они ещё понравились тем, что имели структурную форму брифа на разработку, а также примеры работы, которые были релевантны тому, что мы планировали создать и интегрировать в компании. Ударили по рукам электронным договором, спланировали и оценили объём работ и … наступил 2021-ый.
2. Когда low-code решает!
Медленно тянулся январь 2021-го, ребята из Awara нарисовали амбициозный план по сдаче работ, к которому я отнёсся со здравым пессимизмом, но в начале марта 2021-го мы почему-то стали очень оперативно получать результаты работы и почти готовое решение на Power Apps. Это было не-о-быч-но :)
Сначала меня, конечно же, охватила эйфория, вух, как быстро идём, потом паника, скоро ведь нужно будет тестировать и внедрять (на тот момент в этом проекте у меня было три шапочки — менеджера, бизнес-аналитика и тестировщика) ...
В первый раз мы споткнулись о дизайн. Наверняка все вы видели, когда менеджер берётся сам делать дизайн, а уж не дай бог отдаёт это на откуп разработчикам, то получается то, что обычно получается. Ничего хорошего, в общем :)
Первые прототипы я набрасывал сам, в душе я, конечно же, считал их великим творением, на публике говорил, что дизайн “такой себе” и в действительности будет сильно лучше и удобнее.
Ребят из Awara это не испугало, они предложили несколько отважных решений (бриф, список брифов), но я как тревожная кисонька обратился к нашей дизайн-команде, чтобы сделать хотя бы верхнеуровневое review и предложить базовые улучшения по части UX/UI, которые уложатся в 8-10 часов работы дизайнера.
И знаете что? Дизайн был имплементирован за неделю чистого времени разработки! Такой скорости я ещё не видел никогда, Power Apps мне всё больше нравился, Sharepoint уже не казался таким глючным и тормозным, а Power Automate казался какой-то магией, которую ещё обещали при выпуске Windows Workflow Foundation, но в которую я так и не поверил, ибо программировать там нужно было даже больше, чем конструировать.
Power Platform отлично подходит для того, чтобы что-то быстро собрать и запустить. Ключевое тут “что-то”, не всё что угодно.
3. Когда low-code не решает, или стадия внедрения
Признаюсь, что внедрением внутренних решений я осознанно занимаюсь, наверное, года с 2008-го. И не понаслышке знаю, что проходят они через боль и страдания, и часто дело даже не в самом решении, его потенциальных выгодах и ранних болячках (они говорили, делай MVP, а там разберёмся). Дело в людях. Люди не любят изменений, люди привыкают, и приходится искать инноваторов и подключать другие способы раскатывания.
Казалось бы, причём тут low-code? Рассказываю, всё дело в волшебных пузырьках.
После тестирования, на котором вскрылось около 3-х десятков незначительных проблем и которые были довольно быстро поправлены (как так см. Раздел 2), было решено сделать серию обучающих мероприятий в стиле button-clicking’а и ответов на часто задаваемые вопросы по бизнесу и технической части. Через него прошло порядка 200-250 человек, и в какой-то момент я даже поймал себя на мысли, что мог бы просто включать ранее записанное видео, уходить пить чай минут на 10-15 и возвращаться к моменту обсуждения и ответов на вопросы.
На них вскрылось вот что:
UI от PowerApps не интуитивен и привести его к функциональному виду – дорого!
Люди избалованы красивыми и функциональными веб-решениям от Google и десктоп решениями от того же Microsoft.
Даже мне (уж простите за пафос, но интерфейсами я занимаюсь ещё с 80-х) не всегда очевидно, как поведут себя довольно стандартные элементы интерфейса: выпадающий список и календарь.
Я сначала не понимал, почему люди так хихикают над средой и окрестили её плохим днём. Но так или иначе от кастомизации за 10 с чем-то часов я отказался, мы сделали нормальный ввод в формате dd.mm.yyyy и успокоились.
После обучения, уже на внедрении, вскрылось ещё несколько моментов:
Создание dev, stage, prod окружений невиданная роскошь!
Поскольку мы довольно плотно общаемся с разными разработчиками и стараемся всё делать по канонам зрелой разработки, то я зашёл с козырей, тихо поинтересовавшись у ребят из Awara, а как же мы будем теперь разрабатывать и поставлять новое?
Ответ меня не напугал, нет, чего грешить, я сам в 2000-х работал с prod базой, а когда потерял часть рабочих данных, потом плохо спал, ел, да и вообще старался не попадаться на глаза руководству. Тут же просто ещё раз утвердился в мысли, что Power Platform – это не про зрелую разработку, это продукт, ориентированный на так называемых citizen developers.
Сделать пару дополнительных окружений – никаких проблем, не так дорого, просто раскопируйте всё своё хозяйство на несколько sharepoint-ов, powerapps-ов и тестируйте на здоровье.
НО! Когда дело доходит до переноса кода, забудьте, что у вас тут есть git flow или иной способ безопасной миграции изменений. Старый добрый метод РеКле (также известный под именем Ctrl+C, Ctrl+V). Чтобы не быть голословным, я приведу парочку статей, где автор недоумевает, что не так-то (раз, два)?
Но это всё ещё цветочки, скажу я вам, основной мой страх, конечно же, был в другой части.
Ограничения наступят вам на пятки сразу после запуска!
Ещё на этапе проектирования общей архитектуры решения мой внутренний инженер, который повидал и опробовал на себе уже не одну версию Sharepoint-а, был уверен, что всё, что хоть как-то касается Sharepoint-а и используется как аналог СУБД, обречено на провал на масштабах enterprise разработки.
До сих пор удивляюсь, как доживает последние дни наш старый корп.портал на SP2013, но это материал на отдельную статью, которую, наверное, и не стоит даже писать.
Возможно, набегут советчики и MVP по Power Platform и расскажут про Data Verse, Azure и современные инструменты для использования с PowerApps, но таким я отвечу сразу -- на кой мне тогда ваш low-code и какова стоимость владения решением на горизонте хотя бы в 1 год?
И, конечно же, попрошу сделать расчёт стоимости лицензий, коннекторов и прочей, не всегда очевидной для мирного разработчика подноготной, что прячет Microsoft за своими длинными манифестами в лицензионных политиках.
Ну да ладно, к фактам:
-
Мы сразу условились, что брифы, которых за год может быть около 3-5 тысяч, со временем нужно переносить в некий архив после 6 месяцев с момента выполнения, чтобы:
а) не тормозило, Sharepoint не любит много объектов в себе, вроде как 40К записей, и всё, уже покряхтывает.
б) поиск, отзывчивость интерфейса, запросы клиента к серверу будут быстрее отрабатывать без тонкого тюнинга самого Sharepoint-а, куда сааааавсем не хотелось залезать.
Дед можно заменить на Sharepoint (автор: Ева Морозова) -
В тонкой материи нашего устройства инфраструктуры в компании мы используем внутренний Exchange, а не облачный, из соображений безопасности и экономии на лицензиях.
Об этом мы условились на берегу с разработчиками из Awara-IT, и нужно отдать им должное, они изворачивались как могли, потому как знали тонкости работы Power Platform. И у нас не было потом сюрпризов при деплое финального решения, которое ни у кого бы не запустилось, будь в нём хоть малейшая отсылочка к доступам до облачного Outlook-а.
Вы конкурируете с современными, адаптивными подходами и решениями, которым проиграете, и это дорого вам обойдётся.
В сухом остатке
Вы думаете, мы бросили затею с Power Apps? Совсем нет, просто мы поняли, что это офигенный, правда, не самый дешёвый, способ для проверки MVP решения. Вот только пойди мы сразу к дизайнерам, сделай кликабельные прототипы в Figma, проведи решенческие интервью на пользователях, как мы делаем с большими платформенными решениями и продуктами для клиентов, то поняли бы это всё гораздо раньше.
Конечно, потеряли бы в скорости запуска, и TTM был бы не такой, который нужен менеджменту (трансформироваться нужно, чего тут думать, решения давай!), но сейчас решение на Power Apps работает, обслуживает 3 больших подразделения, а ещё 3 на подходе, но интегрировать мы, конечно же, будем их не в Power Apps, а в то, что разработаем с нуля сильными программистскими руками, а MVP, чего уж, законсервируем и будем вспоминать с теплотой и любовью :)
Я и менеджер, который предлагает всё выбросить и начать с нуля