Александр Бындю @AlexanderByndyu
Автор книг «Антихрупкость в IT» и «Карта гипотез»
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Project Director, Chief Executive Officer (CEO)
Lead
C#
Agile
Microservices
Designing application architecture
Design patterns
SOLID
High-loaded systems
Kanban
Project management
People management
Круто! Всё понял, кроме последнего. Можете, пожалуйста, расписать подробнее вот эту часть?
> самую (на мой взгляд) жестокую ошибку софтверной инженерии: смешение анализа и синтеза (исследований и разработки)
Если на велосипед и самокат смотреть, как на объекты реального мира, то метафора неточная. Если мы говорим про абстракции в IT-продукте, то там вполне одно может перетекать в другое.
Я согласен, что для убеждения надо использовать механизмы "продажи" идеи. А вот для синхронизации подхода к разработке уже подойдут эти картинки
Да, разные варианты для разных "состояний" проекта. Если в уже существующей системе надо добавить "кнопку", то нет смысла идти издалека. Надо просто добавить кнопку. С другой стороны, даже в устоявшемся бизнесе и в давно существующих системах надо сделать нечто, чего в них раньше не было. Тогда подходы с "самокатами" отлично применимы. Я бы за основу брал Cynefin framework, чтобы понимать, как лучше двигаться к решению.
Если взять метаформу физического мира, то это правда будет 4 разных продукта. В IT всё-таки код можно сильно проще переиспользовать и трансформировать.
У вас карма настоящего QA :) А вообще я писал статью в редакторе Хабра, так что, возможно, их визивик шалит.
Михаил, да, тут много разных нюансов. Я думаю, что по первой картинке можно написать (точнее уже написано) много разных книг. Я скорее хотел дать общее направление мысли, чтобы были варианты при планировании метода создания продукта.
Почти так, но иллюстрация подразумевает, что наработки переходят от стадии к стадии и переиспользуются. В реальном мире, конечно, это маловероятно, но в IT такое частенько происходит. Если смотреть на схему, как на работу в физическом мире, то было бы точнее назвать, как вы сказали — каждая следующая стадия это пивот
FFF и правда не про MVP. Мы по нему делаем довольно большие с ложные продукты, которые уже много лет как ушли от стадии MVP.
Отчасти да, но это же только метафора. Как я писал, не каждый клиент встанет на самокат и захочет крутить крутить педали велосипеда. Если вынашиваю такого клиента, то это удача. Он правда может обогнать других.
То есть все проблемы и решения подходят и для 1С?
С 1С не приходилось работать. А какая там специфика?
Когда в проекте два квадратика, то легко написать всеобъемлющее ТЗ. Когда мы говорим о большом процессе, многое создается по ходу работы, которая длится годами. Отслеживание дублирования превращается в нетривиальную задачу.
На самом деле довольно часто используются low-code решения в больших бизнес-процессах, потому что так проще взаимодействовать с аналитиками и другими не-программистами. Им становится проще получить ответы на вопросы о том, как работает процесс.
Много компаний сейчас пошли в эту сторону, так что ваш шанс поработать с low-code возрастает.
Уточните, пожалуйста, вы имеете ввиду ТЗ на какие системы? На создание low-code платформы? Или на создание системы на платформе? Хочу понять сценарий, который вы имеете ввиду
Мы довольно часто используем, например, Camunda в задачах, где длинные бизнес-процессы. Могу для примера привести Order Management System (OMS) в екоме и ритейлере. У заказов есть разные статусы и условия перехода по этим статусам. Удобно бизнес-процесс описать визуально, а начинку сделать обычным кодом
Я думаю, что это прекрасная ниша и нужно писать на коленке на low-code MVP, чтобы проверить гипотезу. Но с самого начала надо обсудить с инвесторами, что это прототип, иначе можно обмануть ожидания. Есть хорошая картинка на тему, прикрепляю к комментарию.
Я бы не назвал UiWebKit платформой. Это скорее набор отдельных компонентов. У них же нет среды выполнения какой-то логики, кроме логики самих виджетов?
Похоже на правду
Имеются ввиду метрики, например, Sonar.
График условно линейный. Чтобы он был линейный нужно еще побороться. Если руки растут из правильных мест, то можно управлять сложностью. Если нет, то ничего не спасет. Но при low-code, когда нет рефакторинга и автотестов, ничего не поможет.