Дефицит интересных проектов

С начала 2000-х и почти до наших дней отечественные программисты жили по принципам, озвученным в известной басне Крылова:

Попрыгунья Стрекоза
Лето красное пропела;
Оглянуться не успела,
Как зима катит в глаза.

Обычно смена работы в программировании с 2001 по 2008 гг. выглядела примерно так:

  • виток инфляции зарплат;
  • осознание того что Андрей/Игорь/Сергей перешел в компанию К, где он получает на 30% больше просто так;
  • хождение по паре собеседований и собственно переход в какую-то компанию, в которой все было новое, интересное и увлекательное.

Внезапно поток интересных вакансий на новых технологиях исчерпал себя (сужу по Microsoft technology stack). Внезапно всем нужны так называемые «миддлы». Внезапно большинство проектов — это поддержка существующих решений, начатых в лучшем случае 4-5, а иногда и все 10 лет назад.



© Idastalder

Что происходит?

Лично я с 2007 по 2011 год задержался на одном месте работы (US startup) и особо не интересовался происходящим на улице, благо компания обошлась незначительным снижением зарплат в кризис для тех, кто не попал под сокращения. Рынок не оценил в конце концов наших усилий, стартап не взлетел, и его решили законсервировать летом 2011 г.

Быстрая публикация резюме и десяток откликов в течении нескольких дней усыпили мою бдительность, и я с мыслью «Ура, наконец-то я буду использовать все новые технологии вместо старых неудобных костылей!» пошел по собеседованиям.

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

Тяжкое наследие

Идет работа над старым проектом, начатым в 2004-2007 году, и компании нужны рабочие руки, чтобы развивать его дальше. Внезапно я осознал, что вакансий с высокой оплатой — ну, я ж не буду ущемлять свои интересы, — под новые проекты я не встретил вообще.

Я слышал примерно следующее:

  • «Да, мы читали, что MVC — это круто, но у нас есть насущные задачи; а потом, когда мы это все сделаем, мы перейдем на MVC, и поэтому нам интересна ваша кандидатура.»
  • «Технологии у нас диктуются датским/немецким (нужное подчеркнуть) клиентом, потому мы мало того, что используем старые технологии, так еще и вот такие вот неизвестные (все относительно, конечно) библиотеки.»
  • «Зачем этот MVC, у нас и веб-формы неплохо справляются.»

Туда, не знаю куда

Вторая серьезная проблема — это компании, которые вообще не могли объяснить, что же конкретно придется делать. Рекрутер рассказывает что-то примерно такое:

«Это очень классная компания из Калифорнии. Мне так понравилось у них в офисе, у них такие вкусные печеньки. Это молодые ребята — вам точно с ними понравится работать.»
«Ну, вы будете работать над проектом в финансовой сфере, где вам придется использовать WPF, WCF, C#, C++, SQL, Oracle и что-то там еще (и писать ++i а не i++, потому что это быстрее — привет, EPAM).»

При этом всем очень нужно закрыть вакансию, причем побыстрее (угадайте, почему). И вникнуть, что же там такое, наверное, элементарно некогда. Вот недавно, мне прислали запрос, вдруг я кого знаю, следующим текстом — так и быть, дословно:

We are going to move forward with one Java/Android resource. After we find the first one, we may go for a second one as well. But, lets find a good lead and then we can build from there.

As I mentioned on the phone, generally speaking we are looking for a very, very smart developer with 5+ years experience in Java. Having experience developing on the Android is a plus but not an absolute requirement.

Обратите внимание — ни слова о том, что за проект и будет ли вообще это интересно этому человеку. А если вы вздумаете попросить более подробной информации вам могут рассказать, где находится офис (как будто все еще есть такая большая разница, где именно работать — хоть в Египте, лишь бы был Wi-Fi) и сколько дней отпуска дается (о чем тоже мы все знаем).

Уровень зарплаты при этом ведь примерно одинаков и сохраняется в тайне до последнего. И тут, я думаю, 75% айтишников уже думает, о чем вообще статья? Разве может быть по-другому?

Что случилось?

Давайте отстранимся от личного выбора и подумаем, почему же так происходит?

Причина одна — новые интересные проекты не идут в Киев:
  • компании предлагают часы, а не решения (еще лучше предлагать чудо). Такой рейт себе могут позволить только состоявшиеся компании (и у них уже есть система, которую написал кто-то — естественно, давно и, естественно, на старых технологиях);
  • компании, в основной своей массе, не имеют портфолио, которое несло бы эмоциональную нагрузку. Считается, что важнее сказать, что ты делал софт для BMW, NBA или же Nestle (даже если это сайт из одной формы на три дня работы);
  • компании не предлагают команд, решающих проблемы заведомо лучше других.
По сути, зарплаты аутсорсинга в Киеве держатся на том факте, что здесь были созданы команды N лет назад. Такую команду целиком никуда не перевезешь (у нас вообще резидентная мобильность ниже средней). И, если повезло и бизнес клиента растет, то и его команда в Киеве тоже будет расти.

Потому и старые проекты.

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

Поэтому и нет времени особо вникнуть в суть проекта — ведь так сложно закрыть 50 вакансий в месяц.

При этом абсолютно всем все равно, что разработчики не одинаковы в своей продуктивности, говорит Joel. (Если, кто-то хочет поспорить, скажите, сколько разработчиков вы уволили за последний год? Я — троих из шести новых; в аутсорсинге человека будут переводить из проекта в проект, но чтобы уволить...)

Мой личный выход оказался в freelance. Оказывается, есть люди, которые готовы вкладывать в местные технологичные проекты. Наши заказчики не владеют английским и не могут искать исполнителей за рубежом, то есть, по сути, конкуренция намного ниже.

Да, их меньше. Да, в какой-то мере с ними сложнее. Но вот сказать, что они меньше платят, я не могу — наш рынок и политическая обстановка быстро меняются, и результат нужен вчера, так что если вы реально компетентны, вы можете получить любую разумную цену.

Что делать глобально?

Мне кажется, компаниям нужно вырабатывать специализацию и натаскивать сотрудников в определённой сфере.

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

К примеру, проблема масштаба большинству разработчиков просто неизвестна; некоторые приложения могут требовать особо сложный клиентский пользовательский интерфейс и т.п.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

LinkedIn

Схожі статті




Найкращі коментарі пропустити

Рулезная статья. Актуальная тема и ситуация описана точно. А вот причины и выводы хочу прокомментировать. Причины:
1. Потому что больше всего вакансий в крупных «бодишопах» где высокая текучка. В небольшой компании, которая делает интересные проекты уже есть сплоченная команда и новые люди не нужны. А если и нужны то они найдут по рекомендации — вакансию публиковать не будут.
2. Потому что «бизнес большинства компаний строится на людях, которые не производят аутсорсинговый продукт, а непосредственно им являются». Такие компании больше всего заинтересованны в «толстом» заказчике с «бесконечным» проектом, который начался много лет назад и будет продолжаться еще столько же. «Мелкие» заказчики с рискованными проектами на новых технологиях их интересуют гораздо меньше.
3. На новых технологиях и R&D проектах риски намного выше. Сложно набрать команду («дутые» синьоры просто не потянут). Выше вероятность что заказчик «отвалится» (передумает делать, конкуренты обойдут и т.д.).

4. Аутсорс — заказчики банально не хотят платить за качество. Им очень тяжело продать хороший дизайн, юнит-тестирование, рефакторинг и другие «лишние» активности. Они готовы получить спагетти-код, лишь бы дешево. Естественно через 2 года такой проект становится не то что «не интересным» а насквозь гнилым (бесконечный багфикс и переделки).

Выводы: компании не волнует «интересность» проекта (их интересует прибыль). Поэтому они ничего не «должны» и не будут делать. У тех, кому повезло попасть на «интересный» или хотя-бы новый проект, просто будет меньше стимулов свалить и освободить место для других желающих.
Процент интересных проектов и новых технологий будет выше в небольших и новых компаниях, которым надо как-то продвигаться на рынок. Большие компании наоборот — плодят бюрократию и «загнивают».

Девелоперу же надо признать простую истину: «интересность», «рискованность», «доходность» и «утомительность» проекта взаимо-зависимы. Очень интересную работу делают в опенсорс-проектах бесплатно и в свободном темпе. Средне-интересная работа в стартапах, где платят мало, надо «вкалывать» и есть риск «прогореть». Ненапряжная «тупая» работа со стабильной оплатой — в «бодишопах». Интересная и высокооплачиваемая работа без «авралов» и «кидалова» — это скорее исключение, подтверждающее это правило.

Для тех кто ищет интересный проект :))

s2.ipicture.ru/...12/BAcsApRC.png

Занятно, что в этой теме на 90% под «интересными проектами» подразумевается «проект, основанный на свежем технологическом стеке», а не интересный в силу предметной области/нетривиальности реализации. Т.е. место, где можно за деньги выучить новую для себя технологию или практику, а не используя текущие знания, решить задачу более высокой степени сложности.

Мне кажется, компаниям нужно вырабатывать специализацию и натаскивать сотрудников в определённой сфере.

А к кому конкретно этот призыв? К владельцам и директорам компаний? Так им и так вроде не плохо. Извините, но Вы требуете от других людей обеспечить Вам интересное и высокооплачиваемое рабочее место. Freelance — кстати реально выход и рост, там уже перестаешь мыслить категориями «сделайте мне хорошо», но и интереса с высокооплачиваемостью там не так чтобы очень много.

А вообще я давно наблюдаю насколько сильно отличается тональность DOU.ua от каких-нибудь специализированных сообществ Долины. На DOU практически не обсуждают «что делаем», а только разговоры о том «как» и «по чем». Создается впечатление, что о стартапах, их философии и собственно за чем они создаются (и закрываются) сотнями, большинство наших разработчиков не знает и не хочет знать категорически. К сожалению, возможно именно поэтому, в Киеве (и вообще в СНГ) экосистемы стартапов почти нет.

Причина одна — новые интересные проекты не идут в Киев:

:) А я скажу наоброт. Интересные проекты должны идти не в Киев, а из Киева. Кто мешает сделать что-то интересное самим?

Это первый текст про «проблемы оутсорса» который сказал чтото действительно стоящее(!).

326 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Тогда самая неинтересная работа — у врачей. Вот уж кто обречён всю жизнь копаться с устаревшими на тысячи лет механизмами. Работающими по технологиям которым больше лет чем человечеству. Мало того, иметь дело с ещё большими бездарями в тех же технологиях. И доверять их использование в самые некомпетентные руки. А после ремонтировать — снова и снова. Зная, что их труд в конце концов умрёт.

И почему тогда люди смотрят Хауза?

// А я занимаюсь производством людей. Заведомо зная что ничего не получится, это имитация. По устаревшим технологиям. По документации (вдумайтесь) индусов! Пожалейте меня ;(

Есть проект на CQRS, DDD, RavenDB, ASP.NET MVC в Киеве в «продуктовой компании». Если интересно — пишите в личку. Вообще по своему опыту скажу — интересные проекты в Киеве есть, просто вы либо плохо ищете, либо по скилам не подходите.

Вдруг вы знаете проект, который показывает, что автор статьи не прав — маякните

IMHO само понятие «технологический стек» — бред. По одной простой причине: цель программного обеспечения в том, чтобы объяснить компьютеру, чего же хочет человек. По сути два конца: человеки и компьютер. И тем и другим в сущности наплевать, что вы там использовали в качестве посредников.

Большинство технологий рождались со светлой миссией — облегчить труд разработки. А заканчивалось как всегда — нужно учить технологию, потому что на неё мода. Мода проходит, а требование знать технологию остаётся (проекты уже есть или были).

