Так это уже происходит. Аутсорсинговые компании и продуктовые компании разные, у них разные подходы ко многим вещам. Это неизбежно случается прямо сейчас.
Я с тобой совершенно не согласен. Конечно, важна совокупность. И цена, и все остальное. Но это все факторы, которые легко копировать. Сложно копировать творческий потенциал команды. С такой командой ты всегда будешь впереди всех.
>Имеет смысл, если это даст конкурентное преимущество.
Фишка в чем. Если творчески подходить к решению проблем, это всегда даст конкурентное преимущество. Под творчеством в данном случае я понимаю не просто витание в облаках и удовлетворение личных амбиций разработчика, а реально классное решение проблемы. Я не верю, что нельзя улучшить обычный сайт по продаже книг. Однозначно можно и скорее всего в разы.
Уже сейчас многие аутсорсеры имеют специализированные подразделения вертикальной интеграции в бизнес заказчика. У вас банковская сфера? Вот у нас отдел G этим занимается. У вас турфирма? Вам в отдел U. Эта тенденция только усилиться. Чтобы делать эффективные решения — нужно знать предметную область. Простая конкуренция. Через пару десятилетий не останется фирм, которые берутся на все и не имеют специализации.
Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление. Если у вас есть проблема, можно ее сразу решить в лоб. Почти всегда это не лучшее решение. Если немного подумать, и взять второе, оно тоже обычно не лучшее. Если есть творческое мышление, проблема может быть решена быстрее, эффективнее и лучше. Паттерны не всегда работают. Решать по шаблону может любой, вот и получаются все эти штамповки одинаковые. Творческие люди нужны любой компании, даже выпускающей молоко или табуретки. Не говоря уже об АйТи.
>Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
> каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов
И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
Вы меня плохо знаете. Я крайне непредвзят в подобных темах. И инструменты, скажем, для начала внедрения agile я всегда советую брать такие: большая белая доска, маркеры и стикеры. Если команда большая или распределенная, тогда можно пробовать тул типа нашего. Или если команда сама поняла, что тул ей нужен, и точно знает зачем.
Я гляжу баг вызвал здоровый энтузиазм выявить его причину. Такое впечатление, что хабр специально сохранил пару десятков багов, для поддержки разговоров в топиках.
Как сказал Стив Джобс, Real artists ship. Так что конечно доводить до конца нужно обязательно (ну или убедиться, что доводить до конца не нужно совсем :)
Мне кажется, Continuous Delivery понимается не совсем верно автором. В оригинале это поставка после каждого коммита. Закоммитил код — собрался и протестировался готовый билд, который можно ставить на продакшн. Это сложно, дорого, но достижимо.
Но в статье есть гораздо более тяжелый минус — оплата, ориентированная на результат. Мы вступаем на тонкую почву эстимейтов, в которых программеру очень легко ошибиться. За результат легко платить, когда табуретки делаешь, когда создаешь систему — это практически нереально. Эстимейты ВСЕГДА будут ошибочными. И это ведет к попыткам сделать эстимейты побольше, чтобы подстраховаться. А заказчик будет просить поменьше, чтобы поменьше заплатить. Это ведет к политическим играм и всему остальному неприглядному грязному белью. Ну его нафиг.
Все так и есть, но можно и нужно сокращать количество «левых» попыток создать нормальный софт. Нужно не только языки программирования учить, но и то, что я перечислил выше. Это поможет. Для инноваций не нужно то количество плагиата и шлака, что есть сейчас.
Шаги? Изучать ТРИЗ. Развивать правое полушарие. Изучать предметную область. Учиться решать проблемы разными способами. Изучать UX.
Мы пробовали Coding Kata один раз. Было прикольно, но задача попалась сложная и не закончили. Это было в рабочее время. Вообще у нас на обучение каждому человеку выделяется 5 часов в неделю. Кроме того проводятся внутренние конференции, воркшопы и так далее. Все это в рабочее время. В целом примерно процентов 15-20 рабочего времени уходит на развитие и обучение.
Я не утверждаю, что Coding Dojo это единственный способ улучшить скилы. Я не знаю. Но он имеет потенциал на мой взгляд.
Из того, что мы активно делаем, это изучение предметной области, UX, craftsmanship, Continuous Delivery внедряем (пока еще до коммитов не дошли, но через полгода думаю дойдем). ТРИЗ только сейчас начали активно изучать. Решение проблем пока оставляет желать лучшего, но все же раньше было гораздо хуже :)
>Кроме этого такой подход трудноприменим в разработке больших систем, которые должны предоставлять гарантированное качество услуги.
Скорее всего да. Просто для таких систем уровень надежности — приоритет номер один. И скорее всего не стоит использовать Continuous Delivery для mission-critical приложений. Но 80% софта пишется для решения бизнес задач и всяких казуальных задач, а там это уже не так критично.
Относительно. Но не весьма и весьма, а просто относительное. Думаю, пару десятков вариантов музыкальных плейеров покроют любые потребности в различиях. Но их существует гораздо больше. И многие ничем особо не отличаются. Нужно уходить от этого. Рано или поздно естественный отбор сделает свое дело, но хотелось бы раньше это уметь предвидеть и не выпускать очередной плагиат или отстой.
Фишка в чем. Если творчески подходить к решению проблем, это всегда даст конкурентное преимущество. Под творчеством в данном случае я понимаю не просто витание в облаках и удовлетворение личных амбиций разработчика, а реально классное решение проблемы. Я не верю, что нельзя улучшить обычный сайт по продаже книг. Однозначно можно и скорее всего в разы.
Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление. Если у вас есть проблема, можно ее сразу решить в лоб. Почти всегда это не лучшее решение. Если немного подумать, и взять второе, оно тоже обычно не лучшее. Если есть творческое мышление, проблема может быть решена быстрее, эффективнее и лучше. Паттерны не всегда работают. Решать по шаблону может любой, вот и получаются все эти штамповки одинаковые. Творческие люди нужны любой компании, даже выпускающей молоко или табуретки. Не говоря уже об АйТи.
>Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
> каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов
И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
Мне кажется, Continuous Delivery понимается не совсем верно автором. В оригинале это поставка после каждого коммита. Закоммитил код — собрался и протестировался готовый билд, который можно ставить на продакшн. Это сложно, дорого, но достижимо.
Но в статье есть гораздо более тяжелый минус — оплата, ориентированная на результат. Мы вступаем на тонкую почву эстимейтов, в которых программеру очень легко ошибиться. За результат легко платить, когда табуретки делаешь, когда создаешь систему — это практически нереально. Эстимейты ВСЕГДА будут ошибочными. И это ведет к попыткам сделать эстимейты побольше, чтобы подстраховаться. А заказчик будет просить поменьше, чтобы поменьше заплатить. Это ведет к политическим играм и всему остальному неприглядному грязному белью. Ну его нафиг.
en.wikipedia.org/wiki/Project_triangle
Мой пост о другом.
Мы пробовали Coding Kata один раз. Было прикольно, но задача попалась сложная и не закончили. Это было в рабочее время. Вообще у нас на обучение каждому человеку выделяется 5 часов в неделю. Кроме того проводятся внутренние конференции, воркшопы и так далее. Все это в рабочее время. В целом примерно процентов 15-20 рабочего времени уходит на развитие и обучение.
Я не утверждаю, что Coding Dojo это единственный способ улучшить скилы. Я не знаю. Но он имеет потенциал на мой взгляд.
Из того, что мы активно делаем, это изучение предметной области, UX, craftsmanship, Continuous Delivery внедряем (пока еще до коммитов не дошли, но через полгода думаю дойдем). ТРИЗ только сейчас начали активно изучать. Решение проблем пока оставляет желать лучшего, но все же раньше было гораздо хуже :)
Скорее всего да. Просто для таких систем уровень надежности — приоритет номер один. И скорее всего не стоит использовать Continuous Delivery для mission-critical приложений. Но 80% софта пишется для решения бизнес задач и всяких казуальных задач, а там это уже не так критично.