Вот вы однако заморочились, разве было не проще, чтобы клиенты обращались за настройками? Либо поставить ограничение — типа за доработку после ТЗ — плати, исправим.
Хорошо, что заморочились, странно, что только недавно. Такие вещи в CRM должны быть по умолчанию. Графики, отчеты, вычисления. А то так можно вести эксельку и не париться. Бесплатно зато
Ни один программист не заинтересован в понимании бизнес-процессов
Вот здесь слишком категорично. В некоторых компаниях вводиться новый термин "продуктовый инженер", и они стремятся (и им удаётся) замотивировать программистов делать фичи, а не таски. Да и всегда среди программистов было субъективное разделение на грейды junior/middle/senior:
Junior получает в качестве задания – "как нужно сделать", и делает (технически проработанное задание)
Middle – "что нужно сделать" (проработанное задание с точки зрения бизнес-процессов)
Senior – "зачем что-то делать" (проблема, для которой нужно найти и реализовать/делегировать решение)
Если по подобного рода задачам подключать три уровня программистов, то ценник, как правило, становится космическим и неконкурентоспособным. Поэтому, как правило, на такие задачи сажают связку менеджер проекта + программист junior, где программист как раз не особо заинтересован в тонкостях и этапах обработки того или иного бизнес-процесса в компании клиента, его задача , как вы правильно написали выполнить изменения в коде, согласно технически проработанному заданию, и видимо такого типа программист и имелся в виду в статье.
Вот вы однако заморочились, разве было не проще, чтобы клиенты обращались за настройками? Либо поставить ограничение — типа за доработку после ТЗ — плати, исправим.
Хорошо, что заморочились, странно, что только недавно. Такие вещи в CRM должны быть по умолчанию. Графики, отчеты, вычисления. А то так можно вести эксельку и не париться. Бесплатно зато
Ни один программист не заинтересован в понимании бизнес-процессов
Вот здесь слишком категорично.
В некоторых компаниях вводиться новый термин "продуктовый инженер", и они стремятся (и им удаётся) замотивировать программистов делать фичи, а не таски.
Да и всегда среди программистов было субъективное разделение на грейды junior/middle/senior:
Junior получает в качестве задания – "как нужно сделать", и делает (технически проработанное задание)
Middle – "что нужно сделать" (проработанное задание с точки зрения бизнес-процессов)
Senior – "зачем что-то делать" (проблема, для которой нужно найти и реализовать/делегировать решение)
Если по подобного рода задачам подключать три уровня программистов, то ценник, как правило, становится космическим и неконкурентоспособным. Поэтому, как правило, на такие задачи сажают связку менеджер проекта + программист junior, где программист как раз не особо заинтересован в тонкостях и этапах обработки того или иного бизнес-процесса в компании клиента, его задача , как вы правильно написали выполнить изменения в коде, согласно технически проработанному заданию, и видимо такого типа программист и имелся в виду в статье.
Самое время для CRM, скоро все самоизолируемся и будем сидеть по домам, работать)
Конструкторы хорошо, в своё время работал на http://runabase.ru/ и https://mydataexpress.ru/
Спасибо за ответ, в ближайшем будущем как раз сделаем обзор конструкторов