Люди, работающие на одном месте достаточно долго, подтвердят — нет никаких «чудесных» технологий! Что действительно есть — так это огромный стек наработки компанией. Именно конечные примеры, библиотеки, шаблоны (и ещё раз шаблоны) — составляют стек компании. И ничто не мешает компании (а не каждому сотруднику по-отдельности) перейти на новую технологию — по сути это всего лишь изменить шаблоны.

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

Для меня трудности в IT всегда связаны с людьми, изредка с существующими системами (творениями людей), и никогда — с технологиями. Всё что людей не касается — идеально поддаётся документированию, изменению, согласованию, и всегда есть несколько практически идентичных способов.

Занятно, что в этой теме на 90% под «интересными проектами» подразумевается «проект, основанный на свежем технологическом стеке», а не интересный в силу предметной области/нетривиальности реализации. Т.е. место, где можно за деньги выучить новую для себя технологию или практику, а не используя текущие знания, решить задачу более высокой степени сложности.

Действительно сложные задачи редко отдают в аутсорс. Разработкой алгоритмов для распознавания образов, речи или другими R&D разработками обычно и занимаются в институтах.
Предметная область для девелопера не очень важна. Медицина или банковское дело — девелоперам все равно не хватит знаний что бы понимать детали. Да им это и не надо. Бизнес-приложение это обычно база, сайт, сервисы, десктоп или мобильный клиент. При этом все собирается на готовых фреймворках + 3-пати библиотеки. Все сложные алгоритмы обычно уже кто-то реализовал за нас.
Это только самопальные гейм-девелоперы для каждой игры пишут свой новый 3Д движок (потому что им интересно).
Поэтому найти «интересный» проект в виде «100 первый интернет-магазин», но на новой платформе гораздо проще, чем «построение 3-D модели внутренних органов по данным ультразвукового сканирования» на старом-добром С++.

Лично для меня интересным проектом стало бы даже переписывание нашего никому не нужного проекта на «свежем технологическом стеке». Выкидывать «гнилой» код — это уже удовольствие.

Действительно сложные задачи редко отдают в аутсорс, но нередко отдают филиалам. Их у нас немного, но есть.

Предметная область для девелопера не очень важна.
Достаточно спорное утверждение, верное только для определенного типа проектов и только до определенного уровня девелопера. По сути, быть слабознакомым с предметной областью можно только в совершеннейшем аутстаффе: вам спеки спустили — вот по спекам и пишите.
Все сложные алгоритмы обычно уже кто-то реализовал за нас.
Справедливо только для случаев (цитирую)"При этом все собирается на готовых фреймворках«. Для ряда задач алгоритм в худшем случае специфицирован и реализации нет вовсе, в лучшем — есть некая эталонная реализация, имеющая тот или иной набор ограничений. Для ряда задач и вовсе постоянная возня в области алгоритмов — источник вечного движения, например, в области криптографии.
Поэтому найти «интересный» проект в виде «100 первый интернет-магазин», но на новой платформе гораздо проще, чем «построение 3-D модели внутренних органов по данным ультразвукового сканирования» на старом-добром С++.
На самом деле, проектов второго типа достаточно немало. У них просто есть два больших ограничения:
— на таких проектах зачастую ищутся уже «готовые» люди, либо же они пропускаются через внутреннюю интернатуру.
— особой новизны в технологическом стеке там не будет: добавлять к рискам R&D проекта риски незнакомства с технологией не рискнет никто.

Ну и вдобавок — это, как правило, проекты в компаниях, которые связаны с производством, а из этого следует то, что можно близко познакомиться с водопадной разработкой, жесткой поркой за попытки вылазить из рамок CMMI и тому подобными вещами, связанными с средне- и долгосрочным планированием.

Ну) Не собираюсь доказывать, что все что на новых технологиях — интересно, да и не считаю я так.

Скорее, чрезмерно устаревшие технологии являются индикатором огромного технического долга, накопленного и растущего в проекте. (Наверняка исключения есть). Вот занятная статья на тему почему его нельзя игнорировать — www.sig.eu/...5-nugroho-1.pdf

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

И львиная доля этого интересного процесса — согласование и обсуждение, тестирование идей. Кодирование не самое важное. Важно не как писать код, а как построен алгоритм. Если через «универсальный интерфейс» — никакой гуру из него конфетку не сделает.

Интересное обсуждение получилось.

Добавлю свои пять копеек.

Интересных проектов не много, по моему мнению, потому что:

а) Интересные проекты не интересны подавляющему большинству программистов;

б) Существует серъёзный языковый барьер через который ещё как-то могут просочиться несложные инструкции по саппорту, но проект который ты родил и растил как ребёнка — попробуйте рассказать его суть индусам с их английским, пусть даже они неплохие ребята, исполнительные и недорогие. Я бы не рискнул.

в) Надеюсь, скоро будет много наших заказчиков, но рейт там в 50% от бодишопного. Единственный вариант работы с ними — это обеспечение лайф-стайл на бодишопе, а с нашими по остаточному принципу.

г) Зарплата мало влияет на интересность — потому как:

«Сам я на гонорарную политику смотрю просто: чем больше,
тем лучше, все писательские разговоры о материальном
стимулировании не стоят ломаного гроша. Вот это Ойло Союзное
орет все время, что, дескать, если бы ему платили, как
Алексею, он бы писал, как Лев. Врет он, халтурщик. Ему
сколько ни плати, все равно будет писать дерьмо. Дай ему
хоть пятьсот за лист, хоть семьсот, все равно он будет
долдонить: хорошо учиться, дети, это очень хорошо, а плохо
учиться, бяки, это никуда не годится, и нельзя маленьких
обижать. И будет он все равно издаваться благополучно,
потому что любой детской редакции занаряжено, скажем,
тридцать процентов издательской площади под литературу о
школьниках, а достанет ли на эти тридцать процентов хороших
писателей — это уже вопрос особый. Подразумевается, что
достанет. А вот Вале Демченко плати двести, плати сто, все
равно он будет писать хорошо, не станет он писать хуже,
оттого что ему платят хуже, хотя никакие площади под его
критический урбанизм не занаряжены, а рецензенты кидаются на

него, как собаки...»

У меня есть пару интересных проектов и адекватный бюджет. Нет модного офиса и медстраховки. Также нужно уметь работать в динамичной среде и при этом писать нормально структурированный код. Так что пишите, кому скучно :) Да, технического английского вполне хватит.

нужно уметь работать в динамичной среде

Что такое «динамичная среда»?

Нет модного офиса и медстраховки

Это плохо

Динамичная — это значит временами приходится отклонятся от плана итерации и вносить в системы изменения, нужные бизнесу здесь и сейчас.

временами приходится отклонятся от плана итерации

Если в пределах восьми часов рабочего времени, это вообще не должно быть проблемой и можно об этом не писать. Грубо говоря: мне платят за то, чтобы я решал проблемы заказчика. Восемь часов окончились, встал и пошел домой.

При такой постановке вопроса вообще можно не заморачиваться.

в харькове с мед. страховкой можно разве что в туалет сходить. а в киеве ситуация отличается? у нас в больницах надо башлять сразу деньги, если со сраховкой то ты идёшь побоку, и цены там завышены раз в 5-10 будут

харькове с мед. страховкой можно разве что в туалет сходить. а в киеве ситуация отличается?

Да, пациент со страховкой ничем не отличается от обычного. Лечился по страховке два раза, всё оплатили. Я заплатил только за какое — то лекарство, которого у них не было. И то говорили, что мол принесите чек и мы компенсируем, но сумма была копеечной и я забил.

в больницах надо башлять сразу деньги, если со сраховкой то ты идёшь побоку, и цены там завышены раз в 5-10 будут

У клиник договор со страховой. Если в такой скажут, что лечить меня не будут, я им душу выну.

Автоматом пойдет жалоба;

1) В страховую, мол не хотят оплачивать страховой случай.

2) Попросту в суд.

Страховая не хочет потерять жирного клиента в лице оутсорсинговой компании, Больница не хочет потерять ручеёк бабла от страховой. Поэтому нерадивых администраторш в регистратуре настигнет анальная кара от руководства в виде лишения премии/увольнения с работы.

В Чернигове разница очень ощущается. Просто «небо и земля» ))

В Харькове у страховых нет «своих» больниц. Поэтому или отправляют в коммерческие клиники или в обычные гос-больницы. Зачастую в гос-больницах врачи лучше (больше опыта). Все лекарства и процедуры обычно оплачивает страховая, но есть нюанс: в гос-больнице персоналу желательно дополнительно выдавать материальные поощрения лично: от страховой им ничего не перепадет а зарплата просто печальная.

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

У меня есть пару интересных проектов и адекватный бюджет. Нет модного офиса и медстраховки. Также нужно уметь работать в динамичной среде и при этом писать нормально структурированный код.

заинтриговало, есть вопросы:
1- в каком городе? (удалёнщики требуются?)
2- какие я.п., технологии (итп) ?
3- полное название Компании и для кого продукт ?

4- вкратце о самом продукте.

1. Киев. Удаленная работа возможна, но по отдельным задачам.
2. NET 4.0/ ASP.NET/ MS Sql Server 2008 R2
3. MDM Technology, клиенты — западные и украинские компании, работающие на фармрынке
4. Мы разрабатываем несколько проектов, которые продаем по схеме SaaS. Направления — CRM, маркетинговые исследования, программы продвижения и продаж.

Стрекозёл и Муравел...

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

Сабж в принципе об эволюции и о ИТ-бизнесе, а он такой какой есть... Новые интересные проекты пойдут туда, куда течет вода (т.е. бабло) и интересность самих программеров до суперновых фрамеворкав это всё доссеракки...

О чем сабж? Вы не нужны вообще? Вы не нужны как услуга которая есть сегодня? Ну да — биллаэть нада меняцца!!! Ибо йеволюццийо! Ибо Стрекозёл и Муравел!

Вы в корне не правы. Проект — это не сделать и забыть. проект — это будущее клиента, и если оно будет светлым — работа у вас будет только прибавляться.

Такое впечатление, что некоторые проекты специально делаются так, чтобы в них не мог разобраться никто кроме первого разработчика.

Каждая функция реализована максимально сложно. Каждому параметру/свойству/значению — wrapper, на каждое действие делается куча вызовов, количество уровней абстракции — зашкаливает, и каждая фиговина имеет какой-то нетривиальный жизненный цикл. Никакого внимания к существующим open-source framework’ам (гордыня не позволяет), непременно надо городить собственный web framework, собственный framework для баз данных, для чего-то ещё, и ещё, и ещё... В отладчик заходишь — и смотришь, как оно пинает от вызова к вызову, от одного уровня абстракции к другому. Что-то приделывать к такой системе и что-то там менять — это нереально.

Какой-то больной на голову гик фанатично удовлетворял свои интеллектуальные фантазии. Он получил своё гиковское удовольствие между ног от всего этого, а людям потом головная боль, проект вполне может загнуться.

Вот откуда такое вредительство берётся?...

Конкретнее ...Чем недоволен?

Тем, как пишутся некоторые проекты, с которыми мне приходилось сталкиваться. Это палки в колёса и будущим коллегам, и фирме. Я думаю, что я достаточно конкретно написал.

Это обычное явление. Одни люди создают стандарты, другие подчиняются созданым стандартам. Да и зачем трогать чужие вещи в которых не разбираешься ? Главные правила инженера — 1) не трогай работающий механизм 2) Изучай конструкцию. 3) Разработай лучше

Я слышал мнение, что исполнитель на почасовой оплате заинтересован в том, чтобы проект длился дольше. Потому что он получит больше денег, по законам арифметики. Сделает быстро и качественно — получит меньше. Сделает медленно и как попало — получит больше.

А насчёт правил:
1) Хотелось бы не трогать, но дали задание внести изменения. Решение сверху.
2) Если дадут на это время.

3) Если дадут на это время.

