Перейти к публикации

Архивировано

Эта тема находится в архиве и закрыта для публикации сообщений.

biocide

Российский менеджмент и стиль лидерства: наблюдения, мнение и рекомендации

Рекомендованные сообщения

Если задача не большая и узко специализированная может. Это я не про себя конечно, но один грамотный архитектор, может написать и продумать лучше, чем 10 студентов в outsourse в конторе на откатах. Вы меня понимаете :)

Это да. Но слово "для других бизнесов" уже говорило что это уже не ваш случай.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это да. Но слово "для других бизнесов" уже говорило что это уже не ваш случай.

Ну , скажем так. Было бы не 2-ва, а 3-ри месяца на разработку и не один бы я делал, а добавили ещё кого нить!

Зато тормоза и проблемы самим можно было разруливать, стоимость была бы до ляма. Везде есть плюсы и минусы))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну , скажем так. Было бы не 2-ва, а 3-ри месяца на разработку и не один бы я делал, а добавили ещё кого нить!

Зато тормоза и проблемы самим можно было разруливать, стоимость была бы до ляма. Везде есть плюсы и минусы))

Вот это уже говорит не профи :)

Самописные системы всегда неэффективны когда есть стандартные решение и требует масштабирование.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот это уже говорит не профи :)

Самописные системы всегда неэффективны когда есть стандартные решение и требует масштабирование.

Я раннее говорил,у каждого подхода есть минусы и плюсы. Масштабируемость, зависит от архитектора.

Простой  пример для систем. Идентификаторы (уникальные значения в базе). Если проектировщик сделает числовые поля (bigint), то да совместимость с другими системами не очень. А если guid поля (newid в MSSQL), то проблем переноса не будет. Или другой пример интеграция, да если процедуры или файлы не очень, а если веб-сервисы изначально, для обмена с другими системами, то это уже другая песня)) У самописных систем, как правило, это скорость и дешевизна разработки, это полный прогиб под бизнес, да масштабируемость и универсальность порой страдает!

Но не бывает все плохо или хорошо, везде есть плюсы и минусы! Иначе бы везде SAP (у кого деньги есть) или 1-С ставили все!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я раннее говорил,у каждого подхода есть минусы и плюсы. Масштабируемость, зависит от архитектора.

Простой  пример для систем. Идентификаторы (уникальные значения в базе). Если проектировщик сделает числовые поля (bigint), то да совместимость с другими системами не очень. А если guid поля (newid в MSSQL), то проблем переноса не будет. Или другой пример интеграция, да если процедуры или файлы не очень, а если веб-сервисы изначально, для обмена с другими системами, то это уже другая песня)) У самописных систем, как правило, это скорость и дешевизна разработки, это полный прогиб под бизнес, да масштабируемость и универсальность порой страдает!

Но не бывает все плохо или хорошо, везде есть плюсы и минусы! Иначе бы везде SAP (у кого деньги есть) или 1-С ставили все!

Проблемы переноса будут. Потому что под твой guid нужно согласовать форматы переноса, решить как будут решаться коллизии, кто это будет делать и мониторить. Утвердить регламент. Отрабатывать каждый раз при модификации систем. И с увеличением взаимодействующих систем расходы растут именно в геометрической прогрессии. Стоимость владения систем целиком может разниться от мировоззрения отдельно взятого программиста.

 

Мало того при внедрении системы - могут преследоваться и стратегические задачи. Например руководителю важно произвести изменения бизнес-процессов, а повседневных механизмов управления изменениями в организации нет (что у нас очень часто случается). И здесь не нужен полный прогиб под бизнес - здесь прогер должен быть классным аналитиком чтобы делать не как просют, а как это будет эффективней. Или например, руководитель понимает что начинает зависеть от "уникального" спеца который еще и права начинает качать.

 

У самописных систем очень много неопределенностей помноженные на человеческий фактор, которые как правило складываются в минусы рано или поздно при масштабных задачах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот человеческий фактор это всегда зло. Да, гении это дешевле и эффективнее на коротких дистанциях, но потом случается всякое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблемы переноса будут. Потому что под твой guid нужно согласовать форматы переноса, решить как будут решаться коллизии, кто это будет делать и мониторить. Утвердить регламент. Отрабатывать каждый раз при модификации систем. И с увеличением взаимодействующих систем расходы растут именно в геометрической прогрессии. Стоимость владения систем целиком может разниться от мировоззрения отдельно взятого программиста.

 

Мало того при внедрении системы - могут преследоваться и стратегические задачи. Например руководителю важно произвести изменения бизнес-процессов, а повседневных механизмов управления изменениями в организации нет (что у нас очень часто случается). И здесь не нужен полный прогиб под бизнес - здесь прогер должен быть классным аналитиком чтобы делать не как просют, а как это будет эффективней. Или например, руководитель понимает что начинает зависеть от "уникального" спеца который еще и права начинает качать.

 

У самописных систем очень много неопределенностей помноженные на человеческий фактор, которые как правило складываются в минусы рано или поздно при масштабных задачах.

 

