Use cases, deployment, classes отлично вписываются в любое объяснение где используется 5 и больше сущностей. Аудитория вводится в курс дела за 5 минут, так как в UML ничего сложного нет —
UML позволяет просто визуализировать сложные вещи. Рискну предположить, что Вы UML никогда не использовали, но мнение имеете :)
Спасибо за ответ, очень интересный практический опыт.
Интересно, про SysML и применение UML в Embedded слышу впервые. Можете пожалуйста рассказать поподробнее как MDE и SysML применяются в Embedded? Для меня сейчас это актуально.
Что такое тру энтерпрайз?
Совпадает с моим опытом. На достаточно большом проекте, где знания передавались на уровне народного эпоса — из уст в уста, использование deployment diagramm добавило в проект ясности.
Спасибо за ответ! Какие виды диаграмм использовали?
Спасибо за развернутый ответ! Я так понял, вы используете UML в основном для себя. Приходилось ли его использовать на уровне проекта (при общении с другими разработчиками, с заказчиком)?
Птицу видно по полету видно опытного человека. Я встречал компании вообще без PM. И ничего — работают, успешно. Размер небольшой — до 50 человек. В больших же компаниях, PM имел профильное образование (например, финансы), достаточное чтобы говорить с бизнесом на одном языке, и самое элементарное техническое.
Забыл еще добавить — тимлид умеет разговаривать не только с начальством (что верно) но и с подчиненными. Насчет не очень хорошего программиста — это зависит от человека, а не от должности. Так же учтите, при команде человек в 8 у тимлида останется в лучшем случае
Team Lead — это Senior developer с организаторскими способностями. И да, он и немного HR, и архитектор, и бизнесаналист, и developer. Это тот самый зам руководителя (PM), который реально работает с людьми и с техникой, по аналогии с сержантом в армии или прорабом на стройке. Дальнейшая эволюция для тимлида — это Delivery manager, т.е техническое управление проектом в
Senior девов частенько назначают тимлидами, поруководить
Freelance-recruiter — обычный рекрутер, поддерживающий контакты с несколькими компаниями, договаривающийся с ними о бонусах и ищущий кандидатов по вакансиям компаний. Как и в любой работе, общаться или нет с рекрутером зависит прежде всего от персональных качеств самого рекрутера как человека. Если человек ответственный — у него и вакансии будут от надежных компаний. Если начинающий — то вакансии будут те, которые ему удастся добыть. Если хотите проверить рекрутера, посмотрите его профиль в социальных сетях (LinkedIn, Facebook). Количество подписчиков, общение в сети может сказать насколько человек вовлечен в активность freelance — рекрутера.
С точки зрения программиста sign-on бонусы это однозначно хорошо — дополнительные деньги. Касательно смены работы я не думаю, что sign-on бонус оказывает большое влияние на принятие решения программистом. Сам по себе бонус может быть причиной смены работы в небольшом количестве случаев, необходим более серьезный повод. Полагаю, в первую очередь пойдут за интересным проектом. Так что, по моему субъективному мнению, для компании sign-on бонус почти бесполезен, для программиста — хорош :)
Больше всего мне в статье понравилось то, что главная задача рекрутера — не отфильтровать кандидатов, а найти нужного (или нужных, т.е. диапазон для выбора).
Рекрутеру нужно понимать кого он ищет. Вряд ли сам рекрутер разберется во всех нюансах job description, тут на помощь должен прийти тимлид. Замечательно, если тимлид (даже с другого проекта) сможет присутствовать при разговоре с заказчиком, когда обсуждается job description. Это совет из моего личного опыта.
Старый тред конечно, добавил в общую копилку свой комментарий — может, кому-то будет полезен :)
IMHO, сколько бы вы не наняли джуниоров, это не гарантирует их превращение в Middle/Senior разработчиков.
Нужно нанять правильного сотрудника, и не важно, какого уровня он будет.
Правильный сотрудник — это разработчик само-мотивированный (которому не нужен постоянный менеджерский надзор),
способный вовремя и без напоминания приходить на работу, выстраивающий правильные отношения с руководством и коллегами,
способный к самообучению, и выполняющий поставленные перед ним задачи в срок.
Все вышеперечисленное — это скорее качества личности, чем профессиональные навыки, их не указывают в резюме. Тем более, у молодого
сотрудника еще не наработана соответсвующая репутация, и нет возможности получить рекомендации.
Даже забрасывая широкую сеть рекрутинга и принимая всех найденных, нет никакой гарантии, что подобные кандидаты будут найдены.
Я полагаю, должен быть какой-то момент прозрения у рекрутера, чтобы найти таких сотрудников, и личные качества рекрутера тоже играют роль.
Вот эти качества и можно поощрять премиями, за рост и долговременное присутствие сотрудника в компании.
Я считаю, что предложенный подход имеет смысл.
Специально нанятый программист с опытом написания систем автоматического тестирования. Результаты своей работы он передает тестировщикам, которые используют и дополняют написанный фреймворк своими тестами.