Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Зоопарк разных решений по автоматизации и геморрой с их интеграцией — вот единственный работающий подход.
Нельзя все-все автоматизировать с помощью одного решения. Нужно использовать то ПО, которое позволяет вести бизнес лучше, а не выкручивать себе руки.
У любой ERP есть свои сильные стороны, но точно есть и свои слабые. И ни одна ERP идеально не ляжет на конкретный бизнес.
Выходит, что вопрос у вас какой-то теоретический, поскольку вариант «автоматизировать все-все одним» не жизнеспособен.
Нельзя все-все автоматизировать с помощью одного решения. Нужно использовать то ПО, которое позволяет вести бизнес лучше, а не выкручивать себе руки.
У любой ERP есть свои сильные стороны, но точно есть и свои слабые. И ни одна ERP идеально не ляжет на конкретный бизнес.
Выходит, что вопрос у вас какой-то теоретический, поскольку вариант «автоматизировать все-все одним» не жизнеспособен.
Мой вопрос был именно о практике ведения проектов. То, что Вы говорите, достаточно понятно. Может быть, я исходно неясно сформулировал свою мысль — я имел в виду практику, когда на крупный проект ключевой интегратор принципиально не берёт другие компании, и особенно — аналогичные по спектру услуг. Вот именно с таким подходом я сталкивался и считал его логично обоснованным в наших условиях.
Когда понимаешь что скушав эту рыбу можно поперхнутся то лучше дать кусок соседу. Всё самому сделать иногда не выходит, и это не самая худшая практика.
Вот вы спрашивали, что будет через год или два, ничего особенного, второй подрядчик подтянет свою часть а вы свою.
Вот вы спрашивали, что будет через год или два, ничего особенного, второй подрядчик подтянет свою часть а вы свою.
Именно поэтому крупный бизнес, считающий деньги и работающий на перспективу, выбирает индустриальные решения: он покупает не столько программный комплекс, сколько пресловутые «лучшие практики», гарантию отсутствия типовых грабель, о существовании которых он может даже не догадываться на нынешнем этапе развития бизнеса.
Очень спорное утверждение (если, конечно, абстрагироваться и не считать весь пост завуалированной джинсой).
Жаль, что Вы так подумали (про джинсу). Мне в самом деле интересно, как у нас обстоят дела на больших проектах, а то, может, я уже давно от жизни отстал. Я там чуть выше в комментариях скорректировал свой основной вопрос, возможно, я неясно выразился.
Кстати, я наслышан и про случаи переманивания специалистов, задачи которых заключались в затыкании конкретных технологических дырок в проектах. Правильный с точки зрения описанного мной вендора подход говорит о том, что следует не хантить спецов, а обратиться к компании с соответствующей компетенцией (и, конечно, находящейся в экосистеме вендора). А это вам как?
Кстати, я наслышан и про случаи переманивания специалистов, задачи которых заключались в затыкании конкретных технологических дырок в проектах. Правильный с точки зрения описанного мной вендора подход говорит о том, что следует не хантить спецов, а обратиться к компании с соответствующей компетенцией (и, конечно, находящейся в экосистеме вендора). А это вам как?
Современные фреймворки дошли того уровня развития, что написать самому будет дешевле, чем развернуть большое готовое при той же (а то и большей) надежности. При этом это будет bespoke, lightweight и легким в поддержании и, самое главное, в добавлении фич (при условии аккуратных разработчиков). Большинство больших игроков, особенно в e-commerce секторе, это заметили.
При чем применимо не только к .NET-сектору (где всегда были большие и удобные плюшки для сильного уменьшения времени), но и к PHP, Ruby.
При чем применимо не только к .NET-сектору (где всегда были большие и удобные плюшки для сильного уменьшения времени), но и к PHP, Ruby.
Это зависит от размера проекта, как я понимаю. Безусловно, для небольшого интернет-магазина я первый посоветую или Битрикс, или Опенкарт, или Виртумарт с Джумлой — да по сути что угодно, что подойдёт под требования заказчика. Просто когда речь идёт о бизнесе с ежегодным оборотом в 20, 50, 80 миллионов долларов, написать самому не получается — слишком всего много, слишком много надо кодировать бизнес-правил — сдаётся мне, писать самому не хватит ни здоровья, ни времени. Именно поэтому крупные заказчики и выбирают больших вендоров и их партнёров.
А так по Вашей логике и бухгалтерию самому написать можно, зачем 1С покупать )))
А так по Вашей логике и бухгалтерию самому написать можно, зачем 1С покупать )))
Далеко ходить не нужно для примера с вашим бюджетом – X5 Retail Group. И это, поверьте, не исключение. Как раз из-за того, что часто специфика крайне узка, использовать готовое решение – себе дороже (на выходе спустя годы получаесят монстр с кучей надстроек вместо отлаженного продукта).
Чорт, ещё дальше в сторону от моего основного вопроса ушли ))
Ну хорошо, если конкретному бизнесу повезло с айти-директором, а айтидиректор в свою очередь угадал с выбором платформы и (самое главное) с выбором системного архитектора — это очень хорошо. Однако, мне кажется, это исключение. Бизнес — это машина, а части в машине должны быть взаимозаменяемы. Что будет с Вашей самописной системой, если Вы покинете проект?
И почему, если всё так, как Вы говорите, западный рынок крупных е-коммерс систем вполне неплохо себя чувствует? Чего ж, одни дураки там в больших компаниях сидят, что ли, что покупают готовые решения, а не пишут под себя?
Ну хорошо, если конкретному бизнесу повезло с айти-директором, а айтидиректор в свою очередь угадал с выбором платформы и (самое главное) с выбором системного архитектора — это очень хорошо. Однако, мне кажется, это исключение. Бизнес — это машина, а части в машине должны быть взаимозаменяемы. Что будет с Вашей самописной системой, если Вы покинете проект?
И почему, если всё так, как Вы говорите, западный рынок крупных е-коммерс систем вполне неплохо себя чувствует? Чего ж, одни дураки там в больших компаниях сидят, что ли, что покупают готовые решения, а не пишут под себя?
Давайте отвечу на вторую часть вашего вопроса:
Если конкретный человек критичен для системы — это плохая архитектура и ведение бизнеса (говнокод, ноль документации, хорошо модуль знает только один человек и т. д.). Касательно же аутсорса у сертифицированных поставщиков, а также вашего «Чего ж, одни дураки там в больших компаниях сидят, что ли, что покупают готовые решения, а не пишут под себя?» — все очень просто.
Во-первых, аутсорс всегда дороже, чем собственные разработчики (но их нужно найти и собрать команду, а это время). Во-вторых, если подобное делается впервые, естествено желание попробовать существующие продукты (и убедится в их несостоятельности удовлетворить необходимые потребности; как пример, вы бы знали чего стоила интеграция для обмена данными между моей системой и ATOS — я мог сделать все, что угодно, подстроится под любую архитектуру, у них же были одни ограничения). Поэтому, если есть время (обычно около года–полутора для большой системы) грамотные люди выбирают создание своей собственной. Я лично знаю одну компанию (помимо обычных примеров), которая 3 раза пыталась создать свою систему сначала, используя готовые наработки, потому и, так называемых, спецов в экосистеме вендора (и еще у одних). В итоге потеряла 3 года, создала свой IT-отдел (из 4 человек) и сделала собственный продукт, каждый месяц выпиливая новые фичи и реализуя любые хотелки клиентов.
Кстати, я наслышан и про случаи переманивания специалистов, задачи которых заключались в затыкании конкретных технологических дырок в проектах. Правильный с точки зрения описанного мной вендора подход говорит о том, что следует не хантить спецов, а обратиться к компании с соответствующей компетенцией (и, конечно, находящейся в экосистеме вендора). А это вам как?
Если конкретный человек критичен для системы — это плохая архитектура и ведение бизнеса (говнокод, ноль документации, хорошо модуль знает только один человек и т. д.). Касательно же аутсорса у сертифицированных поставщиков, а также вашего «Чего ж, одни дураки там в больших компаниях сидят, что ли, что покупают готовые решения, а не пишут под себя?» — все очень просто.
Во-первых, аутсорс всегда дороже, чем собственные разработчики (но их нужно найти и собрать команду, а это время). Во-вторых, если подобное делается впервые, естествено желание попробовать существующие продукты (и убедится в их несостоятельности удовлетворить необходимые потребности; как пример, вы бы знали чего стоила интеграция для обмена данными между моей системой и ATOS — я мог сделать все, что угодно, подстроится под любую архитектуру, у них же были одни ограничения). Поэтому, если есть время (обычно около года–полутора для большой системы) грамотные люди выбирают создание своей собственной. Я лично знаю одну компанию (помимо обычных примеров), которая 3 раза пыталась создать свою систему сначала, используя готовые наработки, потому и, так называемых, спецов в экосистеме вендора (и еще у одних). В итоге потеряла 3 года, создала свой IT-отдел (из 4 человек) и сделала собственный продукт, каждый месяц выпиливая новые фичи и реализуя любые хотелки клиентов.
Справедливости ради, отмечу один факт: свою систему никогда не нужно начать писать, если нет человека, который легко разбирает на кусочки бизнес-кейсы, знает, как сделать удобно и правильно, что приоритетно и т. д. Такой человек действительно будет критичен для системы и бизнеса (по крайней мере до момента запуска + в идеале, года после этого).
Но грамотный работодатель, если нашел такого человека, сделает все, чтобы не потерять (умный человек возьмет его в долю, предоставит опционы и т. д., а не будет держать с зп в 150 на руки).
Но грамотный работодатель, если нашел такого человека, сделает все, чтобы не потерять (умный человек возьмет его в долю, предоставит опционы и т. д., а не будет держать с зп в 150 на руки).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практика ведения крупных проектов от Oracle