Тээкс насчет проблем переноса, отчасти согласен. Мы имеем признак ключевого поля, которое всегда уникально в текущей системе, надо слить с другой, у которой другой идентификатор, опираясь на существующий - генерим новый идентификатор (через sequence например) для каждой записи и приемлимый для новой системы или сбоку разворачиваем базу целиком и делаем некое универсальное представление. Решений масса!

Изменения бизнес-процессов, обычно инициируется бизнесом, а как это будут делать в рамках конкретной системы - все равно. Опять же, если при грамотной спроектированной системы, будет четкая логическая и физическая модель, сделать можно все что угодно. А вот в покупных, могут быть проблемы, в ядро как правило влезать нельзя, а за координальные изменения придётся выложить кругленькую сумму! 

Ну про зависимость от спеца отчасти согласен, но при грамотном подходе, это лечится четким документированием, контролем версий и взаимозаменяемостью программистов. Убедил? :)

И все таки останусь при своем мнении, в зависимости от задач - выбирается то или иное решение и самописное или универсальное, решается в каждом конкретном случае!

Вот человеческий фактор это всегда зло. Да, гении это дешевле и эффективнее на коротких дистанциях, но потом случается всякое.

Гении нужны не везде и даже решения гениев должны быть с документацией и с контролем версий, с аналитиками, тестировщиками и т.д.

Почитайте - проект Одноклассники. Казалось бы крупный проект, mail.ru -бабла немерянно, взяли бы готовое, ан нет. У них самописные решения и достаточно эффективные! Почитайте статьи про их архитектуру :)

 

http://www.insight-it.ru/masshtabiruemost/arkhitektura-odnoklassnikov/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

видать этот профессор работал с "узким кругом ограниченных" руководителей. Большинство первых руководителей предприятий чьи-то ставленники и их задача быть лояльными в первую очередь, а во вторую все свое руководство они видят в том, чтобы вовремя (как им кажется) послать матом и отчитаться наверх. Рассуждать о каком-то экономическом анализе  с ними просто бессмысленно - видишь тупой недоуменный взгляд. На вопрос "какие показатели вам нужны для оценки деятельности вашего предприятия?" они ответить не могут. Ну и соответственно их критерии для отбора подчиненных точно такие же. Лично я наблюдаю жуткую деградацию руководящего управленческого состава. Их обучать нечему по определению...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тээкс насчет проблем переноса, отчасти согласен. Мы имеем признак ключевого поля, которое всегда уникально в текущей системе, надо слить с другой, у которой другой идентификатор, опираясь на существующий - генерим новый идентификатор (через sequence например) для каждой записи и приемлимый для новой системы или сбоку разворачиваем базу целиком и делаем некое универсальное представление. Решений масса!

Изменения бизнес-процессов, обычно инициируется бизнесом, а как это будут делать в рамках конкретной системы - все равно. Опять же, если при грамотной спроектированной системы, будет четкая логическая и физическая модель, сделать можно все что угодно. А вот в покупных, могут быть проблемы, в ядро как правило влезать нельзя, а за координальные изменения придётся выложить кругленькую сумму!

Понимаешь ли - высококлассный прогер с опытом высококлассного аналитика - как бриллиант. Его содержание очень дорого, и оно растет непропорционально росту доходов предприятия как правило.

 

Ну про зависимость от спеца отчасти согласен, но при грамотном подходе, это лечится четким документированием, контролем версий и взаимозаменяемостью программистов. Убедил? :)

Приобретение данных компетенций дороже чем просто покупка стандартизированного решения. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

видать этот профессор работал с "узким кругом ограниченных" руководителей. Большинство первых руководителей предприятий чьи-то ставленники и их задача быть лояльными в первую очередь, а во вторую все свое руководство они видят в том, чтобы вовремя (как им кажется) послать матом и отчитаться наверх. Рассуждать о каком-то экономическом анализе  с ними просто бессмысленно - видишь тупой недоуменный взгляд. На вопрос "какие показатели вам нужны для оценки деятельности вашего предприятия?" они ответить не могут. Ну и соответственно их критерии для отбора подчиненных точно такие же. Лично я наблюдаю жуткую деградацию руководящего управленческого состава. Их обучать нечему по определению...

Да про кумовство я писал раннее в другой теме, это проблема России!

Понимаешь ли - высококлассный прогер с опытом высококлассного аналитика - как бриллиант. Его содержание очень дорого, и оно растет непропорционально росту доходов предприятия как правило.

 

Приобретение данных компетенций дороже чем просто покупка стандартизированного решения. :)

Ну зачем, есть хорошие аналитики. Я вот сейчас например выжимаю все что можно из Db2 для Web клиента, а аналитик выжимает от бизнеса точные хотелки, примерные данные, что должны получиться и что он хочет видеть. Пока хорошо получается, премии получаем))

Ну пока, что хорошие программисты обходятся дешевле, чем лицензия SAP, программисты ABAP, аналитики, внедренцы и т.д. в частности.

Да и у САП не на все решения есть))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Заходи к нам в Telegram!

  • Интересные предложения

×
×
  • Создать...