Смутные перспективы сферы IT...

[syan]

Не такая уж и надуманная, каждые четыре года в начале марта на тематических ресурсах появляются описания таких случаев.

Только бледнолицый брат умеет наступать на грабли дважды?

На проработку столь детальных ТЗ и также принятии готового продукта с такими доскональными тестами уйдет непомерно много ресурсов. Что само по себе приемлемо только для задач узкого круга.

В идеале - ТЗ (по ERP, например) составляется по ISO-9000 либо заказчиком, либо подрядчиком (и утверждается заказчиком) и в нем предусматриваются все возможные бизнес-процессы. Без этого браться за проект - самоубийство. "Сделай мне хорошо" - не ТЗ. Насколько я знаю, и в других областях есть опросные листы, заполняемые заказчиком, и процедура утверждения ТЗ - не самое легкое дело.

Поэтому заказчику часто далеко не все равно, на чем, с помощью чего продукт написан и с помощью чего он работает.
узкого круга.

ИМХО, нельзя заказчика делать арбитром в деле выбора инструмента реализации. Заказчик может не обладать достаточной подготовкой для решения вопроса. Я говорю о конечном потребителе. Я, как заказчик, на вопрос о, скажем, языке реализации ответил бы примерно так: вы специалисты, вы и решайте, а то потом начнется - вот, ты сам захотел на питоне, а, если бы мы на С писали, то тогда бы этих глюков не было.

И тимлиду не должно быть все равно если большая часть проекта написана скажем на ява а какой-то специалист хочет написать какой либо модуль на руби причем нет существенных плюсов в плане выбора последнего.

Если этому специалисту комфортнее писать на руби... Впрочем, я уже изложил свои взгляды на это. Есть еще один немаловажный вопрос - стиль программирования. Можно писать на одном языке, но совершенно в разных стилях. Я с этим сталкивался. У программистов, имеющих значительный опыт в самостоятельных проектах, стили различаются, порой очень сильно.

Руби никто не знает из остальной команды и не планирует его изучать в ближайшее время. Я уже не принимаю во возросшую сложность проекта по увязке всего этого.

Если вам в "сишную" команду нужен человек и у Вас есть выбор между 22-летним Васей, пишущем на С и Стивом Тейксейрой, который принципиально (допустим) пишет на Паскале, кого Вы выберете, при прочих равных условиях?
Конечно, нужно трезво оценивать преимущества и недостатки такого подхода в каждом конкретном случае.

[Fallout]

ИМХО, нельзя заказчика делать арбитром в деле выбора инструмента реализации. Заказчик может не обладать достаточной подготовкой для решения вопроса. Я говорю о конечном потребителе. Я, как заказчик, на вопрос о, скажем, языке реализации ответил бы примерно так: вы специалисты, вы и решайте, а то потом начнется - вот, ты сам захотел на питоне, а, если бы мы на С писали, то тогда бы этих глюков не было.

Это все сильно зависит от специфики проекта и самого заказчика

Если этому специалисту комфортнее писать на руби... Впрочем, я уже изложил свои взгляды на это. Есть еще один немаловажный вопрос - стиль программирования. Можно писать на одном языке, но совершенно в разных стилях. Я с этим сталкивался. У программистов, имеющих значительный опыт в самостоятельных проектах, стили различаются, порой очень сильно.

Да есть такой момент. Именно поэтому старшими разработчиками пишутся эталонные реализации чело либо и проводится ревью кода.

Я лично вообще сторонник достаточно жесткой стандартизации в рамках проекта, включая инструментарий, но конечно без фанатизма.

Если вам в "сишную" команду нужен человек и у Вас есть выбор между 22-летним Васей, пишущем на С и Стивом Тейксейрой, который принципиально (допустим) пишет на Паскале, кого Вы выберете, при прочих равных условиях?
Конечно, нужно трезво оценивать преимущества и недостатки такого подхода в каждом конкретном случае.

Тяжело представить себе такой выбор так как уж очень много факторов влияет которые не позволяют вывести те самые прочие равные условия.
Стив конечно хорош, но скорее всего он будет как чемодан без ручки. Так что вполне выбор может пасть на Васю.

[oxigen_]

В идеале - ТЗ (по ERP, например) составляется по ISO-9000 либо заказчиком, либо подрядчиком (и утверждается заказчиком) и в нем предусматриваются все возможные бизнес-процессы. Без этого браться за проект - самоубийство. "Сделай мне хорошо" - не ТЗ. Насколько я знаю, и в других областях есть опросные листы, заполняемые заказчиком, и процедура утверждения ТЗ - не самое легкое дело.

