Сообщений в теме: 118

[BigDen]

Мое мнение: Разработка ПО в рамках предприятия наиболее выгодное решения для БП самого предприятия, тк. зачастую, во время разработки ТЗ, либо при паралельной работе, как было выше упомянуто, появляется много дополнительных возможностей развития и оптимизации БП предприятия. Равно как и дополнительый инструментарий в виде внешних интерфейсов и разных "связанных" решений, доступен более предприятию чем фрилансеру. Проблему документирования программного кода, как и его комментирования должно решать предприятие, нанимая руководителя проекта, программеры/кодеры могут меняться, но принцип ведения проекта и документирования изменений, опций, функций и прочего - за руководителем от предприятия, такие вопросы нельзя пускать на самотек и оставлять без контроля.

Готовые решения позволяют довести БП предприятия до определенного уровня, но никак не развивать его дальше, т.к. софт меняется и допиливается под новые БП или "хотелки", при нормальном коллективе, фактически постоянно. 

[Rulya_crt]

 

В идеале да, самостоятельная разработка вроде как выгоднее, но при одном но, при наличии квалификации у своих кадров, но не всегда в штате есть сотрудники способные быстро поднять все с нуля, и тогда на помощь приходит его величество аутсорс

А в аутсорсе откуда берутся квалифицированные кадры?

 

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

[asr]

В идеале да, самостоятельная разработка вроде как выгоднее, но при одном но, при наличии квалификации у своих кадров, но не всегда в штате есть сотрудники способные быстро поднять все с нуля, и тогда на помощь приходит его величество аутсорс

А в аутсорсе откуда берутся квалифицированные кадры?

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

Если набирают значит есть квалифицированные кадры?

[Rulya_crt]

 

Если набирают значит есть квалифицированные кадры?

 

 

да, есть, но они работают в компаниях чьим бизнесом является создание софта, а не в компаниях которые пользуются софтом, в этих компаниях все бизнес процессы заточены поп производство софта, и в руководителях сидят люди разбирающиеся в разработке

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

[asr]

Если набирают значит есть квалифицированные кадры?

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

Много слов.
Вопрос простой.
Есть или нету квалифицированные кадры?

[Rulya_crt]

 

Много слов.
Вопрос простой.
Есть или нету квалифицированные кадры?

 

 ответ простой,  есть, но нанимать и содержать их не IT компании сложно и невыгодно

[asr]

Много слов.
Вопрос простой.
Есть или нету квалифицированные кадры?

 ответ простой,  есть, но нанимать и содержать их не IT компании сложно и невыгодно

Так или иначе бизнес их нанимает.
В аутсорсе это происходит через кучу посредников: менеджер проекта, менеждер продаж, менеджер переговоров, главный консультант, вторичный консультант и т.д.
И в чем выгода? Оплачить "труд" десятка посредников?

Сообщение отредактировал asr: 21.12.2015, 16:31:05

[Rulya_crt]

Так или иначе бизнес их нанимает.
В аутсорсе это происходит через кучу посредников: менеджер проекта, менеждер продаж, менеджер переговоров, главный консультант, вторичный консультант и т.д.
И в чем выгода? Оплачить "труд" десятка посредников?

 

 

 выгода в том, что бы купить решение, и наняв джуниора, работать, а не искать квалифицированного сеньёра, тим лида, ждать, условно, пол года на разраработку, три месяца на тестирование, и только потом начинать работать

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

Сообщение отредактировал Rulya_crt: 21.12.2015, 16:38:47

[asr]

Так или иначе бизнес их нанимает.
В аутсорсе это происходит через кучу посредников: менеджер проекта, менеждер продаж, менеджер переговоров, главный консультант, вторичный консультант и т.д.
И в чем выгода? Оплачить "труд" десятка посредников?

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

А готовые решения начинают сразу работать?
Т.е. не проходят тендеры? НЕ выбираются партнеры?
Не тратиться полгода на переписку? Согласование ТЗ? Условий оплаты?
Железо тоже не покупается под "готовое" решение?
Тестирования тоже нету?

Т.е. как колбасу, зашел в магаз, купил и тут же у прилавка можно есть?

[Rulya_crt]

 

А готовые решения начинают сразу работать?
Т.е. не проходят тендеры? НЕ выбираются партнеры?
Не тратиться полгода на переписку? Согласование ТЗ? Условий оплаты?
Железо тоже не покупается под "готовое" решение?
Тестирования тоже нету?

Т.е. как колбасу, зашел в магаз, купил и тут же у прилавка можно есть?

 

 

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

[mda]

любой более-менее серьезный продукт - это не месяцы, а годы теста и развития продукта и соответственные расходы (которые серийный разработчик берет с десятков/сотен/тысяч клиентов)

 

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

 

и потом самый главный минус такого подхода при его якобы гибкости под БП заказчика - это зависимость от ключевого(ых) сотрудников и ГК в этой ситуации не позволяет никак наложить реальную ответственность на работника или удержать его.

у серийного софта по крайней мере есть компания, которой можно заплатить и поддерживать/развивать решение, а вот если убежит разработчик "уникальной системы", вряд ли кто возьмется возится с ней - скажут: "что за фигня? кто так программирует? давайте мы лучше напишем" ))) и круг замкнется )))