И ещё по поводу 3. Есть уже это самое «лучше», ничего городить не надо, достаточно просто взять готовый и проверенный framework. Конечно, если работать не на какие-то необоснованные личные амбиции, а на успешный результат.

исполнитель на почасовой оплате заинтересован в том

Есть впечатление, что в этом заинтересован менеджмент аутсорсинговых контор. А нормальный человек, который хочет чего-то сделать в жизни, должен стремиться сделать как можно больше за свою конечную, между прочем, жизнь, а не тратить неделю на те задачи, которые при правильном подходе могут занимать 15 минут.

Есть впечатление, что в этом заинтересован менеджмент аутсорсинговых контор.

Да. Очевидно, получается так. Если бизнес конторы — это перепродажа человеко-часов, то именно такой интерес у менеджеров и будет.

А если цель — сделать быстро и качественно, то это другое дело.

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

Есть уже это самое «лучше», ничего городить не надо, достаточно просто взять готовый и проверенный framework.

Вот ты и решил свой вопрос

архитектор знает сколько стоит участок работы

ложная предпосылка

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

А к архитектору подойдёт ПМ или директор и скажет: «Слушай, тут заказчик платит за часы работы. То есть чем дольше мы будем работать над этим проектом, тем дольше у нас будет этот источник дохода. Раньше закончим — раньше придётся искать нового клиента. Так что, особо быстро и компактно это делать не нужно. Надо создать видимость огромного объёма работы. Понял? Вперёд.»

А он и рад поэкспериментировать.

Это как вариант. Другой вариант — человек просто больной на голову фанатик с обострённым чувством собственной важности. Вместо практичного и аккуратного решения он начинает городить какой-нибудь огромный framework с гибридными паттернами собственного изобретения и тащится от этого.

Вот ты и решил свой вопрос

Да ничего я не решил...

Просто помечтал, как бы сделать мир чище. :-)

Слушай, тут заказчик платит за часы работы.

В аутсорце все может быть ...

Другой вариант — человек просто больной на голову фанатик с обострённым чувством собственной важности. Вместо практичного и аккуратного решения он начинает городить какой-нибудь огромный framework с гибридными паттернами собственного изобретения и тащится от этого.

Это про Линуса Торвальдcа ? Или Ричарда Сталмана ?

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

А, это другое дело! Если речь идет про неизвестных программистов то это однозначно Сатоши Накамото & Co

начинает городить какой-нибудь огромный framework с гибридными паттернами собственного изобретения и тащится от этого

ну почему же сразу тащится? Я начинал писать проект 7 лет назад, на тот момент выбора особо небыло. После Х лет писанины никто не выделит Х месяцев на перенос всего этого чуда на какой-нибудь фреймворк.

Другое дело когда проект совсем новый, то тут да, надо менять подход.

7 лет назад уже существовали Struts, Hibernate. И не только они, наверное.

Мы сейчас разве о каком-то конкретно ЯП говорим?

Что такое «ЯП»?

Я о том, что если есть достаточно известный framework для web, ORM, JavaScript, то изобретать очередной аналог, работая на коммерческом проекте, — это и неоправданная растрата ресурсов, и создание проблем будущим коллегам, и увеличение рисков для этого проекта.

Я о том, что если есть достаточно известный framework для web, ORM, JavaScript

В том-то и дело — лет 7 назад фреймворки для Web, ORM и Java Script были куда как менее известны и раскручены.

Да. Разве что Struts был хорошо известен.

Мені дуже цікаво, ви мабудь ніколи не бачили поганого коду... Погано це не тоді, коли складний фреймворк, чи багато рівнів абстракції... Це добре. А ось коли є консольна програмка, яка складається с одного файлику, а втому файлику 1 клас, в класі одна функція, а функція на 6500 рядків коду, з операторами Гоу Ту. Ось це пекло... Особливо коли мене запитують «Чому не працює?»... Я так і хочу крові того дурня, що так написало додаток.

It’ just another option to write bad code. It may be one huge function with “go to” and other crap. It may be a huge sequence on tiny method calls. Whatever.

Изредка бывает и излишне «перемудреная» архитектура. Но похожие жалобы я часто слышал от молодых девелоперов. В духе «зачем здесь 20 классов что бы посчитать цену если это можно все написать в одном методе»? Причин недопонимания три:
1. Недостаток опыта работы на долгих проектах и понимания что за год простой метод в 100 строк может превратится в монстра. Если код изначально не сделан максимально гибко — он «загнивает» очень быстро.
2. Недостаток понимания ООП и (особенно!) S. O.L. I. D. принципов.
3. Недостаток опыта написания юнит-тестов с моками. Если код теста больше и сложнее чем код метода — это бесполезный тест.

Учитывая что клиент с вероятностью 80% не захочет заплатить даже за 1-2 дня рефакторинга, самый разумный подход — изначально делать максимально гибкую и изолированную архитектуру. Небольшие классы, очень простые методы, композиция вместо наследования и полная изоляция реализации от интерфейсов. Максимальное покрытие тестами с помощью мок-библиотеки. Все это потом собирается на рантайме через Denendency Injection Container. Для понимания кода — «говорящие» названия классов и методов («само-документирующийся» код) + диаграммы (лучше даже Model Driven Development).

Пишете на Java?

Усложнять логику и писать абстракции нужно тогда, когда метод без этого превратиться в монстра. Если начать писать абстракции раньше — то вы превратите его в монстра помимо его воли. :)
Многие работают по Эджайлу используют Скрам, Джиру и кучу другого софта с красивыми графиками и диаграммами, но забывают простой закон — простое лучше сложного. Потому что понятнее, быстрее в разработке и содержит меньше багов.

Абстракцию нужно писать когда система усложняется. Кэшировать и масштабировать базу — когда увеличивается нагрузка. Раньше — не лучше, чем позже.

Да, там Java.
Начинался этот проект более 10 лет назад (и я в нём не участвовал). Естественно, ни о каких «best practices» речи не шло. Так что в таких случаях, наверное, лучше просто взять наработанный функционал и разработать заново хорошую аккуратную систему, почти полный аналог старой системы.

Но вкладываться в это клиент не захочет, — нет прямой и очевидной выгоды, которую можно выразить в числах. Вот и (beep!) программистам мозги.

Усложнять логику и писать абстракции нужно тогда, когда метод без этого превратиться в монстра.

Я бы с вами согласился, если бы не

клиент с вероятностью 80% не захочет заплатить даже за 1-2 дня рефакторинга

А я еще и добавлю, как поработавший в свое время на том же проекте, что и Beaver Green, что заказчик там имел обыкновение контролировать, на что был потрачен буквально каждый час работы. Так что, именно в тех условиях, over-engineering с самого начала был меньшим злом.

Пишете на Java?

Нет, это был .NET, переписанный в свое время чуть ли не в «лоб» с COM+ / ASP.

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

Вот интересно, а заказчика при этом не смущало рожание с самого начала кучи лишних в 90% никогда не используемых сущностей?

Заказчик был нетехнический, и на код ему было наплевать — именно поэтому ни за какие рефакторинги платить он категорически не хотел. Хоть трижды говнокод, хоть неиспользуемые сущности — работает, критичных багов нет — и прекрасно.

НЕ наплевать на код было команде, т.к. потом все это счастье приходилось поддерживать долгие годы. Поэтому предпочитали «прятать шляпу» и делать overengineering (потому что прятать шляпу на refactoring в мелких change request’ах было бы впоследствии гораздо сложнее).

Насколько я Вас понял, проблема здесь стратегическая. Если заказчик не технический, то он не должен диктовать исполнителю, какие решения принимать. Как у Лебедева было:

Нормальная веб-студия.
— Здравствуйте, вы мне делали сайт. Можно здесь шрифт побольше, а там кружочек в красненький покрасить?

— Нет.

Решение, которое Вы описали, приемлемо в такой ситуации, но было бы лучше наладить связь с заказчиком и пояснить ему, что не делая рефакторинг, он теряет деньги. Согласен, не всегда получается. Всегда есть еще один, более радикальный вариант — поменять заказчика.

Всегда есть еще один, более радикальный вариант — поменять заказчика.

Всегда? Гм... ну я очень хочу увидеть хотя бы один кейс в аутсорсе, где исправно платящего уже не первый год заказчика поменяли бы только потому, что он хочет cheap & dirty решение.

Аутсорсовая компания заказчика из-за этого не поменяет никогда. Поменять заказчика можно проще — перейти в другую компанию / на другой проект. :)

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

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

Мне к ответу Beaver Green ниже и добавить нечего, кроме, разве что, того, что в описанном случае вот этого

Обьектная модель программы обычно некоторым образом моделирует предметную область

изначально не было. Скорее, была некая вариация на тему table module (или как там оно у Фаулера называлось?).

Понятно, количество демагогов в отрасли вижу зашкаливает.

чем сложность экстрактнуть интерфейс из класса когда это нужно

Из одного класса — не сложно. Сложно когда похожих классов больше одного и у них разные интерфейсы. Если 3 человека делали 3 страницы «простым» подходом то скорее всего получатся 3 иерархии моделей, которые потом приводить к общему интерфейсу непросто.

не понял глубины мысли отказа от наследования в пользу композиции. Можно конкретные примеры когда вознлки трудности?

Наследование — довольно сильная и не достаточно гибкая связь. Тем более что множественное наследование не поддерживается. Поэтому для повторного использования композиция (например шаблоны Стратегия или Состояние) удобнее.

Интерфейсы можно наследовать и соединять как угодно, реализуя принцип «interface segregation». А потом комбинировать реализацию в классах с помощью «dependency inversion». Т.е. наследуем интерфейсы, а реализацию комбинируем через агрегацию.

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

Речь не идет о «лишних сущностях» или искусственных абстракциях — их нет смысла создавать наперед (они появятся при реализации). Лично мне нравится Domain Driven Desing и Onion Model, когда приложение строится начиная с основных абстракций предметной области и потом уже «обрастает» лаерами доступа к данным, юзер интерфейсом и т.д.
Именно поэтому я рекомендую начинать с интерфейсов доменной модели. Потому что если плясать от юзер-стори, которые описывают интрерфейс с пользователем, то и архитектура будет строится «от интерфейса» а не от доменной области. Другая крайность — начинают с базы и архитектура идет от реляционной модели.

В «чисто агильном» подходе, когда все делается просто и изначально архитектура «на перед» не строится, я не вижу как можно применить DDD.

Если 3 человека делали 3 страницы «простым» подходом то скорее всего получатся 3 иерархии моделей, которые потом приводить к общему интерфейсу непросто.

Это проблема отсутствия комуникаций в проекте а не проблемы DRY KISS

Наследование — довольно сильная и не достаточно гибкая связь.

Ну давай поиграем в лозунги, та нет — вполне гибкая.

Тем более что множественное наследование не поддерживается.

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

Поэтому для повторного использования композиция (например шаблоны Стратегия или Состояние) удобнее.

Как же она удобнее если прохидится писать кучу совершенно не обязательного спагетти кода?

Интерфейсы можно наследовать и соединять как угодно, реализуя принцип «interface segregation». А потом комбинировать реализацию в классах с помощью «dependency inversion». Т.е. наследуем интерфейсы, а реализацию комбинируем через агрегацию.

Не «т.е.» а это все отлично уживается с наследованием.

Речь не идет о «лишних сущностях» или искусственных абстракциях — их нет смысла создавать наперед (они появятся при реализации).

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

Именно поэтому я рекомендую начинать с интерфейсов доменной модели.

А интерфейсы тут причем? Почему нельзя сразу писать обьекты? Спор то об этом?

В «чисто агильном» подходе, когда все делается просто и изначально архитектура «на перед» не строится, я не вижу как можно применить DDD.

Ну так может это твоя проблема что ты не видишь, а не agile подхода?

Абстракцию нужно писать когда система усложняется. Кэшировать и масштабировать базу — когда увеличивается нагрузка. Раньше — не лучше, чем позже.