Это конечно прекрасно, когда заказчик приходит с готовым ТЗ. Но такое случается редко.
Гораздо чаще заказчик хочет именно "чтоб ему сделали хорошо". И зачастую представление об этом "хорошо" меняется в процессе разработки.

[syan]

Это конечно прекрасно, когда заказчик приходит с готовым ТЗ. Но такое случается редко.
Гораздо чаще заказчик хочет именно "чтоб ему сделали хорошо". И зачастую представление об этом "хорошо" меняется в процессе разработки.

Не знаю. У меня бывает три варианта.
1. Заказчик разрабатывает ТЗ. Обсуждаем. Принимаем. Подписываем.
2. Я разрабатываю ТЗ для заказчика. Обсуждаем. Принимаем. Подписываем.
3. Я отказываюсь от задачи.
Но, менять ТЗ в процессе разработки я не буду. Ни за какие деньги. Кроме того, мои заказчики, в том числе и внутренние (основное место работы у меня в торговой компании, где я веду постоянный проект), недоделанных проектов не видят. Они получают готовый работоспособный вариант, соотвествующий ТЗ (и внутренние тоже пишут!). Был у меня опыт "сделай мне хорошо", закончилось это вялотекущим долгостроем, причем доделки/переделки на боевой базе данных, с большим коллективом. Скандалы, взаимные упреки, программисты, бросающие проект на полдороги (отсюда, кстати, мелкая модульность)...

[oxigen_]

Да я смотрю Вы просто счастливый человек.
Сопровождением своих проектов не занимаетесь, диктуете заказчикам свои условия...

Но большинство программистов работают в совершенно иных условиях )

[syan]

Да я смотрю Вы просто счастливый человек.
Сопровождением своих проектов не занимаетесь, диктуете заказчикам свои условия...

Но большинство программистов работают в совершенно иных условиях )

Ну, почему же? Не совсем "не занимаюсь". Но дописывать в боевой проект не стану. Если клиент хочет, то будет разработана новая версия, по новому ТЗ, за новые деньги. Или дописан и интегрирован новый модуль (dll-ка и ехешник-оболочка). Мне так легче. Денег меньше, зато и хлопот меньше. У меня есть пару проектов, которые работают вообще без вмешательства несколько лет. Правда, это небольшие магазины. Если они "вырастут" из моей программы, они могут либо заказать у меня другую версию, либо выбросить мою программу и заказать у кого-нибудь другую. Поверьте, в последнем случае я тоже не расстроюсь.
А как не диктовать клиенту свои условия? Хвататься за каждую работу на условиях клиента? Слава богу, пока еще нет закона, по которому программист обязан оказывать услугу на невыгодных ему условиях. Или я не в курсе и в вузах нынче дают "клятву Дейкстры", например?

[Hose]

syan, Вам можно позавидовать, однако
Заказчик, который точно знает чего хочет на этапе согласования ТЗ и готов согласиться, что ТЗ никогда не будет меняться - невиданной редкости существо. Или проект невысокой сложности.
разумеется дерибанить боевой проект - дело тухлое,
но ПО приходится периодически расширять, улучшать,
выпуская новые релизы.

[glyph]

syan, Вам можно позавидовать, однако
Заказчик, который точно знает чего хочет на этапе согласования ТЗ и готов согласиться, что ТЗ никогда не будет меняться - невиданной редкости существо. Или проект невысокой сложности.
разумеется дерибанить боевой проект - дело тухлое,
но ПО приходится периодически расширять, улучшать,
выпуская новые релизы.

+1. Такой заказчик настолько редкое явление, что даже в ISO стандартизирован процесс внесения изменений в ТЗ во время разработки.

Собственно, это закономерно. ПО - это отражение реальности, которая практически никогда не бывает статичной. Пока полгода писали ПО, у заказчика много чего может поменяться, по совершенно объективным обстоятельствам. Не адаптироваться в таких случаях - глупость и профессиональное самоубийство.

[syan]

+1. Такой заказчик настолько редкое явление, что даже в ISO стандартизирован процесс внесения изменений в ТЗ во время разработки.