[Rulya_crt]

у серийного софта по крайней мере есть компания, которой можно заплатить и поддерживать/развивать решение, а вот если убежит разработчик "уникальной системы", вряд ли кто возьмется возится с ней - скажут: "что за фигня? кто так программирует? давайте мы лучше напишем" ))) и круг замкнется )))

 

Тоже хотел привести подобный аргумент, но вы меня опередили, одним словом как ни крути, а аутсорс рулит

[asr]

у серийного софта по крайней мере есть компания, которой можно заплатить и поддерживать/развивать решение, а вот если убежит разработчик "уникальной системы", вряд ли кто возьмется возится с ней - скажут: "что за фигня? кто так программирует? давайте мы лучше напишем" ))) и круг замкнется )))

Значит у своего софта есть "разработчик".
А у "серийного" софта "разработчика" нету? И он не может убежать из той конторы?

[Rulya_crt]

 

у серийного софта по крайней мере есть компания, которой можно заплатить и поддерживать/развивать решение, а вот если убежит разработчик "уникальной системы", вряд ли кто возьмется возится с ней - скажут: "что за фигня? кто так программирует? давайте мы лучше напишем" ))) и круг замкнется )))

Значит у своего софта есть "разработчик".
А у "серийного" софта "разработчика" нету? И он не может убежать из той конторы?

 

у серийного софта + к разработчику, есть корпоративные правила разработки, есть писатели технической документации, и поэтому софт может разрабатываться кучей разработчиков, без привязки к личности, а собственный разработчик, под управлением менеджеров не смыслящих в разработке, сделает что бы работало, но вряд ли что бы поддерживалось еще кем то кроме него

[asr]

у серийного софта по крайней мере есть компания, которой можно заплатить и поддерживать/развивать решение, а вот если убежит разработчик "уникальной системы", вряд ли кто возьмется возится с ней - скажут: "что за фигня? кто так программирует? давайте мы лучше напишем" ))) и круг замкнется )))

Значит у своего софта есть "разработчик".
А у "серийного" софта "разработчика" нету? И он не может убежать из той конторы?

у серийного софта + к разработчику, есть корпоративные правила разработки, есть писатели технической документации, и поэтому софт может разрабатываться кучей разработчиков, без привязки к личности, а собственный разработчик, под управлением менеджеров не смыслящих в разработке, сделает что бы работало, но вряд ли что бы поддерживалось еще кем то кроме него

Собственно кто мешает посадить двух разработчиков? (Вроде уже пришли к итогу, проблем с кадрами нет)
Или писать тех документацию, хотя бы на минимальном уровне?
Или использовать корпоративные правил разработки?

Сообщение отредактировал asr: 24.12.2015, 13:37:23

[Rulya_crt]

 

Собственно кто мешает посадить двух разработчиков? (Вроде уже пришли к итогу, проблем с кадрами нет)
Или писать тех документацию, хотя бы на минимальном уровне?
Или использовать корпоративные правил разработки?

 

 

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

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

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

[asr]

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

 

На самом деле это не так.

Если продукт сложный, держат у себя десяток допильщиков (группу сопровождения), которые:

1 Переписываются с разработчиками почему то или иное не работает так как надо.

2 Пишут костыли для согласования разных ПО. Вот тут натыкаемся на отсутствие доков, потому как для разных костылей невозможно применить "корпоративные правила" разработки. Каждый костыль уникален, заточен только под свои условия.

Сообщение отредактировал asr: 24.12.2015, 15:19:56

[Rulya_crt]

 

 

На самом деле это не так.

Если продукт сложный, держат у себя десяток допильщиков (группу сопровождения), которые:

1 Переписываются с разработчиками почему то или иное не работает так как надо.

2 Пишут костыли для согласования разных ПО. Вот тут натыкаемся на отсутствие доков, потому как для разных костылей невозможно применить "корпоративные правила" разработки. Каждый костыль уникален, заточен только под свои условия.

 

ну количество допильщиков зависит от изначального объема прилага, условно если прилаг разрабатывали 10 человек, то на допил хватит одного, если разрабатывали 100, то и на поддержку нужно 10, понятно что цифры условные, но в целом картина такая, что бы разработать что то серьезное с ноля, нужна команда,  которую после разработки, нужно распускать, оставив процентов 10 разработчиков, и такую команду на разовый проект собрать тяжело

[mda]

тренд текущего времени - каждый должен заниматься своим профильным делом

 

в текущих реалиях, нанятые в какой-то (не софтверный бизнес) разработчики будут неконтроллируемым звеном, ибо в 99% компаний МСБ нет в руководстве людей, шарящих в IT, программировании, технологиях, субд и тд... и посему в 99% все закончится выбросом "уникальной разработки" через некоторое время на помойку, либо приспособлением пользователей дружить/реанимировать ПО, различными танцами с бубном пока "оно" дышит.

ни о каком росте, масштабированию "уникальной системы" и прочем - речи идти не будет, естественно...

 

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

[asr]

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

 

 

Если будут платить как разработчикам а не как допиливателям никто никуда не уйдет.

Поскольку создать софт это полдела, а его надо еще и продать, а для этого нужны совершенно другие таланты.