С одной стороны, агильный подход, который требует усложнять архитектуру постепенно, мне нравится. И для своего пет-проекта я именно так и делаю.
Но вот на реальных проектах где в команде около 10 девелоперов разного уровня он, по моему опыту, работает кривовато. На первых итерациях система простая и простые решения обеспечивают хорошую скорость разработки. Клиент доволен. Потом система усложняется — настает пора рефачить и вводить абстракции. А это значит — ломать и приводить к общей архитектуре простые решения, которые каждый девелопер себе придумал. Это замедляет разработку новых фичеров и клиент становится недоволен. В итоге менеджмент начинает давить что бы продолжали применять простые решения а не менять уже «проданный» клиенту код. В итоге все медленно скатывается к дублированию кода, костылям и прочим «дурным запахам» загнивания.

Отдельная история про кэширование в частности и перфоманс со скалабилити в общем. Если изначально на это никто не закладывался, то проблемы обнаруживаются уже на середине проекта, когда оказывается что простые решения хорошо работают только для 2-3 одновременных QA-юзеров, а под реальной нагрузкой все «ложится». Но теперь для добавления кэширования или поддержки более одного сервера уже надо потратить одну-две итерации только на рефакторинг и введение нужных абстракций.

Вот интересно, а заказчика при этом не смущало рожание с самого начала кучи лишних в 90% никогда не используемых сущностей?

Подход разрабатывать архитектуру «наперед» мне кажется более удобным. В принципе можно рассматривать еще нереализованные интерфейсы как некий «бэклог» задач на следующие итерации. Зато очень просто потом делить работу на итерацию: каждый реализует и тестирует свои кусочки и потом это с минимумом проблем стыкуется вместе. Это некоторый компромисс между «водопадом», когда вся архитектура планируется сразу и на весь проект, и чистым аджайлом, когда «наперед» ничего не закладывается.

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

Та нет не значит, или примеры в студию. А уж сложные решения ломать окажется в 10 раз сложнее будет.

что простые решения хорошо работают только для 2-3 одновременных QA-юзеров, а под реальной нагрузкой все «ложится».

А у меня почему то простые решения не ложатся.

В духе «зачем здесь 20 классов что бы посчитать цену если это можно все написать в одном методе»?
Если код теста больше и сложнее чем код метода — это бесполезный тест.
композиция вместо наследования
полная изоляция реализации от интерфейсов
Простые и дельные советы о том как превратить ваш helloworld-ик в кучу over-engineered гавнокода. Меня автор еще раньше повеселил когда утверждал что без interface-ов не бывает юнит тестов с моками, и dependency injection, теперь с интересом слежу за его опусами.

Если код теста больше и сложнее чем код метода — это бесполезный тест.

Если код теста меньше метода, метод его может обмануть, тест выдаст норму на ошибочном методе.

Если код теста меньше метода, метод его может обмануть, тест выдаст норму на ошибочном методе.

Код одного теста должен быть максимально простым. Потому что он тестирует только одну простую ситуацию (один набор параметров, одну ветку в коде). Что бы покрыть весь метод (и он не «обманул» тесты) тестов должно быть много (но простых!) и разных (на граничные значения, «на отказ» и т.д.).

Смысл юнит-тестов в том, что они простые и их правильность человек может проверить «вручную». В то время как метод сложный и его проверить «вручную» на всех вариантах человеческого внимания не хватает — поэтому и нужны тесты.

Да никто же с этим и не спорит. Я хотел подчеркнуть, что SQL-инфекции и прочая прелесть, как вы их будете проверять кучей тестов?

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

Зачем распознавание образов? Есть масса полезных тулов для анализа кода (CodeItRight, FxCop, StyleCop, Resharper). Находить SQL-инфекции, «потерянные» ресурсы, секьюрити-дырки и прочую кривизну в коде это их задача.

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

О, я вижу ту еще и специалист в security. Спорим все дырки эти продукты не выловят?

юнит тесты не проверяют SQL запросы. Это интеграционные тесты

Есть несколько способов сделать юнит-тесты для SQL запросов. Именно для того что бы они запускались автоматически после билда.
Вот навскидку:

msdn.microsoft.com/...e/cc164243.aspx

Статья не об интересных проектах, а о тенденциях рынка аутсорса программистов.

А в аутсорсе чаще скучные проекты, по причинам уже описанным ниже.

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

У меня есть интереснейшая концепция-проект. Деньгоф нема ;) . Технологии — C++/Qt/Qml, UI и большое др. Но, блин, интереееееснооооо... :) Пишите в личку. Посмотрим — шашечки или ехать?

Поспорю, с 2002 я без труда находил интересные вакансии, либо связанные с разработкой продуктов, либо, хотя бы, все писалось с чистого листа.

1) Я специализируюсь на web проектах среднего размера (от 10000 тысяч посетителей в день)
2) C++ в некоторых приложениях незаменим, но для моих задач он проигрывает по выразительности кода .net
3) Уйдя из плоскости поиска работы я нашел интересный проект да еще и с деньгами; идей без денег у самого полно

4) Так что есть встречное предложение — учите .net, mvc и подключайтесь к нам )

Моя концепция покрывает и поглощает веб — что может быть интереснее? :)

Перглянув статтю і камєнти. Складається враження, що більшість людей також не читає текст, а тільки заголовок, і пише свою думку про нього :)

В той же час автор застосовує цікавий літературний прийом, розпочинаючи з антитези. Панове, будьмо уважнішими один до одного.

А зі статтею я згідний на 100500%, навіть не маю що додати. Пробуємо в такому напрямку і рухатися, щось навіть починає виходити.

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

А саме з чим? Цікава Ваша думка.

1) Интересные проекты есть. Знаю несколько проектов именно на MVC, что опровергает первую же посылку Сергея. Проекты новенькие с иголочки. Странно, что ему они не попались на глаза. Не знаю, может они не очень «светятся», причем именно ему.
Так же очень большая потребность в WPFщиках, джавистах и ораклистах, рубистах, питонщиках и т.д. Причем тоже на новые фреймворки и версии продуктов, во всяком случае так говорят коллеги, которые в тех областях знаний работают
2) Мне всегда очень подробно рассказывали о проекте. Не рекрутеры, так на техническом собеседовании или после него. Может автор не доходил даже до технического собеседования?

3) Стенания по поводу неизвестности зарплатного уровня мне тоже не очень понятны. Ужели автор не в состоянии определить свою рыночную цену? Для этого есть множество источников информации. Тот же DOU показывает среднюю планку унылого кодера, который «сидит на попе прямо». Считаете себя спецом, ну умножьте ее на 2 или, там, на 3. Я уж не о говорю о случайных утечках информации там и сям. Сергей также сетует, что никто не ценит сверхпродуктивных людей, так это везде так. Людям платят за то, что галера двигается вперед, а не за то, что они машут веслом ретивей других.

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

В-третьих — своего рода продолжение во-вторых — наличие средств — даже под свой же интересный проект — если деньги не заходят — никакие интересные проекты не стартуют.

Внезапно поток интересных вакансий на новых технологиях исчерпал себя (сужу по Microsoft technology stack). Внезапно всем нужны так называемые «миддлы». Внезапно большинство проектов — это поддержка существующих решений, начатых в лучшем случае 4-5, а иногда и все 10 лет назад.

Обе первые посылки неверны. Собственно все выводы, из них сделанные так же ошибочны

Може це один з проявів переходу 23 сенйорів у зрілий вік.

А в чём выражается интересность проекта? Интересен он для кого? Я понимаю, что «портальчики», соц.сети, блоги, визитки и инет-магазины — это не интересно и однообразно, но ведь всё остальное вроде как имеет свою изюминку.

Основные критерии:
— выразительность кода

— шанс на успех

По-моему код никак не влияет на интересность ковыряния в нём :) Ну, а шанс есть у всех, просто не все его видят.

Что вы имеете в виду под «шансом на успех»?

Критерии у каждого свои. Я думаю, главным является такая «абстрактная» материя как возможность проявлять творчество. Поясню: это возможность самому найти (придумать) решение задачи и красиво его воплотить. Т.е. сделать так, что бы самому понравилось и можно было гордиться результатом.

Почему многие проекты «неинтересные»? Просто потому, что на них уже есть тонны чужого «спагетти-кода» и начальник, который требует тулить заплаты и сходу отметает любые предложения сделать «хорошо», как хочет девелопер (потому, что это дольше). Т.е. главная причина — загнивание проектов под грузом «технического долга» а не неинтересная предметная область («портальчики», «магазинчики»). Новые проекты «с нуля» почти всегда интересны (как минимум первый год), если конечно изначально не взят курс на клепание «халтуры» по-быстрому.

если конечно изначально не взят курс на клепание «халтуры» по-быстрому.

Что, зачастую, и происходит с greenfield проектами, т.к. по-другому не захватишь рыночную нишу быстрее конкурентов.

ну вот и приехали к тому что во всем виноват тупой менеджмент.

Если у начальника в команде девелоперу скучно, он демотивирован и вместо работы сидит на ДОУ то это однозначно недоработка руководителя.

angel.co/talent — очень много очень интересных проектов.

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

имхо КГАМ, без обид и ничего личного=)
1. В Киеве 10+ тыс программистов, это более чем 2 500 текущих проектов, все компании хотят расти это еще сотни других потенциальных проектов.
2. Разве выбрать не из чего?

3. Автор ты сам хоть знаешь чего хочешь?? — если знаешь так напиши что ты хочешь и рекрутеров на линкедыне с опытом найди и скажи найдите мне вот такой вот проект, деньги вот такие..

1. Миллионы мух не могут ошибаться. Мы в курсе.
2. Не из чего. Нет ничего сложнее «ПХП на Зенде» ©.

3. Я знаю. Хочу написать безсерверную (что-то вроде локального облака) учетку с процессным управлением. У тебя есть на примете такой проект? ;)

То что посложнее педалится в серьезных компаниях типа яндекса и гугла, если доросли — то попробуйте к ним устроиться, в чем проблема.
У нас была тема и вроде до сих пор есть — отправляли С++ девелоперов в сониэрик, так из 20 гуру (кстати киевских) прошло собес только 2е! — вот вам и посложнее.

Многие ж чего хотят: посложнее задачи, но не факт что потянет сложнее=> будет учиться на проекте=> нужен не просто мешок денег на такой проект а мешок + мешок в резерве.

3. могу отрекомендовать компанию грид динамикс, правда в Харькове, они с клаудами сложняцкие вещи делают (обратись к Косте Малышеву он там главный, Костя будете должны за пиар=)))

Гугл, яндекс и сониэрикссон уже в Украине? Что, собственно и является темой статьи — интересных проектов в Украине нет. :(

ЗЫ. Мне неинтересны облака в их сегодняшней реализации.

К сожалению страна у нас дикая и потому такие компании как гугл к нам пока не желают заходить и открывать девелопмент центры.

ну что ж тогда частично согласен. Супер-пупер проектов в Украине не разгонишься.

С другой стороны все же то что есть сейчас, лучше чем было 3-5 лет назад.

К сожалению страна у нас дикая и потому

Дело не в дикости, а в целесообразности. Не думаю что гугл сможет тут найти хоть пару сотен инженеров для себя. Да и зачем, если есть Краков (кажись там ближайший дев центр)?

Думаю если гугл откроет офис в Киеве, туда потекут самые неинтересные проекты.

У гугла нет простых программистов. Все крутые. Например:

«Станок для изготовления совков»

Соковыжималка Angel

www.angel-juicer.com.ua

Вот так они работают

У тебя еще и память плохая, веников а не совков.

Клирики могут не чирикать, а проверить качество поиска отсталых американских программистов. Для желаемого вами
«Станок для изготовления веников»

имеем на 8-ом месте выдачи:

Оборудование для производства мешка бумажного — YouTube

www.youtube.com/...h?v=rzaNziet85w

И так на каждом шагу. Шо то у них кризис программистов. Наверно, наши знатоки английского подтянулись.

Помню был когда то такой поисковик — альта виста — он наверное делал именно то что тебе бы хотелось. Почитай про page rank уже например?

Ты ещё скажи, почитать инструкцию, как пользоваться стулом или вордом: «Через полчаса любая секретарша работает в Ворде».

Я так понял, для поисковика надо шестимесячные курсы.

Ничего такого говорить и утверждать не буду, это твои фантазии не в тему.

Вы там с клириками определитесь, фантази, склероз, дикая выдача Гугла или всё сразу.

Да все предельно ясно: про веники ты запамятовал, а про курсы, стул и ворд нафантазировал.

Это ты забыл про совковую соковыжималку с ангельскими крылышками.

Не знал, не знал и забыл? Извини, это не мой стиль.

Ну, в общем я вижу тут за меня все ответили.

За несколько месяцев наблюдений я ни одной толковой вакансии не видел.

так ты ищи а не наблюдай — под лежачий камень только «ПХП на Зенде» и затекает=))

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

