Коллеги, а кто-нибудь [из еще здесь по непонятным причинам оставшихся] имел опыт с No-Code Development Platforms Software? Поделитесь впечатлениями, плз.
Здравствуйте! Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: Образование. Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее. Фрэнк, команда ЖЖ.
Впрочем, ставлю что тулы типа airtables, и анонсированного MS Lists - полетят. Как замена богомерзкому экселю, который можно было бы сразу нормально сделать. Но не как "программирование из квадратиков и стрелочек". Дать простым людям собрать себе реляционную БД с UI - очевидный следующий шаг оффисных тулов. Но не более - шагов дальше не будет.
Худший сценарий - SQL: когда придумали язык для бухгалтеров, а потом пришлось заставлять на этом говне писать кучу умных людей.
Как-то в процессе работы над inShort пытался изучить данную тему, пользователей прорабатывал. В итоге это мало кому нужно, на самом деле, если есть хорошее описание процессов (как основа для ТЗ), то переход к коду сейчас довольно прост. Мало того совмещать оба процесса (описывать и кодировать) вредно для обеих стадий. Однако если руководитель страдает энтузиазмом и природа бизнеса сводится к простым и динамичным процессам, то как временный этап такой вариант приемлем, впрочем как только в процессах возникает ясность, то бизнес быстро обрастает решениями полного цикла разработки. Пока я решил не двигаться в эту сторону.
Посмотрел на описание вашего продукта и вспомнил, как вы его несколько лет назад показывали. И вспомнил, почему в прошлый раз не попробовал: 1. Это для Apple, продуктами которого я не пользуюсь. ) 2. Такое ощущение, что для того, чтобы начать юзать продукт, мне нужно сначала получить еще одно высшее образование. )
Старые песни о главном. "Давайте уберем дорогих и непонятных программистов и пусть нам дешевые крестьяне будут системы разрабатывать." Не, условно коробочный продукт с парой настроек конечно будет полезен. Но как только возникают вопросы, что "а нам бы, батенька, еще тово-этово", то сразу нужно кого-то, кто умеет мыслить как разработчик. Но это типичного менеджера проектов не интересует, ему главное поставить что-то и слинять на другой проект. А мудохаться с расширением функционала за внезапно х10 прайс будет уже другой менеджер, который непроектный. Да и вообще не менеджер, а системный аналитик-разработчик.
Фрагментарно - работает. Не в том месте где должен быть код, а в том месте, где настройки выполняются в виде кода. Использовать осторожно, DSL или embedded lang могут оказаться удобнее.
Но даже при реализации хороших галочек для сложной работы нужны непростые люди.
В общем, проще рассматривать good practice в кодировании галочками как этакий спецфический DSL.
Comments 7
Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: Образование.
Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее.
Фрэнк,
команда ЖЖ.
Reply
Reply
Худший сценарий - SQL: когда придумали язык для бухгалтеров, а потом пришлось заставлять на этом говне писать кучу умных людей.
Reply
В итоге это мало кому нужно, на самом деле, если есть хорошее описание процессов (как основа для ТЗ), то переход к коду сейчас довольно прост. Мало того совмещать оба процесса (описывать и кодировать) вредно для обеих стадий. Однако если руководитель страдает энтузиазмом и природа бизнеса сводится к простым и динамичным процессам, то как временный этап такой вариант приемлем, впрочем как только в процессах возникает ясность, то бизнес быстро обрастает решениями полного цикла разработки. Пока я решил не двигаться в эту сторону.
Reply
1. Это для Apple, продуктами которого я не пользуюсь. )
2. Такое ощущение, что для того, чтобы начать юзать продукт, мне нужно сначала получить еще одно высшее образование. )
Серьезно, описание продукта - катастрофа просто.
Reply
Не, условно коробочный продукт с парой настроек конечно будет полезен.
Но как только возникают вопросы, что "а нам бы, батенька, еще тово-этово", то сразу нужно кого-то, кто умеет мыслить как разработчик.
Но это типичного менеджера проектов не интересует, ему главное поставить что-то и слинять на другой проект.
А мудохаться с расширением функционала за внезапно х10 прайс будет уже другой менеджер, который непроектный. Да и вообще не менеджер, а системный аналитик-разработчик.
Reply
Но даже при реализации хороших галочек для сложной работы нужны непростые люди.
В общем, проще рассматривать good practice в кодировании галочками как этакий спецфический DSL.
Reply
Leave a comment