Его (фрилансера) привлекают для решения конкретной задачи или проблемы, но участия в стратегическом планировании он не принимает и не является частью команды.
Немного кольнуло. А у всех такое мнение, что фрилансер выполняет только разовые задачи? Вы можете предположить, что на него нередко возлагаются именно вопросы стратегии развития. И даже если это не «вписано в договор», то ему все равно приходиться думать о последствиях своего решения, так как потерять крупного клиента – печально, а на простых задачах – не заработать.
В остальном «почему не ходим» – замечено верно. Ужас как хочется, но работа! Вебинары не всегда досматриваешь. А следить за тенденциями, новыми решениями нужно обязательно.
В постах выше было упоминание о ФП … не прошел мимо. Хотелось бы излагать задачу в терминах «чего хочу», а не «сделай это». Разница как между select и for each. Вот только боюсь, что буду не способен все так выразить. Видать не только я. Из-за этого и получаются языки, поддерживающие обе парадигмы.
Нет, не бояться … Просто будут делать это другим способом, на других языках. Возможно с сильной типизацией и в функциональной парадигме (как Letsrock85 ;). Наверняка больше времени будут тратить на выбор архитектуры ПО, в которой учтут прогнозируемые изменения условий эксплуатации, или ещё какие-нибудь требования «высокого порядка». Будут применять системы формального доказательства алгоритмов, симуляцию поведения системы в целом. Надеюсь, это будет просто и массово, как сейчас можно встретить склейку чужих и не проведенных библиотек. Будут, конечно, и framework’и, и SaaS’ы.
Правда и ожидать, что входной билет в эту область станет дешевле не приходиться.
Хотя … если честно. То какую-то большую часть «нынешнего программирования» действительно можно отобрать у человека. А для кого-то это «и хлеб, и масло»….
Но как-то сохранить инженерную культуру нужно пытаться. Эта важная задача бизнеса, и/или государства. (А то конкуренты-то борют.)
Радует уже то, что руководители стали разбирать эти ситуации, а не делать скорые выводы о «туповатом задроте». Поэтому «неистово плюсую». И рекомендую Аркадия пересадить на участок ответственных (server side / hi load) работ, или отвести роль наставника. Если самооценка не окончательно загублена.
А всё же. Не боимся ли мы остаться без Аркадиев? Используя аналогию выше. Про авиаконструкторов: Да, массово нужны авиаремонтники, но раз в 30 лет понадобиться и Главный конструктор. А он сейчас «нерентабельный», отчасти высмеиваемый. Вот фобию у него обнаружили.
О, как! Есть готовое. Сам то всегда реализовывал такую задачу методом Q-грамм (Би-грамм если быть точным). Надеюсь, производительность реализации позволит в лоб сопоставить две таблицы хоты бы 10к в каждой.
Ну, а все-таки, что теперь будет? Обновленный и расширенный новый стандарт SQL, с поддержкой агрегатов (тип CUBE), и что-то для работы иерархиями, или шире … с графами? Может какое-то обобщение с MDX, или GraphQL?
SQL остаётся хорошим для статической модели данных. Там же где данные ненормализованные, либо очевидно, что модель будет и должна меняться, он излишне строгий.
А у самого, из недавнего …
Нужен отчет с диаграммами «в строку»: первая справа, вторая слева. Строк много. Для некоторых необходимо рядом размещать таблицу данных, но с расширенным и переменным описанием объектом анализа.
Всё это необходимо сохранить в ECXEL с сохранением редактирования.
В итоге 800 строк интерфейсной логики, и 4200 — расчетной/оформительской. Предупреждаю — код не Ctrl+C, Ctrl+V, а хорошо декомпозирован.
Бывает и так …
Необходимо разработать сложный отчет с двумя десятками показателей и пятком объектов анализа. Рассчитать все это в СДК можно, но управлять потом невозможно. Это выльется в десяток наборов данных, с простынями «ВЫБРАТЬ», и бойницами параметров (о них писал shumkiiv). И попробуй ошибись с объединением наборов!
Или вот ещё …
Расшифровка и макеты. Специально ездил за книгой Хрусталёвой чтобы разобраться вот с этим …
Ну, не заходит оно.
Далее …
Программное управление параметрами отчета, его структурой: скрыть добавить группировку, убрать параметры при отсутствии какой-то группировки … и подобное. Всё это требует наличия какой-то библиотеки, и её использование ПриКомпоновкеРезультата.
Управление структурой отчета – всегда боль. И всячески нужно скрывать возможность порчи настроек пользователем. Об этом тоже писали.
Говорю об этом в противовес мнению «СДК – это супер отчеты без программирования».
Опять, же ИМХО, но СДК плохой механизм.
СКД очень мощный инструмент. С его помощью можно сделать много вещей, без кодирования. Но … бывает очень сложно сделать то, что нужно.
Это ИМХО за многие годы работы с ней.
Соглашусь и здесь. Нужно посмотреть на ситуацию и глазами заказчика …
А на его глаза действительно часто попадают спецы, которые не удосуживаются толком выслушать; провести презентацию и подготовить внятное коммерческое предложение. Но требуют деньги.
Не далее двух недель назад, по вопросам SEO, общался со специалистом, которого партнер охарактеризовал так … «на бешеной козе не подъедешь»: спецификации работ нет, и не будет; 100% предоплата; средств объективного контроля нет, и не предполагается.
Здесь я вижу, в некоторой части, ответную реакцию на обычный ход ИТ-проектов.
ИТ не хватает «квалифицированного спроса». Конфликт в следующем:
Клиент хочет «универсального решателя проблем» (и 1С, и принтер), но не готов платить за «полное погружение в жизнь компании». Не готов платить абонентскую плату; торгуется за каждый этап, и прочее.
Подрядчик готов пойти на меньшую сумму, но в таком случает готов выполнить «только свою работу»: предельно жестко бодается при согласовании задания, сразу включает кассу при возникновении новых условий.
Органичного, взаимовыгодного сотрудничества, не получается. Стороны «не видят друг друга».
Далее …
Обмен колкостями, разделение на «хаброобитателей» и «инфантильных заказчиков».
Задача была простой интеграция торговой системы с сайтом. Ну, знаете — товары/цены/остатки туда, заказы обратно. Но так как в работах уже три стороны (Заказчик, я и WEB-подрядчик), то составил «хорошее» ТЗ и обсудил его со всеми Сторонами. Под «хорошее» понимаю не просто описание XML-форматов, но и «дух» интеграции: какая система за что отвечает, как не потерять пакет обмена, как восстановить целостность ( … если все же потеряли). Скажу сразу — никто не хотел делать эту работу, и, разумеется, платить. Сделал сам, бесплатно. Внизу написал сроки и фиксированную цену; подписал с Заказчиком; в задании обязал Заказчика руководствоваться этим документом в отношениях с «третьими лицами» (WEB-спецы так и не стали подписывать). Ну, одним словом, все как должно быть, все за свой счет, никого не напрягая.
В итоге …
Предусмотренные в задании проблемы начались. Никого не обижая (это важно!), указал на порядок устранения проблем и их стоимость. Одним словом оказался прав, но не педалировал это; а приял «активную и конструктивную позицию … с улыбкой превозмогал сложившуюся ситуацию».
В самом конце …
Мы расстались. Видимо клиент затаил злобу, из-за того что оказался неправ, и не смог действовать как обычно.
Описанные сценарии знакомы мне на практике. Разумеется, что сам пытался ответить на вопрос «как нужно действовать?», но с публичным обсуждением в таком ключе встречаюсь впервые.
Сам пробовал стратегию «работать только с людьми близкими по духу» — найти таких бывает сложно … и не каждый год. Пробовал «записывать всё и вся» — прослыл занудой.
Формализация отношений рушиться о следующее мнение: «нам нужны просто сроки и суммы, ход умозаключений оставь себе» … Но это же разработка ПО, система учета, необходимость вовлечение сотрудников в процесс?! … Далее как обычно: «мы передумали (столько думать для нас утомительно)», «почему и переделки включены в счет». В итоге «мы от вас устали».
Другой подход – браться только за понятные и простые задачи. Здесь давит конкуренция, и на этом рынке не создать длительных отношений.
Есть гипотеза, что вся эта картина следствие относительной молодости бизнеса в России в целом. Нужно попробовать поработать с «мудрым и старым бизнесом Запада».
И вообще есть же литература. Думаю проблема лишь в маркетинге. (Так и не нашел время прочитать СПИН-продажи (Нил Рекхэм) – но аннотация многообещающая).
И …
Согласен, что такой стиль управления часто просто ВЫГОДЕН.
С годами начинаешь чувствовать «своего клиента». Того где издержки на «администрирование проекта» не съедают дохода и сроков. Остальные не по зубам.
Замечу, что гос. учреждения всегда крупные. И это, с учетом изложенного выше, часто является основным фактором отказа от проекта.
И от себя, и от других не крупных подрядчиков неоднократно слышал «… с бюджетом не работаем!».
Если сохранится дистанционное образование для школьников, то уровень этих ресурсов будет вполне «ниЧё, lol»
Немного кольнуло. А у всех такое мнение, что фрилансер выполняет только разовые задачи? Вы можете предположить, что на него нередко возлагаются именно вопросы стратегии развития. И даже если это не «вписано в договор», то ему все равно приходиться думать о последствиях своего решения, так как потерять крупного клиента – печально, а на простых задачах – не заработать.
В остальном «почему не ходим» – замечено верно. Ужас как хочется, но работа! Вебинары не всегда досматриваешь. А следить за тенденциями, новыми решениями нужно обязательно.
Правда и ожидать, что входной билет в эту область станет дешевле не приходиться.
Хотя … если честно. То какую-то большую часть «нынешнего программирования» действительно можно отобрать у человека. А для кого-то это «и хлеб, и масло»….
Но как-то сохранить инженерную культуру нужно пытаться. Эта важная задача бизнеса, и/или государства. (А то конкуренты-то борют.)
Радует уже то, что руководители стали разбирать эти ситуации, а не делать скорые выводы о «туповатом задроте». Поэтому «неистово плюсую». И рекомендую Аркадия пересадить на участок ответственных (server side / hi load) работ, или отвести роль наставника. Если самооценка не окончательно загублена.
SQL остаётся хорошим для статической модели данных. Там же где данные ненормализованные, либо очевидно, что модель будет и должна меняться, он излишне строгий.
А у самого, из недавнего …
Нужен отчет с диаграммами «в строку»: первая справа, вторая слева. Строк много. Для некоторых необходимо рядом размещать таблицу данных, но с расширенным и переменным описанием объектом анализа.
Всё это необходимо сохранить в ECXEL с сохранением редактирования.
В итоге 800 строк интерфейсной логики, и 4200 — расчетной/оформительской. Предупреждаю — код не Ctrl+C, Ctrl+V, а хорошо декомпозирован.
Бывает и так …
Необходимо разработать сложный отчет с двумя десятками показателей и пятком объектов анализа. Рассчитать все это в СДК можно, но управлять потом невозможно. Это выльется в десяток наборов данных, с простынями «ВЫБРАТЬ», и бойницами параметров (о них писал shumkiiv). И попробуй ошибись с объединением наборов!
Или вот ещё …
Расшифровка и макеты. Специально ездил за книгой Хрусталёвой чтобы разобраться вот с этим …
Ну, не заходит оно.
Далее …
Программное управление параметрами отчета, его структурой: скрыть добавить группировку, убрать параметры при отсутствии какой-то группировки … и подобное. Всё это требует наличия какой-то библиотеки, и её использование ПриКомпоновкеРезультата.
Управление структурой отчета – всегда боль. И всячески нужно скрывать возможность порчи настроек пользователем. Об этом тоже писали.
Говорю об этом в противовес мнению «СДК – это супер отчеты без программирования».
Опять, же ИМХО, но СДК плохой механизм.
Это ИМХО за многие годы работы с ней.
Хотим что-то автоматизировать, но у самих нет представления о том «что мы есть». Ни в бумажном виде, ни в устных рассказах.
Пытаешься привести к общему знаменателю – получаешь сложности ещё на этапе предпроектного обследования.
Заказчик старается оставить для себя бОльший простор для «перемены решения», а стоимость этих изменений переложить на подрядчика.
Что это? «Инфантилизм» или преднамеренные действия? Да, и то и другое!
Да, это была 1С.
А на его глаза действительно часто попадают спецы, которые не удосуживаются толком выслушать; провести презентацию и подготовить внятное коммерческое предложение. Но требуют деньги.
Не далее двух недель назад, по вопросам SEO, общался со специалистом, которого партнер охарактеризовал так … «на бешеной козе не подъедешь»: спецификации работ нет, и не будет; 100% предоплата; средств объективного контроля нет, и не предполагается.
Здесь я вижу, в некоторой части, ответную реакцию на обычный ход ИТ-проектов.
ИТ не хватает «квалифицированного спроса». Конфликт в следующем:
Органичного, взаимовыгодного сотрудничества, не получается. Стороны «не видят друг друга».
Далее …
Обмен колкостями, разделение на «хаброобитателей» и «инфантильных заказчиков».
Задача была простой интеграция торговой системы с сайтом. Ну, знаете — товары/цены/остатки туда, заказы обратно. Но так как в работах уже три стороны (Заказчик, я и WEB-подрядчик), то составил «хорошее» ТЗ и обсудил его со всеми Сторонами. Под «хорошее» понимаю не просто описание XML-форматов, но и «дух» интеграции: какая система за что отвечает, как не потерять пакет обмена, как восстановить целостность ( … если все же потеряли). Скажу сразу — никто не хотел делать эту работу, и, разумеется, платить. Сделал сам, бесплатно. Внизу написал сроки и фиксированную цену; подписал с Заказчиком; в задании обязал Заказчика руководствоваться этим документом в отношениях с «третьими лицами» (WEB-спецы так и не стали подписывать). Ну, одним словом, все как должно быть, все за свой счет, никого не напрягая.
В итоге …
Предусмотренные в задании проблемы начались. Никого не обижая (это важно!), указал на порядок устранения проблем и их стоимость. Одним словом оказался прав, но не педалировал это; а приял «активную и конструктивную позицию … с улыбкой превозмогал сложившуюся ситуацию».
В самом конце …
Мы расстались. Видимо клиент затаил злобу, из-за того что оказался неправ, и не смог действовать как обычно.
… а так хотел fix-price.
Описанные сценарии знакомы мне на практике. Разумеется, что сам пытался ответить на вопрос «как нужно действовать?», но с публичным обсуждением в таком ключе встречаюсь впервые.
Сам пробовал стратегию «работать только с людьми близкими по духу» — найти таких бывает сложно … и не каждый год. Пробовал «записывать всё и вся» — прослыл занудой.
Формализация отношений рушиться о следующее мнение: «нам нужны просто сроки и суммы, ход умозаключений оставь себе» … Но это же разработка ПО, система учета, необходимость вовлечение сотрудников в процесс?! … Далее как обычно: «мы передумали (столько думать для нас утомительно)», «почему и переделки включены в счет». В итоге «мы от вас устали».
Другой подход – браться только за понятные и простые задачи. Здесь давит конкуренция, и на этом рынке не создать длительных отношений.
Есть гипотеза, что вся эта картина следствие относительной молодости бизнеса в России в целом. Нужно попробовать поработать с «мудрым и старым бизнесом Запада».
И вообще есть же литература. Думаю проблема лишь в маркетинге. (Так и не нашел время прочитать СПИН-продажи (Нил Рекхэм) – но аннотация многообещающая).
И …
Согласен, что такой стиль управления часто просто ВЫГОДЕН.
С годами начинаешь чувствовать «своего клиента». Того где издержки на «администрирование проекта» не съедают дохода и сроков. Остальные не по зубам.
Замечу, что гос. учреждения всегда крупные. И это, с учетом изложенного выше, часто является основным фактором отказа от проекта.
И от себя, и от других не крупных подрядчиков неоднократно слышал «… с бюджетом не работаем!».