С точки зрения разработчика различного железа и системного софта — андроид тот ещё pain in the ass. Про применение в машинах в промышленных масштабах я не слышал, видел разные поделки энтузиастов...

зачем он в машинах? андроид это не OS, а юай-ориентированая надстройка над линуксом, в машинах его разве что для взаимодействия с человеком можно применить(предварительно вынеся все управление железом на отдельную платку со своим процом)

Спасибо, кэп! Мы сейчас говорим от телематике в машинах.

go/scala/kotlin

Этой ереси нам не надо. Есть православная Java — и хорошо.

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

Этой ереси нам не надо.
Эта «ересь» придумана для того, чтобы делать действительно нечто стоящее, а не очередную веб морду для никому не нужного портальчика.

А что конкретно такого на го, котлин и скала можно сделать чего нельзя было бы сделать на джава?

Можно не выстрелить себе в ногу, если коротко

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

Конкретно на счет Scala я не знаю, но в общем функциональные языки очень гибкие. На них можно реализовать быстро то, что используя OOP подход заняло — бы в несколько раз больше времени.

На пример, внутренний DSL, отложенные вычисления, элегантный механизм замыканий и т.п. — почитай о функциональном программировании

DSL-и помоему все еще чаще пишут на antlr, отложенные вычисления можно и в джаве делать без проблем, замыкания тоже есть — анонимными классами называются.

DSL-и помоему все еще чаще пишут на antlr

Это внешние DSL, внутренние — нет.

замыкания тоже есть — анонимными классами называются.

Это не совсем то.

Сделать на Java можно всё, что угодно, но для ряда задач указанные языки удобнее

Это внешние DSL, внутренние — нет.

ВТФ внутренние ДСЛ?

Сделать на Java можно всё, что угодно, но для ряда задач указанные языки удобнее

Та вот я все пытаюсь разобраться, для каких?

ВТФ внутренние ДСЛ?

DSL, которое является подмножеством базового языка

Та вот я все пытаюсь разобраться, для каких?

Почитай о функциональных языках. Комменты к статье не место для лекции

а ты сам то имеешь опыт в функциональном программировании? Или так, теоретизируешь прочитав ступление к какой то книжке?

Я имею опыт в декларативном программировании, функциональное только по книжке. Ты почитай заголовок топика: нету на Украине интересных проектов

Ну ты ж первый тут начал прославлять функц. прогр. Кстати по поводу внутренних дсл — подключаем груви плагин в мавене и получаем отличный дсл.

Дело не в ООП, ФП или еще каком-то П. Дело в том что новое — это круто (точнее говоря долно быть круто, по другому быть не может), а старое уже надоело.

Нет нет, дело не в надоело. Дело в том, что скорость реализации новых фич в проекте, начатом в 2011 в три раза выше проекта с 2009, и в 10 — проекта с 2007.

И то что почасовая ставка одинаковая не особо греет.

Нет нет, дело не в надоело.

Я отвечал на комментарий:

но в общем функциональные языки очень гибкие. На них можно реализовать быстро то, что используя OOP подход заняло — бы в несколько раз больше времени.

что скорость реализации новых фич в проекте...

И чем это обусловлено?

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

Выразительность кода у разных языков программирования разная.

Выразительность на 90% зависит от разработчика и на 10% от языка. А учитывая что «ко всему привыкаешь», то на 99% от разработчика и на 1% от языка :)

В прошлом, чистка памяти.

Упростила ... частично, но и привнесла свои особенности.

Но и сейчас бывают ненужные усложнения

И снова разработчик.

Вопрос: где зависимость от времени?

Не вижу смысла варить воду.
Типово (возможно, в worldapp по другому, но вы на Java и я к вам не ходил) менеджмент не выделяет времени команде для переработки кода в старых проектах.
Причем, воля одиночного разработчика тут не работает, ведь надо чтобы была обновлена документация, другие компоненты системы, проведено тестирование.
Инициировать такие изменения снизу крайне сложно:
«А почему вы сразу как надо не сделали»
«Ну вот давайте сделаем срочно вот этот набор фич (потом следующий и т.п.)»
«Ну почему выделять время на рефакторинг, кто сказал что через пол года вы опять не захотите»
А когда что-то таки не выдерживает и ломается нужно исправить как можно быстрее. и потом в будущем — т.е. после закрытия проекта — мы выделим время на рефакторинг.

У меня в команде рефакторинг включен в процесс разработки ПОСЛЕ приемки фичи клиентом. Кстати возможно об этом тоже стоит написать статью

«Быстро реализовать» и «Не выстрелить себе в ногу» — две совершенно разные, вещи.

Как правило язык позволяющий чтото «быстро реализовать» очень хорошо позволяет отстрелить себе ногу. Джава какраз стабильна как монолит. Если не полные **** код на ней пишут, то вполне можно разобраться и поддерживать. Попробуйте разобраться в левом скала коде, писанном студентом.

Код — это самое последнее по важности. Архитектура софта на порядок важнее, участок кода всегда поправить можно при грамотной организации. Или (?) :)

Важное важное :-)

Я не работал в проэктах с выделенным архитектором, который только то и делает что следит за архитектурой. В тех что я работал — всегда найдеться «умник» который своим куском кода завиолейтит вашу архитектуру и в доль и в поперек. На скале это зделать еще проще :-)

А пример можно? Что в джаве есть такого, что приводит к «отстрелу ног», и при этом этого нет в скале/котлине?

P.S. Интересно что про груви никто не вспоминает. :)

Груви отличный язык, чтобы прямиком отсрелить очепяткой себе мозг, прямо во время работы на продакшене :-)

Впрочем как и любой другой динамический язык.

Для подобного —

никому не нужного портальчика

— есть бесплатные CMS, и программирование там вообще не нужно.

А для этого —

чтобы делать действительно нечто стоящее

— существуют Java, C#, C++. Редко что-то иное, но всё равно что-то из mainstream.

На самом деле дефицита проектов нету, так как каждый нормальный программист в принципе держит в голове пару тройку хороших идей.
Проблема есть с инвестициями в СНГ и умением получить их, именно по этой причине многие делают штабквартиры в США(из одного человека). Так как так легче привести деньги в стартап.
Вы можете сказать что для инет стартапа деньги неважны. Но я могу вас уверить что это не так, деньги нужны всегда. Да их кол-во уменьшилось по сравнению с 95годом, но тем не менее это не 200 баксов. Как минимум вашей команде нужно за что то жить, и желательно нормально жить, так как человек не может делать что то на ВАУ когда у него куча личных проблем(Пробывал на себе.. пару месяцев терпишь а потом все 100% демотивация).

Но не смотря на это, стартапов у нас отбавляй, но большинство из них предлагают 500баксов + %от будущей прибыли. И тут уже каждый решает идти ему на риск или нет.

У нас в стране нет проблем с идеями, просто есть много других проблем которые не позволяют или делают проблематичным их реализацию.

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

Итого или нет нормальных программистов или многовато идей, которые чуть выше пойти пива попить.

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

Множество стартапов с миллионными прибылями имеют глупые идеи(по сути не нужные). В тоже время уйма крутых идей прогорают на первой стадии.

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

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

ru.wikipedia.org/wiki/Идея — Идея — прообраз реальности. А реальность подразумевает множество процессов для существования бизнесса. Так что с определением все ок.

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

Не знаю, не знаю, в Принстонском универе хватило трёх студентов:

www.youtube.com/...player_embedded

Ну вообще-то Боинг и жужжалка за 30баков вещи разные.. я бы даже сказал кардинально разные.

Ну да, программист программу не заметил, которая управляет полётом и совместным полётом, в общем, чётам, неинтересная задача.

Эльфы в лесу, домики — деревянные, набегают солдаты дворца и злодеи, можно грабить кОрОваны.

Почему-то картинка навеяла))))

«джва года» осталось подождать)

А чего вы ржете? Если он кроме доли готов предложить зарплату — то как говориться «чим би дитя не тiшилось.....». А вот если только долю — то дааааа..... — парень жжет напалмом просто.

Мне кажется, компаниям нужно вырабатывать специализацию и натаскивать сотрудников в определённой сфере.

У меня прямо противоположное мнение. Пять лет наза беседовал с собственником одной аутсорсингововй компании по поводу зарплаты:

Я: Давайте начнем с $15.
С: Да ну, я с заказчика беру $15, тебе я максимум могу дать $10. Потом, пока $7.

Я: Ну а тогда зачем мне ты, на $15 я и сам себе найду заказчиков.

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

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

Все намного хуже. Наши заказчики просто не могут найти исполнителей. Вообще и в принципе. Не знаю, с чем связано. Я регулярно объясняю, что $50/час специально завышенный рейт, чтобы жаба задушила и меня не вызывали для настройки роутера.

Я: Ну а тогда зачем мне ты, на $15 я и сам себе найду заказчиков.

«В таком случае, у меня есть не меньше оснований полагать что и я один прекрасно справлюсь с вашим делом!» © О. Бендер

:)

:) У меня иллюзий давно нет. Я не справлюсь с его делом — я не умею рисовать иконки, я не умею писать документацию/хелпы, я не умею (точнее мне лень) проводить полное тестирование. То есть, я не могу создать полностью готовый от ушей и до хвоста продукт. Мой удел — мелкие проекты для нетребовательных заказчиков.

Роман, если вы все еще работаете за $15, свяжитесь, пожалуйста, со мной info гав socialtalents.com

Если нет — не бойтесь привлекать других людей, которые умеют рисовать иконки и делать много других классных вещей, которые не делаете вы.

я с заказчика беру $15, тебе я максимум могу дать $10. Потом, пока $7.

Это ещё ничего. Я читал в какой-то заметке, что украинские девелоперы, предоставляемые сутенёром-бодишопом, обходятся заказчику в 35$ в час. То есть программист получает треть и меньше.

Это в каких же компаниях за еду работают? Надо туда наш рекрутмент натравить :)

Это в каких же компаниях за еду работают?

В украинских. :-)

В статье был указан диапазон. То ли 25-35$ в час, то ли 30-35$.

В месяце около 176 рабочих часов. Помножьте и соотнесите со своей зарплатой.

Я понимаю, перепродажа — это бизнес, но чтобы в большинстве случаев и половины (а то и трети) этой суммы исполнителю не отдавать — это уже наглость.

Мои зарплата и схема работы нерепрезентативны.

А для девелоперов — даже если считать 176 часов, то все равно получается около 20 баксов для среднего киевского синьора (3-4к на руки чистыми). А вообще заказчику продается не более 150-160 часов в среднем (т.к. нужно вычесть праздники, отпуска и больничные), так что часовой рейт даже и поболее выходит. Мне поэтому и странно слышать жалостные истории про 10-15 баксов в час для бедных девелоперов.