Собственно, это закономерно. ПО - это отражение реальности, которая практически никогда не бывает статичной. Пока полгода писали ПО, у заказчика много чего может поменяться, по совершенно объективным обстоятельствам. Не адаптироваться в таких случаях - глупость и профессиональное самоубийство.

Я ПО по полгода не пишу максимум - 2 месяца (обычно - месяц). Я не пишу MS Office, я пишу БД с оболочками. Стараюсь не браться за работы, привлекательные финансово, но с маловменяемым заказчиком. Если в течение разработки ТЗ возникают проблемы, типа "Ой! Я теперь хочу не мелкий опт, а розницу и не продажи, а логистику" - я стараюсь отказаться. А вообще, простите, какая может возникнуть непреодолимая проблема в сфере моих интересов? Формула расчета меняется? FIFO на LIFO? Честно говоря, все расчеты я стараюсь вообще всобачивать в БД, оболочка - и есть оболочка. На логику учета она влиять не должна.
Возможно, в каких-то областях ИТ, с которыми я не знаком (ну, переводчики, обучающие программы, экспертные системы, etc.) это невозможно, спорить не стану. Но в торговле - принципы не меняются. Вернее, я не сталкиваюсь с тем, что невозможно предусмотреть на этапе проектирования, или путем изменения хранимой процедуры/триггера поменять малой кровью.
Возможно, я поступаю глупо. Возможно, у меня не будет (и нет, собственно) армии клиентов, жаждущих "написаться" у меня. Зато я спокойно сплю и могу позволить себе даже пофлудить на форумах. Собственно говоря, если бы я зарабатывал на жизнь только этими заказами, я бы, скорее всего, был бы чуть менее переборчив, но не намного.
Видите ли, дело в чем. Я считаю, что ИТ-продукт - такой же товар, как и, скажем, автомобиль или кофеварка. Хочется, конечно, чтобы твоя кофеварка называлась Braun, но и на Vitek есть покупатели. И, мне главное, чтобы мой Vitek не сломался раньше Braun'а, а то, что мой клиент потом сменит меня на Braun, потому что Braun круче, меня не трогает. Vitek окупился в момент расчета клиента. Я продал, клиент купил, все довольны. А за стеклоподъемниками в комплекте - это к BMW. У меня Таврия. Где-то так.

[Fallout]

Я ПО по полгода не пишу максимум - 2 месяца (обычно - месяц). Я не пишу MS Office, я пишу БД с оболочками. Стараюсь не браться за работы, привлекательные финансово, но с маловменяемым заказчиком. Если в течение разработки ТЗ возникают проблемы, типа "Ой! Я теперь хочу не мелкий опт, а розницу и не продажи, а логистику" - я стараюсь отказаться. А вообще, простите, какая может возникнуть непреодолимая проблема в сфере моих интересов? Формула расчета меняется? FIFO на LIFO? Честно говоря, все расчеты я стараюсь вообще всобачивать в БД, оболочка - и есть оболочка. На логику учета она влиять не должна.
Возможно, в каких-то областях ИТ, с которыми я не знаком (ну, переводчики, обучающие программы, экспертные системы, etc.) это невозможно, спорить не стану. Но в торговле - принципы не меняются. Вернее, я не сталкиваюсь с тем, что невозможно предусмотреть на этапе проектирования, или путем изменения хранимой процедуры/триггера поменять малой кровью.
Возможно, я поступаю глупо. Возможно, у меня не будет (и нет, собственно) армии клиентов, жаждущих "написаться" у меня. Зато я спокойно сплю и могу позволить себе даже пофлудить на форумах. Собственно говоря, если бы я зарабатывал на жизнь только этими заказами, я бы, скорее всего, был бы чуть менее переборчив, но не намного.
Видите ли, дело в чем. Я считаю, что ИТ-продукт - такой же товар, как и, скажем, автомобиль или кофеварка. Хочется, конечно, чтобы твоя кофеварка называлась Braun, но и на Vitek есть покупатели. И, мне главное, чтобы мой Vitek не сломался раньше Braun'а, а то, что мой клиент потом сменит меня на Braun, потому что Braun круче, меня не трогает. Vitek окупился в момент расчета клиента. Я продал, клиент купил, все довольны. А за стеклоподъемниками в комплекте - это к BMW. У меня Таврия. Где-то так.

Да, действительно у вас редкое явление. Небольшие проекты да и еще возможность перебирать заказчиками.

[glyph]

Я ПО по полгода не пишу максимум - 2 месяца (обычно - месяц). Я не пишу MS Office, я пишу БД с оболочками.

