Developer Friendly
Будущее за тем софтом, которое делается для разработчиков, а не для пользователей. На самом деле, и для разработчиков и для пользователей, но для пользователей только в том смысле, чтобы разработчикам меньше доделывать.
Раньше софт продавался так:
1) Какому-нибудь корпоративному шишке показывают, как система автоматически рисует красивые графики и помогает сразу получить ответ на вопрос "что происходит".
Конечно-же никто из продающих не говорит о том
- что софт заточен только под определенную бизнес модель
- что графики будут красивыми только если люди будут вбивать "красивые" данные
- что придется натягивать бизнес-процессы предприятия на модель софта, и что-то где-то обязательно порвется. Придется долго и дорого латать эту дырку.
- что для поддержки предлагаемого решения потребуется дополнительная команда специалистов с редкой квалификацией.
2) Этой шишке говорят, что для того, чтобы предлагаемая программная платформа может меняться под изменяющийся рынок, и для того, чтобы вносить изменения не нужны разработчики ПО.
- Посмотрите на WYSIWYG-редактор бизнес-процессов на нашем софте
- Посмотрите на интегрированную систему разработки, которая хранит все решение в одном месте
- Все настройки можно накликать на экране мышкой, нет необходимости разбираться в больших файлах конфигурации.
Корпоративный шишка всю эту херню съедает и говорит "Как классно". Он сам пробуем менять процессы в софте, настройки. Всё круто! Я за рулем шатла!
Софт закупается и отдается в отдел ИТ. Там сидят программисты или админы, которым
- поебать на эти графики
- этот WYSIWYG-редактор БП, форм, потоков нахер никому не нужен.
- мне настройка мышкой на экране нахер не нужна, им нужен конфигурационный файл
Это все потому, что у программистов и админов есть набор очень развитых инструментов и процедур по управлению всякими артефактами разработки ПО. Есть SCM, поиск подстроки в файле (в любом редакторе), есть diff-patch, blame/annotate, есть системы сборки, continues integration и прочая-прочая херня которая помогает установить настоящий устойчивый контроль над ИС предприятия.
Но эти инструменты не любят WYSIWUG, галочки на экране, да и GUI в целом потому, что эта херня не поддается автоматизации. Все эти "eye candy" навороты только хуже делают.
В конечном итоге на предприятии оказывается информационная система, даже несколько, которые сложно поддерживать, сложно менять, которые портят людям жизнь, как рядовым сотрудникам, так и разработчикам и админам из ИТ-отдела.
Корпоративные шишки не понимают, что есть хорошо во внедрении и поддержке информационных систем, а что плохо. Это потому, что они сами никогда не поддерживают ИС.
Утверждение о том, что для поддержки и внесения изменений не нужен разработчик ПО это вообще самая большая наёбка. Дело же не в том, кто не нужен для поддержки системы, а кто нужен. Когда продающая сторона говорит, что не нужны разработчики, она имеет в виду,
- что не нужны дорогостоящие (и вредные) специалисты-программисты.
- достаточно иметь одного сисадмина; или даже специалисты производственных отделов смогут сами вносить изменения в ИС для того, чтобы подгонять ее под свои бизнес-процессы.
На самом же деле, допускать специалистов производственных отделов к изменениям в ИС, когда те касаются изменений в настройках ИС, определении потоков информации в ней очень рисковано. Это может делать только бизнесс-аналитик или аналитик ПО. При этом стоимость обучения таких аналитиков не меньше стоимости обучения разработчиков, а чаще, еще и выше.
Таким образом, вопрос поддержки и сопровождения ИС возвращается профессиональным разработчикам ПО, но которые при этом оказываются лишены своих стандартных инструментов, что только увеличивает стоимость поддержки (в основном из-за хаоса и количество дефектов конфигурации).
Продавая софт я могу с тем же успехом говорить
- Для поддержки этого софта достаточно только всего-лишь-ничего, только очень дорогого сверхквалифициорваного супер-редкого специалиста (которого мы можем вам продать втридорого). Главное, говорить это успокаивающим голосом. Так, как будь-то такие специалисты на каждом углу стоят, ищут работы за 2 пирожка в день и оплату электрички.
После того, как самые умные корпоративные шишки поняли что графики-хуяфики это просто игрушки, а визуальный конструктор бизнес-процессов нахер никому не нужен (хотя бы потому, что научить языку программирования проще, чем концепции разработки ИС и БП) они стали консультироваться с ведущими специалистами ИТ и с разработчиками ПО. Достаточно хотя-бы спросить что-то типа "Мы эту херню сами сможем поддерживать?" - уже станет ясно, чего стоят эти графики-хуяфики.
А еще можно зайти на сайт с резюме специалистов и посмотреть на живую статистику:
Резюме:
- Java (23004)
- Python (12840)
- C++ (8900)
- PHP (17800)
- C# (21039)
- разработчики для системы с красивыми графиками (0)
И тогда реальная стоимость владения системой становится очевидной.
Впервые на рекламу ПО удобного для разработчиков я увидел на сайте Alfresco. Там она была на ровне с преимуществами для пользователей и для руководства. Наконец-то люди доперли, что продавать системы ПО надо программистам/разработчикам, а не руководству.
Руководитель говорит:
- ребята, нам надо что-то делать с этой хуйней. Что скажете?
- а какой бюджет?
- у нас есть около икс-игрек тыщ
- давай тогда мы вот такую хрень купим, вот такую возьмем бесплатную (GNU-GPL) и немного сами допилим, только придется взять еще одного Python-программиста (у нас Федя python знает, но он занят в другом проекте).
Разработчики будут искать то, с чем им легче работать, а не то, что красивые графики рисует. Они будут искать софт, к которому красивые графики легко прикрутить, а не где они уже есть.
Сейчас уже почти на всех новых старт-апах, связанных с ИТ на главной странице рекламируются преимущества для разработчиков прежде всего, а потом для пользователей и прочих ролей. В ближайшие 10 лет это будет главной темой. Легче будет продаваться то, что легче интегрировать с помощью имеющихся трудовых ресурсов.
Если бы я был директором автобазы, я бы закупал те автомобили, которые мои механики могут починить сами, и как можно скорее. Это потому, что моя прибыл больше зависит от количества простоев, а не от красоты грузовиков.
То же самое относится к чисто пользовательским функциям. Я бы не стал покупать автобус с красивым новыми креслами, котороые хер заменишь, я бы стал покупать автобус с возможностью легкой заменой кресел, когда я захочу (это важнее, чем наличие кресел при покупке). При этом легкость замены кресел должен определять тот, кто это будет действительно делать на предприятии, а не тот, кто покупает.
На самом деле сейчас уже не покупают ИС, их арендуют, что рождает новый класс проблем широкого спектра.
Раньше софт продавался так:
1) Какому-нибудь корпоративному шишке показывают, как система автоматически рисует красивые графики и помогает сразу получить ответ на вопрос "что происходит".
Конечно-же никто из продающих не говорит о том
- что софт заточен только под определенную бизнес модель
- что графики будут красивыми только если люди будут вбивать "красивые" данные
- что придется натягивать бизнес-процессы предприятия на модель софта, и что-то где-то обязательно порвется. Придется долго и дорого латать эту дырку.
- что для поддержки предлагаемого решения потребуется дополнительная команда специалистов с редкой квалификацией.
2) Этой шишке говорят, что для того, чтобы предлагаемая программная платформа может меняться под изменяющийся рынок, и для того, чтобы вносить изменения не нужны разработчики ПО.
- Посмотрите на WYSIWYG-редактор бизнес-процессов на нашем софте
- Посмотрите на интегрированную систему разработки, которая хранит все решение в одном месте
- Все настройки можно накликать на экране мышкой, нет необходимости разбираться в больших файлах конфигурации.
Корпоративный шишка всю эту херню съедает и говорит "Как классно". Он сам пробуем менять процессы в софте, настройки. Всё круто! Я за рулем шатла!
Софт закупается и отдается в отдел ИТ. Там сидят программисты или админы, которым
- поебать на эти графики
- этот WYSIWYG-редактор БП, форм, потоков нахер никому не нужен.
- мне настройка мышкой на экране нахер не нужна, им нужен конфигурационный файл
Это все потому, что у программистов и админов есть набор очень развитых инструментов и процедур по управлению всякими артефактами разработки ПО. Есть SCM, поиск подстроки в файле (в любом редакторе), есть diff-patch, blame/annotate, есть системы сборки, continues integration и прочая-прочая херня которая помогает установить настоящий устойчивый контроль над ИС предприятия.
Но эти инструменты не любят WYSIWUG, галочки на экране, да и GUI в целом потому, что эта херня не поддается автоматизации. Все эти "eye candy" навороты только хуже делают.
В конечном итоге на предприятии оказывается информационная система, даже несколько, которые сложно поддерживать, сложно менять, которые портят людям жизнь, как рядовым сотрудникам, так и разработчикам и админам из ИТ-отдела.
Корпоративные шишки не понимают, что есть хорошо во внедрении и поддержке информационных систем, а что плохо. Это потому, что они сами никогда не поддерживают ИС.
Утверждение о том, что для поддержки и внесения изменений не нужен разработчик ПО это вообще самая большая наёбка. Дело же не в том, кто не нужен для поддержки системы, а кто нужен. Когда продающая сторона говорит, что не нужны разработчики, она имеет в виду,
- что не нужны дорогостоящие (и вредные) специалисты-программисты.
- достаточно иметь одного сисадмина; или даже специалисты производственных отделов смогут сами вносить изменения в ИС для того, чтобы подгонять ее под свои бизнес-процессы.
На самом же деле, допускать специалистов производственных отделов к изменениям в ИС, когда те касаются изменений в настройках ИС, определении потоков информации в ней очень рисковано. Это может делать только бизнесс-аналитик или аналитик ПО. При этом стоимость обучения таких аналитиков не меньше стоимости обучения разработчиков, а чаще, еще и выше.
Таким образом, вопрос поддержки и сопровождения ИС возвращается профессиональным разработчикам ПО, но которые при этом оказываются лишены своих стандартных инструментов, что только увеличивает стоимость поддержки (в основном из-за хаоса и количество дефектов конфигурации).
Продавая софт я могу с тем же успехом говорить
- Для поддержки этого софта достаточно только всего-лишь-ничего, только очень дорогого сверхквалифициорваного супер-редкого специалиста (которого мы можем вам продать втридорого). Главное, говорить это успокаивающим голосом. Так, как будь-то такие специалисты на каждом углу стоят, ищут работы за 2 пирожка в день и оплату электрички.
После того, как самые умные корпоративные шишки поняли что графики-хуяфики это просто игрушки, а визуальный конструктор бизнес-процессов нахер никому не нужен (хотя бы потому, что научить языку программирования проще, чем концепции разработки ИС и БП) они стали консультироваться с ведущими специалистами ИТ и с разработчиками ПО. Достаточно хотя-бы спросить что-то типа "Мы эту херню сами сможем поддерживать?" - уже станет ясно, чего стоят эти графики-хуяфики.
А еще можно зайти на сайт с резюме специалистов и посмотреть на живую статистику:
Резюме:
- Java (23004)
- Python (12840)
- C++ (8900)
- PHP (17800)
- C# (21039)
- разработчики для системы с красивыми графиками (0)
И тогда реальная стоимость владения системой становится очевидной.
Впервые на рекламу ПО удобного для разработчиков я увидел на сайте Alfresco. Там она была на ровне с преимуществами для пользователей и для руководства. Наконец-то люди доперли, что продавать системы ПО надо программистам/разработчикам, а не руководству.
Руководитель говорит:
- ребята, нам надо что-то делать с этой хуйней. Что скажете?
- а какой бюджет?
- у нас есть около икс-игрек тыщ
- давай тогда мы вот такую хрень купим, вот такую возьмем бесплатную (GNU-GPL) и немного сами допилим, только придется взять еще одного Python-программиста (у нас Федя python знает, но он занят в другом проекте).
Разработчики будут искать то, с чем им легче работать, а не то, что красивые графики рисует. Они будут искать софт, к которому красивые графики легко прикрутить, а не где они уже есть.
Сейчас уже почти на всех новых старт-апах, связанных с ИТ на главной странице рекламируются преимущества для разработчиков прежде всего, а потом для пользователей и прочих ролей. В ближайшие 10 лет это будет главной темой. Легче будет продаваться то, что легче интегрировать с помощью имеющихся трудовых ресурсов.
Если бы я был директором автобазы, я бы закупал те автомобили, которые мои механики могут починить сами, и как можно скорее. Это потому, что моя прибыл больше зависит от количества простоев, а не от красоты грузовиков.
То же самое относится к чисто пользовательским функциям. Я бы не стал покупать автобус с красивым новыми креслами, котороые хер заменишь, я бы стал покупать автобус с возможностью легкой заменой кресел, когда я захочу (это важнее, чем наличие кресел при покупке). При этом легкость замены кресел должен определять тот, кто это будет действительно делать на предприятии, а не тот, кто покупает.
На самом деле сейчас уже не покупают ИС, их арендуют, что рождает новый класс проблем широкого спектра.