А кроме того — из оставшейся маржи вычтите еще расходы на командировки (как самих девелоперов, так и менеджмента), зарплаты непроизводственного персонала, аренду офиса, налоги (пусть 5%, но все же), затраты на обучение (тренинги, сертификации), участие в конференциях (в т.ч., спонсорство), страховки, печеньки и т.п.

Если вы считаете, что могли бы иметь $35+/час (при загрузке 176 часов в месяц) на фрилансе — флаг в руки, дерзайте. Когда заработаете 18к за квартал чистыми (35*176*3), не забудьте поделиться тут историей успеха.

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

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

Вот к примеру, есть у меня знакомый флешер(фамилию не раскрываю, но лицо реальное 100%). Работает на одеске, получает в среднем 30 баксов в час.

Вопрос: какого рожна ему — одиночке доверяют заказы сравнимые по сложности с заказами для мегамонстра?

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

Вот возьмем, к примеру, Циклум. Они тупо занимаются оутстаффингом: вот вам разработчик, вот ему четыре квадратных места площади, компьютер и интернет.

Давайте штуку баксов сверху его з.п. и управляйте им как хотите. Конечно, при таких раскладах, заказчик не мотивирован платить больше, чем фрилансеру, ведь командой ещё надо как то управлять, строить её и т.п. Для этого необходим украинский менеджер, эйчар процесс налаженный и т.п.

Грубо говоря, Циклум организовывает процесс перемещения денег из кармана заказчика в мой, ведет дела с налоговой и за это получает штуку баксов в месяц с носа одного программиста.

Не то, чтобы я имел какие то вопросы к бизнес — модели циклума, они честно делают своё дело. Но чтобы рейты повышались, им надо напрячься и предлагать немного больше, чем тушка девелопера. Например, брать на себя ответственность за управление проектами. Предоставлять fixed price, вместо time and material тогда бабла будет больше.

Насчет Сиклума не знаю, возможно, все так и есть. В Люксофте многое точно сильно отличается (и рейты, и масштаб проектов, и затраты компании). Понятное дело, что занимаясь чистым аутстаффингом, компания к консалтинговой модели никогда не перейдет. Хотя бы потому, что не знает, какая именно экспертиза есть у ее сотрудников.

То есть, ты согласен, что для повышения рейтов нужно не лить слезы о повышении зарплат и жадности разработчиков, а переходить от продажи жопочасов к консалтингу?

Конечно, согласен. Я об этом пишу в каждом первом комменте к постам про аутсорсинг, в т.ч., и тут: dou.ua/...=comment#195133

Это ж надо менеджменту много думать, много работать и много рисковать, так и жизнь закончится, а отдыхать на лучших курортах мира когда? В славян другой менталитет: ничего не делать, ничем не рисковать, а деньги получать. Легче набрать еще 100000 студентов, индусов, пакистанцев да кого угодно и перепродать хоть по сотне баксов сверху но главное со своей стороны ничего не делать кроме выделения рабочего места. ;-)

Легче набрать еще 100000 студентов, индусов, пакистанцев

Уже не легче

Тренинг центры зачем думаешь открывают? Потому что этот путь легче, чем компании повышать свою ценность на рынке.

Ну это всё лучше, чем не делать ничего

Чем лучше? Этот путь в штатах уже проходили в 2000-х все закончилось крахом и кучей безработных.

Понимаешь, в США все закончилось оутсорсингом. Что из Украины начнут оутсорсить мне как то не верится. Кроме того, безработный в США живет много лучше, например, украинского учителя.

Когда заработаете 18к за квартал чистыми (35*176*3), не забудьте поделиться тут историей успеха.

Половина ДОУ сразу пойдёт стучать в налоговую :)))

зачем стучать? они просто не поверят!

Это первый текст про «проблемы оутсорса» который сказал чтото действительно стоящее(!).

Из текста не совсем понятны критерии интересных проектов: судя по конкретным примерам (MVC vs WinForms), вы говорите только об «интересности» использующихся технологий. Я правильно понял?

Ну а, в целом, кто ищет, тот всегда найдет :)

Критерий у каждого может отличаться, поэтому я не концентрировался.

Я думал, что опыт cloud computing и масштабировании (ну, скажем, от миллиона страниц в день) будет кому-то нужен — ан нет. Просто на MVC такие задачи решать удобнее.

С автором согласен на 75%.
50% за — очень большое количество проектов поддержки с хорошим бюджетом.
15% за — много технологически интересных проектов являются стартапами с малым бюджетом.
10% за — можно неплохо зарабатывать если уметь выберать сдельные краткосрочные проекты (freelance, малоизвестные молодые продуктовые компании).

25% против — есть значительное число компаний (в основном Dedicated R&D Centre) с хорошим бюджетом и постоянным потоком новых проектов.

Вот только эти 25% далеко не mainstream. В каждом таком проекте месяцами не могут закрыть дорогостоящую вакансию по причине специфичных знаний, которых у 95% кандидатов попросту еще нет.

Например, совсем недавно это была разработка под iOS/Android. Сейчас дефицит кадров есть, но самые интересные проекты уже на поддержке либо переехали под крыло Apple/Google.

Напрашивается очевидный вывод. Хотите интересных проектов? — расширяте кругозор настолько, что сможете углядеть куда движется очередной виток технологий (не только IT) в ближайшие пару лет. И делайте это регулярно :)

есть значительное число компаний (в основном Dedicated R&D Centre) с хорошим бюджетом и постоянным потоком новых проектов.

Можете ткнуть меня носом, где это у нас еть эти самые дидикейтед центры продуктовых компаний. Знаю только Самсунг.

В Киеве — может, только Самсунг. Но в Других городах Украины с этим полный порядок. Много компаний, у которых есть своя «платформа» — от простого набора компонентов и CMS до чего-то существенного. Так вот, часто проекты в таких компаниях — подвести платформу под нового клиента. Но под этим соусом ребята постоянно в самой платформе что-то меняют и пересаживаются с одних технологий на другие.

А все-таки, озвучьте. Интересно же!

Я работала 7 лет в Dedicated R&D, у которой продукт. Есть отдел разработки, отдел имплеменации под конкретных клиентов. Компания называется TOA Technologies (USA), ee филиалы в Украине (Харьков) — Inbitec и TOA-Ukraine.

А вот интересно — если бы какой-нибудь среднего размера бодишоп объявил своей главной фичей для потенциальных работников: «не занимаемся суппортом десятилетнего ховнокода, только разработка, только хардкор», дало бы это ему видимое преимущество на рынке труда и смог бы он вообще выжить с таким подходом.

Не смог — бы,работодателю пофик на интерес — бабло рулит

Не обязательно ведь менять сразу всю компанию, но создать отдел «%CompanyName% Startups» куда бы все хотели попасть и слали резюме пачками — вполне можно было бы.

Ну а тем, кто не прошел кастинг в элиту, можно предложить и вакансии в материнскую компанию.

СофтСерв разве не этим занимается? У них же девиз — взять проект на полгода, отдать и больше не брать его назад никогда. С глаз долой — из сердца вон. Зато там работать поинтереснее.

А разве не это главное дао хардкода (ping bsod)?!

дало бы это ему видимое преимущество на рынке труда

Sure.

и смог бы он вообще выжить с таким подходом

Вполне.

Контора была бы избавлена от необходимости каждый раз объяснять клиенту, почему снова сорвали сроки или почему специалисты не смогли разгрести тонны г@вн@кода в проекте.

Да — это помогло бы привлечь больше толковых синьоров, которые ценят интересную работу больше, чем +20% к зарплате.

Только вот заказчиков с таким подходом было бы очень сложно искать. Если сходу говорить: мы делаем в 2 раза дольше и дороже других, зато и в 2 раза качественнее. И мы делаем только «с нуля», сапорт чужого кода не предлагать. Да еще и оплату вперед (бодишоп хочет подписывать контракт на команду на год минимум) и независимо от конечного результата (мы же агильные).

А як спілкування з українськими замовниками? Не було заморочок, паяльник ще не пропонували?)

Таких легко отличить сразу на этапе переговоров

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

Откуда такое мнение? Украинский заказчик, конечно, хуже американского, но намного лучше европейцев и израиля.

Украинский заказчик очень не любит платить за работу

Любит, не любит.... детский сад какой-то. Главное что готов платить и платит, а его чувства мне как-то пофиг. :)

Проблема украинского заказчика в том, что он не понимает, за что он должен платить такие большие деньги. Это решается еще до заказа простым объяснением.

Что делать глобально?

Во-первых, перестать крутить шарманку. Человек не робот чтобы отсиживать 8 часов в день по регламенту. Результат проекта не зависит от количества потраченых на него часов, а зависит от эффективности принятых решений в ходе реализации проекта. К сожалению есть достаточно много фирм, руководство которых «не доросло» до осознания такой банальной истины.

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

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

продвигать в управленческие структуры людей _технически_ более грамотных,

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

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

Если разработчики перекрывают все, и они реально все зубры, то менеджер нах не нужен, это правда. А вот если человек коачит команду по алгоритмам и заботится о том, чтобы из этого что-то выросло, соответствовало целям организации, и происходило в реальные сроки, он не менеджер? Должен ли он при этом алгоритмы знать? Это не диаметрально противоположные специализации, это скиллы в разных измерениях.

Да, он не менеджер (точнее не руководитель проекта). Он тех-лид, тренер, евангелист... Хотя словом менеджер можно назвать что и кого угодно :)

Мой комментарий подразумевает, что вы имелли в виду Project Manager.

Я имел в виду «работу с людьми» vs «работу с алгоритмами».

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

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

См. выше про работу с людьми vs работу с алгоритмами.

так что если вы реально компетентны, вы можете получить любую разумную цену.

Ну місцева публіка лиє крокодиляці сльози, що аутсорс їм як кістка в горлі із захмарними рейтами.

1) Не нужно навязывать формат аутсорса, нужно предложить чудо (а значит, его надо уметь сделать и показать).

2) Я привлекаю людей не из Киева чтобы немного снизить среднюю стоимость часа.

Может быть, мне повезло, но факт существования mail.ua с который обошелся в более миллиона долларов демонстрирует что на самом деле в уанет деньги вкладываются.

Бизнес климат таков, что любой реальный бизнес могут захватить — что интерес инвесторов в интернет проекты будет расти.

Я от не пойму, у Вас психологія інвестора, чи найманого працівника?

Коментар порушує правила спільноти і видалений модераторами.

Ну не знаю. І компанії бувають із «нормальним» підходом до роботи, і проекти в таких компаніях бувають цікаві та інноваційні. Інша річ, що продавати такі послуги важче, ніж «голови». І зарплати високі в таких компаніях ще рідше пропонують...

Хороший анализ. Я бы еще добавил что существует информационный перекос — на слуху крупные компании. Потому что во-первых там много людей, во-вторых им нужен publicity. Маленькие проекты, которые делают что-то очень интересное — они есть, но о них мало кто знает. И им это не нужно особо, и людей которые что-то могут рассказать мало.

Вони не лише «на слуху», в цих компаніях «чомусь» працює значна частка українських ІТ-фахівців. Тому «інформаційний перекіс» неминучий. Менше з тим, в інших компаніях за необхідності практикують серйозний пошук людей на ринку. Проблема в тому, що формально вибір великий, але на серйозні проекти вибирати за великим рахунком немає з кого...