Значит, я был прав, когда сказал про личный опыт. У меня такого масштаба проект был только один, самый первый. После этого (хз, повезло\не повезло) были проекты крупнее. На одном из проектов было около 500 разработчиков и около 200 инженеров, а сама команда была поделена между Бразилией, Европой и Пакистаном. И поверь мне: CR и текучка там были рядовым явлением, сроков-то три года как-никак. В таких условиях от уползания в хаос спасает только стандартизация среды. И да, клиент настаивал на инструментах и технологиях, так как после освоения продукта были планы торговать им дальше и оказывать поддержку самостоятельно. Вполне резонные требования, кстати. Я думаю, что модуль на С в насквозь java-вском приложении был бы неожиданным сюрпризом.

Я считаю, что ИТ-продукт - такой же товар, как и, скажем, автомобиль или кофеварка.

Строго говоря, ИТ-продукт далеко не такой же товар как автомобиль или кофеварка. В определенных случаях это правильное сравнение, но не обобщенное. Ты подразумеваешь вполне определенную модель жизненного цикла продукта, но она ведь не единственная. Бесспорно, существуют условия, в которых все, что ты сказал, нормальная и разумная практика. Вопрос в том, как часто такие условия встречаются.

[syan]

В таких условиях от уползания в хаос спасает только стандартизация среды. И да, клиент настаивал на инструментах и технологиях, так как после освоения продукта были планы торговать им дальше и оказывать поддержку самостоятельно.

Вот-вот. Именно в этом-то и заключается, на мой взгляд, кризис жанра.

Строго говоря, ИТ-продукт далеко не такой же товар как автомобиль или кофеварка.

Ну, строго говоря, как раз такой же, как и все остальные. Просто товар. Как категория. Как сущность, входящая в формулу Деньги-Товар-Деньги. Пачка писчей бумаги совсем не похожа на автомобиль или политический трактат, но и то и другое, и третье - товар.

В определенных случаях это правильное сравнение, но не обобщенное. Ты подразумеваешь вполне определенную модель жизненного цикла продукта, но она ведь не единственная. Бесспорно, существуют условия, в которых все, что ты сказал, нормальная и разумная практика. Вопрос в том, как часто такие условия встречаются.

Вероятно, нередко. Т.е., я вот что хочу сказать - есть масса задач которые можно решить, да - индивидуальным подходом, да - стандартизируя только результат, но - дешевле и меньшими усилиями. И есть достаточное количество клиентов, которым нужно быстро, дешево и без необходимости ежедневного администрирования. Да, что там "достаточное", таких большинство (чисто в количественном выражении). Но я встречал не одну компанию, выбравшую монстра SAP, например, или Navision там, где достаточно было бы самостоятельной разработки. И платят, платят, платят... За поддержку, за адаптацию (хотя им сказали, что SAP - на все случаи жизни). И кормится этим легион программистов (грешен - сам этим кормлюсь), которые, возможно, могли бы создать оригинальный и прорывной продукт, но ковыряются в рамках Системы. Отсюда скучный код, отсюда таскаемая за собой java-машина. Отсюда "вирусы" размером с натурального троянского коня и терабайтные базы данных. И, наконец, отсюда дикие требования к аппаратным платформам. А считаем-то мы то же, что и 10 лет назад. И, если 10 лет назад гипермаркет, скажем, спокойно работал на РIII-500, то сейчас...
Перехода количества в качество нет. А, может быть, есть, но я, в силу своего провинциализма, не вижу? Может быть, все возможные ОС разработаны и лучших не придумаешь?

[syan]

syan, Вам можно позавидовать, однако
Заказчик, который точно знает чего хочет на этапе согласования ТЗ и готов согласиться, что ТЗ никогда не будет меняться - невиданной редкости существо. Или проект невысокой сложности.
разумеется дерибанить боевой проект - дело тухлое,
но ПО приходится периодически расширять, улучшать,
выпуская новые релизы.

