13 июля 2006
Само- или Тамореализация?
Опубликовано в журнале "Компьютерра" №25-26 от 11 июля 2006 года
http://www.computerra.ru/277114/
На круглом столе, который проводил Сергей Рыжиков на Microsoft WebDevCon’06, обсуждалась тема о заказе разработок веб-приложений. Кому их заказывать - внутреннему подразделению компании или стороннему разработчику? Как их разрабатывать - с нуля или на основе тиражных разработок? Правда, всегда есть еще и пятый вариант - ничего не делать.
Вполне естественно, что с веб-приложений обсуждение плавно перетекло на любые IT-системы. Так как время круглого стола на конференции ограничено, то почему бы не продолжить обсуждение в журнале. Для затравки могу примерно повторить свою позицию применительно к уникальным веб-проектам. Что делать, если у вас возникла уникальная или инновационная технологическая бизнес-идея? Примерных аналогов в мире раз-два и обчелся, на тиражных продуктах сверху надстроить что-нибудь вряд ли получится. Выхода другого нет, как писать систему с нуля.
Главное - погасить первый душевный порыв и не писать систему самому на коленке. Естественно, некий прототип вы напишете, установите его на виртуальном хостинге, "это" даже будет работать на ограниченном числе клиентов, транзакций или что вы там будете обрабатывать. Но как только начнется настоящая работа, реальная нагрузка на систему, вы начнете работать одновременно директором, бухгалтером, системным администратором, поднимающим ночью упавший сервер, программистом, срочно латающим дыры в безопасности, логистом и бог знает кем еще. В сутках, конечно, 24 часа, но явно не 48. Я думаю, все интернетчики это проходили, а некоторые до сих пор думают, что это нормально.
Итак, страстей порыв погашен, приступаем к выбору вариантов. Вариантов, собственно, не так и много. Можно организовать у себя группу разработчиков, выбрать из них или нанять правильного руководителя проекта, объяснить ему задачу, поставить срок для запуска (предположим, шесть месяцев) и начать платить зарплату. Так как, по одному из принципов Паркинсона, "работа занимает все отведенное на нее время", то через шесть месяцев от руководителя проекта поступит предложение удлинить срок еще на шесть месяцев. Один мой знакомый разработчик вполне серьезно утверждал, что срок, объявленный программистами, надо умножать на 3,14. Через год система запустится, но так как во внутреннем (на два листа) техническом задании не были оговорены всякие мелочи, то еще через полгода система будет сдана в опытную эксплуатацию. За это время ряды коллектива разработчиков, подучившись, поредеют в связи с переходом на более высокооплачиваемую работу. Поэтому года через три руководитель проекта, кряхтя и матерясь, будет разбираться сам в коде, чтобы объяснить его четвертому составу разработчиков. Это совершенно не отрицает того факта, что система получится хорошая и рабочая.
Оставшийся второй вариант - заказ системы стороннему разработчику. Да, конечно, все проблемы со сроками, текучестью кадров и прочими пертурбациями, описанные выше, будут присутствовать. Но ведь вы за это уже не платите зарплату, вы платите по договору за выполненные работы. Вот и оговаривайте в договоре штрафы, неустойки, сроки и прочие взаимные обязательства. Оговаривайте мелочи, которые можно продумать заранее, в подробном техническом задании. Да, дополнительные работы обязательно будут - мало ли что вы забыли в начале пути. Так оговаривайте их условия в дополнительных соглашениях. В этом случае все проблемы, описанные выше, уже становятся не вашими, а директора компании-разработчика. Причем если эта компания ведет несколько проектов, то она сама и обеспечит заменяемость разработчиков, внедренцев, технических писателей. Кстати, а вы не забыли заказать документацию сопровождения на систему?
Да, в описанных вариантах совершенно очевидно, что по деньгам первый вариант выгоднее. Но только первые пару лет, к сожалению. Потом стоимость сопровождения и доработки системы настолько возрастет, что следующую систему вы, скорее всего, будете заказывать у сторонней компании. Выбирать эту компанию вы будете очень внимательно, по крайней мере из десятка предложенных. И их портфолио изучать, и честный тендер между ними устраивать. Эти выводы, разумеется, только на основе моего опыта разработки различных приложений и только, повторюсь, в случае уникальных систем.
О системах, которые можно построить, надстроить, настроить из тиражных продуктов, можем поговорить в одной из следующих колонок. Самим это делать или довериться опытной компании? Нужно ли учить у себя людей, умеющих настраивать тиражный продукт, если вы уже заказали всю работу сторонней фирме? Вопросов много, и я с удовольствием, как обычно, их прочту в письмах или в комментариях в моем блоге.
http://www.computerra.ru/277114/
На круглом столе, который проводил Сергей Рыжиков на Microsoft WebDevCon’06, обсуждалась тема о заказе разработок веб-приложений. Кому их заказывать - внутреннему подразделению компании или стороннему разработчику? Как их разрабатывать - с нуля или на основе тиражных разработок? Правда, всегда есть еще и пятый вариант - ничего не делать.
Вполне естественно, что с веб-приложений обсуждение плавно перетекло на любые IT-системы. Так как время круглого стола на конференции ограничено, то почему бы не продолжить обсуждение в журнале. Для затравки могу примерно повторить свою позицию применительно к уникальным веб-проектам. Что делать, если у вас возникла уникальная или инновационная технологическая бизнес-идея? Примерных аналогов в мире раз-два и обчелся, на тиражных продуктах сверху надстроить что-нибудь вряд ли получится. Выхода другого нет, как писать систему с нуля.
Главное - погасить первый душевный порыв и не писать систему самому на коленке. Естественно, некий прототип вы напишете, установите его на виртуальном хостинге, "это" даже будет работать на ограниченном числе клиентов, транзакций или что вы там будете обрабатывать. Но как только начнется настоящая работа, реальная нагрузка на систему, вы начнете работать одновременно директором, бухгалтером, системным администратором, поднимающим ночью упавший сервер, программистом, срочно латающим дыры в безопасности, логистом и бог знает кем еще. В сутках, конечно, 24 часа, но явно не 48. Я думаю, все интернетчики это проходили, а некоторые до сих пор думают, что это нормально.
Итак, страстей порыв погашен, приступаем к выбору вариантов. Вариантов, собственно, не так и много. Можно организовать у себя группу разработчиков, выбрать из них или нанять правильного руководителя проекта, объяснить ему задачу, поставить срок для запуска (предположим, шесть месяцев) и начать платить зарплату. Так как, по одному из принципов Паркинсона, "работа занимает все отведенное на нее время", то через шесть месяцев от руководителя проекта поступит предложение удлинить срок еще на шесть месяцев. Один мой знакомый разработчик вполне серьезно утверждал, что срок, объявленный программистами, надо умножать на 3,14. Через год система запустится, но так как во внутреннем (на два листа) техническом задании не были оговорены всякие мелочи, то еще через полгода система будет сдана в опытную эксплуатацию. За это время ряды коллектива разработчиков, подучившись, поредеют в связи с переходом на более высокооплачиваемую работу. Поэтому года через три руководитель проекта, кряхтя и матерясь, будет разбираться сам в коде, чтобы объяснить его четвертому составу разработчиков. Это совершенно не отрицает того факта, что система получится хорошая и рабочая.
Оставшийся второй вариант - заказ системы стороннему разработчику. Да, конечно, все проблемы со сроками, текучестью кадров и прочими пертурбациями, описанные выше, будут присутствовать. Но ведь вы за это уже не платите зарплату, вы платите по договору за выполненные работы. Вот и оговаривайте в договоре штрафы, неустойки, сроки и прочие взаимные обязательства. Оговаривайте мелочи, которые можно продумать заранее, в подробном техническом задании. Да, дополнительные работы обязательно будут - мало ли что вы забыли в начале пути. Так оговаривайте их условия в дополнительных соглашениях. В этом случае все проблемы, описанные выше, уже становятся не вашими, а директора компании-разработчика. Причем если эта компания ведет несколько проектов, то она сама и обеспечит заменяемость разработчиков, внедренцев, технических писателей. Кстати, а вы не забыли заказать документацию сопровождения на систему?
Да, в описанных вариантах совершенно очевидно, что по деньгам первый вариант выгоднее. Но только первые пару лет, к сожалению. Потом стоимость сопровождения и доработки системы настолько возрастет, что следующую систему вы, скорее всего, будете заказывать у сторонней компании. Выбирать эту компанию вы будете очень внимательно, по крайней мере из десятка предложенных. И их портфолио изучать, и честный тендер между ними устраивать. Эти выводы, разумеется, только на основе моего опыта разработки различных приложений и только, повторюсь, в случае уникальных систем.
О системах, которые можно построить, надстроить, настроить из тиражных продуктов, можем поговорить в одной из следующих колонок. Самим это делать или довериться опытной компании? Нужно ли учить у себя людей, умеющих настраивать тиражный продукт, если вы уже заказали всю работу сторонней фирме? Вопросов много, и я с удовольствием, как обычно, их прочту в письмах или в комментариях в моем блоге.
Comments:
<< Home
А как насчет фобий того, кто придумал уникальный проект? Боязнь, того что идею проекта просто украдут? Решение проблемы - авторские права?
# posted by 
: 12:30 PM
: 12:30 PM
Уникальность проекта оценивается очень легко. Надо ответить на вопрос: "Что будет если опубликовать его в газете (интернете)?"
Если ответ - "Ни в коем случае!", то...
Автор блога говорит: "Скучно!"...
...И что он советует?
Если ответ - "Ни в коем случае!", то...
Автор блога говорит: "Скучно!"...
...И что он советует?
# posted by : 2:54 PM
: 2:54 PM
>Автор блога говорит: "Скучно!"...
>...И что он советует?
Это вы о чем? Человек спрашивает, как избавиться от фобий - ответ, лечить проверенными средствами. Каждый считает, что он придумал уникальный проект и он гений. Это нормально. Если автор проекта так не считает, то это совсем другая история :))) Тогда и ответ другой - делайте быстро. Это я уже где-то говорил :)
>...И что он советует?
Это вы о чем? Человек спрашивает, как избавиться от фобий - ответ, лечить проверенными средствами. Каждый считает, что он придумал уникальный проект и он гений. Это нормально. Если автор проекта так не считает, то это совсем другая история :))) Тогда и ответ другой - делайте быстро. Это я уже где-то говорил :)
Насчет фобий это к психотерапевтам. Задавая вопрос я не имел ввиду вопрос 4matic
Я о том, что делать с ПО в случае если проект легко воспроизводим?
Чем больше уникальности, тем труднее воспроизвести. И с ПО ясно как быть. Об этом можно хорошо и складно писать. Я понимаю, что более мелкие проекты - скучны и финансово малоинтересны.
Но!
Большинство проектов именно такие. Большинство ими занимается. Про ИТ проекты еще слышно, их называют «самописное ПО», а про веб что-то я невстречал рассуждений.
Автор проекта - простой и здравомыслящий человек. Он нашел нишу, хочет быть серенькой мышкой, деньжат подзаработать.
Что делать быстро? Купить математику не у кого, либо неадекватная стоимость. Заказывать разработку или разрабатывать своими силами? И вообще можно ли это сделать быстро?
Я о том, что делать с ПО в случае если проект легко воспроизводим?
Чем больше уникальности, тем труднее воспроизвести. И с ПО ясно как быть. Об этом можно хорошо и складно писать. Я понимаю, что более мелкие проекты - скучны и финансово малоинтересны.
Но!
Большинство проектов именно такие. Большинство ими занимается. Про ИТ проекты еще слышно, их называют «самописное ПО», а про веб что-то я невстречал рассуждений.
Автор проекта - простой и здравомыслящий человек. Он нашел нишу, хочет быть серенькой мышкой, деньжат подзаработать.
Что делать быстро? Купить математику не у кого, либо неадекватная стоимость. Заказывать разработку или разрабатывать своими силами? И вообще можно ли это сделать быстро?
# posted by : 6:18 PM
: 6:18 PM
Понял :)
Это скорее как раз вторая часть - о настройке тиражных продуктов. Тот же Битрикс-Старт стоит 200 баксов, если мы говорим о веб-приложениях. И уж явно человек, который смог бы написать сам проект, сможет настроить его под себя. Есть и бесплатные CMS-ки, но для более продвинутых. Главное, сэкономить время на реализацию, а не пытаться изобрести велосипед. Я постараюсь написать об этом, что собственно и обещал. Мысль, вроде бы банальна, но тем не менее масса людей продолжают тратить время на изобретение велосипеда, вместо того чтобы начать зарабатывать на проекте. Что, кстати, еще не факт (заработок), и потому надо это выяснить по-возможности быстро, работает прототип на заработок или нет. Отрывочно, но в колонке попробую поподробнее.
Это скорее как раз вторая часть - о настройке тиражных продуктов. Тот же Битрикс-Старт стоит 200 баксов, если мы говорим о веб-приложениях. И уж явно человек, который смог бы написать сам проект, сможет настроить его под себя. Есть и бесплатные CMS-ки, но для более продвинутых. Главное, сэкономить время на реализацию, а не пытаться изобрести велосипед. Я постараюсь написать об этом, что собственно и обещал. Мысль, вроде бы банальна, но тем не менее масса людей продолжают тратить время на изобретение велосипеда, вместо того чтобы начать зарабатывать на проекте. Что, кстати, еще не факт (заработок), и потому надо это выяснить по-возможности быстро, работает прототип на заработок или нет. Отрывочно, но в колонке попробую поподробнее.
Мне приятно слышать, что Вы предлагаете разные стратегии для проектов разного масштаба. Насколько я понял, для больших проектов нужно использовать аутсорсинг, для малых - типовые решения.
Выбор стратегии несоизмеримой с целью проекта приводит к "попытке изобрести велосипед". Было бы интересно услышать от Вас что-нибудь на эту тему в печати.
В предлагаемых стратегиях нет места для процесса разработки на собственной территории.
Аутсорсинг для больших проектов имеет плюсы. О них Вы хорошо рассказываете. И у него есть существенный минус. В "хороших" web проектах, аутсорсинг - это форма партнерства, очень тесная, основанная на доверии и… как следствие, видимом взаимовыгодном сотрудничестве. Другими словами, совместное ведение бизнеса. А проще говоря - заказывая разработку вы отдаете часть свего будущего бизнеса.
Как мне кажется, Вы об этом знаете и умалчиваете. Трудно отказаться от Битрикса, если на нем работает бизнес. Можно, но сколько это будет стоить нервов! Намного больше, чем увольнение "своих" программистов. И в него, а точнее в людей, которым заказали систему, будет уходить прибыль проекта, в случае непредвиденных обстоятельств с ними. Может быть лучше платить свим? Или их честно считать таковыми?
Теперь представьте, что мне скажет владелец проекта на предложение поделиться бизнесом на стартапе. 50 на 50? 20 на 70 Что бы сказали Вы?
Кстати, про 3.14. Лет 10 назад это дураки услышали звон, но не знали о чем он. Другие всегда брали 4…. и молчали.
Первый этап - разработка прототипа, сейчас модно говорить бета. Она точно будет кривой. Многих программистов уволили только за то, что они честно выложились в ней. Глупо на них сваливать всю вину. Из этой позиции есть три пути к закрытию проекта.
Умно переходить ко второму - латание ошибок и тд, и третьему этапу - сопровождению. До этих этапов доходят 4 из 10. Они то и рассказывают про эмпирическое 3. Они считают это успешным проектом. Для них все рухнуло на этапе сопровождения. Это катастрофа либо для заказчика, либо подрядчика. Кто первый. Он
Четвертый этап прошли единицы - сворачивание системы…
… и развертываение новой.
Итак в малых проектах Вы критерием взяли время. И может быть к нему добавить стоимость? Как со священной коровой быть?
Выбор стратегии несоизмеримой с целью проекта приводит к "попытке изобрести велосипед". Было бы интересно услышать от Вас что-нибудь на эту тему в печати.
В предлагаемых стратегиях нет места для процесса разработки на собственной территории.
Аутсорсинг для больших проектов имеет плюсы. О них Вы хорошо рассказываете. И у него есть существенный минус. В "хороших" web проектах, аутсорсинг - это форма партнерства, очень тесная, основанная на доверии и… как следствие, видимом взаимовыгодном сотрудничестве. Другими словами, совместное ведение бизнеса. А проще говоря - заказывая разработку вы отдаете часть свего будущего бизнеса.
Как мне кажется, Вы об этом знаете и умалчиваете. Трудно отказаться от Битрикса, если на нем работает бизнес. Можно, но сколько это будет стоить нервов! Намного больше, чем увольнение "своих" программистов. И в него, а точнее в людей, которым заказали систему, будет уходить прибыль проекта, в случае непредвиденных обстоятельств с ними. Может быть лучше платить свим? Или их честно считать таковыми?
Теперь представьте, что мне скажет владелец проекта на предложение поделиться бизнесом на стартапе. 50 на 50? 20 на 70 Что бы сказали Вы?
Кстати, про 3.14. Лет 10 назад это дураки услышали звон, но не знали о чем он. Другие всегда брали 4…. и молчали.
Первый этап - разработка прототипа, сейчас модно говорить бета. Она точно будет кривой. Многих программистов уволили только за то, что они честно выложились в ней. Глупо на них сваливать всю вину. Из этой позиции есть три пути к закрытию проекта.
Умно переходить ко второму - латание ошибок и тд, и третьему этапу - сопровождению. До этих этапов доходят 4 из 10. Они то и рассказывают про эмпирическое 3. Они считают это успешным проектом. Для них все рухнуло на этапе сопровождения. Это катастрофа либо для заказчика, либо подрядчика. Кто первый. Он
Четвертый этап прошли единицы - сворачивание системы…
… и развертываение новой.
Итак в малых проектах Вы критерием взяли время. И может быть к нему добавить стоимость? Как со священной коровой быть?
# posted by : 2:09 AM
: 2:09 AM
>Другими словами, совместное ведение бизнеса. А проще говоря - заказывая разработку вы отдаете часть свего будущего бизнеса.
И, наоборот, участвуете, в каком-то смысле, в их будущем бизнесе. Если вместе с вашим проектом они возьмут еще парочку аналогичных, это позволит аутсорсинговой команде развиваться до выпуска тиражных решений. С командой внутри такого произойти не может принципиально. Если и произойдет, то она выделится из вас и, фактически, вы совместно перейти к первому варианту.
>Итак в малых проектах Вы критерием взяли время. И может быть к нему добавить стоимость? Как со священной коровой быть?
Естественно, уменьшили время реализации, увеличили стоимость. Выход один, не доходить до маразма ("девять беременных не могут выносить ребенка за месяц") и искать компромисс. Написать себе формулу, состоящую из нескольких параметров - уровень тиражного продукта, его стоимость, квалификация программистов-настройщиков и доработчиков нужных функций, их стоимость, и попытаться выйти с помощью метода "математического тыка" на оптимум по Парето :)
И, наоборот, участвуете, в каком-то смысле, в их будущем бизнесе. Если вместе с вашим проектом они возьмут еще парочку аналогичных, это позволит аутсорсинговой команде развиваться до выпуска тиражных решений. С командой внутри такого произойти не может принципиально. Если и произойдет, то она выделится из вас и, фактически, вы совместно перейти к первому варианту.
>Итак в малых проектах Вы критерием взяли время. И может быть к нему добавить стоимость? Как со священной коровой быть?
Естественно, уменьшили время реализации, увеличили стоимость. Выход один, не доходить до маразма ("девять беременных не могут выносить ребенка за месяц") и искать компромисс. Написать себе формулу, состоящую из нескольких параметров - уровень тиражного продукта, его стоимость, квалификация программистов-настройщиков и доработчиков нужных функций, их стоимость, и попытаться выйти с помощью метода "математического тыка" на оптимум по Парето :)
> И, наоборот, участвуете, в каком-то смысле, в их будущем бизнесе.
В какой форме закрепляется ваше участие в из бизнесе? Есть более точное определение этой стратегии. :)
>Если вместе с вашим проектом они возьмут еще парочку аналогичных...
Если в начале проекта это мысль допускается, то надо следовать Вашим же советам - надо покупать уже готовый продукт. Зачем тогда нам вообще связваться с заказной разработкой?
Что делать если они не смогут (не получится, не захотят) найти "аналогичные" проекты?
В какой форме закрепляется ваше участие в из бизнесе? Есть более точное определение этой стратегии. :)
>Если вместе с вашим проектом они возьмут еще парочку аналогичных...
Если в начале проекта это мысль допускается, то надо следовать Вашим же советам - надо покупать уже готовый продукт. Зачем тогда нам вообще связваться с заказной разработкой?
Что делать если они не смогут (не получится, не захотят) найти "аналогичные" проекты?
# posted by : 10:26 AM
: 10:26 AM
Формы могут быть разные, опционы на участие в бизнесе, специальные скидки в будущем для вас, главное договориться в начале пути :)
А насчет готового продукта, так мы же в начале уже договорились, что его и нет, либо он очень дорог.
Относительно того, что не смогут найти другие проекты - значит неправильных партнеров вы выбрали, и вам не повезло. Плохо выбирали партнеров по бизнесу. Но, естественно, это возможно.
P.S. Трудно разговаривать с анонимом. В первую очередь, так как непонятен ваш опыт.
А насчет готового продукта, так мы же в начале уже договорились, что его и нет, либо он очень дорог.
Относительно того, что не смогут найти другие проекты - значит неправильных партнеров вы выбрали, и вам не повезло. Плохо выбирали партнеров по бизнесу. Но, естественно, это возможно.
P.S. Трудно разговаривать с анонимом. В первую очередь, так как непонятен ваш опыт.
У систем, сделанных на основе тиражируемых продуктов, есть один ОЧЕНЬ существенный минус.
Компаниям, которые занимаются такими системами, интересны максимально стандартные типовые задачи, которые можно решать на потоке.
Как только ваша задача перерастает рамки типичного интернет-магазина, начинаются проблемы - их ядро не может то, их ядро не может это... Надо доделывать ядро... система этого не может, потому что это универсальная система.
Компания начинает уделять вашей компании все меньше времени, развитие проекта притормаживается за счет большой инерции "тиражируемого продукта".
И в итоге вы все равно приходите к необходимости своей команды.
Компаниям, которые занимаются такими системами, интересны максимально стандартные типовые задачи, которые можно решать на потоке.
Как только ваша задача перерастает рамки типичного интернет-магазина, начинаются проблемы - их ядро не может то, их ядро не может это... Надо доделывать ядро... система этого не может, потому что это универсальная система.
Компания начинает уделять вашей компании все меньше времени, развитие проекта притормаживается за счет большой инерции "тиражируемого продукта".
И в итоге вы все равно приходите к необходимости своей команды.
# posted by : 10:47 AM
: 10:47 AM
Команде настройщиков? Почему бы и нет... Но не писателей кода. И все равно, в случае вырастания системы до большой(а если она развивается, она растет) я все равно упрямый сторонник аутсорсинга. Чем больше денег обрабатывает система, тем больше хочется уменьшить зависимость от личностных факторов при ее масштабируемости. Собственно, колонка уже написана. Отложим продолжение спора до следующей недели :)
777
Коллеги, давайте попробуем ближе к теме и аргументам затронутым в статье.
Сначала по нестыковкам.
В первой части, когда рассматривается возможность самостоятельной разработки, показана фирма, которая нанимает цтирую "правильного руководителя проекта", после чего оказывается, что приступили к проекту с ТЗ "на два листа".
Тут либо нужно говорить о некомпетентном руководителе проекта (как вариант отсутствие на рынке и другие сложности), либо я непонимаю, как все описанные проблемы возможны при Правильном руководстве...Может у автора Собственное видение "правильного руководства"?
Но самое интересное, на мой взгляд это решение, которое предлагается дальше, когда речь заходит об аутсорсинге, опять цитата:
"Оговаривайте мелочи, которые можно продумать заранее, в подробном техническом задании"... Супер!Даже комментировать на мой взгляд нечего.
А теперь всё таки добавим конструктива.
Что бы хотелось увидеть в такой вот статье.
1.Оба варианта для того что бы их можно было сравнивать должны базироваться на одних исходных условиях.
2.Несколько размыто выделен в начале тип проекта. Ну уникальный, но по хорошему ведь в сатье рассмотрены сложности с реализацией. Так что тут бы определится вначале, что мы и для чего собираемся делать...
А теперь выскажу своё мнение по затронутому вопросу.
Не буду проходится по теме аутсорсинга, плюсах и минусах, о тех рисках, что избегаем при таком подходе и тех что приобретаем.
Лично моё мнение, что аутсорсинг должен быть неполным. Любые критичные для бизнеса моменты должны оставаться в компании.
Отдавать на сторону проект, можно только Прооверенному аутсорсеру, в котором вы уверены.
Коллеги, давайте попробуем ближе к теме и аргументам затронутым в статье.
Сначала по нестыковкам.
В первой части, когда рассматривается возможность самостоятельной разработки, показана фирма, которая нанимает цтирую "правильного руководителя проекта", после чего оказывается, что приступили к проекту с ТЗ "на два листа".
Тут либо нужно говорить о некомпетентном руководителе проекта (как вариант отсутствие на рынке и другие сложности), либо я непонимаю, как все описанные проблемы возможны при Правильном руководстве...Может у автора Собственное видение "правильного руководства"?
Но самое интересное, на мой взгляд это решение, которое предлагается дальше, когда речь заходит об аутсорсинге, опять цитата:
"Оговаривайте мелочи, которые можно продумать заранее, в подробном техническом задании"... Супер!Даже комментировать на мой взгляд нечего.
А теперь всё таки добавим конструктива.
Что бы хотелось увидеть в такой вот статье.
1.Оба варианта для того что бы их можно было сравнивать должны базироваться на одних исходных условиях.
2.Несколько размыто выделен в начале тип проекта. Ну уникальный, но по хорошему ведь в сатье рассмотрены сложности с реализацией. Так что тут бы определится вначале, что мы и для чего собираемся делать...
А теперь выскажу своё мнение по затронутому вопросу.
Не буду проходится по теме аутсорсинга, плюсах и минусах, о тех рисках, что избегаем при таком подходе и тех что приобретаем.
Лично моё мнение, что аутсорсинг должен быть неполным. Любые критичные для бизнеса моменты должны оставаться в компании.
Отдавать на сторону проект, можно только Прооверенному аутсорсеру, в котором вы уверены.
# posted by : 11:55 AM
: 11:55 AM
> И все равно, в случае вырастания системы до большой(а если она развивается, она растет) я все равно упрямый сторонник аутсорсинга.
Вы рассуждаете с точки зрения собственика бизнеса. Надоело работать с "контингентом"? Бегаете по коридорам от программистов?
Есть другие точки зрения. Например: владелец бизнеса и заказчик проекта разные люди, а еще бывает, что заказчик проекта и руководитель тоже разные люди. При таких вариантах владельцу все одно... "аутсорсинг". :)
"Купленный аутсорсинг", сторонником которого являетесь, это своя структура с руководителем наделенным полномочиями и независимостью... от владельца.
Вы рассуждаете с точки зрения собственика бизнеса. Надоело работать с "контингентом"? Бегаете по коридорам от программистов?
Есть другие точки зрения. Например: владелец бизнеса и заказчик проекта разные люди, а еще бывает, что заказчик проекта и руководитель тоже разные люди. При таких вариантах владельцу все одно... "аутсорсинг". :)
"Купленный аутсорсинг", сторонником которого являетесь, это своя структура с руководителем наделенным полномочиями и независимостью... от владельца.
# posted by : 12:34 PM
: 12:34 PM
to anonymous
>Компания начинает уделять вашей компании все меньше времени...
Использование тиражируемого продукта предполгает: купил - установил - работай. Другими словами, зарабатывай. Если хочешь еще заработать, то купи. Можнет быть что-нибудь похожее, аналогичное у конкурентов. Зачем цеплятся за продукт?
Вот Феликс был бы рад, если к нему престанут приходить и просить деньги. :)
А ты так и норовишь им денег дать.
>Компания начинает уделять вашей компании все меньше времени...
Использование тиражируемого продукта предполгает: купил - установил - работай. Другими словами, зарабатывай. Если хочешь еще заработать, то купи. Можнет быть что-нибудь похожее, аналогичное у конкурентов. Зачем цеплятся за продукт?
Вот Феликс был бы рад, если к нему престанут приходить и просить деньги. :)
А ты так и норовишь им денег дать.
# posted by : 12:47 PM
: 12:47 PM
Что-то я запутался в анонимах :) Так общаться я не могу. Естественно, во всем есть плюсы и минусы. В аутсорсинге в том числе. Собственно, я высказал всего лишь свое мнение. Причем, действительно у меня - случай совсем особый, руководитель, совладелец, да еще в проектах понимаю. Критичные моменты бизнеса и сам на аутсорсинг не отдам, но что считать критичным в каждом случае. У нас, к примеру, это работа с клиентами-покупателями и клиентами-вендорами, но уж точно не разработка системы.
А вообще, мне можно написать(не анонимное) письмо, литературно излагающее позицию. Если будет интересный диалог, то его лучше опубликовать не обрывками.
Отправить комментарий
А вообще, мне можно написать(не анонимное) письмо, литературно излагающее позицию. Если будет интересный диалог, то его лучше опубликовать не обрывками.
<< Home