Рулезная статья. Актуальная тема и ситуация описана точно. А вот причины и выводы хочу прокомментировать. Причины:
1. Потому что больше всего вакансий в крупных «бодишопах» где высокая текучка. В небольшой компании, которая делает интересные проекты уже есть сплоченная команда и новые люди не нужны. А если и нужны то они найдут по рекомендации — вакансию публиковать не будут.
2. Потому что «бизнес большинства компаний строится на людях, которые не производят аутсорсинговый продукт, а непосредственно им являются». Такие компании больше всего заинтересованны в «толстом» заказчике с «бесконечным» проектом, который начался много лет назад и будет продолжаться еще столько же. «Мелкие» заказчики с рискованными проектами на новых технологиях их интересуют гораздо меньше.
3. На новых технологиях и R&D проектах риски намного выше. Сложно набрать команду («дутые» синьоры просто не потянут). Выше вероятность что заказчик «отвалится» (передумает делать, конкуренты обойдут и т.д.).

4. Аутсорс — заказчики банально не хотят платить за качество. Им очень тяжело продать хороший дизайн, юнит-тестирование, рефакторинг и другие «лишние» активности. Они готовы получить спагетти-код, лишь бы дешево. Естественно через 2 года такой проект становится не то что «не интересным» а насквозь гнилым (бесконечный багфикс и переделки).

Выводы: компании не волнует «интересность» проекта (их интересует прибыль). Поэтому они ничего не «должны» и не будут делать. У тех, кому повезло попасть на «интересный» или хотя-бы новый проект, просто будет меньше стимулов свалить и освободить место для других желающих.
Процент интересных проектов и новых технологий будет выше в небольших и новых компаниях, которым надо как-то продвигаться на рынок. Большие компании наоборот — плодят бюрократию и «загнивают».

Девелоперу же надо признать простую истину: «интересность», «рискованность», «доходность» и «утомительность» проекта взаимо-зависимы. Очень интересную работу делают в опенсорс-проектах бесплатно и в свободном темпе. Средне-интересная работа в стартапах, где платят мало, надо «вкалывать» и есть риск «прогореть». Ненапряжная «тупая» работа со стабильной оплатой — в «бодишопах». Интересная и высокооплачиваемая работа без «авралов» и «кидалова» — это скорее исключение, подтверждающее это правило.

Все верно... но я решил об этом заговорить поскольку опасаюсь, что поставив во главу угла «доходность» украина через несколько лет испортит себе репутацию вообще. Превратимся в такую себе Индию, только в 5 раз дороже (или сколько там).

проблема? наймайте таджиків і узбеків

Обижаете! настоящий украинец выбирает пакет «доходность+побыстрее»

И это правда. А почему? Да потому что в бедной, недоразвитой стране третьего мира нельзя планировать на много лет вперед. Завтра поменяется закон, власть или вообще страна исчезнет. Слышал хорошую фразу: почему страну назвали «Украина» — «Украли вот и назвали.»

Это в России Чубайс может вкладывать деньги в новые электростанции которые будут приносить доход уже его детям. А у нас: набивай карман, выводи за рубеж и вали пока не посадили.

Тем более, имея серьезную специализацию и успешные проекты, проще выбирать место проживания :)

Через несколько лет будет уже не важно в какой стране сидит девелопер. А «доходность» всегда будет во главе угла для любой коммерческой компании.
Раньше я работал в конторе где работа на «плохом» проекте оплачивалась выше, чем на «хорошем». Это было справедливо: хочешь интересной работы — поступись зарплатой.

хы про ипам 100% match :)

Я связывался напрямую с US/EU компаниями которые мне интересны... если сможете их заинтересовать получите интересный проэкт + интересную ЗП

Мне кажется, компаниям нужно вырабатывать специализацию и натаскивать сотрудников в определённой сфере.

А к кому конкретно этот призыв? К владельцам и директорам компаний? Так им и так вроде не плохо. Извините, но Вы требуете от других людей обеспечить Вам интересное и высокооплачиваемое рабочее место. Freelance — кстати реально выход и рост, там уже перестаешь мыслить категориями «сделайте мне хорошо», но и интереса с высокооплачиваемостью там не так чтобы очень много.

А вообще я давно наблюдаю насколько сильно отличается тональность DOU.ua от каких-нибудь специализированных сообществ Долины. На DOU практически не обсуждают «что делаем», а только разговоры о том «как» и «по чем». Создается впечатление, что о стартапах, их философии и собственно за чем они создаются (и закрываются) сотнями, большинство наших разработчиков не знает и не хочет знать категорически. К сожалению, возможно именно поэтому, в Киеве (и вообще в СНГ) экосистемы стартапов почти нет.

Причина одна — новые интересные проекты не идут в Киев:

:) А я скажу наоброт. Интересные проекты должны идти не в Киев, а из Киева. Кто мешает сделать что-то интересное самим?

Я делаю, успешно, и как раз и призываю других поступать также

На DOU.ua обговорюється рівно те, що цікаво його творцям :-)

Это уже практически обвинение в цензуре.

Аж ніяк. Цензура — недопущення публікацій, які суперечать переконанням власника або редакції. Редакційна політика — публікації на теми, які цікавлять власника або редакцію.

Единственное проявление редакционной политики в рубрике «Колумнисты» — требование, чтобы тексты не были ранее опубликованы в другом месте.

Гм, в такому разі така у нас публіка, раз

На DOU практически не обсуждают “что делаем”, а только разговоры о том “как” и “по чем”.

За всех расписываться не буду, но лично я не готов давать конкретные публичные ответы на вопрос «что делаем» — то, что работает для меня, вполне может не сработать для кого-то другого.

Так само може не спрацювати і чуже

«как» и «по чем»

Что в украине нету обстартапных сайтов? Доу не об этом.

Очень верное замечание про долину. Разруха начинается в головах

Всё просто. Вот у меня есть интересный проект с современными технологиями, но нет зарплатного бюджета в $2.5k+, нет теннисного стола, нет медстраховки и соцпакета. Автор бы остался у меня работать?

А что до увольнения — как по мне три из шести это ещё неплохой показатель. Со всеми этими инфляциями тайтлов, и ожиданиями что зарплата будет увеличиваться сама по себе, очень не многие готовы действительно работать.

Теннисный стол, медстраховку и соцпакет однозначно в топку. Я глянул одним глазом ваш сайт — вы, как мне показалось, делаете необычные вещи.

Я не понимаю, откуда у вас жесткое ограничение по зарплате — это ведь не outsourcing — возьмите отличного разработчика на пол дня за $2K и, скорее всего, это будет существенно лучше чем среднестатистический разработчик за $2.5.

Я не понимаю, откуда у вас жесткое ограничение по зарплате — это ведь не outsourcing — возьмите отличного разработчика на пол дня за $2K и, скорее всего, это будет существенно лучше чем среднестатистический разработчик за $2.5.
Религия не позволяет.

возможно вы удивитесь, но так и есть

100% так и есть. НЕ ПОЛОЖЕНО и точка! Собрались хозяева бизнеса, определили основные постулаты и принципы и возвели в ранг закона, обсуждение которых для наемного персонала — табу. Пересмотр фундаментальных пунктов происходит (как правило) после провала стартапов, значительного падения продаж, ухода ключевых сотрудников либо совладельца. Коррекция политических убеждений по ходу развития проекта — высший пилотаж зрелого руководства/собственника.

Это вы о каком-то своём опыте рассказываете?

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

Да, в целом идея хорошая, но мне не приходилось видеть эфективно работающих в двух разных местах по пол-дня разработчиков. Программирование оно затягивает.

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

Резюмируя — интересных проектов полно, но если ты ставишь высокую (аутсорсинговую) планку по зарплате, то это автоматом отсеивает много компаний, и 99% из оставшихся будут бодишопы.

мне не приходилось видеть эфективно работающих в двух разных местах по пол-дня разработчиков.

Достаточно, чтобы вашу половину дня он работал эффективно. Вторая половина дня может быть «фиестой» в виде поддержки предыдущего проекта.

А может оказаться так, что «фиестой» окажется ваш проект.

Я тоже считаю, что человек, посвящающий все свое время одному проекту, думает только о нем, и все отличные идеи, которые его посещают, он несет туда. Это очень ценное свойство, я не хочу его терять.

Нести идеи можно во все проекты, это не материальный объект.

Верно, но их не становится вдвое больше, если человек работает на двух работах.

Че, еслиб за пол дня платили 2К, то остальную пол дня можно бить баклуши (если не стремиться заработать по максимуму конечно). Над этим стоит подумать ;-)

Ну вот какой смысл нанимать себе в команду чувака, которому в целом впадляк работать, и который любит бить баклуши? Чем он усилит команду?

Алексей, в этой ветке мы обсуждаем чуть другой сценарий — когда стартап, у которого нет cashflow предложить 3+ тысяч сегодня и довольствуется джуниорами, имеет шанс попробовать привлечь высококласного специалиста (по собственным критериям) предложив не полную, а частичную занятость.

И мне кажется людей, у которых ситуация позволит либо недосыпать либо работать где-то еще, достаточно, результат труда будет достойный (если ему будет не интересно — он на такую работу просто не пойдет), и, когда возникнет возможность, он с удовольствием пример предложение full time.

Не, ну понятно, что привлечь крутого чувака хоть как-то лучше, чем не привлечь крутого чувака вообще. Только надо отдавать себе отчет, что здесь цель, а что — средство.

Ну чего же сразу впадляк работать? Весь этот фриланс рекламируют наличием свободного времени.

Только все умалчивают сколько времени потрачено что-бы этого добиться.

Ну, тут как по Высоцкому: «если хилый — сразу в гроб!»

Хорошо что ситуация позволяет, пока не вырабатаешь методику и на получишь хорошего клиента, работать «скучной старой» работе.

Проект без бюджета изначально неинтересен ;-)

без бюджета проектов не бывает, у всех есть бюджет, вопрос только в его размере

Понимаешь, интересный проект сам по себе нафик никому не нужен: поучиться и свалить на больше з.п. — вот что интересно.

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

А чем мотивируется машинист электровоза? Может ему платить вообще преступление? Если результат устраивает заказчика, не все ли равно чем он там мотивируется зарплатой или еще чем то?

Вы вообще смысл прочитанного пытаетесь понять, или сразу комментарии пишете? Платить выше среднего машинисту электровоза, который говорит «говно эти электровозы, но раз бабла платите много я поезжу» — я бы не стал. Мастерство оно в деталях, а с таким настроем в деталях всё будет плохо.

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

ИМХО, не всегда: можно делать все качественно и добротно ради того, чтобы улучшить в себе эти качества, чтобы потом их продать подороже :)

не интересно заниматься тем чем вы занимаетесь, и мотивируетесь вы исключительно зарплатой

Не согласен: нравится то, что получается. Как может у меня получаться что либо, если я не вижу смысла в работе? Вот когда на кону крупная сумма, появляется сразу интерес, как следствие желание сделать работу получше — чтоб в следующий раз позвали.

платить вам выше среднего это преступление против рынка разработки.

Опять — же не согласен. Лучше заплатить дорого и получить искомое, чем нанять товарища с горящими глазами, он будет кодить с утра и до забора и не сделает нихрена.

нравится то, что получается

это уже другая мотивация. ЗП тоже хорошая мотивация, но плохо когда единственная.

Лучше заплатить дорого и получить искомое

так вряд ли выйдет получить искомое, если

результат вашей работы скорее всего ниже среднего

ЗП тоже хорошая мотивация, но плохо когда единственная

Зарплата единственная мотивация в конечном итоге. То есть, когда тебя хвалят за то, что вот, ты самый — самый классный, это конечно льстит эго. Но с другой стороны, какое мне дело до мнения незнакомых людей? Ну хвалит меня джуниор — Иван Тимофеевич Пупкин, что мне с этого — то? Бабла ведь это не прибавит.

Может быть другая мотивация: сделать мир немножко лучше — помочь тем, кто нуждается. Но с другой стороны, наши IT — проекты, это на 95% просто экономия бабла.

Я могу понять ученых, медиков, литераторов, артистов, товарищ делающий очередную «игрушечку» для прыщавых подростков с айфонами, при этом кричащий: «я — двигатель прогресса», мне смешон.

