Comments 81
Превосходная статья! Это ваша или перевод?
Моя
На одном дыхании, от и до, и пофиг что там простыня. Хабр торт!
Отличная статья, лучшая из последних которые читал. Продолжение будет?
А что бы вы хотели увидеть в продолжении?
Как вариант: сравнение Scrum и Kanban, для каких команд и проектов подходит та или иная методика. Как правильно их внедрять с нуля, основные ошибки и подводные камни при внедрении. Как будет выглядеть работающая система на стеке Visual Studio и TFS (можно и что-то полегче, например TeamCity + YouTrack), в этом плане лучше всего будет смотреться схема в стиле cheatsheet.
В интернетах это все уже есть.
В интернетах сравнения обычно пишут приверженцы одной из методик, особо не зная другую (особенно изнутри). Процесс внедрения описан либо поверхностно, либо слишком специфично. Опять же пишут либо те кто работает на готовой системе, либо внедрял не более одного раза, не в полном объеме или на однотипных проектах. Хотелось бы узнать именно про реальный опыт и извлеченные уроки, возможно что видение тех кто делает такие системы и тех кто их использует расходятся. В любом случае мое дело предложить…
>> В интернетах сравнения обычно пишут приверженцы одной из методик…
а статью от этого автора мы можем получить как от приверженца вполне конкретного инструмента
а статью от этого автора мы можем получить как от приверженца вполне конкретного инструмента
Вы меня плохо знаете. Я крайне непредвзят в подобных темах. И инструменты, скажем, для начала внедрения agile я всегда советую брать такие: большая белая доска, маркеры и стикеры. Если команда большая или распределенная, тогда можно пробовать тул типа нашего. Или если команда сама поняла, что тул ей нужен, и точно знает зачем.
Если ваша то почему картинки на англицком? =)
Интересно, на западных сайтах публикую переводы русскоязычных статей? Я бы дал на такую статью ссылку своему менеджеру…
Очень много воды и очевидных вещей. Вот в конце хорошие тезисы перечислены. Если бы статья последовательно раскрывала бы каждый из них, было бы лучше, мне кажется. А так всё как-то намешано.
Не согласен. Статья получилась такая, которую может осилить и не-разработчик. А это ведь очень важно, чтобы остальные понимали, что работа программиста — это не «ТЫ ПРОГРАММИСТ ТЫ СКОЛЬКО СЕГОДНЯ ПРОГРАММ НАПИСАЛ?!?».
Вода вначале нужна для правильного фокуса. И я пожалуй соглашусь, что многие вещи очевидны в первой половине. Но очень часто люди сбиваются на мелочи, которые не важны, и теряют фокус на таких важных вещах, а вообще то ли мы делаем?
Если раскрывать глубже, то это уже книга получится :)
Если раскрывать глубже, то это уже книга получится :)
А может быть, там такое пересечение?
То, что вы написали, не имеет никакого отношения к правильному продукту. Мы можете сделать все быстро, качественно и дешево — но это никому не надо.
Это для примера. У Вас 3 категории: правильное, правильно сделланное и сделанное быстро. Часто оказывается, что пересечения в этом нет. Или оно может быть, но для этого надо затратить время, подготовить инструментарий (библиотеки, IDE). Но тогда это уже не будет быстро. Может, повезёт следующим заказчикам, которые придут, а у Вас инструментарий будет. Но чтобы он был, надо с чего-то начать… Замкнутый круг. Или бутстреппинг, если человек — оптимист :).
Мне кажется, я вас понимаю, но дело не в этом. Текущее положение вещей в индустрии таково, что дело не в инструментах и библиотеках (в них тоже, но это менее важно), а в подходах к выяснению требований и выработке лучших решений. Дело в качестве решений на всех уровнях (UX, Development). Нужно менять процесс.
Инструменты и библиотеки (и не только они, но и языки, и принципы организации работы команды, и методы управления проектом) — это ко второму кругу относится, к вопросу «как сделать?». А то, что Вы назвали «в подходах к выяснению требований и выработке лучших решений» — это Ваш первый круг, отвечающий на вопрос «Что сделать?». И то, и другое важно. Первое — очевидно, в первую очередь.
Кстати, это Venn диаграмма
en.wikipedia.org/wiki/Venn_diagram
Она просто показывает возможные зависимости. На самом деле пересечений может и не быть. Некоторые компании делают медленно, плохо и не то, что надо. Они вообще за всеми кругами :)
en.wikipedia.org/wiki/Venn_diagram
Она просто показывает возможные зависимости. На самом деле пересечений может и не быть. Некоторые компании делают медленно, плохо и не то, что надо. Они вообще за всеми кругами :)
В том что Вы написали тоже чаще всего нет пересечения. «Мы делаем быстро, качественно, недорого. Выбирайте любые два условия» (с) не помню кто сказал.
То, что вы написали, это всем известный треугольник
en.wikipedia.org/wiki/Project_triangle
Мой пост о другом.
en.wikipedia.org/wiki/Project_triangle
Мой пост о другом.
конечно. на фрилансе это проекты (примерное 90% от общего числа таких проектов) с заголовками «Доработать проект...», «Выполнить правки...», «Маленький проект на 2 часа».
правда заказчик думает, что эти круги не то, что пересекаются, даже совпадают.
а на самом деле там всё как на картинке.
правда заказчик думает, что эти круги не то, что пересекаются, даже совпадают.
а на самом деле там всё как на картинке.
Отличная статья, спасибо автору! «Знай предметную область!!!» вообще на транспарант и на стену.
В конце концов всё упирается в человеческие взаимоотношения.
Принципы agile [...] мир бизнеса встречает с недоумением. Именно!
Принципы agile [...] мир бизнеса встречает с недоумением. Именно!
> изучать техники решения проблем, такие как ТРИЗ
Можете какой-нибудь веб-ресурс порекомендовать по теме? Или книгу бумажную.
Можете какой-нибудь веб-ресурс порекомендовать по теме? Или книгу бумажную.
Основной ресурс, который встречал, когда первый раз услышал о ТРИЗ:
упс, куда-то ссылка делась www.trizland.ru
Интереснее было бы почитать об опыта решения проблем с помощью ТРИЗ, т.к. сколько не читал про него, кроме красивых слов ничего толком и не нашел.
programming-motherfucker.com тут предлагают 100% работающую альтернативу Agile :)
Супер статья. Очень доходчиво. Спасибо
Очень интересная статья.
Но есть одно но: такое многообразие софтового безобразия существует ещё и потому, что правильность — понятие весьма и весьма относительное. К сожалению )
Но есть одно но: такое многообразие софтового безобразия существует ещё и потому, что правильность — понятие весьма и весьма относительное. К сожалению )
Относительно. Но не весьма и весьма, а просто относительное. Думаю, пару десятков вариантов музыкальных плейеров покроют любые потребности в различиях. Но их существует гораздо больше. И многие ничем особо не отличаются. Нужно уходить от этого. Рано или поздно естественный отбор сделает свое дело, но хотелось бы раньше это уметь предвидеть и не выпускать очередной плагиат или отстой.
Многообразие разных немного-различающихся программ похоже на эволюцию живых существ.
Эволюция программ идет тем же «естественным» путем — огромного количества проб и ошибок.
Не вижу способа как можно от этого уйти, не запрещать же людям кодировать и придумывать, если мы их считаем недостаточно способными :)
Эволюция программ идет тем же «естественным» путем — огромного количества проб и ошибок.
Не вижу способа как можно от этого уйти, не запрещать же людям кодировать и придумывать, если мы их считаем недостаточно способными :)
Все так и есть, но можно и нужно сокращать количество «левых» попыток создать нормальный софт. Нужно не только языки программирования учить, но и то, что я перечислил выше. Это поможет. Для инноваций не нужно то количество плагиата и шлака, что есть сейчас.
> Не вижу способа как можно от этого уйти, не запрещать же людям кодировать и придумывать, если мы их считаем недостаточно способными :)
Почему бы и нет? Михаил таких людей просто увольняет :) Или старается не нанимать.
Почему бы и нет? Михаил таких людей просто увольняет :) Или старается не нанимать.
Хорошая статья. Автор довольно глубоко описал проблематику разработки высокоуровневого программного обеспечения. Здорово, когда куча автоматизированных средств позволяет тестировать все «на лету».
Получается такое бесконечное прототипирование с постепенно улучшающимся качеством. Благо падение скайпа или iPad пока приносит лишь временные неудобства.
Сейчас разработка бизнес-логики и интерфесов стала очень быстрой, но все же, как мне кажется у итерации есть предел.
Кроме этого такой подход трудноприменим в разработке больших систем, которые должны предоставлять гарантированное качество услуги. Представьте случайный неправильный комит в систему управление АЭС, который в виде ежедневного обновления разошелся по стране…
Возможно конечно стоит сначала написать тесты, а только потом писать код, но никто не поручится, что все тесты будут написаны правильно, плюс на тесты будет уходить значительное время, что приведет нас к нижнему порогу итерации.
Получается такое бесконечное прототипирование с постепенно улучшающимся качеством. Благо падение скайпа или iPad пока приносит лишь временные неудобства.
Сейчас разработка бизнес-логики и интерфесов стала очень быстрой, но все же, как мне кажется у итерации есть предел.
Кроме этого такой подход трудноприменим в разработке больших систем, которые должны предоставлять гарантированное качество услуги. Представьте случайный неправильный комит в систему управление АЭС, который в виде ежедневного обновления разошелся по стране…
Возможно конечно стоит сначала написать тесты, а только потом писать код, но никто не поручится, что все тесты будут написаны правильно, плюс на тесты будет уходить значительное время, что приведет нас к нижнему порогу итерации.
>Кроме этого такой подход трудноприменим в разработке больших систем, которые должны предоставлять гарантированное качество услуги.
Скорее всего да. Просто для таких систем уровень надежности — приоритет номер один. И скорее всего не стоит использовать Continuous Delivery для mission-critical приложений. Но 80% софта пишется для решения бизнес задач и всяких казуальных задач, а там это уже не так критично.
Скорее всего да. Просто для таких систем уровень надежности — приоритет номер один. И скорее всего не стоит использовать Continuous Delivery для mission-critical приложений. Но 80% софта пишется для решения бизнес задач и всяких казуальных задач, а там это уже не так критично.
не по теме, но на вашем профиле хабр что-то заглючило 0_о
Почему же не по теме? Вполне себе относится к качеству :)
2^32
Хорошая динамика по карме ))) За такие статьи иногда хочется в карму да побольше дать… Но никак ) Спасибо автору
Интересная статья, однако я не понял следующего, это рекомендации или шаги к действиям?? Т.е насколько это используется в работе?? Допустим, Вы сказали:
Для профессионального развития делаются попытки применить методики тренировок спортсменов или практики восточных единоборств, такие как Coding Dojo и Coding Kata.
Вы применяете эти методики или нет? И если применяете, то в рабочее время?? И как относятся к этому программисты?
Спасибо.
Для профессионального развития делаются попытки применить методики тренировок спортсменов или практики восточных единоборств, такие как Coding Dojo и Coding Kata.
Вы применяете эти методики или нет? И если применяете, то в рабочее время?? И как относятся к этому программисты?
Спасибо.
Шаги? Изучать ТРИЗ. Развивать правое полушарие. Изучать предметную область. Учиться решать проблемы разными способами. Изучать UX.
Мы пробовали Coding Kata один раз. Было прикольно, но задача попалась сложная и не закончили. Это было в рабочее время. Вообще у нас на обучение каждому человеку выделяется 5 часов в неделю. Кроме того проводятся внутренние конференции, воркшопы и так далее. Все это в рабочее время. В целом примерно процентов 15-20 рабочего времени уходит на развитие и обучение.
Я не утверждаю, что Coding Dojo это единственный способ улучшить скилы. Я не знаю. Но он имеет потенциал на мой взгляд.
Из того, что мы активно делаем, это изучение предметной области, UX, craftsmanship, Continuous Delivery внедряем (пока еще до коммитов не дошли, но через полгода думаю дойдем). ТРИЗ только сейчас начали активно изучать. Решение проблем пока оставляет желать лучшего, но все же раньше было гораздо хуже :)
Мы пробовали Coding Kata один раз. Было прикольно, но задача попалась сложная и не закончили. Это было в рабочее время. Вообще у нас на обучение каждому человеку выделяется 5 часов в неделю. Кроме того проводятся внутренние конференции, воркшопы и так далее. Все это в рабочее время. В целом примерно процентов 15-20 рабочего времени уходит на развитие и обучение.
Я не утверждаю, что Coding Dojo это единственный способ улучшить скилы. Я не знаю. Но он имеет потенциал на мой взгляд.
Из того, что мы активно делаем, это изучение предметной области, UX, craftsmanship, Continuous Delivery внедряем (пока еще до коммитов не дошли, но через полгода думаю дойдем). ТРИЗ только сейчас начали активно изучать. Решение проблем пока оставляет желать лучшего, но все же раньше было гораздо хуже :)
UFO just landed and posted this here
Мы кстати тоже BDD используем, только NBehave. Идея сделать интеграцию хороша, но пока не продумывали мы это.
менеджеры — они такие :)
стоит им дать выбор между Atlassian и ..Taucraft (если не ошибаюсь) — и выбор в пользу более известной, стабильной, опять же надежной (о чем и в статье речь) компании — становится очевиден…
стоит им дать выбор между Atlassian и ..Taucraft (если не ошибаюсь) — и выбор в пользу более известной, стабильной, опять же надежной (о чем и в статье речь) компании — становится очевиден…
На следующий день я пришел на работу, открыл бук и OmmWriter радостно завис.
По интерфейсу сразу видно, OmmWriter делал UX специалтст с развитым правым полушарием, lol.
По интерфейсу сразу видно, OmmWriter делал UX специалтст с развитым правым полушарием, lol.
Действительно превосходная статья! По-настоящему про Agile. Огромное спасибо!
Пару слов про скетчи и пример с голосовым управлением: Лет пять (или больше?) назад компания N решила открыть производство холодного чая в Китае. Провели жарким летним днём тесты, пригласили кучу участников и напоили их холодным чаем. И почти все китайцы в один голос заявили, что холодный чай — отстой, и покупать они его не будут. Компания N закрыла свой проект и порадовалась, что не слила кучу бабла.
Через годик компания X тоже захотела выпустить на китайском рынке холодные чаи. Делать маркетинговые исследования им ума не хватило, поэтому они открыли производство и начали продавать чай в милых бутылочках. Окупились они всего за год, став главными игроками рынка и заработав какое-то просто немыслимое баблище.
Почему так происходит? Причин несколько:
— прототипы (чай или управление из соседней комнаты) не всегда передают того, каким на самом деле окажется продукт.
— пользователям иногда нужно время, чтобы понять и принять продукт
— не все умеют проводить и анализировать исследования :)
Через годик компания X тоже захотела выпустить на китайском рынке холодные чаи. Делать маркетинговые исследования им ума не хватило, поэтому они открыли производство и начали продавать чай в милых бутылочках. Окупились они всего за год, став главными игроками рынка и заработав какое-то просто немыслимое баблище.
Почему так происходит? Причин несколько:
— прототипы (чай или управление из соседней комнаты) не всегда передают того, каким на самом деле окажется продукт.
— пользователям иногда нужно время, чтобы понять и принять продукт
— не все умеют проводить и анализировать исследования :)
По таргет процессу
TP Tray
Было бы круто если из него можно было бы сразу баг назначать на разработчика и ставить QA.
А то сейчас приходится все равно приходится после него открывать баг и через сайт ставить разработчика и тестера.
Вообще таргет процесс очень нравится. И руководство кампании идет на встречу молодым стартапам.
TP Tray
Было бы круто если из него можно было бы сразу баг назначать на разработчика и ставить QA.
А то сейчас приходится все равно приходится после него открывать баг и через сайт ставить разработчика и тестера.
Вообще таргет процесс очень нравится. И руководство кампании идет на встречу молодым стартапам.
Отличная статья! Читается на одном дыхании и содержит много полезных идей и рассуждений. Мне близки твои взгляды и приятно знать, что ТаргетПроцесс им следует и делает это успешно.
В принципе я с большинством пунктов согласна, но мне кажется, что местами ты частный опыт распространяешь на индустрию в целом.
Приведу несколько примеров. Допустим, знание предметной области. Бесспорно знание командой предметной области софта это огромный плюс. Не только с точки зрения, что это помогает предлагать идеи и эффективные решения. Но даже банально потому, что не понимая предметной области сложно реализовать функциональность правильно и проверить, что она решает поставленную задачу. Но порог вхождения в разные предметные области может быть различным. Мне пришлось столкнуться с двумя предметными областями, которые я так и не осилила. Первая была связана с добычей нефти, там я ничего не поняла, кроме того, что все должно работать по нужным формулам, но я и не пыталась. Второй мой неудачный опыт был связан с грузоперевозками. Вот там я пыталась, даже общалась локально (клиент был из США) с представителями этого бизнеса, чтобы понять о чем говорит заказчик. Но проект был не длительный (чуть меньше года) и хорошо понять бизнес заказчика мне так и не удалось. Наверное клиент был не прав, он должен был помочь команде понять его бизнес. С другой стороны это была маленькая компания, которой нужно было автоматизировать их бизнес процессы. Софт пишется для бизнеса, и бизнес решает сколько инвестировать в софт, чтобы это имело смысл, ну вот они решили инвестировать мало.
Теперь возьмем ТРИЗ и другие практики для генерации нетипичных решений. А везде ли они нужны? Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Другими словами, есть бизнес, основной доход, которому приносят не технологии, а продукты и услуги. Нужны ли имв зоопарке все эти навороты настолько высококвалифицированные специалисты?
С другой стороны есть очень «технологичный» бизнес. Есть компании гиганты типа Google, Apple, у которых целые отделы занимаются исследованиями, есть отделы проектирования интерфейсов и так далее. Ожидают ли они от каждого разработчика развитие навыков креативного решения проблем?
Собственно бизнес он очень разный, и решения о роли ИТ в нем, каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов. В любом случае, если делать правильные вещи правильно и быстро, это должно принести хороший результат. Но что для этого нужно на мой взгляд все же не так однозначно.
В принципе я с большинством пунктов согласна, но мне кажется, что местами ты частный опыт распространяешь на индустрию в целом.
Приведу несколько примеров. Допустим, знание предметной области. Бесспорно знание командой предметной области софта это огромный плюс. Не только с точки зрения, что это помогает предлагать идеи и эффективные решения. Но даже банально потому, что не понимая предметной области сложно реализовать функциональность правильно и проверить, что она решает поставленную задачу. Но порог вхождения в разные предметные области может быть различным. Мне пришлось столкнуться с двумя предметными областями, которые я так и не осилила. Первая была связана с добычей нефти, там я ничего не поняла, кроме того, что все должно работать по нужным формулам, но я и не пыталась. Второй мой неудачный опыт был связан с грузоперевозками. Вот там я пыталась, даже общалась локально (клиент был из США) с представителями этого бизнеса, чтобы понять о чем говорит заказчик. Но проект был не длительный (чуть меньше года) и хорошо понять бизнес заказчика мне так и не удалось. Наверное клиент был не прав, он должен был помочь команде понять его бизнес. С другой стороны это была маленькая компания, которой нужно было автоматизировать их бизнес процессы. Софт пишется для бизнеса, и бизнес решает сколько инвестировать в софт, чтобы это имело смысл, ну вот они решили инвестировать мало.
Теперь возьмем ТРИЗ и другие практики для генерации нетипичных решений. А везде ли они нужны? Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Другими словами, есть бизнес, основной доход, которому приносят не технологии, а продукты и услуги. Нужны ли им
С другой стороны есть очень «технологичный» бизнес. Есть компании гиганты типа Google, Apple, у которых целые отделы занимаются исследованиями, есть отделы проектирования интерфейсов и так далее. Ожидают ли они от каждого разработчика развитие навыков креативного решения проблем?
Собственно бизнес он очень разный, и решения о роли ИТ в нем, каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов. В любом случае, если делать правильные вещи правильно и быстро, это должно принести хороший результат. Но что для этого нужно на мой взгляд все же не так однозначно.
Уже сейчас многие аутсорсеры имеют специализированные подразделения вертикальной интеграции в бизнес заказчика. У вас банковская сфера? Вот у нас отдел G этим занимается. У вас турфирма? Вам в отдел U. Эта тенденция только усилиться. Чтобы делать эффективные решения — нужно знать предметную область. Простая конкуренция. Через пару десятилетий не останется фирм, которые берутся на все и не имеют специализации.
Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление. Если у вас есть проблема, можно ее сразу решить в лоб. Почти всегда это не лучшее решение. Если немного подумать, и взять второе, оно тоже обычно не лучшее. Если есть творческое мышление, проблема может быть решена быстрее, эффективнее и лучше. Паттерны не всегда работают. Решать по шаблону может любой, вот и получаются все эти штамповки одинаковые. Творческие люди нужны любой компании, даже выпускающей молоко или табуретки. Не говоря уже об АйТи.
>Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
> каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов
И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление. Если у вас есть проблема, можно ее сразу решить в лоб. Почти всегда это не лучшее решение. Если немного подумать, и взять второе, оно тоже обычно не лучшее. Если есть творческое мышление, проблема может быть решена быстрее, эффективнее и лучше. Паттерны не всегда работают. Решать по шаблону может любой, вот и получаются все эти штамповки одинаковые. Творческие люди нужны любой компании, даже выпускающей молоко или табуретки. Не говоря уже об АйТи.
>Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
> каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов
И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
>> Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление
Да, не права.
>> Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
Почему обязательно надо? Имеет смысл, если это даст конкурентное преимущество.
>> И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
То что бизнес обязательно прав, я не писала. Но любой бизнес расставляет приоритеты во что инвестировать бОльше в рекламу, в ИТ, что-то третье. На западе кстати тоже компании разные есть, хотя у них роль ИТ в бизнесе гораздо выше, чем у нас.
Да, не права.
>> Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!
Почему обязательно надо? Имеет смысл, если это даст конкурентное преимущество.
>> И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
То что бизнес обязательно прав, я не писала. Но любой бизнес расставляет приоритеты во что инвестировать бОльше в рекламу, в ИТ, что-то третье. На западе кстати тоже компании разные есть, хотя у них роль ИТ в бизнесе гораздо выше, чем у нас.
>Имеет смысл, если это даст конкурентное преимущество.
Фишка в чем. Если творчески подходить к решению проблем, это всегда даст конкурентное преимущество. Под творчеством в данном случае я понимаю не просто витание в облаках и удовлетворение личных амбиций разработчика, а реально классное решение проблемы. Я не верю, что нельзя улучшить обычный сайт по продаже книг. Однозначно можно и скорее всего в разы.
Фишка в чем. Если творчески подходить к решению проблем, это всегда даст конкурентное преимущество. Под творчеством в данном случае я понимаю не просто витание в облаках и удовлетворение личных амбиций разработчика, а реально классное решение проблемы. Я не верю, что нельзя улучшить обычный сайт по продаже книг. Однозначно можно и скорее всего в разы.
Но вопрос ведь еще и в том, чтобы решить проблему быстро. Если взять не самое оптимальное решение, пусть это в лоб, пусть это не самое лучшее решение, но его можно быстро сделать и книжки сразу продавать. А можно потратить время на поиск более оптимального решения (я кстати тоже не про код, я скорее про UX сейчас говорю), но пока ищешь народ уже закупит себе целую библиотеку у конкурентов. Или сделаешь ты хорошее решение, более удобное для конечного пользователя, чем у конкурентов, а конкуренты возьмут и цены низкие поставят на свои книжки. Пользователи полюбуются немного на твое изящное решение и метнутся сметать книжки с полок конкурента.
Нужно развивать творческое мышление, нужно уметь проверять решение на понятность и все такое. Я ж тока за. Я пытаюсь понять, где баланс.
Нужно развивать творческое мышление, нужно уметь проверять решение на понятность и все такое. Я ж тока за. Я пытаюсь понять, где баланс.
А если я книжки буду продавать, как все. Сделаю сайт, как у большинства конкурентов, зато я вложу деньги в более качественный customer support, если смогу наладить процесс доставки более эффективный, если я буду в каждый заказ с книжками вкладывать карандашики в подарок, мне это выгоднее будет или нет?
Важны не преимущества, это мимолетные достижения, которые быстро перекроет кто-то другой, а инновационные решения в сфере, тогда преимущества будут всегда на высоте. Нужно именно вкладывать инвестиции в поиск инновационные решения, а не в поиск отличий от других компаний, чем кстати большинство компаний и занимается.
Я с тобой совершенно не согласен. Конечно, важна совокупность. И цена, и все остальное. Но это все факторы, которые легко копировать. Сложно копировать творческий потенциал команды. С такой командой ты всегда будешь впереди всех.
>> Сложно копировать творческий потенциал команды. С такой командой ты всегда будешь впереди всех.
А я вот с этим категорически согласна. Просто я считаю, что инновации нужны не только в ИТ, они нужны везде, и в маркетинге и в работе с клиентами. Просто понятно, что мы рассматриваем ИТ здесь.
Что я пытаюсь для себя понять. Так это будет ли действительно одинаковое будущее во всем ИТ. Грубо говоря все, что ты описываешь это первоочердные вещи для бизнеса, в котором ИТ является двигателем. Это допустим ТаргетПроцесс, ну и многое другое. :)
Есть же ИТ, которое является скорее обслуживанием нудж бизнеса, это всякие внутренние системы. Или возьмем теже банкоматы. Кто-то же пишет под них софт? Они неудобные, но зп от этого люди не перестают снимать с карточек, таким образом банку это не первый приоритет. Мне кажется отсюда (из таких отраслей) исходят мнение, что в Ит ваще нет никакого творчества, и все это просто рутинная механическая работа и ты ды.
Мне интересно порассуждать произойдет ли из-за разной роли ИТ в бизнесе расслоение в будущем развитии индустрии (в процессах разработки, обучение специалистов). Было интересно твое мнение, а ты защищаешь свою позицию, с которой я не спорю. Потому что мне она нравится, и я считаю ее правильной для себя. :)
А я вот с этим категорически согласна. Просто я считаю, что инновации нужны не только в ИТ, они нужны везде, и в маркетинге и в работе с клиентами. Просто понятно, что мы рассматриваем ИТ здесь.
Что я пытаюсь для себя понять. Так это будет ли действительно одинаковое будущее во всем ИТ. Грубо говоря все, что ты описываешь это первоочердные вещи для бизнеса, в котором ИТ является двигателем. Это допустим ТаргетПроцесс, ну и многое другое. :)
Есть же ИТ, которое является скорее обслуживанием нудж бизнеса, это всякие внутренние системы. Или возьмем теже банкоматы. Кто-то же пишет под них софт? Они неудобные, но зп от этого люди не перестают снимать с карточек, таким образом банку это не первый приоритет. Мне кажется отсюда (из таких отраслей) исходят мнение, что в Ит ваще нет никакого творчества, и все это просто рутинная механическая работа и ты ды.
Мне интересно порассуждать произойдет ли из-за разной роли ИТ в бизнесе расслоение в будущем развитии индустрии (в процессах разработки, обучение специалистов). Было интересно твое мнение, а ты защищаешь свою позицию, с которой я не спорю. Потому что мне она нравится, и я считаю ее правильной для себя. :)
Так это уже происходит. Аутсорсинговые компании и продуктовые компании разные, у них разные подходы ко многим вещам. Это неизбежно случается прямо сейчас.
Да, но разница может сокращаться, а может расти. Продуктовые и аутсорсинговые они тоже разные бывают. Сам выше писал, что есть аутсорсинговые, которые создают у себя центры компетенций, все же левел-ап. То есть аутсорс он может либо просто отставать, а может деградировать.
Но я считаю, что аутсорс это все же сервис. И от заказчика во многом зависит его качества, какие требования он предъявляет к исполнителю, такой и результат получает. В свою очередь аутсорс может (и должен) сам повышать качество сервиса, пытаться работать с бизнеса клиента, как со своим. Но вот хочет ли этого заказчик? Нужны ли ему инновации, или все-таки ему дешево и быстро.
Но я считаю, что аутсорс это все же сервис. И от заказчика во многом зависит его качества, какие требования он предъявляет к исполнителю, такой и результат получает. В свою очередь аутсорс может (и должен) сам повышать качество сервиса, пытаться работать с бизнеса клиента, как со своим. Но вот хочет ли этого заказчик? Нужны ли ему инновации, или все-таки ему дешево и быстро.
Почему были созданы все эти жуткие монстры с кошмарным интерфейсом, которые истязают своих пользователей, изводят своих создателей и никак не хотят расстаться с жизнью по хорошему? Почему были созданы эти сотни простых как грабли тулов, которые делают одно и то же, отличаясь цветовой гаммой, платформой, и дизайном формы логина?
Потому что 90% всего — это барахло, в полном соответствии с законом Старджона :-)
Потому что 90% всего — это барахло, в полном соответствии с законом Старджона :-)
Есть и противоположные оценки, например "Agile is a cancer that we have to eliminate from the industry".
Представляю себе лица многочисленных клиентов, которым я осмелился бы предложить непрекращающуюся «после каждого коммита» поставку продукта, любое обновление которого (кроме хотфиксов) требует недель их внутренних тестов и опытной эксплуатации.
Представляю себе лица многочисленных клиентов, которым я осмелился бы предложить непрекращающуюся «после каждого коммита» поставку продукта, любое обновление которого (кроме хотфиксов) требует недель их внутренних тестов и опытной эксплуатации.
Sign up to leave a comment.
Будущее гибкой разработки ПО