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

[biocide]

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

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

[andrey_p]

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

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

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

[biocide]

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

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

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

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

[andrey_p]

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

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

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

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

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

[biocide]

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

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

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

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

 

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

 

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

[rus]

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

[andrey_p]

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

 

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

 

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

 

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

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

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

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

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

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

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

 

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

[land]

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

[biocide]

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

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

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

 

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

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

[andrey_p]

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

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

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

 

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

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

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

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