Устал объяснять одно и то же в разных топиках каждые полгода. По моему разумению при продвижении решений для девелопмента(и чего угодно) нужно ориентироваться
1 на степень влияния ЦА на бизнес.
2 на размер ЦА
3 Цена ошибки (повышает зависимость)
Это не формула продвижения, это азы, известные из СМО (если бизнес представить как СМО, что фактически и делается во всяких ххх-менеджментах)
Немерле, как и вся функиональщина, и метапрограммирование нужны в проектах, где влияние девепелоперов на бизнес крайне высоко и цена ошибки высока. Вопрос в том, где же это влияние высокое, а где — низкое(то есть).
I>>Ну решаются, что с того ? Менеджмет и маркетинг всё равно бОльшее влияние имеют, примерно на порядок а то и больше.
VD>Уважаемый, у тебя все перевернуто с ног на голову. Это не производство ради макретинга и менеджмента, а макретинг и менеджмент для производства.
Наоборот, на пальцах :
Бизнес это владелец + топ-менеджмент. Всё остальное обслуживает эту связку. Формула простая — нарисуй концентрические круги — 1 владелец 2 топменеджмент 3 маркетинг 4 производство 5 разработка. Каждый кружочек показывает систему, обслуживающую свой центр. Больше радиус — меньше влияние. Зависимость пропорциональна влиянию. ЗП пропорциональна зависимости. Все, приехали — обслуживающая система имеет заведомо меньшее влияние чем обслуживаемая.
Чем отличается софтверная контора от полиграфии ? В софтверной 4 и 5 это одно и то же, т.е. влияние девелоперов больше.
Это упрощенная модель конечно. Более полной будет ациклический направленый граф, где будем указывать, кто кого обслуживает, тогда можно вписать в эту схему самых разных разработчиков.
Соответсвенно, результаты по этому методу, отсортированы по убыванию важности девелоперов
1. Шаровара и любая разработка в одно лицу — фактически бизнес и есть разработка, зависимость самая высокая
2. R&D — обслуживает фактически маркетинг или даже менеджмент, то есть зависимость выше чем у тех разработчиков что обслуживают производство.
3. Аутсорс как бизнес почти что такой же расклад как в п.1 — снова высокая зависимость. Отсюда ясно, откуда формула "что бы стоять на месте, надо бежать изо всех сил", но есть одно "но" — аутсорс часто распильный, в аутсорс многие проекты просто не попадают и никогда не попадут.
4 Разработкой при производстве или продуктовых конторах получше чем с 1С, но точно похуже чем в аутсорсе.
5 1С — разрабы обслуживают фактически бухгалтерию, которая стоит еще дальше чем производсто. Не надо удивляться чт зависимость низкая.
6 Суппорт — обслуживает не пойми кого не надо удивляться выражению "списали в суппорт", там нужны траблшутеры, которые обслуживают пользователей, а программистов в суппорте может и не быть, а может быть для галки, зависимость низкая.
7 Распильные проекты — тут очевидно
Аномалии — когда вместо маркетинга решения принимают девелоперы. Бывает такое, у меня у самого так бывало Зависимость будет расти.
Другая аномалия — менеджмет и маркетинг тупят со страшной силой. Это значит, что зависимость от девелоперов растет пропорционально этой тупости.
Еще аномалия — готовые решения. Зависимость будет падать.
Как по этой модели вводить оптимизации можно найти в учебнике по СМО. Если сюда вписать цену ошибки, расклад не изменится,но не фатально.
VD>Что будут "маркетировать" маркетологи, если не будет продукта или он будет не качественным? А что это за управление такое, которое привело к ситуации когда программисты заняты хрен знает чем, а маретологи пиарят воздух?
Менеджмент и маркетологи приступают к работе над созданием продукта задолго до того как им займутся программисты и оканчивают много позже чем программисты отстреляются. Ошибки менеджмента например проявляются в том числе в виде сорваных сроков, например если менеджмент не создаёт условий для хорошей работы.
Если маркетировать нечего, это провал менеджмента, т.к. условия не созданых. Не качественный продукт — это снова провал в управлении качеством например или завышеными или неадекватными требованиями. Ну и дальше ты сам себя поправил.
И напоследок, размер ЦА. Сколько девелоперов в России меняют код в 1с что бы привести его в соответствие с законодательством ? Цифры вобщем то известные, надо всего то поискать чуток
А что же никто не комментит? Всё правильно ведь написал.
И вообще. В современном мире любой реальный продукт производить не выгодно по сравнению, например, с банальными валютными спекуляциями на каком-нибудь Форексе. Ничего не делаешь, а купаешься в золоте. Ну как его может быть выгодно производить. если негры за еду нефть выкачали, ты продал её и купаешь в золоте. Если вышел новый бредовый закон, прошелся по конторам в 1С-ке пару строчек поправил, купаешься в золоте. А вы тут какой-то продукт собрались производить, вот ещё глупости какие, пусть Китайцы производят. За еду.
Эффективность превыше всего!
Минимум усилий, максимум бабло!
Рифма
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
S>И вообще. В современном мире любой реальный продукт производить не выгодно по сравнению, например, с банальными валютными спекуляциями на каком-нибудь Форексе.
Там надо риски уметь просчитывать. Очень немногие знают, как это делать.
А по теме, всё правильно (учебники австрийской экономической школы говорят о том же), но вот именно поэтому-то и надо изучать программирование. Чтобы (случайно, разумеется) оказаться там, где твоё влияние на происходящее будет чуть больше нуля.
Здравствуйте, os24ever, Вы писали:
O>А по теме, всё правильно (учебники австрийской экономической школы говорят о том же), но вот именно поэтому-то и надо изучать программирование. Чтобы (случайно, разумеется) оказаться там, где твоё влияние на происходящее будет чуть больше нуля.
Необязательно программирование. Модель говорит о том, что нужно быть там, где от тебя зависимость выше, а это быть поближе к бизнесу. Еще лучше — свой бизнес, желательно такой, что от него зависят финансовые потоки. В идеале это такой бизнес что сам генерирует и контролирует финансовые потоки(так умеет государство )
Само по себе программирование без бизнес-специфики имеет жОстко ограниченый потолок в развитии, зп и тд и тд. С бизнес спецификой этого потолка уже нет или он находится много дальше. То есть, нужно осваивать бизнес в любом случае.
Здравствуйте, Ikemefula, Вы писали:
I>Само по себе программирование без бизнес-специфики имеет жОстко ограниченый потолок в развитии, зп и тд и тд. С бизнес спецификой этого потолка уже нет или он находится много дальше. То есть, нужно осваивать бизнес в любом случае.
Ну дык бизнес-специфика это и есть язык (специфика) предметной области (бизнеса). Налицо противоречие с изначально высказанной мыслью.
Нужно осваивать бизнес в любом случае — всё верно. Осваиваешь предметную область и, перекладывая её на программный код, создаёшь DSL.
Здравствуйте, Ikemefula, Вы писали:
I>Необязательно программирование. Модель говорит о том, что нужно быть там, где от тебя зависимость выше, а это быть поближе к бизнесу. Еще лучше — свой бизнес, желательно такой, что от него зависят финансовые потоки. В идеале это такой бизнес что сам генерирует и контролирует финансовые потоки(так умеет государство :-) )
Ты форумом ошибся. И даже сайтом. Я правда не знаю где ваши собираются, но точно не здесь.
Кстати, у Газпрома сайт есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ikemefula, Вы писали:
I>Необязательно программирование. Модель говорит о том, что нужно быть там, где от тебя зависимость выше, а это быть поближе к бизнесу. Еще лучше — свой бизнес, желательно такой, что от него зависят финансовые потоки. В идеале это такой бизнес что сам генерирует и контролирует финансовые потоки(так умеет государство )
I>Само по себе программирование без бизнес-специфики имеет жОстко ограниченый потолок в развитии, зп и тд и тд. С бизнес спецификой этого потолка уже нет или он находится много дальше. То есть, нужно осваивать бизнес в любом случае.
У меня только один вопрос — если ты такой умный, то чего такой бедный?
Здравствуйте, Ikemefula, Вы писали:
I>Наоборот, на пальцах : I>Бизнес это владелец + топ-менеджмент. Всё остальное обслуживает эту связку. Формула простая — нарисуй концентрические круги — 1 владелец 2 топменеджмент 3 маркетинг 4 производство 5 разработка. Каждый кружочек показывает систему, обслуживающую свой центр. Больше радиус — меньше влияние. Зависимость пропорциональна влиянию. ЗП пропорциональна зависимости. Все, приехали — обслуживающая система имеет заведомо меньшее влияние чем обслуживаемая.
Это вы рассказываете какую-то очень конкретную модель бизнеса. А вот, например, Минцберг выделяет шесть компонентов в структуре компании, и, в зависимости от специфики компании, главным может быть каждый из этих компонентов.
Очень хорошо, что вы читаете буквари менеджмента. Теперь пора почитать литературу для взрослых.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, koodeer, Вы писали:
I>>Само по себе программирование без бизнес-специфики имеет жОстко ограниченый потолок в развитии, зп и тд и тд. С бизнес спецификой этого потолка уже нет или он находится много дальше. То есть, нужно осваивать бизнес в любом случае.
K>Ну дык бизнес-специфика это и есть язык (специфика) предметной области (бизнеса). Налицо противоречие с изначально высказанной мыслью.
Бизнес-специфика это предметная область, точнее целый набор в конкретном бизнесе.
K>Нужно осваивать бизнес в любом случае — всё верно. Осваиваешь предметную область и, перекладывая её на программный код, создаёшь DSL.
А для ДСЛ сменить весь стек технологий и сделать бизнес зависимым от тебя, это тоже бизнес или нет ?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Само по себе программирование без бизнес-специфики имеет жОстко ограниченый потолок в развитии, зп и тд и тд. С бизнес спецификой этого потолка уже нет или он находится много дальше. То есть, нужно осваивать бизнес в любом случае.
НС>У меня только один вопрос — если ты такой умный, то чего такой бедный?
Здравствуйте, Sinclair, Вы писали:
I>>Наоборот, на пальцах : I>>Бизнес это владелец + топ-менеджмент. Всё остальное обслуживает эту связку. Формула простая — нарисуй концентрические круги — 1 владелец 2 топменеджмент 3 маркетинг 4 производство 5 разработка. Каждый кружочек показывает систему, обслуживающую свой центр. Больше радиус — меньше влияние. Зависимость пропорциональна влиянию. ЗП пропорциональна зависимости. Все, приехали — обслуживающая система имеет заведомо меньшее влияние чем обслуживаемая.
S>Это вы рассказываете какую-то очень конкретную модель бизнеса. А вот, например, Минцберг выделяет шесть компонентов в структуре компании, и, в зависимости от специфики компании, главным может быть каждый из этих компонентов.
Я показал упрощенную модель. У Минцберга ничего не меняется, девелоперы, которые ближе к главному компонету, имеют бОльшее влияние, т.е. зависимость от них больше. Куда деть девелоперов которые ближе к оставшимся 5 компонентам ?
И что ты действительно думаешь, что всей этой болтовней ты сможешь убедить народ в том, что не нужно совершенствовать средства производства?
Ты говоришь, что ДСЛ не нужны ибо они несут риски и требуют изучения.
А бизнес всеми силами борется с рисками.
Тогда скажи, почему появились пневматические молотки и шуруповёрты? Ведь они несут кучу рисков. И требует обучение персонала.
То ли дело простой молоток и отвертка. Любая обезьяна использовать может.
Ответ прост: Они значительно повышают производительность труда.
Со всей своей "философией" ты забыл про то, что кроме рисков каждая технология несет с собой преимущества.
И бизнес не борется с рисками, а балансирует преимущества и риски.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>А для ДСЛ сменить весь стек технологий и сделать бизнес зависимым от тебя, это тоже бизнес или нет ?
Как раз под капотом DSL сменить стек технологий гораздо легче, чем сменить, скажем, Java на C++.
Более того, если говорить о бизнес-ориентированных DSL, то, например, существует мнение, что Goldman Sachs выиграл финансовый кризис во многом благодаря тому, что у него был специальный DSL для оценки рисков (под капотом которого развилась огромная распределенная система) — гуглить Slang (DSL) и SecDB (система под ним).
Здравствуйте, Ikemefula, Вы писали:
I>Я показал упрощенную модель. У Минцберга ничего не меняется, девелоперы, которые ближе к главному компонету, имеют бОльшее влияние, т.е. зависимость от них больше. Куда деть девелоперов которые ближе к оставшимся 5 компонентам ?
Не надо никого никуда девать. Вы, наверное, невнимательно читали Минцберга.
Там у девелоперов возможны ровно два места: это либо в операционном ядре (если компания занимается производством софта), либо в техноструктуре.
Власть техноструктуры может быть значительной — для определённых типов компаний. Но она редко бывает главной.
А вот власть операционного ядра называется "адхократией", и она типична для инновационных компаний. В такой компании можно запросто заменить любого топ-менеджера, и ничего не изменится.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sorc17, Вы писали:
S>В современном мире любой реальный продукт производить не выгодно по сравнению, например, с банальными валютными спекуляциями на каком-нибудь Форексе. Ничего не делаешь, а купаешься в золоте.
А еще выгоднее покупать акции МММ. Если знать, когда оттуда выйти.
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Кто тебе сказал что я бедный ?
НС>Ты сам и сказал. Твои печальные истории про покупку айфона и непокупку макбука еще свежи в памяти.
То есть мне надо скупать все что вижу, дабы доказать что я не бедный ? Ну, тогда я бедный, ты прав.
Здравствуйте, jazzer, Вы писали:
J>Как раз под капотом DSL сменить стек технологий гораздо легче, чем сменить, скажем, Java на C++.
J>Более того, если говорить о бизнес-ориентированных DSL, то, например, существует мнение, что Goldman Sachs выиграл финансовый кризис во многом благодаря тому, что у него был специальный DSL для оценки рисков (под капотом которого развилась огромная распределенная система) — гуглить Slang (DSL) и SecDB (система под ним).
Язык без семантики никому и никогда не был нужен. Мнений может быть много, но ты вот уверен, что дело не в том экспириенсе который они накопили, а именно в ДСЛ ?
Здравствуйте, Sinclair, Вы писали:
S>А вот власть операционного ядра называется "адхократией", и она типична для инновационных компаний. В такой компании можно запросто заменить любого топ-менеджера, и ничего не изменится.
А кто определяет структуру компании ? Что будет если уволить это лицо ? почему есть разделение на административное и операционное ядро ?
Даём слово Минцбергу:
"Конечно, одним из решений проблем неопределенности и неэффективности является изменение конфигурации. Сотрудники, которые более не в силах мириться с неопределенностью, и клиенты, уставшие от неэффективности, могут попытаться придать структуре более стабильную, бюрократическую форму.
Как уже упоминалось, в операционной адхократии сделать это довольно легко. Организация просто стандартизирует свои лучшие программы и начинает на них специализироваться, постепенно превращаясь в профессиональную бюрократию. Или в последний раз вводит какое-либо новшество и с его помощью находит выгодную нишу на рынке и приступает к массовому производству, превращаясь в механистическую бюрократию.
"
Снова слово Минцбергу, про адхократию, там где это непосредтственно касается типичных девелоперских проектов:
"Идеально подходя для уникальных проектов, в то же время адхократия не умеет делать обычных вещей. Ее призвание – экстраординарность."
Вот когда все софтверные проекты станут уникальными и экстраординарным, я не спорю, девелоперы будут рулить. Пока что каждый второй российский девелопер занят фиксами в 1С. Еще значительная часть занята похожими делами. Никакая адхократия не имеет отношения к этой области.
