Про испытательный срок тоже есть несколько интересных историй из жизни.
Я не люблю увольнять людей и если есть шанс, что человек не безнадежен, если я вижу, что человек старается — я скорее за то, что бы оставить (условия всегда можно оговорить). Но однажды пришлось уволить человека, который отработал больше года (т.е. испытательный срок прошел), но абсолютно ничего не мог сделать. Даже после детальных объяснений. Даже с троекратным превышением сроков. При том, что позиция его была не джуниорская. В то же время мои джуниоры справлялись с этими же заданиями на ура, даже без разжевывания деталей. Когда я переговорил со всеми тим лидами, у которых он работал, оказалось, что я не один такой. Все отзывались об этом товарище очень негативно. Вопрос: как он смог пройти испытательный срок?
Недавно товарищ, не имея опыта проведения собеседований, взял на работу человека, который, как оказалось, не знает банальных алгоритмических вещей. Брал он его джуниором и с надеждой на то, что он будет развиваться. Но по прошествии половины испытательного срока (~1.5 месяца) человек так и не смог выполнить элементарные задания. Решили уволить. Но… Оказалось, что это не так то просто. И вышестоящее начальство посоветовало «договориться» на «по собственному желанию». Почему именно так, почему не воспользовались тем, что он еще на испытательном сроке — я не знаю, не вникал в суть вопроса. В общих фразах — это очень сложно, не захотели возиться. Уговорить человека расстаться по хорошему тоже было очень не просто…
Позвольте не согласиться. Старый работник развивает проект, который перебежчик оставил. Развивает хорошо, нареканий нет. С работой справляется. Если работник не справляется — зачем тогда его держат? А то, что кто то прошел собеседование — еще ни о чем не говорит. Я знаю несколько человек, которые на отлично проходили теоретические собеседования, но практически ничего не могли сделать (обратное тоже нередкий случай, когда на собеседовании теоретическом все не так круто, как в бою). А если Вы сомневаетесь, не запылились ли Ваши сотрудники — проводите им аттестацию, оплачивайте курсы повышения квалификации и тд. Причем не надо обязаловки. Если сотрудник хочет повышения — пусть пройдет аттестацию. Это адекватно, ИМХО.
Кстати да, присоединяюсь. Аналогичную ситуацию наблюдаю в Москве. Много знакомых/коллег добиваются повышения именно таким образом. В том числе не только ИТ специалисты. И объясняют это следующим образом: поработал в другом месте (у конкурентов, например) — набрался опыта, значит можно повышать. И это обидно, потому что один человек работает год на одном месте, реально двигает (бизнес/проект/тд), а другой пол года там, пол года там а по сути нигде и никак. Перебежчика повышают, а того, кто сидит и работает — нет…
Обычно происходило так: ты приходишь на новое место работы полный надежд, что это работа твоей мечты. Но постепенно все скатывается в полную опу (или ты прозреваешь и начинаешь видеть то, что изначально было скрыто за красивым фасадом). А вот причины самые разные: хорошая команда, но начальство сговнялось (показало свое истинное лицо); хорошее начальство и люди, но проекты постепенно перешли в разряд УГ; интересные динамичные проекты, но с командой невозможно работать и т.д… Даже иногда задумываюсь, а бывает ли так, что бы все вместе: хорошая компания, хорошее руководство, хорошая команда, интересный проект…
Жаль, что в Москве JUG не так активен… Очень бы хотелось посетить конференцию, но не уверен, что получится выбраться в Питер, да еще и на два-три рабочих дня…
Работаю только под музыку. Помогает сконцентрироваться. Русский рок — когда все хорошо и что-нибудь очень тяжелое, когда надо много думать или много и быстро делать. В общем, чем труднее задача — тем тяжелее играет у меня музыка =) При этом мне не важно, знаю я текст или нет, подпеваю или вообще не замечаю, новая, незнакомая мелодия или заслушанная до дыр — производительность от этого не зависит. Все словно идет отдельным процессом.
Сейчас очень много open source проектов, которые могут делать практически все что угодно.
И тем не менее, посмотрите сколько собственных решений написали для себя Facebook, VKontakte и прочие. Все очень сильно зависит от задачи и от масштабов.
Ну вот, пример ситуации. Вы покупаете продукт, который позволяет писать iOS приложения. Например решение от Xamarin. Apple известно тем, что с релизом новой OS заставляет девелоперов переходить на последнии API. В случае если лиценизя на новую версию изменится, вы получаете тут попадос. Если на этом построен ваш бизнес, ему может наступить хана.
Повторюсь, что я не специалист в области права, а так же не знаком с решениями от Xamarin и условиями их распространения — я тружусь несколько в другой области. Но могу сказать только одно: внимательно читайте условия договора… И еще, ваше приложение должно быть абстрагировано от используемых компонентов. Купленная библиотека помогла Вам быстро стартануть и выйти на рынок? Отлично! В следующей версии вы не можете ее использовать? Что ж, берем другой компонент и подпихиваем его в приложение. Если все было правильно сделано изначально, то это не потребует больших затрат. И даже разработка своего компонента в этом случае будет уже более осмысленной, т.к. Вы получили значительный опыт использования стороннего компонента, Вы прощупали все его достоинства и выявили недостатки и теперь вам не составит труда избежать большинства граблей, на которые вы обязательно наступите, если будете писать все с нуля сразу. Что же касается факапа в бизнесе, то тут еще при оценке необходимости покупки компонента Вы должны учитывать этот риск.
При наличии готового компонента приемлемого качества практически никогда не будет разумнее писать самому.
А на ваши замечания насчет рисков можно ответить следующее:
— Большинство вендоров предлагают вначале скачать ознакомительную версию, с которой можно поиграться, выяснить все нюансы. Так же все возникающие вопросы можно обсудить с поддержкой. Если вендор отказывается предоставлять ознакомительную версию и отвечать на ваши вопросы — тут что то не чисто и, наверное, не стоит платить за этот компонент. Хотя, конечно, и тут наверняка есть исключения.
— При покупке компонента ты заключаешь договор, и после его заключения условия оплаты меняться не могут. Теоретически. Правда тут я не силен, юридические аспекты лучше решать с юристами. Но в моей практике как раз с этим проблем не было.
— Многие вендоры (по крайней мере это касается Java) предоставляют source код, иногда за дополнительную плату. Наличие сырцов — это конечно огромный плюс, но и без него можно обойтись. В случае возникновения ошибок, которые растут из купленной библиотеки, они решаются письмом в поддержку.
А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
Вы все верно говорите. Но к сожалению, в реальном мире не все так просто. И менеджеры с такими взглядами, как у Вас встречаются не так часто, как хотелось бы. А еще, за ними зачастую стоит еще более прижимистое руководство. И хорошо, если альтернатив нет. А если есть бесплатная альтернатива? Не важно какая. Когда менеджера или директора волновало удобство API, подробная документация, качество кода и наличие поддержки бесплатного компонента? Да, такое случается. Но чаще приходится слышать: мы будем использовать бесплатную библиотеку! И доводы, что мы с этим компонентом в последствии отгребем на сумму, превышающую стоимость платного компонента не прокатывают. Пока не наступят на грабли. А когда стоимость компонента переваливает за 1k $ — все только усугубляется…
Если выполняются определенные условия, то почему бы не купить компонент? А условия просты:
— Адекватный заказчик/руководство
— По результатам анализа подходящих компонентов, платный компонент ушел в отрыв
— Адекватная стоимость компонента (как минимум дешевле разработки и поддержки подобного компонента собственными силами)
— В стоимость входит качественная поддержка
— Наличие исходных кодов (иногда такое необходимо, например, что бы убедиться, что компонент не навредит бизнесу)
На вскидку это основные пункты. Дополните, если что то забыл. Да, все это прежде всего относилось к Java проектам, но схожие пункты будут и при выборе компонентов для других технологий (разве что выбор бесплатных будет уже).
Нет варианта «Нет и пока не хочу». Скорость загрузки системы мне не так актуальна — я редко выключаю или перезагружаю компьютер (дата загрузки системы на рабочем компьютере — 28.06.2013). Скорость сборки проекта (хоть он и большой) — тоже меня не сильно напрягает. Полностью пересобирать проект требуется не так часто. И эти 5-10-15 минут в день я не считаю потерей — отдыхать тоже надо. Каких то серьезных тормозов системы именно из-за использования HDD я не испытываю. В то же время я с удовольствием перейду на SSD в будущем, когда они станут надежнее, больше и дешевле, т.к. глупо отрицать их достоинства и противиться прогрессу. Поэтому я не хочу, но не хочу пока.
Шутки шутками, но на хабре и правда собралось слишком много инакомыслящих и слишком свободно выражают свои мысли, тем самым подрывая авторитет властей… Так что однажды утром мы реально можем увидеть такую «заставку» вместо привычной странички… Перейдем на другой сайт? Ок, так ведь и его прикроют, рано или поздно… Бегать от проблемы никогда не было выходом…
Ага, давайте уповать на то, что эти законы не будут работать, что через некоторое время о них забудут, а потом и вовсе отменят… А тем временем наша дорогая, всенародно избранная дума, будет и дальше строгать подобные законы… И они тоже не будут работать, только ограничивать очередные наши с вами свободы… Два напрашивающихся вопроса: 1. Если дума принимает неработающие законы — на кой нам такая дума? 2. А ну как эти законы когда-нибудь захотят применить. Ведь однажды окажется, что на любого будет статья…
Сам не раз такое слышал. Но вода камень точит. А позиция страуса ни к чему хорошему обычно не приводит. Бороться надо, а то мы только и умеем, что на кухнях под рюмку чая с друзьями политиков хаить…
Повторюсь, дело лишь в правильно поставленной пропаганде. Люди так настроены только потому что не знают сути, не понимают последствий, считают, что их это не коснется и т.д. Именно поэтому необходимо активное участие интернет ресурсов. Блокирующие страницу статьи с разъяснениями, например.
Я не люблю увольнять людей и если есть шанс, что человек не безнадежен, если я вижу, что человек старается — я скорее за то, что бы оставить (условия всегда можно оговорить). Но однажды пришлось уволить человека, который отработал больше года (т.е. испытательный срок прошел), но абсолютно ничего не мог сделать. Даже после детальных объяснений. Даже с троекратным превышением сроков. При том, что позиция его была не джуниорская. В то же время мои джуниоры справлялись с этими же заданиями на ура, даже без разжевывания деталей. Когда я переговорил со всеми тим лидами, у которых он работал, оказалось, что я не один такой. Все отзывались об этом товарище очень негативно. Вопрос: как он смог пройти испытательный срок?
Недавно товарищ, не имея опыта проведения собеседований, взял на работу человека, который, как оказалось, не знает банальных алгоритмических вещей. Брал он его джуниором и с надеждой на то, что он будет развиваться. Но по прошествии половины испытательного срока (~1.5 месяца) человек так и не смог выполнить элементарные задания. Решили уволить. Но… Оказалось, что это не так то просто. И вышестоящее начальство посоветовало «договориться» на «по собственному желанию». Почему именно так, почему не воспользовались тем, что он еще на испытательном сроке — я не знаю, не вникал в суть вопроса. В общих фразах — это очень сложно, не захотели возиться. Уговорить человека расстаться по хорошему тоже было очень не просто…
И тем не менее, посмотрите сколько собственных решений написали для себя Facebook, VKontakte и прочие. Все очень сильно зависит от задачи и от масштабов.
Повторюсь, что я не специалист в области права, а так же не знаком с решениями от Xamarin и условиями их распространения — я тружусь несколько в другой области. Но могу сказать только одно: внимательно читайте условия договора… И еще, ваше приложение должно быть абстрагировано от используемых компонентов. Купленная библиотека помогла Вам быстро стартануть и выйти на рынок? Отлично! В следующей версии вы не можете ее использовать? Что ж, берем другой компонент и подпихиваем его в приложение. Если все было правильно сделано изначально, то это не потребует больших затрат. И даже разработка своего компонента в этом случае будет уже более осмысленной, т.к. Вы получили значительный опыт использования стороннего компонента, Вы прощупали все его достоинства и выявили недостатки и теперь вам не составит труда избежать большинства граблей, на которые вы обязательно наступите, если будете писать все с нуля сразу. Что же касается факапа в бизнесе, то тут еще при оценке необходимости покупки компонента Вы должны учитывать этот риск.
А на ваши замечания насчет рисков можно ответить следующее:
— Большинство вендоров предлагают вначале скачать ознакомительную версию, с которой можно поиграться, выяснить все нюансы. Так же все возникающие вопросы можно обсудить с поддержкой. Если вендор отказывается предоставлять ознакомительную версию и отвечать на ваши вопросы — тут что то не чисто и, наверное, не стоит платить за этот компонент. Хотя, конечно, и тут наверняка есть исключения.
— При покупке компонента ты заключаешь договор, и после его заключения условия оплаты меняться не могут. Теоретически. Правда тут я не силен, юридические аспекты лучше решать с юристами. Но в моей практике как раз с этим проблем не было.
— Многие вендоры (по крайней мере это касается Java) предоставляют source код, иногда за дополнительную плату. Наличие сырцов — это конечно огромный плюс, но и без него можно обойтись. В случае возникновения ошибок, которые растут из купленной библиотеки, они решаются письмом в поддержку.
А покупать стоит не только уникальные решения, но и просто качественные, с удобным API и отзывчивой поддержкой. А самому писать стоит только ну очень уникальные решения, когда все остальное просто не справляется с вашими конкретными задачами.
— Адекватный заказчик/руководство
— По результатам анализа подходящих компонентов, платный компонент ушел в отрыв
— Адекватная стоимость компонента (как минимум дешевле разработки и поддержки подобного компонента собственными силами)
— В стоимость входит качественная поддержка
— Наличие исходных кодов (иногда такое необходимо, например, что бы убедиться, что компонент не навредит бизнесу)
На вскидку это основные пункты. Дополните, если что то забыл. Да, все это прежде всего относилось к Java проектам, но схожие пункты будут и при выборе компонентов для других технологий (разве что выбор бесплатных будет уже).