Давайте признаем: все в мире делается из за бабок или из любви. Вы что, очень любите своих заказчиков(банки в оутсорсинге, тупые подростки в мобильных играх)?

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

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

Я правильно понимаю что сумма в $2k для вас не крупная?

Я правильно понимаю что участвовать в Open Source вам не будет интересно, и там нет смысла делать свою работу «получше»?

Вам действительно кажется что «искомое» я могу получить только от вас и задорого, а не от товарища которому нравится то что он делает («горящимие глаза»)?

Я правильно понимаю что участвовать в Open Source вам не будет интересно, и там нет смысла делать свою работу «получше»?

OpenSource — это хорошая самореклама. Именно это мотивирует делать получше.

Вам действительно кажется что «искомое» я могу получить только от вас и задорого, а не от товарища которому нравится то что он делает («горящимие глаза»)?

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

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

А то что выше было это типичная позиция жадного работника? Я не говорю что это плохо, каждый работник настроен на свою аудиторию и на свой интерес. Кому-то нравится ходить по собеседованиям и надувать щёки, в надежде получить прибавку в $100, кто-то ищет середину, а кому-то проще работать на совесть, получать удовольствие от того что он делает, и достойную зарплату в придачу.

И не надо рассказывать что собственники продуктовой компании платят «свои личные деньги отрывая их от сердца», и хотят чтобы все работали за 3 копейки.

А то что выше было это типичная позиция жадного работника?

Ну да, это типичная реакция жадного работодателя, он начинает обвинять в жадности работника :)

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

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

И не надо рассказывать что собственники продуктовой компании платят «свои личные деньги отрывая их от сердца», и хотят чтобы все работали за 3 копейки.

Но это же Вы рассказываете что зарплата на 500$ меньше, «тому що продуктовая» :)

собственники продуктовой компании платят «свои личные деньги отрывая их от сердца»,

У меня правило — не работать с отечественным работодателем. Только оутсорс, или иностранные стартапы. У нас все ещё надеются, что сладкая халявка вернется. Америкосы — же знают: люди ходят на работу за баблом.

сумма в $2k для вас не крупная?

Не крупная

участвовать в Open Source вам не будет интересно

Опенсорс хорошо продается. Пример — Spring Framework, Hibernate.

«искомое» я могу получить только от вас и задорого, а не от товарища которому нравится то что он делает

Не только от меня, но другие хотят бабла ещё больше :).
Красноглазики они хороши на простых проектах, или на проектах, где цена ошибки не велика.
Хороший пример — игрушки. Если зависло, сервер перегружается и все.

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

Так что или опыт, или глаза горят — третьего не дано.

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

А тебе сколько годков? Что то мне подсказывает, что 25 ещё нету.

Если это так, расслабься — ты ещё познаешь мир. Как трехлетний ребенок. Вот сделаешь несколько проектов, поймешь, что в общем — то миру от них ни холодно — ни жарко и приоритеты изменятся.

25 нету. Но несколько проектов уже сделал. И вопрос не в том холодно или жарко миру от них (тут соглашусь, большая часть выполненных проектов под это попадут, но не все). Тут вопрос в удовлетворении от того что ты делаешь, и цель получить на выходе качественный, как с внешней так и внутренней стороны продукт. А если думать о з/п тогда такой продукт не получишь и он действительно не будет особо интересен.

Ну значит пройдет просто с годами: посмотришь на чужие машины,дома женщин наконец. Захочешь отдохнуть не в замусоренном крымском поселке, а в пятизвездочном отеле, наконец, просто немного устанешь.

Это этап взросления, если хочешь знать.

Не слушай никого, все правильно делаешь.

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

но о деньгах лучше забыть заранее.

Инфа 100% ? :)

Да, погрешностью можно пренебречь.

Ну это, мягко говоря, не соответствует действительности. При чем как для наемного сотрудника, так и для предпринимателя. Хотя не спорю, в аутсорце ЗП (средняя по палате) выше и скилы требуются более однородные.

Ну что ж палите тогда тему где там в геймдеве высокие зарплаты? При этом не нужно иметь специфические скиллы типа PS3, XBox, ... а только учитывая PC.

Android и iOS спецы крайне востребованы. Flash разработчики чуть теряют в популярности, но зато JavaScript набирает обороты. Серверная часть PHP, Ява и т.д. Везде ЗП рыночные.

Это не PC и их востребованность постоянно скачет то вверх то вниз. Насчет Flash/JS не знаю как там сейчас.

Хреново там сейчас. В связи с последними заявлениями Адоби, хомячки отвернулись от флеша в сторону HTML5. Им и так — и сяк, мол вы понимаете, возможности флеша превышают этот ваш хтмл на порядок, в отдельных местах на два порядка. Нет, говорять, хтмл5 хотим.

С другой стороны, подтверждаю: з.п. в геймдеве в среднем 2/3 от оутсорсинговой при большем входном пороге.

Так что хотите бабла — бегом в оутсорс, а игры по вечерам, в свободное от работы время.

Так что хотите бабла — бегом в оутсорс, а игры по вечерам, в свободное от работы время.

Нет! Игры наше всё! Без игр не было бы интереса изучать программирование, первые игры как проекты были на порядок сложнее офисных продуктов! Там был и реалтайм, и базы данных, и графика с анимацией, и файловые операции с компрессией декомпресией, и работа со звуком ... — все в одной игрушке ...

Ну значи интерес к работе важнее денег — твоё право.

Хреново там сейчас. В связи с последними заявлениями Адоби, хомячки отвернулись от флеша в сторону HTML5. Им и так — и сяк, мол вы понимаете, возможности флеша превышают этот ваш хтмл на порядок, в отдельных местах на два порядка. Нет, говорять, хтмл5 хотим.

Так объяснение простое — флеш айпадом не поддерживается :)

В виде Adobe Air — вполне себе поддерживается, кстати

флеш айпадом не поддерживается

Флеш айпадом вполне себе поддерживается в виде AIR — приложений.

Тут дело в другом: Адоби не знает, как закосить бабла на флексе(не путать с флеш), поэтому отправила его в свободное плавание. До этого, адоби отказался от поддержки флеша в мобильных броузерах. Я подозреваю, что по той же причине.

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

Юзвери они ведь такие: слышали звон, да не знают где он.
На данный момент, в сегменте разработки насыщенных интернет приложений для писишных броузеров флешу альтернативы нет. Этот ваш ХТМЛ5 по возможностям не приблизился даже к флешу пятилетней давности.

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

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

что, неужели так все плохо, что очень сложно в .Net найти интересную работу за рыночные деньги? Я думал это перспектива недалекого будущего. Переходите в более простые технологии, PHP, Python тут пока/уже много интересной работы.

Практика показала, что украинские клиенты сейчас не против .net — так что переучиваться не пришлось — самый крупный клиент у меня — украинский интернет стартап. Естественно, объявления о работе не было.

ну тогда не пойму на что вы жалуетесь то :), опыт в стартапе это всегда хорошо.
Украинский (да и вообще) аутсорсинг на 80% неинтересен, потому что интересные вещи нельзя аутсорсить. Тут ситуацию можно изменить только снизив удельный вес аутсорсинга в нашем ИТ, тогда да будет больше интересной работы. Не стоит наверное ожидать, что 20% интересного мирового аутсорсинга ломанутся сюда и всем станет интересно. И более квалифицированными кадрами это, боюсь, не исправить.

Украинский (да и вообще) аутсорсинг на 80% неинтересен, потому что интересные вещи нельзя аутсорсить. Тут ситуацию можно изменить только снизив удельный вес аутсорсинга в нашем ИТ, тогда да будет больше интересной работы. Не стоит наверное ожидать, что 20% интересного мирового аутсорсинга ломанутся сюда и всем станет интересно.

Это мнение или факт? ©

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

По-моему, Сергей имел в виду именно это.

А вы уверены, что удельный вес людей, чью экспертизу можно продавать, среди всех IT-шников в целом, в Украине сильно больше чем в Индии? Мне кажется если он и больше то незначительно, а продавать и позиционировать индусы умеют.

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

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

Поддержал: Andrey Horsev

«Кукушка хвалит петуха за то, что хвалит он кукушку».

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

А что касается реальных денег — крупные консультанты типа CapGemini себя, вроде, тоже неплохо чувствуют и не страдают от того, что они — не Facebook.

тема правильная, но фриланс не выход. к примеру, кто доверит фрилансеру сложный проект на 10+ (100+) серверов? все равно нужна команда которая будет решать сложные и задачи и которые не под силу одному человеку

Я не призываю сегодня же увольняться и браться за что попало. Фриланс фрилансу рознь — первый проект был небольшим, часов 800 всего, после основной работы. Сейчас работаем над проектом с ежемесячным бюджетом более 500 часов. В той или иной степени вовлечено 9 человек, естественно, есть специализации.

Если нужна небольшая команда — как правило, под задачу собирается команда.

www.readwriteweb.com/..._for_mobile.php
“That was insanely vital to all of our growth at HuffPost. Literally HuffPost has people on every continent in every time zone. Eastern Europe and Latin America, India, Vietnam, Sri Lanka, Philippines.”

Некоторые из них были не командами, а отдельными фрилансерами из разных стран.

Мне понравилась статья, аргументы и выводы. Крайне интересное, и не очень далекое от «абстрактной правды» мировозрение!

Мне кажется, компаниям нужно вырабатывать специализацию и натаскивать сотрудников в определённой сфере.

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

Полностью согласен!

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

Не сыпьте соль на рану......

Со всем полностью согласен

Пост похож на топик «спалите тему» ))

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

В продуктовой фирме ( собственные программные/аппаратные разработки ) найдешь массу проектов на С++, скучно не будет, ИМХО

А где эти продуктовые фирмы со своими аппаратными разработками найти?

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

а можно хоть пару компаний, как пример, у которых есть свои аппаратные разработки. покетбук и самсунг не считаются :) Насколько я помню, на доу обсуждалась эта тема и говорилось, что у нас с эмбеддед все плохо, в частности из-за трудностей с поставками железа.

Незнаю кто такое говорил, взять к примеру VDMais, SEA Electronics, РКС Компоненты, Елекс, Софтсерв, и еще пол сотни фирм рангом пониже ... Некоторые компании вообще не светят свои хардварные продукты, так как любое упоминание «Made In Ukraine» снижает рыночную стоимость продукта ...

...И, наверняка, добовляет гемору с налоговыми :-)

Made in China снижает меньше ? :) Даже Софтсерв, интересно, спасибо.

Made in China снижает меньше ?

Лично для меня Made In China — это Ultra High Quality ! А миф о «китайском качестве» зародился благодаря перекупщикам дешевого барахла.

Согласен насчет мифа, но вроде ультра хай всегда считались Япония и Германия.

покажите мне эту массу проектов. Могу поверить, что гдето еще есть продуктовые конторы, пишущие на С++. Но только вот свежести этим проектам не хватает.

Embedded разработки низкого уровня. PCB / VHDL / C++, вполне актуально ... особенно если иметь доступ к комплектации через Китай или Штаты ...

QT и геймдев. Вроде достаточно свежо :)

в геймдеве уже тоже не очень легко найти С++
там сейчас флеш и пхп

хардкорный геймдев сейчас тоже в основном поддержка

да, точно. но она не так уж и популярна. все вроде что-то делают, но не заметно чтоб кто-то что-то сделал.

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

Я лично рассматриваю «интересные проекты», как инвестицию.

Да, можно пойти скажем на 2.5 вместо трех, но потом записать этот опыт в резюме и устроиться на пять. Если «интересность» не принесет бабла в обозримом будущем, нафик она мне не нужна.

Да, специализация — вариант. Главное, не прогадать с областью, в которой хочешь специализироваться.

Підписатись на коментарі