О релизах - не возражаю. Я не против новых версий. Я именно против "дерибанить боевой проект". Так что, ТЗ - пусть меняется. После сдачи проекта. Будет новая версия, которую заказчик тоже оплатит. Рамочные договоры - кабала, в которую лезть не шибко хочется - есть живые примеры перед глазами - программа, которую разработчики дописывают, на моей памяти, уже 6-й год. За абоноплату. И версии меняются раз в два-три месяца только потому, что приходится интерфейс переделывать - он много функционала выполняет, и структура базы меняется, а программа так и не выросла из своих штанов, хотя проект востребованный в определенных кругах и, в своем роде, хорош.
О сложности: дело не в сложности программы, дело в сложности задачи. Ну, можно закрутить шуруп отверткой за 3 гривны, а можно шуруповертом за 300. Результат один. Да и скорость, с учетом снаряжения шуруповерта "битой" и зарядкой аккумулятора, одинакова.

[glyph]

есть масса задач которые можно решить, да - индивидуальным подходом, да - стандартизируя только результат, но - дешевле и меньшими усилиями.

И есть достаточное количество клиентов,

Общеизвестно же, что рынок поделен на ниши, категории и прочие единицы. Есть целевая аудитория такого плана, есть другого. И никто не мешает делать дешевле и меньшими усилиями, тем более, использовать это как конкурентное преимущество. При прочих равных, разумеется.

Но я встречал не одну компанию, выбравшую монстра SAP, например, или Navision там, где достаточно было бы самостоятельной разработки.

Ну, может, встретишь еще. Deutsche Bahn, например. Масштабы собственных разработок там коллосальны. Их R&D вообще находится в одном городе с SAP, при этом Deutsche Bahn еще и проектирует для себя оборудование разное, от цифровой техники до электросиловых установок. Ряд портов и разных терминалов используют общую платформу и разрабатывают правила сами. Или я не так понял?

И платят, платят, платят... За поддержку, за адаптацию (хотя им сказали, что SAP - на все случаи жизни). И кормится этим легион программистов (грешен - сам этим кормлюсь), которые, возможно, могли бы создать оригинальный и прорывной продукт, но ковыряются в рамках Системы. Отсюда скучный код, отсюда таскаемая за собой java-машина.

Скучный скорее не код, скорее проблемная область для тебя скучная. И это... страна у нас к Мордору близко. Часто интересы клиента лежат в ортогональной плоскости к твоим, особенно, если клиент работает мешком или пилой. Собственно, поэтому у нас госзаказ или что-то по учетно-хозяйственной части - это смрадное болото с утопленниками.

Объемы же сами по себе мало чего говорят. Есть интересный сервис flightcaster, где-то должно быть интервью и презентация Брэдфорда Кросса по технической стороне вопроса. Им приходится обрабатывать террабайты в буквальном смысле и они не хранят состояние (в любой момент можно вырубить питание серверу приложений, затем включить - при сохранности БД процесс продолжается с нужного момента). Но это же у нормальных людей. А у нас "мозг размером с планету" реально может кое-как вести кадры Дома Пионеров.

Перехода количества в качество нет. А, может быть, есть, но я, в силу своего провинциализма, не вижу? Может быть, все возможные ОС разработаны и лучших не придумаешь?

Все зависит от твоего новостного ресурса. Серьезно.

Качественные изменения будут, когда мы начнем решать качественно новые задачи. А это медленный переходный процесс: всего 30% населения подключены к сети, хотя веб изобрели в еще 92м, а tcp/ip и того раньше.

И лично мне кажется, что даже сегодня технология обещает нам качественно новые вещи, просто плюшек мало и на всех их не хватает. В том числе и нам.

[syan]

Офф... Джойстик женского пола. Забавно.

[oxigen_]

Если вернуться к теме и вспомнить о "кризисе в IT", то можно сделать выводы:
В сфере недорогих ВЕБ проектов царит кризис и высокая конкуренция.
Зато в сфере недорогих десктопных приложений с БД полная благодать и стада непуганых заказчиков даже готовы писать ТЗ по стандартам.
Так что бросайте свой PHP.

[syan]

Так что бросайте свой PHP.

Плюсадин

[Rexulnicheck]

Зато в сфере недорогих десктопных приложений с БД полная благодать и стада непуганых заказчиков даже готовы писать ТЗ по стандартам.

Да, но зато такие конторы, которые этим занимаются требуют уже хоть какого-то опыта... И смысла учить жабу или сишарп шобы потом не найти работу особо нету... Хотя учить их канеш не долго... Особенно зная например C++ и PHP...

[oxigen_]

Зная С++ как раз работу найти несложно.

[Rexulnicheck]

Зная С++ как раз работу найти несложно.

В каком городе?
Для этого надо опыт кстати тоже иметь, да и вакансий по C++ куда меньше, чем по C# и Java...